{"id":37667,"date":"2019-10-31T22:18:58","date_gmt":"2019-10-31T19:18:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry\/"},"modified":"2019-10-31T22:18:58","modified_gmt":"2019-10-31T19:18:58","slug":"podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Underst\u00f8ttelse af monorepo og multirepo i werf og hvad Docker Registry har at g\u00f8re med det","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Underst\u00f8ttelse
\n
\nEmnet af monorepo er blevet diskuteret mange gange og skaber som regel en del aktive debatter. N\u00e5r vi skaber werf<\/a><\/noindex> som et open source-v\u00e6rkt\u00f8j designet til at forbedre byggeprocesserne af applikationskode fra Git til Docker-images (og deres efterf\u00f8lgende levering til Kubernetes), t\u00e6nker vi sj\u00e6ldent over, hvilket valg der er bedst. For os er det prim\u00e6rt at sikre alt det n\u00f8dvendige for tilh\u00e6ngere af forskellige meninger (hvis det selvf\u00f8lgelig ikke strider imod sund fornuft).<\/p>\n

Den nyligt tilf\u00f8jede st\u00f8tte til mono-repo i werf er et godt eksempel p\u00e5 dette. Men f\u00f8rst lad os tage et kig p\u00e5, hvordan denne st\u00f8tte overhovedet h\u00e6nger sammen med brugen af werf og hvilken rolle Docker Registry spiller...<\/a><\/noindex><\/p>\n

Problematikken<\/h2>\n

\nForestil dig f\u00f8lgende situation. Virksomheden har mange udviklingsteams, der arbejder p\u00e5 uafh\u00e6ngige projekter. De fleste applikationer k\u00f8rer p\u00e5 Kubernetes og er derfor containeriserede. For opbevaring af containere og billeder kr\u00e6ves der et register. Virksomheden bruger Docker Hub med en enkelt konto COMPANY<\/code>. Ligesom de fleste systems til opbevaring af kildekode, tillader Docker Hub ikke oprettelse af indlejrede hierarkier af repositories<\/b>, som f.eks. COMPANY\/PROJECT\/IMAGE<\/code>. I s\u00e5 fald\u2026 hvordan opbevarer man ikke-monolitiske applikationer i registreret uden at oprette en separat konto for hvert projekt? <\/p>\n

\"Underst\u00f8ttelse
\n
\nM\u00e5ske er den beskrevne situation velkendt for nogle, men lad os se p\u00e5 sp\u00f8rgsm\u00e5let om organisering af opbevaring af applikationer generelt, alts\u00e5 uden at knytte det til det ovenfor beskrevne eksempel og Docker Hub.<\/p>\n

Muligheder for l\u00f8sning<\/h3>\n

\nHvis en applikation er monolitisk<\/b>, leveres i \u00e9t billede, opst\u00e5r der ikke sp\u00f8rgsm\u00e5l, og vi gemmer blot billederne i projektets containerregister.<\/p>\n

