#ansible #ansible-playbook
#ansible
Вопрос:
У меня есть роль wp-vhost
, у которой есть одна роль, от которой она зависит:
// roles/wp-vhost/meta/main.yml
---
dependencies:
- { role: nginx }
При каждом запуске wp-vhost
nginx
роль также будет выполняться. Я понимаю, что это нормально, и это желаемое поведение.
Однако во время моей локальной разработки время излишне теряется на выполнение nginx
роли, когда я хочу запускать только задачи, определенные в wp-vhosts
, поскольку я знаю, что nginx
они выполнялись ранее, и настраивал необходимую среду для wp-vhost
.
Есть ли способ выполнить playbook с ролями без выполнения зависимостей ролей?
Ответ №1:
Я бы сделал это так, чтобы использовать теги Ansible и применить их к вашему конкретному коду «wp-vhost».
Предполагая wp-vhost
, что основной сценарий вашей роли main.yml
включен , хорошей схемой является выделение реальных задач в вспомогательный сценарий, называемый чем-то вроде wp-vhost.yml
, included from main.yml , чтобы код, отличный от nginx, получал тег, который не применяется к роли nginx. В этом случае:
- include: wp-vhost.yml
tags: wp-vhost
Чтобы использовать тег для каждого фрагмента кода Ansible (будь то включенный файл задач или роль), попробуйте записать каждую роль, упомянутую в dependencies
, как это:
- role: nginx
tags: nginx
В режиме тестирования вы можете запускать только определенные для wp-vhost части, подобные этой:
$ ansible-playbook --tags wp-vhost main.yml
Или вы можете запустить весь сборник воспроизведения, включая любые зависимости, подобные этой — по умолчанию выполняется все, игнорируя теги:
$ ansible-playbook main.yml
Это позволяет легко быстро запускать только части сложного набора каскадных ролей и включать файлы при тестировании, а также использовать роль wp-vhost обычно в зависимостях других ролей.
Влияние на структуру роли
Тщательное использование тегов не влияет на структуру роли или использование вообще, и вы обычно используете теги только для тестирования.
Для более сложных ролей обычно в любом случае структурировать задачи в отдельные файлы, сохраняя main.yml простым, например:
- name: Set up base OS
include: base_os.yml
tags: base_os
- name: Ensure logs are rotated
include: logrotate.yml
tags: logrotate
- name: Create users and groups
include: users_groups.yml
tags: users_groups
Решение без включения файлов
Если вы не хотите изменять использование файлов включения в wp-vhosts, вам нужно будет использовать блоки в playbook (Ansible 2.0 ):
- hosts: all
roles:
- role: nginx
tags: nginx
tasks:
- block:
- debug: msg=hello
- someaction: ...
tags: wp-vhosts
Обратите внимание, что окончательное tags:
соответствие block:
so применяется ко всем задачам в этом блоке. Это чище, чем разбивать сборник пьес на несколько пьес.
Альтернатива без тегов
Вы можете использовать when:
условие для вызова роли в зависимостях ролей wp-vhost и определить переменную, например, debug_mode
для управления этим. Однако такая логика отладки / тестирования будет загромождать вашу кодовую базу по сравнению с определением тега для каждого вызова роли или файла задачи.
Комментарии:
1. Привет @RichVel, разве описанный выше подход не эквивалентен отказу от определения любых зависимостей для
wp-vhost
роли в мета-роли? Если я превращуwp-vhost
роль в отдельный сборник задач с отдельными задачами, она перестанет быть ролью, которой можно делиться, импортировать, определять как зависимость и т. Д. Я намерен поддерживатьwp-vhost
иnginx
как отдельные роли, а не отдельные сборники / коллекции включенных задач. Возможно, то, чего я хочу достичь (иногда запуск роли без ее зависимостей), нелегко достичь с помощью Ansible .. если я не понял что-то не так..2. @luqo33 — если вы не укажете никаких тегов, роль будет работать «как задумано» с зависимостью nginx. Обычно вы указываете теги только тогда, когда хотите, чтобы часть роли / задач выполнялась с помощью короткого пути — теги являются полностью необязательными и не препятствуют использованию роли в качестве зависимости. Я обновил ответ примером в конце.
3. Еще раз спасибо, я обнаружил, что ваш подход позволяет мне запускать роли без их зависимостей. Однако следует сделать одно замечание, что, в основном, если в основном сборнике воспроизведения перечислены роли, а не задачи, подобные so:
- {role: wp-vhosts, tags: [vhosts]}
, запуск тега «vhosts» ВСЕГДА будет запускать зависимости ролей, потому что здесь тег применяется ко всей роли (и ее зависимостям). Таким образом, решение состоит в том, чтобы избавиться от тега в главном файле playbook и вместо этого применить теги к отдельным задачам в этой роли (предпочтительно с использованием предложенных операторов include). Как следствие, это влияет на структуру роли.4. Это имеет смысл, учитывая, что одна игра каскадирует свои теги для ролей и задач внутри нее. Я отредактировал свой ответ, чтобы показать, как это можно сделать с помощью блоков, чтобы только задачи получали тег, без подверженного ошибкам назначения тегов для каждой задачи.
5. Мой личный голос за интенсивное
when:
использование. Вы просто проверяете, представлен ли nginx (даже конкретная версия) в системе, если это так, то эта зависимость будет пропущена. Если версия не соответствует, старая версия будет удалена, а новая установлена. ИМХО, это гораздо более «стратегический» подход.