{"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\/da\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Problemet med \"intelligent\" oprydning af containerbilleder og l\u00f8sningen i werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Problemet
\n
\nArtiklen diskuterer problematikken omkring rydning af billeder, der ophobes i containerregistere (Docker Registry og lignende) i realiteten af moderne CI\/CD-pipelines til cloud native-applikationer, der leveres til Kubernetes. Der gives en oversigt over de vigtigste kriterier for relevans af billeder og de f\u00f8lgende vanskeligheder ved automatisering af rydning, pladsering og opfyldelse af teamenes behov. Endelig vil vi p\u00e5 baggrund af et specifikt Open Source-projekt forklare, hvordan man kan overvinde disse vanskeligheder.<\/p>\n

Introduktion<\/h2>\n

\nAntallet af billeder i containerregistret kan hurtigt vokse, hvilket optager mere plads i lageret og dermed \u00f8ger omkostningerne betydeligt. For at kontrollere, begr\u00e6nse eller opretholde en acceptabel v\u00e6kst af den plads, der bruges i registreret, er det almindeligt at:<\/p>\n

    \n
  1. bruge et fast antal tags til billeder;<\/li>\n
  2. rydde billeder p\u00e5 en eller anden m\u00e5de.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nDen f\u00f8rste begr\u00e6nsning er nogle gange acceptabel for sm\u00e5 teams. Hvis udviklerne klarer sig med faste tags (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> og s\u00e5 videre), vil registret ikke vokse i st\u00f8rrelse, og man kan i lang tid slet ikke bekymre sig om rydning. For alle irrelevante billeder overskrives, s\u00e5 der for rydning simpelthen ikke er noget arbejde (alt g\u00f8res af den indbyggede affaldscollector).<\/p>\n

    Alligevel begr\u00e6nser denne tilgang udviklingen betydeligt og er sj\u00e6ldent anvendelig i moderne CI\/CD-oplevelser. En uundg\u00e5elig del af udviklingen er automatisering<\/strong>, som g\u00f8r det muligt at teste, implementere og levere ny funktionalitet til brugerne meget hurtigere. For eksempel oprettes der i alle vores projekter automatisk en CI-pipeline ved hvert commit. Her samles et billede, testes, deployeres til forskellige Kubernetes-milj\u00f8er for fejlfinding og resterende checks, og hvis alt g\u00e5r godt, n\u00e5r \u00e6ndringerne frem til den endelige bruger. Og det er ikke l\u00e6ngere raketvidenskab, men en hverdag for mange \u2013 sandsynligvis ogs\u00e5 for dig, siden du l\u00e6ser denne artikel.<\/p>\n

    Da fejlrettelse og udvikling af ny funktionalitet foreg\u00e5r parallelt, og udgivelser kan finde sted flere gange om dagen, er det \u00e5benlyst, at udviklingsprocessen ledsages af et v\u00e6sentligt antal commits, og dermed \u2013 et stort antal billeder i registreret<\/strong>. Som resultat opst\u00e5r der et presserende sp\u00f8rgsm\u00e5l om, hvordan man effektivt organiserer rydning af registreret, dvs. sletning af irrelevante billeder.<\/p>\n

    Men hvordan bestemmer man overhovedet, om et billede er aktuelt?<\/p>\n

    Relevanskriterier for billeder<\/h2>\n

    \nI langt de fleste tilf\u00e6lde vil de prim\u00e6re kriterier v\u00e6re som f\u00f8lger:<\/p>\n

    1. Det f\u00f8rste (det mest \u00e5benlyse og det mest kritiske af alle) \u2014 er billederne, der er i \u00f8jeblikket i brug i Kubernetes<\/strong>. Fjernelse af disse billeder kan f\u00f8re til alvorlige omkostninger p\u00e5 grund af nedetid i produktionen (for eksempel kan billederne v\u00e6re n\u00f8dvendige ved replikation) eller aflyse bestr\u00e6belserne fra teamet, der arbejder med fejlfinding p\u00e5 en af konturerne. (Af denne grund har vi endda lavet en s\u00e6rlig <\/i>Prometheus-export\u00f8r<\/i><\/a><\/noindex>, som overv\u00e5ger frav\u00e6ret af s\u00e5danne billeder i enhver Kubernetes-klynge.)<\/i><\/p>\n

    2. Det andet (mindre \u00e5benlyse, men ogs\u00e5 meget vigtige og igen relaterer sig til driften) \u2014 er billederne, der er n\u00f8dvendige for at rulle tilbage i tilf\u00e6lde af alvorlige problemer<\/strong> i den nuv\u00e6rende version. For eksempel, i tilf\u00e6lde af Helm er det billederne, der anvendes i de gemte versioner af udgivelsen. (Desuden, som standard i Helm er der en gr\u00e6nse p\u00e5 256 revisioner, men sj\u00e6ldent vil nogen virkelig have brug for at bevare s\u00e5dan<\/i> et stort antal versioner?..) For netop det form\u00e5l gemmer vi versioner, s\u00e5 de kan bruges senere, dvs. at \"rulle tilbage\" til dem ved behov.<\/p>\n

    3. Det tredje \u2014 udviklernes behov<\/strong>: alle billeder, der relaterer sig til deres aktuelle arbejde. For eksempel, hvis vi betragter en PR, giver det mening at beholde det billede, der svarer til den seneste commit samt den forrige commit: s\u00e5ledes kan udvikleren hurtigt vende tilbage til enhver opgave og arbejde med de seneste \u00e6ndringer. <\/p>\n

    4. Det fjerde \u2014 billederne, der svarer til versionerne af vores applikation<\/strong>, dvs. er det endelige produkt: v1.0.0, 20.04.01, sierra osv.<\/p>\n

    NB: De kriterier, der er formuleret her, er baseret p\u00e5 erfaring fra samarbejdet med adskillige udviklingsteams fra forskellige virksomheder. Men selvf\u00f8lgelig kan disse kriterier variere afh\u00e6ngigt af s\u00e6regenhederne i udviklingsprocesserne og den anvendte infrastruktur (f.eks. hvis Kubernetes ikke bruges). <\/p>\n

    Overholdelse af kriterierne og eksisterende l\u00f8sninger<\/h2>\n

    \nPopul\u00e6re tjenester med container registry tilbyder som regel deres politikker for oprydning af billeder: i dem kan du definere betingelserne, under hvilke en tag fjernes fra registreringen. Men mulighederne for disse betingelser begr\u00e6nses af parametre som navne, oprettelsestidspunkt og antal tags*.<\/p>\n

    * Afh\u00e6nger af de specifikke implementeringer af containerregistrering. Vi har unders\u00f8gt mulighederne for f\u00f8lgende l\u00f8sninger: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 pr. september 2020.<\/i><\/p>\n

    Denne samling af parametre er helt tilstr\u00e6kkelig til at opfylde det fjerde kriterium \u2014 det vil sige at v\u00e6lge billeder, der svarer til versioner. Men for alle andre kriterier skal man finde en kompromisl\u00f8sning (mere streng eller derimod g\u00e6ngs politik) \u2014 afh\u00e6ngigt af forventninger og \u00f8konomiske muligheder.<\/p>\n

    For eksempel kan det tredje kriterium \u2014 relateret til udviklernes behov \u2014 l\u00f8ses ved at organisere processer inden for teamerne: specifik navngivning af billeder, f\u00f8ring af specielle allow lists og interne aftaler. Men i sidste ende skal det stadig automatiseres. Hvis de eksisterende l\u00f8sninger ikke er tilstr\u00e6kkelige, er man n\u00f8dt til at lave noget eget.<\/p>\n

    Det samme g\u00e6lder de to f\u00f8rste kriterier: de kan ikke opfyldes uden at modtage data fra et eksternt system \u2014 det system, hvor applikationer implementeres (i vores tilf\u00e6lde er det Kubernetes).<\/p>\n

    Illustration af workflow i Git<\/h3>\n

    \nLad os antage, at du arbejder efter denne skema i Git:<\/p>\n

    \"Problemet
    \n
    \nIkonet med hovedet p\u00e5 skemaet markerer de containerbilleder, der i \u00f8jeblikket er implementeret i Kubernetes for nogle brugere (slutbrugere, testere, ledere osv.) eller bruges af udviklere til fejls\u00f8gning og lignende form\u00e5l.<\/i><\/p>\n

    Hvad sker der, hvis oprydningspolitikkerne tillader at efterlade (ikke slette) billeder kun i henhold til bestemte tag-navne<\/b>?<\/p>\n

    \"Problemet
    \n
    \n\u00c5benlyst, vil et s\u00e5dant scenarie ikke gl\u00e6de nogen.<\/p>\n

    Hvad \u00e6ndrer sig, hvis politikkerne tillader ikke at slette billeder i henhold til et bestemt tidsinterval \/ antal seneste commits<\/b>?<\/p>\n

    \"Problemet
    \n
    \nResultatet er blevet markant bedre, men er stadig langt fra idealt. For vi har stadig udviklere, der har brug for billeder i registry (eller endda implementeret i K8s) til fejls\u00f8gning af fejl\u2026<\/p>\n

    For at opsummere den nuv\u00e6rende situation p\u00e5 markedet: de tilg\u00e6ngelige funktioner i containerregistrene tilbyder ikke tilstr\u00e6kkelig fleksibilitet ved oprydning, og den hoved\u00e5rsag er \u2014 manglen p\u00e5 mulighed for at interagere med den eksterne verden.<\/strong>. Det viser sig, at teams, der har brug for s\u00e5dan fleksibilitet, er n\u00f8dt til selv at implementere eliminering af billeder \"udefra\" ved at bruge Docker Registry API (eller det tilsvarende native API).<\/p>\n

    Men vi har ledt efter en universel l\u00f8sning, der ville automatisere oprydningen af billeder for forskellige teams, der bruger forskellige registre\u2026<\/p>\n

    Vores vej til universel oprydning af billeder<\/h2>\n

    \nHvorfor er der s\u00e5dan et behov? Det skyldes, at vi ikke er en enkeltst\u00e5ende gruppe udviklere, men et team, der betjener adskillige s\u00e5danne grupper og hj\u00e6lper med at l\u00f8se CI\/CD-udfordringer. Og det vigtigste tekniske v\u00e6rkt\u00f8j til dette er en open source-utility. werf<\/a><\/noindex>. Dens s\u00e6rligt ved at den ikke udf\u00f8rer en enkelt funktion, men underst\u00f8tter processerne for kontinuerlig levering p\u00e5 alle trin: fra bygning til deployment.<\/p>\n

    Publicering af billeder i registre* (umiddelbart efter deres bygning) er en \u00e5benlys funktion af en s\u00e5dan utility. Og eftersom billederne placeres der for opbevaring, skal man, hvis dit lager ikke er ubegribelig, ogs\u00e5 st\u00e5 til ansvar for deres efterf\u00f8lgende oprydning. Hvordan vi har haft succes med dette, mens vi har opfyldt alle givne kriterier, vil blive beskrevet videre.<\/p>\n

    * Selvom selve registrene kan v\u00e6re forskellige (Docker Registry, GitLab Container Registry, Harbor osv.), st\u00e5r deres brugere over for de samme problemer. Den universelle l\u00f8sning i vores tilf\u00e6lde er uafh\u00e6ngig af registrets implementering, da den udf\u00f8res uden for selve registrene og tilbyder ensartet adf\u00e6rd for alle.<\/i><\/p>\n

    Selvom vi bruger werf som et eksempel p\u00e5 implementering, h\u00e5ber vi, at de anvendte metoder vil v\u00e6re nyttige for andre teams, der st\u00e5r over for lignende udfordringer.<\/p>\n

    S\u00e5 vi tog fat p\u00e5 den eksterne<\/i> implementering af mekanismen til oprydning af billeder \u2014 i stedet for de muligheder, der allerede er indbygget i registrene for containere. Det f\u00f8rste skridt var at bruge Docker Registry API til at oprette de samme primitive politikker for antal tags og deres oprettelsestid (som n\u00e6vnt ovenfor). Til disse blev der tilf\u00f8jet en tilladelsesliste baseret p\u00e5 de billeder, der bruges i den udrullede infrastruktur<\/strong>, dvs. Kubernetes. For sidstn\u00e6vnte var det tilstr\u00e6kkeligt at iterere gennem alle udrullede ressourcer via Kubernetes API og f\u00e5 en liste over v\u00e6rdier. billede<\/code>.<\/p>\n

    Denne trivielle l\u00f8sning lukkede det mest kritiske problem (kriterium nr. 1), men var kun begyndelsen p\u00e5 vores vej til at forbedre reng\u00f8ringsmekanismen. N\u00e6ste - og en langt mere interessant - skridt var at finde en l\u00f8sning at tilknytte de offentliggjorte billeder til historien i Git<\/strong>.<\/p>\n

    Tagging-schemer<\/h3>\n

    \nFor at starte valgte vi en tilgang, hvor det endelige billede skulle gemme den n\u00f8dvendige information til reng\u00f8ring, og vi opbyggede processen p\u00e5 tagging-schemer. Ved offentligg\u00f8relse af billedet valgte brugeren en bestemt tagging-option (git-branch<\/code>, git-commit<\/code> eller git-tag<\/code>) og brugte den tilsvarende v\u00e6rdi. I CI-systemer blev indstillingen af disse v\u00e6rdier udf\u00f8rt automatisk baseret p\u00e5 milj\u00f8variabler. Grundl\u00e6ggende blev det endelige billede knyttet til en bestemt Git-primitiv<\/strong>, der gemte de n\u00f8dvendige data til reng\u00f8ring i labels.<\/p>\n

    Inden for denne tilgang blev der skabt en r\u00e6kke politikker, der gjorde det muligt at bruge Git som den eneste sandhedskilde:<\/p>\n