Perché l’Infrastructure as Code nella cloud connectivity

Connettere un data center o una branch al cloud significa oggi orchestrare decine di oggetti: transit gateway, route table, security group, subnet, IP pubblici e soprattutto i router virtuali Cisco Catalyst 8000V (C8000V) che terminano i tunnel IPsec verso AWS, Azure o Google Cloud. Farlo a mano dalla console è lento, non ripetibile e produce configurazioni che divergono fra ambienti (dev, staging, prod).

L’Infrastructure as Code (IaC) risolve il problema descrivendo l’infrastruttura in file di testo dichiarativi, versionati in Git. Terraform è lo strumento di riferimento perché è cloud-agnostic: un unico linguaggio (HCL) e provider distinti (aws, azurerm, google) permettono di gestire più cloud dallo stesso workflow. Il vantaggio operativo per l’esame ENCC è chiaro: ripetibilità, versionamento e revisione tramite code review prima del deploy.

Il modello dichiarativo e l’idempotenza

Con Terraform non si scrive come creare le risorse, ma quale stato finale deve esistere. Il ciclo è sempre lo stesso:

Comando Funzione
terraform init Scarica provider e inizializza il backend
terraform plan Calcola il diff fra stato desiderato e stato reale
terraform apply Applica solo le differenze necessarie
terraform destroy Rimuove le risorse gestite

Il concetto chiave è l’idempotenza: rieseguire apply sulla stessa configurazione non ricrea nulla se l’infrastruttura è già allineata. Terraform confronta tre elementi — configurazione HCL, state file e realtà via API del cloud — e agisce solo sul delta. Questo rende sicuro applicare la pipeline più volte, ad esempio in CI/CD.

Provisionare la connettività: gateway, tunnel e C8000V

Un tipico stack di connettività ibrida descritto in Terraform comprende:

  • Istanza C8000V: dispiegata da immagine marketplace, con dimensionamento e licenza (throughput) parametrizzati.
  • Tunnel IPsec / IKEv2: definiti come risorse VPN gateway lato cloud, con pre-shared key e parametri crypto (DH group, encryption) esposti come variabili.
  • Route table: rotte statiche o propagate che instradano il traffico on-prem attraverso il tunnel o il transit gateway.
  • Networking di supporto: VPC/VNet, subnet, IP elastici/pubblici.

Le configurazioni IOS-XE del C8000V (interfacce Tunnel, crypto ikev2, BGP) si iniettano tramite cloud-init / day-0 bootstrap config passata come variabile Terraform, mantenendo il router coerente con l’infrastruttura circostante.

Parametrizzazione e riuso multi-cloud

La forza dell’IaC sta nel non ripetere codice. Si usano:

  • Variabili (variable) per PSK, CIDR, ASN BGP, throughput — mai valori hard-coded.
  • Moduli riutilizzabili: un modulo ipsec-tunnel o c8000v richiamato con input diversi per ogni sito o cloud.
  • Workspace o directory separate per isolare gli ambienti pur condividendo lo stesso codice.

Così una stessa definizione di tunnel si replica su AWS e Azure cambiando solo il provider e pochi parametri, garantendo topologie omogenee.

La gestione dello state: il cuore fragile

Lo state file (terraform.tfstate) è la mappa fra risorse HCL e oggetti reali (con i loro ID). Regole d’oro:

  • Backend remoto (S3, Azure Blob, GCS) invece del file locale, per condivisione e durabilità.
  • State locking (es. DynamoDB) per impedire apply concorrenti che corromperebbero lo state.
  • Lo state contiene dati sensibili (PSK dei tunnel in chiaro): va cifrato e con accessi ristretti.

Perdere o corrompere lo state significa che Terraform non riconosce più le risorse esistenti e potrebbe tentare di ricrearle.

Il drift: quando l’automazione diventa inaffidabile

Il configuration drift si verifica quando qualcuno modifica manualmente una risorsa dalla console cloud (aggiunge una rotta, cambia un parametro del tunnel). Lo state Terraform non ne è a conoscenza e diverge dalla realtà. Al successivo terraform plan Terraform vede la differenza e, per riportare tutto allo stato dichiarato, sovrascrive o distrugge la modifica manuale — potenzialmente abbattendo un tunnel in produzione.

terraform plan è lo strumento di drift detection: mostra sempre cosa cambierebbe prima di agire. Un’infrastruttura sana adotta il principio “Terraform è l’unica fonte di verità”: nessuna modifica manuale, tutto passa da codice e code review.

Trappole tipiche d’esame

  • Scenario: un tunnel IPsec funzionante viene modificato a mano in console; al successivo apply la pipeline lo altera → La risposta giusta: è drift; ogni cambiamento va fatto in HCL, non in console. Terraform riconcilia verso lo stato dichiarato.
  • Scenario: terraform apply eseguito due volte ricrea le risorse? → No: Terraform è idempotente, applica solo il delta calcolato da plan; nessuna ricreazione se già allineato.
  • Scenario: due ingegneri lanciano apply insieme e lo state si corrompe → La risposta giusta: manca lo state locking; usare backend remoto con lock.
  • Scenario: serve rilevare divergenze senza modificare nulla → La risposta giusta: eseguire terraform plan (drift detection), non apply.
  • Scenario: una risorsa cloud esistente creata a mano deve entrare sotto gestione IaC → La risposta giusta: usare terraform import per registrarla nello state, non ricrearla.