🥇Stöd för monorepo och multirepo i werf och vad har Docker Registry med det att göra

Ämnet om ett mono-förvar har diskuterats mer än en gång och orsakar som regel mycket aktiva kontroverser. Genom att skapa werf som ett verktyg med öppen källkod designat för att förbättra processen att bygga applikationskod från Git till Docker-bilder (och sedan leverera dem till Kubernetes), tänker vi inte så mycket på vilket val som är bäst. För oss är det primärt att tillhandahålla allt som behövs för anhängare av olika åsikter (om detta inte strider mot sunt förnuft förstås).

werfs senaste mono-repo-stöd är ett bra exempel på detta. Men först, låt oss ta reda på hur detta stöd i allmänhet är relaterat till att använda werf och vad Docker Registry har att göra med det ...

frågor

Låt oss föreställa oss en sådan situation. Företaget har många utvecklingsteam som arbetar med självständiga projekt. De flesta applikationer körs på Kubernetes och är därför containeriserade. För att lagra behållare, bilder behöver du ett register (register). Som ett sådant register använder företaget Docker Hub med ett enda konto COMPANY. I likhet med de flesta källkodslagringssystem, Docker Hub tillåter inte kapslad lagringshierarki, Till exempel COMPANY/PROJECT/IMAGE. I så fall... hur kan du lagra icke-monolitiska applikationer i registret med denna begränsning utan att skapa ett separat konto för varje projekt?

Kanske är den beskrivna situationen bekant för någon, men låt oss överväga frågan om att organisera applikationslagring i allmänhet, d.v.s. utan hänvisning till ovanstående exempel och Docker Hub.

Lösningar

Om ansökan monolitisk, kommer i en bild, då finns det inga frågor och vi sparar helt enkelt bilderna i projektets containerregister.

När en applikation presenteras som flera komponenter, mikrotjänster, då krävs ett visst tillvägagångssätt. Om exemplet med en typisk webbapplikation som består av två bilder: frontend и backend - de möjliga alternativen är:

Lagra bilder i separata kapslade arkiv:
Lagra allt i ett arkiv och överväg bildnamnet i taggen, till exempel enligt följande:

NB: Det finns faktiskt ett annat alternativ med att spara i olika arkiv, PROJECT-frontend и PROJECT-backend, men vi kommer inte att överväga det på grund av komplexiteten i support, organisation och distribution av rättigheter mellan användare.

werf stöd

Inledningsvis begränsade werf sig till kapslade arkiv - lyckligtvis stöder de flesta register denna funktion. Från version v1.0.4-alfa.3, lagt till arbete med register där kapsling stöds inte, och Docker Hub är en av dem. Från den tidpunkten har användaren ett val av hur applikationsbilderna ska lagras.

Implementering tillgänglig under option --images-repo-mode=multirepo|monorepo (standard multirepo, dvs. lagring i kapslade arkiv). Det definierar mönster som bilder lagras i registret. Det räcker att välja önskat läge när du använder de grundläggande kommandona, och allt annat kommer att förbli oförändrat.

Eftersom de flesta werf-alternativ kan ställas in Miljövariabler, i CI/CD-system är lagringsläget vanligtvis lätt att ställa in globalt för hela projektet. Till exempel, i fallet med GitLab lägg bara till en miljövariabel i projektinställningarna: Inställningar -> CI / CD -> Variabler: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Om vi pratar om att publicera bilder och rulla ut applikationer (du kan läsa om dessa processer i detalj i relevanta dokumentationsartiklar: Publiceringsprocess и Implementeringsprocess), då bestämmer läget enbart mallen som du kan arbeta med bilden med.

Djävulen är i detaljerna

Skillnaden och den största svårigheten när du lägger till en ny lagringsmetod är att rengöra registret (för rensningsfunktioner som stöds av werf, se Rengöringsprocess).

Vid rengöring tar werf hänsyn till bilderna som används i Kubernetes-kluster, såväl som policyer som konfigurerats av användaren. Policyer baseras på indelningen av taggar i strategier. Strategier som stöds för närvarande:

3 strategier länkade av Git-primitiver som tagg, gren och commit;
1 strategi för godtyckliga anpassade taggar.

Vi sparar information om taggstrategin när vi publicerar bilden i den slutliga bildens etiketter. Själva innebörden är den sk metatagg - Krävs för att tillämpa vissa av policyerna. Till exempel, när du tar bort en gren eller tagg från ett Git-förråd är det logiskt att ta bort relaterade oanvänd bilder från registret, som omfattas av en del av våra policyer.

När det sparas i ett arkiv (monorepo), i bildtaggen, förutom metataggen, kan bildens namn också lagras: PROJECT:frontend-META-TAG. För att separera dem introducerade vi inte någon specifik separator, utan lade helt enkelt det nödvändiga värdet till etiketten på den slutliga bilden vid publicering.

NB: Om du är intresserad av att titta på allt som beskrivs i werf-källkoden, kan utgångspunkten vara PR 1684.

I den här artikeln kommer vi inte att ägna mer uppmärksamhet åt problemen och motiveringen av vårt tillvägagångssätt: om taggningsstrategier, lagring av data i etiketter och publiceringsprocessen som helhet - allt detta beskrivs i detalj i en färsk rapport av Dmitry Stolyarov: "werf är vårt verktyg för CI/CD i Kubernetes".

För att sammanfatta

Bristen på stöd för ohnestade register var inte en blockerande faktor för oss eller de werf-användare som vi känner till - trots allt kan du alltid skapa ett separat bildregister (eller byta till ett villkorat Container Registry i Google Cloud) ... Men, att ta bort en sådan begränsning verkade logiskt för att verktyget skulle vara bekvämare för det bredare DevOps-communityt. Genom att implementera det stod vi inför den största svårigheten att omarbeta mekanismen för rensning av behållarregistret. Nu när allt är klart är det skönt att inse att det har blivit lättare för någon, och vi (som huvudutvecklarna av projektet) kommer inte att ha några märkbara svårigheter att ytterligare stödja denna funktion.

Stanna hos oss så kommer vi snart att berätta om andra innovationer inom werf!