Temaet monorepo har blitt diskutert mange ganger, og som regel fÞrer det til ganske aktive debatter. Som et Äpen kildekode-verktÞy utviklet for Ä forbedre prosessen med Ä bygge applikasjonskode fra Git til Docker-avbildninger (og deretter levere dem til Kubernetes), bruker vi lite tid pÄ Ä tenke pÄ hvilket som er det beste valget. VÄrt primÊre fokus er Ä imÞtekomme ulike meninger (sÄ lenge det ikke motsier sunn fornuft, selvfÞlgelig).
Den nylige stÞtten for mono-repo i werf er et godt eksempel pÄ dette. Men fÞrst, la oss finne ut hvordan denne stÞtten er relatert til bruk av werf i det hele tatt, og hva Docker Registry har med det Ä gjÞre ...
Problemer
La oss forestille oss denne situasjonen. Selskapet har mange team med utviklere som jobber med uavhengige prosjekter. De fleste applikasjoner opererer i Kubernetes, og er derfor containeriserte. For Ä lagre containere og bilder trengs et register. Selskapet bruker Docker Hub med én enkelt konto som et slikt register. COMPANYI likhet med de fleste kildekodelagringssystemer, Docker Hub tillater ikke nestet repositorihierarki, slik som COMPANY/PROJECT/IMAGEI sÄ fall ... hvordan kan vi lagre ikke-monolitiske applikasjoner i registeret med denne begrensningen, uten Ä opprette en egen konto for hvert prosjekt?
Kanskje den beskrevne situasjonen er kjent for noen pÄ fÞrstehÄnd, men la oss vurdere spÞrsmÄlet om Ä organisere applikasjonslagring generelt, dvs. uten referanse til eksemplet ovenfor og Docker Hub.
LĂžsninger
Hvis sÞknaden monolittisk, leveres i ett bilde, sÄ oppstÄr det ingen spÞrsmÄl, og vi lagrer ganske enkelt bildene i prosjektets beholderregister.
NĂ„r en applikasjon presenteres som flere komponenter, mikrotjenester, mĂ„ du velge en spesifikk tilnĂŠrming. Bruk eksempelet pĂ„ en typisk webapplikasjon som bestĂ„r av to bilder: frontend Đž backend â de mulige alternativene er:
- Lagre bilder i separate nestede arkiver:
- Lagre alt i ett arkiv, og inkluder bildenavnet i taggen, for eksempel slik:
NBDet finnes faktisk et annet alternativ med lagring i forskjellige arkiver, PROJECT-frontend О PROJECT-backend, men vi vil ikke vurdere det pÄ grunn av kompleksiteten i stÞtte, organisering og fordeling av rettigheter mellom brukere.
StĂžtte i werft
I starten begrenset werf seg til nestede repositorier â heldigvis stĂžtter de fleste registre denne funksjonen. Fra og med versjon , lagt til arbeid med registre der Nesting stĂžttes ikke, og Docker Hub er en av dem. Fra nĂ„ av har brukeren et valg om hvordan applikasjonsavbildninger skal lagres.
Implementering er tilgjengelig som et alternativ --images-repo-mode=multirepo|monorepo (misligholde multirepo, dvs. lagring i nestede arkiver). Den definerer malene som bilder lagres med i registeret. Det er nok Ä velge Þnsket modus nÄr du bruker hovedkommandoene, og alt annet vil forbli uendret.
Siden de fleste werf-alternativer kan angis miljĂžvariablerI CI/CD-systemer er lagringsmodusen vanligvis enkel Ă„ angi globalt for hele prosjektet. For eksempel, i tilfellet med GitLab Det er nok Ă„ legge til en miljĂžvariabel i prosjektinnstillingene: Innstillinger -> CI / CD -> Variabler: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Hvis vi snakker om publisering av bilder og utrulling av applikasjoner (du kan lese om disse prosessene i detalj i de relevante dokumentasjonsartiklene): О ), sÄ bestemmer modusen utelukkende malen du kan jobbe med bildet etter.
Djevelen er i detaljene
Forskjellen og den stÞrste vanskeligheten nÄr man legger til en ny lagringsmetode er Ä rydde opp i registeret. (for rengjÞringsfunksjoner som stÞttes av Werf, se ).
Ved opprydding tar Werf hensyn til bildene som brukes i Kubernetes-klynger, samt brukerkonfigurerbare policyer. Policyene er basert pÄ Ä dele tagger inn i strategier. Strategier som stÞttes for Þyeblikket:
- 3 strategier relatert til Git-primitiver som tag, branch og commit;
- 1 strategi for tilpassede tagger.
Vi lagrer informasjonen om tagstrategien nĂ„r vi publiserer bildet i de endelige bildeetikettene. Selve verdien er den sĂ„kalte metatag â er nĂždvendig for Ă„ anvende enkelte policyer. NĂ„r man for eksempel sletter en gren eller tagg fra et Git-repositorium, er det fornuftig Ă„ ogsĂ„ slette de tilknyttede. ubrukt bilder fra registeret, som er dekket av en del av retningslinjene vĂ„re.
NÄr du lagrer i ett arkiv (monorepo), kan bildenavnet lagres i tillegg til metataggen i bildetaggen: PROJECT:frontend-META-TAGFor Ä skille dem innfÞrte vi ingen spesifikk separator, men la ganske enkelt til den nÞdvendige verdien pÄ etiketten til det endelige bildet da vi publiserte.
NBHvis du er interessert i Ä se pÄ alt som er beskrevet i werf-kildekoden, kan et utgangspunkt vÊre .
I denne artikkelen skal vi ikke legge mer vekt pĂ„ problemene og begrunnelsen for vĂ„r tilnĂŠrming: om taggingsstrategier, lagring av data i etiketter og publiseringsprosessen generelt â alt dette er beskrevet i detalj i en fersk rapport av Dmitrij Stolyarov: â'.
Ă oppsummere
Mangelen pĂ„ stĂžtte for ikke-nestede registre var ikke en blokkerende faktor for oss eller werf-brukerne vi kjenner â tross alt kan man alltid sette opp et eget bilderegister (eller bytte til et betinget containerregister i Google Cloud)... Det virket imidlertid logisk Ă„ fjerne en slik begrensning for Ă„ gjĂžre verktĂžyet praktisk for et bredere DevOps-fellesskap. Under implementeringen mĂžtte vi pĂ„ den stĂžrste vanskeligheten med Ă„ omarbeide mekanismen for rengjĂžring av containerregisteret. NĂ„ som alt er klart, er det hyggelig Ă„ innse at det har blitt enklere for noen, og vi (som hovedutviklerne av prosjektet) forventer ingen merkbare vanskeligheter med ytterligere stĂžtte for denne funksjonen.
FÞlg med, sÄ forteller vi deg om andre nyvinninger i nÊr fremtid. !
PS
Les ogsÄ pÄ bloggen vÄr:
- «";
- «'.
Kilde: www.habr.com
