Puppet vs Chef, за и против от пользователей и вариантов использования [закрыто]

Я уже погуглил и прочитал статью «чтобы марионетка или шеф-повар, что это вопрос» .

Меня интересуют варианты использования, реальные реализации, в которых люди выбирали одно или другое на основе реальных проблем.

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

заранее спасибо

Честно говоря, я думаю, что это сводится к простой точке зрения: 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

http://slashroot.in/puppet-tutorial-how-does-puppet-work

Возможно, это изменилось с тех пор, как я пытался это сделать в последний раз, но когда я пытался использовать chef на RHEL, не было четкого способа его установки. Кто-то создал репозиторий yum, в котором были все необходимые пакеты, но в итоге он установил 200 нечетных пакетов. Puppet, с другой стороны, имеет один оборот (и пару зависимостей).