Я поддерживаю два центра обработки данных, и по мере того, как большая часть нашей важной инфраструктуры начинает контролироваться через марионетку, важно, чтобы мастер марионетки работал на втором сайте, если наш основной сайт выйдет из строя.
Еще лучше было бы иметь своего рода активную / активную настройку, чтобы серверы на втором сайте не опрашивали через WAN.
Существуют ли какие-либо стандартные методы высокой доступности марионеточных нескольких площадок?
Puppet на самом деле очень хорошо подходит для сред с несколькими мастерами, но с некоторыми оговорками. Главный? Многие части Puppet хотят быть централизованными. Центр сертификации, инвентарь и сервисы панели / отчетов, архивирование файлов и сохраненные конфигурации - все они наилучшим образом подходят (или просто требуют) настройки, в которой есть только одно место для общения.
Тем не менее, вполне реально заставить многие из этих движущихся частей работать в среде с несколькими мастерами, если вас устраивает постепенная потеря некоторых функций, когда вы теряете свой основной сайт.
Начнем с базовой функциональности, чтобы получить отчет от узла мастеру:
Эта часть проста. Контроль версий. Если это распределенная система контроля версий, просто централизуйте и синхронизируйте, а также измените поток push / pull по мере необходимости на резервном сайте. Если это Subversion, то вы, вероятно, захотите svnsync репо на ваш резервный сайт.
Один из вариантов здесь - просто синхронизировать файлы центра сертификации между мастерами, чтобы все они использовали один и тот же корневой сертификат и могли подписывать сертификаты. Мне всегда казалось, что это «неправильно»;
Честно говоря, я не могу сказать, что я провел тщательное тестирование этой опции, так как она кажется ужасной. Однако похоже, что Puppet Labs не намерены поощрять этот вариант, согласно примечанию. Вот.
Итак, что остается, так это иметь центрального мастера CA. Все доверительные отношения продолжают работать, когда CA не работает, поскольку все клиенты и другие мастера кэшируют сертификат CA и CRL (хотя они не обновляют CRL так часто, как должны), но вы не сможете подписывать новые сертификаты до тех пор, пока вы получаете резервную копию первичного сайта или восстанавливаете главный центр сертификации из резервных копий на резервном сайте.
Вы выберете одного мастера, который будет действовать как CA, а все остальные отключите его:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Затем вам нужно, чтобы эта центральная система получала весь трафик, связанный с сертификатами. Для этого есть несколько вариантов;
SRV поддержка записи в версии 3.0, чтобы указать все узлы агентов в нужное место для CA - _x-puppet-ca._tcp.example.comca_server параметр config в puppet.conf всех агентовПрокси-сервер всего трафика для запросов, связанных с ЦС, от агентов к правильному мастеру. Например, если вы запускаете все свои мастера в 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.
И это должно сработать.
Прежде чем мы перейдем к вспомогательным услугам, сделаем небольшое примечание;
Я думаю, что это самая веская причина для перехода на 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
Тогда для мастеров не нужны специальные сертификаты - просто добавьте новую запись в свой SRV RR в _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, и он должен обновляться всякий раз, когда услуга доступна.
Итак - если вас устраивает довольно простая среда управления конфигурацией, где вы даже не можете использовать CA для подписания сертификата нового узла, пока он не будет восстановлен, тогда это может работать нормально - хотя это было бы действительно хорошо если бы некоторые из этих компонентов были немного более удобен для распространения.
Подход «марионетки без хозяина», который описывает Ладададада, мне наиболее знаком (в основном это то, что мы делаем с radmind в моей компании). Я предполагаю, что более точно это «несколько мастеров, синхронизированных внешним процессом», где любой данный сервер может (теоретически) обслуживать всю нашу вселенную в чрезвычайной ситуации.
В нашем случае из-за природы radmind мы просто rsync расшифровки стенограмм и файлы данных от утвержденного мастера на сервер radmind каждого удаленного сайта, а клиенты получают свои обновления с сервера с коротким именем хоста radmind (через магию resolv.conf это оценивается как radmind.[sitename].mycompany.com - всегда локальный сервер radmind. Если локальный сервер не работает, его достаточно легко переопределить и указать на сервер любого другого сайта).
Этот вид процесса rsync, вероятно, будет работать и в вашей ситуации, но он, вероятно, неоптимален по сравнению с решением на основе контроля версий.
Для puppet или chef система на основе управления версиями имеет больше смысла, чем простой rsync по нескольким причинам, самая большая из которых заключается в том, что вы управляете версиями puppet-скриптов (а не целых образов ОС, как в случае с radmind).
В качестве дополнительных преимуществ управления на основе контроля версий вы можете иметь несколько человек, работающих над репозиторием одновременно (отличная победа для параллелизма), вы получаете историю изменений практически бесплатно, а если кто-то нарушит среду Puppet, у вас будет легкий откат (предполагая, что вы повторно использовать git у тебя также есть git blame который делает то, что написано на олове).
Креативное ветвление и слияние даже позволяет вам обрабатывать крупное обновление ОС или другой переход в рамках системы контроля версий - как только вы все сделаете правильно, просто переключитесь на новую ветку и (надеюсь) продакшн будет просто работать.
Если бы я реализовал это здесь, я бы, вероятно, воспользовался хуками перед фиксацией и после фиксации в git, чтобы гарантировать, что фиксируемые конфигурации марионетки являются разумными (предварительная версия на стороне клиента), и вытолкну их остальной части вселенной, если они есть (сообщение на стороне сервера - возможно, также запускает обновление среды, если ваша политика развертывания допускает такое поведение).
Что касается создания новых серверов puppetmaster на каждом сайте, вы можете просто проверить среду марионеток для каждого удаленного puppetmaster и использовать либо хакерский метод resolv.conf / hostname, который я описал выше, либо IP-адреса службы anycast, перенаправленные на локальные системы, такие как предложил Мичуельник ( последнее удобно, если вам нужно автоматическое переключение при отказе в случае взрыва марионеточного мастера одного сайта), чтобы убедиться, что каждый сайт видит «правильного» марионеточного мастера и не забивает ваши WAN-ссылки, пытаясь получить обновления.
Ребята из Brain Tree Payments очевидно объединили решения контроля версий и rsync наряду с некоторыми настраиваемыми задачами Capistrano - их решение кажется недоработанным в том смысле, что оно все еще полагается на элементы ручного рабочего процесса, но его можно адаптировать и автоматизировать без особых усилий.
Параноидально-компульсивный тестировщик во мне любит их noop Шаг проверки работоспособности - ненависть к ручным процессам во мне желает некоторого уровня автоматизации вокруг них ...