Salut,
j'ai deux problèmes différents avec Ansible, donc je fais deux threads séparés.
je suis de la veille école et utilise vi, et non pas vscode. donc la hiérarchie standard des roles Ansible (roles/x/tasks), en divisant un playbook en multiples petits fichiers ne me convient pas. moi j'aime bien avoir un gros playbook avec tasks + handlers dans un seul fichier. disons playbook "old-school ci-après.
c'est ce que je faisais jusqu'à présent *1 mais j'arrive aux limites de ce schéma, car dans les pipelines CI/CD je dois faire une multitude de conditions afin de lancer tel ou tel playbook old-school depuis le script ci/cd.
donc j'ai exploré un peu comment faire de beaux playbooks inclusifs avec:
- include_tasks - import_tasks - roles: // include_role
bah le résultat n'est pas fameux. avec include_tasks et import_tasks, cela bloque évidemment à `handlers:` puisque ce n'est pas une tâche. Et avec include_role + `from_tasks: ../old-school-role/tasks-old-school-role.yml`, comme tentative d'éviter la hiérarchie de répertoire standard des roles, j'obtiens cela:
ERROR! Failed loading '[...]/dehydrated/tasks/../tasks-dehydrated.yml' for role (../dehydrated) as it is not inside the expected role path: '[...]/dehydrated/tasks'
voila, je suis donc résigné et n'ai pas le choix. je vais devoir faire comme tout le monde, accepter la modernité et utiliser la hiérarchie standard des roles Ansible.
si toutefois vous avez une idée de comment détourner Ansible pour garder une structure de dossier non-orthodoxe, tout en bénéficiant des playbooks inclusifs (pas de blagues svp, aucun rapport), faites moi signe...
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…
Hello,
Oui, avec des tags ça peut être une solution, par exemple:
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
Le 28/09/2025 à 18:01, Landry MINOZA a écrit :
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/
-
Landry MINOZA -
Pierre-Philipp Braun -
webmaster＠imingo.com