Automazione di rete con Ansible: playbook per configurazione degli switch, backup e rollback

L’automazione di rete con Ansible è per molti team IT la chiave per rendere riproducibili e auditabili le modifiche ricorrenti agli switch, i backup regolari delle configurazioni e le operazioni di rollback controllate. Questo howto pratico è rivolto ad amministratori, ingegneri di sistema e operatori e spiega passo per passo prerequisiti, insidie tipiche, esempi concreti di Playbook e strategie sicure di verifica e ripristino.

Perché l’automazione di rete? Obiettivi e termini in breve

L’automazione di rete riduce errori manuali, accelera i rollout e migliora la tracciabilità. In questo articolo utilizziamo Ansible come strumento di orchestrazione. Ansible è uno strumento di automazione senza agenti: il nodo di controllo (Ansible‑Control‑Node) si connette via SSH o tramite plugin di connessione di rete specifici ai dispositivi ed esegue attività dichiarative (Playbooks).

Termini importanti in una frase: Playbook (file YAML con attività), Inventory (elenco dispositivi), Connection Plugins (es. network_cli per switch), idempotenza (ripetibilità senza effetti collaterali) e rollback (ripristino di una configurazione precedente).

Panoramica dei requisiti operativi

• Nodo di controllo: Ansible 2.15+ o una moderna versione 2.x; Python e le Collections necessarie (es. ansible.netcommon, community.general, eventualmente vendor‑Collections come cisco.ios).
• Accesso: accesso SSH con permessi sufficienti (opzionale password enable/privilege). I dispositivi di rete devono essere raggiungibili dal Control‑Node.
• Inventario: Inventories puliti e group_vars per le credenziali; gestire i secret tramite Ansible Vault o un Secrets‑Backend (es. HashiCorp Vault).
• Ambiente di test: lab o staging con uno o pochi dispositivi per verificare i Playbooks prima dell’introduzione in produzione.

Automazione di rete con Ansible: struttura di Inventory di base

Un inventory chiaro è la base. Qui un semplice esempio INI che molti team usano ancora:

[switches]
sw-core-01 ansible_host=10.0.1.10 ansible_network_os=ios
sw-access-01 ansible_host=10.0.1.20 ansible_network_os=ios

[all:vars]
ansible_user=netadmin
ansible_connection=network_cli
ansible_become=yes
ansible_become_method=enable

Spiegazione: ansible_network_os aiuta Ansible a scegliere il modulo/gestione del prompt appropriato; network_cli è il Connection‑Plugin per switch basati su CLI. Prioritariamente i dati sensibili (password, chiavi SSH) non dovrebbero essere nell’Inventory, ma gestiti tramite Vault o Ansible‑Credential‑Management.

Playbook: raccogliere il backup della configurazione

I backup sono la componente più sottovalutata. Qui un Playbook robusto che recupera la configurazione in esecuzione e la archivia localmente sul Control‑Node. Utilizza il modulo generico ansible.netcommon.cli_command (funziona con molti fornitori) e salva l’output tramite un’azione locale.

---
- name: Collect running-config backups from switches
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Get running configuration
      ansible.netcommon.cli_command:
        command: show running-config
      register: running_cfg

    - name: Ensure backup directory exists on control node
      local_action:
        module: file
        path: "backups/{{ inventory_hostname }}"
        state: directory
        mode: '0750'

    - name: Save running configuration to control node
      local_action:
        module: copy
        content: "{{ running_cfg.stdout[0] | default('') }}n"
        dest: "backups/{{ inventory_hostname }}/{{ inventory_hostname }}-{{ ansible_date_time.iso8601_basic }}.cfg"
        mode: '0640'

Perché così? Il playbook separa i dati del dispositivo (recuperati via SSH) e la conservazione del backup (sul nodo di controllo locale). Questo semplifica la verifica, il controllo delle versioni e l’archiviazione sicura. Prestate attenzione al formato del timestamp (ISO8601) e ai permessi sicuri dei file.

Verificare prima di iniziare

• Verificare l’accesso di test: eseguire un semplice comando ad hoc:

