{"id":96065,"date":"2020-10-07T13:42:09","date_gmt":"2020-10-07T11:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf"},"modified":"2020-10-07T13:42:09","modified_gmt":"2020-10-07T11:42:09","slug":"problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Problemet med \"smart\" rensning av containeravbilder och dess l\u00f6sning i werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Problemet
\n
\nI artikeln diskuteras problematiken kring rensning av avbilder som samlas i containerregistren (Docker Registry och dess motsvarigheter) i dagens CI\/CD-pipelines f\u00f6r cloud native-applikationer som distribueras i Kubernetes. Huvudkriterier f\u00f6r avbilders aktualitet beskrivs, liksom de sv\u00e5righeter som uppst\u00e5r vid automatisering av rensning, utnyttjande av utrymme och tillfredsst\u00e4llande av teamens behov. Slutligen, genom ett specifikt Open Source-projekt, f\u00f6rklarar vi hur dessa utmaningar kan \u00f6vervinnas.<\/p>\n

Introduktion<\/h2>\n

\nAntalet avbilder i containerregistret kan snabbt v\u00e4xa och ta upp mer utrymme i lagringen, vilket i sin tur kan \u00f6ka kostnaden avsev\u00e4rt. F\u00f6r att kontrollera, begr\u00e4nsa eller uppr\u00e4tth\u00e5lla en acceptabel tillv\u00e4xt av det utrymme som upptas i registret, g\u00f6rs f\u00f6ljande:<\/p>\n

    \n
  1. anv\u00e4nda ett fast antal taggar f\u00f6r avbilder;<\/li>\n
  2. p\u00e5 n\u00e5got s\u00e4tt rensa avbilder.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nDen f\u00f6rsta begr\u00e4nsningen \u00e4r ibland acceptabel f\u00f6r sm\u00e5 team. Om utvecklarna klarar sig med fasta taggar (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> och s\u00e5 vidare), kommer registret inte att sv\u00e4lla i storlek och under l\u00e5ng tid beh\u00f6ver man inte ens t\u00e4nka p\u00e5 rensning. Alla obeh\u00f6vliga avbilder \u00e5sidos\u00e4tts och det finns helt enkelt inget arbete kvar att g\u00f6ra f\u00f6r rensning (allt hanteras av den vanliga skr\u00e4pbilen).<\/p>\n

    Trots detta begr\u00e4nsar en s\u00e5dan strategi utvecklingen kraftigt och \u00e4r s\u00e4llan till\u00e4mpbar inom CI\/CD i moderna projekt. Automatisering har blivit en integrerad del av utvecklingsprocessen, som m\u00f6jligg\u00f6r snabbare testning, distribution och leverans av ny funktionalitet till anv\u00e4ndarna. Till exempel skapas det i alla v\u00e5ra projekt automatiskt en CI-pipeline vid varje commit. I den byggs en avbild, testas, distribueras till olika Kubernetes-milj\u00f6er f\u00f6r fels\u00f6kning och vidare kontroller, och om allt g\u00e5r bra - n\u00e5r f\u00f6r\u00e4ndringarna slutligen anv\u00e4ndaren. Detta \u00e4r inte l\u00e4ngre raketvetenskap, utan en vanlig f\u00f6reteelse f\u00f6r m\u00e5nga - f\u00f6rmodligen \u00e4ven f\u00f6r dig, eftersom du l\u00e4ser denna artikel.<\/strong>Eftersom buggar fixas och ny funktionalitet utvecklas parallellt, och med flera releaser som kan ske varje dag, \u00e4r det uppenbart att utvecklingsprocessen \u00e5tf\u00f6ljs av ett betydande antal commits, vilket inneb\u00e4r -<\/p>\n

    ett stort antal avbilder i registret. ett stort antal av bilder i registret<\/strong>. Som ett resultat uppst\u00e5r en akut fr\u00e5ga om hur man organiserar en effektiv reng\u00f6ring av registret, dvs. att ta bort inaktuella avbilder.<\/p>\n

    Men hur kan man \u00f6verhuvudtaget avg\u00f6ra om en avbild \u00e4r aktuell?<\/p>\n

    Kriterier f\u00f6r aktuell avbild<\/h2>\n

    \nI \u00f6verv\u00e4ldigande fall kommer de viktigaste kriterierna att vara f\u00f6ljande:<\/p>\n

    1. Det f\u00f6rsta (det mest uppenbara och mest kritiska av alla) \u00e4r avbilder som just nu anv\u00e4nds i Kubernetes<\/strong>. Att ta bort dessa avbilder kan leda till betydande kostnader relaterade till stillest\u00e5nd i produktionen (till exempel kan avbilder beh\u00f6vas vid replikering) eller helt enkelt f\u00f6rst\u00f6ra teamets insatser som arbetar med fels\u00f6kning p\u00e5 n\u00e5got av konturerna. (Av denna anledning har vi \u00e4ven skapat en speciell <\/i>Prometheus exporter<\/i><\/a><\/noindex>, som \u00f6vervakar avsaknaden av s\u00e5dana avbilder i alla Kubernetes-kluster.)<\/i><\/p>\n

    2. Det andra (mindre uppenbart, men ocks\u00e5 mycket viktigt och \u00e5terigen relaterat till drift) \u00e4r avbilder som kr\u00e4vs f\u00f6r att \u00e5terg\u00e5 i h\u00e4ndelse av allvarliga problem<\/strong> i den aktuella versionen. Till exempel, i fallet med Helm handlar det om avbilder som anv\u00e4nds i sparade versioner av en release. (F\u00f6r \u00f6vrigt, som standard g\u00e4ller en gr\u00e4ns p\u00e5 256 revisioner i Helm, men f\u00e5 m\u00e4nniskor har nog faktiskt behov av att spara s\u00e5 mycket<\/i> versioner?..) Faktum \u00e4r att vi, bland annat, sparar versioner s\u00e5 att vi sedan kan anv\u00e4nda dem, dvs. \"\u00e5terg\u00e5\" till dem vid behov.<\/p>\n

    3. Det tredje \u2014 utvecklarbehoven<\/strong>: alla avbilder som \u00e4r kopplade till deras nuvarande arbeten. Till exempel, om vi granskar ett PR kan det vara meningsfullt att beh\u00e5lla avbilden som motsvarar den senaste commit och, s\u00e4g, den f\u00f6reg\u00e5ende commit: p\u00e5 s\u00e5 s\u00e4tt kan utvecklaren snabbt \u00e5terv\u00e4nda till vilken uppgift som helst och arbeta med de senaste \u00e4ndringarna. <\/p>\n

    4. Det fj\u00e4rde \u2014 avbilder som motsvarar versionerna av v\u00e5r applikation<\/strong>, dvs. som \u00e4r den slutliga produkten: v1.0.0, 20.04.01, sierra osv.<\/p>\n

    NB: Kriterierna som anges h\u00e4r har formulerats utifr\u00e5n erfarenheter av samarbete med tiotals utvecklarteam fr\u00e5n olika f\u00f6retag. Men naturligtvis, beroende p\u00e5 egenskaperna i utvecklingsprocesserna och den anv\u00e4nda infrastrukturen (t.ex. om Kubernetes inte anv\u00e4nds), kan dessa kriterier variera. <\/p>\n

    \u00d6verensst\u00e4mmelse med kriterier och befintliga l\u00f6sningar<\/h2>\n

    \nPopul\u00e4ra tj\u00e4nster med container registry erbjuder vanligtvis sina egna policyer f\u00f6r rensning av bilder: i dem kan du definiera villkor under vilka en tagg tas bort fr\u00e5n registry. Men m\u00f6jligheterna med dessa villkor begr\u00e4nsas av parametrar som namn, skapelsedatum och antal taggar*.<\/p>\n

    * Beroende p\u00e5 specifika implementationer av container registry. Vi har \u00f6verv\u00e4gt m\u00f6jligheterna hos f\u00f6ljande l\u00f6sningar: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 per september 2020.<\/i><\/p>\n

    Dessa parametrar \u00e4r helt tillr\u00e4ckliga f\u00f6r att uppfylla det fj\u00e4rde kriteriet - att v\u00e4lja bilder som motsvarar versioner. Men f\u00f6r alla andra kriterier m\u00e5ste man v\u00e4lja n\u00e5gon form av kompromissl\u00f6sning (en mer strikt eller \u00e5 sin sida mer tolerant politik) - beroende p\u00e5 f\u00f6rv\u00e4ntningar och ekonomiska m\u00f6jligheter.<\/p>\n

    Till exempel kan det tredje kriteriet - som r\u00f6r utvecklarnas behov - l\u00f6sas genom att organisera processer inom team: specifik namngivning av bilder, uppr\u00e4tta speciella allow lists och interna avtal. Men i slut\u00e4ndan m\u00e5ste det \u00e4nd\u00e5 automatiseras. Och om de f\u00e4rdiga l\u00f6sningarna inte r\u00e4cker till, m\u00e5ste man g\u00f6ra n\u00e5got eget.<\/p>\n

    Situationen med de tv\u00e5 f\u00f6rsta kriterierna \u00e4r liknande: de kan inte uppfyllas utan att f\u00e5 data fr\u00e5n ett externt system - det system d\u00e4r applikationerna distribueras (i v\u00e5rt fall \u00e4r det Kubernetes).<\/p>\n

    Illustration av arbetsfl\u00f6det i Git<\/h3>\n

    \nAnta att du arbetar efter ett m\u00f6nster i Git:<\/p>\n

    \"Problemet
    \n
    \nIkonen med huvudet p\u00e5 diagrammet markerar de containerbilder som f\u00f6r n\u00e4rvarande \u00e4r distribuerade i Kubernetes f\u00f6r vissa anv\u00e4ndare (slutanv\u00e4ndare, testare, chefer etc.) eller anv\u00e4nds av utvecklare f\u00f6r debugging och liknande \u00e4ndam\u00e5l.<\/i><\/p>\n

    Vad h\u00e4nder om rensningspolicyerna till\u00e5ter att bilder kvarst\u00e5r (inte tas bort) enbart enligt angivna taggnamn<\/b>?<\/p>\n

    \"Problemet
    \n
    \nUppenbarligen blir ett s\u00e5dant scenario ingen glad.<\/p>\n

    Vad \u00e4ndras om policyerna till\u00e5ter att inte ta bort bilder enligt ett angivet tidsintervall \/ antal senaste commits<\/b>?<\/p>\n

    \"Problemet
    \n
    \nResultatet blev avsev\u00e4rt b\u00e4ttre, men \u00e4r fortfarande l\u00e5ngt ifr\u00e5n idealet. F\u00f6r vi har fortfarande utvecklare som beh\u00f6ver bilder i registret (eller till och med distribuerade i K8s) f\u00f6r att debugga buggar...<\/p>\n

    Sammanfattningsvis, den nuvarande situationen p\u00e5 marknaden: de tillg\u00e4ngliga funktionerna i containerrregister erbjuder inte tillr\u00e4cklig flexibilitet f\u00f6r rensning, och den fr\u00e4msta orsaken \u00e4r att det inte finns n\u00e5got s\u00e4tt att interagera med omv\u00e4rlden<\/strong>. Det inneb\u00e4r att team som beh\u00f6ver denna flexibilitet tvingas implementera borttagning av bilder \"utifr\u00e5n\" genom att anv\u00e4nda Docker Registry API (eller det inhemska API:et f\u00f6r den aktuella implementeringen).<\/p>\n

    Vi har dock s\u00f6kt efter en universell l\u00f6sning som automatiserar rensningen av bilder f\u00f6r olika team som anv\u00e4nder olika register\u2026<\/p>\n

    V\u00e5r v\u00e4g till universell rensning av bilder<\/h2>\n

    \nVarf\u00f6r finns det ett s\u00e5dant behov? Det \u00e4r s\u00e5 att vi inte \u00e4r en separat grupp utvecklare, utan ett team som st\u00f6djer m\u00e5nga s\u00e5dana grupper, och hj\u00e4lper till att l\u00f6sa CI\/CD-fr\u00e5gor p\u00e5 ett omfattande s\u00e4tt. Och det viktigaste tekniska verktyget f\u00f6r detta \u00e4r en Open Source-verktyg werf<\/a><\/noindex>. Dess s\u00e4rskildhet ligger i att den inte utf\u00f6r en enda funktion, utan f\u00f6ljer processerna f\u00f6r kontinuerlig leverans i alla steg: fr\u00e5n byggande till deployment.<\/p>\n

    Publiceringen av bilder i registret* (omedelbart efter deras byggande) \u00e4r en uppenbar funktion f\u00f6r ett s\u00e5dant verktyg. Eftersom bilderna lagras d\u00e4r beh\u00f6ver man, om ditt lagringsutrymme inte \u00e4r o\u00e4ndligt, ocks\u00e5 ta ansvar f\u00f6r deras efterf\u00f6ljande rensning. Hur vi lyckades med detta, och tillfredsst\u00e4llde alla angivna kriterier, kommer att diskuteras vidare.<\/p>\n

    * \u00c4ven om sj\u00e4lva registren kan vara olika (Docker Registry, GitLab Container Registry, Harbor osv.), s\u00e5 m\u00f6ter deras anv\u00e4ndare samma problem. Den universella l\u00f6sningen i v\u00e5rt fall \u00e4r oberoende av registerens implementation, eftersom den utf\u00f6rs utanf\u00f6r sj\u00e4lva registren och erbjuder samma beteende f\u00f6r alla.<\/i><\/p>\n

    Trots att vi anv\u00e4nder werf som exempel p\u00e5 implementation, hoppas vi att de anv\u00e4nda tillv\u00e4gag\u00e5ngss\u00e4tten kommer att vara anv\u00e4ndbara f\u00f6r andra team som st\u00e5r inf\u00f6r liknande sv\u00e5righeter.<\/p>\n

    S\u00e5 vi b\u00f6rjade med extern<\/i> implementeringen av en mekanism f\u00f6r att rensa bilder \u2014 ist\u00e4llet f\u00f6r de funktioner som redan \u00e4r inbyggda i registren f\u00f6r containrar. Det f\u00f6rsta steget var att anv\u00e4nda Docker Registry API f\u00f6r att skapa just dessa primitiva policyer baserade p\u00e5 antalet taggar och deras skapelsedatum (n\u00e4mnda ovan). Dessa kompletterades med en allow list baserad p\u00e5 bilder som anv\u00e4nds i den distribuerade infrastrukturen<\/strong>, dvs. Kubernetes. F\u00f6r det sistn\u00e4mnda r\u00e4ckte det att anv\u00e4nda Kubernetes API f\u00f6r att iterera \u00f6ver alla distribuerade resurser och f\u00e5 en lista med v\u00e4rden. bild<\/code>.<\/p>\n

    Denna triviala l\u00f6sning l\u00f6ste det mest kritiska problemet (kriterium nr 1), men var bara b\u00f6rjan p\u00e5 v\u00e5r v\u00e4g mot att f\u00f6rb\u00e4ttra st\u00e4dprocessen. N\u00e4sta \u2014 och mycket mer intressanta \u2014 steg var att l\u00f6sa knyta de publicerade bilderna till Git-historiken.<\/strong>.<\/p>\n

    Taggningsscheman<\/h3>\n

    \nF\u00f6r att b\u00f6rja valde vi ett tillv\u00e4gag\u00e5ngss\u00e4tt d\u00e4r den slutliga bilden skulle lagra den n\u00f6dv\u00e4ndiga informationen f\u00f6r st\u00e4dning, och vi byggde processen p\u00e5 taggningsscheman. N\u00e4r anv\u00e4ndaren publicerade en bild valde hen ett visst alternativ f\u00f6r taggning (git-gren<\/code>, git-commit<\/code> eller git-tag<\/code>) och anv\u00e4nde motsvarande v\u00e4rde. I CI-system sattes dessa v\u00e4rden automatiskt baserat p\u00e5 milj\u00f6variabler. I grund och botten s\u00e5 kn\u00f6ts den slutliga bilden till en viss Git-primitiv,<\/strong>, som lagrade n\u00f6dv\u00e4ndig data f\u00f6r st\u00e4dning i etiketter.<\/p>\n

    Inom detta tillv\u00e4gag\u00e5ngss\u00e4tt uppstod en upps\u00e4ttning policyer som gjorde det m\u00f6jligt att anv\u00e4nda Git som den enda sanningsk\u00e4llan:<\/p>\n