Ansible vs Terraform 2026: Infrastructure as Code e Domande per Colloqui DevOps

Ansible vs Terraform rappresenta una delle domande di confronto più frequenti nei colloqui DevOps, ma la formulazione stessa rivela un fraintendimento: questi strumenti risolvono problemi differenti. Ansible 2.20 gestisce il configuration management e il deployment delle applicazioni, mentre Terraform 1.15 effettua il provisioning delle risorse infrastrutturali. Comprendere quando ciascuno eccelle, dove si sovrappongono e come si completano a vicenda distingue i Senior DevOps Engineer da chi sta ancora imparando i fondamentali.

Dichiarativo vs Procedurale: La Differenza Fondamentale

Terraform utilizza un approccio dichiarativo. Un file di configurazione descrive lo stato finale desiderato, e Terraform calcola le modifiche necessarie per raggiungerlo. Questo funziona bene per l'infrastruttura che deve essere creata, modificata o distrutta come unità.

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

L'esecuzione di terraform apply crea entrambe le risorse se non esistono, oppure le aggiorna per corrispondere alla configurazione. Eseguirlo nuovamente senza modifiche non produce operazioni: Terraform confronta la configurazione con il suo file di state e non trova nulla da fare.

Ansible utilizza un approccio procedurale con task eseguiti in ordine. Mentre i moduli Ansible sono spesso idempotenti (eseguirli due volte produce lo stesso risultato), il playbook stesso descrive una sequenza di azioni piuttosto che uno stato finale.

# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Ogni task viene eseguito in sequenza. Il pattern notify/handler fornisce un comportamento parzialmente dichiarativo: l'handler viene eseguito solo una volta alla fine, indipendentemente da quanti task lo attivano.

Gestione dello State: Un Argomento Critico per i Colloqui

Terraform mantiene un file di state che mappa la configurazione alle risorse reali. Questo state traccia gli ID delle risorse, le dipendenze e i metadati. Senza di esso, Terraform non può determinare cosa esiste o cosa deve essere modificato.

Ansible non ha un file di state equivalente. Si connette ai sistemi target ed esegue i task, affidandosi allo stato corrente del sistema e all'idempotenza dei moduli. Questo rende Ansible più semplice per iniziare ma più difficile per tracciare i cambiamenti nel tempo.

Una domanda frequente nei colloqui riguarda la sicurezza del file di state. Lo state di Terraform può contenere dati sensibili: password di database, chiavi API, identificatori di risorse. I deployment in produzione memorizzano lo state remotamente (S3, Azure Blob, Terraform Cloud) con crittografia e controlli di accesso.

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

La tabella DynamoDB fornisce il locking, impedendo a due sviluppatori di modificare lo state simultaneamente.

Quando Utilizzare Ciascuno Strumento

Terraform eccelle nel provisioning dell'infrastruttura cloud: macchine virtuali, database gestiti, load balancer, ruoli IAM, VPC. Gestisce automaticamente le dipendenze tra le risorse e supporta tutti i principali provider cloud attraverso una sintassi HCL coerente.

Ansible eccelle nella configurazione di sistemi esistenti: installazione di pacchetti, gestione degli utenti, deployment del codice applicativo, orchestrazione di deployment multi-step. Si connette via SSH (o WinRM per Windows) senza richiedere agent sui sistemi target.

La zona di sovrapposizione crea confusione. Entrambi possono installare software su una VM. Terraform può usare i provisioner per eseguire script dopo la creazione delle risorse. Ansible può creare risorse cloud attraverso moduli come amazon.aws.ec2_instance. Ma utilizzare ogni strumento al di fuori dei suoi punti di forza porta a problemi di manutenibilità.

Il Workflow Combinato in Produzione

La maggior parte delle organizzazioni utilizza entrambi gli strumenti insieme. Terraform effettua il provisioning dell'infrastruttura ed emette i dettagli di connessione. Ansible consuma questi output per configurare i sistemi.

# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}

Una pipeline CI/CD esegue prima Terraform, cattura gli output, genera dinamicamente un inventory Ansible, poi esegue i playbook contro la nuova infrastruttura.

# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"

Questo inventory dinamico interroga AWS direttamente, raggruppando le istanze per i loro tag. Nessuna gestione manuale degli IP richiesta.

OpenTofu: Il Fork che ha Cambiato il Panorama

HashiCorp ha rilicenziato Terraform sotto la Business Source License (BSL) nell'agosto 2023. La community ha risposto creando un fork di Terraform 1.5 in OpenTofu, ora ospitato sotto la Linux Foundation.

