Кажется, я нашел два способа использования марионетки в нескольких средах:
1) Установите puppetmaster в каждой среде и обновляйте рецепты из системы управления версиями только для этой среды, когда будете готовы развернуть рецепты в этой среде.
2) Используйте одного puppetmaster и используйте переменную в puppet.conf каждого клиента, чтобы указать среду, а затем в puppetmaster укажите другой путь к модулю для каждой среды, и каждый из этих путей обновляется до ветви репозитория рецептов, предназначенной для этого. среда (например, разработка, постановка, продакшн).
Запуск только одного puppetmaster кажется, что на одну часть инфраструктуры нужно продолжать работать меньше, но есть некоторая дополнительная сложность в конфигурации.
Есть ли дополнительные плюсы или минусы одного из этих методов или чего-то, чего я полностью упускаю?
Вариант №1 не масштабируется. Будет больно управлять. Puppet поддерживает окружения именно по этой причине :)
Пусть один кукловод обслуживает несколько сред, каждая со своей собственной manifest
и modulepath
директивы. Это действительно распространенный подход, который используют многие люди. Также помните, что:
puppetmasterd.conf
и puppet.conf
файлы конфигурации.puppetd
вы также можете использовать --environment
аргумент.Вы можете вызвать puppetd из командной строки с помощью --environtment. Но это может быть проблемой, если вы хотите переместить много серверов с одного Env на другой.
В мастер project действует как интерфейс «внешних узлов» и позволяет назначать среды хостам / группам хостов из веб-интерфейса. Тогда у вас могут быть разные пути к модулям для разных хостов. Вы даже можете изменить Среды для узлов из интерфейса, позволяя перемещать пути к модулям из Dev-> Prod или как хотите.
Я думаю, тебе стоит взглянуть на кукольные теги
Использование марионеточных сред имеет несколько недостатков:
В компании, в которой я работаю, мы собираемся использовать 2 сервера puppetmaster - один для производства, а другой для остальных сред.
Чтобы упростить управление модулями марионеток на нескольких мастерах марионеток, вы можете хранить свои модули в VCS, например git, и развертывать их новые версии для мастеров марионеток через capistrano и т. Д.
Если вам нужно несколько сред не для управления версиями модулей марионетки, а для предоставления разных данных разным узлам в зависимости от среды (разные переменные, классы узлов и т. Д.), Есть еще несколько вариантов: * наследовать узлы разных сред из базовой «среды» Узлы * предоставляют набор параметров и классов для каждой среды через ENC (Puppet Dashboard, Foreman), в котором вы создаете группу для каждой среды с необходимым набором параметров и добавляете к ним свои узлы. * создать настраиваемый факт или настраиваемую функцию, возвращающую вашу среду (на основе локального файла / тега AWS / запроса к базе данных / чего угодно), и использовать этот факт для обслуживания различных данных в ваших манифестах с помощью условных выражений / extlookup / hiera.