Les importations sont statiques, les inclus sont dynamiques. Les importations ont lieu au moment de l'analyse, y compris au moment de l'exécution.
Les importations remplacent essentiellement la tâche par les tâches du fichier. Il n'y a pas import_taskau moment de l'exécution. Ainsi, des attributs tels que tags, et when(et très probablement d’autres attributs) sont copiés dans chaque tâche importée.
includes sont bien exécutés. tagset whend’une tâche incluse s’appliquent uniquement à la tâche elle-même.
Les tâches importétiquetées à partir d'un fichier importé sont exécutées si la tâche est non étiquetée. Aucune tâche n'est exécutée à partir d'un fichier inclus si la includetâche n'est pas marquée.
Toutes les tâches d'un fichier importé sont exécutées si la importtâche est étiquetée. Seules les tâches balisées d'un fichier inclus sont exécutées si la includetâche est balisée.
Limitations de imports:
- ne peut pas être utilisé avec
with_*ou loopattributs
- impossible d'importer un fichier dont le nom dépend d'une variable
Limitations de includes:
--list-tags ne montre pas les tags des fichiers inclus--list-tasks ne montre pas les tâches des fichiers inclus- vous ne pouvez pas utiliser
notifypour déclencher un nom de gestionnaire qui provient de l'intérieur d'une inclusion dynamique
- vous ne pouvez pas utiliser
--start-at-taskpour commencer l'exécution d'une tâche dans une inclusion dynamique
Plus sur ici et ici .
Pour moi, cela revient essentiellement au fait que imports ne peut pas être utilisé avec des attributs de boucle.
importéchouerait certainement dans des cas comme celui-ci :
# playbook.yml
- import_tasks: set-x.yml
when: x is not defined
# set-x.yml
- set_fact
x: foo
- debug:
var: x
debugn'est pas exécuté, puisqu'il hérite whende la import_taskstâche. Donc, pas de fichiers de tâches d'importation qui changent les variables utilisées dans importl' whenattribut de.
J'avais une politique pour commencer avec imports, mais une fois que j'ai besoin d'un, includeassurez-vous que rien n'est importé par ce fichier inclus ou les fichiers qu'il contient. Mais c'est sacrément difficile à maintenir. Et on ne sait toujours pas si cela me protégera des ennuis. Signification, mélanger includes et imports qu'ils ne recommandent pas.
Je ne peux pas utiliser que imports, car j'ai parfois besoin de boucler des includetâches. Je pourrais probablement passer à seulement includes. Mais j'ai décidé de passer aux importations partout, sauf dans les cas où la tâche est supposée être exécutée plusieurs fois. J'ai décidé de faire l'expérience de tous ces cas difficiles. Peut-être qu'il n'y en aura pas dans mes playbooks. Ou j'espère trouver un moyen de le faire fonctionner.
UPD Une astuce éventuellement utile pour créer un fichier de tâche pouvant être importé plusieurs fois, mais exécutée une fois :
- name: ...
...
when: not _file_executed | default(False)
- name: ...
...
when: not _file_executed | default(False)
...
- name: Set _file_executed
set_fact:
_file_executed: True
UPD Un effet peu attendu du mélange des inclusions et des importations est l’inclusion de vars sur ceux importés:
playbook.yml:
- hosts: all
tasks:
- import_tasks: 2.yml
vars:
v1: 1
- include_tasks: 2.yml
vars:
v1: 1
2.yml:
- import_tasks: 3.yml
vars:
v1: 2
3.yml:
- debug:
var: v1 # 2 then 1
Probablement, car effectue d' include_tasksabord toutes les importations statiques supplémentaires, puis modifie les variables transmises via sa varsdirective.
En fait, cela ne se produit pas uniquement avec les importations:
playbook.yml:
- hosts: all
tasks:
- import_tasks: 2.yml
vars:
v1: 1
- include_tasks: 2.yml
vars:
v1: 1
2.yml:
- debug:
var: v1 # 2 then 1
vars:
v1: 2
UPD Un autre cas de mélange inclut et importe.
playbook.yml:
- hosts: all
tasks:
# here you're bound to use include, some sort of loop
- include_tasks: 2.yml
vars:
https: yes
2.yml:
- import_tasks: 3.yml
when: https
3.yml:
- import_tasks: 4.yml
vars:
https: no # here we're trying to temporarily override https var
- import_tasks: 4.yml
4.yml:
- debug:
var: https
Nous obtenons trueet true, voir le cas précédent (inclure les variables ont priorité sur les variables d'importation). Nous passons donc aux inclus dans 3.yml. Mais alors la première inclusion dans 3.ymlest ignorée. Puisqu'il hérite when: httpsde la tâche parente, et que celle-ci prend soi-disant httpsde la tâche vars. La solution consiste à basculer également vers les inclusions 2.yml. Cela empêche la propagation des when: httpstâches enfants.