Кукольнить все или нет?

Заметьте: есть много теоретических вопросов.

Недавно я читал о Puppet (и подобных системах), которые, как я считаю, могут значительно облегчить мою работу. Но я пытаюсь - и, к сожалению, не могу - понять, что все, что я могу «кукольник». Я могу представить себе «облака» или кластеры высокой доступности, где такая же конфигурация на других серверах. А как насчет рабочих станций? У меня есть один компьютер (centos с kvm), один ноутбук (fedora) и персональный сервер, можно (или нужно) его кукольник? Какие (не) преимущества? Или у нас в компании сотни серверов (в основном с centos), но каждый из них немного отличается. Не могу определиться, лучше ли иметь много конфигов на одном месте .. (Дис) плюсы? Буду рад всем вашим мнениям или ссылкам на эту тему.

Степень, в которой вы можете куколизировать всю среду, зависит от нескольких переменных:

Готовность сотрудников автоматизации писать автоматизацию для каждого. маленький. вещь.
Культурная обусловленность, которая позволяет «я просто изменю это одно, это все равно одноразово» превратиться в «я просто изменю это одно в этом марионеточном манифесте и применю его сейчас; это просто одноразовый . "
Степень неоднородности окружающей среды.

Определенно возможно кукловодить каждую ********** штуку, которую можно кукловодить, но для этого требуется правильная культура и поддержка от каждого, кто может прикоснуться к марионеточному устройству. Некоторыми устройствами принципиально сложно управлять таким образом, такие вещи, как рабочие станции и марионетка, лучше в качестве промежуточного инструмента, чем механизм управления конфигурацией.

Puppet прекрасен, когда вы управляете парком виртуальных машин, которые в основном делают одно и то же. Полная победа, и не нужно много усилий, чтобы добраться до нее.

На другом конце спектра у вас есть то, что у меня было на моей последней работе, а именно 200+ серверов, предоставляющих 130 сервисов, и лишь небольшая группа из них делает это с более чем одной машиной. Есть абсолютно компании (и университеты), которые придумали подобные вещи, но это требует больших усилий и большой поддержки. Для этого требуется, чтобы первый шаг процесса развертывания на новой машине не быть «Установить ОС», но «создать манифесты».

В конечном счете, это проблема культуры между усилиями и эффективностью, которую вам придется решать среди всего вашего ИТ-персонала.

Все, что достаточно похоже во всех системах (или их подмножестве), или что вы можете создать шаблон на основе факта, из которого вы можете извлечь facter это честная игра.

Вещи, которые действительно уникальны, вам, вероятно, не стоит беспокоиться, а следует просто выдавать конфигурации из файловой корзины.

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

Я думаю, что другие рассказали, почему, поэтому я попробую понять, как. Я думаю, понимание того, как кто-то может использовать Puppet, чтобы делать то, что вы хотите, сделает ваше решение более ясным.

Сначала сделайте основной случай

Ваш модуль Puppet для Apache по умолчанию не должен много делать. Установите Apache, настройте его на минимальный стандарт и запустите службу. Сделайте так, чтобы это работало на всех дистрибутивах, которые вам нужно поддерживать.

Добавьте гибкости во-вторых

Нам нужно добавить vhosts. В итоге вы получите систему, которая может отбрасывать файлы или удалять их из набора каталогов conf.d или vhosts.d / в зависимости от того, что вам нужно. То же самое с включением или настройкой модулей.

Используйте классы ролей или групп хостов, чтобы связать ваши строительные блоки вместе

Я думаю, что лучший способ использовать Puppet - убедиться, что он аддитивен. Используя приведенные выше примеры, у нас должен быть модуль, который

Установить Apache
Установить базовые конфигурации
Добавить vhosts в apache
Настройте любые дополнительные параметры
Запустите Apache

Вместо того, чтобы перегружать наш модуль Apache по умолчанию, чтобы делать именно то, что нам нужно для конкретного хоста или группы, мы должны обрабатывать этот класс роли или группы хостов.

class role::web_cust1 {
  include apache
  apache::vhost {'www.domain.com': }
  apache::vhost {'www.domain2.com': priority => '99', }
  include php
  include php-fpm
  include mysql
}

Снова добавка.

Положите особые случаи в Хиеру

Я большой поклонник того, чтобы позволить Puppet's Hiera, думать об этом как о базе данных для Puppet, хранить специальные биты. Если для определенного хоста или группы хостов требуется особая настройка, сначала установите в модуль разумное значение по умолчанию, чтобы обычные пользователи не знали об этом. Затем вставьте данные для этих специальных хостов или групп хостов, чтобы Хиера могла их использовать, передавая их Puppet по мере необходимости.

Мой вариант использования - порт прослушивания. Перед некоторыми серверами стоит Varnish или haproxy. По умолчанию модуль Puppet использует порт 80 Apache, но если Hiera находит данные, он отменяет это значение по умолчанию.

В настоящее время я нахожусь на переходе от достаточно похожей системы Puppetize к Puppetize everything и убежден, что в долгосрочной перспективе Puppetize everything - лучший подход.

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

Лично я также считаю, что принуждение себя вносить каждое изменение через Puppet заставляет меня более внимательно обдумывать это изменение. Когда я пишу манифесты, я более внимательно отношусь к каждому изменению, чем обычно пытаюсь взломать командную строку.

Ваши модули Puppet также станут лучше. У вас более одного модуля Nginx? Возможно, это означает, что ваш модуль Nginx не так уж хорош, и вам нужно сделать его достаточно гибким, чтобы удовлетворить все ваши особые потребности. По крайней мере, абстрагируйте сходство в основном модуле Nginx, который вы расширяете для «пользовательских» модулей.

Кроме того, насколько вы уверены в том, что сможете восстановить все свои серверы с особыми потребностями до их текущего состояния (в отношении конфигурации) в случае аварии? Если каждое изменение, необходимое для добавления заводского сервера Ubuntu во внутреннюю вики, является Puppetized, вы можете легко восстановить текущее состояние своей вики, включая вчерашнюю настройку памяти Tomcat, выполненную Бобом.

Наконец, это может быть очень сложно. Управление множеством очень разных серверов может привести к взлому кода Puppet, если вы не найдете время, чтобы все делать правильно. Если вы не используете Puppet Enterprise, рассмотрите возможность использования hiera и / или ENC, например Foreman, для отделения ваших данных от манифестов. Каждый день придумывайте что-нибудь другое. Пусть ваш коллега расскажет, как это работает в Puppet. Каждое изменение будет проще.