Perché l’automazione entra nel design ENSLD
In un progetto di rete enterprise, la scelta del tool di automazione non è un dettaglio operativo: incide su scalabilità, tempi di provisioning e coerenza della configurazione. L’esame ENSLD chiede di ragionare a livello di design methodology, ovvero quale approccio adottare in funzione dei device coinvolti (router, switch, firewall) e dei vincoli dell’infrastruttura esistente. La discriminante principale è l’architettura del tool: agent-based oppure agentless.
Agent-based vs agentless: il modello architetturale
Un tool agent-based richiede un software residente (agent/daemon) installato sul nodo gestito. L’agent contatta periodicamente un server centrale, scarica il desired state e lo applica localmente. È il modello tipico di Puppet (agent Puppet + Puppet master), Chef (chef-client + Chef server) e, nella modalità classica, SaltStack (Salt minion + Salt master).
Un tool agentless non installa nulla di persistente sul target: si connette on-demand tramite protocolli già presenti (SSH, NETCONF, API REST) ed esegue moduli/task, poi chiude la sessione. È il modello di Ansible, che sfrutta SSH verso i device o le API dei controller.
| Aspetto | Agent-based (Puppet, Chef, Salt) | Agentless (Ansible) |
|---|---|---|
| Software sul device | Sì, daemon residente | No, solo trasporto (SSH/API) |
| Modello prevalente | Pull | Push |
| Linguaggio | DSL / Ruby (Puppet, Chef) | YAML (playbook) |
| Footprint sui device | Elevato | Minimo |
| Prerequisiti | Agent + certificati/keys | SSH/NETCONF raggiungibile |
Push vs pull
Nel modello pull, è il nodo (tramite il suo agent) a “tirare” la configurazione dal master a intervalli regolari e a auto-riconvergere verso lo stato desiderato senza intervento centrale. Questo garantisce drift correction continua: se qualcuno modifica manualmente un device, alla successiva esecuzione l’agent ripristina lo stato definito.
Nel modello push, il control node “spinge” attivamente la configurazione quando l’operatore lo decide (o quando lo lancia una pipeline CI/CD). Il controllo è puntuale e deterministico, ma non c’è riconvergenza automatica tra un run e l’altro. SaltStack merita una nota: pur essendo agent-based, supporta anche un modello push a bassissima latenza tramite il bus di messaggi ZeroMQ, ed esiste Salt SSH (modalità agentless).
Idempotenza: requisito, non optional
Tutti questi tool sono progettati per essere idempotenti: applicare più volte la stessa configurazione produce sempre lo stesso stato finale, senza effetti collaterali o modifiche ripetute. L’idempotenza è ciò che distingue l’automazione dichiarativa da un semplice script che spara comandi. In fase di design va verificato che i moduli usati (es. i moduli ios_config, nxos_* di Ansible) rispettino questa proprietà, evitando che un playbook riscriva la config a ogni esecuzione.
Criteri di scelta nel design
- Scala e footprint sui device: gli apparati di rete (switch, router, firewall) spesso non consentono l’installazione di agent di terze parti sul sistema operativo (IOS/IOS-XE, NX-OS). Questo rende l’approccio agentless la scelta naturale per l’automazione di rete: nessun daemon da gestire, nessun ciclo di patching dell’agent.
- Infrastruttura esistente: in ambienti già consolidati su Puppet/Chef per la gestione di server Linux, può avere senso estendere quel tool anche dove possibile, per riuso di competenze e pipeline.
- Curva di apprendimento: la sintassi YAML di Ansible abbassa la barriera d’ingresso rispetto ai DSL di Puppet o al Ruby di Chef.
- Riconvergenza continua vs controllo puntuale: se serve enforcement costante dello stato, il modello pull è più adatto; se serve orchestrazione controllata e integrazione CI/CD, il push agentless è preferibile.
Nel contesto ENSLD, la raccomandazione ricorrente per il campus e la WAN enterprise è l’approccio agentless con footprint minimo, tipicamente Ansible verso device via SSH/NETCONF o verso controller (Cisco DNA Center / Catalyst Center) via API REST.
Trappole tipiche d’esame
- “Automazione di switch/router senza installare software sui device” → risposta giusta: soluzione agentless (Ansible); gli apparati di rete non ospitano agent di terze parti.
- “Configurazione che si auto-corregge periodicamente senza intervento manuale” → è il modello pull agent-based (Puppet/Chef), non il push di Ansible.
- Confondere Ansible con un tool pull: Ansible è push/agentless — attenzione a distrattori che lo descrivono come agent-based.
- “Server esce dallo stato desiderato tra un run e l’altro”: con il push non c’è riconvergenza automatica; serve un modello pull o uno scheduler esterno.
- Idempotenza attribuita al solo Ansible: è una proprietà di design comune a Puppet, Chef, SaltStack e Ansible — non un fattore discriminante tra agent e agentless.