Terraform su Azure: una guida pratica per principianti all'IaC

Se ti è mai capitato di cliccare avanti e indietro nel portale di Azure cercando di assemblare le risorse cloud a mano, ci sono passato anch’io—e stanca in fretta. È qui che entra in gioco Terraform. È uno strumento di infrastructure-as-code (IaC) che ti permette di definire e gestire la tua infrastruttura cloud con poche righe di codice.

In questo tutorial ci concentreremo sull’uso di Terraform con Azure. Ti guiderò su cosa è Terraform, come funziona nell’ecosistema Azure e come iniziare con esempi pratici. Vedremo anche alcune best practice per aiutarti a creare fin da subito deployment sicuri e affidabili.

Se sei alle prime armi con l’ecosistema Azure, questo percorso su Azure fundamentals offre un’introduzione strutturata ai servizi e ai principi di base.

Perché usare Terraform su Azure?

Terraform, sviluppato da HashiCorp, è uno strumento IaC open-source che ti permette di definire e gestire l’infrastruttura cloud con una sintassi dichiarativa. Insieme a Microsoft Azure, ti consente di scrivere in file di configurazione leggibili da umani risorse come reti virtuali, VM e database.

Perché usare Terraform con Azure? Per coerenza, scalabilità e velocità. Che tu stia creando una singola VM o orchestrando un’applicazione complessa multi-tier, Terraform semplifica il processo riducendo gli errori umani.

Se sei del tutto nuovo a Terraform, questa guida per principianti su Terraform spiega i fondamentali e come iniziare a usarlo per l’infrastructure as code.

Concetti fondamentali di Terraform su Azure

L’integrazione di Terraform con Azure offre una suite di funzionalità che rendono la gestione dell’infrastruttura intuitiva e potente. Vediamo i componenti chiave e le tipologie di risorse Terraform disponibili.

Gestione dell'infrastruttura dichiarativa

L’approccio dichiarativo di Terraform ti consente di definire come deve essere la tua infrastruttura Azure nei file .tf usando l’HashiCorp Configuration Language (HCL). 

Per esempio, puoi specificare una VM Azure con dimensioni, area e impostazioni di rete, e Terraform si occupa del come crearla. Ecco un esempio rapido:

resource "azurerm_virtual_machine" "example" {
  name                  = "my-vm"
  location              = "East US"
  resource_group_name   = "my-resource-group"
  vm_size               = "Standard_D2s_v3"
  network_interface_ids = [azurerm_network_interface.example.id]
  # ... other necessary configurations like OS disk, admin details
}

Questa definizione garantisce l’idempotenza—eseguire lo stesso codice più volte produce lo stesso risultato senza duplicati o errori. 

Ora analizziamo i concetti base di Terraform che rendono possibile questo approccio dichiarativo.

Stato di Terraform (.tfstate)

Il file terraform.tfstate è il cuore del modello dichiarativo di Terraform. È un file JSON che registra lo stato corrente delle tue risorse Azure: cosa è distribuito, relative configurazioni e relazioni. 

Quando esegui terraform apply, Terraform confronta i tuoi file .tf (stato desiderato) con il file .tfstate (stato effettivo) per determinare le modifiche da apportare. Per esempio, se aggiorni la dimensione di una VM nel codice, Terraform verifica il file .tfstate e modifica solo quell’attributo in Azure. 

Puoi memorizzare questo file in locale, ma per i team usa Azure Blob Storage per abilitare la collaborazione e il locking dello stato per prevenire conflitti.

Variabili di Terraform (.tfvars)

Le variabili rendono flessibili e riutilizzabili le configurazioni. Definite in variables.tf e terraform.tfvars, ti permettono di parametrizzare valori come nomi delle risorse o aree. 

Per esempio:

# variables.tf
variable "location" {
  type        = string
  default     = "East US"
  description = "The Azure region where resources will be deployed."
}

# terraform.tfvars (for a specific environment, e.g., production)
location = "West US"

# main.tf
resource "azurerm_resource_group" "example" {
  name     = "my-rg"
  location = var.location
}

Il file terraform.tfvars sovrascrive i default, così puoi distribuire lo stesso codice in aree diverse senza modificare i file .tf principali. Questo approccio è utile per gestire più ambienti (ad es. dev, prod).

