По мере развития продукта и его роста могут возникать различные сложности. В ходе работы над нашей системой MaxPatrol мы столкнулись с исчерпанием ресурсов команды, отвечающей за поддержку инфраструктуры проекта. В частности, нам требовалось наладить систему развертывания — с этим не все было просто. Сегодня мы расскажем о том, в чем конкретно были сложности, и как мы их преодолели, разработав собственный инструментарий для создания дистрибутивов.
Немного истории
В 2013 году инфраструктура нашего проекта выглядела следующим образом:
- 1 компонент продукта;
- 1 проект инсталлятора;
- 6 сервисов и конфигурационных файлов;
- 4 артефакта-источников файлов для дистрибутива;
- 1 человек из команды продукта занимался разработкой инсталлятора.
В процессе развития продукта он стал значительно более масштабным. Увеличивалось количество его обособленных компонентов, в каждом из них увеличивалось число пакетов инсталлятора, увеличивалась сложность каждого отдельного инсталлятора, становилось больше источников файлов. Стала необходимость создания специального отдела инфраструктуры продукта. Некоторые цифры на 2014-2015 год:
- 4 компонента продукта;
- 18 проектов инсталлятора;
- 20+ сервисов и конфигурационных файлов;
- 50+ артефактов;
- ~10 Feature Branches (FB) в одном релизе;
- 4 человека в новом отделе инфраструктуры продукта.
Все это приводило и к росту трудозатрат команды инфраструктуры — система становилась все сложнее, поэтому при внесении изменений необходимо было тратить время на то, чтобы понять, как правильно их осуществить. В результате среднее время ожидания внесения изменений увеличилось.
Мы тратили большое количество времени — каждое изменение необходимо было обсудить с заказчиком, приходилось разбираться с багами на этапе развертывания, далеко не все из которых были связаны с работой инсталлятора и т.д. При этом, изменения всегда имеют высокий приоритет, а значит — приходилось больше заниматься разгребанием этой «текучки», а не развитием инфраструктуры проекта.
В итоге сильно замедлилось развитие инфраструктурных аспектов таких как доставка обновлений, централизованное управление развертыванием и конфигурирование, инструментарий для создания инсталляционных пакетов.. Необходимо было что-то с этим делать.
Решение: разделение зон ответственности
Для оптимизации разработки мы решили разграничить зоны ответственности между членами команд развития инфраструктуры и развития продукта. Чтобы понять, как конкретно нужно это делать, мы провели анализ. Он позволил нам разбить все запросы на изменения на несколько групп:
- Изменение состава инсталлятора компонента — какие файлы из каких артефактов должны попасть в инсталлятор?
- Изменения настройки компонента — какие параметры должны настраиваться, а также в какие конфигурационные файлы и как должны прописываться параметры?
- Изменения требуемого состояния целевой операционной системы — какие сервисы, сайты, правила файрволла, задачи в планировщике, директории (и с какими правами) следует создать?
В итоге распределение различных задач довольно серьезно изменилось — от монопольного «владения» тремя этими классами вопросов командой инфраструктуры мы перешли к смешанной схеме:
Но мало просто договориться о разделении ответственности — нужно еще найти способ технически его реализовать.
DSL спешит на помощь
Domain-specific language или DSL — это такой язык, который подходит для использования в ходе работы над определенной задачей. Если говорить о нашем проекте, то с помощью DSL мы смогли «договориться» и получили инструмент, который позволил всем людям, причастным к разработке, решать свои задачи без необходимости глубоко вникать в детали продукта (как вносить изменения в конфигурационные файлы и т.п.) В итоге работа значительно ускоряется, а все сущности можно можно свободно расширять, что обеспечивает большую гибкость.
Вот какие технологии мы использовали на этом этапе:
- Python (Jinja2, PyYaml, jsonschema): генерация сценариев и конфигурационных файлов, валидация DSL-описаний, генерация документации по схеме;
- PowerShell: сценарии развертывания для Windows;
- C#: самописная библиотека функций для настройки Windows-окружения;
- WiX, MSI: создание инсталляционных пакетов для Windows.
Итоговая схема выглядела так: мы использовали DSL и шаблон сценария для генерации, собственно, итогового сценария.
Использование DSL (Yaml):
Описание сценария развертывания (Jinja2):
Получаем на выходе сценарий развертывания PowerShell:
Аналогичным образом отрабатывается создание конфигурационных файлов: сначала с помощью DSL описываются значения параметров, затем создается шаблон конфигурационного файла — на выходе получаем готовый «конфиг» с нужными параметрами.
Также идет работа и над генерацией документации — сначала разрабатывается схема DSL, потом создается HTML-шаблон документа, что позволяет на выходе получить готовую документацию в HTML.
Результаты и планы
Одним из главных достижений внедрения стал тот факт, что мы наконец-то получили адекватное распределение обязанностей между разработчиками и специалистами по инфраструктуре проекта.
Второй важный эффект: среди причастных к продукту людей перераспределились и знания. В частности, разработчики узнали больше о процессе развертывания — описания инсталлятора и шаблоны конфигураций находятся прямо в их проектах.
Также нам удалось значительно сократить время ожидания внесения изменений. Раньше процесс выглядел так:
В такой схеме мы приходили к постоянному снижению производительности из-за роста числа задач. Частично решить проблему можно было расширением отдела инфраструктуры, но у этого способа есть вполне очевидные рамки применимости. Да и задач всегда будет больше чем людей.
После внедрения новых подходов схема взаимодействия стала выглядеть так:
В результате время внесения изменений всегда одно и то же и не увеличивается от количества заказчиков, которым нужно решить определенную задачу.
Мы не собираемся останавливаться на достигнутом и планируем развивать нашу систему. Вот, что будет сделано уже в ближайшее время:
- Linux как еще одна целевая платформа — мы расширим DSL для описания специфичных для Linux сущностей ОС и реализуем поддержку.deb-сборки на основе описания состава пакета;
- Интеграция с SaltStack — шаблоны скриптов будут заменены на Salt States;
- Публикация инструментов на GitHub в открытом сообществе DevOpsHQ.
P. S. Рассказ о разработанном нами инструментарии для создания дистрибутивов был представлен в рамках DevOps-митапа, который состоялся недавно в Москве.
По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.
Автор: Владимир Селин
P. P. S. Напоминаем, что совсем скоро при поддержке Positive Technologies в Москве пройдет курс по asyncio+aiohttp от Core-разработчика Python Андрея Светлова.
Мы хотим предложить один бесплатный билет на семинар автору лучшего вопроса для Андрея — вопрос выберет он сам и ответит на него в ходе занятия. Присылайте свои вопросы по адресу: asyncio2016@ptsecurity.com.
