Temaet monorepository har blitt diskutert mer enn en gang og forårsaker som regel veldig aktiv debatt. Oppretter Som et åpen kildekode-verktøy designet for å forbedre prosessen med å bygge applikasjonskode fra Git til Docker-bilder (og deretter levere dem til Kubernetes), tenker vi ikke mye på hvilket valg som er best. For oss er det primært å sørge for alt nødvendig for tilhengere av ulike meninger (hvis dette ikke strider mot sunn fornuft, selvfølgelig).
Den nylig introduserte støtten for mono-repo i werf er et godt eksempel på dette. Men først, la oss finne ut hvordan denne støtten generelt er relatert til bruken av werf og hva Docker Registry har å gjøre med det...
Problemer
La oss forestille oss denne situasjonen. Selskapet har mange utviklingsteam som jobber med selvstendige prosjekter. De fleste applikasjoner opererer i Kubernetes og er følgelig containeriserte. For å lagre beholdere og bilder kreves et register. Selskapet bruker Docker Hub med en enkelt konto som et slikt register. COMPANY. I likhet med de fleste kildekodelagringssystemer, Docker Hub lar deg ikke lage et nestet hierarki av depoter, som for eksempel COMPANY/PROJECT/IMAGE. I dette tilfellet... hvordan kan vi lagre ikke-monolittiske applikasjoner i registeret med denne begrensningen uten å opprette en egen konto for hvert prosjekt?
Kanskje den beskrevne situasjonen er kjent for noen fra første hånd, men la oss se på spørsmålet om organisering av applikasjonslagring generelt, dvs. uten referanse til eksemplet ovenfor og Docker Hub.
Løsninger
Hvis søknaden monolittisk, kommer i ett bilde, så oppstår ingen spørsmål og vi lagrer ganske enkelt bildene i prosjektets containerregister.
Når en applikasjon presenteres som flere komponenter, mikrotjenester, så må du velge en bestemt tilnærming. Ved å bruke eksempelet på en typisk nettapplikasjon som består av to bilder: frontend и backend - de mulige alternativene er:
- Lagre bilder i separate nestede depoter:
- Lagre alt i ett depot, og ta med bildenavnet i taggen, for eksempel som følger:
NB: Faktisk er det et annet alternativ med lagring i forskjellige depoter, PROJECT-frontend и PROJECT-backend, men vi vil ikke vurdere det på grunn av kompleksiteten i støtte, organisering og fordeling av rettigheter mellom brukere.
werf støtte
Opprinnelig var werf begrenset til nestede depoter - heldigvis støtter de fleste registre denne funksjonen. Siden versjon , lagt til arbeid med registre der nesting støttes ikke, og Docker Hub er en av dem. Fra dette øyeblikket hadde brukeren et valg om hvordan de skulle lagre applikasjonsbilder.
Implementering tilgjengelig som en del av opsjonen --images-repo-mode=multirepo|monorepo (misligholde multirepo, dvs. lagring i nestede depoter). Den definerer mønstrene som bilder lagres etter i registeret. Det er nok å velge ønsket modus når du bruker de grunnleggende kommandoene, og alt annet vil forbli uendret.
Siden de fleste werf-alternativer kan stilles inn Miljøvariabler, i CI/CD-systemer er lagringsmodusen vanligvis enkel å sette globalt for hele prosjektet. For eksempel, når det gjelder GitLab Bare legg til en miljøvariabel i prosjektinnstillingene: Innstillinger -> CI / CD -> Variabler: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Hvis vi snakker om å publisere bilder og rulle ut applikasjoner (du kan lese om disse prosessene i detalj i de relevante dokumentasjonsartiklene: и ), så bestemmer modusen utelukkende malen du kan jobbe med bildet med.
Djevelen er i detaljene
Forskjellen og hovedvanskeligheten når du legger til en ny lagringsmetode er i ferd med å rense registeret (rengjøringsfunksjoner støttet i werf, se ).
Ved rengjøring tar werf hensyn til bildene som brukes i Kubernetes-klynger, samt brukerkonfigurerte policyer. Retningslinjer er basert på å dele inn tagger i strategier. Strategier som for øyeblikket støttes:
- 3 strategier relatert til Git-primitiver som tag, branch og commit;
- 1 strategi for egendefinerte tagger.
Vi lagrer informasjon om tag-strategien når vi publiserer bildet i etikettene til det endelige bildet. Selve betydningen er den såkalte metatag — nødvendig for å anvende enkelte retningslinjer. For eksempel, når du sletter en gren eller tag fra et Git-depot, er det logisk å slette tilknyttet ubrukt bilder fra registeret, som er dekket av deler av våre retningslinjer.
Når du lagrer i ett depot (monorepo), i bildekoden, i tillegg til metakoden, kan navnet på bildet også lagres: PROJECT:frontend-META-TAG. For å skille dem, introduserte vi ikke noen spesifikk skilletegn, men la ganske enkelt den nødvendige verdien til etiketten til det endelige bildet ved publisering.
NB: Hvis du er interessert i å se på alt som er beskrevet i werf-kildekoden, kan utgangspunktet være .
I denne artikkelen vil vi ikke betale mer oppmerksomhet til problemene og begrunnelsen for vår tilnærming: om taggingstrategier, datalagring i etiketter og publiseringsprosessen generelt - alt dette er beskrevet i detalj i den nylige rapporten av Dmitry Stolyarov: "'.
Å oppsummere
Mangelen på støtte for registre uten nesting var ikke en blokkeringsfaktor for oss eller werf-brukere kjent for oss - du kan tross alt alltid opprette et eget register med bilder (eller bytte til det betingede containerregisteret i Google Cloud) ... Men , virket det logisk å fjerne en slik begrensning for å gjøre verktøyet mer praktisk for det bredere DevOps-fellesskapet. Mens vi implementerte det, møtte vi hovedproblemet med å omarbeide mekanismen for rengjøring av beholderregisteret. Nå som alt er klart, er det hyggelig å vite at det har blitt enklere for noen, og vi (som hovedutviklerne av prosjektet) ser ingen merkbare problemer med å støtte denne funksjonen ytterligere.
Bli hos oss, så vil vi snart fortelle deg om andre innovasjoner innen !
PS
Les også på bloggen vår:
- «";
- «'.
Kilde: www.habr.com