{"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\/et\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Probleem \u201enutika\u201d konteinerite piltide puhastus ja selle lahendus werf'is","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Probleem
\n
\nArtiklis k\u00e4sitletakse konteinerite registrites (Docker Registry ja sarnastes) kogunevate piltide puhastamise probleemistikku, arvestades t\u00e4nap\u00e4evaseid CI\/CD torujuhtmeid cloud native rakenduste jaoks, mis on tarnitud Kubernetesesse. Esitatakse peamised kriteeriumid piltide asjakohasuse osas ja nendest tulenevad raskused puhastamise automatiseerimisel, ruumi s\u00e4\u00e4stmisel ja meeskondade vajaduste rahuldamisel. L\u00f5puks, kasutades konkreetse Open Source projekti n\u00e4idet, r\u00e4\u00e4gime, kuidas neid raskusi \u00fcletada.<\/p>\n

Sissejuhatus<\/h2>\n

\nKonteinerite registris olevate piltide arv v\u00f5ib kiiresti suureneda, kulutades rohkem ruumi salvestusmahule ning seel\u00e4bi suurendades oluliselt selle maksumust. Registris ruumi kontrollimise, piiramise v\u00f5i vastuv\u00f5etava kasvu s\u00e4ilitamise jaoks on tavaks:<\/p>\n

    \n
  1. kasutada fikseeritud arvu silte piltidele;<\/li>\n
  2. mingil moel piltide puhastamine.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nEsimene piirang on m\u00f5nikord lubatav v\u00e4ikestes meeskondades. Kui arendajatele piisab pidevatest siltidest (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> ja jne), register ei suureneks, ja pikalt ei pea \u00fcldse muretsema puhastamise p\u00e4rast. K\u00f5ik aegumatud kujutised asendatakse, ning puhastamiseks ei j\u00e4\u00e4 lihtsalt t\u00f6\u00f6d (k\u00f5ik toimub tavalise pr\u00fcgikoguja kaudu).<\/p>\n

    Kuid selline l\u00e4henemine piirab arendust ja sageli ei ole see rakendatav kaasaegse CI\/CD projektide puhul. Arenduse lahutamatu osa on automatiseerimine<\/strong>, mis v\u00f5imaldab palju kiiremini testida, juurutada ja edastada uusi funktsioone kasutajatele. N\u00e4iteks meie k\u00f5igis projektides luuakse igal commitil automaatselt CI-pipeline. Seal kogutakse pilt, testitakse, juurutatakse erinevatesse Kubernetes'i keskkondadesse t\u00f5rgeteotsimiseks ja j\u00e4relej\u00e4\u00e4nud kontrollide l\u00e4biviimiseks, ning kui k\u00f5ik on h\u00e4sti, j\u00f5uavad muudatused l\u00f5ppkasutajani. See ei ole ammu enam rocket science, vaid iga p\u00e4evane praktika paljudele \u2014 t\u00f5en\u00e4oliselt ka teile, kui loete seda artiklit.<\/p>\n

    Kuna vigade k\u00f5rvaldamine ja uute funktsioonide arendamine toimub paralleelselt ning v\u00e4ljalasked v\u00f5ivad toimuda mitu korda p\u00e4evas, on ilmne, et arendusprotsessiga kaasneb m\u00e4rkimisv\u00e4\u00e4rne hulk commit'e, seega \u2014 registreerimises on palju pilte<\/strong>. Seet\u00f5ttu tekib terav k\u00fcsimus t\u00f5husast registri puhastamisest, st mittesobivate piltide eemaldamisest.<\/p>\n

    Aga kuidas \u00fcldse m\u00e4\u00e4rata, kas pilt on asjakohane?<\/p>\n

    Pildi asjakohasuse kriteeriumid<\/h2>\n

    \nEnamikul juhtudel on p\u00f5hikriteeriumid j\u00e4rgmised:<\/p>\n

    1. Esimene (k\u00f5ige ilmsem ja kriitilisem) \u2014 see on pildid, mis on hetkel kasutusel Kuberneteses<\/strong>. Nende piltide eemaldamine v\u00f5ib p\u00f5hjustada t\u00f5siseid kulusid seoses tootmise seiskumisega (n\u00e4iteks v\u00f5ivad need pildid olla vajalikud replikatsiooniks) v\u00f5i t\u00fchistada meeskonna pingutused, mis tegeleb silumine \u00fche v\u00f5i teise kontuuri peal. (Sel p\u00f5hjusel oleme isegi loonud spetsiaalse <\/i>Prometheuse eksportija<\/i><\/a><\/noindex>, mis j\u00e4lgib selliste piltide puudumist igas Kubernetesi klastris.)<\/i><\/p>\n

    2. Teine (v\u00e4hem ilmne, kuid samuti v\u00e4ga oluline ja j\u00e4lle tootmisega seotud) \u2014 pildid, mis on vajalikud tagasip\u00f6\u00f6rdumiseks t\u00f5siste probleemide ilmnemisel<\/strong> praeguses versioonis. N\u00e4iteks, Helmiga seoses on need pildid, mida kasutatakse salvestatud versioonides. (Muide, Helmil on vaikimisi 256 versiooni piirm\u00e4\u00e4r, kuid t\u00f5en\u00e4oliselt pole kellelgi tegelikult vajadust salvestada sellist<\/i> suur hulk versioone?..) Just selleks me versioone salvestame, et saaksime neid hiljem kasutada, st \u201etagasi kerida\u201d, kui on vaja.<\/p>\n

    3. Kolmas \u2014 arendajate vajadused<\/strong>: k\u00f5ik pildid, mis on seotud nende praeguste t\u00f6\u00f6dega. N\u00e4iteks, kui vaatame PR-i, siis on m\u00f5istlik hoida pilt, mis vastab viimasele commit'ile ja \u00fctleme, eelmisele commit'ile: nii saab arendaja kiiresti naasta mis tahes \u00fclesande juurde ja t\u00f6\u00f6tada viimaste muudatustega. <\/p>\n

    4. Neljas \u2014 pildid, mis vastavad meie rakenduse versioonidele<\/strong>, st on l\u00f5pp-produkt: v1.0.0, 20.04.01, sierra jne.<\/p>\n

    NB: Siin m\u00e4\u00e4ratletud kriteeriumid on koostatud kogenud arendustiimide koost\u00f6\u00f6kogemuse p\u00f5hjal erinevatest ettev\u00f5tetest. Kuid loomulikult v\u00f5ivad need kriteeriumid varieeruda s\u00f5ltuvalt arendusprotsesside ja kasutatava infrastruktuuri (nt Kubernetes'i mittekasutamine) spetsiifilisusest. <\/p>\n

    Kriteeriumite vastavus ja olemasolevad lahendused<\/h2>\n

    \nPopulaarsed container registry teenused pakuvad tavaliselt oma imagede puhastusreegleid: nendes on v\u00f5imalik m\u00e4\u00e4rata tingimusi, mille kohaselt silt registry's kustutatakse. Kuid nende tingimuste v\u00f5imalused on piiratud selliste parameetritega nagu nimed, loomise aeg ja siltide arv*.<\/p>\n

    * S\u00f5ltub konkreetsetest rakendustest container registry. Oleme uurinud j\u00e4rgmiste lahenduste v\u00f5imalusi: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 seisuga september 2020.<\/i><\/p>\n

    Selliste parameetrite kogum on t\u00e4iesti piisav, et t\u00e4ita neljas kriteerium \u2014 see t\u00e4hendab valida pilte, mis vastavad versioonidele. Kuid k\u00f5igi teiste kriteeriumide puhul tuleb teha mingisugune kompromisslahendus (rangem v\u00f5i vastupidi, leebem poliitika) \u2014 s\u00f5ltuvalt ootustest ja rahalistest v\u00f5imalustest.<\/p>\n

    N\u00e4iteks kolmandat kriteeriumi \u2014 mis on seotud arendajate vajadustega \u2014 saab lahendada protsesside korraldamise kaudu meeskondades: spetsiifilised pildinimed, spetsiaalsete lubatud loendite koostamine ja sisemised kokkulepped. Kuid l\u00f5puks on vaja see ikkagi automatiseerida. Ja kui valmis lahenduste v\u00f5imalused ei piisa, tuleb midagi oma k\u00e4tega teha.<\/p>\n

    Sama kehtib kahe esimese kriteeriumi kohta: neid ei saa t\u00e4ita, saamata andmeid v\u00e4lisest s\u00fcsteemist \u2014 just sealt, kus rakenduste juurutamine toimub (meie puhul on see Kubernetes).<\/p>\n

    Workflowsi illustreerimine Git-is<\/h3>\n

    \nEeldame, et t\u00f6\u00f6tate umbes sellise skeemi j\u00e4rgi Git-is:<\/p>\n

    \"Probleem
    \n
    \nKujutise ikooniga on n\u00e4idatud konteinerite pildid, mis on praegu Kuberneteses kasutuses m\u00f5ne kasutaja (l\u00f5ppkasutajad, testijad, juhendajad jne) jaoks v\u00f5i mida arendajad kasutavad t\u00f5rgete silumiseks ja sarnaste eesm\u00e4rkide jaoks.<\/i><\/p>\n

    Mis juhtub, kui puhastuspoliitikad lubavad j\u00e4tta (mitte kustutada) pildid ainult m\u00e4\u00e4ratud sildinimede j\u00e4rgi.<\/b>?<\/p>\n

    \"Probleem
    \n
    \nIlmselgelt ei meeldi selline stsenaarium kellelegi.<\/p>\n

    Mis muutub, kui poliitikad lubavad mitte kustutada pilte m\u00e4\u00e4ratud ajavahemiku \/ viimaste commitide arvu j\u00e4rgi.<\/b>?<\/p>\n

    \"Probleem
    \n
    \nTulemus on m\u00e4rgatavalt parem, kuid siiski kaugel ideaalist. Meil on endiselt arendajaid, kellele on vajalikud registris olevad pildid (v\u00f5i isegi Kuberneteses kasutatavad) t\u00f5rkeotsingu jaoks...<\/p>\n

    Kokkuv\u00f5ttes valitsev olukord turul: konteineriregistrites pakutavad funktsioonid ei paku puhastamiseks piisavalt paindlikkust ja peamine p\u00f5hjus on \u2014 puudub v\u00f5imalus suhelda v\u00e4lismaailmaga.<\/strong>. Tundub, et meeskonnad, kellele on vajalik selline paindlikkus, peavad ise teostama piltide eemaldamise \u201ev\u00e4ljastpoolt\u201d, kasutades Docker Registry API-d (v\u00f5i vastava teostuse natiivset API-d).<\/p>\n

    Kuid me otsisime universaalset lahendust, mis automatiseeriks piltide puhastamise erinevate meeskondade jaoks, kes kasutavad erinevaid registrite...<\/p>\n

    Meie tee universaalse piltide puhastamise suunal<\/h2>\n

    \nKust see vajadus tuleb? Asi on selles, et me ei ole eraldi arendajate r\u00fchm, vaid meeskond, mis teenindab korraga mitut sellist, aidates lahendada CI\/CD k\u00fcsimusi terviklikult. Ja peamine tehniline t\u00f6\u00f6riist selle jaoks on avatud l\u00e4htekoodiga utiliit. werf<\/a><\/noindex>. Selle erip\u00e4ra on see, et see ei t\u00e4ida \u00fchteainust funktsiooni, vaid toetab pideva kohaletoimetamise protsesse k\u00f5igil etappidel: kogumisest kuni juurutamiseni.<\/p>\n

    Piltide avaldamine registris* (vahetult p\u00e4rast nende kogumist) on sellise utiliidi ilmselge funktsioon. Ja kuna pildid pannakse sinna hoidmiseks, siis \u2014 kui teie salvestusruum ei ole piiramatud \u2014 peate vastutama ka nende edasise puhastamise eest. Edasi r\u00e4\u00e4gime sellest, kuidas me oleme selles edukad, rahuldades k\u00f5ik seatud kriteeriumid.<\/p>\n

    * Kuigi registrid v\u00f5ivad olla erinevad (Docker Registry, GitLabi konteineri register, Harbor jne), seisavad nende kasutajad silmitsi samade probleemidega. Universaalne lahendus meie puhul ei s\u00f5ltu registri rakendusest, kuna see teostatakse registritest v\u00e4ljaspool ja pakub k\u00f5igile sama k\u00e4itumist.<\/i><\/p>\n

    Kuigi kasutame werfi n\u00e4itena rakendusest, loodame, et rakendatud l\u00e4henemisviisid on kasulikud ka teistele meeskondadele, kes seisavad silmitsi sarnaste keerukustega.<\/p>\n

    Nii et me v\u00f5tsime k\u00e4sile v\u00e4lise<\/i> mehhanismi piltide puhastamiseks \u2014 erinevalt neist v\u00f5imalustest, mis on juba konteinerite registrites sisse ehitatud. Esimene samm oli Docker Registry API kasutamine, et luua endiselt primitiivseid poliitikaid siltide arvu ja nende loomise aja kohta (nagu juba mainitud). Neile lisati lubamise nimekiri, mis p\u00f5hineb rakendatud infrastruktuuris kasutatavatel piltidel<\/strong>, st Kubernetes. Viimase jaoks oli piisav, kui Kubernetes API kaudu l\u00e4bi k\u00e4ia k\u00f5ik juurutatud ressursid ja saada nimekiri v\u00e4\u00e4rtustest. pilt<\/code>.<\/p>\n

    See lihtne lahendus lahendas k\u00f5ige kriitilisema probleemi (kriteerium nr 1), kuid oli alles meie teekonna algus puhastusmehhanismi t\u00e4iustamiseks. J\u00e4rgmine ja palju huvitavam samm oli seostada avaldatud pildid Git'i ajalooga<\/strong>.<\/p>\n

    M\u00e4rgistamisstrateegiad<\/h3>\n

    \nAlguses valisime l\u00e4henemise, kus l\u00f5plik pilt peab sisaldama vajalikku teavet puhastamiseks, ja \u00fcles ehitasime protsessi m\u00e4rgistusstrateegiate p\u00f5hjal. Pildi avaldamisel valis kasutaja kindla m\u00e4rgistamisvaliku (git-branch<\/code>, git-commit<\/code> v\u00f5i git-tag<\/code>) ja kasutas vastavat v\u00e4\u00e4rtust. CI-s\u00fcsteemides m\u00e4\u00e4rati need v\u00e4\u00e4rtused automaatselt keskkonnamuutujate alusel. Sisuliselt seoti l\u00f5plik pilt kindla Git'i primitiiviga<\/strong>, hoides puhastamiseks vajalikke andmeid etikettides.<\/p>\n

    Selle l\u00e4henemise raames loodi poliitikate kogum, mis v\u00f5imaldas kasutada Git'i kui ainust t\u00f5ep\u00e4devuse allikat:<\/p>\n