GitOps Pipeline voor een Execution Environment (EE) met Ansible Collections

Projecten: c2platform/rws/ansible-gis , c2platform/ansible-collection-core , c2platform/ansible-collection-mw , c2platform/rws/ansible-execution-environment , c2platform/ansible-collection-mgmt

Introductie

Bij gebruik van het Ansible Automation Platform (AAP) zijn er drie strategieën voor het beheren van Ansible-collecties:

1. Verwerk collecties in de EE.
2. Haal collecties op met behulp van requirements.yml¹.
3. Een combinatie van beide.

Elke aanpak heeft zijn voor- en nadelen. Een belangrijk nadeel van het gebruik van een EE is dat de EE en zijn versie extern zijn gedefinieerd in AAP, waardoor een pure GitOps-benadering wordt voorkomen. Deze handleiding beschrijft hoe je een AAP Workflow en een Ansible Job Template gebruikt om AAP te configureren zodat een specifieke EE-versie wordt gebruikt voordat andere Job Templates worden uitgevoerd. Het Job Template maakt gebruik van de Ansible-rol c2platform.mgmt.awx om de EE-versie te beheren. Red Hat raadt aan om alleen de EE te gebruiken om prestatieredenen².

Collectie Strategieën

Gebruik alleen het bestand requirements.yml

Dit is eenvoudig en flexibel, geschikt aan het begin van een project wanneer veel updates aan collecties worden gedaan. Het nadeel is langere jobtijden omdat collecties telkens weer worden opgehaald.

---
collections:
   - name: c2platform.core
      version: 1.0.21
   - name: https://gitlab.com/c2platform/rws/ansible-collection-wincore.git
      type: git
      version: master

Toon Diagram

Gebruik alleen de EE

Jobs worden sneller uitgevoerd op AWX. Het nadeel is de behoefte om nieuwe versies van de collectie en EE vrij te geven en handmatig de nieuwe EE-versie in AWX te configureren³.

Toon Diagram

Gebruik zowel de EE als de requirements.yml

Voeg community-collecties toe aan de EE en gebruik requirements.yml voor regelmatig bijgewerkte collecties.

Een nadeel van het toevoegen van collecties aan de EE is dat het een DTAP-promotiemodel in Git ingewikkelder maakt. Dit kan worden opgelost door een workflow in AWX in te richten die de juiste EE-versie configureert.

Vereisten

• Zorg ervoor dat gsd-awx1 actief is. Raadpleeg Stel de Automation Controller (AWX) in met behulp van Ansible .
• Stel SSH-verbindingen in als je Ansible-plays uitvoert zonder Vagrant. Raadpleeg Ansible gebruiken zonder Vagrant .

Wijzig de EE

Dit gedeelte laat zien hoe je de EE in AAP kunt wijzigen in een workflow job, zodat de nieuwe EE beschikbaar wordt voor jobs die daarna worden uitgevoerd.

1. In het project ansible-gis, schakel over naar de development branch en bewerk group_vars/awx/awx.yml. Definieer gs_ee_images als volgt:

   gs_ee_images:
     default: registry.gitlab.com/c2platform/rws/ansible-execution-environment:0.1.18
     development: quay.io/ansible/awx-ee:24.4.0
   

   Verwijder of schakel de regel met development uit, commit en push terug naar de development branch.
2. Navigeer naar https://awx.c2platform.org/#/execution_environments  . Controleer of quay.io/ansible/awx-ee:24.4.0 de EE is.
3. Navigeer naar https://awx.c2platform.org/#/templates  en klik op de Visualizer link van gsd-awx-collections-workflow. Dit toont een workflow met vijf nodes.
4. Start de workflow.
5. Wanneer de workflow is voltooid, controleer of gsd-collections1 quay.io/ansible/awx-ee:24.4.0 toont en gsd-collections2 registry.gitlab.com/c2platform/rws/ansible-execution-environment:0.1.18.

Dit toont aan dat we de EE in ons DTAP-promotiemodel kunnen opnemen op een vergelijkbare manier als we het bestand requirements.yml gebruiken door een workflow in te richten die een taak zoals gsd-awx-ee omvat om de EE voor de omgeving te beheren.

Promoveer de EE

Dit deel laat zien hoe we wijzigingen, inclusief de EE, kunnen promoten van development naar test.

1. Maak de configuratie in AWX voor de test omgeving met behulp van node gst-awx1⁴:

   export PLAY=plays/mgmt/awx_config.yml
   ansible-playbook $PLAY -i hosts.ini --limit=gst-awx1
   

   Let op:

   Ansible commando’s rechtstreeks uitvoeren werkt alleen als je de nodige SSH configuratie voor hebt ingesteld. Raadpleeg Ansible gebruiken zonder Vagrant voor meer informatie.
2. Gebruik de AWX webinterface en start gst-awx-collections-workflow.
3. Controleer na voltooiing of er geen verschil is tussen collecties in gst-collections1 en gst-collections2.
4. In de development branch, wijzig je het standaardbeeld naar 0.1.19. Commit en push.

   gs_ee_images:
     default: registry.gitlab.com/c2platform/rws/ansible-execution-environment:0.1.19
     development: quay.io/ansible/awx-ee:24.4.0
   

5. Voeg wijzigingen samen naar de test branch en start gst-awx-collections-workflow.
6. Controleer na voltooiing de verschillen tussen de outputs van gst-collections1 en gst-collections2.

Review

In het Ansible Inventory project c2platform/rws/ansible-gis :

1. De play plays/mgmt/awx.yml, die Ansible rollen toont die gebruikt worden om de gsd-awx1 node te creëren.
2. Bestanden binnen group_vars/awx. Deze bestanden bevatten configuratie.
3. Het bestand Vagrantfile.yml, dat de Vagrant LXD machine definieert.

De Ansible rol c2platform.mgmt.awx in de Ansible Management Collectie c2platform/ansible-collection-mgmt . Deze rol gebruikt modules uit de awx.awx collectie om AWX te configureren (job templates, workflows).

De Ansible rollen c2platform.mw.microk8s en c2platform.mw.kubernetes in de Ansible Middleware collectie c2platform/ansible-collection-mw . De eerste rol creëert een Kubernetes instantie; de tweede installeert AWX op het cluster.

Tips

Als je experimenteert of ontwikkelt met AWX configuratie, kun je tags gebruiken om de provisioning te versnellen:

export PLAY=plays/mgmt/awx_config.yml
ansible-playbook $PLAY -i hosts.ini --limit=gsd-awx1 --tags secrets,awx_workflow_job_template,awx_workflow_job_template_node

Je kunt ook tags gebruiken bij gebruik van Vagrant:

export PLAY=plays/mgmt/awx_config.yml
TAGS=secrets,awx_workflow_job_template,awx_workflow_job_template_node vagrant provision gsd-awx1

Notities