# 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: 1. Il modulo viene copiato temporaneamente sul nodo remoto 2. Viene eseguito 3. Restituisce un output JSON 4. 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: 1. Ansible carica il file di configurazione 2. Legge l’inventory 3. Stabilisce connessioni SSH 4. Esegue i task in ordine 5. 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.