Ansible-inventarisproject

Een gestructureerde verzameling bestanden die worden gebruikt voor het beheren van hosts en configuraties. Het omvat doorgaans inventarisbestanden, playbooks, hostvariabelen, groepsvariabelen en Ansible Vault-bestanden.
Categories:
Tags:

Een Ansible-inventarisproject, ook bekend als een Ansible-inventarisproject, is een gestructureerde verzameling bestanden die worden gebruikt in Ansible voor het beheren van hosts en configuraties. Het omvat doorgaans inventarisbestanden, playbooks, hostvariabelen, groepsvariabelen en geheime variabelen ( Ansible Vault-bestanden). Dit type project wordt soms aangeduid als een playbook-project of configuratieproject.

Deze projecten zijn gestructureerd om te worden gebruikt en geconsumeerd door Ansible Automation Platform ( AAP) of AWX.

De inventarisstrategie van C2 Platform-projecten kan worden beschreven als groepgebaseerde omgevingen met dictionary-samenvoeging. Deze benadering helpt bij het efficiënt beheren van meerdere omgevingen, bevordert een GitOps-workflow en maakt flexibele variabele-afhandeling mogelijk. De onderstaande secties verkennen de belangrijkste componenten, voorbeelden en kernconcepten van deze strategie in detail.

Structuur van een inventarisproject

Voorbeelden van zulke projecten zijn  c2platform/ansible,  c2platform/rws/ansible-gis,  c2platform/phx/ansible.

Binnen  c2platform/rws/ansible-gis vind je:

  1. hosts.ini: Het inventarisbestand met hostconfiguraties. Het definieert Ansible-groepen, inclusief de omgevingsgroepen, en ondersteunt de organisatie van hosts op basis van rollen, omgevingen (bijv. development, test, staging, production) of attributen.

  2. group_vars: Een directory die groepsvariabelen opslaat voor de Ansible-groepen die zijn gedefinieerd in het inventarisbestand.

  3. plays: directory die Ansible-playbooks bevat, bijvoorbeeld de play die het Geoweb-subsysteem van het GIS Platform beheert, gebaseerd op Vertigis Studio:

     plays/gis/geoweb.yml

    ---
- name: Geoweb
  hosts: geoweb

  roles:
    - { role: c2platform.wincore.win, tags: ["windows"]}
    - { role: c2platform.gis.vertigis_studio, tags: ["geoweb", "vertigis", "studio", "reporting"]}

  4. secret_vars: Een speciale locatie voor het opslaan van geheimen. Voor meer details, zie Geheimen Beheren met Ansible Vault in AAP / AWX .

  5. collections/requirements.yml: Bestand gebruikt door Ansible Automation Platform AAP (of AWX) om Ansible-collecties van Ansible Galaxy te installeren.

     collections/requirements.yml

    ---
collections:
  - name: community.postgresql
    version: 2.4.3
  - name: ansible.windows
    version: 1.14.0
  - name: community.windows
    version: 2.0.0
  - name: c2platform.gis
    version: 1.0.21
  - name: c2platform.mgmt
    version: 1.0.4
  - name: https://gitlab.com/c2platform/ansible-collection-mw.git
    type: git
    version: master
  # - name: c2platform.mw
  #   version: 1.0.4  # TODO 1.0.5
  - name: c2platform.dev
    version: 1.0.4

  6. roles/requirements.yml: Vergelijkbaar met collections/requirements.yml, ook gebruikt door AAP (of AWX) om Ansible-rollen van Galaxy te installeren.

  7. ansible.cfg: Dit bestand bevat configuratie-instellingen voor Ansible, inclusief standaardinstellingen voor modulegedrag, inventarispaden en rollen. Je kunt hier ook een privé Galaxy Server configureren.

     ansible.cfg

    [defaults]
roles_path=./roles/external:./roles/internal
hash_behaviour = merge
ansible_managed = This file is managed by Ansible, all changes will be lost.
collections_path=../ansible-dev-collections/ansible_collections:../ansible-dev-collections:./
# collections_path=./  # RWS-390
display_skipped_hosts = no
stdout_callback = yaml
# callbacks_enabled=ansible.posix.profile_tasks, ansible.posix.timer
# callbacks_enabled=ansible.posix.profile_roles, ansible.posix.timer

Groepgebaseerde omgevingen

