Den kommande versionen av Red Hat Ansible Engine 2.9 ger spännande förbättringar, av vilka några diskuteras i den här artikeln. Som alltid har vi utvecklat Ansible Network-förbättringar öppet, med stöd från samhället. Häng med oss - ta en titt på och studera utvecklingsplanen för på wikisidan för .
Som vi nyligen meddelade, inkluderar nu Ansible Tower, Ansible Engine och allt innehåll från Ansible Network. Nuförtiden implementeras de flesta populära nätverksplattformarna genom Ansible-moduler. Till exempel:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
För en komplett lista över plattformar som stöds fullt ut av Red Hat genom en Ansible Automation-prenumeration, .
Vad har vi lärt oss
Under de senaste fyra åren har vi lärt oss mycket om att utveckla en plattform för nätverksautomatisering. Det lärde vi oss också как plattformsartefakter används i Ansible-spelböcker och roller av slutanvändare. Och här är vad vi fick reda på:
- Organisationer automatiserar enheter från inte bara en utan många leverantörer.
- Automation är inte bara ett tekniskt fenomen, utan också ett kulturellt.
- Att automatisera nätverk i stor skala är svårare än det verkar på grund av de grundläggande arkitektoniska principerna för automationsdesign.
När vi diskuterade våra långsiktiga tillväxtplaner för över ett år sedan bad våra företagskunder om följande:
- Faktainsamlingen måste standardiseras bättre och anpassas till automationsarbetsflöden på alla enheter.
- Uppdatering av konfigurationer på enheten måste också vara standardiserade och konsekventa så att Ansible-moduler hanterar den andra halvan av cykeln efter att ha samlat in fakta.
- Vi behöver rigorösa och understödda metoder för att konvertera enhetskonfiguration till strukturerad data. På grundval av detta kan sanningskällan flyttas från nätverksenheten.
Faktaförbättringar
Att samla in fakta från nätverksenheter med Ansible sker ofta slumpmässigt. Webbaserade plattformar har olika grader av faktainsamlingsmöjligheter, men de har liten eller ingen funktionalitet för att analysera och standardisera representationen av data i nyckel-värdepar. Läsa Ken Celenza om hur svårt och smärtsamt det kan vara att analysera och standardisera faktadata.
Du kanske har märkt att vi arbetar med rollen Ansible Network Engine. Naturligtvis, 24K nedladdningar senare, har Network Engine-rollen snabbt blivit en av de mest populära Ansible-rollerna i Ansible Galaxy för nätverksautomationsscenarier. Innan vi flyttade mycket av detta till Ansible 2.8 för att förbereda oss för vad som skulle behövas i Ansible 2.9, tillhandahöll denna Ansible-roll den första uppsättningen verktyg för att hjälpa till att analysera kommandon, hantera kommandon och samla in data för nätverksenheter.
Om du vet hur man använder Network Engine är detta ett mycket effektivt sätt att samla in, analysera och standardisera faktadata för användning i Ansible. Nackdelen med denna roll är att du behöver skapa ett helt gäng parsers för varje plattform och för all nätverksaktivitet. För att förstå hur svårt det är att skapa, skicka och underhålla parsers, ta en titt på från killarna på Cisco.
I ett nötskal, att få fakta från enheter och normalisera dem till nyckel-värdepar är avgörande för automatisering i stor skala, men att uppnå detta är svårt när du har många leverantörer och nätverksplattformar.
Varje nätverksfaktamodul i Ansible 2.9 kan nu analysera konfigurationen av en nätverksenhet och returnera strukturerad data – utan ytterligare bibliotek, Ansible-roller eller anpassade parsers.
Sedan Ansible 2.9, varje gång en uppdaterad nätverksmodul släpps, förbättras faktamodulen för att tillhandahålla data om denna del av konfigurationen. Det vill säga att utvecklingen av fakta och moduler nu sker i samma takt, och de kommer alltid att ha en gemensam datastruktur.
Konfigurationen av resurser på en nätverksenhet kan hämtas och konverteras till strukturerad data på två sätt. På båda sätten kan du samla in och omvandla en specifik lista med resurser med ett nytt nyckelord gather_network_resources. Resursnamnen matchar modulnamnen, vilket är väldigt bekvämt.
När du samlar fakta:
Använda ett nyckelord gather_facts du kan hämta den aktuella enhetskonfigurationen i början av spelboken och sedan använda den genom hela spelboken. Ange de individuella resurserna som ska hämtas från enheten.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueDu kanske har märkt något nytt i dessa exempel, nämligen - gather_facts: true är nu tillgänglig för inbyggd faktainsamling för nätverksenheter.
Använda nätverksfaktamodulen direkt:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesSpelboken returnerar följande fakta om gränssnittet:
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ägg märke till hur Ansible hämtar den inbyggda konfigurationen från Arista-enheten och omvandlar den till strukturerad data för att använda som standard nyckel-värdepar för nedströms uppgifter och operationer.
Gränssnittsfakta kan läggas till Ansible lagrade variabler och användas omedelbart eller senare som indata till en resursmodul eos_interfaces utan ytterligare bearbetning eller konvertering.
Resursmoduler
Så vi extraherade fakta, normaliserade data, passade in dem i ett standardiserat internt datastrukturdiagram och fick en färdig källa till sanning. Hurra! Detta är förstås bra, men vi måste fortfarande på något sätt konvertera nyckel-värdeparen tillbaka till den specifika konfigurationen som den specifika enhetsplattformen förväntar sig. Vi behöver nu plattformsspecifika moduler för att möta dessa nya faktainsamlings- och normaliseringskrav.
Vad är en resursmodul? Du kan tänka på en enhets konfigurationssektioner som resurser som tillhandahålls av den enheten. Nätverksresursmoduler är avsiktligt begränsade till en enda resurs och kan staplas som byggstenar för att konfigurera komplexa nätverkstjänster. Som ett resultat förenklas naturligtvis kraven och specifikationen för en resursmodul, eftersom resursmodulen kan läsa и konfigurera en specifik nätverkstjänst på en nätverksenhet.
För att förklara vad en resursmodul gör, låt oss titta på ett exempel på en spelbok som visar en opåverkad operation med nya nätverksresursfakta och 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 överförs data som samlas in från enheten direkt till motsvarande resursmodul utan konvertering. När den startas hämtar spelboken värden från enheten och jämför dem med förväntade. I det här exemplet är de returnerade värdena som förväntat (det vill säga den kontrollerar konfigurationsavvikelser) och rapporterar om konfigurationen har ändrats.
Det ideala sättet att upptäcka konfigurationsdrift är att lagra fakta i Ansible-lagrade variabler och periodiskt använda dem med resursmodulen i inspektionsläge. Detta är en enkel metod för att se om någon har ändrat värdena manuellt. I de flesta fall tillåter organisationer ändringar och konfiguration manuellt, även om många operationer utförs genom Ansible Automation.
Hur skiljer sig de nya resursmodulerna från de tidigare?
För en nätverksautomationsingenjör finns det tre huvudsakliga skillnader mellan resursmoduler i Ansible 3 och tidigare versioner.
1) För en given nätverksresurs (som också kan ses som en konfigurationssektion), kommer moduler och fakta att utvecklas över alla nätverksoperativsystem som stöds samtidigt. Vi tror att om Ansible stöder resurskonfiguration på en nätverksplattform, bör vi stödja det överallt. Detta förenklar användningen av resursmoduler eftersom en nätverksautomationsingenjör nu kan konfigurera en resurs (som LLDP) på alla nätverksoperativsystem med inbyggda och stödda moduler.
2) Resursmoduler inkluderar nu ett tillståndsvärde.
merged: konfigurationen slås samman med den tillhandahållna konfigurationen (standard);replaced: Resurskonfigurationen kommer att ersättas med den tillhandahållna konfigurationen;overridden: Resurskonfigurationen kommer att ersättas med den tillhandahållna konfigurationen; onödiga resursinstanser kommer att raderas;deleted: Resurskonfigurationen kommer att raderas/återställas till standard.
3) Resursmoduler inkluderar nu stabila returvärden. När nätverksresursmodulen har gjort (eller föreslagit) de nödvändiga ändringarna av nätverksenheten, returnerar den samma nyckel-värdepar till spelboken.
before: konfiguration på enheten i form av strukturerad data före uppgiften;after: om enheten har ändrats (eller kan ändras om testläge används), kommer den resulterande konfigurationen att returneras som strukturerad data;commands: Alla konfigurationskommandon körs på enheten för att få den till önskat läge.
Vad betyder allt detta? Varför är det viktigt?
Det här inlägget täcker många komplexa koncept, men vi hoppas att du i slutändan kommer att få en bättre förståelse för vad företagskunder efterfrågar faktiskt insamling, datanormalisering och loopkonfiguration för en automationsplattform. Men varför behöver de dessa förbättringar? Många organisationer driver nu digital transformation för att göra sina IT-miljöer mer smidiga och konkurrenskraftiga. På gott och ont blir många nätverksingenjörer nätverksutvecklare antingen av egenintresse eller på uppdrag av ledningen.
Organisationer inser att automatisering av enskilda nätverksmallar inte löser problemet med silos och bara ökar effektiviteten i viss utsträckning. Red Hat Ansible Automation Platform tillhandahåller rigorösa och normativa resursdatamodeller för att programmatiskt hantera underliggande data på en nätverksenhet. Det vill säga, användare överger gradvis individuella konfigurationsmetoder till förmån för mer moderna metoder med tonvikt på teknik (till exempel IP-adresser, VLAN, LLDP, etc.), snarare än på en specifik leverantörsimplementering.
Betyder detta att dagarna med pålitliga och beprövade kommandomoduler och konfiguration är räknade? Inte i något fall. De förväntade nätverksresursmodulerna kommer inte att vara tillämpliga i alla fall eller för varje leverantör, så kommando- och konfigurationsmodulerna kommer fortfarande att behövas av nätverksingenjörer för vissa implementeringar. Syftet med resursmoduler är att förenkla stora Jinja-mallar och normalisera ostrukturerade enhetskonfigurationer till ett strukturerat JSON-format. Med resursmoduler blir det lättare för befintliga nätverk att omvandla sin konfiguration till strukturerade nyckel-värdepar som representerar en lättläst källa till sanning. Genom att använda strukturerade nyckel-värdepar kan du gå från att köra konfigurationer på varje enhet till att arbeta med oberoende strukturerad data och föra nätverk i framkant av en infrastruktur-som-kod-metod.
Vilka resursmoduler kommer i Ansible Engine 2.9?
Innan vi berättar i detalj vad som kommer att hända i Ansible 2.9, låt oss komma ihåg hur vi delade upp hela arbetet.
Vi identifierade 7 kategorier och tilldelade specifika nätverksresurser till var och en:
Obs: Resurser i fetstil planerades och implementerades i Ansible 2.9.
Baserat på feedback från företagskunder och samhället var det logiskt att först ta itu med de moduler som är relaterade till nätverkstopologiprotokoll, virtualisering och gränssnitt.
Följande resursmoduler har utvecklats av Ansible Network-teamet och motsvarar de plattformar som stöds av Red Hat:
Följande moduler är utvecklade av Ansible-communityt:
exos_lldp_global- från Extreme Networks.nxos_bfd_interfaces- från Cisconxos_telemetry- från Cisco
Som du kan se passar konceptet med resursmoduler in i vår plattformscentrerade strategi. Det vill säga, vi inkluderar de nödvändiga kapaciteterna och funktionerna i själva Ansible för att stödja standardisering i utvecklingen av nätverksmoduler, och även för att förenkla användarnas arbete på nivån Ansibles roller och spelböcker. För att utöka utvecklingen av resursmoduler släppte Ansible-teamet verktyget Module Builder.
Planer för Ansible 2.10 och senare
När Ansible 2.9 väl har släppts kommer vi att arbeta med nästa uppsättning resursmoduler för Ansible 2.10, som kan användas för att ytterligare konfigurera nätverkstopologi och policy, t.ex. . Utvecklingsplanen kan fortfarande justeras, så om du har synpunkter, vänligen anmäl det till .
Resurser och komma igång
Källa: will.com