File di configurazione Terraform (.tf)

Questi file contengono il tuo codice infrastrutturale, scritto in HCL. Definiscono risorse, provider, moduli e altro. Puoi organizzarli in un singolo main.tf o suddividerli in più file (ad es. variables.tf, outputs.tf, network.tf, compute.tf) per chiarezza e migliore organizzazione.

Terraform plan

Prima di applicare le modifiche, il comando terraform plan mostra un’anteprima di cosa farà Terraform—creare, aggiornare o eliminare risorse—in base alla differenza tra i tuoi file .tf e il .tfstate. È come una dry run che intercetta presto i potenziali problemi, mostrando un riepilogo dettagliato delle azioni proposte.

Terraform apply

Il comando terraform apply esegue le modifiche individuate da terraform plan, aggiornando Azure per allinearlo allo stato desiderato e aggiornando il file .tfstate. Ti verrà chiesta conferma prima di applicare le modifiche, fornendo una rete di sicurezza.

Workspace

I workspace di Terraform ti permettono di gestire più ambienti (ad es. dev, staging, prod) con un unico set di file .tf. Ogni workspace ha il proprio file .tfstate, così puoi distribuire infrastrutture simili con configurazioni diverse (ad es. dimensioni VM diverse per dev vs. prod). 

Per creare un nuovo workspace, puoi usare:

terraform workspace new production

Poi, puoi passare al workspace:

terraform workspace select production

Moduli

I moduli sono pacchetti riutilizzabili di codice Terraform. Per esempio, puoi creare un modulo per una rete virtuale Azure e riutilizzarlo su più progetti, riducendo le duplicazioni e favorendo la standardizzazione. Tratteremo i moduli più avanti nella sezione best practice.

Questi concetti—.tfstate, .tfvars e il flusso di lavoro dichiarativo—lavorano insieme per garantire che la tua infrastruttura Azure sia prevedibile, riproducibile e facile da gestire.

Gestione dello stato e collaborazione

Il file terraform.tfstate traccia lo stato della tua infrastruttura. Per i team, archiviarlo in Azure Blob Storage è una best practice fondamentale per abilitare accesso condiviso e controllo versione. Questa configurazione di backend remoto permette a tutti i membri del team di lavorare con una visione coerente dell’infrastruttura. 

Il locking dello stato, una funzionalità fornita automaticamente da molti backend remoti come Azure Blob Storage, previene conflitti quando più persone eseguono comandi Terraform simultaneamente, garantendo l’integrità dei dati.

Ecco un esempio di configurazione di un backend su Azure Blob Storage:

terraform {
  backend "azurerm" {
    resource_group_name  = "my-terraform-state-rg"
    storage_account_name = "mystorageterraformstate"
    container_name  = "tfstate"
    key  = "production/terraform.tfstate" # Path within the container
  }
}

Prima di eseguire terraform init con questa configurazione, dovrai creare manualmente (o con una configurazione Terraform separata) l’account di archiviazione Azure e il container. Questo setup garantisce una gestione sicura e collaborativa delle risorse Azure.

Ecosistema dei provider e AzureRM

Il provider azurerm è il ponte di Terraform verso Azure, traducendo l’HCL in chiamate API per gestire servizi come VM, reti e database. 

Supporta centinaia di tipi di risorse, dal compute (azurerm_linux_virtual_machine, azurerm_windows_virtual_machine) all’analytics (azurerm_synapse_workspace). Tra le sue funzionalità ci sono:

• Copertura ampia: Gestisci una vasta gamma di servizi Azure, incluse macchine virtuali, account di archiviazione, Azure Kubernetes Service (AKS), Azure SQL Database, Azure Cosmos DB con API MongoDB, Azure Functions e molto altro. Il provider azurerm è sviluppato attivamente per supportare nuovi servizi e funzionalità Azure man mano che diventano disponibili.
• Funzioni dinamiche: Usa funzioni definite dal provider per generare nomi unici (ad es. azurerm_resource_group.example.name) o recuperare dettagli su risorse esistenti (ad es. data.azurerm_virtual_network.existing.id). Questo consente configurazioni più dinamiche e intelligenti.
• Sorgenti dati: Il provider azurerm sfrutta data source per recuperare informazioni su risorse Azure esistenti. Questo è particolarmente utile quando devi referenziare risorse non create dalla tua attuale configurazione Terraform. Per esempio, puoi recuperare i dettagli di una rete virtuale esistente per distribuire nuove subnet o VM senza ricreare la VNet.

