Когда целесообразно использовать диспетчер конфигурации (например, Puppet / Chef / Ansible)?

На моем текущем рабочем месте я присматриваю за двумя хост-машинами VMware, физической машиной OpenBSD, тремя виртуальными машинами Debian и шестью виртуальными машинами Windows Server (2008/2012).

Я рассматриваю возможность внедрения инструмента управления конфигурацией, такого как Puppet или Chef. Разумно ли это, или затраты на изучение инструмента перевесят преимущества? Где переломный момент между управляемостью и стоимостью внедрения?

ИМХО, стоит учиться, даже если вы управляете только одним сервером,

Да, будет кривая обучения. Да, вы расстроитесь. Тем не менее, за эти затраты вы будете возвращены в несколько раз за счет надежных, согласованных развертываний в один клик, конфигурации сервера с управлением версиями, простоты настройки сред тестирования / разработки и т. Д.

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

(Sidenote: рассмотрим также Ansible. Это мой предпочитаемый CM, и с ним очень легко начать работать - гораздо проще, чем Puppet или Chef. Кроме того, поддержка окон в Ansible идет хорошо.)

Я рассматриваю возможность внедрения инструмента управления конфигурацией, такого как Puppet или Chef. Разумно ли это, или затраты на изучение инструмента перевесят преимущества?

Это разумно в зависимости от того, сколько времени и денег вам нужно сжечь, и от того, сжигаете ли вы свои деньги или нет.

Инструмент управления конфигурацией (любой из них) становится ценным навыком на современном рынке.

Потратить время на изучение и внедрение инструмента CM, возможно, не самая эффективная вещь с точки зрения вашего бизнеса или среды, но с вашей квалификацией это может стоить.

Где переломный момент между управляемостью и стоимостью внедрения?

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

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

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

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

Имейте в виду, я предвзят. Вы должны оценить каждый инструмент CM самостоятельно.

Как сказал @EEAA, количество серверов не имеет значения. Вы можете воспользоваться преимуществами использования управления конфигурацией на одном компьютере:

• задокументированная установка (задокументирована с помощью сценариев CM)
• надежное развертывание (вы можете [повторно] развертывать свою установку снова и снова
• устойчивость настройки (текущий сервер квакает - раскрутить новый)
• повторное использование (когда вы дошли до точки наличия второго сервера - у вас уже есть сценарии CM, которые вы можете перезапустить с первого)
• обновления (это как новая установка, просто на другой платформе)

Я могу сказать, что мне пришлось внедрить CM для всех моих персональных серверов, так как я работаю там нечасто и забыть все мелкие детали. Наличие сценариев CM в то время как может показаться трудоемким (оно есть), окупаемость того стоит. В долгосрочной перспективе вы сэкономите гораздо больше времени на настройку.

У меня есть опыт работы с Puppet и Ansible. Ansible проще IMO, поскольку он процедурный, а Puppet декларативный. Есть плюсы и минусы для обоих, но я выдернул достаточно волос из-за загадочных ошибок Puppet.

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

Тем не менее, он имеет определенное применение даже для автономных серверов - вы можете настроить пользователей-администраторов, стандартные (с локальными вариациями) конфигурации sshd, postfix или snmpd, а также использовать их для простого сбора информации, например, соблюдения политики или проверки на уязвимость в виде «шелл-шока».

Кроме того, как упомянуто EEAA, он имеет значение для документирования установки, если вы убедитесь, что он действительно переводит сервер из базового состояния в рабочее состояние. Хорошо сочетать его с системой контроля версий (git), чтобы сделанные вами изменения были версионными и документированными. Это очень ценно, если у вас есть команда администраторов.

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

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

Также вам необходимо выяснить, как вы планируете внедрять изменения, внесенные в ваши классы, контролируемым образом и как поддерживать различные версии ваших манифестов.

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

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

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