Как использовать несколько разных кукольных мастеров от одного марионеточного агента?

Question

Существует необходимость в том, чтобы один контакты кукольного агента некоторыеразные кукольные мастера.

Причина: существуют различные группы, которые создают разные и независимые наборы проявлений.

Возможные группы и их задачи

Производитель
• Применение: конфигурация приложения
• Безопасность: закалка
• операции: таблицы маршрутизации, инструменты мониторинга

Каждая из этих групп должны запустить его собственный марионеточный мастер - данные (манифесты и соответствующие данные) должны быть строго разделены. Если это возможно, одна группа должна даже не видеть/иметь доступ к манифестам других (мы используем MAC на операциях марионеточного агента).

Мысли и идей, которые потерпели неудачу:

• использования (только) Хир не является гибким в случае необходимости - есть необходимость иметь различные манифесты.
• r10k: поддерживает несколько окружений, но в каждой среде может быть доступен только один набор манифеста.
• несколько, но такой же кукольный сервер, используя, например, DNS round robin: это наоборот. Нам нужны разные кукольные мастера.

Некоторые способы, которые могли бы быть возможно, но ...

• запуск нескольких экземпляров марионеточных агентов. Это «странно». Преимущество: права доступа могут быть ограничены по мере необходимости (например, кукольный агент приложения может запускаться под пользователем приложения).
• исправление марионетки, которое может обрабатывать более одного марионеточного мастера. Недостаток: может быть, некоторая работа.
• с использованием других механизмов для разделения ответственности. Пример: используйте разные git-репозитории. Создайте одного марионеточного мастера. Марионеточный мастер вытаскивает все разные репозитории и служит манифестам.

Мои вопросы:

1. Существует ли прямой способ реализации этого требования с куклой?
2. Если нет, есть ли какая-то лучшая практика, как это сделать?

Answer 1

Хотя я думаю, что то, что вы пытаетесь сделать здесь, лучше всего решить, включив все ваши модули и данные в один мастер, и что использование сред будет в точности такой же ситуацией (разные мастера предоставят другую набор модулей/данных), это может быть достигнуто за счет внедрения стандартной инфраструктуры с несколькими ведущими устройствами (один главный мастер CA для подписывания сертификатов, несколько мастеров компиляции с сертификатами, подписанными одним и тем же ведущим центром CA, сконфигурированные для перенаправления трафика сертификатов в другом месте) и настроить каждый мастер на иметь все, что вам нужно.Затем вам нужно указать, с каким мастером вы хотите зарегистрироваться в каждом прогоне (cronjob или какой-либо другой подход), и иметь возможность для одной проверки изменить настройки, установленные другим (например, исключая концепцию упрочнения/безопасности). Я бы посоветовал вам глубже подумать о том, как сотрудничать с вашими разнообразными аспектами (git repos для данных и модулей каждого подразделения, которые имеют контроль доступа), чтобы центральный мастер мог удовлетворить ваши потребности (и доступ к этому хозяину был бы единственным способом получать данные/модули со всех сторон). Этот тип установки будет сложным для реализации, но конечный результат будет более надежным и поддерживаемым. Кукольный инк. может даже быть в состоянии сделать консультацию, чтобы помочь вам понять это правильно.

Есть, вероятно, и другие подходы, просто fyi.

Answer 2

Я часто находил удобным для многопользовательских марионеточных агентов для целей развития, потому что с местным марионеточным сервером вы можете мгновенно протестировать изменения манифеста - нет необходимости совершать, нажимать и r10k deploy environment, как есть, re только с использованием среды каталогов и одного (удаленного) кукольного сервера.

Я нашел, что лучший способ сделать это - просто изменить конфигурацию пути (в противном случае вы столкнетесь с проблемами, например, с сертификатами CA, которые не могут быть проверены на другом сервере) - форма вашего «запуска нескольких экземпляров кукольных агентов ". (Я до сих пор запустить их все привилегированные, так все они могут использовать склонный package {} и т.д.)

Для Кукол 3, я бы сделать это путем изменения LIBDIR с --libdir (потому что ssldir находился под LIBDIR), но теперь (Кукольный 4+), более разумно менять --confdir. Так, например:

$ sudo puppet agent -t     # Runs against main puppet server 
$ sudo puppet agent -t \ 
    --server=puppet.dev.example.com \ 
    --confdir=/etc/puppetlabs/puppet-dev # Runs against dev puppet server