Какие правильные вопросы нужно задать, решая, использовать ли Chef или Puppet?

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

• Узлы данных , которые будут запускать закрытые экземпляры MongoDB.
• Узлы приложения , которые будут запускать экземпляры приложения Ruby on Rails и более старого приложения ASP.NET MVC.
• Обработка узлов , которые будут выполнять задания, запрошенные узлами приложения.

Все узлы будут работать на экземплярах Ubuntu 10.04, хотя на них будут установлены разные пакеты.

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

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

Если бы вы начинали этот проект сегодня, какие вопросы вы бы задали себе, чтобы решить, следует ли вам использовать Chef или Puppet для управления конфигурацией? (Примечание: я не хочу отвечать на вопрос «Должен ли я использовать Chef или Puppet?»)

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

Вы хотите DSL? - Рецепты от шеф-повара написаны на рубине, у куклы есть DSL. Хороший или плохой выбор DSL - одно из самых больших различий между поваром и марионеткой. Ссылка, которую вы разместили для сравнения Bitfield Consulting, содержит несколько хороших комментариев по этому поводу, которые вы должны прочитать, если вы еще этого не сделали. Я также нашел этот пост полезным, обязательно прочитайте комментарии.

Ты знаешь рубин? - Если вы не знаете рубин, начать работу с шеф-поваром может быть сложнее или потребовать больших затрат времени, так как вам нужно выучить новый язык. У Puppet есть собственный язык, с которым легко начать. Начиная с версии 2.6, манифесты могут быть написаны и на ruby .

На Open Source Bridge в 2009 году у них была группа авторов и представителей chef, puppet, bcfg2, cfengine и automateit, которую вы можете посмотреть на bliptv, где 1,75 часа обсуждают утилиты управления конфигурацией.

Opscode / повар говорит о разнице между ним и марионеткой в их FAQ , а также.

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

Позвольте мне сначала сказать - если вы не используете Puppet или Chef; нет неправильного ответа. Либо будет намного лучше, чем вы делаете сейчас.

Как руководитель команды, я сделал выбор в пользу Puppet для своей команды. Если бы я был просто командой, я бы выбрал Chef. Вот почему:

Хотя мой опыт, безусловно, в системном администрировании, мой опыт в программировании. Это то, ради чего я учился в школе, и я не привык писать полноценные приложения (не только сценарии). Хотя я не знал Руби, я бы хотел, и Шеф был бы отличным предлогом, чтобы изучить оба.

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

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

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

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

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

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

• Насколько легко настроить экземпляр?
• Какие настройки требуются клиенту для взаимодействия с сервером?

И так далее. Но вы сами можете легко ответить на эти вопросы: настройте их! Подготовка образца и запуск - это несколько часов вашего времени для каждого продукта, и, учитывая, что то, для чего вы его используете, вероятно, будет использоваться в течение длительного времени, время того стоит. Вы можете не только почувствовать, как они обрабатывают вещи, специфичные для платформы (например, основанные на Debian и apt, основанные на RPM и yum), но это определенно поможет вам почувствовать приложения.

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

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

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

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

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

• Каков возраст проекта?
• Насколько активно сообщество (списки рассылки, ошибки, irc и т. Д.)?
• Предоставляется ли хорошая надежная документация со стандартной практикой?

Это хорошие показатели общего успеха проекта и могут несколько предсказать продолжительность жизни.

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

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