Поддръжка на monorepo и multirepo в werf и какво общо има тук Docker Registry

Тема на монорепозитория вече е обсъждана неведнъж и обикновено предизвиква доста активни спорове. Създавайки werf като инструмент с отворен код, предназначен да подобри процесите на компилиране на код на приложения от Git в Docker изображения (и тяхната последваща доставка в Kubernetes), рядко размишляваме върху това какъв избор е по-добър. За нас е приоритет да осигурим всичко необходимо за поддръжниците на различни мнения (освен ако това не противоречи на здравия разум, разбира се).

Наскоро появилата се поддръжка на mono-repo в werf е добър пример за това. Но първо нека да разгледаме как тази поддръжка изобщо е свързана с използването на werf и какво общо има с Docker Registry…

Проблематика

Представете си такава ситуация. В компанията има много екипи разработчици, които работят по независими проекти. Повечето приложения функционират в Kubernetes, следователно - контейнеризирани са. За съхранение на контейнерите и изображенията е необходим регистър (registry). В качеството на такъв регистър в компанията се използва Docker Hub с един единствен акаунт COMPANY. Подобно на повечето системи за съхранение на изходен код, Docker Hub не позволява създаването на вложена йерархия на хранилища, такава като COMPANY/PROJECT/IMAGE. В такъв случай… как обаче с това ограничение да съхраняваме немонолитни приложения в регистъра, без да създаваме отделен акаунт за всеки проект?

Възможно е описаната ситуация на някого да е позната, но нека разгледаме въпроса за организацията на съхранението на приложения в общ план, т.е. без привързаност към гореописания пример и Docker Hub.

Пътища за решение

Ако приложението е монолитно, доставя се в едно изображение, то няма да възникнат въпроси и просто запазваме изображенията в регистъра на контейнерите на проекта.

Когато приложението е представено под формата на няколко компонента, микросервизи, е необходимо да се избере определен подход. На примера на типично уеб приложение, състоящо се от две изображения: фронтенд и backend — възможните варианти са:

1. Да съхраняваме изображения в отделни вложени хранилища:

   

2. Да съхраняваме всичко в едно хранилище, а името на изображението да се отразява в тага, например, по следния начин:

   

NB: Всъщност, има и друг вариант със съхранение в различни хранилища, PROJECT-frontend и PROJECT-backend, но него няма да разглеждаме поради сложността на поддръжката, организацията и разпределението на правата между потребителите.

Поддръжка в werf

Първоначално werf се ограничи до вложени репозитории — за щастие, повечето регистри поддържат тази възможност. Започвайки от версия v1.0.4-alpha.3, добавена е работа с регистри, в които не се поддържа вложеност, и Docker Hub — сред тях. От този момент потребителят получи избор как да съхранява образите на приложението.

Реализацията е налична в рамките на опцията --images-repo-mode=multirepo|monorepo (по подразбиране multirepo, т.е. съхранение във вложени репозитории). Тя определя моделите, по които образите се съхраняват в регистра. Достатъчно е да изберете нужния режим при използване на основните команди, а всичко останало остава непроменено.

Тъй като повечето опции на werf могат да се задават чрез променливи на средата, в CI/CD системите режимът на съхранение, обикновено, е лесен за задаване глобално за целия проект. Например, в случая с GitLab е достатъчно да добавите променлива на средата в настройките на проекта: Settings -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Говорейки за публикуване на образи и деплойване на приложения (за тези процеси можете да прочетете в съответните статии на документацията: Процес на публикуване и Процес на деплойване), режимът изключително определя модела, по който можете да работите с образа.

Дяволът е в детайлите

Разликата и основната сложност при добавянето на нов начин на съхранение — в процеса на почистване на регистъра (възможностите за почистване, поддържани в werf, вижте в Процес на почистване).

При почистването werf взема предвид образите, използвани в Kubernetes клъстери, както и политиките, зададени от потребителя. В основата на политиките лежи разделянето на таговете на стратегии. Стратегиите, поддържани в момента:

1. 3 стратегии, свързани с Git примитиви, като таг, клон и комит;
2. 1 стратегия за произволни потребителски тагове.

Информацията за стратегията на тага се запазва при публикуването на образа в етикетите на крайния образ. Самата стойност — т.нар. мета-таг — е необходима за прилагане на част от политиките. Например, при изтриване на клон или таг от Git репозиторий е логично да се изтрият и свързаните неизползвани образи от регистра, което покрива част от нашите политики.

При съхранение в един репозиторий (monorepo), в тага на образа, освен мета-тага, също може да се съхранява и името на образа: ПРОЕКТ:фронтенд-МЕТА-ТАГ. За тяхното разделяне не въведохме специфичен разделител, а просто добавихме необходимата стойност в етикета на крайния образ при публикуването.

NB: Ако сте заинтересувани да видите всичко описано в изходния код на werf, отправната точка може да бъде PR 1684.

В тази статия няма да се фокусираме повече върху проблемите и обосновката на нашия подход: относно стратегиите за тагове, съхранението на данни в етикети и процеса на публикуване като цяло — всичко това беше подробно описано в скорошния доклад на Дмитрий Столяров: "werf — нашият инструмент за CI/CD в Kubernetes».

Обобщавайки

Липсата на поддръжка на регистри без вложеност не беше блокиращ фактор за нас или известните ни потребители на werf — винаги може да се постави отделен регистрар за образи (или да се премине към условния Container Registry в Google Cloud)… Все пак, премахването на такова ограничение изглеждаше логично, за да бъде инструментът удобен за по-широкото DevOps общество. При реализирането му се сблъскахме с основната сложност в преработката на механизма за почистване на регистъра на контейнери. Сега, когато всичко е готово, е приятно да осъзнаваме, че на някого е станало по-лесно, а при нас (като основни разработчици на проекта) не предвиждаме значителни затруднения в бъдещата поддръжка на тази функция.

Останете с нас и съвсем скоро ще разкажем за други нововъведения в werf!

P.S.

Прочетете също в нашия блог:

• «Сега можете да събирате Docker образи в werf и по обикновен Dockerfile»;
• «werf — наш инструмент за CI/CD в Kubernetes (обзор и видео доклад)».

Източник: habr.com