Chef @DevWeb

Управление окружениями в
сложном проекте
Chef и другие
Александр Чистяков, admin@cezurity.com
DevOps
Cezurity
http://vk.com/av

13.10.2012 www.cezurity.com 1

Давайте знакомиться и дружить

Я:
• Дезертировавший кодер на Java
• Дезертировавший кодер на PHP
• Дезертировавший кодер на C++
• Дезертировавший кодер на Perl
• Немного знаю PowerPoint и Win 7


Пожалуйста, не расходитесь!

Вы:
• Разрабатываете веб-приложения?
• Разрабатываете (компонуете)
архитектуру веб-приложений?
• Поддерживаете production систему?
• Можете назвать первого мэра Санкт-
Петербурга?


Чем занимается компания Cezurity?

• Мы разрабатываем свою
антивирусную систему
• Работающую через web («облачную»)
• Но в чем killer features?
– Бесплатно, без SMS
– Статистический анализ (все слышали
про байезианские фильтры спама?)


Чем занимаюсь в компании я?

• Поддерживаю production
инфраструктуру
• Управляю конфигурацией production
и development окружений
• Поддерживаю код некоторых
подсистем
• Компоную всю вспомогательную
инфраструктуру


Быстрое введение в предметную область


Помедленнее, я записываю!

• Есть сервисы, которые написаны не
нами
• Есть сервисы, которые написаны не
нами, но нами модифицированы
(исправлены, либо дополнены)
• Есть сервисы, которые написаны нами
• Есть правила компоновки и настройки
этих сервисов
• Есть production и development
окружения и ветки кода


Какие задачи нужно решить?

• Унификация описаний конфигурации
(желательно все хранить в одном месте)
• Унификация окружений (development
окружение – добрый брат-близнец
production, а не злой)
• Приведение всех видов сервисов к единому
представлению (captain Package Manager to
the rescue!)
• Необходим общий механизм управления,
анализа состояния системы и контроля
• Кроме того, все должно быть четко


Какими принципами руководствуемся?

• Всё уже придумано до нас!
• К сожалению, не все придумано для нас
– готовимся засучить рукава
• Алгоритм принятия решений:
– Тестируем
– Измеряем
– Анализируем
– Повторяем или Выходим
• Сосед Вася лжет (кстати, все лгут)


Поехали!

• Унификация описаний конфигурации
(желательно все хранить в одном месте)
– Репозиторий у нас уже есть (Subversion), там и
будем хранить
• Возникают новые вопросы:
– Как в репозитории скомпоновать
конфигурационные файлы (Вместе с
приложением? Или все конфиги в одном
общем месте?)
– Как хранить конфиги разных окружений
(Делать брэнчи в Subversion или хранить все в
разных каталогах одной ветки?)


Вопросов пока все больше...

• Унификация окружений (development
окружение – добрый брат-близнец
production, а не злой)
– Количество ручной работы при
развертывании нового окружения должно
быть минимально, иначе окружения
рассинхронизируются
– Идеально, когда конфигурация сервисов
генерируется автоматически по
декларативно описанным параметрам
нового окружения


Но мы будем их записывать...

• Приведение всех видов сервисов к
единому представлению (captain
Package Manager to the rescue!)
– Кажется, эту типовую задачу решали
множество раз?
– http://docs.fedoraproject.org/en-
US/Fedora_Draft_Documentation/0.1/html/R
PM_Guide/index.html
– http://www.debian.org/doc/manuals/maint-
guide/


Степень фрустрации пока что возрастает

• Я сисадмин! Я не хочу ничего читать!
Я хочу пакеты!


Количество логотипов будет расти...

• Необходим общий механизм управления,
анализа состояния системы и контроля
– Нужно централизовать сбор логов
– Нужно мониторить основные параметры
системы и генерировать предупреждения
– Нужно собирать статистику и рисовать графики
– Нужно разворачивать новые версии окружения
согласно установленной процедуре
– Которую сначала необходимо установить
• Кроме того, все должно быть четко!


Чем пользуются другие коллеги?

• Управление конфигурацией, на выбор:
– Chef
– Puppet
– CFEngine
• Решаемые задачи:
– Централизованное хранение описаний
конфигураций
– Генерация конфигов по шаблонам и
параметрам
– Автоматическое развертывание окружений
согласно заданному алгоритму


Необходимо сделать выбор

