Salt and Ansible - Python-based CM systems

Salt и Ansible — средства управления конфигурацией

на языке Python

Как перестать изучать Ruby и начать жить

Александр Чистяков, главный инженер Git in Sky,

2014

Кто я?

§ Меня зовут Саша§ Я главный инженер в компании Git in Sky§ Днем — разработчик ПО§ Ночью — инженер отдела эксплуатации§ Или наоборот

Salt и Ansible — средства управления конфигурацией на языке Python. 2014

Кто вы?

§ Разрабатываете на Python?§ Делаете веб-приложения?§ Может быть, Big Data приложения?§ А сервера у вас есть?§ Много? (Кстати, “много” - это от скольки?)§ Приходится заниматься их настройкой?


Задача #1

§ Есть много серверов§ Их нужно быстро привести к эталонному виду§ Разные серверы — разные роли§ Разные роли — разные приложения§ Возможно, разные платформы:

§ Linux, FreeBSD, Solaris, ...


Задача #2


§ Есть эталонная конфигурация§ Нужно воссоздавать ее в разных окружениях:

§ development§ testing§ staging§ production

§ Окружения отличаются размерами и свойствами сервисов

Какие есть пути решения этих двух задач?

§ Классический — скрипты на bash и пакеты deb/RPM§ Современный — системы управления конфигурацией:

§ CFEngine§ Puppet, Chef§ Salt, Ansible§ Func, Babushka, etc§ ^ Ansible создал автор Func


Словарик

§ «Классический»:§ Старый, неудобный, унаследованный,

недостаточно проработанный§ «Современный»:

§ Новый, удобный,сделанный с учетом ошибокпрошлых лет


Чем плох классический путь?

§ Я знаю одного (1) человека, которому

нравится писать скрипты на bash§ И, по-моему, он гонит§ bash: плохо писать, плохо читать,

недекларативный, неидемпотентный§ Чем плохи deb/RPM пакеты — тема для

отдельного доклада (если вкратце - всем)


Полезные свойства современных систем

§ bash-скрипты изолированы глубоко внутри,

вместо них — DSL для декларативного описания§ Конфигурация применяется параллельно

на всех узлах§ Объекты предметной области составляют

иерархию (роли, модули, группы узлов, атрибуты)


Классическое устройство современных систем

§ Клиент-серверная архитектура§ “Толстый” клиент, много зависимостей§ Часто — eDSL на базе Ruby§ ^ Сама CM система тоже на Ruby§ Pull-модель: клиенты обращаются к серверу


Что нам не нравится?

§ Клиент-серверная архитектура§ Необходимо разворачивать и

поддерживать сервер§ ^ это может быть ресурсозатратно§ Необходимо обеспечивать

безопасность сервера



§ “Толстый” клиент, много зависимостей§ Нужно делать бутстреппинг узла при его

введении в инфраструктуру§ Работает не на любой платформе§ При работе потребляет ресурсы



§ Часто — eDSL на базе Ruby§ Напомните, как называется эта конференция?§ embedded DSL (eDSL) сделан “поверх”

основного языка — декларативность не

навязывается на уровне DSL, можно писать

как угодно плохо



§ Pull-модель: клиенты обращаются к серверу§ Потеря смысла:

§ Зачем нужен командный центр,который требует защиты,но не имеет возможностиоперативного управления?


Как же быть?

§ Использовать Python :)§ Описывать конфигурацию на YAML§ Вернуть серверу возможность

управлять клиентами§ Либо вообще убрать сервер§ Кстати, и клиенты тоже убрать


От теории к практике

§ Salt — начинался как parallel execution tool§ Клиенты поддерживают постоянное соединение

с сервером через ØMQ§ Сейчас это полноценная CM система§ С документацией на 1119 страниц


Чем хорош Salt?

§ Очень быстро развивается§ Предоставляет много возможностей§ Сервер и клиент относительно легковесны§ Выполнение ad hoc команд сделано идеально§ Отличная поддержка сообществом


Чем плох Salt?

§ Слишком быстро развивается§ Приоритет возможностей ради

возможностей часто ведет к потере качества§ Инфраструктура, в которой нужны ad hoc

команды, — источник проблем в будущем§ 1119 страниц невозможно прочесть :(


Что еще можно сказать про Salt?

§ Порог вхождения:§ Спасибо тов. ван Россуму, он минимален

§ Выразительность:§ Авторы пытались построить второй Chef,

к счастью, не получилось§ Кросплатформенность:

§ Пробовал под FreeBSD, получилось


Должно быть что-то еще!

§ Ansible — вторая попытка Michael DeHaan

сделать CM систему§ Никаких зависимостей на узлах, кроме

интерпретатора Python§ Коммуникация между сервером и клиентами

по обычному SSH


Идея довольно современна

§ Решение лежало на поверхности, почему же

им не пользовались раньше?§ Не в любом языке есть библиотека,

реализующая нормальный SSH-клиент§ Кстати, сервера теперь тоже никакого нет,

его можно свернуть и унести с собой


Другие важные следствия

§ Если сервер все равно неизвестно где,

можно, он будет на той же машине?§ В классических системах CM сервер (не) просто

раздает шаблоны конфигурации клиентам§ Я знаю несколько десятков вариантов передачи

файлов, среди них есть удобные


Что мы теряем?

§ В классических CM системах узлы общаются

между собой через сервер:§ Делают autodiscovery, обмениваются

параметрами§ Autodiscovery через CM сервер? Зачем?

§ Есть Serf, etcd, mDNS


Что еще можно сказать про Ansible?

§ Порог вхождения:§ Его нет, я его не заметил

§ Выразительность:§ Местный YAML менее многословен,

чем в Salt§ Кросплатформенность:

§ SmartOS, DragonFly BSD


Что плохо и там, и там?

§ Декларативный YAML слишком декларативен§ Управление серверами — императивный процесс,

исторически§ Приходится прибегать к помощи скриптов на Python§ ^ хорошо, если только на Python, а то ведь и на bash§ У меня есть Salt'овский стейт на Python, но я не готов его

показать


Что ужасно и там, и там?

§ В оглавлении документации Salt по слову “Unit” не находится “Unit testing”§ Поиском по всей документации находится пара абзацев§ Понять, о чем они — невозможно

§ Про Ansible не находится ничего релевантного§ Управление модулями, их версиями и их зависимостями —

аналогов pip или Bundler пока не существует§ Для Ansible есть Ansible Galaxy — это PyPI, но без версий


Останется только один

§ CM системы не могут друг друга убить,

но отлично могут брать друг у друга идеи§ Так появились “Salt SSH” и “Ansible Fireball”§ Последний, к счастью, не выжил§ Лишь бы только не вышло, как с JIRA


Кстати, что касается отказа от сервера

§ В Salt есть salt-call, позволяющий работать

без мастера§ В Chef есть chef-solo, позволяющий работать

без мастера§ Masterless Puppet тоже бывает§ Я же говорил — они друг у друга тырят!


Выводы:

§ На вкус и цвет все CM системы разные§ Последнее слово на этом рынке еще

не прозвучало§ Python пока выступает очень достойно§ Но ему необходима помощь§ Помогите Python съесть Ruby!


С вами был Александр Чистяков,главный инженер Git in Sky

[email protected]://gitinsky.com

http://meetup.com/DevOps-40

Пожалуйста, ваши вопросы.

Спасибо за внимание!

mailto:[email protected]

mailto:[email protected]

http://gitinsky.com/



http://meetup.com/DevOps-40

Salt and Ansible - Python-based CM systems

Technology