Chef @DevWeb

Управление окружениями в сложном проекте

Chef и другие

13.04.2023 1www.cezurity.com

Александр Чистяков, [email protected] DevOpsCezurityhttp://vk.com/av

mailto:[email protected]

http://vk.com/av

13.04.2023 www.cezurity.com 2

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

Я:• Дезертировавший кодер на 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!)

• Необходим общий механизм управления, анализа состояния системы и контроля

• Кроме того, все должно быть четко


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

• Всё уже придумано до нас!• К сожалению, не все придумано для нас –

готовимся засучить рукава• Алгоритм принятия решений:– Тестируем– Измеряем– Анализируем– Повторяем или Выходим

• Сосед Вася лжет (кстати, все лгут)

13.04.2023 www.cezurity.com

Поехали!

• Унификация описаний конфигурации (желательно все хранить в одном месте)– Репозиторий у нас уже есть (Subversion), там и

будем хранить• Возникают новые вопросы:

– Как в репозитории скомпоновать конфигурационные файлы (Вместе с приложением? Или все конфиги в одном общем месте?)

– Как хранить конфиги разных окружений (Делать брэнчи в Subversion или хранить все в разных каталогах одной ветки?)

10


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

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

нового окружения должно быть минимально, иначе окружения рассинхронизируются

– Идеально, когда конфигурация сервисов генерируется автоматически по декларативно описанным параметрам нового окружения

11


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

• Приведение всех видов сервисов к единому представлению (captain Package Manager to the rescue!)– Кажется, эту типовую задачу решали

множество раз?– http://

docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html

– http://www.debian.org/doc/manuals/maint-guide/ 12

http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html




http://www.debian.org/doc/manuals/maint-guide/




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

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

13


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

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

системы и генерировать предупреждения– Нужно собирать статистику и рисовать графики– Нужно разворачивать новые версии окружения

согласно установленной процедуре– Которую сначала необходимо установить

• Кроме того, все должно быть четко!

14


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

• Управление конфигурацией, на выбор:– Chef– Puppet– CFEngine

• Решаемые задачи:– Централизованное хранение описаний

конфигураций– Генерация конфигов по шаблонам и параметрам– Автоматическое развертывание окружений

согласно заданному алгоритму

15


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

• Puppet vs. Chef:– Оба написаны на Ruby– Я уже имел некоторый опыт с Puppet– И мне показалось, что learning curve у него не

такая короткая (а кроме меня системой управления конфигурацией будут пользоваться и другие)

– Макс Трескин считает, что про Puppet я все вру, и он прост, но

– Макс пишет на Эрланге и носит с собой штопор

16


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

• Chef vs. CFEngine:– Chef требует Solr, CouchDB, RabbitMQ (логотипы

логотипы логотипы!)– Все это хозяйство существенно расходует ресурсы– CFEngine может работать на телефоне LG с

Android– CFEngine’s learning curve?

17


Словарик

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

• knife – команднострочный клиент для управления

• recipe – алгоритм применения правил конфигурации

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

• role – группа «рецептов» и других ролей

18


Словарик

• run list – набор «рецептов» и ролей для применения

• attribute – переменная, свойство ноды• node – абстракция хоста, ей ставятся в

соответствие атрибуты и run list• environment – декларативно

объявленные атрибуты, предописывающие окружение

19


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

• Клиент, сервер (клиент это тоже daemon)• Клиент через определенные промежутки времени

забирает с сервера конфигурацию, составляет и применяет run list

• Это pull-модель, а не push (это может быть важно!)• Все упомянутые выше CM системы работают по

pull-модели• Клиент коллекционирует атрибуты узла, такие как

версия и дистрибутив ОС при помощи утилиты ohai

20


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

• Помните, я начал словарик с утилиты knife?• knife – средство опроса состояния

конфигурации на сервере и внесения изменений в конфигурацию

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

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

21


Словарик strikes back

• Ведь есть еще chef-solo, data bags, providers, LWRPs…

• О которых я не упомянул• Так, что я там говорил про learning curve?• Кстати, где брать cookbooks?• Chef очень хорошо приспособлен для работы

с github (там имеется централизованный репозиторий основных cookbooks) <- счастье состоит как раз из таких вот мелочей

22


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

• 42• Репозиторий для Chef у нас находится в

выделенном месте, конфиги лежат в нем же (это просто шаблоны в терминологии Chef)

• Мы используем несколько веток в Subversion для хранения разных окружений, что позволяет нам также иметь разный эталонный набор cookbooks

• Вопрос унификации окружений почти решен

23


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

• Мы используем Debian– Работает (в отличие от RH) checkinstall, но в

интерактивном режиме он довольно говорлив– Отличная утилита FPM, написанная на Ruby

человеком, который хорошо понимал слайд 13– https://github.com/jordansissel/fpm

