Introdução
No laboratório anterior, preparamos nossa cozinha (instalamos o Terraform). Agora, é hora de escrever o cardápio.
No Terraform, normalmente você não descreve manualmente cada etapa de baixo nível. Em vez disso, você descreve os objetos de infraestrutura desejados. Cada objeto gerenciado é representado por um recurso.
Os recursos são as principais unidades gerenciadas pelo Terraform. Eles fazem a ligação entre o código dos seus arquivos .tf e os objetos reais na plataforma de destino.
Pense nisso como fazer um pedido em um restaurante. Você não diz ao chef: “pique uma cebola, refogue-a, bata dois ovos...”; você apenas diz: “Quero uma omelete”. O Terraform é o garçom que recebe seu pedido (a configuração) e garante que a cozinha (o Docker) prepare exatamente o que você solicitou.
Este é o fluxo de trabalho essencial do Terraform: definir recursos, visualizar as alterações propostas e depois aplicá-las.
Defina a imagem
Começamos declarando quais ingredientes precisamos. No mundo do Docker, antes de executar um contêiner, você precisa de uma imagem (como um pacote congelado do software).
Primeiro, entre na pasta do projeto e crie nossa folha de pedido, o arquivo main.tf.
cd ~/project
touch main.tf
Abra main.tf usando o editor de texto nano.
nano main.tf
Sempre começamos informando ao Terraform quem fará o trabalho (o Provider). Copie e cole este bloco padrão no início do arquivo para configurar o provider do Docker:
terraform {
required_providers {
docker = {
source = "kreuzwerker/docker"
version = "~> 3.0.1"
}
}
}
provider "docker" {}
Agora, adicionamos nosso primeiro pedido: a imagem do Nginx. Acrescente este código ao arquivo main.tf, abaixo do bloco do provider (use as teclas de seta para descer):
resource "docker_image" "nginx" {
name = "nginx:latest"
keep_locally = false
}
Depois de colar o código, salve o arquivo. Pressione Ctrl + O, pressione Enter para confirmar e depois pressione Ctrl + X para sair do editor.
Vamos entender essa linguagem:
resource: esta palavra informa ao Terraform: “Quero pedir algo”."docker_image": este é o tipo do item que estamos pedindo. Se estivéssemos integrando com a AWS, poderia seraws_instance."nginx": este é o nome que damos a esse item no nosso caderno para podermos referenciá-lo mais tarde. Ele não altera nada no mundo real.name = "nginx:latest": este é o parâmetro específico enviado ao Docker. Ele informa exatamente qual imagem o Docker deve baixar.
Agora, seu projeto contém um provider e uma instrução de recurso.
Defina o contêiner
Uma imagem fica armazenada no disco, mas um contêiner é a aplicação em execução. É como a diferença entre uma receita e a refeição pronta no prato.
Agora, adicionaremos um segundo recurso ao arquivo main.tf. Esse novo recurso depende do primeiro.
Abra main.tf novamente usando o nano:
nano main.tf
Use as teclas de seta para ir até o final do arquivo e cole este bloco no fim:
resource "docker_container" "web" {
image = docker_image.nginx.image_id
name = "tutorial"
ports {
internal = 80
external = 8000
}
}
Observe o mecanismo na linha image = docker_image.nginx.image_id.
Essa referência é mais do que uma conveniência. Ela permite que o Terraform crie um grafo de dependências e determine automaticamente a ordem de criação.
Em vez de digitar nginx:latest novamente, apontamos para o recurso que definimos anteriormente (docker_image.nginx). Isso informa ao Terraform: “Não tente criar este contêiner até terminar de preparar a imagem”. É assim que criamos dependências.
Também adicionamos um bloco ports. Ele cria uma passagem do seu computador (porta 8000) para dentro do contêiner (porta 80), permitindo que você veja o site.
Inicialize e crie o plano
Antes de permitir que o Terraform faça alterações, precisamos inicializar o projeto (baixar as ferramentas) e depois visualizar o plano.
Primeiro, execute init para instalar os plugins do provider do Docker:
terraform init
Agora, imagine se o garçom trouxesse sua comida imediatamente, sem confirmar o pedido. Isso seria arriscado! O Terraform tem um recurso de segurança chamado Plan. Ele analisa o que você solicitou, verifica o que já existe e calcula a diferença.
Execute o comando de plano:
terraform plan
Observe atentamente a saída. Você verá sinais + verdes ao lado dos recursos. Esses símbolos significam: “Eu criarei isto”.
A fase de plano é um dos recursos de segurança mais valiosos do Terraform. Ela permite inspecionar as alterações propostas antes que qualquer coisa real seja modificada.
Dica importante: sempre leia o plano. Esta é sua última oportunidade de detectar erros antes que eles se tornem parte da infraestrutura real.
Aplique as alterações
O plano pareceu correto. Agora é hora de dizer ao garçom: “Pode fazer!”
O comando apply executa o plano.
terraform apply
O Terraform é muito cuidadoso. Ele exibirá o plano mais uma vez e solicitará uma confirmação final. Você deve digitar yes para prosseguir.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
Depois que você digitar yes e pressionar Enter, o Terraform entrará em contato com o Docker, baixará a imagem e iniciará o contêiner.
Vamos verificar se funcionou! Podemos usar comandos padrão do Docker para conferir se o contêiner está em execução:
docker ps
Você também pode testar o site que acabou de implantar. Como mapeamos a porta 8000, podemos acessá-lo usando curl:
curl localhost:8000
Se você vir o código HTML de “Welcome to nginx!”, implantou com sucesso sua primeira infraestrutura usando código!
Resumo
Parabéns! Você concluiu o fluxo de trabalho essencial do Terraform.
Neste laboratório, você aprendeu:
- Definição de recursos: como especificar o que você deseja (imagens e contêineres) em
main.tf. - Referências: como conectar recursos entre si, por exemplo, informando ao contêiner qual imagem deve usar.
- Plan: como visualizar a “conta” antes de confirmar.
- Apply: como criar a infraestrutura real.
Este ciclo de Write -> Plan -> Apply é exatamente como profissionais gerenciam grandes infraestruturas de nuvem. Você acabou de dar seu primeiro passo para se tornar um engenheiro de DevOps.
