Den kommende udgivelse af Red Hat Ansible Engine 2.9 bringer spændende forbedringer, hvoraf nogle er diskuteret i denne artikel. Som altid har vi udviklet Ansible Network-forbedringer åbent med fællesskabsstøtte. Vær med - tag et kig på og studere udviklingsplanen for på wiki-siden for .
Som vi for nylig annoncerede, inkluderer nu Ansible Tower, Ansible Engine og alt Ansible Network-indhold. I dag er de mest populære netværksplatforme implementeret gennem Ansible-moduler. For eksempel:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
For en komplet liste over platforme, der er fuldt understøttet af Red Hat gennem Ansible Automation-abonnement, .
Hvad har vi lært
I løbet af de sidste fire år har vi lært meget om at udvikle en netværksautomatiseringsplatform. Det lærte vi også som platformsartefakter bruges i Ansible-spillebøger og roller af slutbrugere. Og her er hvad vi fandt ud af:
- Organisationer automatiserer enheder fra ikke kun én, men mange leverandører.
- Automatisering er ikke kun et teknisk fænomen, men også et kulturelt.
- Automatisering af netværk i stor skala er vanskeligere, end det ser ud til på grund af de grundlæggende arkitektoniske principper for automatiseringsdesign.
Da vi diskuterede vores langsigtede vækstplaner for over et år siden, bad vores erhvervskunder om følgende:
- Faktaindsamling skal standardiseres bedre og tilpasses automatiseringsarbejdsgange på tværs af alle enheder.
- Opdatering af konfigurationer på enheden skal også være standardiseret og konsistent, så Ansible-moduler håndterer anden halvdel af cyklussen efter indsamling af fakta.
- Vi har brug for strenge og understøttede metoder til at konvertere enhedskonfiguration til strukturerede data. På dette grundlag kan kilden til sandhed flyttes fra netværksenheden.
Faktaforbedringer
Indsamling af fakta fra netværksenheder ved hjælp af Ansible sker ofte tilfældigt. Web-baserede platforme har forskellige grader af faktaindsamlingsmuligheder, men de har ringe eller ingen funktionalitet til at parse og standardisere repræsentationen af data i nøgleværdi-par. Læs Ken Celenza om, hvor svært og smertefuldt det kan være at analysere og standardisere faktuelle data.
Du har måske bemærket, at vi arbejder på rollen Ansible Network Engine. Naturligvis, 24K downloads senere, 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 ind i Ansible 2.8 for at forberede os på, hvad der ville 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 analysere kommandoer, administrere kommandoer og indsamle data til netværksenheder.
Hvis du ved, hvordan du bruger Network Engine, er dette en meget effektiv måde at indsamle, parse og standardisere faktadata til brug i Ansible. Ulempen ved denne rolle er, at du skal oprette en hel masse parsere for hver platform og for al netværksaktivitet. For at forstå, hvor svært det er at oprette, sende og vedligeholde parsere, skal du tage et kig på fra fyrene hos Cisco.
Kort sagt, at få fakta fra enheder og normalisere dem til nøgleværdi-par er afgørende for automatisering i stor skala, men at opnå dette er svært, når du har mange leverandører og netværksplatforme.
Hvert netværksfaktamodul i Ansible 2.9 kan nu analysere konfigurationen af en netværksenhed og returnere strukturerede data - uden yderligere biblioteker, Ansible-roller eller brugerdefinerede parsere.
Siden Ansible 2.9, hver gang et opdateret netværksmodul frigives, er faktamodulet forbedret for at give data om denne sektion af konfigurationen. Det vil sige, at udviklingen af fakta og moduler nu sker i samme tempo, og de vil altid have en fælles datastruktur.
Konfigurationen af ressourcer på en netværksenhed kan hentes og konverteres til strukturerede data på to måder. På begge måder kan du indsamle og transformere en specifik liste over ressourcer ved hjælp af et nyt søgeord gather_network_resources. Ressourcenavnene matcher modulnavnene, hvilket er meget praktisk.
Mens du samler fakta:
Brug af et søgeord gather_facts du kan hente den aktuelle enhedskonfiguration i begyndelsen af afspilningsbogen og derefter bruge den gennem hele afspilningsbogen. Angiv de individuelle ressourcer, der skal hentes 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 er nu tilgængelig til indbygget faktaindsamling til netværksenheder.
Direkte brug af netværksfaktamodulet:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesAfspilningsbogen returnerer følgende fakta om grænsefladen:
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: Ethernet1Læg mærke til, hvordan Ansible henter den oprindelige konfiguration fra Arista-enheden og transformerer den til strukturerede data til brug som standardnøgleværdi-par til downstream-opgaver og -operationer.
Interfacefakta kan tilføjes til Ansible lagrede variabler og bruges umiddelbart eller senere som input til et ressourcemodul eos_interfaces uden yderligere bearbejdning eller konvertering.
Ressourcemoduler
Så vi har udtrukket fakta, normaliseret dataene, tilpasset dem til et standardiseret internt datastrukturdiagram og har en færdig kilde til sandhed. Hurra! Dette er selvfølgelig fantastisk, men vi skal stadig på en eller anden måde konvertere nøgleværdi-parrene tilbage til den specifikke konfiguration, som den specifikke enhedsplatform forventer. Vi har nu brug for platformsspecifikke moduler for at opfylde disse nye faktaindsamlings- og normaliseringskrav.
Hvad er et ressourcemodul? Du kan tænke på en enheds konfigurationssektioner som ressourcer leveret af den pågældende enhed. Netværksressourcemoduler er bevidst begrænset til en enkelt ressource og kan stables som byggeklodser for at konfigurere komplekse netværkstjenester. Som følge heraf er kravene og specifikationen til et ressourcemodul naturligvis forenklet, da ressourcemodulet kan læse и konfigurere en specifik netværkstjeneste på en netværksenhed.
For at forklare, hvad et ressourcemodul gør, lad os se på et eksempel på en spillebog, der viser en uvirksom operation ved hjælp af nye netværksressourcefakta og modul 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.changedSom du kan se, overføres de indsamlede data fra enheden direkte til det tilsvarende ressourcemodul uden konvertering. Når den startes, henter playbook værdier fra enheden og sammenligner dem med forventede værdier. I dette eksempel er de returnerede værdier som forventet (det vil sige, den tjekker for konfigurationsafvigelser) og rapporterer, om konfigurationen er ændret.
Den ideelle måde at detektere konfigurationsdrift på er at gemme fakta i Ansible-lagrede variabler og periodisk bruge dem med ressourcemodulet i inspektionstilstand. Dette er en enkel metode til at se, om nogen manuelt har ændret værdierne. I de fleste tilfælde tillader organisationer ændringer og konfiguration manuelt, selvom mange operationer udføres gennem Ansible Automation.
Hvordan adskiller de nye ressourcemoduler sig fra de tidligere?
For en netværksautomatiseringsingeniør er der 3 hovedforskelle mellem ressourcemoduler i Ansible 2.9 og tidligere versioner.
1) For en given netværksressource (som også kan opfattes som en konfigurationssektion), vil moduler og fakta udvikle sig på tværs af alle understøttede netværksoperativsystemer samtidigt. Vi mener, at hvis Ansible understøtter ressourcekonfiguration på én netværksplatform, bør vi understøtte det overalt. Dette forenkler brugen af ressourcemoduler, fordi en netværksautomatiseringsingeniør nu kan konfigurere en ressource (såsom LLDP) på alle netværksoperativsystemer med indbyggede og understøttede moduler.
2) Ressourcemoduler inkluderer nu en tilstandsværdi.
merged: konfigurationen er flettet med den angivne konfiguration (standard);replaced: Ressourcekonfigurationen vil blive erstattet med den medfølgende konfiguration;overridden: Ressourcekonfigurationen vil blive erstattet med den medfølgende konfiguration; unødvendige ressourceforekomster vil blive slettet;deleted: Ressourcekonfigurationen vil blive slettet/gendannet til standard.
3) Ressourcemoduler inkluderer nu stabile returværdier. Når netværksressourcemodulet har foretaget (eller foreslået) de nødvendige ændringer til netværksenheden, returnerer det de samme nøgle-værdi-par til afspilningsbogen.
before: konfiguration på enheden i form af strukturerede data før opgaven;after: hvis enheden er ændret (eller kan ændre sig, hvis testtilstand bruges), vil den resulterende konfiguration blive returneret som strukturerede data;commands: Alle konfigurationskommandoer kører på enheden for at bringe den i den ønskede tilstand.
Hvad betyder alt dette? Hvorfor er det vigtigt?
Dette indlæg dækker en masse komplekse koncepter, men vi håber, at du i sidste ende vil have en bedre forståelse af, hvad virksomhedsklienter beder om faktisk indsamling, datanormalisering og loop-konfiguration til en automatiseringsplatform. Men hvorfor har de brug for disse forbedringer? Mange organisationer forfølger nu digital transformation for at gøre deres it-miljøer mere agile og konkurrencedygtige. På godt og ondt bliver mange netværksingeniører netværksudviklere enten af egeninteresse eller på ledelsens foranledning.
Organisationer indser, at automatisering af individuelle netværksskabeloner ikke løser problemet med siloer og kun øger effektiviteten til en vis grad. Red Hat Ansible Automation Platform leverer strenge og normative ressourcedatamodeller til programmæssig styring af de underliggende data på en netværksenhed. Det vil sige, at brugerne gradvist opgiver individuelle konfigurationsmetoder til fordel for mere moderne metoder med vægt på teknologier (f.eks. IP-adresser, VLAN'er, LLDP osv.), frem for en specifik leverandørimplementering.
Betyder det, at dagene med pålidelige og gennemprøvede kommandomoduler og konfiguration er talte? I intet tilfælde. De forventede netværksressourcemoduler vil ikke være anvendelige i alle tilfælde eller for hver leverandør, så kommando- og konfigurationsmodulerne vil stadig være nødvendige for netværksingeniører til visse implementeringer. Formålet med ressourcemoduler er at forenkle store Jinja-skabeloner og normalisere ustrukturerede enhedskonfigurationer til et struktureret JSON-format. Med ressourcemoduler bliver det lettere for eksisterende netværk at transformere deres konfiguration til strukturerede nøgleværdi-par, der repræsenterer en letlæselig kilde til sandhed. Ved at bruge strukturerede nøgleværdi-par kan du gå fra at køre konfigurationer på hver enhed til at arbejde med uafhængige strukturerede data og bringe netværk på forkant med en infrastruktur-som-kode-tilgang.
Hvilke ressourcemoduler kommer i Ansible Engine 2.9?
Før vi fortæller dig i detaljer, hvad der vil ske i Ansible 2.9, så lad os huske, hvordan vi delte hele arbejdets omfang.
Vi identificerede 7 kategorier og tildelte specifikke netværksressourcer til hver:
Bemærk: Ressourcer med fed skrift blev planlagt og implementeret i Ansible 2.9.
Baseret på feedback fra virksomhedskunder og samfundet var det logisk først at tage fat på de moduler relateret til netværkstopologiprotokoller, virtualisering og grænseflader.
Følgende ressourcemoduler blev udviklet af Ansible Network-teamet og svarer til de platforme, der understøttes af Red Hat:
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 platform-centrerede strategi. Det vil sige, at vi inkluderer de nødvendige kapaciteter og funktioner i selve Ansible for at understøtte standardisering i udviklingen af netværksmoduler, og også for at forenkle brugernes arbejde på niveau med Ansible roller og playbooks. For at udvide udviklingen af ressourcemoduler udgav Ansible-teamet værktøjet Module Builder.
Planer for Ansible 2.10 og senere
Når Ansible 2.9 er udgivet, vil vi arbejde på det næste sæt ressourcemoduler til Ansible 2.10, som kan bruges til yderligere at konfigurere netværkstopologi og -politik, f.eks. . Udviklingsplanen kan stadig justeres, så hvis du har kommentarer, bedes du melde det til .
Ressourcer og at komme i gang
Kilde: www.habr.com