Подршка за монорепо и мултирепо у верф-у и какве везе Доцкер регистар има са тим

Тема моно-репозиторија је разматрана више пута и, по правилу, изазива веома активну полемику. Стварањем верф као алатка отвореног кода дизајнирана да побољша процес прављења кода апликације од Гит до Доцкер слика (и затим да их испоручи у Кубернетес), не размишљамо много о томе који је избор најбољи. За нас је примарно да обезбедимо све што је потребно за присталице различитих мишљења (ако то није у супротности са здравим разумом, наравно).

верф-ова недавна моно-репо подршка је добар пример за то. Али прво, хајде да схватимо како је ова подршка генерално повезана са коришћењем верф-а и какве везе Доцкер регистар има са тим...

Проблеми

Замислимо такву ситуацију. Компанија има много развојних тимова који раде на независним пројектима. Већина апликација ради на Кубернетес-у и стога су у контејнерима. За складиштење контејнера, слика, потребан вам је регистар (регистратор). Као такав регистар, компанија користи Доцкер Хуб са једним налогом COMPANY. Слично већини система за складиштење изворног кода, Доцкер Хуб не дозвољава хијерархију угнежђеног спремишта, као такав COMPANY/PROJECT/IMAGE. У том случају… како можете да складиштите немонолитне апликације у регистру са овим ограничењем без креирања посебног налога за сваки пројекат?

Можда је описана ситуација некоме позната из прве руке, али хајде да размотримо питање организовања складиштења апликација уопште, тј. без позивања на горњи пример и Доцкер Хуб.

Решења

Ако апликација монолитна, долази у једној слици, онда нема питања и једноставно чувамо слике у регистру контејнера пројекта.

Када је апликација представљена као више компоненти, микросервис, онда је потребан одређени приступ. На примеру типичне веб апликације која се састоји од две слике: frontend и backend - могуће опције су:

1. Чувајте слике у одвојеним угнежђеним спремиштима:

   

2. Чувајте све у једном спремишту и размотрите име слике у ознаци, на пример, на следећи начин:

   

NB: Заправо, постоји још једна опција са чувањем у различитим спремиштима, PROJECT-frontend и PROJECT-backend, али га нећемо разматрати због сложености подршке, организације и расподеле права између корисника.

верф суппорт

У почетку, верф се ограничио на угнежђена спремишта - на срећу, већина регистара подржава ову функцију. Почевши од верзије в1.0.4-алпха.3, додао рад са матичним књигама у којима гнежђење није подржано, а Доцкер Хуб је један од њих. Од тог тренутка, корисник има избор како да складишти слике апликације.

Имплементација доступна под опцијом --images-repo-mode=multirepo|monorepo (Уобичајено multirepo, тј. складиштење у угнежђеним репозиторијумима). Он дефинише обрасце по којима се слике чувају у регистру. Довољно је изабрати жељени режим када користите основне команде, а све остало ће остати непромењено.

Зато што се већина верф опција може подесити променљиве окружења, у ЦИ/ЦД системима, режим складиштења је обично лако глобално подесити за цео пројекат. На пример, у случају ГитЛаб-а само додајте променљиву окружења у подешавања пројекта: Подешавања -> ЦИ / ЦД -> Променљиве: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Ако говоримо о објављивању слика и пуштању апликација (о овим процесима можете детаљно прочитати у релевантним чланцима документације: Процес објављивања и Процес имплементације), тада режим само одређује шаблон по коме можете да радите са сликом.

Ђаво је у детаљима

Разлика и главна потешкоћа при додавању нове методе складиштења је у процесу чишћења регистра (за функције чишћења које подржава верф, погледајте Процес чишћења).

Приликом чишћења, верф узима у обзир слике које се користе у Кубернетес кластерима, као и смернице које је конфигурисао корисник. Политике се заснивају на подели ознака на стратегије. Тренутно подржане стратегије:

1. 3 стратегије повезане Гит примитивима као што су ознака, грана и урезивање;
2. 1 стратегија за произвољне прилагођене ознаке.

Сачувамо информације о стратегији ознака када објављујемо слику у налепницама коначне слике. Сам смисао је тзв мета таг - Потребно је применити неке од смерница. На пример, када бришете грану или ознаку из Гит спремишта, логично је да избришете повезане неискоришћен слике из регистра, што је покривено делом наших смерница.

Када се сачува у једном спремишту (monorepo), у ознаци слике, поред мета ознаке, може се сачувати и назив слике: PROJECT:frontend-META-TAG. Да бисмо их раздвојили, нисмо увели никакав посебан сепаратор, већ смо једноставно додали потребну вредност ознаци коначне слике приликом објављивања.

NB: Ако сте заинтересовани да погледате све што је описано у верф изворном коду, онда почетна тачка може бити ПР КСНУМКС.

У овом чланку нећемо обраћати више пажње на проблеме и оправданост нашег приступа: о стратегијама означавања, чувању података у етикетама и процесу објављивања у целини - све је то детаљно описано у недавном извештају Дмитрија Стољарова: „верф је наш алат за ЦИ/ЦД у Кубернетесу'.

Резимирајући

Недостатак подршке за неугнештене регистре није био фактор блокирања ни за нас ни за нама познате верф кориснике – на крају крајева, увек можете да подигнете посебан регистар слика (или да се пребаците на условни регистар контејнера у Гоогле Цлоуд-у)... Међутим, уклањање таквог ограничења се чинило логичним како би алат био погоднији за ширу ДевОпс заједницу. Примењујући га, суочили смо се са главном потешкоћом у преради механизма чишћења регистра контејнера. Сада када је све спремно, лепо је схватити да је некоме постало лакше, а ми (као главни програмери пројекта) нећемо имати приметних потешкоћа у даљој подршци овој особини.

Останите са нама и врло брзо ћемо вам причати о осталим иновацијама у верф!

ПС

Прочитајте и на нашем блогу:

• «Сада можете да правите Доцкер слике у верф-у користећи обичан Доцкерфиле";
• «верф - наш алат за ЦИ / ЦД у Кубернетес-у (преглед и видео извештај)'.

Извор: ввв.хабр.цом