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

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

Неотдавнашната монорепо поддръжка на werf е добър пример за това. Но първо, нека разберем как тази поддръжка обикновено е свързана с използването на werf и какво общо има Docker Registry с това ...

Проблеми

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

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

Решения

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

Когато едно приложение е представено като множество компоненти, микроуслуги, тогава е необходим определен подход. На примера на типично уеб приложение, състоящо се от две изображения: frontend и 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.

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

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

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

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

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

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

При запис в едно хранилище (monorepo), в тага на изображението, в допълнение към мета тага, може да се съхранява и името на изображението: PROJECT:frontend-META-TAG. За да ги разделим, не въведохме никакъв специфичен разделител, а просто добавихме необходимата стойност към етикета на крайното изображение при публикуване.

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

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

Обобщавайки

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

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

PS

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

• «Вече можете да създавате Docker изображения в werf, като използвате обикновен Dockerfile»;
• «werf - нашият инструмент за CI / CD в Kubernetes (общ преглед и видео отчет)".

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