Назад | Перейти на главную страницу

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

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

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

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

Кто-нибудь пробовал второй вариант, и как он сработал? Меня особенно интересует производительность высокой доступности в такой среде.

Спасибо.

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

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

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

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

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

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

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

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

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

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

С уважением

Дэйв