Victor Ricardo

Há pouco mais de um mês estávamos criando nosso grupo de segurança para controlar o acesso às instâncias EC2. Pois bem, chegou a hora de testá-lo, atribuindo o mesmo de forma automática, via TERRAFORM. Vamos lá!

Primeiramente, retorne a aws console com seu respectivo usuário e senha tradicionais. Login feito, agora percorra o seguinte PATH:

PÁGINA INICIAL > PAINEL EC2 > REDE E SEGURANÇA > SECURITY GROUPS > SSH-ACCESS

Uma vez selecionado o grupo, copie e cole não o nome, mas sim o id do mesmo. Por exemplo:

sg-044c0695ddfa19d2b

Siga para o VScode e acrescente o parâmetro correspondente dentro do recurso “aws_instance”, passando como argumento o pŕoprio ID:

vpc_security_group_ids = [ "value" ]

Dessa forma, o que temos é:

Como boa prática, devemos sempre executar o plan antes do apply. Por que? Bem, ambientes de produção além de serem críticos, ou seja, essenciais e vitais para o negócio/empresa, eles são na grande maioria bastante “sensíveis”, digamos assim. Em termos práticos, uma alteração/deploy errada(o) em determinado recurso, e toda a infraestrutura vai por água abaixo. Máquinas que não se comunicam mais, usuários que perdem acesso, clientes insatisfeitos pela demora ao carregar o sistema, serão “apenas” alguns dos possíveis efeitos colaterais sentidos pela sua equipe interna. Então, já sabe, primeiro rode o comando terraform plan para visualizar as mudanças propostas, sem afetar diretamente a infra.

terraform plan

Bom, é exatamente aqui que chamo a atenção de todos para duas coisas. A primeira é o resumo do plano, que quando traduzido nos informa: “não há nenhuma adição, muito menos remoção, o que existe são três alterações a serem efetuadas”. Já a segunda, diz respeito ao elementos visuais presentes na tela e que são utilizados como maneira de destaque dos itens para o usuário. Vejam que o TERRAFORM sempre marca as ditas mudanças em amarelo, sendo precedidas pelo acento til (~) :

E quando nos debruçamos ainda mais sobre o código, veremos que o atributo vpc_security_group_ids tem em seu comportamento padrão a espera de uma única string. Em outras palavras, ele retira o grupo atual e acrescenta o novo especificado. Mas não é bem isso que queremos, pois a ideia continua sendo provisionar três máquinas diferentes para três desenvolvedores distintos, salvando a guarda de todas apresentarem um nível mínimo de comunicação entre si (icmp, ping, dns, etc). Portanto, devemos tratar tal referência/parâmetro/atributo como uma lista, na programação diversas vezes chamada de array ou vetor. Então, fica a reflexão: muito cuidado na hora escolher o que você pretende … (A/-) uma STRING que substitui o grupo vigente por outro ou (B/+) uma LISTA constando o atual e mais um, dois, três novos grupos? Pense bem!

No nosso caso, vamos de alternativa B: ssh + default

vpc_security_group_ids = [ "sg-044c0695ddfa19d2b","sg-064d06ebd73c18ed4" ]

Detalhe importante, posicione sempre uma vírgula ( , ) a cada novo ID informado:

Execute novamente o plan para checar se o TERRAFORM fará o determinado por você:

terraform plan

A-há! Agora sim, tudo pronto para entrar em PRODUÇÃO:

terraform apply

>_ TESTE FINAL #01 . . .

>_ TESTE FINAL #02 . . .

terraform show

terraform.tfstate

>_ TESTE FINAL #03 . . .

ssh -i "terraform-kali" [email protected]

Vlw! Flw! E até … Até mais! 🙂