Поддршка за monorepo и multirepo во werf и каква врска има Docker Registry со тоа

Темата за моно складиште е дискутирана повеќе од еднаш и, по правило, предизвикува многу активни контроверзии. Со создавање верф како алатка со отворен код дизајнирана да го подобри процесот на градење апликативен код од слики од Git до Docker (и потоа да ги доставува до Кубернетес), не размислуваме многу за тоа кој избор е најдобар. За нас е примарно да обезбедиме се што е потребно за поддржувачите на различни мислења (ако тоа не е во спротивност со здравиот разум, се разбира).

Неодамнешната моно-репо поддршка на 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 се ограничи на вгнездени складишта - за среќа, повеќето регистри ја поддржуваат оваа функција. Почнувајќи од верзијата v1.0.4-алфа.3, додаде работа со регистри во кои гнездење не е поддржано, а Docker Hub е еден од нив. Од тој момент, корисникот има избор како да ги зачува сликите на апликацијата.

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

Бидејќи повеќето опции за верф може да се постават променливи на животната средина, во CI / CD системите, режимот за складирање обично е лесно да се постави глобално за целиот проект. На пример, во случајот со GitLab само додадете променлива на животната средина во поставките на проектот: Поставки -> CI / CD -> Променливи: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

Ѓаволот е во деталите

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

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

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

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

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

NB: Ако сте заинтересирани да погледнете сè што е опишано во изворниот код на werf, тогаш почетната точка може да биде ПР 1684.

Во оваа статија, нема да обрнуваме повеќе внимание на проблемите и оправданоста на нашиот пристап: за стратегиите за означување, складирање на податоци во етикети и процесот на објавување како целина - сето ова е детално опишано во неодамнешниот извештај на Дмитриј Столјаров: „werf е нашата алатка за CI/CD во Kubernetes".

За да резимираме

Недостатокот на поддршка за невгнездени регистри не беше фактор за блокирање за нас или за нас познатите корисници на werf - на крајот на краиштата, секогаш можете да подигнете посебен регистар на слики (или да се префрлите на условен регистар на контејнери во Google Cloud) ... Сепак, Отстранувањето на таквото ограничување изгледаше логично со цел алатката да биде попогодна за пошироката заедница DevOps. При неговото спроведување, се соочивме со главната тешкотија во преработката на механизмот за чистење на регистарот на контејнери. Сега, кога сè е подготвено, убаво е да сфатиме дека некому му стана полесно и ние (како главни развивачи на проектот) нема да имаме забележителни потешкотии во понатамошната поддршка на оваа функција.

Останете со нас и наскоро ќе ви кажеме за другите иновации во верф!

PS

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

• «Сега можете да изградите Docker слики во werf користејќи обична Dockerfile";
• «werf - нашата алатка за CI / CD во Kubernetes (преглед и видео извештај)".

Извор: www.habr.com