Глобальное против местного управления марионетками

8

Кто-нибудь когда-нибудь управлял несколькими территориально распределенными системами с Puppet?

У меня есть несколько почти одинаковых развертываний (кроме IP-адресов серверов), управление которыми я хочу преобразовать в Puppet.

У меня есть 2 варианта:

Каждое развертывание должно содержать собственный PuppetMaster для предоставления локальных конфигураций, а затем каким-то образом синхронизировать PuppetMasters (возможно, снова с puppet)
Разместите PuppetMaster на AWS EC2 для обеспечения высокой доступности и настройки всех развертываний из одной точки

Кто-нибудь пробовал второй вариант, и как получилось? Особенно меня интересует производительность High-Availability в такой среде.

Спасибо.

puppet

— SyRenity
источник

7

В любом подходе, который вы предлагаете, нет ничего плохого. У нас есть три мастера кукловодства, все они расположены на одном сайте и обслуживают узлы по всему миру - мы разделяем их в зависимости от того, находится ли соединяющий узел кукол в dev / test / prod. Другие люди предпочитают управлять мастером кукол по географическому региону. Другие люди имеют много кукловодов, некоторые управляют только одним узлом!

Главное в том , что это жизненно важно , что вы храните и управлять PuppetMaster манифеста дерево в системе управления версиями - относиться к нему как любой другой код вашей компании поддерживает. Я бы порекомендовал Git, но Subversion также поможет, если вы к этому привыкли. Puppetmaster - это просто служба, которая обслуживает конкретный вид вашей VCS, а не сама центральная база данных.

С вашим контентом в VCS вы можете затем развернуть необходимые манифесты / модули для соответствующих puppetmasters и легко синхронизировать их. Похоже, что для людей есть модуль git / svn repo / module на модуль puppet, хотя ничто не мешает вам поместить все дерево в один репо / модуль.

Мои вопросы к вам будут:

Сколько узлов в каждом развертывании? Если вы говорите о 50+, то наверняка стоило бы пригласить местного кукловода.
Есть ли у сторонних разработчиков какие-либо сторонние организации, которые используют их в дополнение к вашей компании? Хозяин кукол должен иметь очень высокий уровень безопасности - считайте, что он является ключом к двери всех ваших систем и будет содержать очень конфиденциальную информацию.
Точно так же для PM на основе развертывания вы бы разместили их на своем собственном сервере / виртуальной машине, или на существующую машину нужно было бы дать задачу? Я настоятельно рекомендую, чтобы сервер puppetmaster выполнял эту роль отдельно для безопасности.
Как вы ожидаете, что EC2 обеспечит вам более высокую доступность? Насколько я понимаю, экземпляры EC2 не являются HA, хотя должно быть возможно запустить 2+ puppetmasters за сервисом балансировки нагрузки AWS.
Разве развертывания очень разные? Вы хотите изменить их в разное время дня? Несколько кукловодов дают вам более тонкий уровень контроля.

— Майк Паунтни
источник

1

Привет. Мы говорим о 10-20 узлах максимум в каждом развертывании, развертывания во всем мире. Там нет третьих лиц, разрешенных внутри развертывания. Я на самом деле заинтересован сконцентрировать все данные, связанные с Puppet, на выделенной машине, поэтому PM будет размещен на экземпляре EC2. Я, вероятно, буду использовать Heartbeat + DRBD для HA. Развертывания - это, в основном, одни и те же устройства, так как разные IP-адреса серверов различны. Еще раз спасибо.

— SyRenity

Это звучит очень похоже на то, что один кластер puppetmaster в EC2, вероятно, поможет вам. Просто убедитесь, что вы используете Git или Subversion для безопасного хранения своих манифестов :)

— Майк Паунтни,

2

Вы также можете использовать систему без Puppetmaster, используя распределенную VCS, такую как Git, используя схему, описанную здесь:

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

— Джон Арундел
источник

Если у вас нет puppetmaster, вы теряете поддержку хранимых конфигураций, которая является одной из самых мощных функций Puppet. Подумайте, что сбор информации между машинами встроен в обновления; например, вы можете автоматически собирать информацию о запущенных сервисах на всех (управляемых марионетками) хостах для генерации правил межсетевого экрана, правил маршрутизации, мониторинга конфигураций, резервного копирования на основе запросов и т. д.

— Дэвид Гарднер

Да, это справедливо. Конечно, есть преимущества в использовании полноценной системы на основе Puppetmaster, и обычно я это делаю. Я могу видеть ситуации, когда очень легкая, основанная на VCS система, подобная этой, была бы полезна, хотя.

— Джон Арундел

Если вы выбираете настройку без мастера, вы можете сделать это и настроить сервер puppetmaster для получения средств только от факультетов - тогда он не обязательно должен быть слишком высоким.

— Тимур

0

У нас также есть несколько мастеров кукол, различные среды, которые мы синхронизируем. Для этого мы управляем всеми нашими кукольными модулями и манифестами в subversion, а затем разворачиваем кукольные модули на кукловодов, используя обычные кукольные манифесты и модуль vcsdeploy, который выполняет проверку:

http://www.practicalclouds.com/content/guide/pclouds-vcsdeploy-deploy-stuff

Когда мы хотим синхронизироваться, мы помечаем версию, а затем обновляем node.pp для мастера Puppet.

С уважением

Дейв

— user1238985
источник