🥇The Inside Playbook. Funzioni di rete nel nuovo Ansible Engine 2.9

Nel prossimo rilascio di Red Hat Ansible Engine 2.9 troverai miglioramenti impressionanti, alcuni dei quali sono descritti in questo articolo. Come al solito, abbiamo sviluppato i miglioramenti di Ansible Network in modo aperto, con il supporto della comunità. Unisciti a noi — dai un'occhiata a la bacheca dei progetti su GitHub ed esplora il piano di sviluppo per il rilascio di Red Hat Ansible Engine 2.9 nella pagina wiki per Ansible Network.

Come abbiamo recentemente annunciato, Red Hat Ansible Automation Platform ora include Ansible Tower, Ansible Engine e tutto il contenuto di Ansible Network. Attualmente, la maggior parte delle piattaforme di rete più popolari è implementata tramite i moduli Ansible. Ad esempio:

Arista EOS
Cisco IOS
Cisco IOS XR
Cisco NX-OS
Juniper Junos
VyOS

L'elenco completo delle piattaforme completamente supportate da Red Hat tramite l'abbonamento Ansible Automation è pubblicato qui.

Cosa abbiamo imparato

Negli ultimi quattro anni abbiamo imparato molto sullo sviluppo di una piattaforma per l'automazione della rete. Abbiamo anche appreso che come gli artefatti della piattaforma vengono utilizzati nei playbook e nei ruoli di Ansible da parte degli utenti finali. Ecco cosa abbiamo scoperto:

Le organizzazioni automatizzano i dispositivi non di un singolo, ma di molti fornitori.
L'automazione è un fenomeno non solo tecnico, ma anche culturale.
L'automazione su larga scala delle reti è più complessa di quanto sembri, a causa dei principi architettonici fondamentali del design dell'automazione.

Quando abbiamo discusso dei nostri piani di sviluppo a lungo termine più di un anno fa, i nostri clienti aziendali hanno richiesto quanto segue:

La raccolta dei fatti deve essere meglio standardizzata e allineata con il flusso di lavoro di automazione per qualsiasi dispositivo.
Anche l'aggiornamento delle configurazioni sui dispositivi deve essere standardizzato e allineato, in modo che i moduli Ansible possano gestire la seconda metà del ciclo dopo la raccolta dei fatti.
Sono necessari metodi rigorosi e supportati per trasformare la configurazione del dispositivo in dati strutturati. Su questa base, la fonte di verità può essere spostata dal dispositivo di rete.

Miglioramenti dei fatti

La raccolta dei fatti dai dispositivi di rete tramite Ansible avviene spesso in modo casuale. Le piattaforme di rete sono dotate di capacità di raccolta dei fatti in varia misura, ma hanno quasi nessuna — o addirittura nessuna — funzionalità per analizzare e standardizzare la rappresentazione dei dati in coppie chiave-valore. Leggi post Ken Celenza su quanto possa essere difficile e doloroso analizzare e standardizzare i dati dei fatti.

Potreste aver notato come abbiamo lavorato sul ruolo Ansible Network Engine. Naturalmente, dopo 24.000 download, il ruolo Network Engine è rapidamente diventato uno dei ruoli più popolari di Ansible in Ansible Galaxy per gli script di automazione della rete. Prima di trasferire gran parte di questo in Ansible 2.8, per prepararci a ciò che sarà necessario in Ansible 2.9, questo ruolo Ansible ha fornito il primo set di strumenti per aiutare nell'analisi dei comandi, nella gestione dei team e nella raccolta di dati per i dispositivi di rete.

Se sei esperto nell'uso del Network Engine, è un modo molto efficace per raccogliere, analizzare e standardizzare i dati di fatto da utilizzare in Ansible. Uno svantaggio di questo ruolo è che devi creare un sacco di parser per ogni piattaforma e per tutta l'attività di rete. Per capire quanto sia complesso creare, fornire e mantenere i parser, guarda a oltre 1200 parser dai ragazzi di Cisco.

In poche parole, per l'automazione su larga scala, è fondamentale ottenere fatti dai dispositivi e normalizzarli in coppie chiave-valore, ma questo è difficile da raggiungere quando hai molti fornitori e piattaforme di rete.

Ogni modulo di fatto di rete in Ansible 2.9 può ora analizzare la configurazione di un dispositivo di rete e restituire dati strutturati, senza librerie aggiuntive, ruoli Ansible o parser personalizzati.

A partire da Ansible 2.9, ad ogni rilascio di un modulo di rete aggiornato, il modulo di fatto viene migliorato per fornire dati su questa sezione della configurazione. Ciò significa che lo sviluppo di fatti e moduli ora avviene con un ritmo uniforme e avranno sempre una struttura dati comune.

La configurazione delle risorse su un dispositivo di rete può essere estratta e trasformata in dati strutturati in due modi. Entrambi i modi possono raccogliere e trasformare un elenco specifico di risorse utilizzando la nuova parola chiave gather_network_resources. I nomi delle risorse corrispondono ai nomi dei moduli, ed è molto comodo.

