Emnet om et mono-depot er blevet diskuteret mere end én gang og forårsager som regel meget aktiv kontrovers. Ved at skabe 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), tænker vi ikke meget over, hvilket valg der er bedst. For os er det primært at sørge for alt, hvad der er nødvendigt for tilhængere af forskellige meninger (hvis dette selvfølgelig ikke strider mod 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 at bruge werf, og hvad Docker Registry har at gøre med det ...
Problemer
Lad os forestille os en sådan situation. Virksomheden har mange udviklingsteams, der arbejder med selvstændige projekter. De fleste applikationer fungerer i Kubernetes og er derfor containeriserede. For at gemme containere, billeder, skal du bruge et register (registry). 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, såsom COMPANY/PROJECT/IMAGE. I så fald... hvordan kan du 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 fra første hånd, men lad os se på spørgsmålet om at organisere applikationslagring generelt, dvs. uden henvisning til ovenstående eksempel og Docker Hub.
Løsninger
Hvis ansøgningen monolitisk, kommer i ét billede, så er der ingen spørgsmål, og vi gemmer blot billederne i projektets containerregistrering.
Når en applikation præsenteres som flere komponenter, mikrotjenester, så kræves en bestemt tilgang. Om 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 overvej f.eks. billednavnet i tagget 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.
werf støtte
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 det tidspunkt har brugeren et valg om, hvordan applikationsbillederne skal gemmes.
Implementering tilgængelig under option --images-repo-mode=multirepo|monorepo (Standard multirepo, dvs. opbevaring i indlejrede depoter). Det definerer de mønstre, som billederne gemmes efter i registreringsdatabasen. Det er nok at vælge 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. For eksempel, i tilfældet med GitLab blot 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 rensefunktioner understøttet af werf, se ).
Ved rengøring tager werf hensyn til de billeder, der bruges i Kubernetes-klynger, såvel som brugerkonfigurerede politikker. Politikker er baseret på opdelingen af tags i strategier. Strategier, der i øjeblikket understøttes:
- 3 strategier forbundet af Git-primitiver såsom tag, branch og commit;
- 1 strategi for vilkårlige brugerdefinerede tags.
Vi gemmer information om tag-strategien, når vi offentliggør billedet i etiketterne på det endelige billede. Selve betydningen er den såkaldte meta tag - Påkrævet for at anvende nogle af politikkerne. For eksempel, når du sletter en gren eller et tag fra et Git-lager, er det logisk at slette tilknyttet ubrugt billeder fra registreringsdatabasen, som er omfattet af en del af vores politikker.
Når gemt i ét lager (monorepo), i billedtagget, udover metatagget, kan navnet på billedet 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å kan udgangspunktet 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 udgivelsesprocessen som helhed - alt dette er beskrevet detaljeret i en nylig rapport af Dmitry Stolyarov: "'.
sammenfattende
Manglen på understøttelse af registre uden nesting var ikke en blokerende faktor for os eller werf-brugere kendt af os - trods alt kan du altid oprette et separat register af billeder (eller skifte til det betingede Container Registry i Google Cloud) ... Men , virkede det logisk at fjerne en sådan begrænsning for at gøre værktøjet mere bekvemt for det bredere DevOps-fællesskab. Mens vi implementerede det, stødte vi på det største problem med at omarbejde mekanismen til rengøring af containerregistret. Nu hvor alt er klar, er det rart at vide, at det er blevet lettere for nogen, og vi (som de vigtigste udviklere af projektet) forudser ikke nogen mærkbare vanskeligheder med yderligere at understøtte denne funktion.
Bliv hos os, og meget snart vil vi fortælle dig om andre innovationer inden for !
PS
Læs også på vores blog:
- «";
- «'.
Kilde: www.habr.com