Als onderdeel van de groepgebaseerde omgevingen-benadering is er voor elke omgeving (development, test, staging, production) een bijbehorende Ansible-groep, ook bekend als een Ansible-omgevingsgroep. Bijvoorbeeld, in hosts.ini op regels 32 tot 37 wordt een Ansible-groep test (voor de test-omgeving) gedefinieerd met 5 nodes erin. De groepgebaseerde omgevingen-benadering maakt het mogelijk om omgevingsverschillen veel effectiever te beheren.

 hosts.ini

32[test]
33gst-rproxy1         ansible_host=1.1.5.209
34gst-awx1            ansible_host=1.1.5.164
35gst-db1             ansible_host=1.1.5.210
36gst-fme-core        ansible_host=1.1.8.118
37gst-ad              ansible_host=1.1.8.119

 group_vars/test.yml

---
gs_env: test

Voor meer informatie over groepgebaseerde omgevingen:

GitOps

De term GitOps wordt doorgaans gebruikt in de context van cloud-native applicaties, maar is ook van toepassing op Ansible-automatiseringsprojecten. De opzet maakt een pure GitOps-benadering mogelijk door Ansible-playbooks, inventarissen en variabelen te behandelen als declaratieve code opgeslagen in Git, wat een volledige definitie en enkele bron van waarheid biedt. Voor elke omgeving wordt een branch gecreëerd, een omgevingbranch, die de enkele bron van waarheid is voor een specifieke omgeving.

Belangrijke principes van GitOps zijn onder meer:

  • Declaratieve configuratie: Configuraties beschrijven de “desired state” van het systeem, in plaats van imperatieve stappen om die te bereiken.
  • Enkele bron van waarheid: De Git-repository dient als de canonieke bron voor alle configuraties en gewenste toestanden.
  • Automatisering / Reconciliatie: Tools observeren continu wijzigingen in de Git-repository en passen deze automatisch toe, waarbij de current state wordt afgestemd op de desired state.

Pure GitOps

In een pure GitOps-benadering moet je voorkomen dat desired state ergens buiten de Git-repository wordt opgeslagen, omdat dit kan leiden tot inconsistenties en afwijkingen van de enkele bron van waarheid. Houd in plaats daarvan de volledige definitie van alle omgevingen—inclusief nodes, rollen en configuraties—uitsluitend binnen het Ansible-inventarisproject in Git. Geef bijvoorbeeld geen desired state door via Azure DevOps of GitLab CI/CD-pipeline-variabelen, en vermijd het definiëren van inventarissen of variabelen direct in AAP/ AWX; deze moeten verwijzen naar de Git-repository om ervoor te zorgen dat alle toestanden declaratief worden beheerd via Git.

GitOps-pipeline

Een kernconcept in GitOps met Ansible (met omgevingbranches) is de GitOps-pipeline, die groepgebaseerde omgevingen (met Ansible-omgevingsgroepen) en omgevingbranches gebruikt om wijzigingen veilig te promoten. Bijvoorbeeld, wijzigingen kunnen worden gepromoot over omgevingen (bijv. van development naar production) met behulp van merge requests (MRs) in tools zoals GitLab en Azure DevOps met goedkeuringsprocessen. Dit proces zorgt ervoor dat updates worden beoordeeld, getest en automatisch gereconcilieerd, waarbij consistentie wordt behouden en handmatige interventie wordt verminderd.

De GitOps-pipeline is geen GitLab CI/CD-pipeline, maar kan er deel van uitmaken. De GitOps-pipeline bestaat uit MRs en een tool die zorgt voor het automatiserings-/reconciliatiedeel. Doorgaans gebruiken projecten Ansible Automation Platform ( AAP), maar als dat niet beschikbaar is, kan bijvoorbeeld een GitLab Runner worden gebruikt, zoals in het PHX-project.

Voor meer informatie over het gebruik van een GitLab Runner als control node, zie:

Voor meer informatie over branching en merging, zie:

Dictionary-samenvoeging

De term dictionary-samenvoeging verwijst naar een bekende maar zeer krachtige functie van Ansible om dictionaries samen te voegen. Merk op dat we niet verwijzen naar expliciete samenvoeging met behulp van de Ansible Jinja-filter ansible.builtin.combine. We verwijzen naar de globale functie om dictionaries altijd samen te voegen. Deze is standaard uitgeschakeld en kan worden ingeschakeld door hash_behaviour in te stellen op merge in ansible.cfg, zoals getoond in het voorbeeld hieronder:

 ansible.cfg

hash_behaviour = merge

Voor meer informatie:

Aanvullende informatie

Voor verdere referentie, verken de volgende richtlijnen:


Laatst gewijzigd 2025.09.17: guideline engineering vs configuring PHX-162 (9fd7610)