Настроить несуществующие роли с зависимыми ролями

Проблема лучше всего описана на примере:

Есть две роли:

  • mailserver: базовая конфигурация почтового сервера
  • mailinglist: приложение списка рассылки

Программное обеспечение списка рассылки нуждается в почтовом сервере для транспортировки входящих писем в программное обеспечение списка рассылки "виртуальный почтовый ящик". Для этого требуется некоторая конфигурация почтового сервера. Но почтовый сервер не знает о роли списка рассылки и других ролях с аналогичными требованиями к конфигурации.

Что я хотел бы сделать, так это:

  • mailinglist (и другие подобные роли) сохраняет конфигурацию транспорта в переменной transport_config. Это может быть "транспортная карта", например $email = > $spool.
  • mailinglist зависит от роли mailserver.
  • mailserver настраивает его "транспорт" с помощью переменной transport_config.

Есть ли способ сделать что-то подобное в Ansible? Или другое решение этой проблемы? Невозможно использовать переменные роли, такие как {role: mailserver, transport_config: ...}, поскольку в зависимости от почтового сервера может быть более одной роли.

То, о чем я могу думать, является обходным путем: почтовый сервер читает/анализирует каталог конфигурации, в котором определены транспортные карты. mailinglist и другие роли добавляют файлы в этот каталог. Проблема здесь в том, что для этого часто требуется "конструктор конфигурации", который читает такие каталоги конфигурации и генерирует основной файл конфигурации.

ОТВЕТЫ

Ответ 1

В ответ на ваш комментарий о "компоновщике конфигурации" см. собрать незаменимый модуль. Сложной частью может быть получение всех файлов в одном месте, прежде чем запускать сборный модуль.

В противном случае разумное предложение host_ и group_vars имеет смысл.

Ответ 2

Вы можете сделать это, используя ролевые зависимости.

В mailinglist сайта роли по roles/mailinglist/meta/main.yml сайта roles/mailinglist/meta/main.yml, добавить что - то вроде этого:

---
dependencies:
  - { role: mailserver, transport_config: ... }

Сделайте то же самое для любых других подобных ролей.

Ответ 3

Рассмотрите возможность управления конфигурационным файлом mailserver с чем-то вроде dotdee:

С помощью dotdee вы собираете свой окончательный файл конфигурации из серии файлов, помещенных в каталог .d.

В вашем случае роль mailinglist и другие в зависимости от mailserver будут отбрасывать фрагменты конфигурации в каталоге .d (созданный ролью mailserver) и запускать команду для обновления конфигурационного файла mailserver например dotdee --update /path/to/mailserver/conf.

Ответ 4

Я знаю, что это длинный ответ, но я только нашел работоспособное решение, и это немного подлый.

Я использую третью роль settings, у которой нет задач, только переменные в defaults/main.yml. Документы немного расплывчаты в этом вопросе, но значения здесь становятся рифлеными ко всем зависимым ролям, поэтому, если обе роли зависят от settings через свои файлы meta/main.yml, оба получают общий набор значений. Они можно переопределить обычными способами, используя файл group_vars.

Неожиданностью для меня было то, что, поскольку, да, роль settings используется более одного раза, это не имеет значения, потому что в ней нет задач, и эти данные могут перетекать оттуда в цепочку зависимостей.

Это совершенно новая форма потока данных в Ansible, которую я не знал, была возможна.

Ответ 5

Я не достаточно знаком с вашими приложениями здесь, но я думаю, что вам может быть лучше, используя переменные хоста или группы, чтобы передать вашу конфигурацию в свои роли. Роли могут содержать ваши значения по умолчанию и др. И ожидать получения значений переменных хоста/группы, которые вы устанавливаете на индивидуальной основе. Это может означать рассмотрение каждого экземпляра приложения как хоста, а не психического хоста. Как вы его моделируете, это зависит от многих тонких задач вашего рабочего процесса, конфигурации и приложения.

Эта недавняя тема затрагивает некоторые из таких вещей: https://groups.google.com/forum/#!topic/ansible-project/yrnsx2Mw6rc