Сейчас многие компании работают без возможности прямого управления составом пакетов внешних репозиториев, даже если применяют зеркалирование, проксирование и кэширование. Это приводит к тому, что окружение выполнения постоянно меняется, в частности состав докер-образов меняется чаще, чем требуется производству.
Возможны ситуации, когда в состав разрабатываемого продукта могут попадать нежелательные изменения, которые содержатся во внешних зависимостях. Это особенно актуально во время сертификации продукта. Как следствие — затягивание сертификаций, сбои ночных тестов и интеграционного тестирования, поломки on-premise production (производственной среды, расположенной на собственных ресурсах организации) при накатывании хотфикса и прочее. В новой статье мы описали подход, который позволит избежать таких проблем.
Чего мы хотели добиться
Прежде чем приступать к описанию подхода, пара слов о задачах, которые мы хотели решить:
- Получить полный контроль над составом внешних пакетов в релизе (предсказуемость).
- Зафиксировать составы внешних репозиториев для быстрой выкатки хотфиксов с минимальным дополнительным тестированием (скорость).
- Обеспечить продуктовые стенды QA повторяемым предсказуемым фиксированным окружением (повторяемость).
- Независимость от наличия внешнего канала связи (автономность).
- Моментальное переключение на официальные репозитории при аварии (отказоустойчивость).
- Гарантированная проверка ключей внешних репозиториев в сборочных конвейерах (доверие).
- И самое главное, передать управление и контроль над составом внешних пакетов в руки продуктовых команд и релиз-менеджеров (самоуправление).
Анализ жизненного цикла feature-сборок
Наш подход решает задачу фиксации состава внешних репозиториев на конкретную дату, под релиз или фичу. Следующая схема наглядно показывает управление жизненным циклом релиза, feature-сборки и хотфикса.
Для примера возьмем условный репозиторий Debian Stretch. Данный подход применим и для репозиториев Docker, SaltStack и т. п. На временной шкале зафиксировали три среза на даты T1, T2 и T3.
| T1 | T2 | T3 | |
|---|---|---|---|
| stretch | 20200305 | 20200420 | 20200615 |
| Feature1 | 20200304 | 20200304 | 20200501 |
| Feature2 | 20200304 | 20200304 | 20200601 |
| Feature3 | 20200301 | 20200406 | 20200406 |
Мы свели в таблицу состав внешнего репозитория Debian Stretch для сборки дистрибутивов Feature1, Feature2 и Feature3. Из таблицы видно, что состав внешнего репозитория контролируется каждой веткой независимо. Мы приняли соглашение для себя фиксировать ветку master для Debian Stretch ежедневно и давать метки каждому срезу в формате YYYYMMDD, например 2020304 для среза на 4 марта 2020 года. Итого в таблице приведены используемые для дистрибутива в каждой ветке срезы внешнего репозитория в трех разных моментах времени и состав в мастере для Debian Stretch. Команда для каждой фичи или для каждого релиза обновляет состав внешних репозиториев по своему усмотрению и согласно своему циклу разработки.
На примере Feature1: продуктовая команда приступает к разработке новой фичи и фиксирует в конфигурационных файлах состав внешнего репозитория на дату 20200228 (см. на схеме выше).
Переключаем на 20200228
deb http://repository.co/debian-stretch-20200228 stretch main contrib non-freeВ процессе разработки в связи с появлением новых пакетов возникает необходимость обновить пакетную базу до даты 20200304. Переключаем рабочий репозиторий на нужную дату.
Переключаем на 20200304
deb http://repository.co/debian-stretch-20200304 stretch main contrib non-freeДалее происходит еще одно переключение пакетной базы на дату 20200501.
Переключаем на 20200501
deb http://repository.co/debian-stretch-20200501 stretch main contrib non-freeЕсли теперь мы проведем временные срезы, то увидим, что в моменты времени T1 и Т2 разработка Feature1 идет на пакетной базе, «замороженной» 4 марта 2020 года. А в срезе T3 разработка идет уже на новой пакетной базе за 1 мая 2020 года.
Продуктовое мультирелизное управление зависимостями
Теперь рассмотрим управление зависимостями нескольких активных релизов продукта. На поддержке представлены три релиза 2.5, 2.6 и 2.7.
В таблице мы видим соответствие релизов и дат, на которые сделан слепок репозитория. В ней показано, какой срез состава внешнего репозитория использовался для построения конкретной версии дистрибутива.
| Релиз | Состав |
|---|---|
| 2.5.128, 2.5.135, 2.5.207 | 20200301 |
| 2.6.201, 2.6.215, 2.6.315 | 20200301 |
| 2.7.210, 2.7.217, 2.7.305 | 20200404 |
Вместо именования срезов по датам YYYYMMDD мы также используем именование тегами в формате <ProjectName.ReleaseVersion> (название_релиза.версия_релиза продукта, например name.2.2) или <ProjectName-FeatureNumber> (добавляем номер фичи, например 3).
Снапшот для 2.5 по состоянию на 20200301
deb http://repository.co/debian-stretch-projectname-2.5 stretch main contrib non-free # 20200301Таким образом в процессе разработки релиза 2.5 команда фиксирует состав зависимых репозиториев на дату 20200301. Где-то в апреле команда начинает новый релиз 2.6 и решает использовать состав пакетов внешнего репозитория от 2.5. Создаем новый снапшот для 2.6 из снапшота для 2.5. В будущем составы репозиториев для релизов 2.5 и 2.6 могут легко разойтись. Мы сделали для 2.6 свой тег debian-stretch-projectname-2.6.
Снапшот для 2.6 по состоянию на 20200301
deb http://repository.co/debian-stretch-projectname-2.6 stretch main contrib non-free # 20200301В случае релиза 2.7 команда может начать разработку с ветки master — ежедневного снапшота оригинального репозитория.
Снапшот для 2.7 по состоянию на 20200404
deb http://repository.co/debian-stretch-projectname-2.7 stretch main contrib non-free # 20200404Мультипродуктовое управление зависимостями
Рассмотрим мультипродуктовое управление зависимостями на примере двух продуктов с разными релизными циклами и своими продуктовыми командами: Stealth и Infiniti.
Прокомментируем таблицу, что и когда происходит.
| Продукт | Релиз | Состав |
|---|---|---|
| stealth2.2 | r2.2.124 | 20200301 |
| stealth2.2 | r2.2.131, r2.2.162 | 20200305 |
| infiniti4.0 | r4.0.235, r4.0.241 | 20200303 |
| infiniti4.0 | r4.0.250 | 20200308 |
1. Пусть с 1 марта 2020 года стартовала разработка версии 2.2 проекта Stealth, для этого был создан снапшот состава пакетной базы на текущую дату. Выпуск релиза 2.2.124 выполнен с пакетной базой внешнего репозитория от 20200301.
Stealth 2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 202003012. Пятого числа производится обновление пакетной базы. Рабочий репозиторий debian-stretch-stealth-2.2 одномоментно переключается на нужную дату, выпуск релизов 2.2.131 и 2.2.162 выполнен с составом пакетов внешнего репозитория от 20200305. Без дополнительных манипуляций в окружении все 100500 микросервисов продукта одномоментно получили в сборочном конвейере новое окружение 20200305.
Stealth 2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 202003053. Параллельно третьего числа стартует разработка проекта Infiniti версии 4.0 и для нее создается срез состава репозитория на дату 20200303. Версии 4.0.235 и 4.0.241 выпускаются с составом пакетов внешнего репозитория на 20200303.
Infiniti 4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 202003034. После выпуска версии 4.0.241 команда решает обновить состав репозитория до 20200308 и выпустить новый релиз с новым составом внешних пакетов. Версия 4.0.250 выходит с составом пакетов на 20200308.
Infiniti 4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200308Два варианта переключения между состояниями репозиториев позволяют выбрать удобный для процесса разработки подход. В первом случае мы переключаемся в нужное состояние путем указания снапшота репозиториев на конкретную дату. Во втором случае для многокомпонентных продуктов используем именованный срез и двигаем его на нужную дату. Такой механизм обеспечивает единовременное переключение среза во всех 100500 компонентах продукта.
Управление срезами каждого внешнего репозитория мы ведем в отдельном Docker-контейнере, поэтому в любой момент можем переключить конкретный репозиторий на скачивание с внешней сети в случае каких-то аварий.
Скачать список всех репозиториев
# For example
curl repository.co/info/sources.list | grep $(lsb_release -cs) > /etc/apt/sources.listАвтоматическое создание срезов внешних репозиториев
Обновление репозиториев происходит каждую ночь по планировщику GitLab. При добавлении нового репозитория изменения автоматически применяются на сервере.
В момент фиксации нового среза внешнего репозитория проверяется его сертификат, если он отличается от сохраненного у нас, то обновления не происходит, а нам поступает сообщение об ошибке.
Итоги
- Подготовка новой версии дистрибутива к сертификации больше не является головной болью. На период сертификации мы фиксируем состав дистрибутива, и если нужно что-то пофиксить оперативно, то с большой вероятностью в выпущенном хотфиксе не будет ошибок из-за изменения окружения.
- Все feature-сборки получают управляемое состояние внешних репозиториев.
- Ускоряются выкатка хотфиксов и проверка через QA с предсказуемым, быстрым и успешным результатом.
- Feature-стенды получают после развертывания заранее определенную, неизменяемую среду выполнения.
- Продуктовые команды получили полностью самостоятельный контроль над составом внешних репозиториев для любых задач.
Отметим, что у Debian есть официальный ресурс snapshot.debian.org с ежедневными срезами и большой глубиной хранения. Для определенных задач этого достаточно.
Благодарим Сергея Смирнова и сообщество за прекрасный инструмент для управления составом внешних репозиториев Aptly. От нас — небольшой вклад в лучшие практики использования этого полезного инструмента в производственных конвейерах.
В следующих статьях расскажем про связку Aptly + Simple-CDD для подготовки ISO-образов дистрибутивов, делегирование управления внешними зависимостями в продуктовые команды и проблемы применения Aptly в процессе управления внешними зависимостями.
Авторы: Никита Драчёв, Александр Паздников, Тимур Гильмуллин
