My talk on Python-based CM systems from DevConf 2014

2. Давайте познакомимся!
● Меня зовут Саша
● Я работаю главным инженером
● В компании Git in Sky
● Я немного знаю разные языки
программирования
● И умею немного администрировать
сайты

3. А вас как зовут?
● Вы веб-разработчики?
● У вас уже есть опыт
использования CM систем?
● Вам приходится управлять
инфраструктурой?
● Насколько она велика?
● Кстати, что значит понятие “велика”?

4. Возможная задача №1
● МНОГО серверов
● Их нужно БЫСТРО привести
к заданному виду
● Разные роли у разных машин
● Разные роли – это разные приложения
● Гетерогенные среды:
● Linux, FreeBSD, Solaris, ...

5. Возможная задача №2
● Описана эталонная конфигурация
● Разные окружения:
● development, testing
● staging, production
● Окружения различаются
размерами и свойствами
сервисов

6. Как можно решать эти задачи?
● Древний способ – скрипты на bash и пакеты
deb/RPM
● Современный – CM-системы:
● CFEngine
● Puppet, Chef
● Salt, Ansible
● Func, Babushka, Marelle
● Ansible создал автор Func

7. Чем плох древний способ?
● Никто не любит* писать скрипты на bash
● bash: плохо писать, плохо
читать, недекларативный,
неидемпотентный
● deb/RPM-пакеты это тоже
плохо (недекларативно, не
обеспечивается повторяемость)
*Я не люблю

8. Полезные свойства CM-систем
● bash-скрипты не торчат наружу
● Вместо – декларативный DSL
● Исполняется параллельно на
всех узлах
● Объекты предметной области -
иерархия (роли, модули, группы
узлов, атрибуты)

9. Модель предметной области
● Описание конфигурации:
● Описания установленных
пакетов
● Описания разрешенных и
запущенных сервисов
● Шаблоны конфигурационных файлов и
правила их генерации
● Среды, роли, узлы, параметры всего этого

10. Типичное устройство CM-систем
● Клиент-серверная архитектура
● “Толстый клиент”
● Много зависимостей
● Часто – eDSL на Ruby
● ^ (и сама система тоже)
● Pull-модель: клиенты
обращаются к серверу

11. Что нам не нравится?
● Клиент-серверная архитектура
● Нужно развернуть и поддерживать сервер
● Сервер потребляет ресурсы
● Необходимо обеспечить
безопасность сервера
● И его отказоустойчивость

12. Что еще плохо?
● “Толстый клиент”
● Нужно делать бутстреппинг узла при его
введении в инфраструктуру
● Работает не на любой
платформе
● При работе потребляет
ресурсы

13. Что еще плохо?
● Часто – eDSL на Ruby
● Я же на Python секции?
● Вы любите Ruby?
● eDSL сделан “поверх”
основного языка – декларативность не
навязывается на уровне DSL, можно писать
bash скрипты на основном языке

14. Что еще плохо?
● Pull-модель
● Мне кажется, это потеря
смысла:
● Зачем нужен командный
центр, который не имеет
возможности оперативного
управления?

15. Как же быть?
● Больше декларативности:
YAML
● Вернуть серверу возможность
управлять клиентами
● Может, убрать сервер?
● Кстати, может и толстые
клиенты тоже убрать?

16. И, наконец, о практике
● Salt – начинался как средство параллельного
исполнения
● Клиенты постоянно подключены к серверу
через ØMQ
● Эволюционировал в CM-систему
● С документацией на
1668 страниц

17. Чем хорош Salt?
● ОЧЕНЬ быстро развивается
● Уже сейчас предоставляет
много возможностей
● Сервер и клиент относительно
легковесны (в сравнении с Chef)
● Выполнение ad hoc команд сделано идеально
(в сравнении с чем угодно на Ruby)
● Отличная (!) поддержка сообществом

18. Чем плох Salt?
● Слишком быстро развивается
● Инфраструктура, в которой
нужны ad hoc команды -
источник проблем в будущем
● Русские читают документацию только в
критической ситуации, особенно, если ее
1668 страниц

19. Не расходитесь, это не всё!
● Порог вхождения:
● Минимален, это же Python и YAML
● Выразительность:
● Простые вещи делаются просто, вещи
посложнее – сложно (вместо YAML можно
описывать конфигурацию на Python, но будет
некрасиво)
● Кроссплатформенность: Windows, FreeBSD

