🥇Problemet med "smart" rengöring av containerbilder och dess lösning i werf

I artikeln diskuteras problematiken kring rensning av avbilder som samlas i containerregistren (Docker Registry och dess motsvarigheter) i dagens CI/CD-pipelines för cloud native-applikationer som distribueras i Kubernetes. Huvudkriterier för avbilders aktualitet beskrivs, liksom de svårigheter som uppstår vid automatisering av rensning, utnyttjande av utrymme och tillfredsställande av teamens behov. Slutligen, genom ett specifikt Open Source-projekt, förklarar vi hur dessa utmaningar kan övervinnas.

Introduktion

Antalet avbilder i containerregistret kan snabbt växa och ta upp mer utrymme i lagringen, vilket i sin tur kan öka kostnaden avsevärt. För att kontrollera, begränsa eller upprätthålla en acceptabel tillväxt av det utrymme som upptas i registret, görs följande:

använda ett fast antal taggar för avbilder;
på något sätt rensa avbilder.

Den första begränsningen är ibland acceptabel för små team. Om utvecklarna klarar sig med fasta taggar (latest, main, test, boris och så vidare), kommer registret inte att svälla i storlek och under lång tid behöver man inte ens tänka på rensning. Alla obehövliga avbilder åsidosätts och det finns helt enkelt inget arbete kvar att göra för rensning (allt hanteras av den vanliga skräpbilen).

Trots detta begränsar en sådan strategi utvecklingen kraftigt och är sällan tillämpbar inom CI/CD i moderna projekt. Automatisering har blivit en integrerad del av utvecklingsprocessen, som möjliggör snabbare testning, distribution och leverans av ny funktionalitet till användarna. Till exempel skapas det i alla våra projekt automatiskt en CI-pipeline vid varje commit. I den byggs en avbild, testas, distribueras till olika Kubernetes-miljöer för felsökning och vidare kontroller, och om allt går bra - når förändringarna slutligen användaren. Detta är inte längre raketvetenskap, utan en vanlig företeelse för många - förmodligen även för dig, eftersom du läser denna artikel.Eftersom buggar fixas och ny funktionalitet utvecklas parallellt, och med flera releaser som kan ske varje dag, är det uppenbart att utvecklingsprocessen åtföljs av ett betydande antal commits, vilket innebär -

ett stort antal avbilder i registret. ett stort antal av bilder i registret. Som ett resultat uppstår en akut fråga om hur man organiserar en effektiv rengöring av registret, dvs. att ta bort inaktuella avbilder.

Men hur kan man överhuvudtaget avgöra om en avbild är aktuell?

Kriterier för aktuell avbild

I överväldigande fall kommer de viktigaste kriterierna att vara följande:

1. Det första (det mest uppenbara och mest kritiska av alla) är avbilder som just nu används i Kubernetes. Att ta bort dessa avbilder kan leda till betydande kostnader relaterade till stillestånd i produktionen (till exempel kan avbilder behövas vid replikering) eller helt enkelt förstöra teamets insatser som arbetar med felsökning på något av konturerna. (Av denna anledning har vi även skapat en speciell Prometheus exporter, som övervakar avsaknaden av sådana avbilder i alla Kubernetes-kluster.)

2. Det andra (mindre uppenbart, men också mycket viktigt och återigen relaterat till drift) är avbilder som krävs för att återgå i händelse av allvarliga problem i den aktuella versionen. Till exempel, i fallet med Helm handlar det om avbilder som används i sparade versioner av en release. (För övrigt, som standard gäller en gräns på 256 revisioner i Helm, men få människor har nog faktiskt behov av att spara så mycket versioner?..) Faktum är att vi, bland annat, sparar versioner så att vi sedan kan använda dem, dvs. "återgå" till dem vid behov.

3. Det tredje — utvecklarbehoven: alla avbilder som är kopplade till deras nuvarande arbeten. Till exempel, om vi granskar ett PR kan det vara meningsfullt att behålla avbilden som motsvarar den senaste commit och, säg, den föregående commit: på så sätt kan utvecklaren snabbt återvända till vilken uppgift som helst och arbeta med de senaste ändringarna.

4. Det fjärde — avbilder som motsvarar versionerna av vår applikation, dvs. som är den slutliga produkten: v1.0.0, 20.04.01, sierra osv.

NB: Kriterierna som anges här har formulerats utifrån erfarenheter av samarbete med tiotals utvecklarteam från olika företag. Men naturligtvis, beroende på egenskaperna i utvecklingsprocesserna och den använda infrastrukturen (t.ex. om Kubernetes inte används), kan dessa kriterier variera.

