Ansible: configurare molti server in modo ripetibile

Creare un server è ormai questione di secondi. Configurarlo bene, invece, richiede ancora decine di passaggi: utenti, chiavi SSH, pacchetti, firewall, servizi, file di configurazione, aggiornamenti automatici. Farlo a mano una volta è tollerabile; farlo su dieci macchine, sempre nello stesso modo, è un invito all'errore. Ansible è uno degli strumenti più semplici per trasformare questi passaggi in codice.

Perché Ansible è facile da adottare

Ansible ha due caratteristiche che ne spiegano la diffusione:

• non richiede agenti: si collega ai server tramite SSH, lo stesso accesso che usi già, ed esegue i compiti con Python presente sulla macchina remota;
• usa file YAML leggibili: un playbook si capisce anche senza conoscere lo strumento, perché descrive i compiti con nomi espliciti.

Basta installarlo su un computer di controllo, il tuo portatile o un server dedicato, e puoi iniziare.

L'inventario

L'inventario elenca le macchine da gestire, divise in gruppi. Nella forma più semplice è un file di testo:

[web]
web1.example.com
web2.example.com

[db]
db1.example.com ansible_user=admin

I gruppi permettono di applicare configurazioni diverse a ruoli diversi. Con i provider cloud si può usare anche un inventario dinamico, che interroga le API e costruisce l'elenco dei server in base a etichette o tag.

Il playbook

Un playbook associa gruppi di macchine a una lista di compiti. Ogni compito usa un modulo, cioè un'azione già pronta: installare un pacchetto, copiare un file, gestire un servizio.

- name: Configura i server web
  hosts: web
  become: true
  tasks:
    - name: Installa nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Copia la configurazione del sito
      ansible.builtin.template:
        src: sito.conf.j2
        dest: /etc/nginx/sites-available/sito.conf
      notify: Ricarica nginx

    - name: Assicura che nginx sia attivo
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Ricarica nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

Si lancia con ansible-playbook -i inventario sito.yml. L'opzione become esegue i compiti con privilegi amministrativi.

Idempotenza: descrivere lo stato, non le azioni

I moduli di Ansible sono idempotenti: il compito «installa nginx» non reinstalla il pacchetto se è già presente, ma si limita a verificarlo. Per questo un playbook si può eseguire tutte le volte che si vuole; al secondo passaggio, se nulla è cambiato, Ansible riporta che non c'è niente da fare.

È una proprietà preziosa ma non automatica. Il modulo command o shell, che esegue un comando arbitrario, non sa se il comando ha già prodotto il suo effetto. Va usato solo quando non esiste un modulo specifico, e accompagnato da condizioni come creates, che indicano quando il comando non va ripetuto.

Handler: agire solo quando serve

Nell'esempio, il compito che copia la configurazione notifica l'handler «Ricarica nginx». L'handler viene eseguito una sola volta alla fine, e solo se il file è effettivamente cambiato. Così il servizio non viene riavviato inutilmente a ogni esecuzione, e se cinque compiti modificano cinque file la ricarica avviene comunque una volta.

Template e variabili

Il modulo template usa il motore Jinja2 per generare file di configurazione con valori variabili: nome del dominio, numero di processi, indirizzo del database. Le variabili si definiscono per gruppo, per singolo host o nel playbook, e permettono di usare lo stesso codice per staging e produzione cambiando solo i valori.

Per le password, Ansible offre Ansible Vault, che cifra file o singole variabili. Il file cifrato può stare nel repository; la chiave per decifrarlo resta fuori.

Ruoli: organizzare il codice

Quando i playbook crescono, conviene dividerli in ruoli: cartelle con una struttura standard che contengono compiti, handler, template e variabili predefinite per un singolo scopo. Un ruolo «base» crea gli utenti e configura SSH; un ruolo «web» installa e configura il server web; un ruolo «backup» pianifica le copie. Un playbook diventa allora una semplice lista di ruoli da applicare a ciascun gruppo.

Esistono ruoli pubblici già pronti per molti software. Prima di usarne uno, leggine il codice: esegue comandi con privilegi amministrativi sulle tue macchine.

Buone pratiche

• Prova in modalità controllo: --check mostra cosa cambierebbe senza applicarlo, e --diff evidenzia le differenze nei file.
• Limita l'ambito con --limit quando vuoi applicare una modifica a una sola macchina prima di estenderla.
• Dai un nome chiaro a ogni compito: l'output diventa un registro leggibile di ciò che è stato fatto.
• Tieni tutto in Git: inventario, playbook e ruoli diventano la documentazione di come sono configurati i server.
• Esegui i playbook regolarmente, non solo all'installazione, per riportare le macchine allo stato previsto se qualcuno le ha modificate a mano.

Ansible e Terraform insieme

I due strumenti si completano. Terraform crea le risorse, cioè macchine, reti e DNS; Ansible configura ciò che gira dentro le macchine. Con le immagini container parte del lavoro di Ansible si sposta nel Dockerfile, ma resta utile per preparare gli host, gestire server tradizionali e automatizzare operazioni ricorrenti come la rotazione dei certificati o l'aggiunta di un utente su tutte le macchine.

In sintesi

• Ansible configura i server via SSH senza agenti, usando playbook YAML leggibili.
• L'inventario raggruppa le macchine; i moduli idempotenti permettono esecuzioni ripetute senza effetti indesiderati.
• Gli handler riavviano i servizi solo quando la configurazione cambia davvero.
• Template, variabili, Vault e ruoli rendono il codice riutilizzabile e sicuro.
• Usa --check e --diff prima di applicare, e lascia a Terraform la creazione delle risorse.