• Собственная build-система на Python• Сильно заточенная под наши нужды, но наши

пакеты она прекрасно собирает• Пакеты мало собрать, нужно еще сложить в

репозитории

24

https://github.com/jordansissel/fpm

https://github.com/jordansissel/fpm


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

• Утилита reprepro• Всем хороша, но хранит только последнюю

версию пакета• Поэтому у нас пока два независимых

репозитория для production и dev• Из соображений безопасности так будет

всегда, но в дальнейшем мы настроим синхронизацию файлов между ними

• Видимо, сделав разные префиксы для разных окружений

25


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

• Кстати, Chef позволяет разворачивать сервисы, вообще не заботясь о предварительном создании пакетов

• Я не рекомендую так делать без необходимости, но в некоторых случаях приходится

• Например, пакеты для Python и Node.JS ставятся из исходников в обход пакетного менеджера Debian

26


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

• Наши deployment scripts написаны на shell за пару вечеров

• Они неоптимальны• В частности, из-за pull-модели у нас пока

нет обратной связи с Chef-клиентами• Для параллельного исполнения команд

на многих нодах мы применяем pssh• Будем пробовать RunDeck или Fabric

27


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

• Мы используем runit для управления большинством наших daemons

• runit работает как watchdog, если сервис упал – он будет запущен снова через секунду

• Утилита svlogd перехватывает консольный вывод, перенаправляет его в файл и берет на себя ротацию этих файлов

• Любой процесс может быть превращен в сервис, не нужно уметь detach’иться от консоли – runit берет это на себя

28


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

• Большой брат должен следить, варианты:– Zabbix или NAGIOS для алертинга,– Munin или Zabbix для графиков

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

на 9-12 графиков и бонусом приложите базу 9-12 одновременными тяжелыми сортировками

29


Zabbix это боль

• Я умею строить partial index, который решает проблему трэшинга диска, но

• Нормально заскриптовать Zabbix через шаблоны, пригодные для помещения в Chef repo я так и не смог (устал)

• А поэтому– NAGIOS, Munin, но

• Период опроса длинноват, fork()и при работе плагинов

30


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

• Маленький период опроса при алертинге is overrated – в случае падения 30 секунд или 5 минут на доставку алерта не играют решающей роли

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

• А поэтому

31


Avoid server-side JS at all cost

• Графики – Graphite + Statsd– Graphite это такой better MRTG/RRDTool,

написан на Python (но это неважно)– Statsd это такой агрегатор первичных

значений метрик, написан на базе Node.JS (это важно), и от 20 до 50 процентов метрик он у нас терял

• Graphite позволяет определять графики прямо в процессе их просмотра, что мне очень нравилось на начальном этапе

32


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

• Statsd умеет принимать данные по UDP (Graphite уже тоже умеет, но Statsd научился первым)

• Всегда передавайте вспомогательную статистику по UDP – ей не жалко пожертвовать при отказах системы обработки статистики

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

33


Ruby is the new Perl

• Statsd пришлось выбросить из-за упомянутых потерь первичных значений

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

которая работает и ничего не теряет

34

https://github.com/seatgeek/statsd_rb

https://github.com/seatgeek/statsd_rb


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

• Splunk, loggly и т.п. – стоят денег• http://

www.quora.com/What-are-the-best-free-alternatives-to-Splunk:– Logstash– Graylog2– Logio (Node.JS!)– Fluentd

35

http://www.quora.com/What-are-the-best-free-alternatives-to-Splunk




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

• Часть наших daemons логгируют через syslog, часть – в файлы, часть – на консоль

• Удобнее всего – на консоль, мы заворачиваем такие логи в файлы через svlogd

• Logstash – агент на нодах и препроцессор, мониторит файлы логов и сбрасывает результаты обработки на Graylog2

• syslogd – сбрасывает логи на Graylog2 напрямую

36


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

• ElasticSearch для индексации и хранения• MongoDB для хранения

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

миллионов сообщений– Продолжаем наблюдение

37


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

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

38


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

• pull-модель не очень хорошо совместима с нашим текущим набором deployment scripts– Хотим упорядочить процесс выкладки

• Графики Graphite хорошо бы тоже описывать при помощи Chef– https://github.com/ripienaar/gdash (Ruby again!)

• Нагрузка будет расти - есть планы по улучшению инфраструктуры уже сейчас (логотипы логотипы логотипы!)

39

https://github.com/ripienaar/gdash

https://github.com/ripienaar/gdash


Выводы

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

40


Вопросы

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

41


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

• Александр Чистяков, компания Cezurity

• [email protected]• http://alexclear.livejournal.com• https://github.com/alexclear• Кстати, мы нанимаем!– Developers, developers, developers!

42

mailto:[email protected]

http://alexclear.livejournal.com/

https://github.com/alexclear

Documents

Chef @DevWeb