Ansible --tags пропускает нужные задачи: include_tasks и import_tasks

В playbook выделили настройку приложения в отдельный файл и добавили tag deploy к include_tasks. Полный запуск работает. Запуск с --tags deploy сообщает об успешном включении файла, но полезные задачи пропускает. Проблема возникает потому, что тег включения не обязан наследоваться содержимым динамического файла.

При выборе по тегам Ansible сначала решает, запускать ли сам include. Если он выбран, динамически загружает задачи, а затем отбирает уже их. Тег только на внешней строке решает первый вопрос. Для второго нужны теги внутри файла либо явное наследование через apply.

Сделаем небольшой пример без изменения сервера

Сохраните файл deploy.yml со списком задач:

- name: Show selected deployment step
  ansible.builtin.debug:
    msg: "deployment task selected"

Рядом создайте site.yml. Следующий вариант добавляет deploy и включению, и загружаемым задачам:

- name: Demonstrate dynamic task tags
  hosts: localhost
  connection: local
  gather_facts: false
  tasks:
    - name: Load deployment tasks
      ansible.builtin.include_tasks:
        file: deploy.yml
        apply:
          tags: deploy
      tags: deploy

ansible-playbook -i localhost, site.yml --tags deploy

При таком запуске ожидается сообщение deployment task selected. Если удалить apply, оставив только внешний tags, include будет выбран, но нетегированная debug-задача внутри не пройдёт отбор. Пример позволяет проверить именно наследование без изменения файлов конфигурации или перезапуска служб.

Обратная ошибка — добавить теги только внутренним задачам. Тогда внешний include может быть пропущен, и до содержимого Ansible не дойдёт. Иногда include помечают always, чтобы он был доступен при различных selections; это не делает все внутренние задачи безусловными. Выбор должен соответствовать тому, какие части файла действительно разрешено выполнять отдельно.

Когда удобнее import_tasks

Статический import обрабатывает список задач заранее и передаёт свой tag импортированным задачам. Если файл фиксирован и должен целиком относиться к deploy, можно заменить задачу включения:

    - name: Import deployment tasks
      ansible.builtin.import_tasks: deploy.yml
      tags: deploy

Этот фрагмент заменяет предыдущую задачу в tasks, а не добавляется рядом. Два варианта одновременно выполнили бы содержимое дважды при обычном запуске. Выбор include или import влияет также на доступность задач при предварительном просмотре и момент обработки условной логики; это не просто разные написания одного действия.

Динамический include удобен, когда файл выбирается во время выполнения или включение используется в цикле. Статический import подходит для заранее известной структуры. Если нужен только общий tag статического набора, import часто делает намерение понятнее. Не переводите существующий динамический сценарий в import без проверки условий и переменных.

Проверим, что показывает предварительный просмотр

ansible-playbook -i localhost, site.yml --list-tags
ansible-playbook -i localhost, site.yml --tags deploy --list-tasks

Эти команды помогают увидеть структуру, но динамически включаемые внутренние задачи не раскрываются так же полно, как статические. Поэтому отсутствие внутренней строки в list-tasks не является достаточным доказательством, что она никогда не выполнится. Сопоставляйте просмотр с типом повторного использования и безопасным тестовым запуском.

Дополнительно проверьте --skip-tags: исключение может отменить выбор задачи, даже если другой tag явно запрошен. Gather facts и специальные теги также влияют на картину. В примере facts отключены, чтобы вывод демонстрировал только включение и debug.

Оценим самостоятельность выбранной части

Теги фильтруют выполнение, но не создают зависимости. Если deploy использует переменную, которую до этого вычисляла нетегированная задача, выборочная часть может оказаться неполной. Для реального playbook проверьте входные данные и нужные подготовительные шаги выбранного сценария.

Хороший tag обозначает осмысленную операцию с понятными входами и результатом. Когда оба уровня отбора заданы явно, команда --tags перестаёт быть случайной попыткой запустить часть большого файла и становится проверяемым интерфейсом автоматизации.

Ещё по теме

• Ansible Vault и no_log: где секреты остаются после расшифровки
• Ansible check mode: что реально проверяет dry run и чего он не видит

Продолжить изучение

Хотите собрать настройку серверов в повторяемый процесс? Inventory, роли, шаблоны и обновление сервисов входят в программу «Ansible: автоматизация инфраструктуры».