Prima di tuffarti in Terraform, può essere utile capire come configurare manualmente Azure—questa guida per principianti ti accompagna attraverso gli elementi essenziali.

Configurazione di un ambiente Terraform-Azure

Passiamo alla pratica! Questa sezione ti guida nel setup iniziale necessario per usare Terraform con la tua sottoscrizione Azure.

Autenticazione e strumenti CLI

Per interagire con Azure, prima devi installare e configurare l’Azure Command Line Interface (CLI). L’Azure CLI fornisce gli strumenti necessari per l’autenticazione e la gestione delle risorse Azure. Una volta installata, accedi al tuo account Azure:

az login

Il comando sopra aprirà una finestra del browser per l’autenticazione interattiva. Per un riferimento rapido, questa cheat sheet di Azure CLI può semplificare i tuoi workflow a riga di comando.

Per i deployment automatizzati con Terraform, specialmente in pipeline CI/CD, è altamente consigliato creare e usare i service principal di Azure Active Directory (AAD). I service principal forniscono un modo sicuro e programmatico per autenticare Terraform con la tua sottoscrizione Azure senza richiedere login interattivi.

Per creare un service principal con ruolo "Contributor" a livello di sottoscrizione, esegui:

az ad sp create-for-rbac --name "http://myTerraformServicePrincipal" --role "Contributor" --scopes "/subscriptions/<your-subscription-id>"

L’output fornirà appId, password e tenant (tenant ID). Puoi quindi impostarli come variabili d’ambiente per Terraform:

export ARM_CLIENT_ID="<appId>"
export ARM_CLIENT_SECRET="<password>"
export ARM_TENANT_ID="<tenant>"
export ARM_SUBSCRIPTION_ID="<your-subscription-id>"

Inizializzazione di un progetto

Un progetto tipico Terraform segue una struttura a directory, spesso con file .tf separati per diversi tipi di risorse o moduli (ad es. main.tf, variables.tf, outputs.tf, network.tf, compute.tf). 

Per iniziare qualsiasi progetto Terraform, vai nella directory del progetto ed esegui il comando terraform init. Questo comando inizializza la directory di lavoro, scarica i plugin dei provider necessari (come azurerm) e configura il backend per la gestione dello stato come definito nella tua configurazione.

mkdir my-azure-terraform-project
cd my-azure-terraform-project
# Create your .tf files here
terraform init

Questo comando prepara la directory alle operazioni di Terraform, assicurando che tutti i plugin richiesti siano disponibili.

Provisioning di risorse Azure

Questa sezione offre esempi pratici di provisioning di risorse Azure comuni usando Terraform, mostrando come definirle e distribuirle in modo programmatico.

Reti virtuali e subnet

Terraform eccelle nella definizione e distribuzione dell’infrastruttura di rete su Azure. Puoi definire facilmente reti virtuali (VNet) e segmentarle in subnet, controllando gli spazi IP e l’isolamento di rete. 

La gestione intrinseca delle dipendenze in Terraform garantisce che le risorse vengano create nell’ordine corretto; per esempio, le subnet saranno create solo dopo che la VNet padre è stata creata con successo. Ecco un esempio:

resource "azurerm_resource_group" "network_rg" {
  name     = "my-network-rg"
  location = "East US"
}

resource "azurerm_virtual_network" "main_vnet" {
  name                = "my-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.network_rg.location
  resource_group_name = azurerm_resource_group.network_rg.name
}

resource "azurerm_subnet" "web_subnet" {
  name                 = "web-subnet"
  resource_group_name  = azurerm_resource_group.network_rg.name
  virtual_network_name = azurerm_virtual_network.main_vnet.name
  address_prefixes     = ["10.0.1.0/24"]
}

resource "azurerm_subnet" "app_subnet" {
  name                 = "app-subnet"
  resource_group_name  = azurerm_resource_group.network_rg.name
  virtual_network_name = azurerm_virtual_network.main_vnet.name
  address_prefixes     = ["10.0.2.0/24"]
}

Macchine virtuali con cloud-init