• Puppet vs. Chef:
– Оба написаны на Ruby
– Я уже имел некоторый опыт с Puppet
– И мне показалось, что learning curve у него
не такая короткая (а кроме меня системой
управления конфигурацией будут
пользоваться и другие)
– Макс Трескин считает, что про Puppet я все
вру, и он прост, но
– Макс пишет на Эрланге и носит с собой
штопор


Необходимо сделать выбор

• Chef vs. CFEngine:
– Chef требует Solr, CouchDB, RabbitMQ (логотипы
логотипы логотипы!)
– Все это хозяйство существенно расходует
ресурсы
– CFEngine может работать на телефоне LG с
Android
– CFEngine’s learning curve?


Словарик

• «Chef», а не «Chief» not not

• knife – команднострочный клиент для
управления
• recipe – алгоритм применения правил
конфигурации
• cookbook – набор связанных между собой
«рецептов», шаблонов и других
определений
• role – группа «рецептов» и других ролей


Словарик

• run list – набор «рецептов» и ролей для
применения
• attribute – переменная, свойство ноды
• node – абстракция хоста, ей ставятся в
соответствие атрибуты и run list
• environment – декларативно
объявленные
атрибуты, предописывающие
окружение


Как это работает?

• Клиент, сервер (клиент это тоже daemon)
• Клиент через определенные промежутки
времени забирает с сервера
конфигурацию, составляет и применяет run
list
• Это pull-модель, а не push (это может быть
важно!)
• Все упомянутые выше CM системы работают
по pull-модели
• Клиент коллекционирует атрибуты
узла, такие как версия и дистрибутив ОС при
помощи утилиты ohai


Как конфигурация попадает на сервер?

• Помните, я начал словарик с утилиты knife?
• knife – средство опроса состояния
конфигурации на сервере и внесения
изменений в конфигурацию
• Конфигурация на сервере может не
соответствовать тому, что лежит в
репозитории – не забывайте использовать
knife!
• К chef-server’у также прилагается web-
интерфейс, который я всегда зачем-то
настраиваю и никогда не использую


Словарик strikes back

• Ведь есть еще chef-solo, data bags, providers,
LWRPs…
• О которых я не упомянул
• Так, что я там говорил про learning curve?
• Кстати, где брать cookbooks?
• Chef очень хорошо приспособлен для
работы с github (там имеется
централизованный репозиторий основных
cookbooks) <- счастье состоит как раз из
таких вот мелочей


Настало время ответов на вопросы

• 42
• Репозиторий для Chef у нас находится в
выделенном месте, конфиги лежат в нем же
(это просто шаблоны в терминологии Chef)
• Мы используем несколько веток в Subversion
для хранения разных окружений, что
позволяет нам также иметь разный
эталонный набор cookbooks
• Вопрос унификации окружений почти решен


Почти, потому что есть еще пакеты...

• Мы используем Debian
– Работает (в отличие от RH) checkinstall, но в
интерактивном режиме он довольно говорлив
– Отличная утилита FPM, написанная на Ruby
человеком, который хорошо понимал слайд 13
– https://github.com/jordansissel/fpm
• Собственная build-система на Python
• Сильно заточенная под наши нужды, но
наши пакеты она прекрасно собирает
• Пакеты мало собрать, нужно еще сложить в
репозитории


...и репозитории

• Утилита reprepro
• Всем хороша, но хранит только
последнюю версию пакета
• Поэтому у нас пока два независимых
репозитория для production и dev
• Из соображений безопасности так будет
всегда, но в дальнейшем мы настроим
синхронизацию файлов между ними
• Видимо, сделав разные префиксы для
разных окружений


Свобода подразумевает ответственность

• Кстати, Chef позволяет разворачивать
сервисы, вообще не заботясь о
предварительном создании пакетов
• Я не рекомендую так делать без
необходимости, но в некоторых случаях
приходится
• Например, пакеты для Python и Node.JS
ставятся из исходников в обход
пакетного менеджера Debian


Собранные пакеты надо уметь деплоить

• Наши deployment scripts написаны на
shell за пару вечеров
• Они неоптимальны
• В частности, из-за pull-модели у нас пока
нет обратной связи с Chef-клиентами
• Для параллельного исполнения команд
на многих нодах мы применяем pssh
• Будем пробовать RunDeck или Fabric


Сервисами надо уметь управлять

• Мы используем runit для управления
большинством наших daemons
• runit работает как watchdog, если сервис
упал – он будет запущен снова через секунду
• Утилита svlogd перехватывает консольный
вывод, перенаправляет его в файл и берет
на себя ротацию этих файлов
• Любой процесс может быть превращен в
сервис, не нужно уметь detach’иться от
консоли – runit берет это на себя


