🥇The Inside Playbook. Nätverksfunktioner i den nya Ansible Engine 2.9

I den kommande utgåvan av Red Hat Ansible Engine 2.9 förväntar vi oss imponerande förbättringar, varav några beskrivs i denna artikel. Som vanligt har vi utvecklat förbättringarna av Ansible Network öppet, med stöd från gemenskapen. Gå med oss – ta en titt på issuesidan på GitHub och utforska utvecklingsplanen för släppet av Red Hat Ansible Engine 2.9 på wikisidan för Ansible Network.

Som vi nyligen meddelade, Red Hat Ansible Automation Platform inkluderar nu Ansible Tower, Ansible Engine och allt innehåll från Ansible Network. Just nu implementeras de flesta populära nätverksplattformar genom Ansible-moduler. Till exempel:

Arista EOS
Cisco IOS
Cisco IOS XR
Cisco NX-OS
Juniper Junos
VyOS

En fullständig lista över plattformar som fullt stödjs av Red Hat genom Ansible Automation-prenumeration, publiceras här.

Vad vi har lärt oss

Under de senaste fyra åren har vi lärt oss mycket om att utveckla en plattform för nätverksautomatisering. Vi har också lärt oss att som artefakterna från plattformen tillämpas i playbooks och roller inom Ansible ur slutanvändarnas perspektiv. Och här är vad vi har kommit fram till:

Organisationer automatiserar inte bara en, utan många leverantörers enheter.
Automatisering är inte bara ett tekniskt fenomen, utan också en kulturell sådan.
Storskalig automatisering av nätverk är mer komplex än det verkar, på grund av grundläggande arkitektoniska designprinciper för automatisering.

När vi diskuterade våra långsiktiga utvecklingsplaner för mer än ett år sedan, bad våra företagskunder om följande:

Faktainsamlingen måste standardiseras bättre och anpassas till automatiseringsarbetsflödet för alla enheter.
Uppdatering av konfigurationer på enheten behöver också standardiseras och anpassas så att Ansible-moduler kan hantera den andra halvan av cykeln efter faktainsamlingen.
Det behövs strikta och stödjande metoder för att konvertera enhetskonfigurationer till strukturerade data. På den grunden kan källan till sanningen flyttas från nätverksenheten.

Förbättringar av faktainsamling

Faktainsamling från nätverksenheter med hjälp av Ansible sker ofta på måfå. Nätverksplattformar är i olika grad utrustade med funktioner för faktainsamling, men de har nästan inga – eller inga alls – funktioner för att analysera och standardisera representationen av data i nyckel-värde-par. Läs mer inlägg Ken Celenza om hur utmanande och plågsamt det kan vara att analysera och standardisera faktadata.

Du kanske har märkt hur vi har arbetat med rollen Ansible Network Engine. Efter 24 000 nedladdningar har Network Engine-rollen snabbt blivit en av de mest populära rollerna i Ansible Galaxy för automatiseringsskript för nätverket. Innan vi flyttade mycket av detta till Ansible 2.8 för att förbereda oss för vad som krävs i Ansible 2.9, gav denna Ansible-roll det första verktyget för att hjälpa till med parsning av kommandon, hantering av kommandon och insamling av data för nätverksutrustning.

Om du är bekant med användningen av Network Engine är det ett mycket effektivt sätt att samla, parsa och standardisera faktadata för användning i Ansible. Nackdelen med denna roll är att det krävs en mängd parser för varje plattform och för all nätverksaktivitet. För att förstå hur utmanande det är att skapa, leverera och underhålla parsers, kolla in över 1200 parsers från grabbarna på Cisco.

Kort sagt, för storskalig automatisering är det avgörande att hämta fakta från enheter och normalisera dem till nyckel-värde-par, men det är svårt när du har många leverantörer och nätverksplattformar.

Varje faktormodul för nätverk i Ansible 2.9 kan nu analysera konfigurationen av nätverksutrustningen och återge strukturerade data - utan extra bibliotek, Ansible-roller eller anpassade parsers.

Från och med Ansible 2.9 förbättras faktormodulen med varje utgivning av den uppdaterade nätverksmodulen för att tillhandahålla data om den här delen av konfigurationen. Det betyder att utvecklingen av fakta och moduler nu sker i takt med varandra, och de kommer alltid att ha en gemensam datastruktur.

