Проблема лучше всего описана на примере:
Есть две роли:
mailserver: базовая конфигурация почтового сервераmailinglist: приложение списка рассылкиПрограммное обеспечение списка рассылки нуждается в почтовом сервере для транспортировки входящих писем в программное обеспечение списка рассылки "виртуальный почтовый ящик". Для этого требуется некоторая конфигурация почтового сервера. Но почтовый сервер не знает о роли списка рассылки и других ролях с аналогичными требованиями к конфигурации.
Что я хотел бы сделать, так это:
mailinglist (и другие подобные роли) сохраняет конфигурацию транспорта в переменной transport_config. Это может быть "транспортная карта", например $email = > $spool.mailinglist зависит от роли mailserver.mailserver настраивает его "транспорт" с помощью переменной transport_config.Есть ли способ сделать что-то подобное в Ansible? Или другое решение этой проблемы? Невозможно использовать переменные роли, такие как {role: mailserver, transport_config: ...}, поскольку в зависимости от почтового сервера может быть более одной роли.
То, о чем я могу думать, является обходным путем: почтовый сервер читает/анализирует каталог конфигурации, в котором определены транспортные карты. mailinglist и другие роли добавляют файлы в этот каталог. Проблема здесь в том, что для этого часто требуется "конструктор конфигурации", который читает такие каталоги конфигурации и генерирует основной файл конфигурации.
В ответ на ваш комментарий о "компоновщике конфигурации" см. собрать незаменимый модуль. Сложной частью может быть получение всех файлов в одном месте, прежде чем запускать сборный модуль.
В противном случае разумное предложение host_ и group_vars имеет смысл.
Вы можете сделать это, используя ролевые зависимости.
В mailinglist сайта роли по roles/mailinglist/meta/main.yml сайта roles/mailinglist/meta/main.yml, добавить что - то вроде этого:
---
dependencies:
- { role: mailserver, transport_config: ... }
Сделайте то же самое для любых других подобных ролей.
Рассмотрите возможность управления конфигурационным файлом mailserver с чем-то вроде dotdee:
dotdeeС помощью dotdee вы собираете свой окончательный файл конфигурации из серии файлов, помещенных в каталог .d.
В вашем случае роль mailinglist и другие в зависимости от mailserver будут отбрасывать фрагменты конфигурации в каталоге .d (созданный ролью mailserver) и запускать команду для обновления конфигурационного файла mailserver например dotdee --update /path/to/mailserver/conf.
Я знаю, что это длинный ответ, но я только нашел работоспособное решение, и это немного подлый.
Я использую третью роль settings, у которой нет задач, только переменные в defaults/main.yml. Документы немного расплывчаты в этом вопросе, но значения здесь становятся рифлеными ко всем зависимым ролям, поэтому, если обе роли зависят от settings через свои файлы meta/main.yml, оба получают общий набор значений. Они можно переопределить обычными способами, используя файл group_vars.
Неожиданностью для меня было то, что, поскольку, да, роль settings используется более одного раза, это не имеет значения, потому что в ней нет задач, и эти данные могут перетекать оттуда в цепочку зависимостей.
Это совершенно новая форма потока данных в Ansible, которую я не знал, была возможна.
Я не достаточно знаком с вашими приложениями здесь, но я думаю, что вам может быть лучше, используя переменные хоста или группы, чтобы передать вашу конфигурацию в свои роли. Роли могут содержать ваши значения по умолчанию и др. И ожидать получения значений переменных хоста/группы, которые вы устанавливаете на индивидуальной основе. Это может означать рассмотрение каждого экземпляра приложения как хоста, а не психического хоста. Как вы его моделируете, это зависит от многих тонких задач вашего рабочего процесса, конфигурации и приложения.
Эта недавняя тема затрагивает некоторые из таких вещей: https://groups.google.com/forum/#!topic/ansible-project/yrnsx2Mw6rc