Давненько не было новых логотипов

• Большой брат должен следить,
варианты:
– Zabbix или NAGIOS для алертинга,
– Munin или Zabbix для графиков
• Я много раз пытался использовать
Zabbix, и каждый раз бросал:
– Чтобы понять, почему, сделайте в нем
Screen на 9-12 графиков и бонусом
приложите базу 9-12 одновременными
тяжелыми сортировками


Zabbix это боль

• Я умею строить partial index, который
решает проблему трэшинга диска, но
• Нормально заскриптовать Zabbix через
шаблоны, пригодные для помещения в
Chef repo я так и не смог (устал)
• А поэтому
– NAGIOS, Munin, но
• Период опроса длинноват, fork()и при
работе плагинов


Надо отделять мух от котлет

• Маленький период опроса при
алертинге is overrated – в случае
падения 30 секунд или 5 минут на
доставку алерта не играют решающей
роли
• Но информацию для показа на
графиках хотелось бы получать чаще
• А поэтому


Avoid server-side JS at all cost

• Графики – Graphite + Statsd
– Graphite это такой better
MRTG/RRDTool, написан на Python (но это
неважно)
– Statsd это такой агрегатор первичных
значений метрик, написан на базе Node.JS
(это важно), и от 20 до 50 процентов метрик
он у нас терял
• Graphite позволяет определять графики
прямо в процессе их просмотра, что мне
очень нравилось на начальном этапе


Кстати, а зачем два инструмента?

• Statsd умеет принимать данные по UDP
(Graphite уже тоже умеет, но Statsd научился
первым)
• Всегда передавайте вспомогательную
статистику по UDP – ей не жалко
пожертвовать при отказах системы
обработки статистики
• В один Graphite можно передавать данные
через несколько Statsd, что позволяет
обрабатывать очень большой поток
первичных значений


Ruby is the new Perl

• Statsd пришлось выбросить из-за
упомянутых потерь первичных
значений
• Похоже, весь нормальный Ops
engineering софт в современном мире
пишется на Ruby:
– https://github.com/seatgeek/statsd_rb
– Drop-in замена оригинальному
statsd, которая работает и ничего не
теряет


Сбор логов – как это делают люди?

• Splunk, loggly и т.п. – стоят денег
• http://www.quora.com/What-are-the-
best-free-alternatives-to-Splunk:
– Logstash
– Graylog2
– Logio (Node.JS!)
– Fluentd


Сбор логов – как это делаем мы?

• Часть наших daemons логгируют через
syslog, часть – в файлы, часть – на консоль
• Удобнее всего – на консоль, мы
заворачиваем такие логи в файлы через
svlogd
• Logstash – агент на нодах и
препроцессор, мониторит файлы логов и
сбрасывает результаты обработки на
Graylog2
• syslogd – сбрасывает логи на Graylog2
напрямую


Сбор логов – как это делает Graylog2?

• ElasticSearch для индексации и хранения
• MongoDB для хранения
вспомогательной информации
• Ruby-based web dashboard
• Ну и как оно?
– С 23 сентября по 12 октября обработано 96
миллионов сообщений
– Продолжаем наблюдение


Я забыл сказать, в чем была сложность?

• Некоторые параметры наших
окружений:
– 62 cookbooks
– 31 roles
– 18 nodes in dev env, 25 in production
– Hundreds of daemons in production


Планы на будущее

• pull-модель не очень хорошо совместима с
нашим текущим набором deployment scripts
– Хотим упорядочить процесс выкладки
• Графики Graphite хорошо бы тоже описывать
при помощи Chef
– https://github.com/ripienaar/gdash (Ruby again!)
• Нагрузка будет расти - есть планы по
улучшению инфраструктуры уже сейчас
(логотипы логотипы логотипы!)


Выводы

• Конфигурация это код
• Сисадмин – девелопер
• Знание – сила


Вопросы

• .................?
• ....................?
• ...............?
• ...................?


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

• Александр Чистяков, компания
Cezurity
• admin@cezurity.com
• http://alexclear.livejournal.com
• https://github.com/alexclear
• Кстати, мы нанимаем!
– Developers, developers, developers!


Chef @DevWeb

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (7)

Similar to Chef @DevWeb

Similar to Chef @DevWeb (20)

More from Alex Chistyakov

More from Alex Chistyakov (20)

Chef @DevWeb