Konfigurationen av resurser på nätverksutrustningen kan extraheras och omvandlas till strukturerade data på två sätt. Båda sätten gör det möjligt att samla och omvandla en specifik lista av resurser med den nya nyckelordet gather_network_resources. Resursnamnen motsvarar modulernas namn, vilket är mycket praktiskt.

Under faktainsamlingsprocessen:

Med hjälp av nyckelordet gather_facts kan den aktuella konfigurationen av enheten extraheras i början av playbooken och sedan användas genom hela playbooken. Ange specifika resurser som ska extraheras från enheten.

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

Du kanske har lagt märke till något nytt i dessa exempel, nämligen — gather_facts: true nu tillgängliga för att samla in fakta nativt för nätverksenheter.

Använda modulen för nätverksfakta direkt:

- name: samla in gränssnittsconfigurationsfakta
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Spelbok återger 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: Ethernet1

Observera hur Ansible hämtar den nativa konfigurationen från Arista-enheten och omvandlar den till strukturerade data för att använda som standardnyckel-värde-par för efterföljande uppgifter och operationer.

Gränssnittsdata kan läggas till i Ansible:s lagrade variabler och användas direkt eller senare som indata för modulen resurs eos_interfaces utan ytterligare bearbetning eller omvandling.

Resursmoduler

Så, vi har extraherat fakta, normaliserat data, skrivit dem i en standardiserad intern datamodell och fått en klar källa till sanning. Hurra! Det är naturligtvis fantastiskt, men vi behöver fortfarande på något sätt omvandla nyckel-värde-paren tillbaka till den specifika konfiguration som en viss enhetsplattform förväntar sig. Nu behöver vi moduler för specifika plattformar för att möta dessa nya krav på faktainsamling och normalisering.

Vad är en resursmodul? Konfigurationsavsnitt för en enhet kan ses som resurser som tillhandahålls av den här enheten. Nätverksresursmoduler är avsiktligt begränsade till en resurs och kan staplas som byggstenar för att konfigurera komplexa nätverkstjänster. Som ett resultat förenklas kraven och specifikationen för en resursmodul naturligt, eftersom resursmodulen kan läsa och konfigurera en specifik nätverkstjänst på nätverksenheten.

För att förklara vad en resursmodul gör, låt oss se på ett exempelspelbok som visar en identisk operation med hjälp av de nya fakta om nätverksresurs och modulen eos_l3_interface.

- namn: exempel på fakta som skickas tillbaka till enheten.
  hosts: arista
  gather_facts: false
  tasks:
  - namn: hämta arista eos-fakta
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - namn: säkerställa att IP-adressinformationen är korrekt
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - namn: säkerställa att konfigurationen inte har ändrats
    assert:
      that: not result.changed

Som ni ser har data som samlats in från enheten överförts direkt till den relevanta resursmodulen utan omvandling. När playbook körs hämtar den värden från enheten och jämför dem med förväntade. I det här exemplet motsvarar de extraherade värdena de förväntade (det vill säga en konfigurationsavvikelse kontrolleras) och ett meddelande ges om huruvida konfigurationen har ändrats.

Det perfekta sättet att upptäcka konfigurationsavvikelser är att spara fakta i lagrade Ansible-variabler och regelbundet använda dem tillsammans med resursmodulen i kontrolläge. Detta är en enkel metod för att se om någon har ändrat värden manuellt. I de flesta fall tillåter organisationer handändringar och konfiguration, även om många operationer utförs genom Ansible Automation.

Vad skiljer de nya resursmodulerna från tidigare?

Det finns 3 huvudsakliga skillnader för en nätverksautomationstekniker mellan resursmodulerna i Ansible 2.9 och tidigare versioner.

1) För en specifik nätverksresurs (som också kan ses som ett konfigurationsavsnitt) kommer moduler och fakta att utvecklas i alla stödda nätverksoperativsystem samtidigt. Vi anser att om Ansible stöder resurskonfigurationen på en nätverksplattform så bör vi stödja det överallt. Detta förenklar användningen av resursmodulerna, eftersom nätverksautomationsteknikern nu kan konfigurera resursen (till exempel LLDP) i alla nätverksoperativsystem med inbyggda och stödda moduler.

2) Resursmoduler inkluderar nu värdet av tillstånd.

sammanfogad: konfigurationen är sammanfogad med den tillhandahållna konfigurationen (som standard);
ersatt: resurskonfigurationen kommer att ersättas med den tillhandahållna konfigurationen;
överskriden: resurskonfigurationen kommer att ersättas med den tillhandahållna konfigurationen; överflödiga resursinstanser kommer att tas bort;
borttagen: resurskonfigurationen kommer att tas bort / återställas som standard.

