Это вопрос религиозный больше.
Лично я — пользуюсь Chef по ряду причин:
— мне нравится ruby и писать рецепты на ruby больше чем DSL у puppet
— мой начальник — один из известных тренеров по chef в европе
— исходя из предыдущего пункта — chef у нас — стандарт на работе.
Если сравнивать с puppet — то у puppet немного более длинная история — а значит и немного больше литературы. а вскидку могу назват 2-3 англоязычных книги. chef пока не может этим похвастаться. Но у chef — просто прекрасная wiki и отличное коммьюнити где можно получить ответы на вопросы, а так же найти рецепты, советы и т.д.
На самом деле самый правильный метод выбора — так же как с linux-дистрибутивом первым. Лучше пользоваться тем, в чем разбирается соседский гуру. Но когда я начинал — у меня такого гуру еще не было, по этому меня выручили запросы в гугл вроде «chef vs. puppet» и «configuration management systems comparison» и просто интуиция совмещенная с авантюризмом, которые подсказали «chef перспективнее, моложе и интереснее для изучения»
Возможно я не совсем понятно написал, извините. Я имел в виду абстрактную ситуацию с различными дистрибутивами на однотипных узлах, отягощенную еще и различными версиями ос. А не просто множество разных версий одной ОС ан разных типах серверов.
Ну об этом я и на писал в заключении. Нужно просто оглянуться, собраться с духом — и переделать. Пока оно не превратилось в такой страшный для всех администраторов всем legacy который нужно поддерживать и ненавидеть.
Chef / Puppet и им подобные – не совсем похожи на capistrano. Capistrano — хорошее дополнение для этих инструментов, хотя и не обязательное. Cap позволяет выполнять команды на удаленных серверах. По сути — обёртка над ssh, особенно удобная для развертывания приложений.
Системы управления конфигурациями служат для того чтобы выполнить начальную(и повседневную) настройку сервера — установить ПО, развернуть нужные конфигурационные файлы и т.д. Особенно, когда таких(особенно однотипных) серверов больше двух.
А стоит ли использовать в малых системах — это личное дело каждого.
Мое мнение — да. Мне удобнее сначала написать рецепт, внимательно его прочитать, а потом запустить chef-client на нужных узлах и применить изменения. Плюс некоторая централизованность есть. Плюс возможность протетстировать предстоящие изменения на тестовой площадке.
если вкратце — то какая вам лично больше нравится. Лучше всего попробуйте обе. Первое впечатление бывает редко бывает обманчиво.
а так планы хорошие, только наверное очень смелые в той части где 12.04. Вот правда. Очень смелые.
Лично я — пользуюсь Chef по ряду причин:
— мне нравится ruby и писать рецепты на ruby больше чем DSL у puppet
— мой начальник — один из известных тренеров по chef в европе
— исходя из предыдущего пункта — chef у нас — стандарт на работе.
Если сравнивать с puppet — то у puppet немного более длинная история — а значит и немного больше литературы. а вскидку могу назват 2-3 англоязычных книги. chef пока не может этим похвастаться. Но у chef — просто прекрасная wiki и отличное коммьюнити где можно получить ответы на вопросы, а так же найти рецепты, советы и т.д.
На самом деле самый правильный метод выбора — так же как с linux-дистрибутивом первым. Лучше пользоваться тем, в чем разбирается соседский гуру. Но когда я начинал — у меня такого гуру еще не было, по этому меня выручили запросы в гугл вроде «chef vs. puppet» и «configuration management systems comparison» и просто интуиция совмещенная с авантюризмом, которые подсказали «chef перспективнее, моложе и интереснее для изучения»
Системы управления конфигурациями служат для того чтобы выполнить начальную(и повседневную) настройку сервера — установить ПО, развернуть нужные конфигурационные файлы и т.д. Особенно, когда таких(особенно однотипных) серверов больше двух.
А стоит ли использовать в малых системах — это личное дело каждого.
Мое мнение — да. Мне удобнее сначала написать рецепт, внимательно его прочитать, а потом запустить chef-client на нужных узлах и применить изменения. Плюс некоторая централизованность есть. Плюс возможность протетстировать предстоящие изменения на тестовой площадке.