Durante la raccolta dei fatti:

Utilizzando la parola chiave gather_facts puoi estrarre la configurazione attuale del dispositivo all'inizio del playbook e poi utilizzarla per tutto il playbook. Specifica le singole risorse da estrarre dal dispositivo.

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

Potresti aver notato qualcosa di nuovo in questi esempi, cioè — gather_facts: true ora disponibile per la raccolta nativa di fatti per i dispositivi di rete.

Utilizzo del modulo di raccolta dei fatti di rete direttamente:

- name: raccogliere fatti di configurazione dell'interfaccia
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Il playbook restituisce i seguenti fatti sull'interfaccia:

ansible_facts:
   ansible_network_resources:
      interfaces:
      - enabled: true
        name: Ethernet1
        mtu: '1476'
      - enabled: true
        name: Loopback0
      - enabled: true
        name: Loopback1
      - enabled: true
        mtu: '1476'
        name: Tunnel0
      - enabled: true
        name: Ethernet1
      - enabled: true
        name: Tunnel1
      - enabled: true
        name: Ethernet1

Nota come Ansible estrae la configurazione nativa dal dispositivo Arista e la trasforma in dati strutturati, utilizzabili come coppie chiave-valore standard per attività e operazioni successive.

I fatti dell'interfaccia possono essere aggiunti alle variabili memorizzate di Ansible e utilizzati immediatamente o successivamente come input per il modulo risorsa eos_interfaces senza ulteriore elaborazione o trasformazione.

Moduli risorsa

Quindi, abbiamo estratto i fatti, normalizzato i dati, inseriti in uno schema di struttura dati internamente standardizzato e ottenuto una fonte di verità pronta. Evviva! Questo è fantastico, ma abbiamo comunque bisogno di convertire le coppie chiave-valore di nuovo nella configurazione specifica che si aspetta una piattaforma specifica del dispositivo. Ora abbiamo bisogno di moduli per piattaforme specifiche per soddisfare questi nuovi requisiti di raccolta di fatti e normalizzazione.

Cos'è un modulo risorsa? Le sezioni di configurazione del dispositivo possono essere viste come risorse fornite da questo dispositivo. I moduli di risorse di rete sono deliberatamente limitati a una sola risorsa e possono essere impilati, come mattoncini, per configurare servizi di rete complessi. Di conseguenza, i requisiti e le specifiche per il modulo risorsa si semplificano naturalmente, poiché il modulo risorsa può leggere e configurare un servizio di rete specifico su un dispositivo di rete.

Per spiegare cosa fa un modulo risorsa, diamo un'occhiata a un esempio di playbook che mostra un'operazione idempotente utilizzando i nuovi fatti delle risorse di rete e il modulo eos_l3_interface.

- nome: esempio di fatti trasferiti direttamente al dispositivo.
  hosts: arista
  gather_facts: false
  tasks:
  - nome: raccogliere fatti eos di arista
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - nome: assicurarsi che le informazioni sull'indirizzo IP siano accurate
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - nome: assicurarsi che la configurazione non sia cambiata
    assert:
      that: not result.changed

Come puoi vedere, i dati raccolti dal dispositivo vengono trasferiti direttamente al modulo delle risorse senza alcuna trasformazione. Quando viene eseguito il playbook, estrae i valori dal dispositivo e li confronta con quelli attesi. In questo esempio, i valori ottenuti corrispondono a quelli attesi (cioè viene eseguito un controllo delle deviazioni di configurazione) ed è emesso un messaggio che indica se la configurazione è cambiata.

Il modo ideale per rilevare una deviazione di configurazione è quello di memorizzare i fatti in variabili persistenti Ansible e utilizzarli periodicamente insieme al modulo delle risorse in modalità di verifica. Questo è un metodo semplice per vedere se qualcuno ha modificato i valori manualmente. Nella maggior parte dei casi, le organizzazioni consentono modifiche e configurazioni manuali, anche se molte operazioni vengono eseguite tramite Ansible Automation.

Cosa distingue i nuovi moduli delle risorse da quelli precedenti?

Per un ingegnere di automazione della rete, ci sono 3 principali differenze tra i moduli delle risorse in Ansible 2.9 e le versioni precedenti.

1) Per una specifica risorsa di rete (che può anche essere vista come una sezione di configurazione), i moduli e i fatti si svilupperanno simultaneamente su tutti i sistemi operativi di rete supportati. Riteniamo che, se Ansible supporta la configurazione di una risorsa su una piattaforma di rete, essa dovrebbe essere supportata ovunque. Questo semplifica l'uso dei moduli delle risorse, poiché ora un ingegnere di automazione della rete può configurare una risorsa (come LLDP) su tutti i sistemi operativi di rete con moduli nativi e supportati.

2) I moduli delle risorse ora includono uno stato di valore.

