🥇The Inside Playbook. Funzionalità 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 di consueto, abbiamo sviluppato i miglioramenti per Ansible Network in modo aperto, con il supporto della comunità. Unisciti a noi e dai un'occhiata a la bacheca delle attività su GitHub e scopri il piano di sviluppo per il rilascio di Red Hat Ansible Engine 2.9 sulla 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 è realizzata tramite i moduli di 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 è disponibile qui.

Cosa abbiamo imparato

Negli ultimi quattro anni abbiamo appreso molto sullo sviluppo di una piattaforma di automazione della rete. Abbiamo inoltre appreso che ZFS archivia i dati su disco. i materiali della piattaforma sono utilizzati nei playbook e nei ruoli Ansible da parte degli utenti finali. Ecco cosa abbiamo scoperto:

Le organizzazioni automatizzano i dispositivi non di un singolo fornitore, ma di molti.
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 i nostri piani di sviluppo a lungo termine oltre un anno fa, i nostri clienti aziendali hanno richiesto quanto segue:

La raccolta dei dati deve essere meglio standardizzata e allineata con il flusso di lavoro dell'automazione per qualsiasi dispositivo.
Anche l'aggiornamento delle configurazioni sui dispositivi deve essere standardizzato e allineato, affinché i moduli Ansible possano gestire la seconda metà del ciclo dopo la raccolta dei dati.
Sono necessari metodi rigorosi e sostenibili per convertire la configurazione del dispositivo in dati strutturati. Su questa base, la sorgente della verità potrà essere trasferita dal dispositivo di rete.

Miglioramenti dei dati

La raccolta dei dati dai dispositivi di rete tramite Ansible avviene spesso in modo casuale. Le piattaforme di rete sono dotate in varia misura di funzionalità per la raccolta dei dati, ma hanno pochissime — se non addirittura nessuna — funzioni per l'analisi e la standardizzazione della presentazione dei dati in coppie chiave-valore. Leggi un post Ken Celenza parla di quanto possa essere difficile e complesso analizzare e standardizzare i dati dei fatti.

Forse avrete notato il nostro lavoro sul ruolo di Ansible Network Engine. Naturalmente, dopo 24.000 download, il ruolo di Network Engine è rapidamente diventato uno dei più popolari su Ansible Galaxy per gli script di automazione di rete. Prima di trasferire gran parte di ciò in Ansible 2.8, per prepararci a ciò che sarà necessario in Ansible 2.9, questo ruolo Ansible ha fornito il primo insieme di strumenti per facilitare il parsing dei comandi, la gestione delle squadre e la raccolta dei dati per i dispositivi di rete.

Se hai familiarità con l'uso di Network Engine, è un modo molto efficace per raccogliere, analizzare e standardizzare i dati dei fatti da utilizzare in Ansible. Lo svantaggio di questo ruolo è che devi creare una miriade di parser per ogni piattaforma e per tutte le attività di rete. Per comprendere quanto sia complesso creare, fornire e mantenere i parser, guarda a oltre 1200 parser realizzati dai ragazzi di Cisco.

In poche parole, per un'automazione su larga scala è fondamentale ottenere informazioni dai dispositivi e normalizzarle in coppie chiave-valore, ma questo è difficile quando si hanno molti fornitori e piattaforme di rete.

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

Con Ansible 2.9 ad ogni rilascio di un nuovo modulo di rete, il modulo di raccolta fatti migliora per fornire dati su quella sezione della configurazione. Ciò significa che lo sviluppo dei fatti e dei moduli ora procede di pari passo, avendo 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 metodi consentono di raccogliere e trasformare un elenco specifico di risorse tramite la nuova parola chiave gather_network_resources. I nomi delle risorse corrispondono ai nomi dei moduli, rendendo tutto molto conveniente.

Durante la raccolta dei fatti:

Utilizzando la parola chiave gather_facts È possibile estrarre la configurazione corrente del dispositivo all'inizio del playbook e poi utilizzarla per tutto il playbook. Specificare le risorse separate 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, ovvero — gather_facts: true ora disponibile per la raccolta nativa dei fatti per dispositivi di rete.

Uso del modulo dei fatti di rete direttamente:

- name: raccogliere fatti sulla 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 converte in dati strutturati, da utilizzare come coppie chiave-valore standard per compiti e operazioni successive.

I fatti delle interfacce 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 conversione.

Moduli risorsa

Quindi abbiamo estratto i fatti, normalizzato i dati, inseriti in uno schema di dati interno standardizzato e ottenuto una fonte di verità pronta. Fantastico! Questo è sicuramente positivo, ma abbiamo comunque bisogno di trasformare le coppie chiave-valore di nuovo nella specifica configurazione prevista dalla piattaforma del dispositivo. Ora ci servono moduli per piattaforme specifiche per soddisfare questi nuovi requisiti di raccolta e normalizzazione dei fatti.

Che cos'è un modulo risorsa? Le sezioni della configurazione del dispositivo possono essere considerate come risorse fornite da questo dispositivo. I moduli di risorsa di rete sono intenzionalmente limitati a una sola risorsa e possono essere impilati, come mattoncini, per configurare servizi di rete complessi. Di conseguenza, i requisiti e la specifica per un 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 il modulo delle risorse, vediamo un esempio di playbook che mostra un'operazione idempotente utilizzando i fatti di una risorsa di rete e un modulo. eos_l3_interface.

