Подписка на RSS

Puppet против Chef: 10 причин, из-за которых выигрывает Puppet

Puppet, Chef, cfengine, и Bcfg2 – игроки в пространстве управления конфигурациями. Если вы ищете Linux решения для автоматизации или инструменты управления конфигурациями серверов, то вы скорее всего натолкнетесь на такие 2 технологии, как Puppet и Opscode Chef. У них очень похожая архитектура, и они решают одинаковые виды задач. Puppet от Reductive Labs существует дольше, у него большое количество пользователей. Chef от Opscode извлек несколько уроков из разработки Puppet и у него есть клиент высокого уровня – EngineYard.

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

“Chef против Puppet” – это продолжающийся спор, но вот 10 преимуществ, которые сегодня есть у Puppet над Chef по моему мнению.

  1. Большее количество инсталляций
    Проще говоря, практически все используют Puppet, а не Chef. В то время как на сайте Chef есть только небольшой список компаний, испольщующих его, у Puppet есть более 80 организаций, в том числе Google, Red Hat, Siemens, большое количество крупных фирм по всему миру, и несколько университетов из основных, включая Stanford и Harward Law School.
    Это значит, что у Puppet серьезные намерения, и облегчает его распространение. Когда люди узнают, что эту же технологию использует Google, они полагают, что она работает. У развертываний Chef нет этого преимущества (пока). Разработчики и системные администраторы часто смотрят на своих коллег в других компаниях для социального доказательства.
  2. Большее количество разработчиков
    Puppet настолько широко используется, что большое количество людей работают над ним. У Puppet много контрибуторов в исходный код ядра, но также он породил разнообразие систем поддержки и сторонних дополнений специфичных для Puppet, в том числе Foreman. Популярные инструменты создают свои собственные экосистемы.
    Число разработчиков Chef растет быстро, но пока остает от Puppet, и его разработчики безусловно менее опытны в работе над ним, так как это более молодой проект.
  3. Выбор языков конфигурации
    Puppet использует для конфигурирования серверов язык, который специально разработан для этой задачи: это предметно-ориентированный язык, оптимизированный для задачи описания и связывания таких ресурсов, как пользователи и файлы.
    Chef использует расширение Ruby. Ruby хороший язык программирования общего назначения, но он не разрабатывается специально для управления конфигурацией, и обучение Ruby намного сложнее чем обучение язык Puppet.
    Некоторые считают, что отсутствие предметного-ориентированного языка является преимуществом Chef. Они приводят аргумент: «Вы получаете мощь Ruby бесплатно». К сожалению, в Ruby есть много неинтуитивных вещей, особенно для начинающих, также необходимо овладеть большим и сложным синтаксисом.
    В Puppet есть экспериментальная поддержка написания манифестов на языке, встроенном в Ruby, также как в Chef. Поэтому возможно лучше будет сказать, что Puppet дает вам выбор использования либо его предметно-ориентированного языка, либо мощь языка общего назначения Ruby. Я схожусь во мнении с Chris Siebenmann, что проблема использования языков общего назначения для конфигураций в том, что они жертвуют ясностью ради мощи, и это не является выгодным обменом.
  4. Более длинный путь в коммерческом использовании
    Puppet находится в коммерческой эксплуатации много лет, и он непрерывно совершенствовался и улучшался. Он развертывался в очень больших инфраструктурах (5000+ машин) и уроки производительности и масштабирования полученные из этих проектов, внесли вклад в разработку Puppet.
    Chef все еще находится на ранней стадии разработки. С моей точки зрения он еще не созрел для промышленного использования. Он не поддерживает столько операционных систем, сколько Puppet. Так что возможно он даже не может рассматриваться как вариант в вашем окружении. Хотя развертывания Chef сущестуют на множестве платформ, поэтому проверяйте доступность для вашей ОС.
  5. Лучшая документация
    У Puppet есть огромная поддерживаемая пользователям вики с сотнями страницдокументации и исчерпывающих справочных руководств и для языка, и для типов ресурсов. В добавок к этому, он активно обсуждается в нескольких списках рассылоки есть очень популярный IRC канал. Поэтому, какова бы ни была ваша проблема с Puppet, ответ найти легко. (Если вы начинаете знакомиться с Puppet, можете обратиться к моему руководству по Puppet.)
    По вполне понятным причинам разработчики Chef больше сконцентированы на том, чтобы сделать рабочий инструмент, чем на написание обширной документации.Руководства по Chef существуют, но они немного схематичны. Информация есть, но она рассеяна и сложно найти необходимую часть.
  6. Больше способов использования
    И Chef, и Puppet могут использоваться как инструмент развертывания. Документация по Chef нацелена на пользователей, развертывающих Ruby on Rails приложения, в частности в облачных окружениях – основной его пользователь это EngineYard, и это чем они занимаются, большая часть руководств направлена на это. Chef не ограничивается Rails, но справедливо будет сказать, что это его основной способ использования.
    Puppet, напротив, не ассоциируется ни с каким конкретным языком или web фреймворком. Его пользователи управляют приложениями Rails, но также PHP приложениями, Python и Django, Mac десктопами или AIX мэйнфреймами с Oracle.
    Необходимо прояснить, что это не является техническим преимуществом Puppet, это результат того, что у его сообщества, документации и использования база более обширна. Чем бы вы не пытались управлять, используя Puppet, вы скорее всего обнаружите, что кто-то уже это сделал и может помочь вам.
  7. Поддержка большего количества платформ
    Puppet поддерживает множество платформ. Независимо от того где он запущен, на OS X или на Solaris, Puppet знает какой пакетный менеджер и какие команды использовать для создания ресурсов. Сервер Puppet может быть запущен на любой платформе, которая поддерживает Ruby. Он может быть запущен на довольной устаревших версиях ОС и Ruby (важный момент во многих промылшенных окружениях, которые консервативны в смысле обновления программного обеспечения).
    Chef поддерживает меньшее чем Puppet количество платформ, в большой степени потому, что зависит от недавних версий Ruby и CouchDB. Хотя количество поддерживаемых платформ все время растет, также как и у Puppet. Puppet и Chef могут развертывать все области вашей инфраструктуры, которые находятся в списк поддерживаемых платформ.
  8. Не изобретает заново велосипед
    Chef был сильно вдохновлен Puppet. Он в большой степени дублирует функциональность, уже существующую в Puppet – но у него нет всех возможностей Puppet. Если вы уже используете Puppet, Chef не может предложить вам ничего нового, что стоило бы перехода.
    Конечно Puppet тоже переизобрел много функциональности, которая была в предыдущих поколениях программного обеспечения, управляющего конфигурациями, таких как cfengine. Все повторяется.
  9. Явное управление зависимостями
    Некоторые ресурсы зависят от других ресурсов – вещи должны быть выполнены в определенном порядке. Chef похоже на shell скрипт: вещи выполняются в том порядке, в котором они написаны, и это все. Но так как нет способа явно сказать, что один ресурс зависит от другого, порядок ваших ресурсов в коде может быть критичен, или нет – читатель не сможет определить это посмотрев на набор команд. Следовательно, рефакторинг и перемещение кода могут быть опасны, простое изменение порядка ресурсов в текстовом файле может сломать работу.
    В Puppet зависимости всегда явные и вы можете свободно менять порядок ресурсов в коде, не влия на порядок приложения. Ресурс в Puppet может «слушать» изменения в вещах, от которых он зависит: если изменяется конфигурация Apache, может быть автоматически вызыван перезапуск Apache. Верно и обратное, ресурсы могут «уведомлять» другие ресурсы, которые могут быть заинтересованы в них. Chef тоже может это делать, но от вас не требуется делать эти зависимости явными – и это с моей точки зрения плохо, хотя некоторые не соглашаются. Andrew Clay Shafer продуманно написал об этом различии: Puppet, Chef, Dependencies and WorldViews).
    Фанаты chef считают, что его поведение детерминировано: одни и те же изменения будут каждый раз применяться в одном и том же порядке. Sterve Traugott и Lance Brown спорят о важности этого свойства в статье Why Order Matters: Turing Equivalence in Automated Systems Administration.
  10. Лучшая осведомленность потребителей
    Хотя это не техническик момент, но возможно он самый важный. Когда вы говорите «управление конфигурациями», большинство людей (по крайней мере среди тех, кто знает о чем речь) обычно ответят «Puppet». Puppet владеет этим пространством. Я знаю, что есть большое, готовое помочь сообщество, к которому я могу обратиться, и даже опубликованные книги про Puppet. Puppet настолько широко признан, что фактически любая задача, с которой вы можете столкнуться, уже была кем-то обнаружена и решена.

Заключение

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

Автор статьи: John Arundel
Дата: 12 января 2010
Оригинал статьи

Leave a Reply

Your email address will not be published. Required fields are marked *