Perché l’Infrastructure as Code

Gestire risorse Azure dal portale è veloce ma non ripetibile: non lascia traccia di cosa è stato creato e non garantisce che due ambienti (dev, test, prod) siano identici. L’Infrastructure as Code (IaC) risolve il problema descrivendo l’infrastruttura in file dichiarativi versionabili in Git, sottoponibili a code review e ridistribuibili in pipeline CI/CD. In Azure lo strumento nativo è l’Azure Resource Manager (ARM), che espone due linguaggi di authoring: il classico ARM template (JSON) e il più recente Bicep.

Dichiarativo, non imperativo

Entrambi i formati sono dichiarativi: dichiari lo stato finale desiderato (una VM con queste proprietà, questa subnet, questo NSG) e ARM calcola le operazioni necessarie per raggiungerlo. Non scrivi la sequenza di comandi passo-passo. Questa è la base dell’idempotenza (vedi sotto).

ARM JSON vs Bicep

Bicep non è un servizio diverso: è un linguaggio DSL che al momento del deploy viene transpilato in ARM JSON (bicep build). ARM esegue sempre e solo JSON. Rispetto al JSON, Bicep offre:

  • Sintassi più concisa e leggibile: niente parentesi graffe annidate, niente stringhe [concat(...)] per le espressioni.
  • Modularità con i module: un file .bicep può richiamare altri moduli, favorendo il riuso (es. un modulo network, uno compute).
  • Astrazione: gestione automatica delle dipendenze tra risorse tramite riferimento simbolico (raramente serve dependsOn esplicito), type safety e IntelliSense in VS Code.
  • parameters e output: i parameters rendono il template riutilizzabile fra ambienti (SKU, location, nomi); gli output restituiscono valori calcolati a runtime (es. l’endpoint di uno Storage Account, l’IP pubblico) da passare a step successivi della pipeline.

Per l’esame: Bicep è il linguaggio raccomandato per i nuovi progetti; JSON resta valido e alcuni tool lo richiedono ancora. Puoi convertire nei due sensi con az bicep build e az bicep decompile.

Deployment mode: Incremental vs Complete

Ogni deployment ARM verso un resource group usa una mode, ed è un concetto tipico da esame.

  • Incremental (default): ARM aggiunge o aggiorna le risorse presenti nel template. Le risorse già esistenti nel resource group ma non menzionate nel template vengono lasciate intatte. È la modalità sicura per aggiornamenti graduali.
  • Complete: ARM porta il resource group a corrispondere esattamente al template. Le risorse presenti nel resource group ma assenti dal template vengono ELIMINATE.

Il Complete mode va usato con estrema cautela: è utile per garantire che un ambiente contenga solo ciò che è definito nel codice, ma un template incompleto può cancellare risorse critiche. Prima di applicarlo, usa sempre l’operazione what-if per una preview.

az deployment group what-if -g rg-prod -f main.bicep
az deployment group create -g rg-prod -f main.bicep --mode Complete

Azure CLI e Azure PowerShell

Il deployment e la gestione si effettuano con due CLI equivalenti:

  • Azure CLI: comandi az deployment group create (scope resource group), az deployment sub create (scope subscription).
  • Azure PowerShell: New-AzResourceGroupDeployment, New-AzSubscriptionDeployment.

Sono strumenti imperativi che invocano deployment dichiarativi. La scelta è spesso questione di ecosistema (PowerShell su Windows/on-prem, CLI cross-platform e nelle pipeline Linux). Entrambe supportano il passaggio di un parameter file (--parameters @prod.parameters.json).

Idempotenza

Un deployment ARM è idempotente: rieseguire lo stesso template (in Incremental) più volte produce sempre lo stesso stato, senza errori né duplicati. Se una risorsa esiste già con le proprietà dichiarate, ARM non fa nulla; se differisce, la allinea. Questo rende sicuro il redeploy in pipeline e distingue IaC dagli script imperativi, che fallirebbero al secondo run (es. “risorsa già esistente”).

Trappole tipiche d’esame

  • Devi cancellare le risorse non più presenti nel template per allineare l’ambiente al codice → mode Complete (ma solo dopo what-if, perché elimina tutto ciò che non è nel template).
  • Un aggiornamento a un template deployato in Complete ha rimosso uno Storage Account non incluso → è il comportamento atteso: in Complete le risorse assenti dal template vengono eliminate, non ignorate.
  • Rieseguire lo stesso deployment Incremental due volte non deve creare duplicati né dare errore → è garantito dall’idempotenza di ARM.
  • Devi passare l’endpoint di una risorsa creata a uno step successivo della pipeline → usa un output del template, non un valore hard-coded.
  • Serve un template già scritto in JSON convertito a Bicep (o viceversa) → az bicep decompile / az bicep build; ricorda che ARM esegue comunque solo JSON transpilato.