Infrastructure as Code: Terraform, Ansible

Infrastructure as Code: Terraform, Ansible

1) Perché e cosa sono diversi gli strumenti

Terraform è una orchestrator-IaC dichiarativa: crea/modifica un'infrastruttura cloud (VPC, K8s, LB, database, IAM) tramite i provider. Gestisce il ciclo di vita delle risorse e memorizza lo stato.
Ansible è un sistema di gestione della procedura e della configurazione: configura host/software (pacchetti, file, servizi), gestisce le applicazioni, il templating, l'orchestrazione dei passaggi. Senza agente (SSH/WinRM), con idoneità alle attività.

Combinazione: Terraform - «Di cosa è fatta la piattaforma», Ansibile - «Come viene configurata e avviata».

2) Struttura dei repository e dei livelli

1. Fondazione (Landing Zone): reti, IAM, KMS, registri di base/monitoraggio.

2. Platform: cluster Kubernets, basi, code, osservabilità-stack.

3. Workloads: spazi/neimspace, account di assistenza, policy, confighi.

• «iac/terraform/» - moduli e ambienti (« modules/», «invs/»).
• «iac/ansibile/» - ruoli (« roles/»), playbook («playbooks/»), inventari (« inventorie/»).
• «policies/» - OPA/Conftest regole.
• «pipelines/» - CI/CD script (lint/plan/apply/test).

3) Terraform: moduli, state, ambienti

3. 1 Moduli

Piccole, riutilizzabili: «vpc», «eks», «rds», «redis», «alb», «iam-role».
Entrate «variabili». tf ", uscite" outputs ". tf ', versioni tramite registro moduli/git-tag.

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 Stato (state)

Backend remoto (S3/GCS + DynamoDB/LockTable) + blocco.
Suddivisione per ambienti: 'prod. tfstate`, `staging. tfstate`.
State-drivt: «terraform plan» in CHI pianificato; alert alla 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

• Singole cartelle «invs/prod», «invs/stage» (visibile).
• Workspace per variazioni facili, ma evitare di mescolare segreti.
• Impostazioni tramite "tfvars": "prod. tfvars`, `stage. tfvars`.

4) Ansibile: ruoli, inventari, idemotia

4. 1 Ruoli e playbook

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 Inventari e altoparlanti

`inventories/prod/hosts. yml '+ variabili' group _ vars/host _ vars '.
Inventario dinamico: 'aws _ ec2', 'gcp _ compute', 'kubernets'. core`.

4. 3 Idampotenza

Utilizzare i moduli (non «shell») dove possibile.
«changed _ when »/« check _ mode» per i test secchi.
Gli Handlers riflettono solo quando cambiano.

5) Segreti e configi

Terraform: secrezione dei valori tramite «sensitive = true»; I segreti stessi non sono nello state (memorizzare i segreti AWS da Vault/KMS e fare riferimento all'origine data).
Ansibile: Vault per la crittografia delle variabili ('ansile-vault encrypt'), integrazione con il HashiCorp Vault/KMS.
GitOps: segreti in un archivio/repo separato, accesso least-privilege.

6) Criteri e conformità (Policy as Code)

OPA/Conftest per Piani di Terraform - Disabilita le risorse pubbliche S3 aperte da SG (tags).
Terraform Cloud/Enterprise - Sentinel come alternativa.
Ansible Lint - Stile e sicurezza (senza «sudo: yes» dove non è necessario, senza 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) Test di IaC

Terraform: «tflint», «tfsec »/« checkov», Terratest (Go) per i controlli di integrazione.
Ansibile: 'ansile-lint', Molecule (+ Docker/Podman/EC2) per la verifica dei ruoli.
Test di smoak dopo apply: HTTP probes, porta/processo, diritti.

8) CI/CD и GitOps

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

2. Piano: 'terraform plan'con la pubblicazione dell'artefatto (commento in MR).

3. Policy Gate: Conftest/Sentinel.

4. Apply (manual/approved) - Solo sul main con firma degli artefatti.

5. Ansibile deploy: '--check', poi '--diff'in prod.

6. Post-checks: Sintetica/Probe, nota di rilascio.

