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:

• Acesso a root
• Suite XCode completa ou git for OS X

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.

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.

Evento TI no Vale 2012

No último sábado (15/12), participei do evento "TI no Vale 2012" a pedido de meu amigo William Antônio (jesuíno), organizado por ele e mais alguns integrantes do JUG Vale, localizado na cidade de São José dos Campos. Fiquei honrado por novamente voltar a esta cidade que tanto admiro por ter um grupo de programadores fanáticos (assim como o William) e também por esta região ter institutos de pesquisa de peso (como o ITA e o INPE). A última vez que fui para lá foi para um evento do próprio JUG Vale.

Logo do evento

O eventou contou com quatro trilhas (no mesmo formato de eventos como o TDC (The Developers Conference): Games, Mente Aberta, Nuvem de Elétrons e Programação. O próprio site foi algo interessante (e também parte do assunto relevante a este blog), pois eles contruíram o site do evento utilizando Openshift como uma solução de PaaS e também de hospedagem. Para quem quiser conferir, o site é http://site-tinovale.rhcloud.com.
Eu participei da trilha Programação, onde apresentei a palestra "Sua aplicação nas nuvens com Openshift". O objetivo da palestra tratou de falar sobre como Cloud Computing tem impulsionado muitas startups a criarem suas idéias e lançarem ao mercado em tempo recorde com baixo custo e como grandes empresas puderam economizar com TI simplesmente diminuindo a ociosidade de seu parque de servidores. Por fim, apresentei quatro demos interessantes: Uma aplicação Magento (um framework de e-commerce escrito em PHP) rodando na nuvem, uma (simples) aplicação em Python com Django, demonstrei uma breve instrodução ao projeto Capedwarf, que permite a migração de aplicações Google App Engine para ambientes JavaEE/JBoss e Openshift sem mexer em uma linha de código(farei um post sobre isso nas próximas semanas), e um exemplo prático de como migrar e por fim demonstrei como é possível criar um ambiente DevOps com Openshift e Jenkins (claro que só isso não é o suficiente, mas é um bom ponto de partida para isso).
Minha intenção com as demos foi simplesmente mostrar que Startups hoje viraram moda, mas nem sempre sinônimo de startup é rentabilidade a curto prazo. Porém é possível encurtar essa trilha se sua solução/idéia precisa de uma hospedagem à Internet e que também permita criar um ambiente de Middleware à sua escolha, sem ter que te travar por conta de suportar apenas uma ou outra tecnologia. Além disso, é possível também usar soluções já prontas no mercado (como o Magento ou sua própria aplicação em GAE) sem ter que reinventar a roda ou reescrever código. Espero que o pessoal do evento tenha gostado, pois eu gostei e sempre gosto muito de apresentar por lá.
Gostaria de novamente agradecer ao William e ao pessoal do JUG Vale que sempre me recebem muito bem quando eu vou aos eventos e também ao Professor Renzo da FATEC e Diretor de Tecnologia da QMagico (uma espécie de Khan Academy brazuca) por compartilhar seus conhecimentos e experiências com o Google App Engine. Segue abaixo meus slides apresentados no evento, e como ainda não recebi as fotos do evento ficarei devendo nesse momento. Assim que tiver as fotos eu posto aqui.

Primeiros passos com Openshift

Introdução

Esse é o primeiro de muitos posts que venho organizando sobre Cloud Computing. Ultimamente tenho me interessado bastante no assunto e por isso venho estudando a fundo sobre assuntos que giram em torno dessa nova buzzword.

Vamos ao que interessa: nesse post explicarei como criar sua primeira aplicação utilizando um serviço PaaS (Platform-as-a-Service, explicarei melhor esse e outros termos em outro post) da Red Hat chamado OpenShift. O OpenShift é um serviço relativamente novo porém traz diversas funcionalidades que fazem dele um serviço PaaS bem mais amplo. Para criar a nossa primeira aplicação, é necessário instalar os seguintes componentes:

• Eclipse Indigo
• JBoss Tools 3.3.1
• Opcionalmente pode ser utilizado o JBoss Developer Studio 5.0, que já possui uma configuração pronta com Eclipse + JBoss Tools

Criando uma conta no OpenShift

Antes de criar nossa aplicação, precisamos criar uma conta no OpenShift no site http://openshift.redhat.com.   Esse é um dos pontos de acesso para criar, gerenciar e monitorar suas aplicações e tecnologias hospedadas no OpenShift através da interface de gerenciamento. Abaixo a página inicial do OpenShift:

Página inicial do OpenShift

Na página inicial, clique em "Sign up - It's free" (e de fato é... =D ) e preencha os dados conforme a tela abaixo:

Feito isso, você receberá um e-mail de confirmação de sua inscrição e pronto! Agora podemos criar aplicações no ambiente OpenShift.

Criando um domain

criando um domain

Abrirá um diálogo para digitar o nome do seu domain. Após escolher um nome para seu domain, clique em Finish:

Criando a aplicação

Finalmente, vamos criar a aplicação clicando com o botão direito na sua conta Openshift e selecionar "New OpenShift Application...":

Abrirá uma tela para criar sua aplicação. Eu vou tentar explicar por cima o que cada seção desse wizard faz. Como podem perceber, você pode usar:

• Use Existing Application: Caso você já tenha uma aplicação pronta, você pode já apontar para o locla onde está esse projeto
• New application: É onde utilizaremos. Nesse caso, você terá que colocar informações adicionais para configurar sua aplicação, tais como:
• Name: O nome que ficará sua aplicação. Ao acessar sua aplicação, ela terá o formato http://aplicacao-dominio.rhcloud.com
• Type: O tipo da aplicação que você irá desenvolver. É aqui onde você indica se vai criar uma aplicação Java, PHP, Ruby, etc. Tentarei postar como desenvolver aplicações que não sejam apenas Java
• Gear Profile: É o tamanho da sua medida de recursos. Um gear no OpenShift é uma unidade computacional de storage e memória, onde há uma limitação desses recursos para assim poder utilizar apenas o necessário. Imaginem uma aplicação que ocupa apenas 500MB e que consome 300MB de RAM, com um gear small você pode consumir exatamente o que precisa sem comprometer os recursos disponíveis para as outras aplicações utilizarem.
• Embeddable Cartridges: Um Cartridge no OpenShift é como blocos de software que você vai adicionando na infraestrutura da sua aplicação. Exemplo: Toda aplicação precisa de um Banco de Dados, então você adiciona um cartridge para isso (no momento, os gears de Banco disponíveis no OpenShift são MySQL, PostgreSQL e MongoDB). Além disso, há outros cartridges que podem auxiliar no desenvolvimento e administração de sua aplicação, como o phpMyAdmin, cron, etc.

Agora que preenchemos as informações para a aplicação e clicar em Next, surge uma tela para definir se precisa criar um projeto para sua aplicação ou se vai utilizar um já existente e também para criar uma configuração de servidor para o OpenShift, assim como criamos uma configuração de servidor JBoss para iniciar/parar o servidor e fazer o deploy de aplicações nele.

Por fim, aparece uma tela para definir o local onde o git fará um clone do repositório remoto para sua máquina. IMPORTANTE: você precisa definir as chaves SSH para poder fazer esse clone. Você pode clocar em "SSH2 Preferences" e seguir os passos para configurar essas chaves

Por fim, sua aplicação será criada e depois que o Eclipse finalizar basta acessar a URL e já terá uma página inicial:

Bom pessoal, essa é só a ponta do iceberg para iniciar. Nos próximos posts, irei aprofundar um pouco mais sobre conceitos teóricos e práticos, e se tiverem alguma sugestão é só mandar um comentário.