20. Что еще умеет Salt
● Масштабироваться: Salt Syndic (репитер)
● Управлять частным облаком: Salt Virt
● Управлять публичным облаком: Salt Cloud
● Заменить собой cron: опция “schedule”
● Показывать статус инфраструктуры и
выполнять команды через веб-интерфейс:
Halite

21. Еще один претендент
● Ansible – вторая попытка
Michael DeHaan сделать CM-систему
● На управляемых узлах нужен только
интепретатор Python, никаких клиентов*
● Коммуникация между “сервером” и клиентами
по обычному SSH
*чуть позже мы вернемся к
вопросу о том, что такое “клиент”

22. Звучит очень круто!
● Почему никто не сделал
подобное раньше?
● Потому, что в Ruby нет
нормального быстрого SSH-клиента? :)
● Кстати, как я обеспечиваю безопасность
своего Ansible-сервера?
● Я привез его с собой в своем рюкзаке, он
отключен от сети

23. Работает еще более круто!
● Если мой Ansible-сервер в зале, что же
применяет конфигурацию на клиентах?
● Как применяет конфигурацию CM-система?
● Клиент скачивает файлы с сервера
● И применяет правила из них локально
● Постойте, я знаю много разных способов
передачи файлов с сервера клиенту!
● Некоторые из них даже “high load” :)

24. Сервер не нужен
● На каждом хосте по cron
работает команда ansible-pull
● Она забирает из git-репозитория
новую версию, если она есть
● И применяет ее локально
● Проблема курицы и яйца – как ansible-pull
попадет в cron первый раз?
● При помощи моего “сервера”

25. Нужен ли сервер?
● Пришлось пожертвовать
возможностями, которые
сервер предоставлял в
классических CM-системах:
● autodiscovery, обмен параметрами*
● Autodiscovery через CM сервер? Зачем?
● Для этого есть Serf, etcd, mDNS
*можно, но теперь это peer-to-peer связь

26. Другие свойства Ansible
● Порог вхождения:
● Еще ниже, чем у Salt
● Выразительность:
● Местный диалект YAML менее многословен,
чем у Salt
● Кросплатформенность:
● Разработчики знают такие платформы, о
которых даже я не знаю (DragonFly BSD)

27. Кросплатформенность
● Я использую Ansible под SmartOS:
● SmartOS работает с флешки, и каталоги
/usr/bin и /etc там недоступны на запись
● SmartOS – это Solaris, а не Linux, там SMF, а
не sysvinit, upstart или systemd
● При рестартах некоторая часть
конфигурации теряется
● Ansible отлично справляется со всем этим

28. Что плохо (и там, и там)?
● Выразительности YAML часто
недостаточно – не все сценарии есть
● Управление серверами императивно
● Скрипты “на bash” неизбежны
● Я писал state для Salt на Python
● Он был так же плох, как и на bash

29. Что ужасно (и там, и там)?
● Можно много спорить о необходимости
unit-тестирования
● Но механизмов для него нет ни в Salt, ни в
Ansible (в отличие от Chef)
● Управление модулями, их версиями и их
зависимостями – в зачаточном состоянии (нет
аналогов pip, Bundler или librarian-chef)
● Есть Ansible Galaxy (это как PyPI, но без
версий)

30. Great artists steal
● Open Source-системы могут пользоваться
идеями друг друга не боясь патентных
преследований
● Так появились “salt-ssh” и “Ansible Fireball”
● Последний благополучно умер, вместо
ZeroMQ-транспорта рекомендуется включать
в ansible.cfg SSH pipelining
● (но ansible-pull все равно быстрее)

31. (Chef-)сервер не нужен!
● Все пользуются идеями друг друга:
● В Salt есть salt-call (masterless)
● В Chef есть chef-solo
● Masterless Puppet тоже можно настроить

32. Выводы
● Конкуренция – двигатель прогресса
● Прогресс в области CM-систем пока еще не
остановился
● Python-based CM-системы молоды и бурно
развиваются
● Мы можем им помочь!
● 62

33. Спасибо за внимание!
● Пожалуйста, ваши вопросы!
● С вами был Александр Чистяков,
● Главный инженер Git in Sky
● http://twitter.com/noatbaksap
● alex@gitinsky.com
● http://gitinsky.com,
http://meetup.com/DevOps-40