Dal caos all'automazione: perché Ansible cambia tutto
Immagina di dover configurare 50 server identici. Uno alla volta. A mano. Collegandoti via SSH, digitando gli stessi comandi, sperando di non sbagliare. Poi il cliente ti chiede di rifare tutto perché è cambiata una variabile. Hai vissuto questo scenario? Benvenuto nel mondo che esisteva prima di Ansible.
Questo è il mio primo post ed è strutturato in tre livelli: partiremo dal concetto zero, cos'è Ansible e perché esiste fino ad per arrivare a capire come funziona sotto il cofano.
Cos'è Ansible, in parole semplici
Ansible è un motore di automazione IT open source sviluppato da Red Hat. Nella pratica, è uno strumento che ti permette di descrivere in un file di testo (in formato YAML) come vuoi che siano configurati i tuoi sistemi. Ansible esegue in automatico il codice e configura contemporaneamente tutti i sistemi inclusi nell'inventario associato.
Analogia del quotidiano
Pensa a una ricetta. Tu scrivi: "aggiungi 200g di farina, scalda a 180°, cuoci per 30 minuti". Ansible è il cuoco che esegue la ricetta identica su mille forni contemporaneamente, senza stancarsi e senza dimenticare nulla.
Il problema che risolve
Prima dell'automazione, i team IT vivevano con tre grandi mali: la deriva della configurazione (ogni server diverso dagli altri per piccole modifiche fatte nel tempo), la documentazione che mente (i runbook diventano obsoleti) e il fattore bus (solo Mario sa come funziona quel server).
Ansible trasforma la configurazione in codice versionabile. Il tuo playbook è la documentazione. Ed è sempre aggiornata, perché è proprio quello che viene eseguito.
Perché così tanti la scelgono?
- Agentless: Non installa nulla sui server che gestisce. Usa SSH (o WinRM per Windows). Zero overhead.
- YAML leggibile: I playbook si leggono quasi come frasi in inglese. Non servono anni di programmazione per capire cosa fa uno script.
- Idempotente: Eseguilo una o cento volte: il risultato è sempre lo stesso. Se Apache è già installato, Ansible non lo reinstalla.
- Ecosistema enorme: Oltre 3.000 moduli ufficiali per gestire cloud, database, network, container, applicazioni.
Come funziona: i concetti chiave
Ansible ha un'architettura elegante nella sua semplicità.
Ci sono tre attori principali: il control node (il tuo laptop o un server dedicato), i managed node (i server che vuoi configurare), e l'inventario che li collega.
L'inventario: chi gestisci
L'inventario è semplicemente una lista di server o dispositivi remoti. Può essere un file statico (anche un semplice .ini o YAML) oppure dinamico, generato da AWS, GCP, Azure, VMware in tempo reale.
# Group servers by role
[webservers]
web-01.example.com
web-02.example.com
[databases]
db-01.example.com # ansible_user=postgres
[all:vars]
ansible_user=deploy
ansible_ssh_private_key_file=~/.ssh/id_rsainventory.ini
Il Playbook: cosa fare
Il playbook è il cuore di Ansible. È un file YAML che descrive una sequenza di plays, ciascuno composto da tasks. Ogni task usa un modulo, pensa ai moduli come a funzioni predefinite per ogni operazione comune.
---
# One play = group of servers + tasks list
- name: Configure webservers
hosts: webservers
become: yes # equivalent to sudo
tasks:
- name: Install Nginx
ansible.builtin.apt:
name: nginx
state: present # idempotent
- name: Start and enable the service
ansible.builtin.service:
name: nginx
state: started
enabled: yes
install_webserver.yml
Lo esegui con un singolo comando:
$ ansible-playbook -i inventory.ini install_webserver.yml
PLAY [Configure the webservers] ***********************************
TASK [Gathering Facts] ***********************************************
ok: [web-01.example.com]
ok: [web-02.example.com]
TASK [Install Nginx] *************************************************
changed: [web-01.example.com]
changed: [web-02.example.com]
TASK [Start and enable the service] **********************************
ok: [web-01.example.com]
ok: [web-02.example.com]
PLAY RECAP *******************************************************
web-01 : ok=3 changed=1 unreachable=0 failed=0
web-02 : ok=3 changed=1 unreachable=0 failed=0Il colore del risultato è tutto:
- ok significa "già nel giusto stato, nulla da fare"
- changed significa "ho apportato la modifica"
- failed è l'unica cosa da temere e Ansible si ferma
Sotto il cofano: architettura e best practice
Ansible vs gli altri: dove si posiziona
Nel panorama DevOps esistono altri tool di configuration management. Ognuno ha la sua filosofia. Ecco un confronto dei principali strumenti disponibili:
| Ansible | Puppet | Chef | Terraform | |
|---|---|---|---|---|
| Language | YAML | Proprietary DSL | Ruby (DSL) | HCL |
| Agentless | ✓ Yes | ✗ No | ✗ No | ✓ Yes |
| Learning curve | Low | High | High | Medium |
| Primary use | Config + orchestration | Config mgmt | Config mgmt | Provisioning |
| Push vs Pull | Push | Pull | Pull | Push |
Nota Tecnica
Ansible e Terraform non sono concorrenti ma si complementano a vicenda, entrambi possono fare provisioning. La differenza reale è nell'approccio: Terraform gestisce lo stato dell'infrastruttura (sa cosa esiste, cosa è cambiato, cosa va distrutto), mentre Ansible eccelle nell'orchestrazione e configuration management. In molti team si usano insieme: Terraform per il ciclo di vita delle risorse cloud, Ansible per tutto ciò che succede dentro.
Struttura di un progetto reale
I playbook semplici funzionano subito, ma per progetti di scala si usa la struttura a Roles: cartelle standardizzate che rendono il codice riutilizzabile e testabile. Ansible Galaxy è il repository pubblico di roles già pronti.
site.yml # main playbook
inventory/
production.ini
staging.ini
roles/
nginx/
tasks/main.yml # what to do
handlers/main.yml # ex: restart nginx on change
templates/ # Jinja2 files with variables
defaults/main.yml # default values
vars/main.yml # override variables
postgresql/
tasks/main.yml
...
group_vars/
webservers.yml # variables per group
all.ymlIdempotenza: il concetto più importante
L'idempotenza non è un optional ma è il requisito fondamentale di ogni buon playbook. Significa eseguire il task una volta o cento volte e deve produrre esattamente lo stesso risultato finale.
I moduli Ansible built-in sono progettati per essere idempotenti. Se usi il modulo copy, copia il file solo se è diverso. Se usi package, installa solo se non è già presente. Quando invece usi shell o command, sei tu responsabile di garantirla (in questo caso si usa in combinazione con creates o when).
Altri concetti fondamentali
- Jinja2 Templates
File di configurazione dinamici con variabili, loop e condizioni essenziali per ambienti multi-stage. - Ansible Vault
Crittografia dei dati sensibili (password, chiavi API) direttamente nei playbook evitando di usare le credenziali in chiaro. - AWX / AAP
L'interfaccia grafica enterprise per Ansible: scheduling, RBAC, audit log, integrazione CI/CD. - Molecule
Il framework per testare i tuoi roles in container isolati, prima di applicarli in produzione.
Conclusione
Ansible non è solo uno strumento tecnico, è un cambio di mentalità:
Passare dall'eseguire al descrivere. Dall'intervento manuale alla ripetibilità garantita. Dall'infrastruttura come sequenza di comandi all'infrastruttura come codice.
Nel prossimo post vedremo come scrivere un playbook da zero, testarlo in locale con Docker, e strutturare il primo role riutilizzabile. Stay tuned e se hai domande, la sezione commenti è aperta.