Ad agosto 2026, OpenTofu 1.11.6 rimane un sostituto drop-in per la maggior parte dei workflow Terraform. Stessa sintassi HCL, stesso ecosistema di provider, stesso formato di state. OpenTofu ha aggiunto funzionalità non presenti nel binario open-source di Terraform: crittografia dello state, provider for_each e valutazione anticipata delle variabili.

Per la preparazione ai colloqui, è importante comprendere la distinzione delle licenze. La BSL permette l'uso interno ma limita la costruzione di prodotti concorrenti. Le organizzazioni preoccupate per il vendor lock-in o con requisiti di compliance specifici potrebbero preferire la licenza MPL 2.0 di OpenTofu. L'acquisizione di HashiCorp da parte di IBM nel dicembre 2024 ha aggiunto un'altra variabile alle discussioni sulle relazioni con i vendor.

Domande Comuni nei Colloqui DevOps

Domanda: Ansible può sostituire Terraform?

Non efficacemente. Ansible può creare risorse cloud, ma manca la gestione dello state. Eseguire lo stesso playbook due volte potrebbe creare risorse duplicate. Il file di state di Terraform traccia cosa esiste e calcola le modifiche minime. Utilizzare Ansible per ciò che fa meglio: il configuration management.

Domanda: Come si gestiscono i secret in Terraform?

Mai committare secret nel version control. Utilizzare variabili d'ambiente, integrazione con Vault o secret manager dei cloud provider. Marcare le variabili come sensitive per impedire che appaiano nei log:

# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}

Domanda: Cos'è l'idempotenza in Ansible?

Un'operazione idempotente produce lo stesso risultato sia che venga eseguita una volta o più volte. Il modulo apt con state: present installa un pacchetto se mancante e non fa nulla se già installato. Scrivere playbook idempotenti previene modifiche indesiderate nelle esecuzioni successive.

Domanda: Come si testa il codice Infrastructure?

Terraform: terraform validate verifica la sintassi, terraform plan mostra le modifiche in anteprima, e strumenti come Terratest eseguono test di integrazione. Ansible: ansible-lint rileva problemi, la modalità --check esegue dry run, e Molecule testa i role contro container.

Per una preparazione più approfondita sui colloqui Terraform, consultare Terraform Interview Questions: Infrastructure as Code Complete Guide. Esercitazioni pratiche con i moduli Terraform Basics e Ansible Configuration Management.

Compatibilità delle Versioni ed Ecosistema

Versioni stabili attuali ad agosto 2026:

L'architettura delle collection di Ansible separa le funzionalità core dai moduli specifici per provider. La collection amazon.aws riceve aggiornamenti indipendentemente dal core di Ansible. Questo è rilevante per il version pinning nelle pipeline CI/CD.

Il versioning dei provider di Terraform segue principi simili. I file di lock (terraform.lock.hcl) assicurano versioni dei provider coerenti tra i membri del team e i sistemi CI.

# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

Scegliere tra i Due: Un Framework Decisionale

La domanda raramente è Ansible o Terraform. La domanda è quale strumento gestisce quale responsabilità.

Per un quadro completo di come questi strumenti si inseriscono nei moderni workflow di deployment, consultare CI/CD Pipeline Interview Questions.

Cosa Dovrebbero Sapere i Senior Engineer su Ansible e Terraform

• Terraform gestisce lo state dell'infrastruttura in modo dichiarativo; Ansible configura i sistemi in modo procedurale. Utilizzarli insieme produce infrastruttura manutenibile.
• La sicurezza del file di state è importante. Memorizzare lo state di Terraform remotamente con crittografia e locking abilitati.
• OpenTofu fornisce un'alternativa con licenza MPL a Terraform con funzionalità aggiuntive. La migrazione è semplice per la maggior parte dei workflow.
• L'idempotenza non è automatica. Scrivere playbook che producono risultati coerenti nelle esecuzioni ripetute.
• L'inventory dinamico elimina la gestione manuale degli host. Interrogare direttamente i cloud provider per l'infrastruttura attuale.
• Il version pinning previene sorprese. Bloccare le versioni dei provider in Terraform; pinnare le versioni delle collection in Ansible.
• Testare il codice Infrastructure richiede approcci diversi: terraform plan per l'anteprima delle modifiche, modalità --check per i dry run di Ansible, framework di test di integrazione per entrambi.