На моем текущем рабочем месте я наблюдаю за двумя хост-машинами VMware, физической машиной OpenBSD, тремя виртуальными машинами Debian и шестью виртуальными машинами Windows Server (2008/2012).
Я подумываю о внедрении инструмента управления конфигурацией, такого как Puppet или Chef. Разумно ли это, или накладные расходы на изучение инструмента перевешивают преимущества? Где переломный момент между управляемостью и стоимостью внедрения?
ИМХО стоит изучить, даже если вы управляете только одним сервером,
Да, придется учиться. Да, вы разочаруетесь. Тем не менее, эти затраты будут окупаться многократно за счет надежного, последовательного развертывания одним щелчком мыши, конфигурации сервера с контролем версий, простоты настройки сред тестирования / разработки и т. Д.
В дополнение к преимуществам вашей текущей работы, возможность добавить систему CM к вашему резюме - большая победа. Ожидается, что современные системные администраторы будут иметь как минимум контакт в систему управления конфигурацией, если не на умение.
(Примечание: рассмотрите также Ansible. Это мой предпочтительный CM, и он очень легко начать работать - намного проще, чем Puppet или Chef. Кроме того, поддержка Windows в Ansible идет хорошо.)
Я подумываю о внедрении инструмента управления конфигурацией, такого как Puppet или Chef. Разумно ли это, или накладные расходы на изучение инструмента перевешивают преимущества?
Это разумно в зависимости от того, сколько времени и денег у вас есть, и от того, сжигаете ли вы свои деньги.
Инструмент управления конфигурацией (любой из них) становится ценным навыком на современном рынке.
Тратить время на изучение и внедрение инструмента CM может быть не самым эффективным с точки зрения вашего бизнеса или среды, но с точки зрения вашего набора навыков это может иметь смысл.
Где переломный момент между управляемостью и стоимостью внедрения?
Большинство инструментов управления конфигурацией доступны бесплатно с той оговоркой, что их сложнее установить и запустить.
На этот вопрос немного сложно ответить, поскольку это действительно зависит от того, что вы делаете каждый день для управления этими серверами. Если от вас вообще ничего не требуется, инструмент управления конфигурацией может оказаться излишним.
Если вам действительно нужно привести свою инфраструктуру в предсказуемое и базовое состояние, то, возможно, не будет большого вреда подобрать самые основы чего-то вроде SaltStack или Ansible.
По моему личному опыту, Salt очень легко запустить и загрузить на серверы, и его можно использовать для очень простого удаленного выполнения и отчетности, что может пригодиться, если оно еще не реализовано в вашей среде.
Имейте в виду, я пристрастен. Вам следует самостоятельно оценить каждый инструмент CM.
Как и сказал @EEAA - количество серверов не имеет значения. Вы можете воспользоваться преимуществами использования управления конфигурацией на одной машине:
Могу сказать, что мне пришлось внедрить CM для всех моих личных серверов, так как я работаю там нечасто и забываю все мелкие детали. Хотя использование сценариев CM может показаться трудоемким (это так), окупаемость того стоит. В долгосрочной перспективе вы сэкономите гораздо больше времени, которое потратите на настройку.
У меня есть опыт работы с Puppet и Ansible. Ansible - это IMO проще, поскольку он процедурный, а Puppet - декларативный. У обоих есть плюсы и минусы, но я выдернул достаточно волос из-за загадочных ошибок Puppet.
Оба требуют много работы, если вы хотите создать чистую и многократно используемую конфигурацию. Затраты начинают окупаться, если у вас есть хотя бы два очень похожих сервера, например облака или скопления.
Тем не менее, он имеет некоторое применение даже для автономных серверов - вы можете настроить пользователей с правами администратора, стандартные (с локальными вариациями) конфигурации sshd, postfix или snmpd, а также использовать их для простого сбора информации, например, для соблюдения политики или проверки на уязвимость Shellshock.
Кроме того, как упоминалось EEAA, он имеет значение для документирования настройки, если вы убедитесь, что он действительно переводит сервер из базового состояния в рабочее состояние. Хорошо комбинировать его с системой контроля версий (git), чтобы вносимые вами изменения были версированы и документированы. Это очень ценно, если у вас есть команда администраторов.
Puppet или любая другая система управления приносит большие преимущества, которые были подчеркнуты другими ответами здесь, но когда дело доходит до управления, нет серебряной пули.
Например, создание классов марионеток для сложных систем требует много времени и усилий, а иногда и слез, поскольку существует множество подводных камней, а сообщения об ошибках не всегда ясны на 100%, и при обновлении программного обеспечения вы должны потратить время на адаптацию классов марионеток к любой новой спецификации или процедура и выясните, какой подход лучше всего подходит для этого (марионетка, например, декларативная, а обновление обычно процедурное)
Также вам нужно выяснить, как вы планируете внедрять изменения, внесенные в ваши классы, контролируемым образом, и как поддерживать различные версии ваших манифестов.
Вам также следует подумать о том, как обновить свое решение для управления, когда для этого придет время.
Если вы тратите значительное количество времени на написание, например, классов марионеток, вам придется выполнять множество установок в один клик, чтобы получить реальные преимущества.
Я рекомендую изучить все еще и там, где это уместно, то есть распространение файлов конфигурации может быть хорошим местом для начала, и брать его оттуда.