Emnet af monorepo er blevet diskuteret mange gange og skaber som regel en del aktive debatter. Når vi skaber som et open source-værktøj designet til at forbedre byggeprocesserne af applikationskode fra Git til Docker-images (og deres efterfølgende levering til Kubernetes), tænker vi sjældent over, hvilket valg der er bedst. For os er det primært at sikre alt det nødvendige for tilhængere af forskellige meninger (hvis det selvfølgelig ikke strider imod sund fornuft).
Den nyligt tilføjede støtte til mono-repo i werf er et godt eksempel på dette. Men først lad os tage et kig på, hvordan denne støtte overhovedet hænger sammen med brugen af werf og hvilken rolle Docker Registry spiller...
Problematikken
Forestil dig følgende situation. Virksomheden har mange udviklingsteams, der arbejder på uafhængige projekter. De fleste applikationer kører på Kubernetes og er derfor containeriserede. For opbevaring af containere og billeder kræves der et register. Virksomheden bruger Docker Hub med en enkelt konto COMPANY. Ligesom de fleste systems til opbevaring af kildekode, tillader Docker Hub ikke oprettelse af indlejrede hierarkier af repositories, som f.eks. COMPANY/PROJECT/IMAGE. I så fald… hvordan opbevarer man ikke-monolitiske applikationer i registreret uden at oprette en separat konto for hvert projekt?
Måske er den beskrevne situation velkendt for nogle, men lad os se på spørgsmålet om organisering af opbevaring af applikationer generelt, altså uden at knytte det til det ovenfor beskrevne eksempel og Docker Hub.
Muligheder for løsning
Hvis en applikation er monolitisk, leveres i ét billede, opstår der ikke spørgsmål, og vi gemmer blot billederne i projektets containerregister.
Når applikationen er præsenteret som flere komponenter, mikrotjenester, kræves der at vælge en bestemt tilgang. Tag et typisk web-applikations eksempel, der består af to billeder: frontend og backend — mulige muligheder er:
- Opbevar billeder i separate indlejrede repositories:
- Opbevar alt i ét repository, og sørg for at tage billednavnet i betragtning i tagget, for eksempel på følgende måde:
NB: Faktisk er der også en mulighed for at gemme i forskellige repositories, PROJECT-frontend og PROJECT-backend, men den vil vi ikke overveje på grund af kompleksiteten ved support, organisering og fordeling af rettigheder blandt brugerne.
Støtte i werf
Oprindeligt begrænsede werf sig til nestede repositories - heldigvis understøtter de fleste registre denne mulighed. Fra version , er der tilføjet support for registre, der ikke understøtter indlejring, herunder Docker Hub. Fra dette tidspunkt havde brugeren valget om, hvordan applikationsbilleder skulle opbevares.
Implementeringen er tilgængelig under indstillingen --images-repo-mode=multirepo|monorepo (som standard multirepo, dvs. opbevaring i nestede repositories). Den definerer skabelonerne, hvormed billeder opbevares i registrene. Det er tilstrækkeligt at vælge den ønskede tilstand ved brug af hovedkommandoerne, mens alt andet forbliver uændret.
Da de fleste werf-indstillinger kan angives via miljøvariabler, kan opbevaringsmetoden i CI/CD-systemer typisk let indstilles globalt for hele projektet. For eksempel, i tilfælde af GitLab. Det er tilstrækkeligt at tilføje en miljøvariabel i projektindstillingerne: Indstillinger -> CI / CD -> Variabler: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Når man taler om publicering af billeder og udrulning af applikationer (disse processer kan læses detaljeret i de relevante artikler i dokumentationen: og ), så definerer tilstanden udelukkende skabelonen, hvormed man kan arbejde med et billede.
Djævlen ligger i detaljerne
Forskellen og den primære kompleksitet ved at tilføje en ny opbevaringsmetode ligger i processen med at rense registry. (mulighederne for rengøring, der understøttes i werf, se i ).
Ved oprydning tager werf hensyn til de billeder, der bruges i Kubernetes-klynger, samt de politikker, der er konfigureret af brugeren. Grundlaget for politikkerne består i opdelingen af tags i strategier. Strategier, der i øjeblikket understøttes:
- 3 strategier relateret til Git-primitiver som tag, gren og commit;
- 1 strategi til vilkårlige brugerdefinerede tags.
Information om tag-strategien gemmes, når der publiceres et billede i etiketterne på det færdige billede. Selve værdien - den såkaldte metatag - er nødvendig for at anvende nogle politikker. For eksempel, når man sletter en gren eller tag fra Git-repositoriet, giver det mening at slette de relaterede ubrugte billeder fra registrene, hvilket dækkes af dele af vores politikker.
Når man gemmer i ét repository (monorepo), kan der i billedtagget, udover metatagget, også gemmes navnet på billedet: PROJEKT:frontend-META-TAG. For deres adskillelse anvendte vi ikke en specifik separator, men tilføjede blot den nødvendige værdi til etiketten af det endelige billede ved offentliggørelsen.
NB: Hvis du er interesseret i at se på alt det, der er beskrevet i kildekoden til werf, kan udgangspunktet være .
I denne artikel vil vi ikke bruge mere tid på problematikken og begrundelsen for vores tilgang: strategier for tagging, datalagring i etiketter og selve publiceringsprocessen — alt dette er beskrevet i en nylig rapport af Dmitriy Stolyarov: "».
Sammenfatning
Manglen på understøttelse af registreringer uden indlejring var ikke en blocker for os eller de kendte brugere af werf — for man kan altid oprette et separat billedregister (eller skifte til en type Container Registry i Google Cloud)… Men at fjerne en sådan begrænsning virkede logisk for at gøre værktøjet mere anvendeligt for det bredere DevOps-samfund. Mens vi implementerede det, stødte vi på den største udfordring ved at omarbejde mekanismen til rengøring af containerregisteret. Nu, hvor alt er klar, er det rart at vide, at det er blevet lettere for nogen, og at vi (som de primære udviklere af projektet) ikke ser nogen væsentlige vanskeligheder i at støtte denne funktion fremover.
Bliv hos os, og snart vil vi fortælle om andre nye funktioner i !
P.S.
Læs også på vores blog:
- «»;
- «».
Kilde: habr.com
