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

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

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

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

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

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

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

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

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

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

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

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

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

Сделайте основной случай первым

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

Добавить гибкость второй

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

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

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

1. Установите Apache
2. Установить основные конфиги
3. Добавьте vhosts к apache
4. Настройте любые дополнительные параметры
5. Запустите 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
}

Опять аддитив.

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

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

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

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

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

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

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

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

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