ansible switches -m ansible.netcommon.cli_command -a "command='show version'" -i inventory.ini

Se ciò fallisce, verificare: versione di Ansible, plugin di connessione, accesso alla rete, credenziali e rilevamento del prompt (timeout, password ‚enable‘).

Playbook: modifica della configurazione (Push) con Diff e Check‑Mode

Per i playbook di modifica è consigliabile utilizzare approcci modulare e il più idempotenti possibile. Molte collection dei vendor (es. cisco.ios.ios_config) implementano logiche idempotenti. Se ciò non è possibile, utilizzate cli_config con –check o le opzioni diff.

---
- name: Deploy interface description to access switches
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Apply interface configuration lines
      ansible.netcommon.cli_config:
        lines:
          - interface GigabitEthernet1/0/48
          - description "PRD: uplink to router"
          - switchport mode access
          - switchport access vlan 100
      register: cfg_result

    - name: Show diff when changed
      debug:
        var: cfg_result.diff

Eseguire le operazioni prima su un singolo gruppo di dispositivi di test, poi a lotti. Durante i test usate ansible-playbook --check --diff per ridurre i rischi; tenete presente che non tutti i moduli di rete supportano pienamente il Check‑Mode.

Strategie di rollback: tipologie e implementazione

Il rollback non è un’operazione one‑click valida per tutti i dispositivi. Ci sono tre approcci pragmatici:

1. Ripristino nativo del vendor (consigliato): usare le funzioni del dispositivo come configure replace (supportato da molti Cisco IOS‑XEs) o i rollback di Junos. Sono spesso atomici e riducono transizioni incoerenti.
2. Push dell’ultimo backup noto buono: caricare il file di backup e inviarlo riga per riga con cli_config. È più ampiamente applicabile, ma può generare stati intermedi incoerenti.
3. Confronto delle configurazioni e revert selettivo: identificare solo le righe modificate e applicare correzioni selettive. Più laborioso, ma meno rischioso in ambienti eterogenei.

Esempio: rollback semplice (Push del file salvato)

---
- name: Rollback config by pushing saved file content
  hosts: switches
  gather_facts: no
  connection: network_cli
  vars:
    rollback_file: "backups/{{ inventory_hostname }}/{{ inventory_hostname }}-20260728T120000Z.cfg"
  tasks:
    - name: Read rollback file on control node
      local_action:
        module: slurp
        src: "{{ rollback_file }}"
      register: rollback_raw

    - name: Decode rollback content
      set_fact:
        rollback_text: "{{ rollback_raw.content | b64decode }}"

    - name: Apply rollback configuration via CLI
      ansible.netcommon.cli_config:
        lines: "{{ rollback_text.split('n') }}"
      register: rb_result

    - name: Debug apply result
      debug:
        var: rb_result

Attenzione: questo metodo sovrascrive praticamente tutte le righe. Testatelo in un ambiente di laboratorio. I problemi sorgono se il backup salvato contiene comandi di console proprietari, stati temporanei delle interfacce o voci non persistenti.

Regole operative sicure e checklist prima delle modifiche

Prima di ogni modifica, le seguenti verifiche dovrebbero essere automatizzate o documentate:

• Backup disponibile e testato (vedi Playbook).
• Change‑Window definito e stakeholder informati.
• Esecuzione di un test in Check‑Mode o su uno Staging‑Device.
• Serialità: distribuire le modifiche in piccoli lotti (serial: 1–5 in Ansible) per evitare guasti di massa.
• Validazione: dopo la modifica eseguire controlli automatizzati (Ping, BGP‑Neighbors, VLAN‑Membership).
• Rollback‑Playbook a portata di mano e procedura di RESTore testata disponibile.

Problemi tipici e come risolverli

1) Problemi di autenticazione e di prompt

Sintomi: timeout, prompt inattesi, mancanza dei diritti di enable. Cause: ansible_connection errato, mancata escalation dei privilegi, stringhe di prompt diverse. Soluzione: configurare group_vars per ansible_become, ansible_become_password o usare chiavi SSH e un test ad‑hoc di verifica con show version. Se necessario, configurare i parametri di timeout e verificare le stringhe di prompt interattive in ansible.cfg.

