Комментарии 23
а сильно ли отличается по сложности исполнение обращений к OpenStack api из шел скрипта от использования Chef? Т.е. с точки зрения администратора при использовании шефа надо знать как работает и то и другое если я правильно понимаю, вопрос не проще ли администратору разобраться только в облачном апи и запускать свои обращения каким-нибудь дженкинсом допустим?
На самом деле, каждому свое. Chef — автоматизация процесса конфигурации. Это же не просто инструмент для запуска скриптов. Он умеет гораздо больше. Также как и основное назначение Jenkins — совсем не заменяет Chef. То, что он умеет ранить external job — это хорошо. Уместно ли в упомянутом случае это делать? Возможно Вы достигнете цели. Вопрос будет ли это оптимизированная автоматизация?
Такой ад шеф, для не извращенцев советую Ansible.
Подскажите, чем он лучше? Я смотрю многие вот рекомендуют. Я, например, опасаюсь того, что мне будет не найти под него какой-нибудь готовый рецепт установщика например Oracle XE, или jdk ораклового, или там даже redis'а, который не проприетарен, как те что я выше перечислил. Плюс меня смущает, что там еще один язык, yaml.
Ansible и Salt имеет смысл использовать когда сходятся два условия
— лютая, бешеная любовь к python и одновременная ненависть к ruby
— задача простая и относительно линейная
Оба весьма декларативны и фактически в форме ML описывают конечное состояние системы. Вопросы начинаются когда конечное состояние зависит от внешних факторов или других систем
— лютая, бешеная любовь к python и одновременная ненависть к ruby
— задача простая и относительно линейная
Оба весьма декларативны и фактически в форме ML описывают конечное состояние системы. Вопросы начинаются когда конечное состояние зависит от внешних факторов или других систем
НЛО прилетело и опубликовало эту надпись здесь
Возможно я что то не так понимаю, но, зачем ansible нужен chefspec и тот же testkitchen если play-файл ansible и есть тот тест который вы пишите для chef.
Вот пример задач описаные используя yaml для ansible:
— name: Ensure APT cache is up to date
apt: update_cache=yes cache_valid_time=3600
— name: Ensure sudo group rights are absent
lineinfile: dest=/etc/sudoers regexp="^%sudo" state=absent
— name: Ensure deploy user exists
user: name=deploy shell=/bin/bash
Они и есть тесты, а запуск ansible удовлетворяет их. Конечно тут уже все упирается в корректности модулей.
Вот пример задач описаные используя yaml для ansible:
— name: Ensure APT cache is up to date
apt: update_cache=yes cache_valid_time=3600
— name: Ensure sudo group rights are absent
lineinfile: dest=/etc/sudoers regexp="^%sudo" state=absent
— name: Ensure deploy user exists
user: name=deploy shell=/bin/bash
Они и есть тесты, а запуск ansible удовлетворяет их. Конечно тут уже все упирается в корректности модулей.
НЛО прилетело и опубликовало эту надпись здесь
Ну в целом вы правы, и на сколько я пока понял в ansible действительно легче писать отдельные роли под разные ос. Но опять же зависит от задачи, ansible во многом полагается на плагины которые по их мнению и должны решать эти задачи. Вот например модуль service, hostname у каждого есть разные стратегий в зависимости от OS.
Я не пробую сказать что ansible лучше или гибче всех, а то что на нем быстрее и легче можно настроить разумное количество серверов, и можно освоить за ночь.
Я не пробую сказать что ansible лучше или гибче всех, а то что на нем быстрее и легче можно настроить разумное количество серверов, и можно освоить за ночь.
НЛО прилетело и опубликовало эту надпись здесь
Большое спасибо, жду с нетерпением продолжения.
Ответите на извечный вопрос — почему chief, а не puppet?..
Ответите на извечный вопрос — почему chief, а не puppet?..
И не salt?
А это дело личное. Например, язык манифестов/рецептов. Мне удобно было использовать Ruby. Хорошее комьюнити Chef — предостаточно готовых кукбуков, вокруг которых можно писать свои wrapper-ы. Да и просто сравнил свой небольшой опыт использования Puppet vs Chef. Chef оказался более удобным. Вышла совокупность впечатлений.
Просто на слуху (во всяком случае у меня в окружении) Chef vs puppet. Вот выше порекомендовали интересный Ansible…
У них есть очень критическая разница в подходе к идемпотентности.
Когда обе системы применяют конфигурацию к серверу то шеф выполняет каждый шаг конфигурации последовательно, а паппет от балды или все сразу.
Вся ругань возникает из за порядка выполнения действий на сервере. Для шефа достаточно написать их в желаемом порядке а для паппета приходится городоить зависимости.
С точки зрения теории паппет прав, с точки зрения жизненного опыта шеф сильно удобнее.
Когда обе системы применяют конфигурацию к серверу то шеф выполняет каждый шаг конфигурации последовательно, а паппет от балды или все сразу.
Вся ругань возникает из за порядка выполнения действий на сервере. Для шефа достаточно написать их в желаемом порядке а для паппета приходится городоить зависимости.
С точки зрения теории паппет прав, с точки зрения жизненного опыта шеф сильно удобнее.
Ух ты. Шеф за 21 день! А путешествия во времени будут?
Теперь серьезно. Холивары на тему как готовить Шеф сейчас очень горячая тема — вот например. Грубо говоря ответа на вопрос «как правильно готовить Шеф» нету пока даже в Opscode, но к их чести, надо сказать, что они приложили большие усилия за последний год что бы собрать обобщить опыт своих клиентов и составть какой то Best Practice.
Я про все это говорю ибо перечитал и поучаствовал в куче подобных холиваров по долгу службы и мне кажется одна вещь обязательная для таких топиков здесь упущена — а именно опыт и инфраструктура автора. Это не из вредности, но советы людей могут быть очень противоречивыми из-за разницы окружений в которых они работают. Хорошо про это сказал Phil Dibowitz в самом начале своего выступления.
Теперь серьезно. Холивары на тему как готовить Шеф сейчас очень горячая тема — вот например. Грубо говоря ответа на вопрос «как правильно готовить Шеф» нету пока даже в Opscode, но к их чести, надо сказать, что они приложили большие усилия за последний год что бы собрать обобщить опыт своих клиентов и составть какой то Best Practice.
Я про все это говорю ибо перечитал и поучаствовал в куче подобных холиваров по долгу службы и мне кажется одна вещь обязательная для таких топиков здесь упущена — а именно опыт и инфраструктура автора. Это не из вредности, но советы людей могут быть очень противоречивыми из-за разницы окружений в которых они работают. Хорошо про это сказал Phil Dibowitz в самом начале своего выступления.
С Шефом все может быть :)
А если серьезно — полностью согласен по поводу инфраструктуры.
Сделано это намеренно — дабы статьи не приобретали узконаправленный характер по компании, в которой все сделано на UNIX или Windows или Linux.
Поэтому я трезво отношусь к спорам, мне, как начинающему, очень интересно услышать другие идеи, но комментарии — чем «хуже/лучше» не несут идей, это просто спор.
В дальнейших частях будет изложен глобальный подход. Отдельным рядом пойдут статьи про решение кастомных задач, с которыми приходится встречаться.
А если серьезно — полностью согласен по поводу инфраструктуры.
Сделано это намеренно — дабы статьи не приобретали узконаправленный характер по компании, в которой все сделано на UNIX или Windows или Linux.
Поэтому я трезво отношусь к спорам, мне, как начинающему, очень интересно услышать другие идеи, но комментарии — чем «хуже/лучше» не несут идей, это просто спор.
В дальнейших частях будет изложен глобальный подход. Отдельным рядом пойдут статьи про решение кастомных задач, с которыми приходится встречаться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Chef за 21 день. Часть первая. Введение