Accedi Iscriviti
By Fabio —

Dal caos all'automazione: perché Ansible cambia tutto

Configurare 50 server identici. Uno alla volta. A mano. Collegandosi via SSH, digitando gli stessi comandi, sperando di non sbagliare. Poi il cliente chiede di rifare tutto perché è cambiata una variabile. Questo era il mondo che esisteva prima di Ansible.

Questo è il primo post ed è strutturato in tre livelli: si parte dal concetto zero, cos'è Ansible e perché esiste, fino 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 permette di descrivere in un file di testo (in formato YAML) come devono essere configurati i sistemi. Ansible esegue in automatico il codice e configura contemporaneamente tutti i sistemi inclusi nell'inventario associato.

Analogia del quotidiano

Pensa a una ricetta. Si scrive: "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 accumulate 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 playbook è la documentazione. Ed è sempre aggiornata, perché è proprio quello che viene eseguito.

Perché così tanti la scelgono?

  • Agentless: Non installa nulla sui server gestiti. 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: Eseguito 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 laptop o un server dedicato da cui si lancia Ansible), i managed node (i server da configurare), e l'inventario che li collega.

Ansible si connette via SSH ai nodi remoti presenti nell'inventario

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_rsa

inventory.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: i moduli sono 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:

terminal
$ 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=0

Il colore del risultato è tutto:

  • ok significa "già nel giusto stato, nulla da fare"
  • changed significa "modifica apportata"
  • failed è l'unica cosa da temere: 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.

project structure with roles
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.yml

Idempotenza: il concetto più importante

L'idempotenza non è un optional ma è il requisito fondamentale di ogni buon playbook. Significa che eseguire un task una volta o cento volte produce esattamente lo stesso risultato finale.

I moduli Ansible built-in sono progettati per essere idempotenti. Il modulo copy copia il file solo se è diverso. Il modulo package installa solo se non è già presente. Con shell o command la garanzia di idempotenza è a carico di chi scrive il playbook, 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, senza usare credenziali in chiaro.
  • AWX / AAP
    L'interfaccia grafica enterprise per Ansible: scheduling, RBAC, audit log, integrazione CI/CD.
  • Molecule
    Il framework per testare i 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.

Iscriviti a Ansible Automation Blog

Non perdere gli ultimi articoli. Iscriviti ora per essere aggiornato sulle nuove pubblicazioni.
mario@esempio.it
Iscriviti