Överensstämmelse med kriterier och befintliga lösningar

Populära tjänster med container registry erbjuder vanligtvis sina egna policyer för rensning av bilder: i dem kan du definiera villkor under vilka en tagg tas bort från registry. Men möjligheterna med dessa villkor begränsas av parametrar som namn, skapelsedatum och antal taggar*.

* Beror på specifika implementationer av container registry. Vi har övervägt möjligheterna hos följande lösningar: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - fram till september 2020.

Dessa parametrar är helt tillräckliga för att uppfylla det fjärde kriteriet - att välja bilder som motsvarar versioner. Men för alla andra kriterier måste man välja någon form av kompromisslösning (en mer strikt eller å sin sida mer tolerant politik) - beroende på förväntningar och ekonomiska möjligheter.

Till exempel kan det tredje kriteriet - som rör utvecklarnas behov - lösas genom att organisera processer inom team: specifik namngivning av bilder, upprätta speciella allow lists och interna avtal. Men i slutändan måste det ändå automatiseras. Och om de färdiga lösningarna inte räcker till, måste man göra något eget.

Situationen med de två första kriterierna är liknande: de kan inte uppfyllas utan att få data från ett externt system - det system där applikationerna distribueras (i vårt fall är det Kubernetes).

Illustration av arbetsflödet i Git

Anta att du arbetar efter ett mönster i Git:

Ikonen med huvudet på diagrammet markerar de containerbilder som för närvarande är distribuerade i Kubernetes för vissa användare (slutanvändare, testare, chefer etc.) eller används av utvecklare för debugging och liknande ändamål.

Vad händer om rensningspolicyerna tillåter att bilder kvarstår (inte tas bort) enbart enligt angivna taggnamn?

Uppenbarligen blir ett sådant scenario ingen glad.

Vad ändras om policyerna tillåter att inte ta bort bilder enligt ett angivet tidsintervall / antal senaste commits?

Resultatet blev avsevärt bättre, men är fortfarande långt ifrån idealet. För vi har fortfarande utvecklare som behöver bilder i registret (eller till och med distribuerade i K8s) för att debugga buggar...

Sammanfattningsvis, den nuvarande situationen på marknaden: de tillgängliga funktionerna i containerrregister erbjuder inte tillräcklig flexibilitet för rensning, och den främsta orsaken är att det inte finns något sätt att interagera med omvärlden. Det innebär att team som behöver denna flexibilitet tvingas implementera borttagning av bilder "utifrån" genom att använda Docker Registry API (eller det inhemska API:et för den aktuella implementeringen).

Vi har dock sökt efter en universell lösning som automatiserar rensningen av bilder för olika team som använder olika register…

Vår väg till universell rensning av bilder

Varför finns det ett sådant behov? Det är så att vi inte är en separat grupp utvecklare, utan ett team som stödjer många sådana grupper, och hjälper till att lösa CI/CD-frågor på ett omfattande sätt. Och det viktigaste tekniska verktyget för detta är en Open Source-verktyg werf. Dess särskildhet ligger i att den inte utför en enda funktion, utan följer processerna för kontinuerlig leverans i alla steg: från byggande till deployment.

Publiceringen av bilder i registret* (omedelbart efter deras byggande) är en uppenbar funktion för ett sådant verktyg. Eftersom bilderna lagras där behöver man, om ditt lagringsutrymme inte är oändligt, också ta ansvar för deras efterföljande rensning. Hur vi lyckades med detta, och tillfredsställde alla angivna kriterier, kommer att diskuteras vidare.

* Även om själva registren kan vara olika (Docker Registry, GitLab Container Registry, Harbor osv.), så möter deras användare samma problem. Den universella lösningen i vårt fall är oberoende av registerens implementation, eftersom den utförs utanför själva registren och erbjuder samma beteende för alla.

Trots att vi använder werf som exempel på implementation, hoppas vi att de använda tillvägagångssätten kommer att vara användbara för andra team som står inför liknande svårigheter.

Så vi började med extern implementeringen av en mekanism för att rensa bilder — istället för de funktioner som redan är inbyggda i registren för containrar. Det första steget var att använda Docker Registry API för att skapa just dessa primitiva policyer baserade på antalet taggar och deras skapelsedatum (nämnda ovan). Dessa kompletterades med en allow list baserad på bilder som används i den distribuerade infrastrukturen, dvs. Kubernetes. För det sistnämnda räckte det att använda Kubernetes API för att iterera över alla distribuerade resurser och få en lista med värden. bild.