Effettuare il provisioning di macchine virtuali (VM) con Terraform è semplice. Per automatizzare la configurazione post-deployment e il setup iniziale, puoi sfruttare script cloud-init. 

cloud-init ti permette di iniettare script eseguiti al primo avvio della VM, abilitando attività come installazione di software, configurazione utenti o setup di servizi, direttamente dalla tua configurazione Terraform.

Ecco un esempio di provisioning di una VM Linux con un semplice script cloud-init per installare Nginx:

resource "azurerm_resource_group" "vm_rg" {
  name     = "my-vm-rg"
  location = "East US"
}

resource "azurerm_network_interface" "vm_nic" {
  name                = "my-vm-nic"
  location            = azurerm_resource_group.vm_rg.location
  resource_group_name = azurerm_resource_group.vm_rg.name

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.web_subnet.id # Assuming web_subnet defined above
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.vm_public_ip.id
  }
}

resource "azurerm_public_ip" "vm_public_ip" {
  name                = "my-vm-public-ip"
  location            = azurerm_resource_group.vm_rg.location
  resource_group_name = azurerm_resource_group.vm_rg.name
  allocation_method   = "Static"
}

resource "azurerm_linux_virtual_machine" "my_vm" {
  name                  = "my-linux-vm"
  location              = azurerm_resource_group.vm_rg.location
  resource_group_name   = azurerm_resource_group.vm_rg.name
  size                  = "Standard_B2s"
  admin_username        = "azureuser"
  admin_password        = "P@ssw0rd1234!" # In a real scenario, use Azure Key Vault or variables
  network_interface_ids = [azurerm_network_interface.vm_nic.id]

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "18.04-LTS"
    version   = "latest"
  }

  # cloud-init script to install Nginx
  custom_data = base64encode(<<EOF
#cloud-config
packages:
  - nginx
runcmd:
  - systemctl start nginx
  - systemctl enable nginx
EOF
  )
}

Modularizzare l'infrastruttura

Man mano che la tua infrastruttura Azure cresce, modularizzare le configurazioni Terraform diventa fondamentale per riutilizzabilità, manutenibilità e scalabilità. 

I moduli racchiudono un insieme di risorse correlate e relative configurazioni in unità riutilizzabili. Questa sezione offre indicazioni su come strutturare il tuo codice Terraform in moduli e mostra come richiamarli nelle configurazioni principali, promuovendo una codebase più pulita e organizzata.

Esempio: Struttura del modulo (modules/web-app/main.tf):

# modules/web-app/main.tf
resource "azurerm_app_service_plan" "app_plan" {
  name                = var.app_service_plan_name
  location            = var.location
  resource_group_name = var.resource_group_name
  kind                = "Linux"
  sku {
    tier = "Basic"
    size = "B1"
  }
}

resource "azurerm_app_service" "app_service" {
  name                = var.app_service_name
  location            = var.location
  resource_group_name = var.resource_group_name
  app_service_plan_id = azurerm_app_service_plan.app_plan.id
}

variable "app_service_plan_name" {
  type = string
}

variable "app_service_name" {
  type = string
}

variable "location" {
  type = string
}

variable "resource_group_name" {
  type = string
}

output "app_service_default_hostname" {
  value = azurerm_app_service.app_service.default_host_name
}

Esempio: Richiamare il modulo (main.tf nella directory root):

resource "azurerm_resource_group" "app_rg" {
  name     = "my-webapp-rg"
  location = "East US"
}

module "my_web_app" {
  source                = "./modules/web-app" # Path to your module
  app_service_plan_name = "my-webapp-plan"
  app_service_name      = "my-unique-webapp-2025"
  location              = azurerm_resource_group.app_rg.location
  resource_group_name   = azurerm_resource_group.app_rg.name
}

output "webapp_url" {
  value = module.my_web_app.app_service_default_hostname
}

Questa struttura rende semplice riutilizzare la logica di deployment della tua web app in ambienti o progetti diversi.

Workflow avanzati con Terraform

Questa sezione esplora funzionalità Terraform più sofisticate che aumentano flessibilità e potenza dei tuoi deployment infrastrutturali, andando oltre il semplice provisioning di base.

Data source e configurazioni dinamiche

I data source in Terraform permettono di recuperare informazioni su risorse esistenti, sia gestite da Terraform sia no. Questo è utilissimo per integrarsi con infrastrutture preesistenti o per lookup dinamici. 

