m4nifest0-tech

Cerca nel sito

Automazione

Provisioning automatico di VM con Ansible e cloud-init

Creazione ripetibile di macchine virtuali Proxmox da un template cloud-init, con Ansible e Git come fonte di verità della configurazione.
Completato

Problemi affrontati

  • La creazione manuale delle VM produceva macchine con configurazioni leggermente diverse, dipendenti da chi le aveva preparate.
  • Ogni nuova VM richiedeva molti passaggi ripetitivi: clonazione, rete, utenti, chiavi e pacchetti di base.
  • Non esisteva un elenco affidabile dei sistemi in esecuzione e del loro scopo.
  • Le modifiche non erano tracciate: era impossibile ricostruire quando e perché una configurazione fosse cambiata.

Soluzione implementata

Un template di VM basato su un'immagine cloud Debian viene clonato tramite le API di Proxmox da un playbook Ansible. Al primo avvio cloud-init imposta utente di automazione, chiavi pubbliche, nome host e parametri di rete. Terminato il primo avvio, Ansible applica i ruoli di base (aggiornamenti, orario, agente di monitoraggio, hardening) e poi i ruoli specifici del servizio. Inventario, variabili e playbook risiedono in un repository Git, così ogni modifica passa da commit e revisione. Le credenziali sono protette con Ansible Vault e l'utente per le API ha privilegi minimi.

Risultati

  • Una nuova VM è pronta all'uso con un'unica esecuzione, riproducibile e identica a ogni ripetizione.
  • L'inventario nel repository è la fonte di verità sui sistemi esistenti e sul loro ruolo.
  • Le modifiche alla configurazione sono tracciate in Git e possono essere riviste o annullate.
  • Ricreare una VM danneggiata richiede soltanto di rilanciare il playbook, senza configurazioni manuali.

Descrizione tecnica

Creare una VM a mano significa ripetere gli stessi passaggi e accettare piccole differenze tra una macchina e l'altra. Il caso di studio trasforma la creazione in un flusso dichiarativo: la VM si descrive in un file versionato e si ottiene con un'unica esecuzione.

Flusso di provisioning

  1. La VM è descritta nell'inventario Ansible, nel repository Git: nome, ruolo, risorse, segmento di rete e indirizzo.
  2. Un playbook clona il template tramite le API di Proxmox VE e imposta i parametri cloud-init.
  3. Al primo avvio cloud-init configura utente di automazione, chiavi pubbliche, nome host e rete, quindi installa e avvia il guest agent.
  4. Terminato il primo avvio, Ansible si collega e applica i ruoli di base e quelli specifici del servizio.
  5. La VM viene registrata nel monitoraggio e inclusa nei job di backup.

Componenti e scelte

  • Template da immagine cloud ufficiale Debian, aggiornato periodicamente e clonato in modalità completa, così che ogni VM sia indipendente.
  • API di Proxmox con un utente di servizio dedicato e un ruolo a privilegi minimi, invece di un accesso amministrativo completo. Le credenziali sono protette con Ansible Vault e non compaiono in chiaro nel repository.
  • Ruoli idempotenti: rieseguire il playbook su una VM già configurata non produce modifiche.
  • Git come fonte di verità: ogni cambiamento passa da commit e revisione, con possibilità di tornare alla versione precedente.
  • Indirizzi e nomi assegnati dall'inventario e non scelti a mano, per evitare duplicati e mantenere il piano degli indirizzi allineato a ciò che è realmente in esecuzione.

Il playbook automatizza la stessa sequenza che, a mano e in forma semplificata, corrisponde a questi comandi:

Equivalente manuale sul nodo Proxmox
qm clone 9000 120 --name vm-esempio --full
qm set 120 --ciuser automazione --ipconfig0 ip=192.0.2.50/24,gw=192.0.2.1
qm start 120

Nota

Il template non contiene credenziali: utenti e chiavi pubbliche vengono iniettati al momento della clonazione da cloud-init.

Verifiche e collaudo

Ogni ruolo è provato su una VM usa e getta prima dell'impiego reale. Una seconda esecuzione del playbook deve risultare senza modifiche, a conferma dell'idempotenza; l'analisi statica con ansible-lint intercetta gli errori comuni e la modalità --check --diff mostra in anticipo ciò che cambierebbe. Si controlla inoltre che cloud-init termini senza errori con cloud-init status --wait. La prova più significativa è distruggere una VM e ricrearla dal repository: deve tornare identica, a conferma che lo stato dichiarato corrisponde alla realtà.

Possibili evoluzioni

Una pipeline di integrazione continua che esegua lint e prove a ogni modifica, un inventario dinamico collegato alle API di Proxmox, la registrazione automatica dei nomi DNS e delle prenotazioni DHCP e un confronto con strumenti dichiarativi come OpenTofu. I dettagli sono in Ansible e cloud-init per il provisioning su Proxmox.