unito: la configurazione è stata unita alla configurazione fornita (di default);
sostituito: la configurazione della risorsa sarà sostituita dalla configurazione fornita;
sopravraso: la configurazione della risorsa sarà sostituita dalla configurazione fornita; gli istanze superflue delle risorse saranno rimosse;
deleted: la configurazione della risorsa sarà rimossa/recuperata per impostazione predefinita.

3) I moduli delle risorse ora includono valori di ritorno stabili. Quando un modulo della risorsa di rete apporta (o propone) le necessarie modifiche a un dispositivo di rete, restituisce le stesse coppie chiave-valore nel playbook.

before: configurazione sul dispositivo sotto forma di dati strutturati prima dell'attività;
dopo: se il dispositivo è cambiato (o può cambiare, se è attivata la modalità di verifica), la configurazione risultante verrà restituita sotto forma di dati strutturati;
comandi: qualsiasi comando di configurazione eseguito sul dispositivo per portarlo nello stato desiderato.

Cosa significa tutto questo? Perché è importante?

Questo post descrive molti concetti complessi, ma speriamo che alla fine comprenderai meglio perché i clienti aziendali richiedono la raccolta di fatti, la normalizzazione dei dati e la configurazione del ciclo per la piattaforma di automazione. Ma perché hanno bisogno di questi miglioramenti? Attualmente molte organizzazioni stanno affrontando una trasformazione digitale per rendere i propri ambienti IT più agili e competitivi. Che sia buono o cattivo, molti ingegneri di rete stanno diventando sviluppatori di rete, per interesse personale o su richiesta dei dirigenti.

Le organizzazioni comprendono che l'automazione di singoli modelli di rete non risolve il problema della frammentazione e migliora l'efficienza solo fino a un certo punto. La piattaforma Red Hat Ansible Automation Platform fornisce modelli di dati rigorosi e normativi delle risorse per gestire programmaticamente i dati di base su un dispositivo di rete. Ciò significa che gli utenti stanno gradualmente abbandonando i metodi di configurazione individuale a favore di metodi più moderni con un focus sulle tecnologie (ad esempio indirizzi IP, VLAN, LLDP, ecc.), piuttosto che su implementazioni specifiche del fornitore.

Significa che i giorni dei moduli di comando e delle configurazioni affidabili e testate sono contati? Certamente no. I moduli di risorse previsti non saranno applicabili in tutti i casi e non per ogni fornitore, quindi i moduli di command e le configurazioni saranno ancora necessari per gli ingegneri di rete in determinate implementazioni. L'obiettivo dei moduli di risorse è semplificare i grandi modelli Jinja e normalizzare le configurazioni dei dispositivi non strutturate in un formato JSON strutturato. Con i moduli di risorse, alle reti esistenti sarà più facile trasformare la propria configurazione in coppie chiave-valore strutturate, che costituiranno una fonte di verità leggibile. Utilizzando coppie chiave-valore strutturate, si può passare dall'esecuzione delle configurazioni su ogni dispositivo al lavoro con dati strutturati indipendenti, spostando le reti al centro dell'approccio 'infrastruttura come codice'.

Quali moduli di risorse verranno introdotti in Ansible Engine 2.9?

Prima di entrare nei dettagli su cosa ci sarà in Ansible 2.9, ricordiamo come abbiamo suddiviso l'intero carico di lavoro.

Abbiamo identificato 7 categorie e assegnato a ciascuna specifiche risorse di rete:

Nota: le risorse evidenziate in grassetto erano pianificate e implementate in Ansible 2.9.
Sulla base dei feedback dei clienti aziendali e della comunità, è stato logico iniziare con quei moduli legati ai protocolli di topologia di rete, alla virtualizzazione e alle interfacce.
I seguenti moduli di risorse sono stati sviluppati dal team Ansible Network e corrispondono alle piattaforme supportate da Red Hat:

I seguenti moduli sono stati sviluppati dalla comunità Ansible:

exos_lldp_global — di Extreme Networks.
nxos_bfd_interfaces — di Cisco
nxos_telemetry — di Cisco

Come puoi vedere, il concetto di moduli di risorse si integra nella nostra strategia di orientamento alle piattaforme. Cioè, includiamo le funzionalità e le capacità necessarie direttamente in Ansible, per supportare la standardizzazione nello sviluppo dei moduli di rete e semplificare il lavoro degli utenti a livello di ruoli e playbook Ansible. Per espandere lo sviluppo dei moduli di risorse, il team Ansible ha rilasciato uno strumento Module Builder.

Piani per Ansible 2.10 e oltre

Dopo il rilascio di Ansible 2.9, ci concentremo sul successivo set di moduli di risorse per Ansible 2.10, che potranno essere utilizzati per ulteriori configurazioni della topologia e delle politiche di rete, ad esempio ACL, OSPF e BGP. È ancora possibile modificare il piano di sviluppo, quindi, se hai commenti, faccelo sapere nella comunità Ansible Network.