Capitolo 2 – Architettura e Componenti di Ansible

Dopo aver compreso cos’è Ansible, è fondamentale capire come è strutturato e quali sono i suoi componenti principali.
Una corretta comprensione dell’architettura è essenziale per utilizzarlo in modo professionale in ambienti server.
2.1 Modello Architetturale
Ansible utilizza un modello push-based.
Questo significa che:
Le configurazioni vengono inviate dal nodo di controllo
I server remoti non eseguono processi agent in background
Le operazioni vengono eseguite solo quando richiesto
Questo approccio riduce complessità, consumo risorse e superficie di attacco.
2.2 Control Node
Il Control Node è la macchina su cui è installato Ansible.
Caratteristiche:
Da qui vengono eseguiti comandi e playbook
Deve avere accesso SSH ai nodi gestiti
Contiene inventory, playbook, ruoli e configurazioni
Requisiti:
Linux o macOS (Windows supportato tramite WSL)
Python installato
Accesso SSH verso i nodi remoti
In ambienti enterprise il Control Node può essere:
Una macchina amministrativa
Un server dedicato all’automazione
Un runner CI/CD
2.3 Managed Nodes
I Managed Nodes sono i server che vengono configurati da Ansible.
Requisiti minimi:
SSH attivo
Python installato (preferibilmente Python 3)
Utente con privilegi sudo
Importante:
Non è richiesto alcun agente Ansible installato sul nodo remoto.
Questo è uno dei principali vantaggi rispetto ad altri strumenti di configuration management.
2.4 Inventory
L’Inventory è il file che definisce quali server devono essere gestiti.
Può essere:
Statico (file ini o yaml)
Dinamico (generato tramite script o integrazione cloud)
Esempio concettuale:
Gruppo web
Gruppo database
Variabili specifiche per gruppo o host
L’inventory è il punto di partenza di qualsiasi esecuzione.
2.5 Moduli
I Moduli sono le unità operative di Ansible.
Sono piccoli programmi che:
Installano pacchetti
Gestiscono servizi
Creano utenti
Copiano file
Modificano configurazioni
Quando eseguiamo un comando Ansible:
Il modulo viene copiato temporaneamente sul nodo remoto
Viene eseguito
Restituisce un output JSON
Viene rimosso
Questo processo è trasparente per l’amministratore.
2.6 Playbook
I Playbook sono file YAML che descrivono lo stato desiderato dell’infrastruttura.
Definiscono:
Su quali host operare
Quali task eseguire
In quale ordine
Un playbook può:
Installare pacchetti
Configurare servizi
Applicare template
Riavviare demoni
Rappresentano il cuore dell’automazione con Ansible.
2.7 Idempotenza
Concetto fondamentale in ambito sistemistico.
Un’operazione è idempotente quando:
Può essere eseguita più volte
Produce sempre lo stesso risultato finale
Non genera modifiche se lo stato è già corretto
Esempio:
Se nginx è già installato → nessuna azione
Se non è installato → viene installato
Questo garantisce:
Sicurezza nelle riesecuzioni
Stabilità in produzione
Coerenza infrastrutturale
2.8 Flusso di Esecuzione
Quando si lancia un playbook:
Ansible carica il file di configurazione
Legge l’inventory
Stabilisce connessioni SSH
Esegue i task in ordine
Riporta lo stato finale (ok, changed, failed)
L’output fornisce:
Numero host raggiunti
Task modificati
Eventuali errori
Conclusione
Ansible si basa su un’architettura semplice ma estremamente potente:
Nessun agente
Comunicazione SSH
Stato dichiarativo
Modularità
Comprendere questi elementi è fondamentale prima di passare alla configurazione operativa.
Nel prossimo capitolo entreremo nella configurazione iniziale dell’ambiente di lavoro: inventory, ansible.cfg e struttura progetto.