Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

My talk on Salt and Ansible from DevConf 2014

2 134 vues

Publié le

My talk on Python-based CM systems from DevConf 2014

Publié dans : Technologie
  • Soyez le premier à commenter

My talk on Salt and Ansible from DevConf 2014

  1. 1. Давайте познакомимся! ● Меня зовут Саша ● Я работаю главным инженером ● В компании Git in Sky ● Я немного знаю разные языки программирования ● И умею немного администрировать сайты
  2. 2. А вас как зовут? ● Вы веб-разработчики? ● У вас уже есть опыт использования CM систем? ● Вам приходится управлять инфраструктурой? ● Насколько она велика? ● Кстати, что значит понятие “велика”?
  3. 3. Возможная задача №1 ● МНОГО серверов ● Их нужно БЫСТРО привести к заданному виду ● Разные роли у разных машин ● Разные роли – это разные приложения ● Гетерогенные среды: ● Linux, FreeBSD, Solaris, ...
  4. 4. Возможная задача №2 ● Описана эталонная конфигурация ● Разные окружения: ● development, testing ● staging, production ● Окружения различаются размерами и свойствами сервисов
  5. 5. Как можно решать эти задачи? ● Древний способ – скрипты на bash и пакеты deb/RPM ● Современный – CM-системы: ● CFEngine ● Puppet, Chef ● Salt, Ansible ● Func, Babushka, Marelle ● Ansible создал автор Func
  6. 6. Чем плох древний способ? ● Никто не любит* писать скрипты на bash ● bash: плохо писать, плохо читать, недекларативный, неидемпотентный ● deb/RPM-пакеты это тоже плохо (недекларативно, не обеспечивается повторяемость) *Я не люблю
  7. 7. Полезные свойства CM-систем ● bash-скрипты не торчат наружу ● Вместо – декларативный DSL ● Исполняется параллельно на всех узлах ● Объекты предметной области - иерархия (роли, модули, группы узлов, атрибуты)
  8. 8. Модель предметной области ● Описание конфигурации: ● Описания установленных пакетов ● Описания разрешенных и запущенных сервисов ● Шаблоны конфигурационных файлов и правила их генерации ● Среды, роли, узлы, параметры всего этого
  9. 9. Типичное устройство CM-систем ● Клиент-серверная архитектура ● “Толстый клиент” ● Много зависимостей ● Часто – eDSL на Ruby ● ^ (и сама система тоже) ● Pull-модель: клиенты обращаются к серверу
  10. 10. Что нам не нравится? ● Клиент-серверная архитектура ● Нужно развернуть и поддерживать сервер ● Сервер потребляет ресурсы ● Необходимо обеспечить безопасность сервера ● И его отказоустойчивость
  11. 11. Что еще плохо? ● “Толстый клиент” ● Нужно делать бутстреппинг узла при его введении в инфраструктуру ● Работает не на любой платформе ● При работе потребляет ресурсы
  12. 12. Что еще плохо? ● Часто – eDSL на Ruby ● Я же на Python секции? ● Вы любите Ruby? ● eDSL сделан “поверх” основного языка – декларативность не навязывается на уровне DSL, можно писать bash скрипты на основном языке
  13. 13. Что еще плохо? ● Pull-модель ● Мне кажется, это потеря смысла: ● Зачем нужен командный центр, который не имеет возможности оперативного управления?
  14. 14. Как же быть? ● Больше декларативности: YAML ● Вернуть серверу возможность управлять клиентами ● Может, убрать сервер? ● Кстати, может и толстые клиенты тоже убрать?
  15. 15. И, наконец, о практике ● Salt – начинался как средство параллельного исполнения ● Клиенты постоянно подключены к серверу через ØMQ ● Эволюционировал в CM-систему ● С документацией на 1668 страниц
  16. 16. Чем хорош Salt? ● ОЧЕНЬ быстро развивается ● Уже сейчас предоставляет много возможностей ● Сервер и клиент относительно легковесны (в сравнении с Chef) ● Выполнение ad hoc команд сделано идеально (в сравнении с чем угодно на Ruby) ● Отличная (!) поддержка сообществом
  17. 17. Чем плох Salt? ● Слишком быстро развивается ● Инфраструктура, в которой нужны ad hoc команды - источник проблем в будущем ● Русские читают документацию только в критической ситуации, особенно, если ее 1668 страниц
  18. 18. Не расходитесь, это не всё! ● Порог вхождения: ● Минимален, это же Python и YAML ● Выразительность: ● Простые вещи делаются просто, вещи посложнее – сложно (вместо YAML можно описывать конфигурацию на Python, но будет некрасиво) ● Кроссплатформенность: Windows, FreeBSD
  19. 19. Что еще умеет Salt ● Масштабироваться: Salt Syndic (репитер) ● Управлять частным облаком: Salt Virt ● Управлять публичным облаком: Salt Cloud ● Заменить собой cron: опция “schedule” ● Показывать статус инфраструктуры и выполнять команды через веб-интерфейс: Halite
  20. 20. Еще один претендент ● Ansible – вторая попытка Michael DeHaan сделать CM-систему ● На управляемых узлах нужен только интепретатор Python, никаких клиентов* ● Коммуникация между “сервером” и клиентами по обычному SSH *чуть позже мы вернемся к вопросу о том, что такое “клиент”
  21. 21. Звучит очень круто! ● Почему никто не сделал подобное раньше? ● Потому, что в Ruby нет нормального быстрого SSH-клиента? :) ● Кстати, как я обеспечиваю безопасность своего Ansible-сервера? ● Я привез его с собой в своем рюкзаке, он отключен от сети
  22. 22. Работает еще более круто! ● Если мой Ansible-сервер в зале, что же применяет конфигурацию на клиентах? ● Как применяет конфигурацию CM-система? ● Клиент скачивает файлы с сервера ● И применяет правила из них локально ● Постойте, я знаю много разных способов передачи файлов с сервера клиенту! ● Некоторые из них даже “high load” :)
  23. 23. Сервер не нужен ● На каждом хосте по cron работает команда ansible-pull ● Она забирает из git-репозитория новую версию, если она есть ● И применяет ее локально ● Проблема курицы и яйца – как ansible-pull попадет в cron первый раз? ● При помощи моего “сервера”
  24. 24. Нужен ли сервер? ● Пришлось пожертвовать возможностями, которые сервер предоставлял в классических CM-системах: ● autodiscovery, обмен параметрами* ● Autodiscovery через CM сервер? Зачем? ● Для этого есть Serf, etcd, mDNS *можно, но теперь это peer-to-peer связь
  25. 25. Другие свойства Ansible ● Порог вхождения: ● Еще ниже, чем у Salt ● Выразительность: ● Местный диалект YAML менее многословен, чем у Salt ● Кросплатформенность: ● Разработчики знают такие платформы, о которых даже я не знаю (DragonFly BSD)
  26. 26. Кросплатформенность ● Я использую Ansible под SmartOS: ● SmartOS работает с флешки, и каталоги /usr/bin и /etc там недоступны на запись ● SmartOS – это Solaris, а не Linux, там SMF, а не sysvinit, upstart или systemd ● При рестартах некоторая часть конфигурации теряется ● Ansible отлично справляется со всем этим
  27. 27. Что плохо (и там, и там)? ● Выразительности YAML часто недостаточно – не все сценарии есть ● Управление серверами императивно ● Скрипты “на bash” неизбежны ● Я писал state для Salt на Python ● Он был так же плох, как и на bash
  28. 28. Что ужасно (и там, и там)? ● Можно много спорить о необходимости unit-тестирования ● Но механизмов для него нет ни в Salt, ни в Ansible (в отличие от Chef) ● Управление модулями, их версиями и их зависимостями – в зачаточном состоянии (нет аналогов pip, Bundler или librarian-chef) ● Есть Ansible Galaxy (это как PyPI, но без версий)
  29. 29. Great artists steal ● Open Source-системы могут пользоваться идеями друг друга не боясь патентных преследований ● Так появились “salt-ssh” и “Ansible Fireball” ● Последний благополучно умер, вместо ZeroMQ-транспорта рекомендуется включать в ansible.cfg SSH pipelining ● (но ansible-pull все равно быстрее)
  30. 30. (Chef-)сервер не нужен! ● Все пользуются идеями друг друга: ● В Salt есть salt-call (masterless) ● В Chef есть chef-solo ● Masterless Puppet тоже можно настроить
  31. 31. Выводы ● Конкуренция – двигатель прогресса ● Прогресс в области CM-систем пока еще не остановился ● Python-based CM-системы молоды и бурно развиваются ● Мы можем им помочь! ● 62
  32. 32. Спасибо за внимание! ● Пожалуйста, ваши вопросы! ● С вами был Александр Чистяков, ● Главный инженер Git in Sky ● http://twitter.com/noatbaksap ● alex@gitinsky.com ● http://gitinsky.com, http://meetup.com/DevOps-40

×