Abbinati a configurazioni dinamiche (come for_each e count), i data source abilitano script Terraform altamente flessibili e adattivi, in grado di reagire a varie condizioni e disponibilità di risorse.

Esempio: Uso di un data source per trovare una VNet esistente e aggiungere una nuova subnet:

# Data source to fetch an existing Virtual Network
data "azurerm_virtual_network" "existing_vnet" {
  name                = "production-vnet"
  resource_group_name = "production-network-rg"
}

# Create a new subnet within the existing VNet
resource "azurerm_subnet" "new_app_subnet" {
  name                 = "new-app-subnet"
  resource_group_name  = data.azurerm_virtual_network.existing_vnet.resource_group_name
  virtual_network_name = data.azurerm_virtual_network.existing_vnet.name
  address_prefixes     = ["10.0.3.0/24"]
}

Esempio: Creazione dinamica di più VM usando for_each e una variabile mappa:

variable "vm_configs" {
  type = map(object({
    size = string
    ip   = string
  }))
  default = {
    "web-server-01" = { size = "Standard_B1s", ip = "10.0.1.10" },
    "web-server-02" = { size = "Standard_B1s", ip = "10.0.1.11" }
  }
}

resource "azurerm_linux_virtual_machine" "web_servers" {
  for_each              = var.vm_configs
  name                  = each.key
  location              = azurerm_resource_group.main_rg.location
  resource_group_name   = azurerm_resource_group.main_rg.name
  size                  = each.value.size
  admin_username        = "azureuser"
  admin_password        = "StrongPassword!123" # Use Key Vault in production
  network_interface_ids = [azurerm_network_interface.web_servers_nic[each.key].id]

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "18.04-LTS"
    version   = "latest"
  }
}

resource "azurerm_network_interface" "web_servers_nic" {
  for_each            = var.vm_configs
  name                = "${each.key}-nic"
  location            = azurerm_resource_group.main_rg.location
  resource_group_name = azurerm_resource_group.main_rg.name

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.web_subnet.id
    private_ip_address_allocation = "Static"
    private_ip_address            = each.value.ip
  }
}

Policy as code con Sentinel

Per le organizzazioni con requisiti stringenti di compliance e governance, HashiCorp Sentinel offre un framework di policy-as-code che si integra con Terraform Enterprise (o può essere adattato per usi personalizzati con Terraform Cloud). 

Sentinel ti consente di definire policy granulari che impongono best practice di sicurezza, costi e operatività prima che l’infrastruttura venga fornita. 

Per esempio, una policy potrebbe impedire la creazione di VM più grandi di una certa dimensione o assicurare che tutte le risorse abbiano tag specifici. Policy predefinite possono far rispettare standard di conformità, impedendo che deployment non conformi raggiungano l’ambiente Azure.

Strategie di ottimizzazione dei costi

Terraform, insieme ad Azure Policy, può essere uno strumento potente per imporre controlli sui costi nel tuo ambiente Azure. 

Definendo Azure Policy che limitano gli SKU delle risorse, impongono i tag per l’allocazione dei costi o impediscono il deployment di risorse costose, puoi implementare misure efficaci di risparmio direttamente nei tuoi workflow IaC. 

Terraform può anche distribuire e gestire Azure Policy, garantendo che le regole di governance siano versionate e applicate in modo coerente.

Esempio: Distribuire una definizione di Azure Policy con Terraform:

resource "azurerm_resource_group" "policy_rg" {
  name     = "azure-policy-rg"
  location = "global" # Policies are global resources
}

resource "azurerm_policy_definition" "deny_large_vms" {
  name         = "deny-large-vm-skus"
  policy_type  = "Custom"
  mode         = "All"
  display_name = "Deny creation of large VM SKUs (E-series)"
  description  = "This policy denies the creation of Azure Virtual Machines with SKUs from the E-series for cost management."

  policy_rule = <<POLICY_RULE
{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "field": "Microsoft.Compute/virtualMachines/sku.name",
        "like": "Standard_E*"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}
POLICY_RULE
}

