Я собираюсь начать новый проект, который отчасти потребует развертывания множества идентичных узлов примерно трех разных классов:
Все узлы будут работать на экземплярах Ubuntu 10.04, хотя у них будут установлены разные пакеты.
Я немного знаком с Chef по предыдущим проектам, но не считаю себя экспертом. Стремясь проявить должную осмотрительность, я исследовал альтернативные возможности. У нас есть несколько сотрудников, которые давно пользуются Puppet, и они посоветовали мне взглянуть на него.
Однако мне трудно оценить оба варианта. Chef и Puppet во многом используют одну и ту же доменную терминологию - пакеты, Ресурсы, атрибутыи так далее, и у них есть общая история, которая проистекает из разных подходов к одной и той же проблеме. Так что в некотором смысле они очень похожи. Но большая часть сравнительной информации, которую я нашел, например Эта статья, немного устарело.
Если бы вы начинали этот проект сегодня, какие вопросы вы задали бы себе, чтобы решить, следует ли использовать Chef или Puppet для управления конфигурацией? (Примечание: я не хочу получить ответ на вопрос «Что мне использовать: Chef или Puppet?»)
И Puppet, и Chef прекрасно могут делать то, что вы хотите. Лучше всего будет начать делать то, что вы пытаетесь сделать, и решить, какой инструмент вам больше нравится. Я думаю, что вам нужно задать следующие важные вопросы:
Вы хотите DSL? - Рецепты от шеф-повара написаны рубином, у марионетки есть DSL. Хороший ли DSL или плохой выбор - одно из самых больших различий между поваром и марионеткой. Ссылка, которую вы отправили сравнение bitfield consulting есть хорошие комментарии по этому поводу, которые вы должны прочитать, если еще не сделали. Я также нашел это сообщение в блоге полезно, обязательно прочтите и комментарии.
Вы знаете рубин? - Если вы не знаете рубин, начать работу с шеф-поваром может быть сложнее или потребовать больших затрат времени, так как вам нужно выучить новый язык. Кукла имеет свою собственный язык с которой легко начать. Начиная с марионетки 2.6, манифесты могут быть написаны на рубине слишком.
На Open Source Bridge в 2009 году у них была группа авторов и представителей chef, puppet, bcfg2, cfengine и automateit, которую вы можете смотреть на bliptv в котором содержится 1,75 часа обсуждения утилит управления конфигурацией.
Opscode / Chef рассказывает о разнице между ним и марионеткой в их FAQ также.
Я думаю, что ваше незнание правильных вопросов может быть связано с тем, что у вас нет слишком большого опыта работы с любым из них, как только вы начнете их использовать, вы начнете видеть различия между ними. Я бы посоветовал прийти с некоторыми реальными жизненными проблемами, которые вы решите с поваром или марионеткой, а затем начните пытаться их решить и посмотреть, что вам в них нравится / не нравится. С Opscode / Chef они предлагать размещенное решение что для начала вы можете бесплатно настроить 5 узлов.
Позвольте мне сказать сначала - если вы не используете Puppet или Chef; нет неправильного ответа. Либо будет намного лучше, чем то, что вы делаете сейчас.
Как руководитель группы я сделал выбор в пользу Puppet для своей команды. Если бы я был командой, состоящей только из себя, я бы выбрал Chef. Вот почему:
В то время как мой опыт, безусловно, связан с системным администрированием, у меня есть опыт программирования. Это то, ради чего я ходил в школу, и я не привыкать писать полные приложения (а не только скрипты). Хотя я не знал Ruby, я хочу знать, и Chef был бы отличным поводом изучить оба.
Однако в моей команде полно системных администраторов, практически не имеющих опыта программирования, за исключением случайных сценариев оболочки. Для них создание марионеточного модуля во многом похоже на написание файла конфигурации. Он декларативен, здесь нет итераторов, и в целом он более удобен для администратора.
Команды, состоящие из разработчиков, выполняющих действия системного администратора, обычно предпочитают Chef. Поскольку DSL Puppet является декларативным, порядок (даже внутри отдельных файлов) не имеет значения, и это расстраивает многих, привыкших к более типичному языку программирования.
Я также слышал, что много раз говорилось, что Chef гораздо более дружелюбен к облаку, чем Puppet, но в прошлом году Puppet сделал акцент на этом в своем продукте Puppet Enterprise. Я не могу сказать, исходя из опыта облачных возможностей любого из продуктов.
Из-за этих качеств сложился стереотип (и часто он верен), что Puppet будет более распространенным на предприятии на физических машинах, где Chef управляет стартапами в облаке. Конечно, есть исключения, но то, что я видел, безусловно, подтверждает стереотип.
Если это команда из одного человека, оцените оба и выберите тот, который вам нравится. Однако, если, как и я, у вас есть команда людей, убедитесь, что вы ставите потребности своей команды в приоритет над любыми личными предпочтениями, это спасет вас позже, когда вы попытаетесь получить поддержку.
Полное раскрытие информации, мы не используем ни один из них, хотя мы оценили их внутренне, пытаясь выбрать систему управления конфигурацией. Так что не считайте меня экспертом по любому из этих вопросов.
И так далее. Но вы сами очень легко ответите на эти вопросы: задайте их! Подготовка и запуск образца - это несколько часов вашего времени для каждого продукта, и, учитывая, что все, для чего вы его используете, будет использоваться в течение длительного времени, время того стоит. Вы можете не только почувствовать, как они справляются со специфическими для платформы вещами (например, на основе Debian и apt, на основе RPM и yum), но это определенно поможет вам почувствовать приложения.
Также имейте в виду, что все функции в мире не компенсируют сложный интерфейс, плюс, это может выявить проблемы, специфичные для вашей инфраструктуры - то есть, что произойдет, если файлы конфигурации будут обновлены в другом порядке чем ожидалось?
Так что это мой совет; Chef и Puppet не так уж и сложны, чтобы настроить один сервер и один или два клиента, и вы получите личный опыт работы с обоими. Кроме того, если вы начнете настраивать его и поймете, что это огромная проблема, у вас уже будут знания, прежде чем вы начнете это делать.
Если в вашем проекте есть люди, которые уже имеют опыт работы с Puppet, я предлагаю вам просто использовать Puppet.
Chef и Puppet довольно похожи, и оба проекта одинаково качественны. Если у вас есть доступ к людям, у которых уже есть опыт работы с Puppet, просто используйте Puppet.
Вышеупомянутое, безусловно, является хорошим руководством, я также люблю задавать эти общие вопросы всякий раз, когда я рассматриваю новую стороннюю зависимость.
Это хорошие индикаторы общего успеха проекта и могут отчасти предсказать продолжительность его жизни.
Попробуйте найти людей, которые использовали Chef или Puppet больше пары месяцев, и спросите их об их опыте.
Для меня это тесно связано с традициями определенного сообщества. Исторически Chef был ближе к ребятам из RubyOnRails. Также большая часть популярности Chef в сообществе ROR, потому что Engineyard построила свою инфраструктуру поверх Chef.