{"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 \"nutikast\" konteineripiltide puhastamisest ja selle lahendus werf'is","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Probleem
\n
\nArtiklis k\u00e4sitletakse konteinerite registrites (nt Docker Registry) kogunevate piltide puhastamise probleeme kaasaegsete CI\/CD torujuhtmete tingimustes, mis on m\u00f5eldud Kuberneteses tarnitavatele pilvep\u00f5histele rakendustele. Toome v\u00e4lja peamised piltide aktuaalsuse kriteeriumid ja nendest tulenevad raskused puhastamise automatiseerimisel, ruumi s\u00e4\u00e4stmisel ja meeskondade vajaduste rahuldamisel. L\u00f5puks r\u00e4\u00e4gime konkreetse avatud l\u00e4htekoodiga projekti n\u00e4itel, kuidas neid raskusi \u00fcletada.<\/p>\n

Sissejuhatus<\/h2>\n

\nKonteinerite registris olevate piltide arv v\u00f5ib kiiresti kasvada, h\u00f5ivates rohkem ruumi salvestuses ja suurenedes seel\u00e4bi oluliselt selle maksumust. Ruumi kontrollimiseks, piiramiseks v\u00f5i vastuv\u00f5etava kasvu s\u00e4ilitamiseks registry's kasutatakse tavaliselt:<\/p>\n

    \n
  1. fikseeritud arvu silte piltide jaoks;<\/li>\n
  2. millelegi muule nagu piltide puhastamine.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nEsimene piirang on m\u00f5nikord lubatav v\u00e4ikestes meeskondades. Kui arendajatele piisab p\u00fcsivatest siltest (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> jne), ei paisu register suuruseks ja saab pikka aega t\u00e4ielikult unustada puhastamisest. K\u00f5ik mitteaktuaalsed pildid \u00fcksteise \u00fcle kirjutatakse ja puhastamiseks ei j\u00e4\u00e4 lihtsalt t\u00f6\u00f6d (k\u00f5ik toimub tavap\u00e4rase r\u00e4mpsup\u00fc\u00fcdja kaudu).<\/p>\n

    Siiski piirab selline l\u00e4henemine tugevalt arendustegevust ja on harva kasutatav kaasaegsetes CI\/CD projektides. Arendamise lahutamatuks osaks on saanud automaatika<\/strong>, mis v\u00f5imaldab uute funktsioonide testimist, juurutamist ja tarnimist kasutajatele palju kiiremini. N\u00e4iteks meie k\u00f5igis projektides luuakse iga commiti ajal automaatselt CI-pipe. Seal luuakse pilt, testitakse, suunatakse erinevatesse Kubernetes keskkondadesse t\u00f5rgete v\u00e4ltimiseks ja \u00fclej\u00e4\u00e4nud kontrollide jaoks, ja kui k\u00f5ik on h\u00e4sti, j\u00f5uavad muudatused l\u00f5ppkasutajani. See pole ammu mitte raketiteadus, vaid paljudele igap\u00e4evane praktika \u2014 t\u00f5en\u00e4oliselt ka teile, kuna loete seda artiklit.<\/p>\n

    Kuna vigade k\u00f5rvaldamine ja uue funktsionaalsuse arendamine toimub paralleelselt ning v\u00e4ljastamine v\u00f5ib toimuda mitu korda p\u00e4evas, on ilmselge, et arendusprotsessiga kaasneb m\u00e4rkimisv\u00e4\u00e4rne arv commit'e, ja seega - suure arvu piltide olemasolu registry's.<\/strong>Seet\u00f5ttu kerkib teravalt \u00fcles k\u00fcsimus efektiivse registry puhastamise korraldamisest, st mitteaktuaalsete piltide eemaldamisest.<\/p>\n

    Kuidas aga kindlaks teha, kas pilt on asjakohane?<\/p>\n

    Pildi asjakohasuse kriteeriumid<\/h2>\n

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

    1. Esimene (k\u00f5ige ilmsem ja k\u00f5ikidest k\u00f5ige kriitilisem) \u2014 need on pildid, mis hetkel kasutatakse Kuberneteses<\/strong>. Nende eemaldamine v\u00f5ib p\u00f5hjustada t\u00f5siseid kulusid seoses produktsiooni seiskumisega (n\u00e4iteks v\u00f5ivad pildid olla vajalikud kopeerimise ajal) v\u00f5i t\u00fchistada meeskonna pingutused, kes tegeleb t\u00f5rgete t\u00f5rkeotsinguga m\u00f5nes kontuuris. (Sellep\u00e4rast tegime eraldi <\/i>Prometheus eksportija<\/i><\/a><\/noindex>, mis j\u00e4lgib selliste piltide puudumist igas Kubernetes-klastris.)<\/i><\/p>\n

    2. Teine (v\u00e4hem ilmne, kuid samuti v\u00e4ga oluline ja j\u00e4lle seotud kasutamisega) \u2014 pildid, mis on vajalikud rikka juhtudel, kui esinevad t\u00f5sised probleemid<\/strong> praeguses versioonis. N\u00e4iteks, kui r\u00e4\u00e4kida Helm'ist, siis on need pildid, mis on kasutusel salvestatud v\u00e4ljalaskeversioonides. (Muide, Helm'il on vaikimisi 256 revideerimise piirm\u00e4\u00e4r, kuid kas kellelgi on t\u00f5eliselt vajadust s\u00e4ilitada nii<\/i> suurt versioonide arvu?..) Me hoiame versioone just selleks, et neid hiljem kasutada, st et saaksime vajadusel \u201etagasi p\u00f6\u00f6rduda\u201c.<\/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, on m\u00f5istlik j\u00e4tta pilt, mis vastab viimasele commit'ile ja, \u00fctleme, eelmisele commit'ile: nii saab arendaja kiiresti naasta igasse \u00fclesandesse ja t\u00f6\u00f6tada viimaste muudatustega. <\/p>\n

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

    NB: Siin v\u00e4lja toodud kriteeriumid on formuleeritud loodud on p\u00f5hinedes kogemustele, mis on saadud koost\u00f6\u00f6s k\u00fcmnete arendajate meeskondadega erinevatest ettev\u00f5tetest. Kuid loomulikult v\u00f5ivad need kriteeriumid erinevalt s\u00f5ltuda arendusprotsesside ja kasutatava infrastruktuuri (nt kui Kubernetesit ei kasutata) spetsiifikast. <\/p>\n

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

    \nPopulaarsed konteineriregistrite teenused pakuvad tavaliselt oma pildipuhastuspoliitikat: nendes saate m\u00e4\u00e4rata tingimused, mille alusel silt kustutatakse registrist. Kuid nende tingimuste v\u00f5imalused on piiratud selliste parameetritega nagu nimed, loomise aeg ja siltide arv*.<\/p>\n

    * S\u00f5ltub konkreetsetest lahendustest container registry. Oleme kaalunud 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

    Selline parameetrite kogum on piisav, et rahuldada neljandat kriteeriumi \u2014 see t\u00e4hendab valides pilte, mis vastavad versioonidele. K\u00f5ikide \u00fclej\u00e4\u00e4nud kriteeriumite puhul peab aga leidma mingisuguse kompromissi (karmema v\u00f5i vastupidi, leebema poliitika) vastavalt ootustele ja rahalistele v\u00f5imalustele.<\/p>\n

    N\u00e4iteks kolmas kriteerium \u2014 arendajate vajadustega seotud \u2014 v\u00f5ib lahendada meeskondade sees toimingute korraldamise kaudu: spetsiifiliste piltide nimetamine, spetsiaalsete lubade loetelu koostamine ja sisemised kokkulepped. Kuid l\u00f5puks tuleb see ikkagi automatiseerida. Ja kui valmis lahendused ei rahulda vajadusi, tuleb teha midagi oma k\u00e4tega.<\/p>\n

    Sarnane olukord on ka kahe esimese kriteeriumiga: neid ei saa t\u00e4ita ilma andmete saamiseta v\u00e4lisest s\u00fcsteemist \u2014 just sellest, kus rakenduste juurutamine toimub (meie puhul on see Kubernetes).<\/p>\n

    T\u00f6\u00f6voo illustratsioon Git-is<\/h3>\n

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

    \"Probleem
    \n
    \nScheemis m\u00e4rgitud pea ikooniga on konteineripildid, mis on hetkel juurutatud Kuberneteses m\u00f5nedele kasutajatele (l\u00f5ppkasutajatele, testijatele, juhtidele jne) v\u00f5i mida arendajad kasutavad t\u00f5rgete t\u00f5rkeotsinguks ja muudel eesm\u00e4rkidel.<\/i><\/p>\n

    Mida juhtub, kui puhastuspoliitikad lubavad j\u00e4tta (mitte kustutada) pilte ainult m\u00e4\u00e4rapidude nimede j\u00e4rgi<\/b>?<\/p>\n

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

    Mis muutub, kui poliitikad v\u00f5imaldavad mitte kustutada pilte m\u00e4\u00e4ratud ajavahemiku \/ viimaseid commit\u2019e arvu p\u00f5hjal<\/b>?<\/p>\n

    \"Probleem
    \n
    \nTulemus on olnud m\u00e4rkimisv\u00e4\u00e4rselt parem, kuid on endiselt kaugel ideaalist. L\u00f5ppude l\u00f5puks on meil endiselt arendajaid, kellele on vaja pilte registris (v\u00f5i isegi juurutatud K8s-s), et t\u00f5rkeid t\u00f5rkeotsinguks\u2026<\/p>\n

    Kokkuv\u00f5ttes ei paku konteineriregistrite kaudu saadaval olevad funktsioonid piisavat paindlikkust puhastamise osas, mille peamine p\u00f5hjus on v\u00e4lismaailmaga suhtlemise puudumine<\/strong>. Tulemuseks on see, et meeskonnad, kes vajavad sellist paindlikkust, peavad piltide eemaldamist \u201ev\u00e4ljastpoolt\u201c ise rakendama, kasutades Docker Registry API-d (v\u00f5i vastava rakenduse natiivset API-d).<\/p>\n

    Otsisime universaalset lahendust, mis automatiseeriks piltide puhastamise erinevate meeskondade jaoks, kes kasutavad erinevaid registreid\u2026<\/p>\n

    Meie tee universaalse piltide puhastamiseni<\/h2>\n

    \nKust see vajadus tuleb? Asi on selles, et me ei ole \u00fcksi arendajate r\u00fchm, vaid meeskond, mis teenindab mitmeid selliseid r\u00fchmi, aidates komplekselt lahendada CI\/CD k\u00fcsimusi. Ja peamine tehniline t\u00f6\u00f6riist selleks on avatud l\u00e4htekoodiga utiliit werf<\/a><\/noindex>. Selle erip\u00e4ra on see, et see ei t\u00e4ida ainult \u00fchte funktsiooni, vaid toob esile pideva tarnimise protsessid k\u00f5igil etappidel: kogumisest kuni juurutamiseni.<\/p>\n

    Piltide registreerimine* (kohe p\u00e4rast nende koostamist) on sellise utiliidi ilmne funktsioon. Ja kuna pildid pannakse sinna s\u00e4ilitamiseks, siis \u2014 kui teie ladustamine ei ole l\u00f5putu \u2014 tuleb vastutada ka nende hilisema puhastamise eest. Edasi r\u00e4\u00e4gime, kuidas me selles osas edu saavutasime, j\u00e4rgides k\u00f5iki ette antud kriteeriume.<\/p>\n

    * Kuigi registreerimised v\u00f5ivad olla erinevad (Docker Registry, GitLabi konteineri register, Harbor jne), seisavad nende kasutajad silmitsi sama probleemiga. Meie universaalne lahendus ei s\u00f5ltu registreerimise rakendusest, kuna see tehakse v\u00e4ljaspool registreid ja pakub \u00fchtlast k\u00e4itumist k\u00f5igile.<\/i><\/p>\n

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

    Nii et me asusime v\u00e4lis<\/i> mehhanismi rakendama piltide puhastamiseks \u2014 selle asemel, et kasutada konteineriregistrites juba olemasolevaid v\u00f5imalusi. Esimene samm oli Docker Registry API kasutamine nende lihtsate poliitikate loomiseks, mis k\u00e4sitlesid siltide arvu ja nende loomise aega (nagu eespool mainitud). Neile lisati lubatud nimekiri p\u00f5hjal, mida kasutati juurutatud infrastruktuuris<\/strong>, st, Kubernetes. Viimase jaoks oli piisav, et l\u00e4bi Kubernetes API l\u00e4bida k\u00f5ik juurutatud ressursid ja saada v\u00e4\u00e4rtuste nimekirja. image<\/code>.<\/p>\n

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

    Siltimisplaanid<\/h3>\n

    \nAlustuseks valisime l\u00e4henemise, mille kohaselt peab l\u00f5pppilt salvestama vajalikku teavet puhastamiseks ja me ehitasime protsessi siltimisplaanide peale. Pildi avaldamisel valis kasutaja teatud siltimisv\u00f5imaluse (git-haru<\/code>, git-commit<\/code> v\u00f5i git-silt<\/code>) ja kasutas vastavat v\u00e4\u00e4rtust. CI-s\u00fcsteemides seadistati need v\u00e4\u00e4rtused automaatselt keskkonnamuutujate alusel. Sisuliselt seostati l\u00f5pppilt teatud Git'i primitiiviga,<\/strong>hoides vajalikku teavet puhastamiseks silte.<\/p>\n

    Selle l\u00e4henemise raames saadi poliitikate kogum, mis v\u00f5imaldas Git'i kasutada ainsa t\u00f5e allikana:<\/p>\n