Strumenti di orchestrazione e config management

Perché serve un tool di configuration management

In una rete enterprise con centinaia di dispositivi, configurare a mano ogni switch e router porta a config drift (divergenza fra lo stato reale e quello desiderato), errori umani e lentezza. I tool di configuration management risolvono il problema descrivendo lo stato desiderato in modo dichiarativo e idempotente: applicare due volte la stessa policy non cambia nulla se il dispositivo è già conforme. Per l’esame ENCOR devi saper classificare ciascun tool lungo due assi ortogonali: agent-based vs agentless e push vs pull.

Agent-based vs agentless

• Agent-based: sul nodo gestito gira un software residente (un daemon) che comunica con il server centrale. Richiede installazione e manutenzione dell’agent. Appartengono a questa famiglia Puppet, Chef e SaltStack (con i suoi minion).
• Agentless: nessun software permanente sul nodo. Il controllo avviene tramite protocolli già presenti — SSH, oppure API/NETCONF sui dispositivi di rete. Il capostipite è Ansible.

Push vs pull

• Pull: l’agent sul nodo, a intervalli regolari, chiede al server la configurazione da applicare. Tipico di Puppet e Chef.
• Push: il server (o control node) invia attivamente la configurazione al momento voluto dall’operatore. Tipico di Ansible e, in modalità standard, di SaltStack.

Confronto dei quattro tool

SaltStack è il caso più insidioso: usa i minion (quindi agent-based) e comunica via un message bus persistente che lo rende molto veloce su larga scala, ma può funzionare anche senza minion tramite salt-ssh. Non incasellarlo in modo rigido.

Ansible in dettaglio (il più probabile all’esame)

Ansible è agentless e push. Il control node legge un inventory (l’elenco dei dispositivi) ed esegue playbook in YAML che invocano moduli idempotenti. Sui server Linux usa SSH e Python; sui dispositivi di rete Cisco (IOS-XE, NX-OS) usa moduli specifici che parlano via CLI su SSH oppure via NETCONF/RESTCONF. Punto cruciale: non esiste alcun daemon Ansible sempre attivo. Il “master server” si materializza solo quando lanci il playbook e sparisce a fine esecuzione — non serve un processo in ascolto permanente né sui nodi né sul controller. Questo lo rende leggero e ideale per l’onboarding rapido.

Dove si colloca Cisco DNA Center

Cisco DNA Center non è un semplice tool di configuration management: è un controller intent-based per il campus enterprise, che orchestra provisioning, SWIM (Software Image Management), template (Jinja2/Velocity nel Template Editor) e Assurance. Espone una northbound REST API (Intent API) verso applicazioni e sistemi esterni (ITSM, IPAM), e verso i device agisce con NETCONF, SNMP e CLI. Rispetto ai tool generalisti:

• Ansible/Puppet possono integrarsi con DNA Center chiamandone la REST API, invece di configurare i device direttamente.
• DNA Center aggiunge un livello di astrazione dell’intento (dico cosa voglio, non come) e di telemetria/assurance che i tool tradizionali non hanno.

Trappole tipiche d’esame

• Scenario: la domanda chiede se Ansible sia agent-based → Risposta giusta: NO. Ansible è agentless, usa SSH o API, e opera in push. Chi lo classifica come agent-based sbaglia.
• Scenario: “quale tool NON richiede un master server sempre in esecuzione?” → Risposta giusta: Ansible. Non tutti i tool hanno un daemon persistente; Ansible gira on-demand dal control node.
• Scenario: distinguere push da pull per Puppet/Chef → Risposta giusta: entrambi sono pull (l’agent scarica la config dal server), mentre Ansible e SaltStack sono push.
• Scenario: SaltStack classificato solo come agentless → Risposta giusta: è agent-based con i minion; l’opzione salt-ssh è una variante agentless, non la modalità principale.
• Scenario: DNA Center trattato come “l’ennesimo Puppet” → Risposta giusta: è un controller intent-based con REST API e Assurance, un livello di orchestrazione superiore, non un semplice config manager.