Terraform Infrastructure Code na prática: o código e os comandos que realmente importam
Terraform Infrastructure Code: o essencial em um artigo — código real, diagramas e etapas concretas, extraídos de um curso de 38 lições.
Sem teoria interminável aqui: abra o terminal e pratique. Aqui está o essencial de Terraform Infrastructure Code, extraído diretamente de um curso completo de 38 lições — com código real que você pode copiar e colar agora.
- Introdução ao Terraform e IaC
- Instalação e Primeiros Passos
- Linguagem HCL Providers Variáveis e Recursos
- Módulos e Organização do Código
- State Backend Remoto e Workspaces
Capítulo 08 – Lição 2 : Primeiro Projeto GCP — VPC, Firewall e Compute Engine
1. Pré-requisitos
Antes de começar, certifique-se de que todos os elementos abaixo estejam em vigor. Sem esses pré-requisitos, o terraform apply falhará com erros de autenticação ou API não ativada.
1.1 Contas e ferramentas
1.2 Credenciais GCP a recuperar
Você precisará dessas informações para configurar o provider Terraform e autenticar as chamadas de API :
| Elemento | Como obter | Exemplo |
|---|---|---|
| Project ID (string curto) | gcloud config get-value project | mon-projet-tf-prod |
| Project Number (12 dígitos) | gcloud projects describe PROJECT_ID --format="value(projectNumber)" | 123456789012 |
| Organization ID (opcional) | gcloud organizations list | 987654321000 |
| Billing Account ID | gcloud billing accounts list | 0X0X0X-0Y0Y0Y-0Z0Z0Z |
| Service Account email | Formato padrão da SA Terraform | tf-sa@PROJECT_ID.iam.gserviceaccount.com |
gcloud auth application-default login é suficiente.1.3 Configurar a autenticação gcloud + ADC
Uma única vez na sua máquina: autentique-se com sua conta Google, defina o projeto, crie uma Service Account dedicada ao Terraform e configure as Application Default Credentials (ADC) que o Terraform lê automaticamente.
# 1. Login do usuário (abre o navegador)
gcloud auth login
# 2. Selecionar o projeto
gcloud config set project mon-projet-tf-prod
# 3. Criar uma Service Account dedicada ao Terraform
gcloud iam service-accounts create tf-sa \
--display-name="Terraform Service Account"
# 4. Atribuir a função (Editor para os exercícios, mais restrita em prod)
gcloud projects add-iam-policy-binding mon-projet-tf-prod \
--member="serviceAccount:tf-sa@mon-projet-tf-prod.iam.gserviceaccount.com" \
--role="roles/editor"
# 5. ADC para dev local (método recomendado para Terraform)
gcloud auth application-default login
# 6. (Alternativa CI/CD) Criar uma chave JSON — sensível, proteja!
gcloud iam service-accounts keys create key.json \
--iam-account=tf-sa@mon-projet-tf-prod.iam.gserviceaccount.com
# export GOOGLE_APPLICATION_CREDENTIALS=$PWD/key.json
# 7. Verificar
gcloud auth list
gcloud config list project1.4 Ativar as APIs GCP necessárias
O GCP exige que você ative explicitamente cada serviço antes de poder usá-lo. Para esta lição, apenas o Compute Engine é estritamente necessário, mas vale ativar as APIs comuns de uma vez:
gcloud services enable \
compute.googleapis.com \
cloudresourcemanager.googleapis.com \
iam.googleapis.com \
iap.googleapis.com
# Verificar as APIs ativadas
gcloud services list --enabled1.5 Permissões IAM mínimas
Para este exercício, a Service Account do Terraform deve poder criar recursos do Compute Engine e ler o projeto. A função roles/editor (usada em 1.3) cobre amplamente a necessidade. Em produção, prefira funções direcionadas como roles/compute.admin + roles/iam.serviceAccountUser (least privilege).
1.6 Chave SSH para Compute Engine
Para conectar via SSH à VM (fora do IAP), o GCP suporta dois modos: OS Login (recomendado, autenticação via IAM — usado nesta lição) ou chaves SSH clássicas via metadados do projeto. Veja como gerar uma chave dedicada ao GCP:
# Gerar um par de chaves RSA 4096 bits dedicado ao GCP
ssh-keygen -t rsa -b 4096 -f ~/.ssh/gcp_vm -C "votre-user@gcp"
# Opção A : OS Login ativado na VM (usado nesta lição)
# → a chave pública é gerenciada por IAM, nada a enviar em metadados
# Opção B : Adicionar via metadados do projeto (chave SSH clássica)
gcloud compute project-info add-metadata \
--metadata-from-file ssh-keys=~/.ssh/gcp_vm.pub
# Restringir as permissões da chave privada (obrigatório)
chmod 400 ~/.ssh/gcp_vm2. Estrutura do Projeto
Aqui está a árvore de diretórios típica desta lição. O código está organizado em vários arquivos .tf de acordo com sua responsabilidade, mais um script Bash externo injetado na VM via metadata_startup_script.
# Estrutura recomendada para este projeto premier-projet-gcp/ ├── versions.tf # Configuração Terraform + provider google ├── variables.tf # Variáveis de entrada (project_id, region, zone, ...) ├── main.tf # VPC + subnet + firewall rules + VM Compute Engine ├── outputs.tf # IP pública, comando SSH IAP, URL HTTP ├── startup-script.sh # Script Bash executado no boot da VM (Nginx) ├── terraform.tfvars # Valores específicos (project_id, ...) — NÃO-COMMITADO └── .gitignore # Excluir .tfstate, .tfvars, .terraform/, key.json
2.1 Papel de cada arquivo
| Arquivo | Papel | Lido pelo Terraform? |
|---|---|---|
versions.tf | Bloco terraform { required_providers } + bloco provider "google" | Sim |
variables.tf | Variáveis de entrada com type, default, description | Sim |
main.tf | Todas as resource e data sources GCP | Sim |
outputs.tf | Outputs expostos após apply (IP, URL, comando SSH IAP) | Sim |
startup-script.sh | Script Bash injetado na VM via a função file() | Lido por file() |
terraform.tfvars | Valores concretos das variáveis (project_id = "...") | Auto-carregado |
.gitignore | Excluir *.tfstate, *.tfvars, .terraform/, key.json | Não (Git) |
2.2 Como o Terraform carrega os arquivos
Capítulo 08 – Lição 1 : GCP Fundamentos e Autenticação Terraform
gcloud, criar uma Service Account, ativar as APIs necessárias e configurar o provider google do Terraform.1. Hierarquia GCP vs AWS e Azure
| Nível | AWS | Azure | GCP |
|---|---|---|---|
| Top-level | Organization | Tenant | Organization |
| Contêiner intermediário | OU | Management Group | Folder |
| Conta de faturamento | Account | Subscription | Project (com Billing Account vinculada) |
| Região | Region | Location | Region (us-central1, europe-west1, northamerica-northeast1...) |
| Zona | AZ | Availability Zone | Zone (us-central1-a, -b, -c) |
| Identidade de serviço | IAM Role | Service Principal / MI | Service Account |
project explícito.2. Instalar gcloud CLI
Windows (PowerShell)
Download e execução do instalador oficial Google Cloud SDK para Windows. Uma vez iniciado, o instalador configura gcloud, gsutil e bq, e oferece inicializar a conexão com sua conta GCP.
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/dl/cloudsdk/channels/rapid/GoogleCloudSDKInstaller.exe", "$env:Temp\GoogleCloudSDKInstaller.exe")
& $env:Temp\GoogleCloudSDKInstaller.exemacOS
Instalação do gcloud via Homebrew (o gerenciador de pacotes macOS mais usado). O cask instala o SDK completo e o adiciona automaticamente ao PATH.
brew install --cask google-cloud-sdk
Linux (apt)
Procedimento oficial Debian/Ubuntu: adicionar o repositório APT Google, importar a chave GPG assinada e instalar google-cloud-cli. Este método permite receber atualizações automáticas via apt.
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" \
| sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg \
| sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
sudo apt update && sudo apt install -y google-cloud-cliValidação rápida da instalação: o comando exibe as versões do SDK, de bq (BigQuery) e gsutil (Storage). Uma saída vazia indica um problema de PATH a corrigir antes de continuar.
# Verificar gcloud --version # Google Cloud SDK 488.x.x # bq 2.x.x # gsutil 5.x.x
3. Criar e Configurar um Project GCP
Bootstrap completo de um projeto GCP em CLI:
# 1. Conexão (abre o navegador) gcloud auth login # 2. Criar um project (project_id deve ser globalmente único) PROJECT_ID="monprojet-tf-$(date +%s)" gcloud projects create $PROJECT_ID --name="Mon Projet Terraform" # 3. Vincular à billing account (obrigatório para a maioria dos recursos) BILLING_ID=$(gcloud billing accounts list --format="value(ACCOUNT_ID)" --limit=1) gcloud billing projects link $PROJECT_ID --billing-account=$BILLING_ID # 4. Definir o project ativo gcloud config set project $PROJECT_ID gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a # 5. Verificar gcloud config list # [compute] # region = us-central1 # zone = us-central1-a # [core] # project = monprojet-tf-1714234567
4. Ativar as APIs Necessárias
Ativação em lote das APIs GCP mais comuns necessárias para Compute, Storage, IAM, Cloud SQL, Cloud Run e Secret Manager. O segundo comando (gcloud services list --enabled) permite verificar o que já está ativado no projeto.
# Ativar as APIs comuns
gcloud services enable \
compute.googleapis.com `# Compute Engine` \
storage.googleapis.com `# Cloud Storage` \
cloudresourcemanager.googleapis.com `# Resource Manager` \
iam.googleapis.com `# IAM` \
iamcredentials.googleapis.com `# IAM Credentials (para SA tokens)` \
sqladmin.googleapis.com `# Cloud SQL Admin` \
run.googleapis.com `# Cloud Run` \
secretmanager.googleapis.com `# Secret Manager` \
--project=$PROJECT_ID
# Listar as APIs ativadas
gcloud services list --enabled --project=$PROJECT_IDCapítulo 03 – Lição 4 : Projeto Serverless — Lambda, API Gateway e VPC com Módulos
1. Pré-requisitos
Este projeto implanta 3 módulos Terraform que orquestram juntos uma VPC, uma função Lambda e um API Gateway. Antes de executar terraform apply, verifique se todos os elementos abaixo estão em vigor — caso contrário você obterá erros de IAM, timeouts de invocação Lambda ou erros 500 na API.
1.1 Contas e ferramentas
1.2 Credenciais AWS a recuperar
Você precisará dessas 3 informações do console AWS para autenticar o Terraform:
| Elemento | Onde encontrar | Exemplo |
|---|---|---|
| Account ID (12 dígitos) | Console AWS → no canto superior direito, clique no seu nome → Minha conta | 123456789012 |
| Access Key ID | IAM → Users → seu usuário → Security credentials → Create access key | AKIAIOSFODNN7EXAMPLE |
| Secret Access Key | Exibido UMA ÚNICA VEZ durante a criação (caso contrário recrie uma nova chave) | wJalrXUt...EXAMPLEKEY |
aws configure (armazenadas em ~/.aws/credentials) ou variáveis de ambiente. Adicione *.tfvars, *.tfstate*, .terraform/ e dist/ ao seu .gitignore.1.3 Configurar a autenticação AWS CLI
Uma única vez na sua máquina: execute aws configure e cole suas chaves. O arquivo ~/.aws/credentials é criado e o Terraform o lerá automaticamente (o provider AWS e o provider archive não precisam de nenhum token específico).
aws configure
# AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key [None]: wJalrXUt...EXAMPLEKEY
# Default region name [None]: ca-central-1
# Default output format [None]: json
# Verificar que funciona
aws sts get-caller-identity
# {
# "UserId": "AIDA...EXAMPLE",
# "Account": "123456789012", ← Seu Account ID
# "Arn": "arn:aws:iam::123456789012:user/votre-user"
# }1.4 Permissões IAM mínimas
O usuário (ou função) utilizado deve poder criar Lambda, API Gateway, IAM (funções de execução), VPC e CloudWatch Logs. Para este exercício, anexe as seguintes políticas gerenciadas ao usuário IAM:
| Política gerenciada AWS | Por quê |
|---|---|
AWSLambda_FullAccess | Criar/modificar a função Lambda e os aws_lambda_permission |
AmazonAPIGatewayAdministrator | Criar a REST API, os métodos, as integrações e o deployment |
IAMFullAccess | Criar a função de execução Lambda e anexar as políticas |
AmazonVPCFullAccess | Criar a VPC, as subnets e o Security Group do módulo vpc |
CloudWatchLogsFullAccess | Criar o aws_cloudwatch_log_group da Lambda |
PowerUserAccess + IAMFullAccess também é suficiente.1.5 Código-fonte Lambda
O módulo data "archive_file" (usado no main.tf raiz) compacta automaticamente seu código Python a cada plan. Você deve criar a pasta de origem antes do primeiro terraform plan, caso contrário o Terraform falhará com « source_dir does not exist » :
# Criar a estrutura esperada por data "archive_file" mkdir -p src/lambda touch src/lambda/index.py # O conteúdo será visto na seção 8 # Sem SSH/.pem necessário aqui — a Lambda é invocada via API Gateway, não por SSH
2. Estrutura do Projeto
Aqui está a árvore completa do projeto, pensada para modularidade. O main.tf raiz atua como maestro: ele instancia os 3 módulos e conecta seus outputs/inputs. Cada módulo em modules/ é autossuficiente (possui seus próprios variables.tf e outputs.tf) e pode ser reutilizado em outro projeto.
# Estrutura completa do projeto serverless
project-serverless/
├── providers.tf # Versões Terraform + provider AWS + archive
├── variables.tf # Variáveis globais (project_name, environment, region)
├── main.tf # Orquestração : chamadas module.vpc, module.lambda, module.api_gateway
├── outputs.tf # Outputs raiz (api_url, lambda_name, lambda_arn)
├── terraform.tfvars # Valores concretos (NÃO-COMMITIDO)
├── .gitignore # *.tfstate, *.tfvars, .terraform/, dist/
├── README.md
│
├── src/
│ └── lambda/
│ └── index.py # Código Python da Lambda
│
├── dist/ # ZIP gerado por data "archive_file" (NÃO-COMMITIDO)
│ └── lambda.zip
│
├── environments/ # Valores específicos por ambiente
│ ├── dev.tfvars
│ └── prod.tfvars
│
└── modules/
├── vpc/ # Módulo de rede reutilizável
│ ├── main.tf # aws_vpc, aws_subnet, aws_security_group
│ ├── variables.tf # prefix, cidr, environment
│ └── outputs.tf # vpc_id, private_subnets, lambda_sg_id
│
├── lambda/ # Módulo função Lambda + IAM
│ ├── main.tf # aws_lambda_function, aws_cloudwatch_log_group
│ ├── iam.tf # Função de execução + anexos de policy
│ ├── variables.tf # function_name, runtime, handler, vpc_id...
│ └── outputs.tf # function_name, function_arn, invoke_arn
│
└── api_gateway/ # Módulo API REST
├── main.tf # aws_api_gateway_rest_api, methods, deployment
├── variables.tf # api_name, lambda_arn, lambda_name
└── outputs.tf # api_id, api_url, stage2.1 Papel de cada arquivo
| Arquivo | Papel | Nível |
|---|---|---|
providers.tf | Versões do Terraform + providers (aws, archive) | Raiz |
variables.tf | Variáveis globais compartilhadas entre todos os módulos | Raiz |
main.tf (raiz) | Instancia os módulos e passa os outputs de um como inputs do outro | Raiz |
outputs.tf (raiz) | Reexpõe os outputs dos módulos no nível do projeto (ex. api_url) | Raiz |
modules/<m>/main.tf | Lógica de negócio do módulo (recursos AWS) | Módulo |
modules/<m>/variables.tf | Interface pública do módulo — o que um consumidor pode configurar | Módulo |
modules/<m>/outputs.tf | Valores expostos pelo módulo (consumíveis pela raiz ou outro módulo) | Módulo |
src/lambda/index.py | Código aplicativo Python — compactado automaticamente por data "archive_file" | App |
environments/*.tfvars | Valores concretos por ambiente (passados via -var-file) | Config |
2.2 Como o Terraform carrega os arquivos — não existe "ponto de entrada"
main.tf primeiro. Ele mescla automaticamente TODOS os arquivos .tf da pasta atual em um único conjunto. Os nomes main.tf, iam.tf, variables.tf são uma convenção, não uma obrigação técnica. No módulo lambda/, separar iam.tf de main.tf melhora a legibilidade — para o Terraform, é estritamente equivalente a um único arquivo grande.Este artigo cobre os trechos mais úteis — o curso completo Terraform Infrastructure Code (10 capítulos, 38 lições, exercícios corrigidos e projeto final) leva você até o fim.
./acceder-au-cours-complet curso gratuito : Dominando o Claude CodeFAQ
Quanto tempo para aprender Terraform Infrastructure Code?
É necessário ter pré-requisitos?
Por onde começar concretamente?
📬 Quer receber este tipo de guia toda semana? Inscreva-se gratuitamente — código real, zero enrolação.