Emnet om en monorepo er blevet diskuteret mange gange og forårsager som regel en ret aktiv debat. Opretter Som et open source-værktøj designet til at forbedre processen med at bygge applikationskode fra Git til Docker-billeder (og derefter levere dem til Kubernetes), bruger vi ikke meget tid på at tænke på, hvad der er det bedste valg. For os er det primære at sørge for alt, hvad der er nødvendigt for tilhængere af forskellige meninger (hvis dette selvfølgelig ikke er i modstrid med sund fornuft).
werfs seneste mono-repo-støtte er et godt eksempel på dette. Men lad os først finde ud af, hvordan denne support generelt er relateret til brugen af werf, og hvad Docker Registry har med det at gøre...
Problemer
Lad os forestille os denne situation. Virksomheden har mange teams af udviklere, der arbejder på selvstændige projekter. De fleste applikationer kører i Kubernetes og er derfor containeriserede. For at gemme containere, billeder kræves et register. Virksomheden bruger Docker Hub med en enkelt konto som sådan et register. COMPANY. I lighed med de fleste kildekodelagringssystemer, Docker Hub tillader ikke indlejret lagerhierarki, som f.eks COMPANY/PROJECT/IMAGE. I så fald... hvordan kan vi gemme ikke-monolitiske applikationer i registreringsdatabasen med denne begrænsning uden at oprette en separat konto for hvert projekt?
Måske er den beskrevne situation bekendt for nogen, men lad os overveje spørgsmålet om organisering af applikationsopbevaring generelt, dvs. uden henvisning til ovenstående eksempel og Docker Hub.
Løsninger
Hvis ansøgningen monolitisk, leveres i ét billede, så opstår der ingen spørgsmål, og vi gemmer blot billederne i projektbeholderregistret.
Når en applikation præsenteres som flere komponenter, mikrotjenester, så skal der vælges en specifik tilgang. Ved at bruge eksemplet med en typisk webapplikation bestående af to billeder: frontend и backend — de mulige muligheder er:
- Gem billeder i separate indlejrede depoter:
- Gem alt i ét lager, og inkluder billednavnet i tagget, for eksempel som følger:
NB: Faktisk er der en anden mulighed med at gemme i forskellige depoter, PROJECT-frontend и PROJECT-backend, men vi vil ikke overveje det på grund af kompleksiteten af support, organisering og fordeling af rettigheder mellem brugere.
Support i werf
Oprindeligt begrænsede werf sig til indlejrede arkiver - heldigvis understøtter de fleste registre denne funktion. Siden version , tilføjet arbejde med registre, hvori indlejring er ikke understøttet, og Docker Hub er en af dem. Fra dette tidspunkt havde brugeren mulighed for at vælge, hvordan applikationsbilleder skulle gemmes.
Implementering fås som tilvalg --images-repo-mode=multirepo|monorepo (Standard multirepolagring i indlejrede lagre). Det definerer de skabeloner, som billeder gemmes i registreringsdatabasen. Vælg blot den ønskede tilstand, når du bruger de grundlæggende kommandoer, og alt andet forbliver uændret.
Da de fleste werf muligheder kan indstilles miljøvariabler, i CI/CD-systemer er lagringstilstanden normalt let at indstille globalt for hele projektet. f.eks. i tilfældet med GitLab det er nok at tilføje en miljøvariabel i projektindstillingerne: Indstillinger -> CI / CD -> Variabler: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Hvis vi taler om udgivelse af billeder og udrulning af applikationer (du kan læse om disse processer i detaljer i de relevante dokumentationsartikler: и ), så bestemmer tilstanden udelukkende skabelonen, som du kan arbejde med billedet med.
Djævelen er i detaljerne
Forskellen og den største vanskelighed, når du tilføjer en ny lagringsmetode, er i færd med at rense registreringsdatabasen (for rengøringsmuligheder understøttet af werf, se ).
Ved rengøring tager werf hensyn til de billeder, der bruges i Kubernetes-klynger, såvel som brugerkonfigurerbare politikker. Politikkerne er baseret på at opdele tags i strategier. Strategier, der i øjeblikket understøttes:
- 3 strategier relateret til Git-primitiver såsom tag, branch og commit;
- 1 strategi for tilpassede tags.
Vi gemmer tagstrategioplysninger, når vi offentliggør et billede i det endelige billedes etiketter. Selve betydningen er den såkaldte meta tag — er nødvendig for at anvende nogle politikker. For eksempel, når du sletter en gren eller tag fra et Git-lager, giver det mening også at slette de relaterede. ubrugt billeder fra registreringsdatabasen, som er omfattet af en del af vores politikker.
Når du gemmer i ét lager (monorepo), i billedtagget kan billednavnet udover metatagget også gemmes: PROJECT:frontend-META-TAG. For at adskille dem introducerede vi ikke nogen specifik separator, men tilføjede blot den nødvendige værdi til etiketten på det endelige billede ved udgivelsen.
NB: Hvis du er interesseret i at se på alt beskrevet i werf-kildekoden, så kunne et udgangspunkt være .
I denne artikel vil vi ikke være mere opmærksomme på problemerne og begrundelsen for vores tilgang: om taggingstrategier, lagring af data i etiketter og publiceringsprocessen generelt - alt dette er beskrevet detaljeret i en nylig rapport af Dmitry Stolyarov: "'.
sammenfattende
Manglen på understøttelse af ikke-indlejrede registre var ikke en blokerende faktor for os eller de werf-brugere, vi kender - du kan trods alt altid oprette et separat billedregistrering (eller skifte til et betinget Container Registry i Google Cloud)... Men at fjerne denne begrænsning virkede logisk for at gøre værktøjet praktisk for et bredere DevOps-fællesskab. Mens vi implementerede det, stødte vi på det største problem med at omarbejde mekanismen til at rense containerregistret. Nu hvor alt er klar, er det rart at indse, at nogen har fundet det nemmere, og vi (som de vigtigste udviklere af projektet) forudser ikke nogen væsentlige vanskeligheder med yderligere support af denne funktion.
Følg med, og vi vil fortælle dig om andre innovationer i den nærmeste fremtid. !
PS
Læs også på vores blog:
- «";
- «'.
Kilde: www.habr.com
