Зачем использовать Chef / Puppet вместо сценариев оболочки?

Новое в инструментах Puppet и Chef. Похоже, что работа, которую они выполняют, может быть выполнена с помощью сценариев оболочки. Возможно, это было сделано в сценариях оболочки, пока они не появились.

Я бы согласился, что они более читабельны. Но есть ли другие преимущества по сравнению со сценариями оболочки, кроме того, что они читаются?

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

chmod 640 /my/file

а также

file { "/my/file":
    mode => 640,
}

но есть большая разница между ними:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

а также

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

Что произойдет, если wget потерпит неудачу? Как ваш сценарий справится с этим? И что произойдет, если после этого в вашем скрипте будет что-то, что требует наличия $ FILE с правильным содержимым?

Вы можете утверждать, что можно просто вставить echo "Hello world" > $FILEсценарий, за исключением того, что в первом примере сценарий должен выполняться на клиенте, тогда как puppet компилирует все это на сервере. Поэтому, если вы изменяете контент, вам нужно всего лишь изменить его на сервере, и он изменит его на столько систем, сколько вы захотите. И кукольный автоматически обрабатывает зависимости и проблемы для вас.

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

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

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

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

Вы ответили на свой вопрос ...

Автоматизация становится все более масштабируемой и формализованной . В наши дни Puppet и Chef считаются стандартами (см. Объявления о работе ).

Скриптовые сценарии оболочки имеют свое место, но они не масштабируются в контексте движения DevOps. Читаемость является частью этого.

Шеф - повар делает его гораздо проще управлять и версию установки комплексной инфраструктуры, особенно в любом типе облаков среды против того , чтобы вручную FTP или ПКПП кучи скриптов , организованных в Нестандартизованных модах. В зависимости от того, каким количеством зависимостей вам нужно управлять, размер этого выигрыша может сильно различаться, что делает решение о переходе на решение CM неочевидным для многих людей.

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

Правильное решение CM помогает обеспечить успех в масштабе за счет упрощения межплатформенной автоматизации и совместной работы в команде. Хотя это можно сделать с помощью хорошо организованной, правильно поддерживаемой, версионной группы сценариев оболочки; Вы должны спросить себя «почему». Chef / Puppet и подобные технологии появились, потому что группа талантливых SysOps устала от необходимости снова и снова решать одни и те же проблемы и решила предложить нам лучший вариант.

Ключевые части:

• идемпотентность
• Простота управления зависимостями (управление версиями)
• Стандартизированная организация (принята на отраслевом уровне)
• Абстракция для отделения задач конфигурации сервера от деталей системного уровня
• Способность использовать знания сообщества (это гарантированно охватывает все вышеупомянутые принципы)

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

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

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

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

Если ваши потребности в сборке скромны (или вы предпочитаете изготавливать вручную органические серверы справедливой торговли со свободным диапазоном), сделайте это просто.

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

С учетом вышесказанного вы можете запускать Chef без сервера (chef-solo), и я уверен, что у Puppet есть аналог, где вы все еще можете использовать чужие кулинарные книги и рецепты без запуска центрального сервера.

Еще одним преимуществом является сообщество: есть много людей (многие из которых будут умнее и / или опытнее вас). Лично мне нравится, когда кто-то другой выполняет мою работу за меня, часто более масштабно, чем я бы.

Я создал оболочку автоматизации сервера на основе сценариев оболочки: https://github.com/myplaceonline/posixcube

Я уверен, что я не первый, кто делает такой проект, но я не мог найти что-то подобное, чтобы соответствовать моим потребностям, поэтому я подумал, что другие могут найти это полезным. У меня был только опыт работы с Chef, но когда я начал оглядываться на Ansible и других, я хотел попробовать сценарии оболочки, и мне пока нравится результат.