L'imminente rilascio di Red Hat Ansible Engine 2.9 apporta interessanti miglioramenti, alcuni dei quali vengono discussi in questo articolo. Come sempre, abbiamo sviluppato apertamente i miglioramenti di Ansible Network, con il supporto della community. Unisciti a noi: dai un'occhiata e studiare il piano di sviluppo per nella pagina wiki per .
Come abbiamo recentemente annunciato, ora include Ansible Tower, Ansible Engine e tutti i contenuti della rete Ansible. Al giorno d'oggi, le piattaforme di rete più popolari sono implementate tramite moduli Ansible. Per esempio:
- AristaEOS
- Cisco IOS
- Cisco IOS XR
- Sistema operativo Cisco NX
- Ginepro Giunone
- VOS
Per un elenco completo delle piattaforme completamente supportate da Red Hat tramite l'abbonamento ad Ansible Automation, .
Cosa abbiamo imparato
Negli ultimi quattro anni abbiamo imparato molto sullo sviluppo di una piattaforma di automazione della rete. Abbiamo imparato anche questo come gli artefatti della piattaforma vengono utilizzati nei playbook e nei ruoli Ansible dagli utenti finali. Ed ecco cosa abbiamo scoperto:
- Le organizzazioni stanno automatizzando i dispositivi non di uno solo, ma di molti fornitori.
- L’automazione non è solo un fenomeno tecnico, ma anche culturale.
- Automatizzare le reti su larga scala è più difficile di quanto sembri a causa dei principi architettonici fondamentali della progettazione dell’automazione.
Quando abbiamo discusso dei nostri piani di crescita a lungo termine più di un anno fa, i nostri clienti aziendali hanno chiesto quanto segue:
- La raccolta dei fatti deve essere meglio standardizzata e allineata ai flussi di lavoro di automazione su tutti i dispositivi.
- Anche le configurazioni di aggiornamento sul dispositivo devono essere standardizzate e coerenti in modo che i moduli Ansible gestiscano la seconda metà del ciclo dopo la raccolta dei dati.
- Abbiamo bisogno di metodi rigorosi e supportati per convertire la configurazione del dispositivo in dati strutturati. Su questa base la fonte della verità può essere spostata dal dispositivo di rete.
Miglioramenti dei fatti
La raccolta di informazioni dai dispositivi di rete tramite Ansible avviene spesso in modo casuale. Le piattaforme basate sul Web hanno vari gradi di capacità di raccolta dei fatti, ma hanno poche o nessuna funzionalità per l'analisi e la standardizzazione della rappresentazione dei dati in coppie chiave-valore. Leggere Ken Celenza su quanto possa essere difficile e doloroso analizzare e standardizzare i dati reali.
Potresti aver notato che stiamo lavorando sul ruolo di Ansible Network Engine. Naturalmente, dopo 24 download, il ruolo Network Engine è diventato rapidamente uno dei ruoli Ansible più popolari in Ansible Galaxy per gli scenari di automazione della rete. Prima di trasferire gran parte di questo in Ansible 2.8 per prepararci a ciò che sarebbe stato necessario in Ansible 2.9, questo ruolo Ansible forniva il primo set di strumenti per aiutare ad analizzare i comandi, gestire i comandi e raccogliere dati per i dispositivi di rete.
Se sai come utilizzare Network Engine, questo è un modo molto efficiente per raccogliere, analizzare e standardizzare i dati concreti da utilizzare in Ansible. Lo svantaggio di questo ruolo è che è necessario creare un sacco di parser per ciascuna piattaforma e per tutta l'attività di rete. Per capire quanto sia difficile creare, spedire e mantenere i parser, dai un'occhiata a dai ragazzi di Cisco.
In poche parole, ottenere dati dai dispositivi e normalizzarli in coppie chiave-valore è essenziale per l'automazione su larga scala, ma raggiungere questo obiettivo è difficile quando si hanno 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, ogni volta che viene rilasciato un modulo di rete aggiornato, il modulo dei fatti viene migliorato per fornire dati su questa sezione della configurazione. Cioè, lo sviluppo di fatti e moduli ora avviene allo stesso ritmo e avranno sempre una struttura dati comune.
La configurazione delle risorse su un dispositivo di rete può essere recuperata e convertita in dati strutturati in due modi. In entrambi i modi, puoi raccogliere e trasformare un elenco specifico di risorse utilizzando una nuova parola chiave gather_network_resources. I nomi delle risorse corrispondono ai nomi dei moduli, il che è molto comodo.
Mentre raccogli i fatti:
Utilizzando una parola chiave gather_facts puoi recuperare la configurazione corrente del dispositivo all'inizio del playbook e quindi utilizzarla nell'intero playbook. Specificare le singole risorse da recuperare dal dispositivo.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TruePotresti aver notato qualcosa di nuovo in questi esempi, vale a dire: gather_facts: true è ora disponibile per la raccolta dei fatti nativa per i dispositivi di rete.
Utilizzando direttamente il modulo dei fatti di rete:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesIl 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: Ethernet1Nota come Ansible recupera la configurazione nativa dal dispositivo Arista e la trasforma in dati strutturati da utilizzare come coppie chiave-valore standard per attività e operazioni downstream.
I fatti dell'interfaccia possono essere aggiunti alle variabili memorizzate Ansible e utilizzati immediatamente o successivamente come input in un modulo di risorse eos_interfaces senza ulteriore elaborazione o conversione.
Moduli di risorse
Quindi, abbiamo estratto i fatti, normalizzato i dati, inseriti in un diagramma di struttura dei dati interna standardizzata e ricevuto una fonte di verità già pronta. Evviva! Questo è fantastico, ovviamente, ma dobbiamo ancora riconvertire in qualche modo le coppie chiave-valore nella configurazione specifica prevista dalla piattaforma del dispositivo specifico. Ora abbiamo bisogno di moduli specifici della piattaforma per soddisfare questi nuovi requisiti di raccolta dei fatti e normalizzazione.
Cos'è un modulo di risorse? Puoi considerare le sezioni di configurazione di un dispositivo come risorse fornite da quel dispositivo. I moduli delle risorse di rete sono intenzionalmente limitati a una singola risorsa e possono essere impilati come elementi costitutivi per configurare servizi di rete complessi. Di conseguenza, i requisiti e le specifiche per un modulo di risorsa sono naturalmente semplificati, poiché il modulo di risorsa è in grado di leggere и configurare un servizio di rete specifico su un dispositivo di rete.
Per spiegare cosa fa un modulo di risorse, diamo un'occhiata a un playbook di esempio che mostra un'operazione idemponente utilizzando nuovi fatti e moduli sulle risorse di rete eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changedCome puoi vedere, i dati raccolti dal dispositivo vengono trasferiti direttamente al modulo di risorse corrispondente senza conversione. Una volta avviato, il playbook recupera i valori dal dispositivo e li confronta con i valori previsti. In questo esempio, i valori restituiti sono quelli previsti (ovvero, controlla le deviazioni della configurazione) e segnala se la configurazione è cambiata.
Il modo ideale per rilevare la deviazione della configurazione è archiviare i fatti nelle variabili memorizzate Ansible e utilizzarli periodicamente con il modulo delle risorse in modalità di ispezione. Questo è un metodo semplice per vedere se qualcuno ha modificato manualmente i valori. Nella maggior parte dei casi, le organizzazioni consentono modifiche e configurazioni manualmente, sebbene molte operazioni vengano eseguite tramite Ansible Automation.
In cosa differiscono i nuovi moduli delle risorse da quelli precedenti?
Per un ingegnere di automazione di rete, esistono 3 differenze principali tra i moduli di risorse in Ansible 2.9 e le versioni precedenti.
1) Per una determinata risorsa di rete (che può anche essere considerata come una sezione di configurazione), i moduli e i fatti si evolveranno simultaneamente su tutti i sistemi operativi di rete supportati. Pensiamo che se Ansible supporta la configurazione delle risorse su una piattaforma di rete, dovremmo supportarla ovunque. Ciò semplifica l'utilizzo dei moduli di risorse poiché un tecnico dell'automazione di rete può ora configurare una risorsa (come LLDP) su tutti i sistemi operativi di rete con moduli nativi e supportati.
2) I moduli delle risorse ora includono un valore di stato.
merged: la configurazione viene fusa con la configurazione fornita (default);replaced: La configurazione della risorsa verrà sostituita con la configurazione fornita;overridden: La configurazione della risorsa verrà sostituita con la configurazione fornita; le istanze di risorse non necessarie verranno eliminate;deleted: la configurazione della risorsa verrà eliminata/ripristinata ai valori predefiniti.
3) I moduli di risorse ora includono valori di ritorno stabili. Quando il modulo delle risorse di rete ha apportato (o proposto) le modifiche necessarie al dispositivo di rete, restituisce le stesse coppie chiave-valore al playbook.
before: configurazione sul dispositivo sotto forma di dati strutturati prima dell'attività;after: se il dispositivo è cambiato (o potrebbe cambiare se si utilizza la modalità test), la configurazione risultante verrà restituita come dato strutturato;commands: eventuali comandi di configurazione vengono eseguiti sul dispositivo per portarlo nello stato desiderato.
Cosa significa tutto questo? Perché è importante?
Questo post copre molti concetti complessi, ma speriamo che alla fine tu abbia una migliore comprensione di ciò che i clienti aziendali chiedono in fatto di raccolta, normalizzazione dei dati e configurazione del loop per una piattaforma di automazione. Ma perché hanno bisogno di questi miglioramenti? Molte organizzazioni stanno ora perseguendo la trasformazione digitale per rendere i propri ambienti IT più agili e competitivi. Nel bene e nel male, molti ingegneri di rete diventano sviluppatori di rete per interesse personale o per volere del management.
Le organizzazioni si stanno rendendo conto che l’automazione dei singoli modelli di rete non risolve il problema dei silos e aumenta solo in una certa misura l’efficienza. Red Hat Ansible Automation Platform fornisce modelli di dati di risorse rigorosi e normativi per gestire in modo programmatico i dati sottostanti su un dispositivo di rete. Ciò significa che gli utenti stanno gradualmente abbandonando i metodi di configurazione individuali a favore di metodi più moderni che pongono l'accento sulle tecnologie (ad esempio, indirizzi IP, VLAN, LLDP, ecc.), piuttosto che sull'implementazione specifica del fornitore.
Ciò significa che i giorni di moduli di comando e configurazioni affidabili e comprovati sono contati? In nessun caso. I moduli delle risorse di rete previsti non saranno applicabili in tutti i casi o per ogni fornitore, pertanto i moduli di comando e configurazione saranno comunque necessari agli ingegneri di rete per determinate implementazioni. Lo scopo dei moduli di risorse è semplificare modelli Jinja di grandi dimensioni e normalizzare le configurazioni dei dispositivi non strutturati in un formato JSON strutturato. Con i moduli di risorse, sarà più semplice per le reti esistenti trasformare la propria configurazione in coppie chiave-valore strutturate che rappresentano una fonte di verità di facile lettura. Utilizzando coppie chiave-valore strutturate, puoi passare dall'esecuzione di configurazioni su ciascun dispositivo all'utilizzo di dati strutturati indipendenti e portare le reti in prima linea in un approccio Infrastructure-as-Code.
Quali moduli di risorse saranno disponibili in Ansible Engine 2.9?
Prima di raccontarvi nel dettaglio cosa accadrà in Ansible 2.9, ricordiamo come abbiamo suddiviso l'intero ambito di lavoro.
Abbiamo individuato 7 categorie e assegnato a ciascuna specifiche risorse di rete:
Nota: le risorse in grassetto sono state pianificate e implementate in Ansible 2.9.
Sulla base del feedback dei clienti aziendali e della comunità, era logico affrontare prima i moduli relativi ai protocolli della 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 sviluppati dalla comunità Ansible:
exos_lldp_global- da Extreme Networks.nxos_bfd_interfaces- da Cisconxos_telemetry- da Cisco
Come puoi vedere, il concetto di moduli di risorse si adatta alla nostra strategia incentrata sulla piattaforma. Cioè, includiamo le capacità e le funzioni necessarie nello stesso Ansible per supportare la standardizzazione nello sviluppo di moduli di rete e anche per 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 lo strumento Module Builder.
Piani per Ansible 2.10 e versioni successive
Una volta rilasciato Ansible 2.9, lavoreremo sulla prossima serie di moduli di risorse per Ansible 2.10, che possono essere utilizzati per configurare ulteriormente la topologia e le policy di rete, ad es. . Il piano di sviluppo può ancora essere modificato, quindi se avete commenti, segnalateli a .
Risorse e come iniziare
Fonte: habr.com