Запускать роль Ansible без запуска зависимостей, определенных в мета-стеке роли

#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 (даже конкретная версия) в системе, если это так, то эта зависимость будет пропущена. Если версия не соответствует, старая версия будет удалена, а новая установлена. ИМХО, это гораздо более «стратегический» подход.