Infrastructure as Code: Terraform, Ansible

Infrastructure as Code: Terraform, Ansible

1) Por que IaC e o que as ferramentas são diferentes

Terraform - orchestrator-IaC declaratório: cria/altera a infraestrutura na nuvem (VPC, K8s, LB, BD, IAM) através de provedores. Gerencia o ciclo de vida dos recursos e armazena o estado.
O Ansable é um config-IaC de procedimentos e gerenciamento de configuração: configura hosts/software (pacotes, arquivos, serviços), fornece recursos para aplicações, templação, orquestração de passos. Sem agente (SSH/WinRM), com idimpotência de tarefas.

Combinação: Terraform - «O que é feito a plataforma», e Ansable - «Como é configurado e executado».

2) Estrutura de repositórios e camadas

1. Foundation (Landing Zona): redes, IAM, KMS, revistas básicas/monitoramento.

2. Plataforma: clusters Kubernetes, bases, filas, observabilidade-pilha.

3. Workloads: espaços/neimspace, contas de serviço, políticas, configs.

• 'iac/terraform/' - módulos e ambientes (' modales/', 'envs/').
• 'iac/ansibe/' - papéis (' roles/'), playbooks ('playbooks/'), inventários/').
• 'policies/' - OPA/Conftest regras.
• 'pipelines/' - XI/CD de script (lint/place/apply/teste).

3) Terraform: plug-ins, state, ambiente

3. 1 Módulos

Pequenos, reutilizados: «vpc», «eks», «rds», «redis», «alb», «iam-role».
Entradas → 'variáveis. tf ', saídas →' outputs. tf ', versões - através do registro de módulos/git-tags.

hcl module "vpc" {
source = "git::ssh://git@repo/iac. git//modules/vpc? ref=v1. 6. 0"
name  = "prod-core"
cidr  = "10. 0. 0. 0/16"
azs  = ["eu-central-1a","eu-central-1b"]
}

3. 2 Estado (state)

Backend remoto (S3/GCS + DynamoDB/LockTable) + bloqueio.
Divisão de ambientes: 'prod. tfstate`, `staging. tfstate`.
State-drivt: 'terraform place' em CI agendado; alert à deriva.

hcl terraform {
backend "s3" {
bucket     = "iac-state"
key      = "prod/network/terraform. tfstate"
region     = "eu-central-1"
dynamodb_table = "iac-locks"
encrypt    = true
}
}

3. 3 Workspaces / Envs

• Diretórios individuais 'envs/prod',' envs/estágio '(visível).
• Workspaces para variações leves, mas evite misturar segredos.
• Parâmetros através de '08vars': 'prod. tfvars`, `stage. tfvars`.

4) Ansível: papéis, inventários, idempotação

4. 1 Papéis e playbooks

roles/
nginx/
tasks/main. yml templates/.j2 handlers/main. yml defaults/main. yml playbooks/
site. yml

yaml
- hosts: web become: true roles:
- role: nginx vars:
nginx_listen_port: 8080

4. 2 Inventários e dinâmicas

`inventories/prod/hosts. yml '+ variáveis' group _ vars/hosts _ vars '.
Inventário dinâmico: 'aws _ ec2', 'gcp _ compute', 'kubernetes. core`.

4. 3 Idempotidade

Use os módulos (não 'shell') sempre que possível.
'changed _ when '/' check _ modes' para testes secos.
Os Handlers só refletem quando mudam.

5) Segredos e configs

Terraform: secreção de valores através de 'sensival = true'; os próprios segredos não estão no state (armazene em AWS Secret Manager/HashiCorp Vault/KMS e faça referência à fonte data).
Ansível: Vault para criptografia de variáveis ('anxile-vault encrypt'), integração com HashiCorp Vault/KMS.
GitOps: segredos em um armazém/repo separado, acesso por least-privege.

6) Políticas e conformidade (Policy as Código)

OPA/Conftest para planos de Terraform: proibição de recursos públicos S3 abertos SG (tags).
Terraform Cloud/Enterprise - Sentinel como alternativa.
Ansable Lint: estilo e segurança (sem 'sodo: yes' onde não é necessário, sem raw-shell).

rego package terraform. security

deny[msg] {
input. resource_type == "aws_security_group_rule"
input. values. cidr_blocks[_] == "0. 0. 0. 0/0"
input. values. from_port == 22 msg:= "SSH from 0. 0. 0. 0/0 is forbidden"
}

7) Testes de IaC

Terraform: 'se', 'se '/' checkov', Terratest (Go) para verificações de integração.
Ansable: 'anxile-lint', Molecule (+ Docker/Podman/EC2) para verificar papéis.
Testes pós-apply: HTTP probes, porta/processo, permissões.

8) CI/CD и GitOps

1. Lint/Sec: tflint, tfsec/checkov, ansible-lint.

2. Plano: 'terraform place' com a publicação do artefato (comentário em MR).

3. Policy Gate: Conftest/Sentinel.

4. Apply (manual/approved): apenas no principal com assinatura de artefatos.

5. Ansable deploy: '-check' em um estágio, seguido por '-diff' em prod.

6. Post-checks: sintética/probe, anotação de lançamento dashboard.

• Guarde os manifestos como fonte da verdade; Argo CD/Flux para Kubernetes, mas clusters/primitivos básicos - através do Terraform.

9) Patternes para Kubernetes, redes, BD

9. 1 Kubernetes

Terraform: EKS/GKE/ACS clusters, nódulos, IAM, StorageClass, LB.
Ansable: preparação de AMI/bastiões, montagem de imagens/repositório, pós-install (loggers/agentes/OTel).