• Conservare i manifesti come fonte di verità; Argo CD/Flux per Kubernets, ma cluster/primitivi di base tramite Terraform.

9) Pattern per Kubernets, reti, database

9. 1 Kubernetes

Terraform: EKS/GKE/AKS cluster, nodi, IAM, StorageClass, LB.
Ansible: preparazione di AMI/bastioni, assemblaggio di immagini/repository, post-install (logger/agenti/OTEL).

9. 2 Reti e perimetro

Terraform: VPC/subnet/NAT/Transit-Gateway/WAF, percorsi.
Ansibile: config NGINX/Avvoy/HAProxy, TLS, configi WAF regole.

9. 3 Basi/cache/code

Terraform: RDS/CloudSQL-gruppo, Redis/ElastiCache, Kafka/MSK.
Ansibile: riscaldamento della cache, processi di migrazione, configurazione di backup/agenti.

10) Esempi di configure

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 - Origine del segreto data

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 Ansibile - ruolo postgresql-client (porzione)

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 Ansibile - NGINX con template

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) Controllo della deriva e della corrispondenza

Periodico'terraform plan'nella chiave read-only; crea un ticket durante una soluzione temporanea.
Ansible --check pianificato per i ruoli critici (modalità audited).
Report: regole OPA/Conftest non soddisfatte, risorse senza tag/backup/monitoraggio.

12) Osservazione e verifica

Logi'terraform apply'e gli artefatti del piano - Salva nel magazzino degli oggetti.
Ansibile: 'callback _ plugins' (json) Loga centrale/ELK; attivare job ID, commit SHA, trace _ id.
Metriche: tempi di esecuzione dei piani/playbook, frequenza delle modifiche, copertura dei test.

13) Sicurezza

Firma moduli/ruoli o tag/hash fissi.
Diritti IAM minimi ('plan' ≠' apply '), separare i ruoli CI e umano-applower.
Crittografia di stato/login, registri privati di moduli/ruoli.
Il criterio «no plaintext secret in VCS», il segreto-scanner (gitleaks/trofflehog).

14) Anti-pattern

Un singolo modulo mostro di Terraform per tutto; nessuna versione dei moduli.
Locale'terraform. tfstate'e nessun blocco.
Le modifiche manuali nella nuvola, sopra la IaC, → una deriva eterna.
Ansibile'shell '/' command ', invece dei moduli (rompe l'idampotenza).
Inventario in un unico file senza gruppi/variabili, miscelazione prod/stage.
Segreti in vars/repository, nessun Vault/KMS.
Apply senza Piano e senza Peer Review.

15) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Configura backend/lock remoto, disattiva Terraform.
Abilita tflint/tfsec/checkov, ansile-lint; negoziare tag/etichette di risorse.
Avvia ruoli ansibili per NGINX/agenti/loger; Organizzare l'inventario.

11-25 giorni

Aggiungi Conftest/OPA, Terratest e Molecule per i moduli/ruoli critici.
CI: «piano» su MR, artefatto del piano, manual-apply; Ansible `--check` на stage.
Integra il segreto-storage (Vault/KMS/Secret Manager).

26-45 giorni

Piano automatico pianificato per i dettagli draft, report delle regole.
Catalogo dei moduli/ruoli con versioning Documentazione "README. md'in ognuno.
GitOps: annotazioni di rilascio, collegamento con monitoraggio e alert-gate.

16) Metriche di maturità

% degli ambienti con stato remoto e loop = 100%.
La percentuale di moduli/ruoli con test è pari al 70%.
Tempo medio da MR a apply (prod) - ore, non giorni.
«Deriva manuale» zero (tutti i cambiamenti vengono effettuati tramite MR).
Il 100% delle risorse critiche sono coperte da Policy as Code (tag, crittografia, backup).

17) Conclusione

Terraform specifica una base di infrastruttura prevedibile e ripetibile Ansable porta host e servizi allo stato richiesto. Aggiungi Policy as Code, lo state remoto con la posizione, i test, il segreto-management e il CA/CD con il - e il tuo tracciato diventa controllato, sicuro e veloce, e le release sono atomiche e reversibili.