Импорт статический, в том числе динамический. Импорт происходит во время синтаксического анализа, включает во время выполнения.
Импорт в основном заменяет задачу задачами из файла. Там нет import_taskво время выполнения. Таким образом, такие атрибуты, как tagsи when(и, скорее всего, другие атрибуты) копируются в каждую импортированную задачу.
includeс действительно выполнены. tagsи whenвключенной задачи относятся только к самой задаче.
Помеченные задачи из импортированного файла выполняются, если importзадача не помечена. Задачи не выполняются из включенного файла, если includeзадача не помечена.
Все задачи из импортированного файла выполняются, если importзадача помечена. Только помеченные задачи из включенного файла выполняются, если includeзадача помечена.
Ограничения imports:
- не могут быть использованы
with_*или loopатрибуты
- невозможно импортировать файл, имя которого зависит от переменной
Ограничения includes:
--list-tags не показывает теги из включенных файлов--list-tasks не показывает задачи из включенных файлов- вы не можете использовать
notifyдля запуска имя обработчика, которое происходит из динамического включения
- вы не можете использовать,
--start-at-taskчтобы начать выполнение задачи внутри динамического включения
Подробнее об этом здесь и здесь .
Для меня это в основном сводится к тому, что imports нельзя использовать с атрибутами цикла.
importбы , конечно , не в состоянии в таких случаях , как это :
# playbook.yml
- import_tasks: set-x.yml
when: x is not defined
# set-x.yml
- set_fact
x: foo
- debug:
var: x
debugне выполняется, так как он наследует whenот import_tasksзадачи. Таким образом, нет импортирования файлов задач , которые изменяют переменные , используемые в import«s whenатрибута.
У меня была политика для начала с imports, но как только мне нужно includeубедиться, что ничего не импортируется этим включенным файлом или файлами, которые он включает. Но это чертовски сложно поддерживать. И до сих пор не ясно, защитит ли это меня от неприятностей. То есть смешивать includeс и importс, которые они не рекомендуют.
Я не могу использовать только imports, так как мне иногда нужно циклически includeвыполнять задачи. Я мог бы, вероятно, переключиться только на includeс. Но я решил переключиться на импорт везде, кроме случаев, когда задача должна выполняться несколько раз. Я решил испытать все эти сложные случаи из первых рук. Может быть, не будет в моих пьесах. Или, надеюсь, я найду способ заставить это работать.
UPD Возможно полезный трюк для создания файла задачи, который можно импортировать много раз, но выполнить один раз :
- name: ...
...
when: not _file_executed | default(False)
- name: ...
...
when: not _file_executed | default(False)
...
- name: Set _file_executed
set_fact:
_file_executed: True
UPD Один не совсем ожидаемый эффект от смешивания включает и импортирует то, что включает в себя переопределенные переменные импорта:
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
Вероятно, потому что include_tasksсначала выполняет все дополнительные статические операции импорта, а затем изменяет переменные, передаваемые через его varsдирективу.
На самом деле, это происходит не только с импортом:
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 Еще один случай смешивания включает и импортирует.
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
Мы получаем trueи true, видим предыдущий случай (включающие переменные имеют приоритет над импортируемыми переменными). Таким образом, мы переключаемся на включает в 3.yml. Но затем первое включение в 3.ymlпропускается. Поскольку он наследуется when: httpsот родительской задачи, а последняя предположительно берет httpsот задачи vars. Решение состоит в том, чтобы переключиться на включения в 2.yml. Это предотвращает распространение when: httpsна дочерние задачи.