Como a documentação oficial do Ubuntu está um desatualizada resolvi montar um pequeno guia contendo alguns conceitos básicos do AWS e também aquilo que é necessário para a configuração e uso do Amazon EC2 a partir da linha de comando utilizando o AWS CLI.
Falando AWSês
Dentro do ecossistema do Amazon Web Services (AWS) os serviços disponíveis disponíveis utilizam “nomes fantasia”, maquinas virtuais são executadas dentro do Elastic Compute Cloud, ou simplesmente EC2, e são tratadas pelo nome de instâncias.
As instâncias são criadas a partir de Amazon Machine Images, ou simplesmente imagens, que consistem de máquinas virtuais pré-configuradas em uma arquitetura, sistema operacional e, se for o caso, aplicações — algo conceitualmente bem parecido com o que acontece nas boxes do Vagrant e contêineres no Docker.
É possível utilizar imagens disponibilizadas gratuitamente na Community AMIs, comprá-las no AWS Marketplace ou então criar as suas próprias — o Packer pode ser usado para esta finalidade.
API do Amazon Web Services
Dentro da interface de administração web do AWS , no EC2 Management Console, é possível criar executar, parar e apagar instâncias, configurar regras de firewall, roteamento etc. É possível também utilizar um painel de administração desenvolvido por terceiros¹ ou mesmo ferramentas de linha de comando para realizar estas mesmas operações.
Em ambos os casos todos estarão conversando com o AWS usando uma mesma linguagem, a API do AWS, e para acessá-la é necessário estar devidamente autorizado.
Então, a partir da interface de administração web, vá em «seu nome aqui»→”Security Credentials”, selecione a opção “Access Keys (Access Key ID and Secret Access Key)” e em seguida clique em “Create New Access Key”.
E acredite na mensagem, realmente será a (primeira e) única oportunidade de você saber o conteúdo da secret access key! Não é possível recuperá-la e o jeito será criar outra, portanto, baixe o arquivo com a chave — ele se chama “rootkey.csv” — e guarde-o em lugar seguro.
Instalando o AWS CLI
A documentação do Ubuntu faz referência ao Amazon EC2 API tools (ec2-api-tools) que foi substituída pelo Universal Command Line Environment for AWS (awscli) e que gerencia o Amazon EC2 e também os demais serviços do AWS.
E exceto por um pequeno “detalhe” sua instalação é relativamente simples:
# sudo apt-get install awscli groff Reading package lists... Done Building dependency tree ...
A princípio ele ou alguma dependência dele não “informa” ao APT que o groff precisa ser instalado. E para facilitar um pouco a vida e os dedos e o teclado use:
$ complete -C '$( which aws_completer )' aws
Para habilitar o auto complete dos comandos do AWS CLI dentro do Bash — isto pode ser colocado em “~/.bashrc” para ficar permanente. E sendo escrito em Python ele também pode ser instalado via pip e aí tanto em máquinas rodando Linux, *BSD ou MacOS X — Mas consulte a documentação para maiores detalhes.
(¹) Existem diversos gerenciadores a disposição (livres, gratuitos ou pagos) e até mesmo híbridos, isto é, não específicos do ecossistema AWS.
Configurando
Com o pacote instalado e as chaves de acesso devidamente criadas, abra um terminal e digite:
$ aws configure AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXXXX AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Default region name [None]: sa-east-1 Default output format [None]: text
Os valores destes dois sujeitos, AWS Access Key ID e AWS Secret Access Key, estão dentro do arquivo baixado no passo anterior, como região² padrão indiquei a infraestrutura da América do Sul e como formato de saída dos comandos indiquei texto — o padrão é JSON.
Usando uma analogia bem simplificada, pense que as chaves de acesso funcionam como um ‘login’ e ‘senha’ para autenticar na API do AWS e fazer o que eu quiser lá dentro. Entendeu agora o motivo da “paranoia” com relação à Access Key? — ainda na analogia do ‘login’ dentro do AWS há também a figura de usuários com poderes mais limitados. 🙂
(²) Em “AWSês (muito) simplificado” uma região corresponde a um dos data centers que estão ao redor do mundo.
Testando 1,2,3,4,5
Um teste bem simples para verificar se está tudo devidamente configurado e funcionando:
$ aws ec2 describe-images --owners amazon | tail --lines=5
O comando retornará as últimas cinco imagens disponíveis dentro da região selecionada, algo mais ou menos assim:
Obtendo algo parecido já é possível seguir adiante, em caso contrário verifique se as chaves foram corretamente digitadas — pode-se executar novamente o aws configure para corrigir ou mesmo editar o arquivo “~/.aws/credentials”.
Chaves de segurança
O EC2 mantém pares de chaves distintas por região logo, se você pretende acessar as instâncias via SSH é bom bom ter alguma disponível:
$ aws ec2 create-key-pair --key-name sa-east-1_teste xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY---- sa-east-1_teste
A parte pública da chave será automaticamente armazenada no AWS enquanto que a parte privada será exibida na tela. Salve o bloco (a coisa entre”BEGIN” e “END”) em um arquivo (algo como “sa-east-1_teste.pem”³), proteja-o devidamente da vista de curiosos com chmod 400 e guarde-o em um lugar seguro mas de fácil acesso para você.
(³) Se preferir use um nome mais curto e fácil de digitar do que “sa-east-1_teste.pem” 🙂
Criando uma nova instância
Lembra que será usada uma imagem pré existente? A partir do localizador de AMI do Ubuntu eu procurei e escolhi a ami-a1bf2ecd por dois motivos: (1) é imagem do Ubuntu 16.04 LTS 64-bit disponível na região sa-east-1 e (2) está disponível para ser utilizada por usuários do plano gratuito do AWS! 🙂
Também é preciso escolher o tipo da instância. Isto funciona como um “tamanho”para a a configuração da máquina virtual. Ela significa basicamente o poder computacional a ser alocado definindo o número de processadores, quantidade de memória RAM etc.
O mais importante, ao menos para pessoal da Amazon, o tipo define o valor a ser cobrado pela execução da instância, o custo em CPU/hora apresentado na fatura de serviços.Como é apenas um teste escolhi algo pequeno e dentro do orçamento, o t2.micro.
Em “AWSês” fluente, para instanciar uma imagem basta executar:
$ aws ec2 run-instances --image-id ami-a1bf2ecd --instance-type t2.micro \ --key sa-east-1_teste 999999999999 r-XXXXXXXX INSTANCES 0 x86_64 False xen ami-a1bf2ecd i-YYYYYYYY t2.micro sa-east-1_teste ... STATE 0 pending STATEREASON pending pending
Omiti grande parte das mensagens de retorno e deixei a mais importante delas grafada, o “i-YYYYYYYY” é justamente a identificação da instância que acabou de ser criada dentro do EC2.
Grupos de segurança
A instância que acabou de ser criada encontra-se dentro de uma rede virtual (VPC ou Virtual Private Cloud em “AWSês”) que é o seu lote particular dentro da nuvem e para disponibilizar ao “mundo exterior” serviços como FTP, HTTP, SSH etc é necessária sua autorização.
Isto é feito dentro de grupos de segurança e não individualmente por instância e como sei que a “i-YYYYYYYY”está no grupo “default” (visto que não defini nada diferente quando a criei), autorizo o acesso externo via SSH a ela (e todas as instâncias deste) grupo com:
$ aws ec2 authorize-security-group-ingress --group-name "default" \ --protocol tcp --port 22 --cidr 0.0.0.0/0
Pela mesma lógica outras formas de acesso são autorizadas/revogadas. E precisando de mais complexidade basta criar outros grupos de segurança — tipo “rede interna”, “servidores web” etc — e posicionar corretamente as instâncias dentro deles.
Acesso via SSH
Como eu sei qual o nome do meu host? Com o subcomando describe-instances é possível descobrir (é normal a informação aparece duplicada):
$ aws ec2 describe-instances --instance-id i-YYYYYYYY | grep ASSOC ASSOCIATION amazon ec2-«...».compute.amazonaws.com 99.99.99.99 ASSOCIATION amazon ec2-«...».compute.amazonaws.com 99.99.99.99
Para acessar instância faça:
$ ssh -i sa-east-1_teste.pem ec2-«...».compute.amazonaws.com Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-34-generic x86_64 ... ubuntu@ip-99-99-99-99:~$ _
E partir deste ponto é um host comum e corrente… 🙂
Outros comandos
Para revogar o acesso via SSH ao grupo de segurança “default”:
$ aws ec2 revoke-security-group-ingress --group-name "default" \ --protocol tcp --port 22 --cidr 0.0.0.0/0
Para desligar uma instância em execução:
$ aws ec2 stop-instances --instance-ids i-YYYYYYYY
Para iniciar uma instância parada:
$ aws ec2 start-instances --instance-ids i-YYYYYYYY
Para EXCLUIR uma instância:
$ aws ec2 terminate-instances --instance-ids i-YYYYYYYY
Claro, bastante cuidado com este sujeito pois diferente do que acontece na interface web ele não pedirá confirmação alguma da ação.
Finalizando…
Apesar de um tanto corrido, foi possível listar os passos necessários para criar, ligar, desligar, liberar/remover acesso e, claro, excluir uma máquina virtual instância dentro do EC2 e em caso de dúvida basta consultar a documentação que é bastante completa.
E boa diversão brincando de time sharing, digo, nuvem! 🙂
giovannireisnunes 
Pingback: JSON em shell script | giovannireisnunes
Boa noite, estou tentando rodar um comando aws dentro de um script shell /bin/bash para sincronizar arquivos da minha maquina com um banker amazon, dentro do script da erro “aws comando não encontrado” se eu rodar o comando no terminal ele funciona. Tu teria alguma sugestão?
CurtirCurtir
A princípio me parece que o local onde está o “aws” não está definido no PATH da shell em que o script está rodando. Verifique isto colocando o caminho completo do programa “/usr/bin/aws”,”/usr/local/bin/aws” etc. Na dúvida use “which aws” para descobrir a localização (aliás, você pode executar este comandando no começo do script para se certificar que o sistema não sabe onde o “aws” está).
CurtirCurtido por 1 pessoa