Capitolo 2

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.