Terraform vs. Ansible: Quale Strumento Ti Serve Davvero?

Chi è nuovo all'Infrastructure as Code di solito pone la domanda in uno di questi due modi: "quale strumento dovrei imparare per primo" oppure "perché i team usano entrambi." La risposta breve è che Terraform e Ansible risolvono problemi diversi, e la maggior parte dei setup in produzione li usa insieme piuttosto che sceglierne uno.

A cosa serve davvero Terraform

Terraform è uno strumento di provisioning. Dichiara quale infrastruttura dovrebbe esistere: una VPC, tre istanze EC2, un database RDS, un bucket S3 con una policy specifica. Scrivi in HCL descrivendo lo stato finale, esegui terraform plan per vedere cosa cambierà, poi terraform apply per realizzarlo. Terraform mantiene un file di stato (localmente o in un backend come un bucket S3 con locking DynamoDB) che mappa la tua configurazione agli ID delle risorse reali nel cloud provider.

Il punto di forza qui è la risoluzione delle dipendenze tra i provider. Se dici a Terraform di creare un security group e poi allegarlo a un'istanza EC2, lui figura automaticamente l'ordine. Funziona anche su AWS, Azure, GCP, Cloudflare, Datadog e dozzine di altri provider attraverso lo stesso workflow, il che conta una volta che la tua infrastruttura si estende a più di un vendor.

Terraform è scarso in tutto ciò che accade dentro la macchina una volta che esiste. Non installa pacchetti, non modifica file di configurazione, non riavvia servizi in nessun modo significativo e continuativo. Provisioner come remote-exec esistono ma lo stesso HashiCorp consiglia di evitarli per qualsiasi cosa al di là del bootstrapping.

A cosa serve davvero Ansible

Ansible è uno strumento di configuration management. Si connette via SSH (o WinRM per Windows) ed esegue task su macchine che già esistono: installa nginx, genera un file di configurazione, crea un utente, riavvia un servizio, assicura che un cron job sia presente. I playbook sono YAML, e i moduli sono idempotenti per design, perciò eseguire lo stesso playbook due volte non dovrebbe cambiare nulla la seconda volta se il sistema già corrisponde allo stato desiderato.

Ansible non ha bisogno di agenti installati sugli host target, solo Python e accesso SSH, il che rende facile applicarlo all'infrastruttura esistente. È anche bravo nei task di orchestrazione che non sono strettamente "provisioning" — riavvii progressivi su una flotta, step di deploy blue-green, esecuzione di una migrazione di database su un host e poi aggiornamento di un load balancer.

Dove si sovrappongono e dove la gente si confonde

Entrambi gli strumenti possono tecnicamente fare un po' del lavoro dell'altro. Ansible ha moduli cloud (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) che possono avviare infrastruttura. Terraform ha provisioner che possono eseguire comandi shell su una nuova istanza. Ma usare Ansible per il provisioning significa rinunciare al tracking dello stato di Terraform e al workflow plan/diff, e usare i provisioner di Terraform per la configurazione significa rinunciare al configuration management idempotente e ripetibile.

La divisione pratica su cui la maggior parte dei team si assesta:

• Terraform costruisce l'infrastruttura: reti, istanze di compute, load balancer, database gestiti, ruoli IAM.
• Ansible configura ciò che c'è sopra: installazioni di software, utenti, file di configurazione, stato dei servizi, step di deployment dell'applicazione.

Un esempio concreto dell'handoff

Diciamo che stai preparando tre web server dietro a un load balancer su AWS.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform crea le istanze e output i loro IP. Puoi alimentare quell'output in un inventario Ansible dinamico (il plugin inventario amazon.aws.aws_ec2 legge i tag EC2 direttamente, nessun copy-paste manuale necessario) e poi eseguire:

ansible-playbook -i aws_ec2.yml site.yml

dove site.yml installa nginx, inserisce la configurazione dell'app, e avvia il servizio. Terraform non tocca mai nginx. Ansible non tocca mai la VPC. Ciascuno strumento rimane nella sua corsia, e ciascuno ha il suo proprio modello di stato/idempotenza che non entra in conflitto con l'altro.

Errori comuni da evitare

Memorizzare lo stato di Terraform in git è l'errore iniziale più comune — i file di stato possono contenere segreti in plaintext e causare conflitti di merge che corrompono il tuo modello di infrastruttura. Usa un remote backend sin dal primo giorno.

Con Ansible, l'errore è scrivere playbook che non sono effettivamente idempotenti — usare moduli shell o command per cose che hanno un modulo appropriato (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) che già gestisce correttamente la logica check-then-act.

Se stai decidendo cosa imparare per primo: impara Terraform se stai facendo cloud provisioning e setup multi-environment, impara Ansible se stai gestendo config drift su server che hai già. La maggior parte dei ruoli DevOps si aspetta familiarità con entrambi nel primo anno.

Per saperne di più su state management, inventari dinamici, e costruire una pipeline CI/CD completa intorno a questi strumenti, dai un'occhiata ai segmenti DevOps e Cloud correlati su Korra Studio.