Den kommende utgivelsen av Red Hat Ansible Engine 2.9 gir spennende forbedringer, noen av dem er omtalt i denne artikkelen. Som alltid har vi utviklet Ansible Network-forbedringer åpent, med fellesskapsstøtte. Bli med - ta en titt på og studere utviklingsplanen for på wiki-siden for .
Som vi nylig annonserte, inkluderer nå Ansible Tower, Ansible Engine og alt Ansible Network-innhold. I dag er de mest populære nettverksplattformene implementert gjennom Ansible-moduler. For eksempel:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
For en komplett liste over plattformer som er fullt støttet av Red Hat gjennom Ansible Automation-abonnement, .
Hva har vi lært
I løpet av de siste fire årene har vi lært mye om å utvikle en nettverksautomatiseringsplattform. Det lærte vi også som plattformartefakter brukes i Ansible-spillebøker og roller av sluttbrukere. Og her er hva vi fant ut:
- Organisasjoner automatiserer enheter fra ikke bare én, men mange leverandører.
- Automatisering er ikke bare et teknisk fenomen, men også et kulturelt fenomen.
- Automatisering av nettverk i stor skala er vanskeligere enn det ser ut til på grunn av de grunnleggende arkitektoniske prinsippene for automatiseringsdesign.
Da vi diskuterte våre langsiktige vekstplaner for over et år siden, ba våre bedriftskunder om følgende:
- Faktainnsamlingen må standardiseres bedre og tilpasses automatiseringsarbeidsflyter på tvers av alle enheter.
- Oppdatering av konfigurasjoner på enheten må også være standardisert og konsistent slik at Ansible-moduler håndterer andre halvdel av syklusen etter å ha samlet inn fakta.
- Vi trenger strenge og støttede metoder for å konvertere enhetskonfigurasjon til strukturerte data. På dette grunnlaget kan sannhetens kilde flyttes fra nettverksenheten.
Faktaforbedringer
Innsamling av fakta fra nettverksenheter ved hjelp av Ansible skjer ofte tilfeldig. Nettbaserte plattformer har ulik grad av faktainnsamlingsmuligheter, men de har liten eller ingen funksjonalitet for å analysere og standardisere representasjonen av data i nøkkelverdi-par. Lese Ken Celenza om hvor vanskelig og smertefullt det kan være å analysere og standardisere faktadata.
Du har kanskje lagt merke til at vi jobber med rollen Ansible Network Engine. Naturligvis, 24K nedlastinger senere, har Network Engine-rollen raskt blitt en av de mest populære Ansible-rollene i Ansible Galaxy for nettverksautomatiseringsscenarier. Før vi flyttet mye av dette inn i Ansible 2.8 for å forberede oss på det som ville være nødvendig i Ansible 2.9, ga denne Ansible-rollen det første settet med verktøy for å hjelpe til med å analysere kommandoer, administrere kommandoer og samle inn data for nettverksenheter.
Hvis du vet hvordan du bruker Network Engine, er dette en veldig effektiv måte å samle inn, analysere og standardisere faktadata for bruk i Ansible. Ulempen med denne rollen er at du må lage en hel haug med parsere for hver plattform og for all nettverksaktivitet. For å forstå hvor vanskelig det er å lage, sende og vedlikeholde parsere, ta en titt på fra gutta i Cisco.
I et nøtteskall, å få fakta fra enheter og normalisere dem til nøkkelverdi-par er avgjørende for automatisering i stor skala, men å oppnå dette er vanskelig når du har mange leverandører og nettverksplattformer.
Hver nettverksfaktamodul i Ansible 2.9 kan nå analysere konfigurasjonen av en nettverksenhet og returnere strukturerte data – uten ekstra biblioteker, Ansible-roller eller tilpassede parsere.
Siden Ansible 2.9, hver gang en oppdatert nettverksmodul utgis, er faktamodulen forbedret for å gi data om denne delen av konfigurasjonen. Det vil si at utviklingen av fakta og moduler nå skjer i samme tempo, og de vil alltid ha en felles datastruktur.
Konfigurasjonen av ressurser på en nettverksenhet kan hentes og konverteres til strukturerte data på to måter. På begge måter kan du samle inn og transformere en spesifikk liste over ressurser ved å bruke et nytt nøkkelord gather_network_resources. Ressursnavnene samsvarer med modulnavnene, noe som er veldig praktisk.
Mens du samler fakta:
Ved hjelp av et nøkkelord gather_facts du kan hente gjeldende enhetskonfigurasjon i begynnelsen av spilleboken, og deretter bruke den gjennom hele spilleboken. Spesifiser de individuelle ressursene som skal hentes fra enheten.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueDu har kanskje lagt merke til noe nytt i disse eksemplene, nemlig - gather_facts: true er nå tilgjengelig for innfødt faktainnsamling for nettverksenheter.
Bruke nettverksfaktamodulen direkte:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPlaybook returnerer følgende fakta om grensesnittet:
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: Ethernet1Legg merke til hvordan Ansible henter den opprinnelige konfigurasjonen fra Arista-enheten og transformerer den til strukturerte data for bruk som standard nøkkelverdi-par for nedstrømsoppgaver og operasjoner.
Grensesnittfakta kan legges til Ansible lagrede variabler og brukes umiddelbart eller senere som input til en ressursmodul eos_interfaces uten ytterligere behandling eller konvertering.
Ressursmoduler
Så vi har hentet ut fakta, normalisert dataene, tilpasset dem i et standardisert internt datastrukturdiagram og har en ferdig kilde til sannhet. Hurra! Dette er selvfølgelig flott, men vi må fortsatt på en eller annen måte konvertere nøkkelverdi-parene tilbake til den spesifikke konfigurasjonen som den spesifikke enhetsplattformen forventer. Vi trenger nå plattformspesifikke moduler for å møte disse nye kravene til faktainnsamling og normalisering.
Hva er en ressursmodul? Du kan tenke på en enhets konfigurasjonsseksjoner som ressurser levert av den enheten. Nettverksressursmoduler er med vilje begrenset til én enkelt ressurs og kan stables som byggeklosser for å konfigurere komplekse nettverkstjenester. Som et resultat blir kravene og spesifikasjonene for en ressursmodul naturlig nok forenklet, siden ressursmodulen kan lese и konfigurere en bestemt nettverkstjeneste på en nettverksenhet.
For å forklare hva en ressursmodul gjør, la oss se på et eksempel på en lekebok som viser en uvirksom operasjon ved å bruke nye nettverksressursfakta 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 dataene som samles inn fra enheten direkte til den tilsvarende ressursmodulen uten konvertering. Når den lanseres, henter spilleboken verdier fra enheten og sammenligner dem med forventede verdier. I dette eksemplet er verdiene som returneres som forventet (det vil si at den sjekker for konfigurasjonsavvik) og rapporterer om konfigurasjonen er endret.
Den ideelle måten å oppdage konfigurasjonsdrift er å lagre fakta i Ansible-lagrede variabler og periodisk bruke dem med ressursmodulen i inspeksjonsmodus. Dette er en enkel metode for å se om noen har endret verdiene manuelt. I de fleste tilfeller tillater organisasjoner endringer og konfigurasjon manuelt, selv om mange operasjoner utføres gjennom Ansible Automation.
Hvordan skiller de nye ressursmodulene seg fra de tidligere?
For en nettverksautomatiseringsingeniør er det tre hovedforskjeller mellom ressursmoduler i Ansible 3 og tidligere versjoner.
1) For en gitt nettverksressurs (som også kan tenkes på som en konfigurasjonsseksjon), vil moduler og fakta utvikles på tvers av alle støttede nettverksoperativsystemer samtidig. Vi tror at hvis Ansible støtter ressurskonfigurasjon på én nettverksplattform, bør vi støtte det overalt. Dette forenkler bruken av ressursmoduler fordi en nettverksautomatiseringsingeniør nå kan konfigurere en ressurs (som LLDP) på alle nettverksoperativsystemer med innebygde og støttede moduler.
2) Ressursmoduler inkluderer nå en tilstandsverdi.
merged: konfigurasjonen er slått sammen med den angitte konfigurasjonen (standard);replaced: Ressurskonfigurasjonen vil bli erstattet med den angitte konfigurasjonen;overridden: Ressurskonfigurasjonen vil bli erstattet med den angitte konfigurasjonen; unødvendige ressursforekomster vil bli slettet;deleted: Ressurskonfigurasjonen vil bli slettet/gjenopprettet til standard.
3) Ressursmoduler inkluderer nå stabile returverdier. Når nettverksressursmodulen har gjort (eller foreslått) de nødvendige endringene på nettverksenheten, returnerer den de samme nøkkelverdi-parene til spilleboken.
before: konfigurasjon på enheten i form av strukturerte data før oppgaven;after: hvis enheten har endret seg (eller kan endres hvis testmodus brukes), vil den resulterende konfigurasjonen bli returnert som strukturerte data;commands: Alle konfigurasjonskommandoer kjøres på enheten for å bringe den til ønsket tilstand.
Hva betyr alt dette? Hvorfor er det viktig?
Dette innlegget dekker mange komplekse konsepter, men vi håper at du til slutt vil ha en bedre forståelse av hva bedriftsklienter ber om faktisk innsamling, datanormalisering og sløyfekonfigurasjon for en automatiseringsplattform. Men hvorfor trenger de disse forbedringene? Mange organisasjoner driver nå med digital transformasjon for å gjøre IT-miljøene sine mer smidige og konkurransedyktige. På godt og vondt blir mange nettverksingeniører nettverksutviklere, enten av egeninteresse eller på oppdrag fra ledelsen.
Organisasjoner innser at automatisering av individuelle nettverksmaler ikke løser problemet med siloer og bare øker effektiviteten til en viss grad. Red Hat Ansible Automation Platform gir strenge og normative ressursdatamodeller for programmatisk å administrere de underliggende dataene på en nettverksenhet. Det vil si at brukere gradvis forlater individuelle konfigurasjonsmetoder til fordel for mer moderne metoder med vekt på teknologier (for eksempel IP-adresser, VLAN, LLDP, etc.), snarere enn på en spesifikk leverandørimplementering.
Betyr dette at dagene med pålitelige og velprøvde kommandomoduler og konfigurasjon er talte? Ikke i noe tilfelle. De forventede nettverksressursmodulene vil ikke være aktuelt i alle tilfeller eller for hver leverandør, så kommando- og konfigurasjonsmodulene vil fortsatt være nødvendig av nettverksingeniører for visse implementeringer. Hensikten med ressursmoduler er å forenkle store Jinja-maler og normalisere ustrukturerte enhetskonfigurasjoner til et strukturert JSON-format. Med ressursmoduler vil det være lettere for eksisterende nettverk å transformere sin konfigurasjon til strukturerte nøkkelverdi-par som representerer en lettlest kilde til sannhet. Ved å bruke strukturerte nøkkelverdi-par kan du gå fra å kjøre konfigurasjoner på hver enhet til å jobbe med uavhengige strukturerte data og bringe nettverk i forkant av en infrastruktur-som-kode-tilnærming.
Hvilke ressursmoduler kommer i Ansible Engine 2.9?
Før vi forteller deg i detalj hva som vil skje i Ansible 2.9, la oss huske hvordan vi delte opp hele arbeidsomfanget.
Vi identifiserte 7 kategorier og tildelte spesifikke nettverksressurser til hver:
Merk: Ressurser med fet skrift ble planlagt og implementert i Ansible 2.9.
Basert på tilbakemeldinger fra bedriftskunder og samfunnet, var det logisk først å ta tak i disse modulene knyttet til nettverkstopologiprotokoller, virtualisering og grensesnitt.
Følgende ressursmoduler ble utviklet av Ansible Network-teamet og tilsvarer plattformene som støttes av Red Hat:
Følgende moduler er utviklet av Ansible-fellesskapet:
exos_lldp_global- fra Extreme Networks.nxos_bfd_interfaces- fra Cisconxos_telemetry- fra Cisco
Som du kan se, passer konseptet med ressursmoduler inn i vår plattformsentriske strategi. Det vil si at vi inkluderer de nødvendige egenskapene og funksjonene i selve Ansible for å støtte standardisering i utviklingen av nettverksmoduler, og også for å forenkle arbeidet til brukere på nivå med Ansible-roller og spillebøker. For å utvide utviklingen av ressursmoduler, lanserte Ansible-teamet Module Builder-verktøyet.
Planer for Ansible 2.10 og utover
Når Ansible 2.9 er utgitt, vil vi jobbe med neste sett med ressursmoduler for Ansible 2.10, som kan brukes til å konfigurere nettverkstopologi og policy ytterligere, f.eks. . Utbyggingsplanen kan fortsatt justeres, så hvis du har kommentarer, vennligst meld fra til .
Ressurser og komme i gang
Kilde: www.habr.com