Infrastructure as Code in pipeline: validate, plan, apply

Portare Terraform in una pipeline CI/CD significa trattare l’infrastruttura come software: ogni change passa da un repo Git, viene revisionato e promosso in modo tracciabile. Il flusso canonico prevede tre fasi. Prima la validazione (fmt e validate) come check sintattico e di stile eseguito da Cloud Build (il runner di CI). Poi il plan, che calcola il diff tra stato desiderato e stato reale senza applicare nulla: è l’artefatto da revisionare. Infine l’apply, che esegue le modifiche. Il punto d’esame ricorrente è il gate di approvazione manuale fra plan e apply per gli ambienti prod: aumenta l’affidabilità a scapito della velocità pura di rilascio, un trade-off tipico DevOps. Lo state va tenuto remoto (GCS backend) con state locking, altrimenti esecuzioni concorrenti corrompono lo stato. In alternativa a una pipeline self-managed, Infrastructure Manager esegue Terraform in modo gestito con un service account dedicato; in entrambi i casi vale il least privilege sul service account che fa apply.

Policy-as-code: governance dentro la pipeline

La policy-as-code codifica i vincoli di sicurezza e compliance come regole versionate, non come checklist manuali (riduzione di toil). Nel contesto Terraform, la validazione pre-apply con Config Validator (invocabile via gcloud) valuta il plan contro un set di constraint e blocca le risorse non conformi — per esempio un bucket con accesso pubblico o una VM senza label obbligatorie — prima che l’apply tocchi il progetto. È l’approccio shift-left: il difetto emerge in CI, non in produzione, dove il MTTR sarebbe più alto. Attenzione a non confondere questa validazione dell’IaC con l’enforcement runtime sui cluster, che è compito del Policy Controller.

GitOps con Config Sync e Policy Controller

Il GitOps usa Git come single source of truth con riconciliazione pull-based: un agente sul cluster confronta di continuo lo stato reale con quello dichiarato e converge. Config Sync è quell’agente per GKE: sincronizza lo stato desiderato dal repo e corregge automaticamente il drift. Se qualcuno modifica una risorsa a mano con kubectl, Config Sync la riporta a quanto è in Git — quindi il fix corretto è modificare il repo, non il cluster. Policy Controller (basato su OPA Gatekeeper) aggiunge i guardrail: agisce in admission control applicando constraint ai workload Kubernetes, con modalità dryrun/audit per introdurre una nuova policy e osservarne l’impatto senza bloccare i deploy esistenti. Insieme garantiscono desired state coerente su molti cluster, riducendo il toil operativo.

Continuous testing dell’infrastruttura e pipeline ML

Il continuous testing dell’infrastruttura non è solo il plan: comprende policy check, e dove serve integration test contro ambienti effimeri creati e distrutti dalla pipeline. Gli stessi principi si applicano al machine learning. Le Vertex AI Pipelines orchestrano come DAG le fasi di training, evaluation e deploy del modello, versionando dati, codice e artefatti. Il CI/CD per ML (MLOps) introduce il continuous training: il ri-addestramento è automatizzato e triggerato da nuovi dati o dal degrado delle metriche, non lanciato a mano. Prima del deploy su un endpoint si inserisce un evaluation gate che confronta il candidato con il modello in produzione: se non supera le soglie, non viene promosso, e resta possibile il rollback. È lo stesso trade-off affidabilità vs velocità visto per l’infrastruttura, applicato ai modelli.

Trappole tipiche d’esame

  • Un cluster GKE mostra drift perché un operatore ha modificato risorse a mano → Config Sync: in GitOps la modifica manuale viene sovrascritta; correggi il repo Git, non il cluster.
  • Bloccare risorse cloud non conformi prima che l’IaC le crei → policy-as-code in pipeline (Config Validator sul plan Terraform): non è compito del Policy Controller, che agisce sui workload Kubernetes.
  • Impedire il deploy di workload Kubernetes non conformi → Policy Controller (Gatekeeper): enforcement in admission sul cluster, distinto dalla validazione del plan Terraform.
  • Introdurre una nuova constraint senza rompere i deploy attuali → modalità dryrun/audit del Policy Controller: osservi le violazioni prima di passare all’enforcement.
  • Evitare terraform apply automatico e non revisionato in prod → gate di approvazione manuale fra plan e apply, con state remoto e locking: l’affidabilità prevale sulla velocità.
  • Ri-addestrare e ripubblicare il modello all’arrivo di nuovi dati → continuous training con Vertex AI Pipelines più evaluation gate: promuovi solo se supera le soglie, mai deploy diretto senza validazione.