2) Mancata idempotenza

Se si usano comandi CLI grezzi, le azioni spesso non sono idempotenti (modifiche ad ogni esecuzione). Meglio: moduli di configurazione specifici del vendor (es. cisco.ios.ios_config) che eseguono il confronto dello stato. Se ciò non fosse possibile, implementare logiche di confronto personalizzate (diff prima/dopo, hash).

3) La parallelità può causare interruzioni di rete

Cambi massivi simultanei possono violare dipendenze (es. STP, LACP). In Ansible, utilizzare serial nei Play o esecuzioni per ruolo tramite tag. Esempio:

- hosts: switches
  serial: 3
  tasks:
    - name: Apply change
      ...

4) Backup incompleti

Alcuni dispositivi forniscono solo parti della configurazione o richiedono comandi speciali per la persistenza. Verificare i backup regolarmente tramite test di RESTore automatizzati in laboratorio.

Validazione e monitoring dopo la modifica

Le verifiche automatiche sono obbligatorie. Esempi di controlli che dovrebbero essere eseguiti immediatamente dopo una modifica:

• Raggiungibilità ICMP per i percorsi critici.
• Stato dei neighbor (BGP/OSPF) per i router adiacenti.
• Controllo VLAN e stato delle porte per le porte di accesso interessate.
• Monitorare metriche SNMP/Telemetry (latenza, error‑rate) — le anomalie indicano potenziali problemi.

Un piccolo esempio di come implementare un controllo post‑change come Playbook:

---
- name: Post-change validation
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Check interface up status
      ansible.netcommon.cli_command:
        command: show interfaces status
      register: intf_status

    - name: Fail if critical port is down
      fail:
        msg: "Critical interface down on {{ inventory_hostname }}"
      when: "'Gi1/0/48' in intf_status.stdout[0] and 'notconnect' in intf_status.stdout[0]"

Audit, Archivierung und Retention

I backup dovrebbero essere versionati, verificati e archiviati. Si consiglia un approccio con repository Git per i backup di testo (solo per i file di configurazione) combinato con object storage per l’archivio a lungo termine (es. S3). Verificare i seguenti punti:

• Integrität: controlli hash periodici.
• Retention‑Policy: definire i periodi di conservazione legali/contrattuali.
• Zugriffskontrolle: chi può avviare un ripristino? (controlli basati sui ruoli)

Praxisbeispiel: Minimaler Workflow für einen Change

1. Aggiornare il playbook nel repository, aprire un Merge Request con review.
2. Eseguire un dry‑run (–check) sullo switch di staging.
3. Creare un backup automatico prima della modifica.
4. Distribuire la modifica in piccoli batch con monitoraggio in tempo reale.
5. Eseguire automaticamente i post‑check; in caso di errori attivare automaticamente il rollback.

Troubleshooting: Wichtige Prüfsequenz

1. Test di connessione: attività ad hoc come sopra (show version).
2. Controllare i log: la modalità verbose di Ansible -vvv mostra il dialogo SSH e il riconoscimento del prompt.
3. Problemi di prompt/expect: verificare che il prompt del modulo (ansible_network_os) sia impostato correttamente.
4. Timeout: aumentare ansible_connection_timeout in group_vars se necessario.
5. Testare il rollback in anticipo: eseguire un ripristino in un ambiente isolato.

Netzwerkautomation mit Ansible: CI/CD, Secrets und Telemetrie integrieren

L’integrazione nelle pipeline CI/CD rende le modifiche tracciabili e soggette ad audit. Un tipico flusso è: Merge Request → lint/unit test automatico dei playbook → dry‑run in laboratorio → fase di approvazione → rollout sequenziale. Per la gestione dei segreti, utilizzare Ansible Vault o un sistema di secret dedicato (es. HashiCorp Vault). Vault consente credenziali dinamiche e riduce il rischio di password a lunga durata.

