Puppet vs Chef, за и против от пользователей и вариантов использования
Я уже погуглил и прочитал статью "чтобы марионетка или шеф-повар, что это вопрос".
Меня интересуют варианты использования, реальные реализации, в которых люди выбирали одно или другое на основе реальных проблем.
Меня особенно интересует интеграция с проблемами сапожников (я знаю, что кукольный - это стандартный подход в этом направлении); как у кого-нибудь есть опыт интеграции шеф-повара?
заранее спасибо
6 ответов
Честно говоря, я думаю, что это сводится к простой точке зрения: Chef кажется более императивным, программным решением, использование ruby в качестве языка мгновенно заставляет меня надеяться, что кто-то перенес его на python, как и путь мира со всеми идеи рубина.
Это не то, что вы хотите для такого рода вещей, хотя. Вы хотите поговорить с пустотой, в которой будет находиться система, и объявить:
"В порту 80 вызывается с севера демон по имени nginx. Его задача - служить".
"Пользователь должен существовать, его имя должно быть chiggsy, и он должен быть одним из сильных в группе колеса"
"Поднимите стену огня, тонкого в местах 80,443,8080"
И так далее, хотя, возможно, на языке менее цветочным.
Кукольный поддерживает эту парадигму лучше ИМО. Я бы использовал любой из них, у меня не было предпочтения, но когда дело дошло до меня, декларативное подходило мне лучше.
Марионетка.
Я написал подробное сравнение Chef с Puppet здесь: Puppet против Chef: 10 причин, почему Puppet выигрывает. Хотя он не включает варианты использования, я надеюсь, что он предоставит некоторые полезные отправные точки для людей, которые задаются вопросом, какой инструмент выбрать для автоматизации своей инфраструктуры.
Извините за многословие. Используйте инструмент, который облегчает выполнение вашей работы. В этом смысл автоматизации, верно?
История: Я использовал Puppet на прошлых концертах, и в прошлом месяце я потратил около недели, пытаясь привыкнуть к шеф-повару, чтобы посмотреть, смогу ли я переключиться на мой новый концерт.
Я не прыгнул.
Жаргон: Одна из неприятных проблем с обеими этими системами - перегрузка жаргоном. (рецепты, шаблоны, узлы, роли, атрибуты, поставщики) Это продолжается и продолжается. Я обнаружил, что шеф сделал еще один шаг. (Нож, шеф и т. Д.)
Зрелость кода: достаточно сказать, что я нашел шеф-повара слишком грубым. Это очень похоже на то, что чувствовала кукла в.21/.22 таймфрейме 3-4 года назад. Там происходит много потока.
Нельзя сказать, что этого не произошло и в марионетке. (Я заново обнаружил много замечательных особенностей в марионетках, которые появились только в последние несколько лет. - Соответствие регулярному выражению!)
Рубин: Мне не нравились все рубиновые перегрузки в Chef. (вам нужны драгоценные камни и грабли, прежде чем вы даже сможете начать) Вы можете использовать ruby для решения сложных задач в кукольном а'ла-факторе, но вам это не нужно, если вы этого не хотите.
Сложность: мне не нравился фокус на GUI на шеф-поваре. Я понимаю, что это симпатично, и у куклы есть веб-интерфейс в работах как дополнение, но я чувствую, что это должно быть более разъединенным.
У шеф-повара гораздо более сложная архитектура. Это может масштабироваться лучше, но есть много потенциальных точек отказа.
http://wiki.opscode.com/display/chef/Architecture
Шеф-повар нуждается в couchdb, rabbitmq и solr в дополнение к API-серверу и веб-интерфейсу.
Мне просто нужен простой клиент-серверный интерфейс, для которого не требуется структура MVC, а за ним - сложное хранилище данных.
Кукольный намного проще в этом отделе. (не сказать, что не так много дополнений, чтобы сделать его более грязным)
Начало работы: в конце концов, я пошел с тем, что я знал. Потратив неделю на хакерство на стороне и едва сумев разобраться с шеф-поваром, я смог вернуться к марионетке и выяснить свои основные потребности за несколько часов. (управление пакетами, управление пользователями, шаблоны конфигурационных файлов)
Предостережение о модулях: Puppet недавно перешел на использование "модулей", предоставленных третьими сторонами. Я не заканчивал тем, что использовал их, и я нашел широкий диапазон в их качестве. Обязательно загляните под крышки и посмотрите, что и как они работают, прежде чем копаться в них.
Вот мнение: мы попробовали все из них в нашей компании, и мы предпочитаем марионетку. Просто потому, что им легко пользоваться.
Я сам видел случаи, когда управление 1000 хостами с разными конфигами намного проще с марионеткой. Такие компании, как Google, используют Puppet для своего развертывания.
Основная архитектура проекта puppet такова, что она работает намного лучше, чем другие, если вы настроите ее правильно. Например, добавление ваших пользовательских фактов для ваших пользовательских конфигураций и т. Д. По ссылкам ниже может быть предоставлена некоторая информация http://slashroot.in/puppet-tutorial-installing-puppet-master-and-puppet-agent
Возможно, это изменилось с тех пор, как я пытался это сделать в последний раз, но когда я пытался использовать chef на RHEL, не было четкого способа его установки. Кто-то создал репозиторий yum, в котором были все необходимые пакеты, но в итоге он установил 200 нечетных пакетов. Puppet, с другой стороны, имеет один оборот (и пару зависимостей).