3) Resursmoduler inkluderar nu stabila återlämnade värden. När nätverksresursmodulen gör (eller föreslår) nödvändiga ändringar i nätverksenheten returneras samma nyckel-värde-par till playbooken.

before: konfiguration på enheten i form av strukturerade data fram till uppgiften;
efter: om enheten har ändrats (eller kan förändras om kontrollläge används), kommer den resulterande konfigurationen att returneras i form av strukturerade data;
kommandon: alla konfigurationskommandon som körs på enheten för att få den i önskat tillstånd.

Vad betyder allt detta? Varför är det viktigt?

I detta inlägg beskrivs många komplexa koncept, men vi hoppas att du tillslut kommer att bättre förstå vad företagskunder efterfrågar i termer av faktainsamling, datanormalisering och konfigurationscykler för automatiseringsplattformar. Men varför behöver de dessa förbättringar? Just nu genomgår många organisationer en digital transformation för att göra sina IT-miljöer mer flexibla och konkurrenskraftiga. Oavsett om det är bra eller dåligt, så blir många nätverksingenjörer nätverksutvecklare — antingen av eget intresse eller på direktiv från ledningen.

Organisationer inser att automatisering av enskilda nätverksmallar inte löser problemet med fragmentering och ökar effektiviteten endast upp till en viss gräns. Red Hat Ansible Automation Platform tillhandahåller strikta och normerande datamodeller för resurser för att programmatisk hantering av grunddata på nätverksenheten. Det innebär att användare gradvis överger individuella konfigurationsmetoder till förmån för mer moderna metoder med fokus på teknik (till exempel IP-adresser, VLAN, LLDP, etc.), snarare än specifika vendorimplementationer.

Betyder det att dagarna för pålitliga och beprövade moduler för kommandon och konfigurationer är räknade? Absolut inte. De förväntade modulerna för nätverksresurser kommer inte att tillämpas i alla fall och inte för varje leverantör, så moduler för kommandon och konfigurationer kommer fortfarande att behövas av nätverksingenjörer för specifika implementationer. Syftet med resurserna är att förenkla stora Jinja-mallar och normalisera ostrukturerade enhetskonfigurationer i ett strukturerat JSON-format. Med resurserna kommer existerande nätverk att lättare kunna omvandla sin konfiguration till strukturerade nyckel-värde-par, som kommer att utgöra en läsbar källa till sanning. Genom att använda strukturerade nyckel-värde-par kan man gå från att köra konfigurationer på varje enhet till att arbeta med oberoende strukturerade data och sätta nätverken i fokus med en "infrastruktur som kod"-ansats.

Vilka resurser kommer att finnas i Ansible Engine 2.9?

Innan vi går in på detaljer om vad som kommer att ingå i Ansible 2.9, låt oss påminna oss om hur vi har delat upp hela arbetsomfånget.

Vi har identifierat 7 kategorier och tilldelat specifika nätverksresurser till var och en:

Obs: Ressourcer markerade med fet stil var planerade och implementerade i Ansible 2.9.
Baserat på feedback från företagskunder och communityn var det logiskt att först fokusera på de moduler som relaterar till nätverkstopologi, virtualisering och gränssnitt.
Följande resurser har utvecklats av Ansible Network-teamet och motsvarar de plattformar som stöds av Red Hat:

Följande moduler har utvecklats av Ansible-communityn:

exos_lldp_global — från Extreme Networks.
nxos_bfd_interfaces — från Cisco
nxos_telemetry — från Cisco

Som ni ser passar konceptet med resurser in i vår plattformsorienterade strategi. Det innebär att vi inkluderar de nödvändiga funktionerna och egenskaperna i själva Ansible för att stödja standardisering vid utvecklingen av nätverksmoduler och ytterligare förenkla användarnas arbete på nivåerna roller och Ansible-spel. För att utöka utvecklingen av moduler har Ansible-teamet släppt verktyget Module Builder.

Planer för Ansible 2.10 och framåt

Efter lanseringen av Ansible 2.9 kommer vi att ta oss an nästa uppsättning resurser för Ansible 2.10, som kommer att kunna användas för ytterligare anpassning av nätverkets topologi och policy, såsom ACL, OSPF och BGPUtvecklingsplanen kan fortfarande justeras, så om du har några kommentarer, vänligen meddela det i Ansible Network-gemenskapen.