Hier is een gestructureerde aanpak en best practices voor het ontwerpen van een Ansible playbook dat rolafhankelijkheden en versies efficiënt beheert voor je omgevingen ontwikkeling, staging en productie: 1. Organiseer je projectstructuur: ``` ansible-project/ ├── inventories/ │ ├── development/ │ ├── staging/ │ └── production/ ├── roles/ │ ├── webserver/ │ ├── database/ │ └── monitoring/ ├── playbooks/ │ └── site.yml ├── requirements.yml └── ansible.cfg ``` 2. Gebruik `requirements.yml` voor rolversies en afhankelijkheden: ```yaml # requirements.yml - src: git@github.com:jou/ansible-webserver.git version: v1.2.0 name: webserver - src: git@github.com:jou/ansible-database.git version: v3.4.1 name: database - src: git@github.com:jou/ansible-monitoring.git version: v2.0.0 name: monitoring ``` 3. Installeer en beheer rolversies: ```bash ansible-galaxy collection install -r requirements.yml ``` Of voor rollen: ```bash ansible-galaxy install -r requirements.yml ``` 4. Gebruik verschillende variabelenbestanden per omgeving: ```yaml # inventories/development/vars.yml roles_versions: webserver: v1.2.0 database: v3.4.1 monitoring: v2.0.0 ``` ```yaml # inventories/staging/vars.yml roles_versions: webserver: v1.3.0 database: v3.5.0 monitoring: v2.1.0 ``` ```yaml # inventories/production/vars.yml roles_versions: webserver: v1.3.2 database: v3.5.2 monitoring: v2.2.0 ``` 5. In je playbook, gebruik dynamische rolversies: ```yaml # playbooks/site.yml - hosts: all vars_files: - inventories/{{ inventory_name }}/vars.yml roles: - role: webserver version: "{{ roles_versions.webserver }}" - role: database version: "{{ roles_versions.database }}" - role: monitoring version: "{{ roles_versions.monitoring }}" ``` *(Let op: Ansible ondersteunt niet standaard het specificeren van rolversies binnen het playbook zelf; je kunt dit beheren via requirements.yml en de geïnstalleerde rollen, of via dynamische inventories en conditionele inclusie.)* 6. Best practices voor afhankelijkheidsbeheer: - Zorg dat je `requirements.yml` expliciet de rolversies vermeldt. - Bij het updaten van rollen, verhoog de semantische versie volgens git-tags. - Gebruik tags en CI/CD-pijplijnen om automatische updates te controleren en te testen. 7. Automatisering van versie-updates: - Maak een script of CI/CD-pipeline die: - Git-tags checkt voor nieuwe versies. - `requirements.yml` bijwerkt met nieuwe versies. - Rollen opnieuw installeert. - Tests draait om verificatie. Bijvoorbeeld, een CI-job die: ```bash # Controleer nieuwe Git-tags git fetch --tags latest_tag=$(git describe --tags `git rev-list --tags --max-count=1`) # Update requirements.yml automatisch # (Met een script dat de nieuwe versies uit de tags haalt) # Installeer rollen ansible-galaxy install -r requirements.yml --force ``` 8. Vermijd conflicten in productie: - Beperk automatische updates in productie; doe dit handmatig of via gecontroleerde CI/CD-stappen. - Gebruik versie-locking (`version:` in requirements.yml) om te voorkomen dat onverwachte updates plaatsvinden. - Test nieuwe versies eerst in staging voordat je ze in productie uitrolt. 9. Overweeg gebruik van `ansible-pull` of een centrale CI/CD pipeline om consistent te blijven en updates te automatiseren. Samenvatting: - Gebruik `requirements.yml` met semantische versies en Git-tags. - Beheer per-omgeving variabelen voor rolversies. - Automatiseer updates via CI/CD pipelines met versiebeheer en tests. - Voorkom conflicten door versies expliciet te specificeren en in staging eerst te testen. Wil je dat ik een voorbeeld van een volledige `requirements.yml` of een CI-script voor je opstel?

