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