I det kommende udgivelse af Red Hat Ansible Engine 2.9 venter der imponerende forbedringer, hvoraf nogle er beskrevet i denne artikel. Som altid har vi udviklet forbedringer af Ansible Network åbent med støtte fra fællesskabet. Deltag — kig på og udforsk udviklingsplanen for på wiki-siden for .
Som vi for nylig har annonceret, nu Ansible Tower, Ansible Engine og alt indhold fra Ansible Network. I øjeblikket implementeres de fleste populære netværksplatforme via Ansible-moduler. For eksempel:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Den komplette liste over platforme, der er fuldt understøttet af Red Hat gennem Ansible Automation-abonnementet, .
Hvad vi har lært
I de seneste fire år har vi lært meget om udviklingen af en platform til netværksautomatisering. Vi har også lært om, hvordan hvordan artefakter fra platformen anvendes i Ansible-playbooks og roller fra slutbrugerne. Og her er, hvad vi har fundet ud af:
- Organisationer automatiserer ikke kun enhed fra én leverandør, men mange.
- Automatisering er ikke blot et teknisk fænomen, men også et kulturelt.
- Storskala netværksautomatisering er mere kompleks, end det ser ud, på grund af fundamentale arkitektoniske designprincipper for automatik.
Da vi diskuterede vores langsigtede udviklingsplaner for over et år siden, bad vores erhvervskunder om følgende:
- Indsamling af fakta skal standardiseres bedre og harmoniseres med automatiseringsarbejdsgange for enhver enhed.
- Opdatering af konfigurationer på enheden skal også standardiseres og harmoniseres, så Ansible-moduler kan håndtere den anden halvdel af cyklussen efter indsamlingen af fakta.
- Der er behov for strenge og understøttede metoder til at konvertere enhedens konfiguration til strukturerede data. På denne base kan sandhedskilden flyttes væk fra netværksenheder.
Forbedringer af fakta
Indsamling af fakta fra netværksenheder med Ansible foregår ofte tilfældigt. Netværksplatforme er i varierende grad udstyret med muligheder for indsamling af fakta, men de har næsten ingen — eller slet ingen — funktioner til at analysere og standardisere præsentationen af data i nøgle-værdi-par. Læs Ken Celenza om, hvor svært og besværligt det kan være at analysere og standardisere fakta-data.
Du har måske bemærket, hvordan vi har arbejdet på Ansible Network Engine-rollen. Naturligvis, efter 24.000 downloads er Network Engine-rollen hurtigt blevet en af de mest populære Ansible-roller i Ansible Galaxy til netværksautomatiseringsscenarier. Før vi flyttede meget af dette til Ansible 2.8 for at forberede os på, hvad der vil være nødvendigt i Ansible 2.9, gav denne Ansible-rolle det første sæt værktøjer til at hjælpe med at parse kommandoer, administrere hold og indsamle data til netværksenheder.
Hvis du er bekendt med brugen af Network Engine, er det en meget effektiv måde at indsamle, parse og standardisere faktadata til brug i Ansible. Ulempen ved denne rolle er, at man skal oprette en masse parsere for hver platform og for al netværksaktivitet. For at forstå, hvor svært det er at lave, levere og vedligeholde parsere, kan du tage et kig på fra drengene fra Cisco.
Kort sagt er det meget vigtigt at hente fakta fra enheder og normalisere dem til nøgle-værdi-par for storskala automatisering, men det er svært at opnå, når du har mange leverandører og netværksplatforme.
Hver netværksfaktamodul i Ansible 2.9 kan nu analysere konfigurationen af netværksenheden og returnere strukturerede data — uden ekstra biblioteker, Ansible-roller eller brugerdefinerede parsere.
Fra Ansible 2.9 bliver faktamodulet forbedret ved hver udgivelse af det opdaterede netværksmodul for at levere data om denne del af konfigurationen. Det vil sige, at udviklingen af fakta og moduler nu sker i ét tempo, og de vil altid have en fælles datamodel.
Konfigurationen af ressourcerne på en netværksenhed kan udtrækkes og konverteres til strukturerede data på to måder. Begge metoder kan samle og konvertere en specifik liste af ressourcer ved hjælp af det nye nøgleord gather_network_resources. Ressource navnene svarer til modulnavne, og det er meget praktisk.
Under indsamlingen af fakta:
Ved hjælp af nøgleordet gather_facts kan den nuværende konfiguration af enheden udtrækkes i starten af playbooken og derefter bruges i hele playbooken. Angiv specifikke ressourcer, der skal udtrækkes fra enheden.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueDu har måske bemærket noget nyt i disse eksempler, nemlig — gather_facts: true nu tilgængelig for nativ indsamling af fakta til netværksenheder.
Brug af netværksfaktamodulet direkte:
- name: indsamle interface konfigurationsfakta
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPlaybooken returnerer følgende fakta om interfacet:
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: Ethernet1Bemærk, hvordan Ansible udtrækker den native konfiguration fra Arista-enheden og omdanner den til strukturerede data, som kan bruges i form af standard nøgle-værdi-par til efterfølgende opgaver og operationer.
Interfacefakta kan tilføjes til Ansible's gemte variabler og bruges med det samme eller senere som input til ressourcemodulet eos_interfaces uden yderligere behandling eller omdannelse.
Ressourcemoduler
Så vi har udtrukket fakta, normaliseret dataene, skrevet dem ind i en standardiseret intern datafaktakstruktur og fået en klar sandhedskilde. Hurra! Det er selvfølgelig fantastisk, men vi skal stadig finde en måde at omdanne nøgle-værdi-par tilbage til den specifikke konfiguration, som enhedens platform forventer. Nu har vi brug for moduler til specifikke platforme for at imødekomme disse nye krav til faktainsamling og normalisering.
Hvad er et ressourcemodul? Enhedens konfigurationsafsnit kan betragtes som ressourcer, der leveres af denne enhed. Netværksressourcemoduler er bevidst begrænset til én ressource, og de kan stables som byggeklodser for at konfigurere komplekse netværkstjenester. Som et resultat forenkles kravene og specifikationen for ressourcemodulet naturligt, da ressourcemodulet kan læse og konfigurere en bestemt netværkstjeneste på netværksenheden.
For at forklare, hvad ressourcemodulet gør, lad os se på et eksempel på en playbook, der viser en idempotent operation ved hjælp af de nye netværksressourcefakta og modulet eos_l3_interface.
- navn: eksempel på fakta, der bringes direkte tilbage til enheden.
værter: arista
indsamle_fakta: falsk
opgaver:
- navn: hent arista eos fakta
eos_fakta:
indsamle_subset: min
indsamle_netsressourcer: l3_interfaces
- navn: sikre, at IP-adresseoplysningerne er korrekte
eos_l3_interfaces:
konfiguration: "{{ ansible_network_resources['l3_interfaces'] }}"
registrer: resultat
- navn: sikre, at konfigurationen ikke er ændret
bekræft:
at: ikke resultat.ændretSom du kan se, bliver de indsamlede data fra enheden sendt direkte til den relevante ressourcemodul uden konvertering. Når playbooken køres, henter den værdier fra enheden og sammenligner dem med de forventede. I dette eksempel stemmer de modtagne værdier overens med de forventede (dvs. konfigurationsafvigelserne kontrolleres) og der gives en meddelelse om, hvorvidt konfigurationen er blevet ændret.
Den ideelle måde at opdage konfigurationsafvigelser på er at gemme fakta i Ansible-variabler og regelmæssigt bruge dem sammen med ressourcemodulet i kontroltilstand. Det er en enkel metode til at se, om nogen har ændret værdierne manuelt. I de fleste tilfælde tillader organisationer ændringer og konfiguration manuelt, selvom mange operationer udføres via Ansible Automation.
Hvordan adskiller de nye ressourcemoduler sig fra de tidligere?
For en netværksautomatiseringsingeniør er der 3 primære forskelle mellem ressourcemodulerne i Ansible 2.9 og tidligere versioner.
1) For en bestemt netværksressource (som også kan betragtes som et konfigurationsafsnit) vil modulerne og fakta udvikle sig i alle understøttede netværksoperativsystemer samtidig. Vi mener, at hvis Ansible understøtter konfigurationen af ressourcen på én netværksplatform, skal vi også støtte den overalt. Dette gør brugen af ressourcemoduler lettere, fordi netværksautomatiseringsingeniøren nu kan konfigurere ressourcen (f.eks. LLDP) på tværs af alle netværksoperativsystemer med nativt understøttede moduler.
2) Ressourcemoduler inkluderer nu tilstandsoplysninger.
sammensluttet: konfigurationen er sammensluttet med den angivne konfiguration (standard);erstatte: konfigurationen af ressourcen vil blive erstattet med den angivne konfiguration;override: konfigurationen af ressourcen vil blive erstattet med den angivne konfiguration; overskydende ressourceeksemplarer vil blive fjernet;deleted: konfigurationen af ressourcen vil blive fjernet/gendannet som standard.
3) Ressourcemoduler inkluderer nu stabile returnerede værdier. Når netværksressourcemodulet har foretaget (eller foreslået) nødvendige ændringer på netværksenheden, returnerer det de samme nøgle-værdi-par til playbooken.
før: konfigurationen på enheden i form af strukturerede data før opgaven;efter: hvis enheden har ændret sig (eller kan ændre sig, hvis der anvendes kontroltilstand), vil den resulterende konfiguration blive returneret i form af strukturerede data;kommandorer: alle konfigurationskommandoer, der køres på enheden, for at bringe den i ønsket tilstand.
Hvad betyder dette? Hvorfor er det vigtigt?
Dette indlæg beskriver mange komplekse koncepter, men vi håber, at du til sidst vil forstå bedre, at virksomhedskunder beder om faktaindsamling, normalisering af data og konfigurationscykler til automatiseringsplatformen. Men hvorfor har de brug for disse forbedringer? Mange organisationer gennemgår i øjeblikket digital transformation for at gøre deres IT-miljøer mere fleksible og konkurrencedygtige. Godt eller skidt, men mange netværksingeniører bliver netværksudviklere — enten af egen interesse eller opfordret af ledelsen.
Organisationer forstår, at automatisering af individuelle netværksmønstre ikke løser problemet med fragmentering og kun øger effektiviteten op til et vist punkt. Red Hat Ansible Automation Platform giver strenge og normaliserende datamodeller for ressourcer til programmatisk at styre de grundlæggende data på netværksenheden. Det vil sige, at brugere gradvist bevæger sig væk fra individuelle konfigurationsmetoder til fordel for mere moderne metoder, der fokuserer på teknologier (f.eks. IP-adresser, VLAN, LLDP osv.), snarere end på specifik implementering fra en leverandør.
Betyder dette, at dagene for pålidelige og velafprøvede team- og konfigurationsmoduler er talte? Nej, det gør de ikke. De forventede netværksressourcemoduler vil ikke være anvendelige i alle tilfælde og for hver leverandør, så team- og konfigurationsmoduler vil stadig være nødvendige for netværksingeniører til specifikke implementeringer. Formålet med ressourcemodulerne er at forenkle store Jinja-skabeloner og normalisere ustrukturerede enheds konfigurationer til et struktureret JSON-format. Med ressourcemoduler vil eksisterende netværk kunne omdanne deres konfigurationer til strukturerede nøgle-værdi-par, som vil udgøre en læsevenlig kilde til sandhed. Ved at bruge strukturerede nøgle-værdi-par kan man gå fra at køre konfigurationer på hver enhed til at arbejde med uafhængige strukturerede data og bringe netværk i fokus med et 'infrastruktur som kode'-tilgang.
Hvilke ressourcemoduler vil finde vej til Ansible Engine 2.9?
Før vi dykker ned i detaljerne om, hvad der vil være i Ansible 2.9, lad os huske, hvordan vi delte hele omfanget af arbejdet.
Vi har identificeret 7 kategorier og tildelt specifikke netværksressourcer til hver af dem:
Bemærk: De ressourcer, der er fremhævet med fed, blev planlagt og implementeret i Ansible 2.9.
Baseret på feedback fra virksomhedskunder og fællesskabet var det logisk at begynde med de moduler, der relaterer til netværkstopologiprotokoller, virtualisering og grænseflader.
Følgende ressourcemoduler er udviklet af Ansible Network-teamet og understøtter de platforme, som Red Hat støtter:
Følgende moduler er udviklet af Ansible-fællesskabet:
exos_lldp_global— fra Extreme Networks.nxos_bfd_interfaces— fra Cisconxos_telemetry— fra Cisco
Som du kan se, passer konceptet med ressourcemoduler ind i vores platformorienterede strategi. Det vil sige, at vi inkorporerer de nødvendige funktioner og egenskaber direkte i Ansible for at understøtte standardiseringen i udviklingen af netværksmoduler og for at forenkle brugernes arbejde på niveauet for roller og Ansible-playbooks. For at udvide udviklingen af ressourcemoduler har Ansible-teamet udgivet værktøjet Module Builder.
Planer for Ansible 2.10 og fremad
Efter udgivelsen af Ansible 2.9 vil vi fokusere på det næste sæt ressourcemoduler til Ansible 2.10, som kan anvendes til yderligere at tilpasse netværkstopologi og politik, såsom Udviklingsplanen kan stadig justeres, så hvis du har kommentarer, bedes du give besked i .
Ressourcer og opstart
Kilde: habr.com
