In de komende release van Red Hat Ansible Engine 2.9 kunt u indrukwekkende verbeteringen verwachten, waarvan sommige in dit artikel worden beschreven. Zoals gebruikelijk hebben we de verbeteringen voor Ansible Network openbaar ontwikkeld, met de steun van de gemeenschap. Doe mee ā kijk op de en bekijk het ontwikkelingsplan voor op de wiki-pagina voor .
Zoals we onlangs hebben aangekondigd, nu inclusief Ansible Tower, Ansible Engine en alle inhoud van Ansible Network. Momenteel wordt de meeste populaire netwerkplatforms gerealiseerd via Ansible-modules. Bijvoorbeeld:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Een volledige lijst van platforms die volledig worden ondersteund door Red Hat via het Ansible Automation-abonnement, .
Wat we hebben geleerd
In de afgelopen vier jaar hebben we veel geleerd over het ontwikkelen van een platform voor netwerkautomatisering. Daarnaast hebben we ook geleerd dat hoe de artefacten van het platform worden toegepast in playbooks en rollen van Ansible door eindgebruikers. En dit is wat we hebben ontdekt:
- Organisaties automatiseren apparaten van niet Ć©Ć©n, maar van vele leveranciers.
- Automatisering is niet alleen een technische aangelegenheid, maar ook een culturele.
- Schaalautomatisering van netwerken is moeilijker dan het lijkt, vanwege fundamentele architecturale ontwerpprincipes voor automatisering.
Toen we meer dan een jaar geleden onze langetermijnontwikkelingsplannen bespraken, vroegen onze zakelijke klanten om het volgende:
- Het fact verzamelen moet beter gestandaardiseerd en afgestemd worden op de automatiseringsworkflow voor alle apparaten.
- Het bijwerken van configuraties op apparaten moet ook gestandaardiseerd en afgestemd worden, zodat Ansible-modules de tweede helft van de cyclus kunnen verwerken na het verzamelen van feiten.
- Er zijn strenge en ondersteunde methoden nodig om de configuratie van een apparaat om te zetten in gestructureerde gegevens. Op basis hiervan kan de waarheidsgenerator worden verplaatst van het netwerkapparaat.
Verbeteringen van feiten
Het verzamelen van feiten van netwerkapparaten met Ansible gebeurt vaak willekeurig. Netwerkplatforms zijn in verschillende mate uitgerust met mogelijkheden voor het verzamelen van feiten, maar ze hebben bijna geen ā of helemaal geen ā functies voor het parseren en standaardiseren van de weergave van gegevens in sleutel-waarde-paren. Lees Ken Celenza over hoe moeilijk en pijnlijk het kan zijn om feitengegevens te analyseren en te standaardiseren.
Misschien heb je gemerkt dat we aan de rol van Ansible Network Engine hebben gewerkt. Natuurlijk, na 24.000 downloads is de rol van Network Engine snel een van de populairste Ansible-rollen in Ansible Galaxy geworden voor netwerkautomatiseringsscripts. Voordat we veel hiervan naar Ansible 2.8 hebben overgebracht ter voorbereiding op wat nodig zal zijn in Ansible 2.9, bood deze Ansible-rol de eerste set tools om commando's te parseren, teams te beheren en gegevens voor netwerkapparaten te verzamelen.
Als je bekend bent met het gebruik van Network Engine, is het een zeer effectieve manier om gegevensfeiten te verzamelen, parseren en standaardiseren voor gebruik in Ansible. Het nadeel van deze rol is dat er een heleboel parsers voor elk platform en voor alle netwerkactiviteiten moeten worden gemaakt. Om te begrijpen hoe moeilijk het is om parsers te maken, te leveren en te onderhouden, kijk naar van de jongens van Cisco.
Kortom, voor grootschalige automatisering is het cruciaal om feiten van apparaten te verkrijgen en deze te normaliseren in sleutel-waardeparen, maar dat is moeilijk te bereiken wanneer je te maken hebt met veel leveranciers en netwerkplatforms.
Elke netwerk feitmodule in Ansible 2.9 kan nu de configuratie van een netwerkapparaat analyseren en gestructureerde gegevens retourneren - zonder extra bibliotheken, Ansible-rollen of aangepaste parsers.
Met de release van Ansible 2.9 wordt bij elke release van de bijgewerkte netwerkmodule de feitmodule verbeterd om gegevens over dit configuratiegedeelte te leveren. Dit betekent dat de ontwikkeling van feiten en modules nu in hetzelfde tempo plaatsvindt, en ze zullen altijd dezelfde gegevensstructuur delen.
De configuratie van bronnen op een netwerkapparaat kan op twee manieren worden geƫxtraheerd en omgevormd tot gestructureerde gegevens. Beide methoden kunnen een specifieke lijst van bronnen verzamelen en omvormen met het nieuwe sleutelwoord gather_network_resources. De namen van de bronnen komen overeen met de namen van de modules, wat heel praktisch is.
Tijdens het verzamelen van feiten:
Met behulp van het sleutelwoord gather_facts kun je de huidige configuratie van het apparaat aan het begin van de playbook extraheren en deze gedurende de hele playbook gebruiken. Geef de specifieke bronnen op die moeten worden geƫxtraheerd van het apparaat.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueJe hebt misschien iets nieuws opgemerkt in deze voorbeelden, namelijk ā gather_facts: true nu beschikbaar voor het native verzamelen van feiten voor netwerkapparaten.
Gebruik de module voor netwerkfacts direct:
- naam: verzamel interfaceconfiguratiefuncties
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesDe playbook 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: Ethernet1Let op hoe Ansible de native configuratie van het Arista-apparaat extraheert en deze omzet in gestructureerde gegevens voor gebruik als standaard sleutel-waarde paren voor toekomstige taken en operaties.
Interfacefeiten kunnen worden toegevoegd aan opgeslagen Ansible-variabelen en onmiddellijk of later als invoer voor de resource-module worden gebruikt. eos_interfaces zonder verdere verwerking of transformatie.
Resource-modules
Dus, we hebben feiten verzameld, de gegevens genormaliseerd, ze in een gestandaardiseerde interne datastructuur geschreven en hebben een betrouwbare waarheid doel bereikt. Hoera! Dit is zeker geweldig, maar we moeten nog steeds de sleutel-waarde paren op de een of andere manier terugtransformeren naar de specifieke configuratie die een specifiek apparaat verwacht. Nu hebben we modules voor bepaalde platforms nodig om te voldoen aan deze nieuwe eisen voor het verzamelen van feiten en normalisatie.
Wat is een resourcemodule? Apparatuurconfiguratiesecties kunnen worden opgevat als bronnen die door dat apparaat worden geleverd. Netwerkresource-modules zijn opzettelijk beperkt tot Ć©Ć©n bron en kunnen als bouwstenen worden gestapeld om complexe netwerksdiensten te configureren. Hierdoor worden de eisen en specificaties voor de resourcemodule op natuurlijke wijze vereenvoudigd, omdat de resourcemodule kan lezen en een specifieke netwerksdienst op een netwerkapparaat configureren.
Om uit te leggen wat een resourcemodule doet, laten we kijken naar een voorbeeld playbook dat een idempotente operatie laat zien met gebruik van de nieuwe netwerkresource feiten en de module eos_l3_interface.
- naam: voorbeeld van feiten die direct terug naar het apparaat worden gepusht.
hosts: arista
verzamel_feiten: false
taken:
- naam: pak arista eos feiten
eos_facts:
verzamel_subset: min
verzamel_netwerkbronnen: l3_interfaces
- naam: zorg ervoor dat de IP-adresinformatie nauwkeurig is
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
registreer: resultaat
- naam: zorg ervoor dat de configuratie niet is gewijzigd
assert:
dat: niet resultaat.veranderdZoals u kunt zien, worden de gegevens die van het apparaat zijn verzameld, rechtstreeks aan de bijbehorende hulpbronmodule doorgegeven zonder conversie. Bij het uitvoeren van de playbook worden waarden van het apparaat opgehaald en met de verwachte waarden vergeleken. In dit voorbeeld komen de verkregen waarden overeen met de verwachte waarden (dat wil zeggen, de configuratieafwijkingen worden gecontroleerd) en er wordt een bericht gegeven of de configuratie is gewijzigd.
De ideale manier om een configuratieafwijking te ontdekken, is door feiten op te slaan in opgeslagen Ansible-variabelen en deze regelmatig te gebruiken met de hulpbronmodule in de verificatiemodus. Dit is een eenvoudige methode om te zien of iemand waarden handmatig heeft gewijzigd. In de meeste gevallen staan organisaties handmatige wijzigingen en configuratie toe, hoewel veel operaties via Ansible Automation worden uitgevoerd.
Wat maakt de nieuwe hulpbronmodules anders dan de vorige versies?
Voor een netwerkautomatiseringsingenieur zijn er 3 belangrijkste verschillen tussen de hulpbronmodules in Ansible 2.9 en eerdere versies.
1) Voor een specifieke netwerkbron (die ook kan worden gezien als een configuratiegedeelte) zullen modules en feiten zich tegelijkertijd ontwikkelen in alle ondersteunde netwerkbesturingssystemen. We denken dat als Ansible de configuratie van een bron op Ć©Ć©n netwerkplatform ondersteunt, we dit overal moeten ondersteunen. Dit vereenvoudigt het gebruik van hulpbronmodules, omdat een netwerkautomatiseringsingenieur nu een bron (bijvoorbeeld LLDP) kan configureren in alle netwerkbesturingssystemen met native en ondersteunde modules.
2) Hulpbronmodules bevatten nu een statuswaarde.
samengevoegd: de configuratie is samengevoegd met de verstrekte configuratie (standaard);vervangen: de configuratie van de bron wordt vervangen door de verstrekte configuratie;overschreven: de configuratie van de bron wordt vervangen door de verstrekte configuratie; overbodige exemplaren van de bronnen worden verwijderd;deleted: de configuratie van de bron wordt verwijderd/hersteld naar de standaard.
3) De modulebronnen omvatten nu stabiele teruggegeven waarden. Wanneer de netwerkbronmodule de noodzakelijke wijzigingen in het netwerkapparaat aanbrengt (of voorstelt), retourneert deze dezelfde sleutel-waarde paren naar het playbook.
voor: configuratie op het apparaat in de vorm van gestructureerde gegevens vĆ³Ć³r de taak;na: als het apparaat is gewijzigd (of kan worden gewijzigd als de controlemodus wordt gebruikt), wordt de resulterende configuratie geretourneerd als gestructureerde gegevens;opdrachten: alle configuratieopdrachten die op het apparaat zijn uitgevoerd om het in de gewenste staat te brengen.
Wat betekent dit allemaal? Waarom is het belangrijk?
In deze post worden veel complexe concepten besproken, maar we hopen dat je uiteindelijk beter begrijpt dat zakelijke klanten vragen om feitverzameling, normalisatie van gegevens en configuratiecycli voor het automatiseringsplatform. Maar waarom hebben ze deze verbeteringen nodig? Veel organisaties zijn momenteel bezig met digitale transformatie om hun IT-omgevingen flexibeler en competitiever te maken. Of dit goed of slecht is, veel netwerkingenieurs worden netwerkontwikkelaars ā uit eigen interesse of op aandringen van leidinggevenden.
Organisaties begrijpen dat automatisering van afzonderlijke netwerktemplates het probleem van versnippering niet oplost en de efficiƫntie slechts tot op zekere hoogte verhoogt. Het Red Hat Ansible Automation Platform biedt strikte en normaliserende gegevensmodellen voor bronnen om programmatisch de basisgegevens op netwerkapparaten te beheren. Dit betekent dat gebruikers geleidelijk afstappen van individuele configuratiemethoden ten gunste van modernere technieken met de nadruk op technologieƫn (zoals IP-adressen, VLAN, LLDP, enz.), in plaats van op specifieke implementaties van leveranciers.
Betekent dit dat de dagen van betrouwbare en beproefde command-modules en configuraties geteld zijn? Absoluut niet. De verwachte netwerkbronnen zullen niet in alle gevallen en niet voor elke leverancier toepasbaar zijn, dus de command-modules en configuraties zullen nog steeds nodig zijn voor bepaalde implementaties door netwerkingenieurs. Het doel van de bronnenmodules is om grote Jinja-sjablonen te vereenvoudigen en niet-gestructureerde apparaatconfiguraties om te zetten in een gestructureerd JSON-formaat. Met de bronnenmodules zal het voor bestaande netwerken gemakkelijker zijn om hun configuraties om te zetten in gestructureerde sleutel-waarde paren, die zullen dienen als een leesbare waarheid. Door gestructureerde sleutel-waarde paren te gebruiken, kunnen we overstappen van het runnen van configuraties op elk apparaat naar het werken met onafhankelijke gestructureerde gegevens en netwerken vooropstellen in de 'infrastructuur als code' aanpak.
Welke bronnenmodules komen er in Ansible Engine 2.9?
Voordat we in detail ingaan op wat er in Ansible 2.9 te wachten staat, laten we even terugblikken op hoe we het totale werk hebben verdeeld.
We hebben 7 categorieƫn gedefinieerd en aan elke categorie specifieke netwerkbronnen toegewezen:
Opmerking: bronnen die vetgedrukt zijn, waren gepland en geĆÆmplementeerd in Ansible 2.9.
Gebaseerd op feedback van zakelijke klanten en de gemeenschap was het logisch om eerst te focussen op de modules die verband houden met netwerktopologieprotocollen, virtualisatie en interfaces.
De volgende bronnenmodules zijn ontwikkeld door het Ansible Network-team en zijn gericht op de platforms die door Red Hat worden ondersteund:
De volgende modules zijn ontwikkeld door de Ansible-gemeenschap:
exos_lldp_globalā van Extreme Networks.nxos_bfd_interfacesā van Cisconxos_telemetryā van Cisco
Zoals je kunt zien, past het concept van bronnenmodules in onze strategie om ons op platformen te richten. Dit betekent dat we de noodzakelijke mogelijkheden en functies in Ansible zelf opnemen om standaardisatie te ondersteunen bij de ontwikkeling van netwerkmodules, en om het werk voor gebruikers op het niveau van rollen en playbooks in Ansible te vereenvoudigen. Om de ontwikkeling van bronnenmodules uit te breiden, heeft het Ansible-team een tool genaamd Module Builder uitgebracht.
Plannen voor Ansible 2.10 en verder
Na de release van Ansible 2.9 gaan we ons richten op de volgende set bronnenmodules voor Ansible 2.10, die kunnen worden gebruikt voor verdere aanpassing van netwerktopologie en beleid, zoals Het ontwikkelingsplan kan nog worden aangepast, dus als u opmerkingen heeft, laat het ons weten in .
Resources en hoe aan de slag te gaan
Bron: habr.com