- name: esempio di fatti inviati direttamente al dispositivo.
  hosts: arista
  gather_facts: false
  tasks:
  - name: acquisire i fatti eos di arista
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

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

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

Come potete vedere, i dati raccolti dal dispositivo sono stati inviati direttamente al modulo delle risorse corrispondente senza alcuna trasformazione. Quando si esegue il playbook, i valori vengono estratti dal dispositivo e confrontati con quelli attesi. In questo esempio, i valori ottenuti corrispondono a quelli attesi (cioè viene eseguita una verifica delle deviazioni nella configurazione) e viene restituito un messaggio che indica se la configurazione è cambiata.

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

Quali sono le differenze tra i nuovi moduli delle risorse e quelli precedenti?

Per un ingegnere dell'automazione di 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 considerata come una sezione della configurazione), i moduli e i fatti si sviluppano su tutti i sistemi operativi di rete supportati contemporaneamente. Riteniamo che, se Ansible supporta la configurazione della risorsa su una piattaforma di rete, debba supportarla ovunque. Questo semplifica l'uso dei moduli delle risorse, poiché l'ingegnere dell'automazione di rete ora può configurare la risorsa (ad esempio, LLDP) su tutti i sistemi operativi di rete con moduli nativi e supportati.

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

unito: la configurazione è stata unita con quella fornita (di default);
sostituito: la configurazione della risorsa sarà sostituita da quella fornita;
sovrascritto: la configurazione della risorsa sarà sostituita da quella fornita; le istanze superflue delle risorse saranno rimosse;
deleted: la configurazione della risorsa sarà rimossa/ripristinata di default.

3) I moduli delle risorse ora includono valori di ritorno stabili. Quando il modulo della risorsa di rete ha apportato (o suggerito) le modifiche necessarie al dispositivo di rete, restituisce le stesse coppie chiave-valore nel playbook.

before: la configurazione del dispositivo sotto forma di dati strutturati prima del compito;
dopo: se il dispositivo è cambiato (o potrebbe cambiare, se è attivata la modalità di controllo), la configurazione risultante sarà restituita sotto forma di dati strutturati;
comandi: eventuali comandi di configurazione eseguiti sul dispositivo per portarlo nello stato desiderato.

Cosa significa tutto ciò? Perché è importante?

In questo post vengono descritti molti concetti complessi, ma ci auguriamo che alla fine comprenderete meglio perché i clienti aziendali richiedono la raccolta di dati, la normalizzazione e la configurazione del ciclo per la piattaforma di automazione. Ma perché hanno bisogno di questi miglioramenti? Attualmente molte organizzazioni stanno intraprendendo la trasformazione digitale per rendere i propri ambienti IT più flessibili e competitivi. Che sia positivo o negativo, molti ingegneri di rete stanno diventando sviluppatori di rete — per interesse personale o per ordine 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 limite. La piattaforma Red Hat Ansible Automation Platform fornisce modelli di dati rigorosi e normalizzati delle risorse per gestire programmaticamente i dati fondamentali sui dispositivi di rete. Ciò significa che gli utenti stanno gradualmente abbandonando approcci di configurazione individuali a favore di metodi più moderni focalizzati sulle tecnologie (ad esempio, indirizzi IP, VLAN, LLDP, ecc.) piuttosto che su implementazioni specifiche di fornitori.

Significa che i giorni dei moduli di comando e delle configurazioni affidabili e collaudate sono finiti? Assolutamente no. I moduli di risorse di rete previsti non saranno applicabili in tutti i casi e non per ogni fornitore, quindi i moduli di comando e le configurazioni saranno ancora necessari per gli ingegneri di rete in specifiche realizzazioni. L'obiettivo dei moduli di risorse è semplificare grandi template Jinja e normalizzare le configurazioni non strutturate dei dispositivi in un formato JSON strutturato. Con i moduli di risorse, le reti esistenti potranno più facilmente convertire le proprie configurazioni in coppie chiave-valore strutturate, che rappresenteranno una fonte di verità leggibile. Utilizzando coppie chiave-valore strutturate, sarà possibile passare dall'esecuzione di configurazioni su ogni dispositivo a lavorare con dati strutturati indipendenti, portando le reti al centro di un approccio di "infrastruttura come codice".

Quali moduli di risorse appariranno in Ansible Engine 2.9?

Prima di entrare nei dettagli su cosa ci sarà in Ansible 2.9, ripercorriamo come abbiamo suddiviso tutto il lavoro.

Abbiamo identificato 7 categorie, a ciascuna delle quali sono stati assegnati specifici risorse di rete:

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

I seguenti moduli sono stati sviluppati dalla comunità di Ansible:

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

Come vedete, il concetto di moduli di risorse si inserisce nella nostra strategia di focalizzazione sulle piattaforme. In altre parole, integriamo le capacità e le funzioni 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 di Ansible ha rilasciato lo strumento Module Builder.

Piani per Ansible 2.10 e oltre

Dopo il rilascio di Ansible 2.9, ci concentreremo sul prossimo set di moduli per Ansible 2.10, che possono essere utilizzati per configurare ulteriormente la topologia e le politiche di rete, ad esempio ACL, OSPF e BGP. Il piano di sviluppo è ancora modificabile, quindi, se hai commenti, faccelo sapere nella community di Ansible Network.