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

Chef / Puppet с несколькими серверами конфигурации

Поддерживает ли Puppet или Chef реплицированные серверы puppetmasterd / Chef? Мне кажется очень удивительным, что эти инструменты вызывают единую точку отказа, но я не смог найти упоминания об этом ни в их документации, ни в Google.

Я знаю, что Puppet и Chef можно запускать без сервера (возможно, с обновлением, например, git, как описано в http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control), но он выглядит как гражданин второго сорта и, по-видимому, теряет некоторую способность контролировать.

Для марионетки вам понадобится

  1. Идентичные манифесты. Этого можно добиться сохранение ваших манифестов в системе контроля версий и проверять их на каждом сервере, что вам в любом случае следует делать.
  2. Единая база данных для сохраненная конфигурация, если вы его используете. Это так же просто, как переключиться с sqlite по умолчанию на MySQL или PostgreSQL. Затем вы можете использовать инструменты этой базы данных для репликации базы данных, если хотите.
  3. Сертификаты из одного центра сертификации на всех кукловодов. Дэн Боде есть лучшее объяснение, которое я видел. Однако это может не работать так, как вы ожидаете. Кроме того, я не уверен, как это работает с клиентскими сертификатами (т.е. / var / lib / puppet / ssl / ca / ​​signed / *). Может быть, их проверка всегда выполняется одним ЦС (что создает единую точку отказа), или, возможно, файлы pem будут распространены каждому марионеточному мастеру после того, как они подписаны ЦС.

Chef был разработан с нуля для работы с несколькими серверами для всех его внутренних компонентов, поскольку это основная функция Платформа Opscode - хорошо масштабируемый размещенный Chef Server.

Различные основные компоненты Chef Server:

  • Сервер API
  • Хранилище данных (CouchDB)
  • Поисковая система (SOLR)

Таким образом, каждый из этих компонентов может работать на отдельных серверах, и Chef может быть настроен для использования отдельных серверов для каждого компонента. Для получения информации о конфигурации см. Настройки конфигурации Chef страница. В первую очередь, настройки couchdb_url и solr_url могут указывать либо на отдельный сервер (или серверы), на котором выполняются эти компоненты, либо на балансировщик нагрузки, расположенный перед ними.

API Chef Server также потребуется доступ к кулинарным книгам, которые могут находиться в общей файловой системе.

Если вас беспокоит единственная точка отказа, создайте марионеточный кластер :)

  1. Создайте кластер с corosync/pacemaker (или сердцебиение старой школы), сделайте его активным / пассивным или даже активным / активным
  2. Дублируйте важные данные двух (или более) серверов с помощью DRBD или другой метод
  3. Прибыль!

Клиенты марионеток получают свои манифесты с марионеточного сервера, идентифицированного DNS (если вы не укажете сервер на клиенте, но это не очень хорошо), поэтому у вас есть много способов гарантировать, что вы никогда не останетесь без сервера, будь то активный / активный сервер. пассивный кластер, где пассивный получает IP-адрес в случае сбоя активного или даже меняет запись DNS на новый сервер в случае сбоя (первый вариант является наиболее элегантным).

В те дни отличный ресурс для кластеров - это документ Cluster from Scratch от кластерные лаборатории. Руководство включает в себя примеры конфигурации DRBD, поэтому оно очень подробное.