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

Темата на монорепозитория вече е обсъждана многократно и обикновено предизвиква доста активни спорове. Създавайки werf като Open Source инструмент, предназначен да подобри процесите на изграждане на код за приложения от 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 е достатъчно да добавите променлива на средата в настройките на проекта: Настройки -> CI / CD -> Променливи: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

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

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

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

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

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

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

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