Hier is een gestructureerde aanpak voor je Ansible playbook met best practices voor rolafhankelijkheden en versiebeheer: ## Aanbevolen Projectstructuur ``` ansible-project/ ├── environments/ │ ├── development/ │ │ ├── group_vars/ │ │ └── inventory.yml │ ├── staging/ │ │ ├── group_vars/ │ │ └── inventory.yml │ └── production/ │ ├── group_vars/ │ └── inventory.yml ├── roles/ │ └── requirements.yml ├── collections/ │ └── requirements.yml ├── group_vars/ │ ├── all.yml │ ├── webservers.yml │ ├── databases.yml │ └── monitoring.yml ├── site.yml ├── playbooks/ │ ├── webserver.yml │ ├── database.yml │ └── monitoring.yml └── ansible.cfg ``` ## 1. Rol Requirements Bestand `roles/requirements.yml`: ```yaml # Ontwikkelomgeving - laatste versies - src: https://github.com/your-org/ansible-webserver version: main name: webserver - src: https://github.com/your-org/ansible-database version: develop name: database - src: https://github.com/your-org/ansible-monitoring version: main name: monitoring # Staging omgeving - specifieke versies - src: https://github.com/your-org/ansible-webserver version: v2.1.0 name: webserver - src: https://github.com/your-org/ansible-database version: v1.4.2 name: database - src: https://github.com/your-org/ansible-monitoring version: v3.0.1 name: monitoring # Productie omgeving - stabiele versies - src: https://github.com/your-org/ansible-webserver version: v2.0.4 name: webserver - src: https://github.com/your-org/ansible-database version: v1.3.8 name: database - src: https://github.com/your-org/ansible-monitoring version: v2.2.3 name: monitoring ``` ## 2. Omgevingsspecifieke Configuratie `environments/development/group_vars/all.yml`: ```yaml # Ontwikkeling - flexibele versies role_versions: webserver: "main" database: "develop" monitoring: "main" # Ontwikkelingsspecifieke variabelen debug_mode: true log_level: debug ``` `environments/production/group_vars/all.yml`: ```yaml # Productie - vergrendelde versies role_versions: webserver: "v2.0.4" database: "v1.3.8" monitoring: "v2.2.3" # Productie veiligheidsinstellingen debug_mode: false log_level: warn ``` ## 3. Hoofd Playbook Structuur `site.yml`: ```yaml - name: Apply infrastructure configuration hosts: all vars_files: - "{{ playbook_dir }}/group_vars/all.yml" roles: - role: webserver tags: webserver - role: database tags: database - role: monitoring tags: monitoring ``` ## 4. Geavanceerde Rol Afhankelijkheden `roles/webserver/meta/main.yml`: ```yaml dependencies: - role: common version: ">=1.2.0" when: common_role is defined - role: monitoring version: "~2.2" when: "'monitoring' in group_names" galaxy_info: author: jouw-team description: Webserver role min_ansible_version: 2.9 galaxy_tags: - webserver - nginx - apache ``` ## 5. Versie Compatibiliteit Controle `playbooks/version_check.yml`: ```yaml - name: Validate role version compatibility hosts: localhost gather_facts: false vars: required_versions: webserver: ">=2.0.0" database: ">=1.3.0" monitoring: ">=2.2.0" tasks: - name: Check installed role versions command: "ansible-galaxy list" register: installed_roles - name: Validate version compatibility fail: msg: "Incompatible version for {{ item.role }}: {{ item.installed }}" when: > item.installed is version(item.required, 'lt') loop: "{{ role_versions | dict2items }}" ``` ## 6. Geautomatiseerde Versie Updates ### CI/CD Pipeline Script ```bash #!/bin/bash # automated_version_update.sh ENVIRONMENT=$1 ROLE=$2 NEW_VERSION=$3 # Valideer semantische versie if ! [[ $NEW_VERSION =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then echo "Fout: Ongeldige semantische versie $NEW_VERSION" exit 1 fi # Update requirements.yml sed -i "s|version:.*$ROLE.*|version: $NEW_VERSION|g" environments/$ENVIRONMENT/requirements.yml # Test in staging voor productie-updates if [ "$ENVIRONMENT" == "production" ]; then echo "Test update in staging omgeving eerst" ansible-playbook -i environments/staging/inventory.yml test_update.yml fi # Voer playbook uit ansible-playbook -i environments/$ENVIRONMENT/inventory.yml site.yml --check ``` ## 7. Best Practices voor Versiebeheer ### Versie Lock Bestand `roles/versions.lock`: ```yaml # Vergrendelde versies voor productie production: webserver: v2.0.4 database: v1.3.8 monitoring: v2.2.3 dependencies: common: v1.2.1 staging: webserver: v2.1.0 database: v1.4.2 monitoring: v3.0.1 ``` ### Dependency Resolution Script ```python #!/usr/bin/env python3 # dependency_resolver.py import yaml import semver def check_dependencies(environment): with open('roles/versions.lock', 'r') as f: versions = yaml.safe_load(f) env_versions = versions.get(environment, {}) # Controleer op conflicterende versies for role, version in env_versions.items(): # Implementeer compatibiliteitscontroles pass ``` ## 8. Uitvoering en Automatisering ### Installatie Commando's: ```bash # Rol dependencies installeren per omgeving ansible-galaxy install -r environments/development/requirements.yml ansible-galaxy install -r environments/production/requirements.yml # Playbook uitvoeren met omgevingsspecifieke configuratie ansible-playbook -i environments/production/inventory.yml site.yml ``` ### Git Hooks voor Versiebeheer: `.git/hooks/pre-commit`: ```bash #!/bin/bash # Controleer of versie-updates semantisch zijn python3 scripts/validate_versions.py ``` Deze structuur biedt: - **Scheiding van concerns** per omgeving - **Semantisch versiebeheer** met Git tags - **Geen versieconflicten** in productie - **Geautomatiseerde updates** met validatie - **Dependency resolutie** met compatibiliteitscontroles Voor maximale stabiliteit raad ik aan om een **canary deployment** strategie te implementeren waarbij nieuwe versies eerst in staging worden getest voordat ze naar productie gaan.