Comments 17
UFO just landed and posted this here
У меня была идея создания подобного ПО.
Приятно думать, что теперь не придется делать свой велосипед )
Приятно думать, что теперь не придется делать свой велосипед )
Есть ~20 машин под Debian Squeeze. Сейчас все настройки управляются Puppet. Это меня устраивает. Но Puppet не решает задачу синхронного обновления всех машин. То есть, хотелось бы в 1 шаг узнать, как отличается набор ПО на всех машинах и в 1 шаг обновить / доустановить нужное / удалить лишнее. Есть такой инструмент?
Очень легко, можно создать рецепт, который смотрит список всех узлов, смотрит список установленных рецептов на них, и недостающие на данной машине рецепты добавляет к ней, и затем инициирует второй проход конвергенции.
Если же нужно согласовывать не набор рецептов, а набор пакетов, то и это несложно, хотя это и неправильный путь. Лучше всегда работать рецептами и ролями.
Например, в случае Debian можно поступить так:
Создать рецепт, который добавляет атрибут installed-packages к узлу путём выполнения dpkg -l. Возможно. такой рецепт уже есть.
И затем создать рецепт, который доставляет пакеты исходя из общего списка пакетов для всех узлов.
Например, в случае Debian можно поступить так:
Создать рецепт, который добавляет атрибут installed-packages к узлу путём выполнения dpkg -l. Возможно. такой рецепт уже есть.
И затем создать рецепт, который доставляет пакеты исходя из общего списка пакетов для всех узлов.
> Chef использует DSL, основанный на Ruby
Puppet тоже, как ни странно :-)
Поэтому про самописный DSL в Puppet лучше уберите.
Puppet тоже, как ни странно :-)
Поэтому про самописный DSL в Puppet лучше уберите.
Что насчет Viper-a в єтой категории? Сам пакет -солянка из дургих. (dhcp-server-ldap+netinstall+preseed+openldap+puppet) Все настройки в лдап-е.
Кто то сием чудом пользовался?
Кто то сием чудом пользовался?
интересно! нашел инструкцию. www.debian-administration.org/article/Automatic_host_installation_using_Viper
буду пробовать
буду пробовать
Меня смущает его узкопрофильность: парк должен быть строго Debian.
А по жизни обычно великое разнообразие :)
А по жизни обычно великое разнообразие :)
Вы не правы, не только дебиан. Все будет зависить от правильно исползования preseed конфигурации (kickstart или другой аналогии что кормиться для автоинстала) и дальнейшего использования папета (а он не дебиан ориентрированный).
Хотя с другой стороны для того же редхата есть утилита spacewalk , и держать разнообразный зоопарк — как по мне — тоже не правильно.
В данный момент в вайпере проблемка с лдапом… ну кикак у меня не выходит пока что полностью его подружить с новой архитектурой slapd.conf.
Вайпер не болие чем солянка пекетов, автосконфигурированная под debian-like системы. А что вы будете ставить на скелет ldap-а — зависит от вас.
Хотя с другой стороны для того же редхата есть утилита spacewalk , и держать разнообразный зоопарк — как по мне — тоже не правильно.
В данный момент в вайпере проблемка с лдапом… ну кикак у меня не выходит пока что полностью его подружить с новой архитектурой slapd.conf.
Вайпер не болие чем солянка пекетов, автосконфигурированная под debian-like системы. А что вы будете ставить на скелет ldap-а — зависит от вас.
Chef — моя основная тулза как у Deployment Engineer, но, несмотря на то, что люблю его нежно не могу не упомянуть об объективных недостатках.
1) Готовые cookbooks бывают странного качества. Очень многие ориентированы на Debian, и под RH-like их вообще не проверяли. То есть править приходится много
2) Сам чеф молод, и ошибки часто встречаются. Например он очень любит класть собственный CouchDB
3) Некоторые вещи реализованы странно — например проверка классов до выполнения рецепта. Создает проблемы, если хочется DSL расширить.
4) Документация хороша, но очень поверхностна. Очень часто приходится смотреть в исходники.
5) И наверное главное — нет альтернативы web-интерфейсу для менеджмента. Да, я в курсе про knife, но это сторонний сервис и в будущем, видимо, платный
Особое отличие от Puppet — это как раз поиск, его в кукле нет и реализовать очень сложно. Вообще opscode изначально занимались именно консультациями по puppet, но, устав с ним бороться, написали свой «велосипед».
Кстати, вас не интересует создание русскоязычного ресурса про Chef?
1) Готовые cookbooks бывают странного качества. Очень многие ориентированы на Debian, и под RH-like их вообще не проверяли. То есть править приходится много
2) Сам чеф молод, и ошибки часто встречаются. Например он очень любит класть собственный CouchDB
3) Некоторые вещи реализованы странно — например проверка классов до выполнения рецепта. Создает проблемы, если хочется DSL расширить.
4) Документация хороша, но очень поверхностна. Очень часто приходится смотреть в исходники.
5) И наверное главное — нет альтернативы web-интерфейсу для менеджмента. Да, я в курсе про knife, но это сторонний сервис и в будущем, видимо, платный
Особое отличие от Puppet — это как раз поиск, его в кукле нет и реализовать очень сложно. Вообще opscode изначально занимались именно консультациями по puppet, но, устав с ним бороться, написали свой «велосипед».
Кстати, вас не интересует создание русскоязычного ресурса про Chef?
1) согласен, иногда приходится переделывать рецепты.
2) Пока не встречался с падениями базы, а вот индекс рушится часто (ferret). Делаю sudo rm /srv/chef/search_index/* в таком случае. Поправят в 0.8, переходом на другой поисковый движок.
3) Никаких проблем не было в связи с этим. Если помнить порядок загрузки и компиляции, то, как мне думается, можно очень легко и красиво расширить язык, используя файлы определений.
4) Плюс один. Недокументированы такие гадости, как, например, отсутствие нотификаций при выполнении блока кода.
5) JSON-интерфейс есть, просто никому пока не пришло в голову написать свою админку. Надо посмотреть, какой они её сделают в Chef 0.8.
Пока не уверен, что нужен такой ресурс. Я использую Chef пока немного поверхностно. Тупо решаю свои задачи, не более того.
2) Пока не встречался с падениями базы, а вот индекс рушится часто (ferret). Делаю sudo rm /srv/chef/search_index/* в таком случае. Поправят в 0.8, переходом на другой поисковый движок.
3) Никаких проблем не было в связи с этим. Если помнить порядок загрузки и компиляции, то, как мне думается, можно очень легко и красиво расширить язык, используя файлы определений.
4) Плюс один. Недокументированы такие гадости, как, например, отсутствие нотификаций при выполнении блока кода.
5) JSON-интерфейс есть, просто никому пока не пришло в голову написать свою админку. Надо посмотреть, какой они её сделают в Chef 0.8.
Пока не уверен, что нужен такой ресурс. Я использую Chef пока немного поверхностно. Тупо решаю свои задачи, не более того.
3) Там помимо определений есть еще и libraries. И вот с ними возникают проблемы, например:
в foo/libraries/foo.rb
require «bar»
class Chef
class Resource
class Foo < Chef::Resource
…
end
end
Так вот если этого bar не будет, то естественно, работать не будет. Но не будет работать также, если в рецепте перед вызовом Foo сказать gem_package «bar». То есть Chef просто при загрузке классов упадет :(
5) Ну как раз knife это в ту сторону, просто реализовано через сервис самого opscode
в foo/libraries/foo.rb
require «bar»
class Chef
class Resource
class Foo < Chef::Resource
…
end
end
Так вот если этого bar не будет, то естественно, работать не будет. Но не будет работать также, если в рецепте перед вызовом Foo сказать gem_package «bar». То есть Chef просто при загрузке классов упадет :(
5) Ну как раз knife это в ту сторону, просто реализовано через сервис самого opscode
Sign up to leave a comment.
Первый опыт в качестве шеф-повара, или управление конфигурацией