resource "azurerm_policy_assignment" "deny_large_vms_assignment" {
  name                 = "deny-large-vm-skus-assignment"
  scope                = "/subscriptions/${data.azurerm_subscription.current.id}" # Assign to entire subscription
  policy_definition_id = azurerm_policy_definition.deny_large_vms.id
  display_name         = "Deny large VM SKUs"
}

data "azurerm_subscription" "current" {}

Questa combinazione ti permette di far rispettare automaticamente le policy sui costi dell’organizzazione, prevenendo overspending e promuovendo l’efficienza delle risorse.

Integrazione CI/CD

Questa sezione si concentra sull’integrazione di Terraform nelle pipeline di Continuous Integration/Continuous Delivery (CI/CD) per deployment automatizzati e affidabili, rendendo i cambiamenti infrastrutturali parte fluida del ciclo di vita del software.

Pipeline di Azure DevOps

Azure DevOps offre una piattaforma robusta per costruire pipeline CI/CD. Un flusso comune include:

1. Initialize: terraform init per scaricare i provider e impostare il backend.
2. Plan: terraform plan -out per generare e salvare un execution plan.
3. Review (approvazione manuale): una fase in cui il plan generato viene revisionato da una persona prima dell’apply.
4. Apply: terraform apply tfplan per eseguire le modifiche.

Puoi esplorare come Azure DevOps supporti workflow CI/CD end-to-end per il deploy delle applicazioni in questo tutorial pratico.

GitHub Actions

GitHub Actions offre un modo flessibile e potente per automatizzare i tuoi workflow Terraform direttamente nei repository GitHub. Usa file YAML per definire workflow che rispondono a eventi come push o pull request.

Ecco i passaggi per un deployment Terraform di base usando GitHub Actions:

1. Definisci il trigger del workflow: di solito on: push su un branch specifico (ad es. main).
2. Checkout del codice: usa actions/checkout@v3.
3. Configura le credenziali Azure: imposta le variabili d’ambiente usando i GitHub Secrets (ad es. AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID).
4. Installa Terraform: usa hashicorp/setup-terraform@v2.
5. Terraform init: inizializza la directory di lavoro.
6. Terraform plan: crea e mostra l’execution plan.
7. Terraform apply (condizionale): applica le modifiche, spesso condizionato da un passaggio di approvazione manuale o da un branch specifico.

Esempio: YAML per un workflow GitHub Actions (.github/workflows/terraform-azure.yml):

name: 'Terraform Azure CI/CD'

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

env:
  ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
  ARM_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
  ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
  ARM_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  TF_STATE_RG: 'my-terraform-state-rg'
  TF_STATE_SA: 'mystorageterraformstate'
  TF_STATE_CONTAINER: 'tfstate'
  TF_STATE_KEY: 'production/terraform.tfstate'

jobs:
  terraform:
    name: 'Terraform Actions'
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: './terraform' # Assuming Terraform files are in a 'terraform' folder

    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
      - name: Terraform Init
        id: init
        run: terraform init -backend-config="resource_group_name=${{ env.TF_STATE_RG }}" -backend-config="storage_account_name=${{ env.TF_STATE_SA }}" -backend-config="container_name=${{ env.TF_STATE_CONTAINER }}" -backend-config="key=${{ env.TF_STATE_KEY }}"
      - name: Terraform Plan
        id: plan
        run: terraform plan -no-color
      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve

Sicurezza e conformità

Questa sezione evidenzia considerazioni di sicurezza e conformità quando lavori con Terraform su Azure, enfatizzando pratiche sicure per dati sensibili e accesso di rete.

Integrazione con Azure Key Vault

Gestire dati sensibili come API key, stringhe di connessione, credenziali database e certificati nelle configurazioni Terraform può essere rischioso se non trattati correttamente. Azure Key Vault offre una soluzione sicura e centralizzata per archiviare e gestire secret, chiavi e certificati. 

Esempio: Recuperare una password del database da Key Vault:

# Data source to retrieve an existing Azure Key Vault
data "azurerm_key_vault" "my_key_vault" {
  name                = "my-secure-keyvault"
  resource_group_name = "my-secrets-rg"
}

# Data source to retrieve a specific secret from the Key Vault
data "azurerm_key_vault_secret" "db_password" {
  name         = "DbPassword"
  key_vault_id = data.azurerm_key_vault.my_key_vault.id
}