La telemetria (es. gNMI, streaming telemetry, SNMP Traps) integra l’automazione con metriche in tempo reale. Dopo una modifica gli alert di telemetria dovrebbero essere automaticamente collegati al contesto del change (Change‑ID, Run‑ID) — in questo modo si può stabilire se un allarme è stato causato dalla modifica.

Beispiel: CI‑Step, der ein Playbook im Check‑Mode ausführt

#!/bin/bash
# CI step: run playbook in check mode and fail on changes
ansible-playbook -i inventory.ini change_playbook.yml --check --diff
if [ $? -ne 0 ]; then
  echo "Check mode failed or would change devices" >&2
  exit 1
fi

Atomicere Rollbacks: Vendor‑native Replace

Se la vostra piattaforma supporta configure replace o una procedura equivalente di replace atomico, usatela. Questo riduce il rischio di stati intermedi. Esempio per Cisco IOS‑XEs con un modulo vendor (esempio concettuale):

---
- name: Atomic replace from candidate file (vendor-specific)
  hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Replace running-config atomically
      cisco.ios.ios_config:
        src: "backups/{{ inventory_hostname }}/candidate.cfg"
        replace: yes
        save_when: modified

Nota: i parametri hanno nomi diversi a seconda della vendor‑Collection. Verifichi la documentazione della sua vendor‑Collection e testi intensivamente la procedura in un ambiente di laboratorio.

Monitoraggio: liste di controllo, conoscenze operative e best practice

Per un funzionamento sostenibile sono decisivi i meccanismi di monitoraggio e verifica. Raccomandazioni:

• Test di RESTore automatizzati almeno ogni trimestre in un ambiente isolato.
• Controlli di differenza dopo ogni backup: generare un hash (p. es. SHA256) e salvarlo come metadati.
• Allegare il Change‑Context al monitoring: Run‑ID, Commit‑Hash, operatore, numero del ticket.
• Alert‑Playbooks: in caso di allarmi critici rollback automatico o trigger di escalation secondo la policy.

Esempio: generazione dell’hash e salvataggio dei metadati dopo il backup:

sha256sum backups/sw-core-01/sw-core-01-20260728T120000Z.cfg > backups/sw-core-01/metadata.txt
echo "commit: $GIT_COMMIT" >> backups/sw-core-01/metadata.txt
echo "run_id: $CI_RUN_ID" >> backups/sw-core-01/metadata.txt

Runbook di emergenza: ripristino manuale e accesso OOB

Se il rollback automatico fallisce, è necessario un runbook chiaro. Sintesi:

1. Verificare la console OOB (Console‑Server, IPMI/Redfish) — garantisce l’accesso quando la rete non è raggiungibile.
2. Identificare l’ultimo backup integro (verificare i metadati: Timestamp, SW‑Version).
3. Caricare il rollback localmente sulla console o applicarlo via TFTP/USB.
4. Controlli di base: interfacce up, Routing/Neighbors, ACL critiche.
5. Controlli post-operazione dettagliati e chiusura del ticket dopo conferma del successo.

Conclusione: consigli pratici per la gestione operativa

L’automazione di rete con Ansible fornisce trasparenza e velocità — a condizione che si investa nell’igiene dell’inventario, nella disciplina dei backup, in procedure di rollback testate e in una strategia di introduzione graduale. Utilizzi moduli specifici del vendor dove opportuno, automatizzi gli script di validazione e mantenga regole rigorose di accesso e retention. Su dispositivi eterogenei, strategie pragmatiche di backup e rollback selettivo sono la scelta più sicura.

Punto di partenza concreto: crei un backup‑Playbook come sopra, lo testi su uno switch di staging e poi estenda passo dopo passo i suoi Change‑Playbooks con Check‑Mode, output diff e roll‑out serializzati. Integre ciò con CI/CD, integrazione della telemetry e test di RESTore regolari per ridurre in modo duraturo i rischi operativi.

Per questo tema sono importanti anche gli Ansible Playbooks e le configurazioni degli switch. L’articolo contestualizza questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.