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