Le importazioni sono statiche, le inclusioni sono dinamiche. Le importazioni avvengono al momento dell'analisi, include in fase di esecuzione.
Le importazioni sostituiscono sostanzialmente l'attività con le attività del file. Non c'è import_taskin fase di esecuzione. Pertanto, attributi come tagse when(e molto probabilmente altri attributi) vengono copiati in ogni attività importata.
includegli s sono effettivamente eseguiti. tagse whendi un'attività inclusa si applicano solo all'attività stessa.
Le attività contrassegnate da un file importato vengono eseguite se l' importattività non è contrassegnata. Nessuna attività viene eseguita da un file incluso se l' includeattività non è contrassegnata.
Tutte le attività da un file importato vengono eseguite se l' importattività è taggata. Solo le attività contrassegnate da un file incluso vengono eseguite se l' includeattività è contrassegnata.
Limitazioni di imports:
- non può essere utilizzato con
with_*o loopattributi
- impossibile importare un file, il cui nome dipende da una variabile
Limitazioni di includes:
--list-tags non mostra i tag dai file inclusi--list-tasks non mostra attività dai file inclusi- non è possibile utilizzare
notifyper attivare il nome di un gestore che proviene da un'inclusione dinamica
- non è possibile utilizzare
--start-at-taskper iniziare l'esecuzione in un'attività all'interno di un'inclusione dinamica
Maggiori informazioni qui e qui .
Per me ciò dipende essenzialmente dal fatto che imports non può essere utilizzato con gli attributi di loop.
importfallirebbe sicuramente in casi come questo :
# playbook.yml
- import_tasks: set-x.yml
when: x is not defined
# set-x.yml
- set_fact
x: foo
- debug:
var: x
debugnon viene eseguito, poiché eredita whendall'attività import_tasks. Quindi, nessun file Operazione di importazione che cambiano variabili utilizzate nel import's whenattributo.
Avevo una politica per iniziare con imports, ma una volta ho bisogno di includeassicurarmi che nulla sia importato da quel file incluso o dai file che include. Ma è abbastanza difficile da mantenere. E non è ancora chiaro se mi proteggerà dai problemi. Significato, mescolando includes e imports che non raccomandano.
Non posso usare solo le imports, poiché occasionalmente ho bisogno di eseguire il ciclo delle includeattività. Probabilmente potrei passare solo a includes. Ma ho deciso di passare alle importazioni ovunque, ad eccezione dei casi in cui l'attività dovrebbe essere eseguita più volte. Ho deciso di provare di persona tutti quei casi difficili. Forse non ce ne sarà nessuno nei miei playbook. O speriamo di trovare un modo per farlo funzionare.
UPD Un trucco forse utile per creare un file di attività che può essere importato più volte, ma eseguito una volta :
- 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 effetto non realmente previsto della miscelazione di inclusioni e importazioni è che includono variare quelli di importazione:
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
Probabilmente, perché include_tasksprima fa tutte le importazioni statiche aggiuntive, quindi cambia le variabili passate tramite la sua varsdirettiva.
In realtà, succede non solo con le importazioni:
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 altro caso di miscelazione include e importazioni.
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
Otteniamo truee true, vedi il caso precedente (includere i var ha la precedenza sui import import). Quindi passiamo a include in 3.yml. Ma poi il primo include in 3.ymlviene saltato. Dal momento che eredita when: httpsdall'attività padre e quest'ultima presumibilmente prende httpsdall'attività vars. La soluzione è passare anche a include in 2.yml. Ciò impedisce la propagazione when: httpsalle attività secondarie.