На самом деле Puppet хорошо подходит для мультимастериальных сред с предостережениями. Основным? Многие части Puppet хотели бы быть централизованными. Центр сертификации, службы инвентаризации и панели мониторинга / отчетов, пакетные файлы и сохраненные конфигурации - все они в своих лучших проявлениях (или просто требуют) настройки, в которой есть только одно место для общения.
Тем не менее, это вполне выполнимо, чтобы заставить многие из этих движущихся частей работать в среде с несколькими мастерами, если вы согласны с постепенной потерей некоторых функций, когда вы потеряли свой основной сайт.
Давайте начнем с базовой функциональности, чтобы получить отчет об узле для мастера:
Модули и манифесты
Эта часть проста. Контроль версий им. Если это распределенная система управления версиями, то просто централизуйте и синхронизируйте, а также измените поток push / pull по мере необходимости на сайте аварийного переключения. Если это Subversion, то вы, вероятно, захотите сделать репозиторий svnsyncна своем сайте аварийного переключения.
Центр сертификации
Один из вариантов здесь - просто синхронизировать файлы центра сертификации между мастерами, чтобы все имели один и тот же корневой сертификат и могли подписывать сертификаты. Это всегда казалось мне "делать это неправильно";
- Должен ли один мастер действительно видеть свой собственный сертификат, представленный в аутентификации клиента для входящего соединения от другого мастера, как действительный?
- Будет ли это надежно работать для службы инвентаризации, приборной панели и т. Д.?
- Как добавить дополнительные действительные имена альтернативных DNS в будущем?
Я не могу честно сказать, что я провел тщательное тестирование этого варианта, так как он кажется ужасным. Однако, похоже, что Puppet Labs не хотят поощрять эту опцию, как отмечается здесь .
Итак, у нас есть центральный CA-мастер. Все доверительные отношения остаются работоспособными, когда ЦС не работает, поскольку все клиенты и другие мастера кэшируют сертификат ЦС и CRL (хотя они не обновляют CRL так часто, как должны), но вы не сможете подписывать новые сертификаты до вы создаете резервную копию основного сайта или восстанавливаете мастер CA из резервных копий на отказоустойчивом сайте.
Вы выберете одного мастера в качестве CA, и все остальные мастера отключат его:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Затем вы захотите, чтобы центральная система получала весь трафик, связанный с сертификатами. Есть несколько вариантов для этого;
- Используйте
SRVподдержку новой записи в 3.0, чтобы указать все узлы агента в нужное место для ЦС -_x-puppet-ca._tcp.example.com
- Настройте
ca_serverопцию конфигурации во puppet.confвсех агентах
Проксируйте весь трафик для связанных с CA запросов от агентов на правильный мастер. Например, если вы запускаете все ваши мастера в Apache через Passenger, то настройте это на не-CA:
SSLProxyEngine On
# Proxy on to the CA.
ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
# Caveat: /certificate_revocation_list requires authentication by default,
# which will be lost when proxying. You'll want to alter your CA's auth.conf
# to allow those requests from any device; the CRL isn't sensitive.
И это должно сделать это.
Прежде чем мы перейдем к вспомогательным услугам, примечание стороны;
DNS-имена для главных сертификатов
Я думаю, что это самая веская причина для перехода на 3.0. Скажем, вы хотите указать узел на «любой старый рабочий мастер».
В версии 2.7 вам понадобится общее имя DNS, как puppet.example.com, и все мастера нуждаются в этом в своем сертификате. Это означает установку dns_alt_namesв их конфигурации, повторную выдачу сертификата, который был у них до того, как они были настроены в качестве главного, повторную выдачу сертификата, когда вам нужно добавить новое DNS-имя в список (например, если вы хотите, чтобы несколько DNS-имен агенты предпочитают мастеров на своем сайте) .. некрасиво.
С 3.0 вы можете использовать SRVзаписи. Дайте всем своим клиентам это;
[main]
use_srv_records = true
srv_domain = example.com
Тогда для мастеров не нужно никаких специальных сертификатов - просто добавьте новую запись в свой SRVRR at, _x-puppet._tcp.example.comи все готово, это живой мастер в группе. Более того, вы можете легко сделать логику выбора мастера более сложной; «любой старый рабочий мастер, но предпочитает тот, который находится на вашем сайте», устанавливая разные наборы SRVзаписей для разных сайтов; не dns_alt_namesнужно
Отчеты / Панель инструментов
Это работает лучше всего централизованно, но если вы можете жить без него, когда ваш основной сайт не работает, то нет проблем. Просто настройте всех ваших мастеров с правильным местом для размещения отчетов.
[master]
reports = http
reporturl = https://puppetdash.example.com/reports/upload
... и все готово Ошибка загрузки отчета не является фатальной для запуска конфигурации; это будет просто потеряно, если тост сервера приборной панели.
Инвентаризация фактов
Еще одна приятная вещь, которую нужно приклеить к вашей приборной панели - это служба инвентаризации. Если в документации facts_terminusуказано значение, restрекомендуемое в документации, это фактически нарушит работу конфигурации, когда центральная служба инвентаризации не работает. Хитрость здесь в том, чтобы использовать inventory_serviceконечную остановку на нецентральных мастерах, что допускает постепенный отказ.
facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140
Настройте центральный сервер инвентаризации для хранения данных инвентаризации через ActiveRecord или PuppetDB, и он должен постоянно обновляться, когда служба доступна.
Итак, если вы согласны с довольно скромной средой управления конфигурацией, где вы даже не можете использовать ЦС для подписи сертификата нового узла, пока он не будет восстановлен, тогда это может работать просто отлично - хотя это было бы очень приятно если бы некоторые из этих компонентов были более дружественными к распространению .