Groepgebaseerde omgevingen

Probleem

Bij het beheren van Ansible-projecten voor verschillende omgevingen zoals ontwikkeling, test, staging en productie, is het belangrijk om een gestructureerde aanpak te hebben om inventaris en variabelen te organiseren.

Context

Ansible stelt je in staat om groepen in inventaris te definiëren, die kunnen worden gebruikt om hosts met vergelijkbare rollen of attributen te organiseren. Groepsvariabelen kunnen ook worden gebruikt om omgevingsspecifieke variabelen te definiëren die worden toegepast op hosts in die groepen.

Oplossing

Volg deze richtlijnen om een strategie van groepgebaseerde omgevingen te implementeren in je Ansible-inventarisproject:

1. Organiseer je inventarisbestand binnen het Ansible-inventarisproject en voeg een Ansible-groep toe voor elke omgeving (bijv. development, test, staging, production) die we kunnen aanduiden als omgevingsgroepen.
2. Wijs hosts toe aan de juiste omgevingsgroepen afhankelijk van de omgeving waarvan ze deel uitmaken, bijv. ontwikkelingshosts aan de groep development, productiehosts aan de groep production.
3. Maak afzonderlijke bestanden voor groepsvariabelen voor elke omgevingsgroep, bijv. group_vars/development.yml, group_vars/test.yml, enz.

Voordelen

• Biedt een duidelijke en georganiseerde manier om inventaris en variabelen voor verschillende omgevingen te beheren.
• Hiermee kun je omgevingsspecifieke configuraties definiëren in groepsvariabelen, wat het eenvoudig maakt om instellingen voor elke omgeving aan te passen.
• Vereenvoudigt de ontwikkeling van playbooks en Ansible-rollen, aangezien je groepsvariabelen kunt gebruiken om omgevingsspecifieke details te abstraheren uit playbooks en rollen.
• Ontsluit de kracht van Ansible om omgevingsverschillen effectief, efficiënt en intuïtief te beheren.

Alternatieven

Hoewel groepgebaseerde omgevingen de aanbevolen aanpak is, bestaan er alternatieven. Een ouder patroon dat in eerdere Ansible-documentatie werd voorgesteld, omvatte het creëren van meerdere group_vars-directories, één voor elke omgeving. Dit patroon is alleen zinvol als omgevingen zeer verschillend zijn, wat in de praktijk zelden het geval is. Het beheren van verschillen over meerdere directories vereist constant gebruik van externe diff- en merge-tools, wat het omslachtig maakt.

Daarentegen maakt het gebruik van een enkele group_vars-directory een echte GitOps-aanpak mogelijk, waarbij omgevingsverschillen effectiever worden behandeld via omgevingsgroepen en branching-strategieën. Op dit punt is het creëren van omgevingsgroepen de standaardmethode geworden voor het beheren van omgevingen in Ansible-projecten.

Een andere optie is het gebruik van hostvariabelen voor aanpassingen per host. Echter, groepsvariabelen zijn beter voor omgeving-brede instellingen om herhaling te voorkomen en de onderhoudbaarheid te verbeteren.

Voorbeelden en implementatie

RWS-project

De omgevingsgroep van het RWS-project bevat, als voorbeeld, slechts twee omgevingen (development, test). Deze bestanden bevatten slechts één variabele gs_env, met waarde development en test.

 group_vars/development.yml

---
gs_env: development

 group_vars/test.yml

---
gs_env: test

Deze projectvariabele gs_env kan nu behoorlijk effectief worden gebruikt om omgevingsverschillen te beheren. Om een volledig beeld te krijgen van hoe dit wordt gebruikt, kun je het project lokaal klonen en vervolgens zoeken naar voorkomens van de variabele in de groepsvariabelen-directory.

Op dit punt kun je kijken naar een specifiek voorbeeld van hoe twee projectvariabelen gs_ad_controller en gs_ad_controller_ip worden gebruikt om ervoor te zorgen dat een host lid wordt van het juiste AD-domein. Zie voor meer informatie de link hieronder:

• Onderscheid tussen Ansible engineering en operations: Onderscheid ansible engineering en operations als afzonderlijke disciplines om hoogwaardige, onderhoudbare automatisering te garanderen.

PHX-project

Het inventarisproject voor het PHX-project  c2platform/phx/ansible bevat een geavanceerder voorbeeld dat een projectvariabele px_env introduceert voor de omgeving, maar ook een omgevingscontrole.

 group_vars/all/env.yml

---
px_env: "{{ group_names | intersect(px_envs) | first }}"
px_envs: ['test', 'development']
px_envs_node: "{{ group_names | intersect(px_envs) }}"
px_envs_node_count: "{{ px_envs_node | length }}"
px_envs_check:
  name: >-
    Environment {{ inventory_hostname }} → {{ px_envs_node | join(', ') }}    
  type: fail
  msg: >-
    Node {{ inventory_hostname }} should be associated with exactly
    one environment group of: {{ px_envs | join(', ') }}!    
  when: "{{ px_envs_node_count != '1' }}"

Dit code-fragment, gedefinieerd in group_vars/all/env.yml, stelt omgevingsvariabelen in en implementeert een validatiecontrole om juiste groepstoewijzingen te garanderen. Hier is een uitsplitsing:

• px_env: Stelt de omgeving dynamisch in door de intersectie te vinden van de groepnamen van de host met de toegestane omgevingen (px_envs). Het selecteert de eerste (en verwachte enige) match.
• px_envs: Een lijst van toegestane omgevingsnamen, zoals ’test’ en ‘development’.
• px_envs_node: Berekent de intersecterende omgevingsgroepen voor de huidige host.
• px_envs_node_count: Telt het aantal intersecterende omgevingsgroepen.
• px_envs_check: Configureert een Ansible fail-moduletask. Het definieert een faalconditie die triggert als een host niet is geassocieerd met precies één omgevingsgroep uit px_envs. Dit fungeert als een safeguard tijdens playbook- uitvoering om misconfiguraties te voorkomen, met een aangepast foutbericht dat het probleem uitlegt.

Merk op, zoals hieronder getoond, dat het Ansible-inventarisproject nog steeds een omgevingsgroep-bestand heeft, maar de variabele px_env is uitgeschakeld. Het bestand zou verwijderd kunnen worden.

 group_vars/development.yml

---
# deprecated see group_vars/all/env.yml
# px_env: development

Deze setup zorgt ervoor dat elke host behoort tot precies één omgevingsgroep, wat consistentie bevordert en fouten voorkomt in multi-omgevingsopstellingen.

Aanvullende informatie

Voor aanvullende inzichten en richtlijnen:

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