Lucas Teixeira

Você pode controlar praticamente toda sua infraestrutura AWS através dos consoles web da Amazon, mas uma outra saída bem interessante, é configurar as APIs de acesso da amazon em sua máquina e acessar tudo diretamente da linha de comendo.

Cada serviço que possui uma API, possui um pacote para baixar, este post mostra como configurar e utilizar a API Tools do EC2, que são as instâncias da amazon. O primeiro passo é gerar e baixar as chaves de acesso de sua conta. Conto que a partir deste momento, você já tem um cadastro no AWS da Amazon (http://aws.amazon.com) e já se cadastrou no EC2 (http://aws.amazon.com/ec2).

Enfim, basta acessar esta URL (página de credenciais no seu perfil): https://aws-portal.amazon.com/gp/aws/developer/account/index.html?ie=UTF8&action=access-key, acessar a aba do meio, X.509 Certificates e criar um novo certificado. Isto irá baixar para seu computador dois arquivos, um que é sua chave privada (private key), e o outro que é de fato o certificado X.509 para se conectar no ambiente AWS.

ATENÇÃO: Estes arquivos não podem ser baixados novamente, caso você os perca, terá que criar um outro certificado e baixar novamente, portante, guarde-os com carinho.

Após ter os arquivos de credenciais, baixe o pacote da api do endereço: http://aws.amazon.com/developertools/351 e descompactá-lo em algum diretório. Eu particularmente sempre opto por um diretório “aws” na pasta do meu usuário, e ali dentro uma pasta “ec2″. Ou seja, as pastas baixadas (lib e bin) para mim ficam dentro da seguinte pasta:

/Users/lucastex/aws/

Dentro desta mesma pasta aws eu mantenho um diretório keys e nele guardo aquelas duas chaves que baixamos no primeiro passo.

O último passo, é definir algumas variáveis de ambiente para que o toolkit possa funcionar sem problemas. Precisamos definir o JAVA_HOME apontando para a instalação do java na máquina, e algumas variáveis que apontam para os certificados do AWS, além de é claro, redefinir o PATH para que os binários do AWS possam ser encontrados. Fiz isso no meu .bash_profile no meu Mac, mas se alguem usa linux ou windows, basta definir variáveis de sistema com estes nomes e respectivos valores:

export AWS_HOME=~/aws
export EC2_HOME=$AWS_HOME/ec2
export KEYS_HOME=$AWS_HOME/keys
export EC2_PRIVATE_KEY=`ls $KEYS_HOME/pk-*.pem`
export EC2_CERT=`ls $KEYS_HOME/cert-*.pem`
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
export PATH=$PATH:$EC2_HOME/bin

Pronto, basta garantir que estas instruções estão válidas para a sessão corrente. Na dúvida, encerre e reinicie a sessão do terminal.

Suas credenciais já estão configuradas! Você pode fazer um teste simples com o comando abaixo:

ec2-run-instances –region us-east-1 –instance-type t1.micro ami-4a0df923

Com este comando aí em cima, você está dizendo para que o AWS suba uma nova instância do tipo t1.micro na região de disponibilidade us-east-1 com a AMI ami-4a0df923.

AMI: São as máquinas já pré-montadas disponíveis para você utilizar, existem milhares na internet disponíveis, cada uma com seu código. Você pode usar uma AMI limpa do ubuntu como também pode utilizar uma das muitas que já vem com o ambiente inteiro instalado. Existem AMIs para desenvolvimento Ruby on Rails, desenvolvimento Java, AMIs com toda a stack AMP, e etc. Visite http://aws.amazon.com/amis para mais detalhes.

Rápido e simples! Em poucos segundos você já tem uma instância rodando. Acesse o console EC2 (https://console.aws.amazon.com/ec2/home) para ver o status da instância! Com o tempo vou colocando outras dicas, para acessar a maquina por SSH, configurar firewall e acesso externo além de outras coisas.

Faz um tempo já que estou mexendo com os serviços da Amazon AWS. Fiquei muito contente com os resultados dos meus testes, eles hoje já comportam uma infraestrutura completa por lá, que acaba por suprir toda a minha necessidade de infra. Nos próximos projetos aqui da nova empresa, estaremos investindo pesado nisso, e confiando nossa infraestrutura por lá.

Pra quem ainda não viu nada disso, vou colocar aqui alguns dos serviços que iremos utilizar deles, e o que exatamente são eles.

• EC2: Elastic Compute Cloud – São as instâncias de máquinas virtualizadas, propriamente ditos, os “servidores” que iremos utilizar.
• EBS: Elastic Block Storage – Um EBS é attachado (conectado) a uma instância EC2 como um HD que é conectado em sua máquina, é um disco de fato, onde sua instância dá o boot.
• S3: Simple Storage Service – É um mecanismo de armazenamento de arquivos “nas nuvens”. Um storage que independe de máquina ou servidor. É como se fosse daqueles antigos discos virtuais, mas com uma confiabilidade e durabilidade muito maior, além de controle de ACL (segurança) para cada object (arquivo) ou bucket (pasta) lá dentro.
• CloudFront: O CloudFront se posiciona junto com o S3, servindo como uma forma de cache para estes arquivos. Ele possui nós espalhados pelo mundo todo, e é ideal para servir arquivos estáticos como CSS, JS, e imagens de maneira rápida, muito rápida.
• ELB: Elastic Load Balancer – Utilizado para balancear a carga entre suas instâncias na requisição a sua aplicação. Com isso você escala sua aplicação muito facilmente, por exemplo: Quando você tem uma carga de acesso muito grande, basta subir novas instâncias (novas máquinas) no seu parque de máquinas, e disponibilizá-las jutno a este ELB. É possível duplicar ou triplicar a capacidade de sua infraestrutura apenas com alguns cliques, copiando servidores e aumentando a capacidade de seu parque.
• RDS: Relational Database Service – Trocando em miúdos, é um “mysql elástico”. Ele está na infra da propria Amazon, e consegue se dimensionar dependendo de sua necessidade, são vários tipos (small, large, extra, etc) de instâncias de banco de dados que você pode contratar dele. Para quem desenvolve, e para a aplicação, nada muda, o mesmo driver JDBC do banco, e apenas uma URL JDBC diferenciada.
• CloudWatch: Um servico de monitoramento que você pode usar para acompanhar a saúde de suas instâncias EC2, dos discos EBS e até do seu banco RDS. Métricas como IO, memória, CPU, etc estão disponíveis e você pode setar alarmes para elas.
• Route 53: Um servico de DNS, foi o último a ser testado, era uma grande reclamação do pessoal, pois ainda dependiam de um DNS externo, agora já não precisam, podem usar o próprio DNS da Amazon.

Todos os serviços tem uma característica que eu acho muito legal, que é o tal do pay-as-you-go, ou seja, você paga o que utilizar e quanto utilizar. No caso das máquinas (instâncias), paga por quantas horas elas estiverem sendo utilizadas. No caso de um disco EBS, paga por quantos GB estiver alocando, no caso do DNS Route 53, paga por queries em cima do serviço. Ou seja, nada de custos exorbitantes quando não se tem um retorno (acesso) exorbitante. Seu orçamento acompanha o real uso desta infraestrutura.

É muito legal entender como estes serviços funcionam, e mais que isso, como podem trabalhar juntos. Principalmente quando se fala em autoscaling desta arquitetura. É possível definir métricas para o CloudWatch (monitoramento), para que caso sua infraestrutura esteja chegando no limite, ele automaticamente aumente esta infra subindo novas máquinas por exemplo.  Também é possível o contrário, ou seja, baixar máquinas que não estejam sendo necessárias no determinado momento para uma economia de dinheiro.

Cloud Computing tem virado um super buzz ultimamente, tem que ser visto e analisado com cuidado, mas não podemos deixar passar em branco. E com certeza, a Amazon lidera este segmento desde o seu lançamento.

Até mais,