install.yml
---
- name: install test
hosts: "{{ env }}"
gather_facts: true
roles:
- role: update
tags:
- never
- update
- install
- role: user
tags:
- never
- user
- install
- role: server
tags:
- never
- server
- install
# all tags
ansible-playbook install.yml -i hosts -e env=prod --tags install
ansible-playbook install.yml -i hosts -e env=prod --tags update
ansible-playbook install.yml -i hosts -e env=prod --tags user
ansible-playbook install.yml -i hosts -e env=prod --tags server
Bonjour,
Alors, ça date un peu ($JOB-2) et il peut y avoir des choses qui ont évolué (il n’y avait pas d’import ou include ou les 2, et ma mémoire qui fait défaut), mais j’ai eu un projet de déploiement d’une archi importante Ansible dont le déroulement complet était trop long pour être réappliqué intégralement à chaque modification.
J’avais une structure de code plutôt standardisée (arborescence des rôles avec séparation des tasks, vars et handlers dans des dossiers différents), et un unique playbook de base qui faisait la coordination et appelait les rôles en sequence avec les listes de paramètres dont ils avaient besoin.
La sélection de l’exécution partielle se faisait grâce aux tags. Chaque appel de rôle du playbook de base et chaque tache des rôles avait (souvent vi des blocs) un ou plusieurs tags. Quelques taches systématiques (inventaire, fabrication des groupes en fonctions de remontées d’inventaires — os, versions, subnet…) avaient le tag always. Quelques unes avec never, debug permettait de ne les lancer qu’en mode « debug »
Ça me permettait de ne lancer que ce dont j’avais besoin, de séparer un peu les tâches de build nécessaire uniquement au déploiement d’une nouvelle machine de celles de maintenance et MCO, etc…
Reste à voir dans quelle mesure, c’est utilisable avec une CI (en tout cas la partie, c’est une tâche, rôle, whatever avec ce tag qui a été modifié donc on fait tourner avec ce tag en particulier…
_______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/