Открыть список
Как стать автором
Обновить

Комментарии 23

а сильно ли отличается по сложности исполнение обращений к OpenStack api из шел скрипта от использования Chef? Т.е. с точки зрения администратора при использовании шефа надо знать как работает и то и другое если я правильно понимаю, вопрос не проще ли администратору разобраться только в облачном апи и запускать свои обращения каким-нибудь дженкинсом допустим?
На самом деле, каждому свое. Chef — автоматизация процесса конфигурации. Это же не просто инструмент для запуска скриптов. Он умеет гораздо больше. Также как и основное назначение Jenkins — совсем не заменяет Chef. То, что он умеет ранить external job — это хорошо. Уместно ли в упомянутом случае это делать? Возможно Вы достигнете цели. Вопрос будет ли это оптимизированная автоматизация?
Разрешите уточнить, «ранить» — это запускать или что-то другое?
Так точно. Запускать. Привычный сленг пробивается, прошу прощения :)
Такой ад шеф, для не извращенцев советую Ansible.
Подскажите, чем он лучше? Я смотрю многие вот рекомендуют. Я, например, опасаюсь того, что мне будет не найти под него какой-нибудь готовый рецепт установщика например Oracle XE, или jdk ораклового, или там даже redis'а, который не проприетарен, как те что я выше перечислил. Плюс меня смущает, что там еще один язык, yaml.
Yaml не язык, а разметка. К тому же, даже в шефе зачастую бывает выгоднее написать свой рецепт установки, что равносильно play-list у энсибла,.
Ansible и Salt имеет смысл использовать когда сходятся два условия
— лютая, бешеная любовь к python и одновременная ненависть к ruby
— задача простая и относительно линейная

Оба весьма декларативны и фактически в форме ML описывают конечное состояние системы. Вопросы начинаются когда конечное состояние зависит от внешних факторов или других систем
Ну как раз в ansible можно достаточно безболезненно сделать зависимость состояния системы от процесса выполнения скрипта. Например нам надо загрузить на бекенды новую дату на балансерах поправить статику и только после этого рестартнуть бекенды. Как это сделать в шефе?
Но, с другой стороны, в ansible пока нет ничего аналогичного chefspec или testkitchen — те инструменты, которые появились в шефе спустя кучу времени. И как то тестировать ansible, кроме как тестируя дату в вагранте шелскриптами — сложно и зачастую неоправдано.
Возможно я что то не так понимаю, но, зачем 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 удовлетворяет их. Конечно тут уже все упирается в корректности модулей.
Если задачи такого уровня — все ок и для шефа. Но там где есть удобоваримые проверки типа «слушает ли сервер такой-то порт», «что отдает сервер на такой-то запрос», «создались ли такие-то файлы после выполнения такого-то скрипта» в энсибле надо использовать сторонние тулы или как-то извращаться с башскриптами и втроенным регистрированием — есть такая возможность register.
А что делать если у нас несколько ОС? Делать отдельные роли под каждую ос? Или проверять в плейбуках? И те задачи, которые в шефе решаются просто, в темплейтах энсибла могут выглядеть вот так:

{% if ansible_distribution_version|truncate(1, True, "")|int== 6%}
  {% set release = "squeeze"%}
{% elif ansible_distribution_version|truncate(1, True, "")|int== 7%}
  {% set release = "wheezy"%}
{% endif %}

То есть чем сложнее задача, тем замороченнее становится конфигурить энсибл. И на каком-то этапе шеф становится намного проще и логичнее того, что вы нагородите в энсибле. Но, повторюсь, это только для более-мение сложных задач.
Вы не думайте, я вроде очень неплохо знаком с энсиблом и у него достаточно слабых сторон. Если не нужен сверхгибкий инструмент он подходит и подходит просто замечательно. Может через пару лет он догонит и перегонит шеф. Но пока они занимают разные ниши.
Ну в целом вы правы, и на сколько я пока понял в ansible действительно легче писать отдельные роли под разные ос. Но опять же зависит от задачи, ansible во многом полагается на плагины которые по их мнению и должны решать эти задачи. Вот например модуль service, hostname у каждого есть разные стратегий в зависимости от OS.

