TERRAFORM SERIES: Final … Working on AWS: (backend) Colaborando em Equipe
“Uma andorinha só não faz verão“ … Antigo ditado popular brasileiro. Mas, que tenta trazer consigo a mensagem do POST de hoje … Tanto no âmbito pessoal (família, amigos) quanto profissional (colegas, superiores, subordinados) ninguém, absolutamente ninguém (sim, isso inclui você e eu!!!), está sozinho ou totalmente independente. A palavra da moda talvez seja auto-suficiente. E é justamente sobre isso que iremos tratar. Ou deveria dizer “provisionar” ??? (hehehe) Bem, a escolha é sua 😀
Agora sim, falando sério. Quando estamos inseridos em um time de infraestrutura, ou desenvolvimento, ou ambos (no caso de empresas que já adotam o DevOps) é normal ter que compartilhar arquivos e pastas para construção de um determinado projeto. Entretanto, isso não quer dizer que duas pessoas deveriam estar editando o mesmo arquivo de configuração simultaneamente, por exemplo. E por que não Victor? Porque do contrário, o sistema hospedeiro não saberia qual é a porta correta para escutar requisições HTTP: seria a minha porta 80 ou a sua porta 8080? Difícil não? Pois é, meio complicado 🙁
Enfim, do jeito que está, simplesmente não dá. Dessa forma, ou trabalhamos sozinhos no projeto (1 – 1). Ou na melhor das hipóteses, toda vez que alguém pensar em fazer algo, deve gritar para todo mundo ouvir: Ei, vou abrir o arquivo X … Vou renomear a pasta Y … Atenção! Reiniciando o serviço Z, a conexão irá cair momentaneamente … AARGH 😐 Um verdadeiro pesadelo (Ou feira livre né?)
Sendo assim, proponho duas saídas, na esperança de melhorar esse cenário caótico. A) Você deverá implantar localmente algum tipo de versionamento, desde os mais simples, como Git ou SVN, até os mais complexos, como GitLab ou Bitbucket. B) Manter todo o estado da sua infra hospedado diretamente na nuvem da HashiCorp, chamada de Terraform Cloud
Nós vamos de opção “B”, então mãos-a-obra:
>_ Criando uma conta: SIGN UP
Totalmente gratuito, basta cadastrar um e-mail válido, nome de usuário e senha. Ao final, não esqueça de consentir os termos de uso e política de privacidade.
Siga para sua caixa de entrada e abra o email padrão (típico comportamento esperado nos dias atuais)
>_ Criando um workflow do zero: START FROM SCRATCH
Escolha a opção do meio, para simular uma nova infra e definir por conta própria alguns parâmetros. O primeiro deles informa o nome do grupo, chamado aqui de organização
Próxima tela, caímos nos espaços de trabalho (ou workspaces) Esses nada mais são do que as configurações da nossa infra, ou seja, aqueles mesmos arquivos que criamos anteriormente lá no VScode. E sim, nós vamos importá-los para cá (não reinvente a roda!!!) MAS, CONTUDO, PORÉM, TODAVIA, para que isso aconteça é preciso antes gerar um token de acesso. Dirija-se até seu avatar, clique em user settings, em seguida tokens, e por fim, create an API token Dê um nome, salve e copie o HASH
Próximo passo, criar o arquivo de referência ao token, localizado imediatamente abaixo da sua /HOME. Seguindo o doc, a recomendação é que seja nomeado como .terraformrc ou terraform.rc E formate o mesmo com esse conteúdo:
credentials "app.terraform.io" {
token = "Q1lxCm2AFUONng.atlasv1.y1Mg3F4OjzB3Iz4yUJ10DaNU4zu4UqtjuvM5bDqysiniNbYZUUMNOzniBzRVYtjVAsE"
}
Terceira etapa, instruir o TERRAFORM a olhar diretamente para a nuvem e não mais o local do projeto. Para isso, retorne ao VScode e crie um novo arquivo remote-state.tf Depois cole o seguinte
# Using a single workspace:
terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "vicrldacombr"
workspaces {
name = "aws-victor"
}
}
}
Quase terminado, agora necessitamos inicializar o diretório novamente, para que as alterações sejam vistas pelo TERRAFORM:
terraform init
Aparentemente tudo OK, mas nunca é demais validar as coisas … Volte para a nuvem e TA-DAAAA
>_ Alterando o estado e visualizando modificações: NEW DEPLOY
Modifique o estado atual da sua infra. Por exemplo, crie simplesmente um novo recurso. Qualquer um: no meu caso aqui, estou pegando um bucket S3. Aproveitando os exemplos anteriores, acompanhe:
resource "aws_s3_bucket" "NEW-deploy" {
bucket = "novo-item"
acl = "private"
tags = {
Name = "novo-item"
}
}
terraform plan&&terraform apply
Errata: O Terraform CLOUD ainda não possui aquelas mesmas credenciais que você definiu no AWS CLI. Sendo assim, para resgatar ambas você deve abrir o arquivo que fez download anteriormente (no início da série) Feito isso, agora vá para o site do Terraform Cloud e dentro do seu acesso clique na opção Settings, depois em Variables sets e logo após create variable set, escreva um nome pra variável (coloquei o nome do usuário), seleciona a opção Apply to all workspaces in this organization e depois add variable Seleciona a opção Environment variable e no campo “Key” digite AWS_ACCESS_KEY_ID e em “Value” digite o ID da chave, marque a opção Sensitive. Repita o mesmo processo de add variable agora no campo “Key” digite AWS_SECRET_ACCESS_KEY e em “Value” sua chave secreta. Adicionado as duas chaves, finaliza no botão Save variable set.
O resultado em tela será mais ou menos assim:
Agora rode novamente o comando terraform plan para verificar se está tudo certo:
terraform apply e pronto! só aguardar …
Observem que o recurso foi criado e de hoje em diante nós temos o tão sonhado versionamento na infra vigente:
CURTA, COMPARTILHE, COMENTE 😉
REFERÊNCIAS:
https://www.atlassian.com/git/tutorials/what-is-version-control
https://en.wikipedia.org/wiki/List_of_version-control_software
https://www.softwaretestinghelp.com/version-control-software/
https://app.terraform.io/session
https://www.terraform.io/cli/config/config-file