Denna triviala lösning löste det mest kritiska problemet (kriterium nr 1), men var bara början på vår väg mot att förbättra städprocessen. Nästa — och mycket mer intressanta — steg var att lösa knyta de publicerade bilderna till Git-historiken..

Taggningsscheman

För att börja valde vi ett tillvägagångssätt där den slutliga bilden skulle lagra den nödvändiga informationen för städning, och vi byggde processen på taggningsscheman. När användaren publicerade en bild valde hen ett visst alternativ för taggning (git-gren, git-commit eller git-tag) och använde motsvarande värde. I CI-system sattes dessa värden automatiskt baserat på miljövariabler. I grund och botten så knöts den slutliga bilden till en viss Git-primitiv,, som lagrade nödvändig data för städning i etiketter.

Inom detta tillvägagångssätt uppstod en uppsättning policyer som gjorde det möjligt att använda Git som den enda sanningskällan:

Vid borttagning av en gren/tagg i Git togs även de relaterade bilderna automatiskt bort från registret.
Antalet bilder kopplade till Git-taggar och commits kunde regleras med antalet taggar som användes i den valda schemat, samt tidpunkten för den relaterade committen.

Överlag uppfyllde den resulterande implementationen våra behov, men snart väntade en ny utmaning. Problemet var att under tiden vi använde taggningsscheman baserade på Git-primitiver stötte vi på ett antal nackdelar. (Eftersom deras beskrivning går utanför ämnet för denna artikel, kan alla intresserade få detaljerna här.) Därför, efter att ha beslutat att gå över till ett mer effektivt tillvägagångssätt för taggning (innehållsbaserad taggning), var vi tvungna att ompröva även vår städimplementation.

Den nya algoritmen

Varför? Vid taggning inom ramen för innehållsbaserad kan varje tagg motsvara flera commits i Git. Vid städning av bilder kan man inte längre utgå bara från committen där den nya taggen lades till i registret.

För den nya städalgoritmen beslutades det att lämna taggningsscheman och bygga processen på meta-bilder,, där varje bild lagrar en koppling av:

commit som publiceringen utfördes (det spelar ingen roll om bilden lades till, ändrades eller förblev densamma i containerregistret);
och vår interna identifierare som motsvarar den byggda bilden.

Med andra ord, säkerställdes kopplingen mellan de publicerade etiketterna och commits i Git..

Den slutgiltiga konfigurationen och den övergripande algoritmen

Användare i konfigurationen av städningen har nu tillgång till policys som avgör hur aktuella bilder väljs. Varje sådan policy definieras av:

ett antal referenser, dvs. Git-taggar eller Git-grenar, som används vid skanning;
och en gräns för antalet bilder som ska sökas för varje referens från mängden.

Som en illustration — så här har konfigurationen av standardpolicys sett ut:

cleanup:
  keepPolicies:
  - references:
      tag: /.* /
      limit:
        last: 10
  - references:
      branch: /.* /
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

Denna konfiguration innehåller tre policys som motsvarar följande regler:

Behåll bilden för de 10 senaste Git-taggarna (baserat på datum för taggning).
Behåll högst 2 bilder publicerade under den senaste veckan för högst 10 grenar som haft aktivitet den senaste veckan.
Behåll 10 bilder för grenarna main, staging och production.

Den slutgiltiga algoritmen sammanfattas i följande steg:

Inhämta manifest från container-registret.
Exkludera bilder som används i Kubernetes, eftersom vi redan har filtrerat ut dem genom att fråga K8s API.
Skanna Git-historiken och exkludera bilder enligt de angivna policys.
Ta bort de återstående bilderna.

Återgår vi till vår illustration, så här ser det ut med werf:

Men även om du inte använder werf, kan en liknande metod för avancerad städning av bilder — i en eller annan implementation (enligt den föredragna metoden för attetagningar av bilder) — tillämpas i andra system/verktyg. Det är nog att komma ihåg de problem som uppstår och hitta de möjligheter i din stack som låter dig integrera deras lösning så smidigt som möjligt. Vi hoppas att den väg vi har gått kan hjälpa dig att se på ditt specifika fall med nya detaljer och tankar.

Slutsats

Så småningom möter nästan alla team problemet med att register blir överfulla.
Vid sökandet efter lösningar är det först och främst nödvändigt att fastställa kriterierna för relevansen av bilden.
Verktygen som erbjuds av populära container registry-tjänster gör det möjligt att organisera en mycket enkel rengöring, som inte tar hänsyn till "den yttre världen": bilder som används i Kubernetes och särskildheterna i arbetsflöden inom teamet.
En flexibel och effektiv algoritm måste ha en uppfattning om CI/CD-processer och hantera inte bara data från Docker-bilder.