terça-feira, 15 de outubro de 2013

Openshift origin: sua nuvem privada

Como todos já sabem, o OpenShift têm evoluído cada vez mais e mais pessoas estão utilizando o serviço para desenvolvimento de aplicações na nuvem. Inclusive há histórias bem interessantes sobre aplicações e startups sobre OpenShift. Caso queiram conhecer alguns cases de sucesso, vocês podem  algumas delas através da página:

Mas para algumas startups, o maior caso de sucesso não é a aplicação hospedada no OpenShift e sim a infraestrutura da nuvem! Sim amigos, há startups que oferecem o serviço na nuvem assim como a Red Hat e a Google: trata-se de uma startup brasileira chamada getup (http://www.getupcloud.com). A startup oferece um serviço de hospedagem e PaaS exatamente como o OpenShift faz, porém com algumas vantagens para os desenvolvedores brazucas, como:
  • Infraestrutura totalmente feita no Brasil (seu ambiente foi construído no ambiente AWS assim como o OpenShift Online mas usando o datacenter de São Paulo)
  • O suporte é em Português (assim como no OpenShift Online, porém o plano pago do OpenShift ainda será lançado)
  • Acompanha todas as atualizações do OpenShift
Portanto, como devem ter percebido, o OpenShift é um projeto Open Source assim como todos os outros projetos que a Red Hat mantém. Por isso, é possível ter acesso ao código dele bem como é possível configurar uma nuvem privada dentro de sua própria empresa/startup/casa.
Tentarei nas próximas seções explicar as formas de como ter um ambiente OpenShift rodando em seu ambiente particular. Nota: Caso queira conhecer um pouco sobre a arquitetura interna do Openshift, basta ler essa página: http://aprendendo-cloud-computing.blogspot.com.br/p/aqruitetura-do-openshift.html

Antes, um aviso...

Após a Red Hat anunciar a sua versão On-Premise (ou seja, OpenShift rodando em redes privadas corporativas), houve a necessidade de separar as diferentes áreas para dar foco total aos engenheiros na inovação e produtização do OpenShift. Temos o OpenShift Online que é o serviço de hospedagem da comunidade acessível pelo endereço http://openshift.com e também com uma conta paga você terá acesso a mais recursos computacionais, o OpenShift Origin é o projeto Open Source da Red Hat e por fim temos o produto da Red Hat para empresas que é o OpenShift Enterprise. Abaixo você pode observar melhor a relação entre esses projetos:
Projetos OpenShift

Configurando o ambiente OpenShift

Esse é o jeito mais complexo de se construir  um ambiente pois você irá configurar cada componente em questão e portanto leva-se muito tempo para isso. No entanto, é a melhor forma de estudar a arquitetura do OpenShift e isso será fundamental para caso você tenha problemas com o ambiente que está configurando.
Para isso, siga o Deployment Guide na página do OpenShift: http://openshift.github.io/documentation/oo_deployment_guide_comprehensive.html

Automatizando a configuração com Puppet

Claro que é muito bacana seguir os passos para fazer o deployment para compreender como cada componente se encaixa (acredito, eu acho isso melhor que quebra-cabeças), mas em um ambiente como o próprio OpenShift Online (o serviço PaaS público da Red Hat), torna-se inviável provisionar servidores para comportar a carga sem ao menos ter uma forma de automatizar a instalação/configuração. Pensando nisso, a equipe da comunidade criou alguns scripts em puppet para provisionar de forma automatizada. Inclusive, é possível provisionar um ambiente completo OpenShift em um servidor (o famoso all-in-one) ou configurar alguns componentes somente no servidor. O site do OpenShift tem um Puppet Deployment Guide para isso e caso queira é só seguir: http://openshift.github.io/documentation/oo_deployment_guide_puppet.html
Abaixo uma classe Puppet para provisionamento do OpenShift all-in-one:
  class { 'openshift_origin' :
      #The DNS resolvable hostname of this host
      node_fqdn                  => "broker.example.com",

      #The domain under which application should be created. Eg: <app>-<namespace>.example.com
      cloud_domain               => 'example.com',

      #Upstream DNS server.
      dns_servers                => ['8.8.8.8'],

      enable_network_services    => true,
      configure_firewall         => true,
      configure_ntp              => true,

      #Configure the required services
      configure_activemq         => true,
      configure_mongodb          => true,
      configure_named            => true,
      configure_avahi            => false,
      configure_broker           => true,
      configure_node             => true,

      #Enable development mode for more verbose logs
      development_mode           => true,

      #Update the nameserver on this host to point at Bind server
      update_network_dns_servers => true,

      #Use the nsupdate broker plugin to register application
      broker_dns_plugin          => 'nsupdate',

      #If installing from a local build, specify the path for Origin RPMs
      #install_repo               => 'file:///root/origin-rpms',

      #If using BIND, let the broker know what TSIG key to use
      named_tsig_priv_key         => '<tsig key>',

      #If using an external ethernet device other than eth0
      #eth_device                 => '<ethernet device name, eg: enp0s5>',

      #If using with GDM, or have users with UID 500 or greater, add to this list
      #os_unmanaged_users         => ['gdm'],

      #If using the stable version instead of the nightly
      #install_repo               => 'release',
      #dependencies_repo          => 'release',
    }

Download das Máquinas Virtuais (o famoso Lazy Mode)

Se vocês forem como eu, então procurarão pela maneira mais fácil. =D Trata-se simplemente se um repositório onde há diversos arquivos de Máquinas Virtuais já instalados e configurados com OpenShift e é só importar para o Hypervisor de sua preferência. Assim, você terá o mínimo de esforço necessário para rodar o OpenShift localmente em sua máquina/servidor.
Tela de início da Máquina Virtual OpenShift
Você pode encontrar mais informações no Virtual Machine Deployment Guide: http://openshift.github.io/documentation/oo_deployment_guide_vm.html
Bom, por ora é isso. Quem tiver dúvidas ou teve problemas com alguns dos métodos para provisionar seu próprio ambiente OpenShift, podem postar um comentário. Até a próxima.

quarta-feira, 26 de junho de 2013

NoSQL e Hibernate - Será que vai dar samba?

NoSQL é a nova hype do momento, e todos estão aprendendo um pouco mais sobre novas formas de armazenamento. O termo foi introduzido por funcionários da Rackspace que queriam organizar um evento para discutir Bancos de Dados distribuídos. A idéia era discutir sobre Bancos de Dados que não se preocupam pelo ACID(Atomicidade, Consistência, Isolamento e Durabilidade).
Neste post, irei mostrar um pouco sobre adotar um banco de dados nosql em sua aplicação OpenShift utilizando java e um projeto recente da família Hibernate: o Hibernate OGM.

OpenShift e NoSQL

Desde o lançamento do OpenShift ele oferece três Bancos de Dados como repositório de dados para suas aplicações. Dentre eles, há 1 Banco de Dados NoSQL: O MongoDB.
O MongoDB é um Banco de Dados NoSQL que utiliza o conceito de armazenamento baseado em documentos, ou seja, ele guarda as informações em coleções e expressando o dado em um formato JSON, ou como o próprio site do MongoDB diz: um armazenamento orientado a documentos.

Rockmongo

Assim como o MySQL e o PostgresSQL possuem interfaces de gerenciamento na web (o phpMyAdmin, por exemplo), o MongoDB também possui uma interface de gerenciamento: o Rockmongo.

Hibernate OGM

O Hibernate OGM (Object Grid Mapping) é um subprojeto do Hibernate que permite utilizar os mesmos conceitos do ORM(Object Relational Mapping) em Bancos de Dados NoSQL. Assim podemos mapear objetos e persisti-los no Banco de Dados sem precisar conhecer as formas de inserir esses dados.

Como fazer deploy de uma aplicação Hibernate OGM no OpenShift?

Para dar início, vamos criar uma aplicação Java no OpenShift e adicionar os cartridges MongoDB e Rockmongo:
$ rhc app create -t jbossas-7 -a nosql
$ rhc app add-cartridge mongodb-2.2
$ rhc app add-cartridge rockmongo-1.1
Para esse post, eu utilizei o repositório do Github do próprio OpenShift com o projeto kitchensink (um pequeno CRUD muito utilizado para criar quickstarts para o JBoss) adaptado para utilizar o Hibernate OGM. Você pode encontrar o projeto em:

https://github.com/openshift/openshift-ogm-quickstart

Agora, iremos adicionar a URL do repositório Github em nosso projeto OpenShift:

$ cd nosql
$ git remote add upstream -m master git://github.com/openshift/openshift-ogm-quickstart.git
$ git pull -s recursive -X theirs upstream master
$ git push
Agora, basta acessar o endereço: http://nosql-${namespace}.rhcloud.com e ver a aplicação rodando:

Aplicação NoSQL com Hibernate OGM e MongoDB
Como instalamos também o Rockmongo, você pode acessar utilizando o endereço http://nosql-${namespace}.rhcloud.com/rockmongo:

Aplicação Rockmongo

Considerações

  • Apesar de utilizar Hibernate EntityManager e com isso poder fazer uso de JPA, infelizmente ele não escaneia automaticamente pelas classes marcadas com @Entity. Você terá que referenciá-las no arquivo persistence.xml, senão não irá funcionar.
  • O projeto utilizado também faz uso de Hibernate Search para busca de dados, o que possibilita utilizar Full-Text Search em suas aplicações
  • Caso tenha feito o deploy do projeto mas não tenha encontrado as coleções da aplicação no Rockmongo, não se preocupe. O MongoDB (ou o Hibernate OGM, não entendi o processo nesse caso) só cria a coleção quando o primeiro registro é persistido.
Bom pessoal, é isso. Eu tive um bocado de trabalho para fazer o build por conta dessas considerações e também por conta da build Maven. Quem precisar de ajuda, posta um comentário que eu procuro ajudar o mais rápido possível.

terça-feira, 18 de junho de 2013

Treinamento de MongoDB

A 10gen (empresa ligada ao MongoDB, um banco de dados NoSQL), em parceria com a EdX, criou uma série de treinamentos ao estilo MOOC (Massive Online Open Course).
Trata-se de treinamentos para quem quiser conhecer mais sobre o MongoDB e como utilizá-lo. Uma grande notícia é que eles estão criando cursos tanto para quem é desenvolvedor quanto para quem é DBA. Atualmente eles possuem 3 treinamentos:

  • MongoDB For Java Developers
  • MongoDB For Developers (Esse utilizando Python como linguagem)
  • MongoDB For DBAs

Somente os dois primeiros treinamentos estão em curso no momento, mas logo eles irão disponibilizar mais treinamentos. Para quem quiser conferir, basta criar um conta no site:

https://education.10gen.com/

E depois aplicar nos treinamentos já em andamento. Irei explorar um pouco sobre MongoDB num próximo post utilizando o novo módulo do Hibernate: O Hibernate OGM. Aguardem!

segunda-feira, 17 de junho de 2013

Novidades do OpenShift Online

Nesta semana está sendo realizado em Boston o Red Hat Summit, o maior evento que a Red Hat promove sobre suas tecnologias e sobre Open Source. Como em qualquer evento que uma grande empresa promove, sempre há lançamentos na véspera ou no período em que o evento ocorre, portanto eu quero apresentar algumas das novidades que foram apresentadas até agora para o OpenShift.

Downloadable Cartridges e outras tecnologias disponíveis

Uma das maiores funcionalidades para mim é a liberdade de utilizar linguagens e tecnologias no OpenShift. Java, Python, Perl, PHP e outras linguagens podem ser utilizadas e ainda por cima pode-se utilizar o famoso cartridge faça-você-mesmo(DIY, ou Do-It-Yourself). Além de linguagens, há também as tecnologias de backend (MySQL, PostgreSQL e MongoDB) e Jenkins.
Na nova versão do OpenShift (atualizado recentemente), você tem agora mais liberdade de escolha porém sobre qualquer tecnologia e linguagem. Isso se deve ao novo conceito chamado de Downloadable Cartridges, onde você pode apontar para o repositório git desse cartridge e o OpenShift irá baixar o código, preparar o ambiente e já apresentar um Hello World clássico daquela linguagem.

Uma aplicação Ceylon de exemplo rodando no OpenShift
Abaixo uma listagem das novas linguagens/tecnologias disponíveis:

API de criação de cartridges simplificada

Antes era possível ter acesso a API de criação de cartridges para assim a comunidade poder adicionar suas próprias tecnologias, porém infelizmente só era possível utilizar quem utilizava a versão da comunidade (OpenShfit Origin, falarei sobre ele em outro post). Além disso, a API era muito complexa e levava muito tempo para poder adicionar novas tecnologias.
Recentemente, a equipe do OpenShift lançou a segunda versão da API que facilitou bastante a criação de cartridges para o OpenShift, e também pode ser utilizado com o OpenShift Online com a nova funcionalidade de Downlodable Cartridges (ver seção anterior)
Você pode conferir mais informações no blog do OpenShift sobre como criar um cartridge no OpenShift:

https://www.openshift.com/blogs/introducing-the-openshift-cartridge-api-version-2

Caso alguém queira fazer um projeto de cartridge, tenho algumas sugestões e iniciei o desenvolvimento deles. A quem interessar, me mandem mensagens que eu passo maiores informações.

Silver Plan

We are open for business! Agora o OpenShift Online possui um plano pago para quem quiser ter um apoio do suporte da Red Hat e dispor de mais gears (unidade do OpenShift que limita memória e storage) para suas aplicações. A versão gratuita ainda está disponível e todos aqueles que ainda não possuem ainda podem criar suas contas gratuitas, ou ainda fazer um upgrade. Startups podem criar uma conta gratuita, avaliar a ferramenta e o ambiente e quando quiserem (ou perceberem que já precisam de mais recursos) podem fazer o upgrade.
Para quem quiser saber mais sobre o Silver Plan, pode verificar na página do OpenShift:

https://www.openshift.com/products/pricing

Infelizmente, o Silver Plan é restrito a EUA/Canadá mas fiquem atento às novidades. A equipe de desenvolvimento já está trabalhando para um plano no Brasil. \o/

Templates para criação do ambiente OpenShift Origin em Openstack

Para quem conhece o OpenShift sabe que ele é uma solução conhecida como PaaS (Platform-as-a-Service), mas há soluções Open Source no mercado que permite criar um IaaS (Infrastructure-as-a-Service) e assim criar um ambiente local de OpenShift dentro dele.
Uma dessas soluções é o Openstack, que é uma comunidade com um monte de empresas com o propósito de criar uma solução para IaaS. E para quem quiser instalar o OpenShift Origin (versão do OpenShift Online da comunidade), pode utilizar os scripts automatizados para provisionamento do ambiente OpenShift de forma automatizada. Você pode conferir em:

https://github.com/openstack/heat-templates/tree/master/openshift-origin

Bom, por hora são essas as novidades. Eu particularmente achei muit boa as novidades, principalmente os Downloadable Cartridges. E vocês, o que acharam?

sábado, 20 de abril de 2013

O canivete suíço do desenvolvedor: ferramentas de diagnóstico para aplicações Java EE

Saudações a todos,

Estou postando direto do JUDCon 2013 Brazil para dizer meu muito obrigado a todos que compareceram e que vieram cheio de vontade de conhecer mais o ecossistema JBoss. Os workshops de Openshift (ministrados diretamente pelos evangelistas OpenShift) também foi um sucesso.

Para os que compareceram à minha palestra, segue abaixo a apresentação:

quinta-feira, 18 de abril de 2013

JUDCon Brasil 2013 - Não Percam

Amanhã começa o evento mais importante para a comunidade JBoss: O JUDCon, JBoss Users and Developers Conference. E como era de se esperar, teremos bastante assunto sobre OpenShift... \o/
Eu irei palestrar no evento, mas o assunto não está relacionado sobre Cloud Computing nem OpenShift (mesmo assim, espero que gostem). Mas para compensar, teremos workshops com os desenvolvedores do Openshift (Steven Citron-Pousty e Shekhar Gulati) e até um desenvolvedor brazuca (Fabiano Franz) apresentando.
Para quem quiser ir, ainda dá tempo. Acesse http://www.jboss.org/events/JUDCon/2013/brazil e veja o local e agenda do evento. Espero ver todos por lá.

Ferramentas de DevOps em Openshift

Introdução

Além de todos os benefícios que eu sempre venho dizendo e escrevendo neste blog do Cloud Computing, quero aqui mostrar um cenário do qual o desenvolvimento de aplicações pode se tornar cada vez mais prático utilizando  ferramentas que podem auxiliar o que chamados de DevOps (Development Operations). DevOps trata de unir o desenvolvimento, Quality Assurance (QA) e Infraestrutura (Technology Operations) de forma a estressar a comunicação, colaboração e integração entre esses times e com isso padronizando os ambientes de desenvolvimento e facilitando o gerenciamento de releases da aplicação.

Um gráfico que exemplifica o papel de DevOps em um processo de software  (Fonte: wikipedia)
Cloud Computing, além de provisionar um ambiente operacional para suas aplicações em questão de segundos, aproxima o desenvolvedor de um ambiente de produção (ou muito próximo dele) e assim o desenvolvedor consegue ter uma visibilidade muito maior de como sua aplicação irá se comportar em um ambiente desses. Entretanto, não podemos simplesmente botar todo o foco nisso sem esquecer em métricas de qualidade do código nem em integração contínua.
Nesse post eu irei mostrar que em Openshift você pode fazer tudo isso e ainda por cima disponibilizar publicamente e de uma forma bem simples.

Gerenciamento de projetos com Redmine

Redmine é uma ferramenta escrita em Ruby que permite a criação e gerenciamento de issues de projetos, além de servir como um repositório de documentos e arquivos relevantes ao projeto e também pode ser criada uma base de conhecimento em formato wiki. O que eu achei a maior sacada do Redmine é que ele traz uma visualização das issues em um gráfico Gantt(o gráfico preferido dos gerentes de projetos), podendo assim ver a situação do projeto de forma online.
Gráfico Gantt gerado pelo Redmine
Atualmente, eu venho utilizando o Redmine em um projeto pessoal meu e por isso eu venho estudando essa ferramenta para pode me organizar nas tarefas. Com ele, eu consigo ver exatamente o que eu quero que minha aplicação tenha e assim poder eu mesmo organizar as tarefas e ir registrando meu progresso.
Aliando a facilidade de provisionar um sistema como o Redmine com a infraestrutura de nuvem pública, é possível criar um ambiente para os gestores de projetos de uma startup a gerenciarem e monitorarem os projetos e seus detalhes de forma que não precisem manter essa infraestrutura (nem pagarem por isso).

Integração Contínua com Jenkins

Quem já ouviu falar de Integração contínua, com certeza já ouviu falar do Hudson/Jenkins. Essa ferramenta pode ser uma mão na roda para projetos com muitos desenvolvedores, onde ele auxilia a equipe a testar todo o projeto a partir do código que já se encontra em um repositório de código, desde compilando o código até executando testes unitários e de integração. Tarefas mais completas (e por consequëncia, complexas) chegam até a publicar os artefatos em repositórios como o Nexus.
Tela do jenkins e os detalhes de uma tarefa automatizada
Dentre todas as ferramentas que irei mencionar neste post, esse com certeza é o mais integrado ao ambiente OpenShift pois já nasceu com essa integração com o Jenkins e portanto é o mais fácil de se utilizar dentro do OpenShift.

Qualidade de código com Sonar

Para aumentar a qualidade de código de seus projetos, há a ferramenta Sonar para análise de qualidade de código. Obviamente, isso é feito de forma estática e baseado em regras de desenvolvimento. Para cobrir a qualidade do código em execução deve-se utilizar ferramentas de teste unitários, de integração, funcionais, etc. Isso tudo pode ser combinado no Jenkins em uma tarefa de integração contínua, com mencinado na seção anterior.
O Sonar já vem com algumas regras (algumas delas criadas pela própria Sun, e que Deus a tenha), o que permite que você não comece a criar as regras do zero e poupando tempo na definição das mesmas.
Tela do sonar com um exemplo de análise de um projeto
Um detalhe importante para utilizar o sonar em seus projetos OpenShift: o projeto é todo estruturado no Maven e portanto você pode utilizar o plugin do Sonar para assim poder executar a tarefa:
$ mvn sonar:sonar
Porém o plugin exige que se utilize uma URL com uma porta específica para acesso ao repositório do Sonar e registrar todas as informações relevantes à ele. Como no OpenShift, as regras de segurança são muito restritar, é necessário que você habilite o port forward em sua aplicação sonar com o seguinte comando:
$ rhc port-forward -a <aplicacao_sonar>

Monitoramento de aplicações com Openshift Metrics

OpenShift fornece um cartridge específico para o monitoramento da saúde de sua aplicação. Ela é muito simples, mas já te dá informações cruciais da sua aplicação(como consumo de memória e CPU). Para adicionar em sua aplicação o cartridge para monitorar sua aplicação, basta executar:
$ rhc cartridge add metrics-0.1 -a <nome-aplicacao>
Após a conclusão do comando, você pode acessar o Metrics através da URL:
http://<aplicacao>-<dominio>.rhcloud.com/metrics/

OpenShift metrics
Por ser uma ferramenta ainda experimental, o código ainda não está disponível. Acredito que em breve teremos mais funcionalidade e também a abertura do código.

Conclusão

As ferramentas apresentadas neste post podem ser instaladas de forma muito simples: seja pela ferramenta rhc ou pelo próprio console administrativo do Openshift ou até utilizando dos quickstarts da comunidade que, em sua maioria, se encontram no github do Openshift. Apesar da facilidade da criação desse ambiente, as contas gratuitas do Openshift permitem até 3 aplicações criadas e portanto você pode consumir toda a sua cota, mas nada te impede de criar várias contas e gerenciar essas aplicações em uma conta específica.

sexta-feira, 15 de março de 2013

Gerenciando suas aplicações no cloud com as ferramentas de cliente

Neste post, irei mostrar a ferramenta rhc, que permite gerenciar em linha de comando todas as aplicações, seu domínio e outras informações referentes à sua conta OpenShift. No primeiro post, eu mostrei muito por cima como criar uma primeira aplicação usando a IDE Eclipse utilizando o Plugin JBoss Tools. Tentarei aqui ser o mais neutro possível a respeito de plataformas então eu vou explicar como instalar a ferramenta no Linux, Mac OS e Windows.

Instalando a ferramenta no Linux

Para poder utilizar a ferramenta no Linux, é preciso instalar os seguintes pacotes:
  • rubygems
  • git
Como podem ver, a ferramenta foi escrita em Ruby e por isso apesar de mencionar a instalação de apenas dois pacotes eles trarão dependências adicionais para poder fazer os pacotes principais funcionarem.
Após a instalação com sucesso dos pacotes, basta executar o seguinte comando para instalar o rhc:
$ sudo gem install rhc

Instalando a ferramenta no Mac

Para instalar a ferramenta no Mac, é preciso ter os seguintes pré-requisitos:
Após a instalação, basta executar o comando:
$ sudo gem install rhc

Instalando a ferramenta no Windows

Para instalar a ferramenta no Windows, é preciso ter os seguintes pré-requisitos:
  • Instalar o Ruby 1.9 for Windows (Lembre-se de marca a opção "Add Ruby executables to your PATH")
  • Instalar o Git for Windows (Marque a opção "Run Git from the Windows Command Prompt")
Feito isso, basta executar o comando:
C:\> gem install rhc

Configuração inicial da ferramenta

O primeiro comando que iremos aprender é o comando:
$ rhc setup
Nele, você irá fazer as configurações iniciais da ferramenta, como gerar as chaves de segurança SSH para o login da ferramenta(muito importante para poder conectar ao repositório git das aplicações), a criação de um nome de domínio(com ele, todas as aplicações criadas pela sua conta levarão esse nome único para identificar aplicações criadas por você), e verificar alguma pendência de configuração exigida pelo OpenShift.
Após o procedimento de setup, ele irá gerar os seguintes arquivos:
<user_dir>/.openshift/express.conf
<user_dir>/.ssh
O primeiro é uma configuração bem básica do Openshift (inicialmente um usuário padrão ao usar o comando rhc, que pode usar outro usuário adicionando a opção -l no comando, e o endereço do servidor Openshift) e o outro é o repositório de chaves SSH para comunicação com os serviços Openshift. Sem isso, você não conseguirá fazer um git clone do repositório.

Criando a aplicação

Depois de preparado o ambiente, estamos prontos para a criação da aplicação. O comando para criar é:
$ rhc app create -a <nome_da_aplicacao> -t <tipo_aplicacao>
Onde o <tipo_aplicacao> pode ser:

  •  dyi-0.1
  • jbossas-7
  • jbosseap-6.0
  • jenkins-1.4
  • nodejs-0.6
  • perl-5.10
  • php-5.3
  • python-2.6
  • python-2.7
  • python-3.3
  • ruby-1.8
  • ruby-1.9
  • jbossews-1.0 (basicamente um Tomcat 6)
  • jbossews-2.0 (basicamente um Tomcat 7)
  • zend-5.6
Como podem ver na lista, a variedade de linguagens/servidores para desenvolvimento no Openshift tem crescido cada vez mais. E ainda podemos criar nosso próprio com o Do-It-Yourself Cartridge (farei um post explicando sobre isso). Essa tarefa irá criar um processo automático que no final irá gerar um endereço do repositório git e também a URL da sua aplicação no formato http://<nome_da_aplicacao>-<nome_do_dominio>.rhcloud.com

Snapshots da aplicação

Caso você queira criar backups de sua aplicação para posteriormente voltar às versões anteriores, o Openshift permite que você crie snapshots da sua aplicação e restaurá-los quando quiser. Em outras palavras, o snapshot é arquivo compactado que contém tudo que sua aplicação precisa para ser recuperada em uma outra gear do Openshift, tais como as variáveis de ambiente, o repositório git, os binários da aplicação, etc. Para criar um snapshot, basta executar o comando:

$ rhc snapshot save -a <nome_da_aplicacao> -f <nome_do_arquivo>

Assim, caso você queira restaurar a aplicação, execute o comando:

$ rhc snapshot restore -a <nome_da_aplicacao> -f <nome_do_arquivo>

Diagnóstico de problemas

Sempre pode ocorrer problemas e que precisam de nossa intervenção para que nossa aplicação possa voltar ao ar ou até mesmo monitorar nossas aplicações para procurar eventuais problemas. Para isso, o rhc possui alguns comando que podem auxiliar o desenvolvedor a encontrar o problema.
O primeiro de todos os comandos irá verificar a saúde da infraestrutura do Openshift:

$ rhc server

Nele, é possível verificar se o problema não é generalizado e portanto se há alguma ação que pode ser realmente tomada por conta da sua aplicação. Caso apareça a mensagem "All systems running fine", então estamos à salvo... =D
O segundo comando inspecionará todos os logs da sua aplicação e irá imprimir (sob demanda) as mensagens deles. O comando é:

$ rhc tail -a <nome_da_aplicacao>

Por fim, pode ser necessário inspecionar a performance em si da aplicação, assim verificando se a mesma está muito lenta, então pode ser necessário inspecionar as Threads do sistema. O comando para gerar o thread dump (um arquivo que descreve todas as Thread em execução do sistema) é:

$ rhc threaddump -a <nome_da_aplicacao>

Após a execução desse comando ele irá retornar uma mensagem dizendo onde o Thread Dump estará disponível, podendo inspecionar utilizando o comando descrito anteriormente. Para ser mais exato, o próprio rhc irá já enviar o comando completo que deve ser executado para inspecionar o Thread Dump.

Conclusão

Espero que esse post seja de muita utilidade a todos pois alguns usuários Openshift como eu adoram em algum momento utilizar a linha de comando para criar suas aplicações e até mesmo automatizar alguns processos. Fica aqui uma dica: todos esses comandos do rhc por trás há uma API REST que é consumida pelos comandos (que são nada mais nada menos que código Ruby). Em um post futuro explicarei sobre a API REST.

quinta-feira, 3 de janeiro de 2013

Migre suas aplicações Google App Engine para Openshift.

Há tempos que quando iniciei meu contato com Cloud Computing, sempre fiquei com o pé atrás ao falar de Google App Engine (GAE). Não que ele seja ruim, que não há escalabilidade ou qualquer coisa desse tipo, mas principalmente porque desenvolver com o GAE implica em utilizar apenas duas linguagens (Java e Python) e às vezes ter que se limitar a usar algumas coisas da própria linguagem suportada por esse PaaS(como o Java) e com isso podendo até não permitindo utilizar alguns de seus frameworks.
Um dos princípios que costumo falar ao adotar soluções PaaS é o de sempre verificar se o seu provedor não utiliza soluções fechadas (o famoso Vendor Lock-in) e portanto "prendem" o cliente a ficar em suas soluções sem uma chance de poder migrar as mesmas para um outro provedor. Neste artigo, irei descrever como migrar suas aplicações GAE para o Openshift, e de novo não porque Openshift é melhor e/ou GAE é ruim, mas principalmente por trazer maior liberdade para o cliente final poder avaliar outros provedores.

O Google App Engine(GAE)

O Google App Engine (ou GAE) é um dos pioneiros em se tratando de soluções PaaS(Platform-as-a-Service, ou Plataforma-como-um-serviço). Trata-se de utilizar a infraestrutura dos servidores do Google (a mesma utilizada pelo Google para manter todos os seus serviços no ar) para criar, desenvolver e administrar suas aplicações utilizando como linguagem o Java ou o Python. Não há o que negar sobre a performance dos datacenters do Google e sobre sua capacidade de inovação, o que fez com que o GAE se tornasse um dos principais provedores de soluções de Middleware gratuito para Cloud Computing, e também contém uma interface bem simples para monitorar e administrar suas aplicações.
Tela inicial do GAE
 O GAE oferece duas linguagens para desenvolvimento de aplicações, que são o Java e o Python. Em relação ao Python, o desenvolvimento de aplicações é tranquilo e conta com diversos (e bons) tutoriais na Internet para auxiliar no desenvolvimento. Já não consigo ver uma vantagem tão grande assim quando se fala de desenvolver uma aplicação GAE usando Java, já que há uma série de limitações que a Google impõe à linguagem, criando uma espécie de JRE White List que diz quais são as classes que podem ser usadas para o desenvolvimento de aplicações. Isso pode tornar alguns frameworks não funcionarem direito por conta dessas restrições (veja a página Will it Play) ou até mesmo terem que ser configurados de uma forma que dá um bocado de trabalho.
Interface administrativa do GAE
O GAE também possui um Datastore próprio baseado no conceito de BigTable e que é próprio do Google. Assim como toda a tecnologia provida do GAE, esse datastore é base para diversos serviços do Google, o que torna a confiabilidade no mesmo ainda maior. Entretanto, por ser uma tecnologia específica deles não há muito o que fazer se for o caso de migrar uma aplicação GAE para outras plataformas.
Por fim, e dessa vez quis deixar os serviços que eu digo que são os diferenciais do GAE, ele possui um esquema de versões da aplicação que eu acho muito bom. Ele consiste em implantar diversas versões de uma aplicação e com isso poder testar cada versão isoladamente (adicionando como sufixo o número da versão). Após o teste da última versão (ou da versão que deseja publicar), basta selecioná-lo na lista e pedir para publicar, com o mínimo de downtime em sua aplicação. Outro grande diferencial é o dashboard do GAE (ver figure acima), que fornece diversas métricas para monitoramente de administração da sua aplicação.
Novamente, meu objetivo aqui não é dizer que X é melhor que Y nem tirar os méritos de determinadas tecnologias. Quis aqui apenas expressar alguns dos pontos positivos e negativos e também fornecer alternativas para manter a liberdade de escolha de provedores. Com base nessa breve descrição, quis mostrar que uma aplicação GAE roda exclusivamente no ambiente do Google por motivos que forçam o desenvolvedor a utilizar tecnologias fechadas do Google e que portanto pode tornar a migração dessas aplicações inviável. Pensando nisso, eu quis criar este post para apresentar o projeto CapeDwarf. Explicarei na próxima seção no que consiste este projeto e também mostrarei como utilizá-lo.

O projeto CapeDwarf

O projeto CapeDwarf é um projeto da JBoss que visa criar um ambiente semelhando ao do GAE utilizando todo o ecossistema de middleware da própria JBoss. O criador do projeto, Aleš Justin, descreve o CapeDwarf como "uma implementação do Google App Engine, que permite que aplicações sejam implantados em servidores JBoss AS sem modificação". Mas como assim sem modificação? Está me dizendo que eu posso migrar uma aplicação GAE para o CapeDwarf sem mexer em sequer uma linha de código?
A resposta mais clara para a pergunta acima é: Sim! Você pode migrar aplicações GAE para o CapeDwarf sem alterar 1 LoC (medida da Engenharia de Software que indica Linha de código (ou Line of Code). A idéia é simplesmente criar uma série de subsistemas em cima do servidor de aplicações JBoss para que uma aplicação GAE possa viver fora do ambiente, utilizando jGroups, Infinispan e outros projetos da JBoss.org.
Você pode encontrar maiores informações no site do projeto.

Executando no Openshift

O passo a passo descrito nesta seção parte da premissa que o leitor leu o primeiro post a respeito dos primeiros passos para utilização do Openshift, portanto irei direto ao assunto.
Na tela de gerenciamento do Openshift, você verá a listagem de todas as aplicações criadas na sua conta (lembrando uma coisa importante: caso já tenha 3 aplicações criadas, sugiro criar uma nova conta ou remover uma das aplicações pois o Openshift limita uma conta free a criar até 3 aplicações sem habilitar Scaling) ou se não tiver nenhuma ele irá direto para a tela de criação de uma aplicação.
Tela de gerenciamento do Openshift
Na tela de criação da aplicação, procure por CapeDwarf. Basicamente, se trata de um servidor JBoss AS contendo toda a camada que o CapeDwarf implementa para "simular" os serviços do GAE.
Criação da nova aplicação
Depois de selecionado o tipo de aplicação, defina o nome da sua nova aplicação. Note que o Openshift irá pegar todo o código necessário para configurar o ambiente do github. Caso queira ver outras opções de aplicação, poderá verificar diretamente no site.
Configuração da nova aplicação
Por fim, clique no botão "Create Application"
Finalização da criação da aplicação
Feito isso, o Openshift irá realizar os processos iniciais (propagar o novo endereço em seus servidores DNS, clonar o código do Openshift, fazer o build, etc.) e depois mostrará a tela de conclusão com a URL da sua nova aplicação. Se você chegou até aqui, então estamos no caminho certo. =D
Tela de informações sobre a nova aplicação criada
Copie e cole o endereço criado para sua nova aplicação e acesse em seu navegador favorito(não se preocupe se a URL retornar HTTP 500 ou HTTP 404, isso só indica que a URL ainda não propagada nos servidores DNS). Você terá a tela abaixo:
Tela inicial da nova aplicação
Essa é a tela de apresentação do CapeDwarf rodando no Openshift. Veja que há também um endereço git configurado para sua aplicação, portanto faça o clone de seu repositório para poder copiar o código. Como uma alternativa caso você tenha apenas o arquivo .war gerado da sua aplicação, copie no diretório <app_dir>/deployments, e não se esqueça de gerar um arquivo vazio dentro de <app_dir>/.openshift/markers/skip_maven_build para dizer ao Openshift não gerar mais builds. Esse procedimento não sobreescreverá a tela inicial da aplicação, devendo ser acessada como http://gaeapp-meudominio.rhcloud.com/minhaappgae.
Você leitor deve se perguntar agora: mas o GAE permite monitorar minha aplicação através de uma interface administrativa, por acaso migrando minha aplicação para o CapeDwarf/Openshift eu vou perder essa funcionalidade? A resposta é não. Se você observar rolando a página um pouco mais pra baixo, há uma seção chamada Admin Console, onde ele fornece um usuário e senha que você pode acessar a interface administrativa de sua aplicação
Senha gerada para acesso ao admin console
Com esse usuário e senha em mãos, basta acessar a URL http://gaeapp-meudominio.rhcloud.com/_ah/admin (não se esqueça que se sua aplicação estiver empacotada como um .war em <app_dir>/deployments, você deve acrescentar o nome da aplicação) e após o login você terá acesso ao console administrativo de sua aplicação. Note que ela é semelhante ao console do GAE propositalmente para que não haja nenhuma dificuldade em utilizar o ambiente.
Console Administrativo da aplicação GAE no CapeDwarf
Muito legal, não? Pois bem, a má notícia é que o CapeDwarf ainda está em sua versão Beta1 (nos próximos dias a JBoss irá lançar o Beta2) e portanto algumas das funcionalidades dessa interface ainda não estão prontos, bem como alguns dos serviços que o GAE oferece ainda não foram implementados (são bem poucos, mas isso depende de quão dependente desses serviços estão com o GAE).
Fico por aqui e caso tenham dúvidas/sugestões/reclamações a respeito do CapeDwarf ou do Openshift, podem postar comentários que eu responderei com maior prazer. Ou se preferir, pode ir no fórum do CapeDwarf e perguntar diretamente aos desenvolvedores do projeto.

Curso online: Amazon Web Services For Newbies



Recebi ontem um tweet do José Papo (Amazon Web Services Evangelist - Latin America e meu ex-professor da graduação) indicando um curso gratuito sobre AWS para Newbies. Basicamente, o curso trata de explicar o conceito de algumas das ferramentas que compoem o AWS e qual a finalidade de cada uma delas para sua infraestrutura. Ao fim do curso o instrutor Anthony James (Twitter: @anthonydjames), dá uma prática de como utilizar as ferramentas e botar no ar aplicações na nuvem da amazon.

Bom, este post é curto apenas para divulgar aos interessados em conhecer soluções de IaaS (Infrastructure-as-a-Service, ou Infraestrutura-como-um-serviço) e como eles funcionam. Para quem quiser conhecer o curso, mas acessar a página da udemy.com e procurar por "Amazon Web Services for Dummies". Para os leitores pragmáticos (a.k.a. os preguiçosos, como eu), pode acessar o curso diretamente aqui.