#ansible #ansible-role
#ansible #ansible-роль
Вопрос:
Проблему лучше всего описать на примере:
Есть две роли:
mailserver: базовая конфигурация почтового сервераmailinglist: приложение для рассылки
Программе списка рассылки требуется почтовый сервер для передачи входящих сообщений в «виртуальный почтовый ящик» программы списка рассылки. Для этого требуется некоторая настройка почтового сервера. Но почтовый сервер не знает ни о роли списка рассылки, ни о других ролях с аналогичными требованиями к конфигурации.
Что я хотел бы сделать, так это:
mailinglist(и другие подобные роли) сохраняет конфигурацию транспорта в переменнойtransport_config. Это может быть «транспортная карта» типа $email => $ spool.mailinglistзависит отmailserverроли.mailserverнастраивает его «транспорт» с помощью переменнойtransport_config.
Есть ли способ сделать что-то подобное в Ansible? Или другое решение этой проблемы? Невозможно использовать переменные роли типа {role: mailserver, transport_config: ...} , поскольку в зависимости от почтового сервера может быть более одной роли.
Что я могу придумать, так это обходной путь: почтовый сервер считывает / анализирует каталог конфигурации, в котором определены транспортные карты. mailinglist и другие роли добавляют файлы в этот каталог. Проблема здесь в том, что для этого часто требуется «конструктор конфигурации», который считывает такие каталоги конфигурации и генерирует основной файл конфигурации.
Комментарии:
1. вы сообщили, что не можете использовать
dotdeeorassemble, потому что они не могут собирать строки. Можете ли вы привести нам пример синтаксиса конфигурации, который вам нужен для вашегоmailserver?2. Это что-то вроде
transport_config = file:/etc/mailserver/transport_foo, file:/etc/mailserver/transport_bar.3. Разрешены ли продолжения строк в этом синтаксисе? Как закончить строку с помощью ` `, чтобы продолжить содержимое в следующей строке? Возможно, подобным образом вы могли бы использовать
assemble, чтобы поместить каждый транспорт в отдельную строку с продолжением.
Ответ №1:
Вы можете выполнить это, используя зависимости ролей.
В mailinglist роли под roles/mailinglist/meta/main.yml добавьте что-то вроде этого:
---
dependencies:
- { role: mailserver, transport_config: ... }
Сделайте то же самое для любых других похожих ролей.
Комментарии:
1. Как написано в вопросе, это невозможно сделать. В любом случае спасибо!
2. На самом деле, вы неправильно поняли мой ответ. Зависимость от роли находится в роли mailinglist. Другие роли, которые также зависят от
mailserver, могут иметь свои собственные зависимости в своих собственных,meta/main.ymlиtransport_configпеременная будет меняться соответствующим образом. Пожалуйста, пересмотрите ответ.3. Но при этом роль почтового сервера будет запускаться несколько раз, каждый раз перезаписывая последнюю конфигурацию почтового сервера.
4.
allow_duplicates: falsedocs.ansible.com/ansible/latest/user_guide/…
Ответ №2:
В ответ на ваш комментарий о «сборщике конфигурации» см. Модуль сборки ansible. Сложная часть может заключаться в том, чтобы собрать все файлы в одно место перед запуском модуля сборки.
В противном случае предложение tima о host_ и group_vars имеет смысл.
Комментарии:
1. Ах, здорово, не знал об этом модуле. К сожалению, это не сработает с моим примером, поскольку конфигурация транспорта выполняется в одной строке в файле конфигурации. Например.
transport_config = foo:bar, foo2:bar2, ....2. В моем случае значения, разделенные запятыми, могут разделять несколько строк, так что это действительно работает. И, возможно, это сработает для большинства вариантов использования.
Ответ №3:
Я знаю, что на этот вопрос есть длинный ответ, но я только что нашел работоспособное решение, и оно немного хитрое.
Я использую третью settings роль, у которой нет задач, только переменные в defaults/main.yml . Документы немного расплывчаты в этом вопросе, но значения здесь передаются всем зависимым ролям, поэтому, если обе роли зависят от settings своих meta/main.yml файлов, обе получают общий набор значений. Они переопределяются обычными способами, через group_vars файл.
Меня удивило то, что, поскольку settings роль используется более одного раза, это не имеет значения, потому что в ней нет задач, и эти данные могут поступать оттуда вверх по цепочке зависимостей.
Это совершенно новая форма потока данных в Ansible, о которой я не знал, что это возможно.
Ответ №4:
Рассмотрите возможность управления mailserver файлом конфигурации с помощью чего-то вроде dotdee :
- Оригинальное сообщение Дастина Киркланда, описывающее концепцию
dotdeeРепозиторий Дастина- Более простая реализация с меньшим количеством функций в Python
С помощью dotdee вы собираете свой окончательный файл конфигурации из серии файлов, размещенных в .d каталоге.
В вашем случае mailinglist роль и другие, зависящие от mailserver , будут удалять фрагменты конфигурации в .d каталоге (созданном mailserver ролью) и запускать команду для обновления mailserver файла конфигурации, подобного dotdee --update /path/to/mailserver/conf .
Комментарии:
1. Выглядит как
assembleмодуль Ansible, но имеет ту же слабость, то есть он не может собирать строки, только файлы.
Ответ №5:
Я недостаточно хорошо знаком с вашими приложениями здесь, чтобы быть уверенным, но я думаю, что вам может быть лучше использовать переменные хоста или группы для передачи вашей конфигурации вашим ролям. Роли могут содержать ваши значения по умолчанию и др. и ожидать получения значений переменных хоста / группы, которые вы устанавливаете на индивидуальной основе. Это может означать обработку каждого экземпляра приложения как хоста, а не как физического хоста. То, как вы это моделируете, зависит от многих тонкостей вашего рабочего процесса, конфигурации и приложения.
Этот недавний поток затрагивает некоторые вещи такого рода:https://groups.google.com/forum /#!topic/ansible-project/yrnsx2Mw6rc
Комментарии:
1. Возможно, я ошибаюсь, но это не решит мою проблему, поскольку сами роли обеспечивают конфигурацию базовых ролей. В моем примере я не хочу настраивать транспорт, поскольку это «деталь реализации».