Обзор: Puppet, Chef, Ansible, Salt

[@Yur4eg]

Меня вот интересует один вопрос. Проекты Salt и Ansible существенно моложе, чем Puppet и Chef. Всвязи с чем вызвано их появление на свет? Можно ли говорить о том, что это следующее поколение систем управления конфигурациями?

[@pashukoff]

Yes

[@pashukoff]

Да. Могу говорить за Ansible. После попыток быстро что-то сделать с Chef, Puppet, CFEngine. Ansible это глоток свежего воздуха. Базовые вещи можно начинать делать после прочтения одной А4 страницы. Автоматический репорт после выполнения команды максимально упрощает дебаг. У меня только одни вопрос: «Почему раньше нельзя было так просто сделать» :)

[@reiser]

Можно ссылку на это «одну А4 страницу»?
Разбираюсь в ansible, вопросов больше, чем ответов.

[@kirillrst]

Да, можно и так сказать про Ansible. Рефакторил как-то Puppet для крупного хостинга — было стойкое желание написать свой puppet из-за не очевидных часто конфигов на ruby, агента на сервере, из-за мелочей, которые могли бы быть реализованы проще. Автору ansible удалось избавиться от недостатков puppet: работа через ssh, простой конфиг в yaml, низкий порог вхождения, мои админы оценили.

[@camec]

В Puppet Enterprise наиболее полный веб-интерфейс из всех, позволяющий контролировать управляемые узлы в реальном времени с помощью предварительно созданных модулей и «поваренных книг» (cookbooks)

После этого абзаца невольно засомневался, что автор хоть немного повникал в реальную архитектуру Puppet.

[@morkot]

Я думаю, автор не вникал, а просто перевёл.

[@horridum]

Спасибо, поправил. А в архитектуру puppet я как раз сейчас вникаю, оф.документация очень даже ничего — правда на ее перевод я замахиваться боюсь. :-)

[@onlinehead]

На сколько я помню, cookbooks это концепция Chef, а не Puppet. Очевидно ошибка перевода.
Так же нет важных архитектурных отличий и табличка очень субъективная.
Одно наличие в Salt MQ подсистемы для получения статусов и логов с хостов, а в Chef реляционного Postgress для хранения данных говорит очень много о применимости и масштабируемости этих систем.
В общем, оригинальная статья не очень ок и может привести человека к ложному выбору.
Реально масштабно использовал только chef на 1000+ хостах. Летело:)

[@horridum]

В оригинале — «Puppet Enterprise has the most complete Web UI of the bunch, allowing for real-time control of managed nodes using prebuilt modules and cookbooks present on the master servers.», но с Вами согласен — о «поваренных книгах» в доках по Puppet упоминается в объяснении классов — «Classes: The Puppet classes (or Chef cookbooks, etc.) applied to this node». То ес ть по-русски — «Классы: Классы Puppet (или „поваренные книги“ Chef» и т.д.) применяемые к этому узлу". Каюсь, не очень удачный выбор статьи, однако опыта работы ни с одной из этих систем не было, о чем я честно предупредил в начале. :-)

[@heel]

Мы как раз переводим сейчас наши Rails проекты с Chef на Ansible. Базовые вещи в Ansible делаются действительно проще и понятнее нежели в случаи с Chef.

[@voidMan]

После мучительных попыток освоить Chef, пробовал Puppet, теперь попробую Ansible, он действительно кажется проще и понятнее, спасибо.

[@weirdan]

AnsibleWorks AWX теперь называется Ansible Tower.

[@jandosul]

Про Ansible незнал, думал буду учить chef/ruby. Спасибо

[@shishieff]

не сосвем понял про push для chef

можно делать
knife ssh «role:webserver AND chef_environment:production» «sudo chef-client» -С 4
и деплоить изменения сразу и с указанной конкуренцией ( что может быть удобно, когда сервера стоят за балансировщиком и нужно чтото рестартить).

По моему скромному мнению, chef идеалогически правильно заточен под devops workflow.