N\u00e5r applikationen er pr\u00e6senteret som flere komponenter, mikrotjenester<\/b>, kr\u00e6ves der at v\u00e6lge en bestemt tilgang. Tag et typisk web-applikations eksempel, der best\u00e5r af to billeder: frontend<\/code> og backend<\/code> \u2014 mulige muligheder er:<\/p>\n

    \n
  1. Opbevar billeder i separate indlejrede repositories:\n

    \"Underst\u00f8ttelse<\/li>\n

  2. Opbevar alt i \u00e9t repository, og s\u00f8rg for at tage billednavnet i betragtning i tagget, for eksempel p\u00e5 f\u00f8lgende m\u00e5de:\n

    \"Underst\u00f8ttelse<\/li>\n<\/ol>\n

    \nNB<\/b>: Faktisk er der ogs\u00e5 en mulighed for at gemme i forskellige repositories, PROJECT-frontend<\/code> og PROJECT-backend<\/code>, men den vil vi ikke overveje p\u00e5 grund af kompleksiteten ved support, organisering og fordeling af rettigheder blandt brugerne.<\/i><\/p>\n

    St\u00f8tte i werf<\/h2>\n

    \nOprindeligt begr\u00e6nsede werf sig til nestede repositories - heldigvis underst\u00f8tter de fleste registre denne mulighed. Fra version v1.0.4-alpha.3<\/a><\/noindex>, er der tilf\u00f8jet support for registre, der ikke underst\u00f8tter indlejring<\/b>, herunder Docker Hub. Fra dette tidspunkt havde brugeren valget om, hvordan applikationsbilleder skulle opbevares.<\/p>\n

    Implementeringen er tilg\u00e6ngelig under indstillingen --images-repo-mode=multirepo|monorepo<\/code> (som standard multirepo<\/code>, dvs. opbevaring i nestede repositories). Den definerer skabelonerne, hvormed billeder opbevares i registrene. Det er tilstr\u00e6kkeligt at v\u00e6lge den \u00f8nskede tilstand ved brug af hovedkommandoerne, mens alt andet forbliver u\u00e6ndret.<\/p>\n

    Da de fleste werf-indstillinger kan angives via milj\u00f8variabler<\/b>, kan opbevaringsmetoden i CI\/CD-systemer typisk let indstilles globalt for hele projektet. For eksempel, i tilf\u00e6lde af GitLab.<\/b> Det er tilstr\u00e6kkeligt at tilf\u00f8je en milj\u00f8variabel i projektindstillingerne: Indstillinger -> CI \/ CD -> Variabler: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    N\u00e5r man taler om publicering af billeder og udrulning af applikationer (disse processer kan l\u00e6ses detaljeret i de relevante artikler i dokumentationen: Publiceringsproces<\/a><\/noindex> og Udrulningsproces<\/a><\/noindex>), s\u00e5 definerer tilstanden udelukkende skabelonen, hvormed man kan arbejde med et billede.<\/p>\n

    Dj\u00e6vlen ligger i detaljerne<\/h3>\n

    \nForskellen og den prim\u00e6re kompleksitet ved at tilf\u00f8je en ny opbevaringsmetode ligger i processen med at rense registry. (mulighederne for reng\u00f8ring, der underst\u00f8ttes i werf, se i Reng\u00f8ringsproces<\/a><\/noindex>)<\/i>.<\/p>\n

    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\u00e5r i opdelingen af tags i strategier. Strategier, der i \u00f8jeblikket underst\u00f8ttes:<\/p>\n

      \n
    1. 3 strategier relateret til Git-primitiver som tag, gren og commit;<\/li>\n
    2. 1 strategi til vilk\u00e5rlige brugerdefinerede tags.<\/li>\n<\/ol>\n

      \nInformation om tag-strategien gemmes, n\u00e5r der publiceres et billede i etiketterne p\u00e5 det f\u00e6rdige billede. Selve v\u00e6rdien - den s\u00e5kaldte metatag<\/b> - er n\u00f8dvendig for at anvende nogle politikker. For eksempel, n\u00e5r man sletter en gren eller tag fra Git-repositoriet, giver det mening at slette de relaterede ubrugte<\/i> billeder fra registrene, hvilket d\u00e6kkes af dele af vores politikker.<\/p>\n

      N\u00e5r man gemmer i \u00e9t repository (monorepo<\/code>), kan der i billedtagget, udover metatagget, ogs\u00e5 gemmes navnet p\u00e5 billedet: PROJEKT:frontend<\/b>-META-TAG<\/code>. For deres adskillelse anvendte vi ikke en specifik separator, men tilf\u00f8jede blot den n\u00f8dvendige v\u00e6rdi til etiketten af det endelige billede ved offentligg\u00f8relsen.<\/p>\n

      NB<\/b>: Hvis du er interesseret i at se p\u00e5 alt det, der er beskrevet i kildekoden til werf, kan udgangspunktet v\u00e6re PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      I denne artikel vil vi ikke bruge mere tid p\u00e5 problematikken og begrundelsen for vores tilgang: strategier for tagging, datalagring i etiketter og selve publiceringsprocessen \u2014 alt dette er beskrevet i en nylig rapport af Dmitriy Stolyarov: \"werf \u2014 vores v\u00e6rkt\u00f8j til CI\/CD i Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Sammenfatning<\/h2>\n

      \nManglen p\u00e5 underst\u00f8ttelse af registreringer uden indlejring var ikke en blocker for os eller de kendte brugere af werf \u2014 for man kan altid oprette et separat billedregister (eller skifte til en type Container Registry i Google Cloud)\u2026 Men at fjerne en s\u00e5dan begr\u00e6nsning virkede logisk for at g\u00f8re v\u00e6rkt\u00f8jet mere anvendeligt for det bredere DevOps-samfund. Mens vi implementerede det, st\u00f8dte vi p\u00e5 den st\u00f8rste udfordring ved at omarbejde mekanismen til reng\u00f8ring 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\u00e6re udviklere af projektet) ikke ser nogen v\u00e6sentlige vanskeligheder i at st\u00f8tte denne funktion fremover.<\/p>\n

      Bliv hos os, og snart vil vi fort\u00e6lle om andre nye funktioner i werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n