Давайте познакомимся!

● Меня зовут Саша● Я работаю главным инженером● В компании 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● alex@gitinsky.com● http://gitinsky.com,http://meetup.com/DevOps-40