De komende release van Red Hat Ansible Engine 2.9 brengt spannende verbeteringen met zich mee, waarvan er enkele in dit artikel worden besproken. Zoals altijd hebben we Ansible Network-verbeteringen openlijk ontwikkeld, met steun van de gemeenschap. Doe met ons mee - kijk eens naar en bestudeer het ontwikkelingsplan voor op de wikipagina voor .
Zoals we onlangs hebben aangekondigd, bevat nu Ansible Tower, Ansible Engine en alle Ansible Network-inhoud. Tegenwoordig worden de meeste populaire netwerkplatforms geïmplementeerd via Ansible-modules. Bijvoorbeeld:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX OS
- Jeneverbes Junos
- VyOS
Voor een volledige lijst met platforms die volledig worden ondersteund door Red Hat via een Ansible Automation-abonnement, .
Wat hebben we geleerd
De afgelopen vier jaar hebben we veel geleerd over het ontwikkelen van een netwerkautomatiseringsplatform. Dat hebben wij ook geleerd hoe platformartefacten worden door eindgebruikers gebruikt in Ansible-playbooks en -rollen. En dit is wat we ontdekten:
- Organisaties automatiseren apparaten van niet slechts één, maar vele leveranciers.
- Automatisering is niet alleen een technisch fenomeen, maar ook een cultureel fenomeen.
- Het automatiseren van netwerken op schaal is moeilijker dan het lijkt vanwege de fundamentele architectonische principes van automatiseringsontwerp.
Toen we ruim een jaar geleden onze groeiplannen voor de lange termijn bespraken, vroegen onze zakelijke klanten om het volgende:
- Het verzamelen van feiten moet beter worden gestandaardiseerd en afgestemd op de automatiseringsworkflows op alle apparaten.
- Het updaten van configuraties op het apparaat moet ook gestandaardiseerd en consistent zijn, zodat Ansible-modules de tweede helft van de cyclus kunnen afhandelen na het verzamelen van feiten.
- We hebben rigoureuze en ondersteunde methoden nodig voor het omzetten van apparaatconfiguratie in gestructureerde gegevens. Op basis hiervan kan de bron van de waarheid van het netwerkapparaat worden verplaatst.
Feitelijke verbeteringen
Het verzamelen van feiten van netwerkapparaten met behulp van Ansible gebeurt vaak willekeurig. Webgebaseerde platforms hebben verschillende mogelijkheden voor het verzamelen van feiten, maar ze hebben weinig of geen functionaliteit voor het parseren en standaardiseren van de representatie van gegevens in sleutel-waardeparen. Lezen Ken Celenza over hoe moeilijk en pijnlijk het kan zijn om feitelijke gegevens te analyseren en te standaardiseren.
Je hebt misschien gemerkt dat we aan de Ansible Network Engine-rol werken. Uiteraard, 24K downloads later, is de Network Engine-rol snel een van de meest populaire Ansible-rollen in Ansible Galaxy geworden voor scenario's voor netwerkautomatisering. Voordat we een groot deel hiervan naar Ansible 2.8 verplaatsten ter voorbereiding op wat nodig zou zijn in Ansible 2.9, bood deze Ansible-rol de eerste set tools om opdrachten te ontleden, opdrachten te beheren en gegevens voor netwerkapparaten te verzamelen.
Als u weet hoe u Network Engine moet gebruiken, is dit een zeer efficiënte manier om feitengegevens te verzamelen, parseren en standaardiseren voor gebruik in Ansible. Het nadeel van deze rol is dat je voor elk platform en voor alle netwerkactiviteiten een hele reeks parsers moet maken. Als u wilt begrijpen hoe moeilijk het is om parsers te maken, verzenden en onderhouden, kunt u een kijkje nemen op van de jongens van Cisco.
Kortom: het verkrijgen van feiten uit apparaten en het normaliseren ervan in sleutel-waardeparen is essentieel voor automatisering op schaal, maar het bereiken hiervan is moeilijk als je veel leveranciers en netwerkplatforms hebt.
Elke netwerkfeitenmodule in Ansible 2.9 kan nu de configuratie van een netwerkapparaat analyseren en gestructureerde gegevens retourneren - zonder extra bibliotheken, Ansible-rollen of aangepaste parsers.
Sinds Ansible 2.9 wordt de feitenmodule elke keer dat er een bijgewerkte netwerkmodule wordt uitgebracht, verbeterd om gegevens over dit gedeelte van de configuratie te leveren. Dat wil zeggen dat de ontwikkeling van feiten en modules nu in hetzelfde tempo plaatsvindt en dat ze altijd een gemeenschappelijke datastructuur zullen hebben.
De configuratie van bronnen op een netwerkapparaat kan op twee manieren worden opgehaald en omgezet in gestructureerde gegevens. Op beide manieren kunt u een specifieke lijst met bronnen verzamelen en transformeren met behulp van een nieuw trefwoord gather_network_resources. De resourcenamen komen overeen met de modulenamen, wat erg handig is.
Tijdens het verzamelen van feiten:
Een trefwoord gebruiken gather_facts u kunt de huidige apparaatconfiguratie aan het begin van het draaiboek ophalen en deze vervolgens in het hele draaiboek gebruiken. Geef de afzonderlijke bronnen op die van het apparaat moeten worden opgehaald.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueHet is je misschien iets nieuws opgevallen in deze voorbeelden, namelijk: gather_facts: true is nu beschikbaar voor native feitenverzameling voor netwerkapparaten.
Direct gebruik maken van de netwerkfeitenmodule:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesHet draaiboek retourneert de volgende feiten over de interface:
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: Ethernet1Merk op hoe Ansible de oorspronkelijke configuratie van het Arista-apparaat ophaalt en deze omzet in gestructureerde gegevens om te gebruiken als standaard sleutel-waardeparen voor downstream-taken en -bewerkingen.
Interfacefeiten kunnen worden toegevoegd aan opgeslagen Ansible-variabelen en onmiddellijk of later worden gebruikt als invoer voor een resourcemodule eos_interfaces zonder aanvullende bewerking of conversie.
Bronmodules
Dus haalden we de feiten eruit, normaliseerden de gegevens, pasten ze in een gestandaardiseerd intern datastructuurdiagram en kregen een kant-en-klare bron van waarheid. Hoera! Dit is natuurlijk geweldig, maar we moeten de sleutel-waardeparen op de een of andere manier nog steeds omzetten naar de specifieke configuratie die het specifieke apparaatplatform verwacht. We hebben nu platformspecifieke modules nodig om aan deze nieuwe vereisten voor het verzamelen en normaliseren van feiten te voldoen.
Wat is een resourcemodule? U kunt de configuratiesecties van een apparaat beschouwen als bronnen die door dat apparaat worden geleverd. Netwerkbronmodules zijn opzettelijk beperkt tot één enkele bron en kunnen als bouwstenen worden gestapeld om complexe netwerkdiensten te configureren. Als gevolg hiervan worden de vereisten en specificaties voor een resourcemodule op natuurlijke wijze vereenvoudigd, aangezien de resourcemodule kan lezen и een specifieke netwerkservice configureren op een netwerkapparaat.
Laten we, om uit te leggen wat een bronmodule doet, eens kijken naar een voorbeeld van een draaiboek dat een idempodent-bewerking laat zien met behulp van nieuwe netwerkbronfeiten en module 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.changedZoals u kunt zien, worden de door het apparaat verzamelde gegevens zonder conversie rechtstreeks naar de overeenkomstige bronmodule overgedragen. Bij het starten haalt het playbook waarden op van het apparaat en vergelijkt deze met de verwachte waarden. In dit voorbeeld zijn de geretourneerde waarden zoals verwacht (dat wil zeggen, er wordt gecontroleerd op configuratieafwijkingen) en wordt gerapporteerd of de configuratie is gewijzigd.
De ideale manier om configuratieafwijkingen te detecteren is door feiten op te slaan in opgeslagen Ansible-variabelen en deze periodiek te gebruiken met de resourcemodule in inspectiemodus. Dit is een eenvoudige methode om te zien of iemand de waarden handmatig heeft gewijzigd. In de meeste gevallen staan organisaties wijzigingen en configuratie handmatig toe, hoewel veel bewerkingen worden uitgevoerd via Ansible Automation.
Hoe verschillen de nieuwe resourcemodules van de vorige?
Voor een netwerkautomatiseringsingenieur zijn er drie belangrijke verschillen tussen bronmodules in Ansible 3 en eerdere versies.
1) Voor een bepaalde netwerkbron (die ook kan worden gezien als een configuratiesectie) zullen modules en feiten tegelijkertijd evolueren over alle ondersteunde netwerkbesturingssystemen. Wij zijn van mening dat als Ansible de configuratie van bronnen op één netwerkplatform ondersteunt, we dit overal moeten ondersteunen. Dit vereenvoudigt het gebruik van resourcemodules omdat een netwerkautomatiseringsingenieur nu een resource (zoals LLDP) kan configureren op alle netwerkbesturingssystemen met native en ondersteunde modules.
2) Resourcemodules bevatten nu een statuswaarde.
merged: de configuratie wordt samengevoegd met de opgegeven configuratie (standaard);replaced: De resourceconfiguratie wordt vervangen door de opgegeven configuratie;overridden: De resourceconfiguratie wordt vervangen door de opgegeven configuratie; onnodige resource-instanties worden verwijderd;deleted: De bronconfiguratie wordt verwijderd/teruggezet naar de standaardwaarde.
3) Hulpbronmodules bevatten nu stabiele retourwaarden. Wanneer de netwerkbronmodule de noodzakelijke wijzigingen aan het netwerkapparaat heeft aangebracht (of voorgesteld), stuurt deze dezelfde sleutel-waardeparen terug naar het speelboek.
before: configuratie op het apparaat in de vorm van gestructureerde gegevens vóór de taak;after: als het apparaat is gewijzigd (of kan veranderen als de testmodus wordt gebruikt), wordt de resulterende configuratie geretourneerd als gestructureerde gegevens;commands: Alle configuratieopdrachten worden op het apparaat uitgevoerd om het in de gewenste staat te brengen.
Wat betekent dit allemaal? Waarom is het belangrijk?
Dit bericht behandelt veel complexe concepten, maar we hopen dat je uiteindelijk een beter begrip zult krijgen van waar zakelijke klanten om vragen, namelijk verzameling, datanormalisatie en lusconfiguratie voor een automatiseringsplatform. Maar waarom hebben ze deze verbeteringen nodig? Veel organisaties streven nu naar digitale transformatie om hun IT-omgevingen flexibeler en competitiever te maken. In goede en slechte tijden worden veel netwerkingenieurs netwerkontwikkelaars, hetzij uit eigenbelang, hetzij in opdracht van het management.
Organisaties realiseren zich dat het automatiseren van individuele netwerksjablonen het probleem van silo’s niet oplost en de efficiëntie slechts tot op zekere hoogte verhoogt. Het Red Hat Ansible Automation Platform biedt rigoureuze en normatieve resourcedatamodellen om de onderliggende data op een netwerkapparaat programmatisch te beheren. Dat wil zeggen dat gebruikers geleidelijk individuele configuratiemethoden opgeven ten gunste van modernere methoden met de nadruk op technologieën (bijvoorbeeld IP-adressen, VLAN's, LLDP, enz.), in plaats van op een specifieke leveranciersimplementatie.
Betekent dit dat de dagen van betrouwbare en bewezen commandomodules en configuratie geteld zijn? In geen geval. De verwachte netwerkbronmodules zullen niet in alle gevallen of voor elke leverancier toepasbaar zijn, dus de opdracht- en configuratiemodules zullen voor bepaalde implementaties nog steeds nodig zijn voor netwerkingenieurs. Het doel van resourcemodules is om grote Jinja-sjablonen te vereenvoudigen en ongestructureerde apparaatconfiguraties te normaliseren naar een gestructureerd JSON-formaat. Met resourcemodules zal het voor bestaande netwerken gemakkelijker zijn om hun configuratie om te zetten in gestructureerde sleutel-waardeparen die een gemakkelijk leesbare bron van waarheid vertegenwoordigen. Door gestructureerde sleutel-waardeparen te gebruiken, kunt u overstappen van het uitvoeren van configuraties op elk apparaat naar het werken met onafhankelijke gestructureerde gegevens en netwerken op de voorgrond plaatsen van een infrastructuur-als-code-aanpak.
Welke resourcemodules komen er in Ansible Engine 2.9?
Voordat we u in detail vertellen wat er zal gebeuren in Ansible 2.9, laten we onthouden hoe we de hele reikwijdte van het werk hebben verdeeld.
We hebben zeven categorieën geïdentificeerd en aan elke categorie specifieke netwerkbronnen toegewezen:
Opmerking: de vetgedrukte bronnen zijn gepland en geïmplementeerd in Ansible 2.9.
Op basis van feedback van zakelijke klanten en de gemeenschap was het logisch om eerst die modules aan te pakken die verband hielden met netwerktopologieprotocollen, virtualisatie en interfaces.
De volgende resourcemodules zijn ontwikkeld door het Ansible Network-team en komen overeen met de platforms die door Red Hat worden ondersteund:
De volgende modules zijn ontwikkeld door de Ansible-gemeenschap:
exos_lldp_global- van Extreme Netwerken.nxos_bfd_interfaces- van Cisconxos_telemetry- van Cisco
Zoals u kunt zien, past het concept van resourcemodules in onze platformgerichte strategie. Dat wil zeggen dat we de noodzakelijke mogelijkheden en functies in Ansible zelf opnemen om standaardisatie bij de ontwikkeling van netwerkmodules te ondersteunen, en ook om het werk van gebruikers op het niveau van Ansible-rollen en draaiboeken te vereenvoudigen. Om de ontwikkeling van resourcemodules uit te breiden, heeft het Ansible-team de Module Builder-tool uitgebracht.
Plannen voor Ansible 2.10 en hoger
Zodra Ansible 2.9 is uitgebracht, zullen we werken aan de volgende reeks bronmodules voor Ansible 2.10, die kunnen worden gebruikt om de netwerktopologie en het beleid verder te configureren, b.v. . Het ontwikkelplan kan nog worden aangepast, dus heeft u opmerkingen, meld dit dan bij .
Hulpbronnen en aan de slag
Bron: www.habr.com