Я не пробую сказать что ansible лучше или гибче всех, а то что на нем быстрее и легче можно настроить разумное количество серверов, и можно освоить за ночь.
>>на нем быстрее и легче можно настроить разумное количество серверов, и можно освоить за ночь.

Так и есть.

>>ansible во многом полагается на плагины которые по их мнению и должны решать эти задачи.

Поэтому ждем аналога установщика для разных ОС. Но даже когда он будет, делать зависимости шаблонов от ОС надо будет руками.

Каждой задаче свой инструмент. И, если вы не помните, это вы говорили что шеф для извращенцев.
А как с ansible общаться по api и не платить 10 000 баксов в год за мизерные 100 серверов?
Большое спасибо, жду с нетерпением продолжения.
Ответите на извечный вопрос — почему chief, а не puppet?..
И не salt?
А это дело личное. Например, язык манифестов/рецептов. Мне удобно было использовать Ruby. Хорошее комьюнити Chef — предостаточно готовых кукбуков, вокруг которых можно писать свои wrapper-ы. Да и просто сравнил свой небольшой опыт использования Puppet vs Chef. Chef оказался более удобным. Вышла совокупность впечатлений.
Просто на слуху (во всяком случае у меня в окружении) Chef vs puppet. Вот выше порекомендовали интересный Ansible…
Никогда не понимал таких холиварных сравнений. Умеешь делать автоматизацию на Puppet — делай. Умеешь на Chef — делай. Удобно? Ну и ок. Не умеет Puppet что-то — переползай на Chef или выдумывай костыль. Все предельно просто — кому нужны сравнения. Это же не спорт, это IT технологии.
У них есть очень критическая разница в подходе к идемпотентности.
Когда обе системы применяют конфигурацию к серверу то шеф выполняет каждый шаг конфигурации последовательно, а паппет от балды или все сразу.
Вся ругань возникает из за порядка выполнения действий на сервере. Для шефа достаточно написать их в желаемом порядке а для паппета приходится городоить зависимости.

С точки зрения теории паппет прав, с точки зрения жизненного опыта шеф сильно удобнее.
Честно, я начинал знакомится с Puppet и на этом все закончилось — я не смог упорядочить директивы. Потом я только понял, что там есть зависимости — но было поздно, были написаны первые рецепты Чефа.
Ух ты. Шеф за 21 день! А путешествия во времени будут?

Теперь серьезно. Холивары на тему как готовить Шеф сейчас очень горячая тема — вот например. Грубо говоря ответа на вопрос «как правильно готовить Шеф» нету пока даже в Opscode, но к их чести, надо сказать, что они приложили большие усилия за последний год что бы собрать обобщить опыт своих клиентов и составть какой то Best Practice.

Я про все это говорю ибо перечитал и поучаствовал в куче подобных холиваров по долгу службы и мне кажется одна вещь обязательная для таких топиков здесь упущена — а именно опыт и инфраструктура автора. Это не из вредности, но советы людей могут быть очень противоречивыми из-за разницы окружений в которых они работают. Хорошо про это сказал Phil Dibowitz в самом начале своего выступления.
С Шефом все может быть :)
А если серьезно — полностью согласен по поводу инфраструктуры.
Сделано это намеренно — дабы статьи не приобретали узконаправленный характер по компании, в которой все сделано на UNIX или Windows или Linux.
Поэтому я трезво отношусь к спорам, мне, как начинающему, очень интересно услышать другие идеи, но комментарии — чем «хуже/лучше» не несут идей, это просто спор.
В дальнейших частях будет изложен глобальный подход. Отдельным рядом пойдут статьи про решение кастомных задач, с которыми приходится встречаться.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
1993
Местоположение
США
Сайт
www.epam.com
Численность
свыше 10 000 человек
Дата регистрации
Представитель
vesyolkinaolga

Блог на Хабре