resource "azurerm_sql_server" "example" {
  administrator_login          = "sqladmin"
  administrator_login_password = data.azurerm_key_vault_secret.db_password.value # Securely retrieve password
}

Questo metodo assicura che i dati sensibili non vengano mai esposti direttamente nel tuo codice Terraform o nel file di stato, aderendo alle best practice di sicurezza.

Network Security Group (NSG)

I Network Security Group (NSG) sono fondamentali per applicare regole di traffico e mettere in sicurezza le reti virtuali Azure. Agiscono come un firewall virtuale, consentendo o negando il traffico di rete in ingresso e in uscita verso le risorse Azure in base a regole da te definite.

Esempio: Configurare un NSG per una web application:

resource "azurerm_network_security_group" "web_nsg" {
  name                = "web-nsg"
  location            = azurerm_resource_group.network_rg.location
  resource_group_name = azurerm_resource_group.network_rg.name

  security_rule {
    name                       = "AllowHTTPInbound"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefix      = "Internet"
    destination_address_prefix = "*"
  }
  security_rule {
    name                       = "AllowSSHInbound"
    priority                   = 120
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "22"
    source_address_prefix      = "YourTrustedIPRange" # IMPORTANT: Restrict to known IPs
    destination_address_prefix = "*"
  }
}

# Associate NSG with a subnet 
resource "azurerm_subnet_network_security_group_association" "web_subnet_nsg_association" {
  subnet_id                 = azurerm_subnet.web_subnet.id
  network_security_group_id = azurerm_network_security_group.web_nsg.id
}

Best practice per deployment enterprise

Questa sezione delinea le best practice essenziali per distribuire e gestire Terraform su larga scala in un contesto enterprise, con focus su design, manutenzione e monitoraggio.

Reference architecture

Per deployment Azure robusti ed efficienti, allinea le tue configurazioni Terraform all’Azure Well-Architected Framework. Questo quadro fornisce blueprint per progettare soluzioni cloud di alta qualità, sicure e convenienti, guidando i tuoi design Terraform per affidabilità, sicurezza, ottimizzazione dei costi, eccellenza operativa ed efficienza prestazionale.

Igiene del file di stato

Il file di stato di Terraform è la single source of truth della tua infrastruttura. Garantiscine integrità e sicurezza attraverso:

• Archiviazione remota: usa sempre un backend remoto come Azure Blob Storage per la gestione collaborativa dello stato.
• Cifratura e controllo accessi: verifica che lo stato remoto sia cifrato a riposo e applica Azure RBAC rigorosi per limitare l’accesso.
• Locking e versioning dello stato: sfrutta il locking integrato per prevenire conflitti e abilita il versioning sul container di archiviazione per tracciabilità storica e recovery.

Monitoraggio e rilevamento del drift

Mantieni la consistenza dell’infrastruttura monitorando attivamente il "configuration drift"—deviazioni non autorizzate dal tuo stato Terraform definito.

• Rilevamento proattivo: implementa esecuzioni periodiche di terraform plan nelle tue pipeline CI/CD (ad es. notturne) per identificare cambiamenti.
• Monitoraggio Azure: utilizza Azure Monitor e Log Analytics per tracciare salute delle risorse ed eventi.
• Rimediation automatizzata: sviluppa processi (manuali o automatizzati) per rieseguire terraform apply e riportare le risorse fuori allineamento in conformità con la tua IaC.

Per monitorare e ottimizzare ulteriormente la tua infrastruttura, Azure Monitor offre utili intuizioni—questa guida ti mostra come iniziare.

Conclusione

E con questo è tutto! Ora hai visto come Terraform può rendere la gestione delle risorse Azure molto più efficiente e prevedibile. Abbiamo visto come portare l’automazione nel tuo workflow con strumenti CI/CD come Azure DevOps e GitHub Actions, e come mantenere tutto sicuro con Azure Key Vault e Network Security Group.

Abbiamo anche toccato alcune best practice importanti—come usare reference architecture, gestire con cura i file di stato e tenere d’occhio i cambiamenti con monitoraggio e rilevamento del drift.

Con questi strumenti e consigli, sei sulla buona strada per costruire un’infrastruttura più affidabile e scalabile su Azure.

Vuoi convalidare le tue competenze? Queste domande di colloquio su Terraform possono aiutarti a prepararti per opportunità di lavoro o certificazioni!