9. 2 Redes e perímetro

Terraform: VPC/Subeti/NAT/Transit-Gateway/WAF, rotas.
Ansable: config NGINX/Envoy/HAProxy, TLS, configs WAF regras.

9. 3 Bases/cachês/filas

Terraform: RDS/CloudSQL parâmetro-grupo, Redis/ElastiCache, Kafka/MSK.
Ansable: Aquecimento do cachê, tarefas de migração, configuração de bacapes/agentes.

10) Exemplos de configs

10. 1 Terraform — RDS PostgreSQL + SG

hcl module "db" {
source        = "terraform-aws-modules/rds/aws"
engine        = "postgres"
engine_version    = "15. 4"
instance_class    = "db. m6g. large"
allocated_storage  = 100 name         = "core"
username       = var. db_user password       = var. db_password # см. secret data source vpc_security_group_ids = [module. db_sg. security_group_id]
multi_az       = true backup_retention   = 7
}

module "db_sg" {
source = "terraform-aws-modules/security-group/aws"
name  = "db-core"
vpc_id = module. vpc. vpc_id ingress_cidr_blocks = ["10. 0. 0. 0/8"]
ingress_rules    = ["postgresql-tcp"]
}

10. 2 Terraform - Fonte de segredo de dados

hcl data "aws_secretsmanager_secret_version" "db" {
secret_id = "prod/db/core"
}
variable "db_password" {
type   = string sensitive = true default  = jsondecode(data. aws_secretsmanager_secret_version. db. secret_string). password
}

10. 3 Ansable - papel postgresql-cliente (fatia)

yaml
- name: Install packages apt:
name: [ "postgresql-client-15" ]
state: present update_cache: yes

- name: Create. pgpass copy:
dest: /home/deploy/.pgpass mode: '0600'
content: "{{ db_host }}:5432:core:{{ db_user }}:{{ db_password }}"
no_log: true

- name: Smoke query shell: psql -h {{ db_host }} -U {{ db_user }} -d core -c "select 1"
register: psql_out changed_when: false

10. 4 Ansível - NGINX com templite

yaml
- name: Deploy nginx. conf template:
src: templates/nginx. conf. j2 dest: /etc/nginx/nginx. conf notify: Restart nginx

- name: Ensure nginx running service:
name: nginx state: started enabled: true

handlers:
- name: Restart nginx service: { name: nginx, state: restarted }

11) Controle da deriva e da conformidade

Regularmente 'terraform place' em uma chave read-only; cria um tíquete em caso de discrepância.
Anxile -check programado para papéis críticos (modo de auditoria).
Relatórios: políticas OPA/Conftest não cumpridas, recursos sem marcas de formatação/backup/monitoramento.

12) Observação e auditoria

Logs 'terraform apply' e artefatos de planos - guarde no armazenamento de objetos.
Ansable: 'callback _ plugins' (json) → loga central/ELK; inclua job ID, commit SHA, trace _ id.
Métricas: tempo de execução de planos/playbooks, taxa de alteração, cobertura de testes.

13) Segurança

A assinatura de módulos/papéis ou marcas de formatação fixas/hashy.
Direito IAM mínimo ('plano' ≠ 'apply'), divida o papel CI e o homem-aparador.
Criptografia de estado/logs, registros privados de módulos/papéis.
Política «no plaintext secret in VCS», scanners de segredo (gitleaks/trufflehog).

14) Anti-pattern

Um módulo monstro Terraform «para tudo»; nenhuma versão dos módulos.
Local 'terraform. Pois não há bloqueios.
Correções manuais na nuvem acima da deriva eterna.
Ansable 'shell '/' command' em vez dos módulos (quebra a idempotidade).
Inventário «em um único arquivo» sem grupos/variáveis, mistura prod/estágio.
Segredos em vars/repositórios, sem Vault/KMS.
Apply sem Plano e sem Peer Review.

15) Folha de cheque de implementação (0-45 dias)

0-10 dias

Configure o backend remoto/lock, descomponha os módulos do Terraform.
Ativar o 08lint/tcsec/checkov, ansível-lint; negociar as marcas/editoras de recursos.
Criar papéis Ansível para NGINX/agentes/logers; Organizar os inventários.

11 a 25 dias

Adicionar Conftest/OPA, Terratest e Molecule para módulos/papéis críticos.
CI: 'plan' em MR, artefacto de plano, manual-apply; Ansible `--check` на stage.
Integrar armazenamento em segredo (Vault/KMS/Secret Management).

26-45 dias

Plano automático programado para detecção drive, relatórios de políticas.
Catálogo de pods/papéis versionizados; documentação 'README. md em cada um.
GitOps: anotações de lançamentos, ligação com monitoramento e alert-gates.

16) Métricas de maturidade

% dos ambientes com estado e looks remotos = 100%.
O percentual de módulos/papéis com testes (Terratest/Molecule) ≥ de 70%.
Tempo médio de MR a apply (prod) - horas, não dias.
«Deriva manual» zero (todas as alterações são feitas através do MR).
100% dos recursos críticos estão cobertos pelo Policy as Code (tags, criptografia, backup).

17) Conclusão

A Terraform define uma base de infraestrutura previsível e repetível; O Ansable leva os hosts e serviços ao estado necessário. Adicione Policy as Code, estado remoto com localização, testes, gestão de segredo e CI/CD com plan→review→apply - e seu circuito de IaC será controlado, seguro e rápido e seus lançamentos são atômicos e reversíveis.