{"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\/ro\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Problema \u201einteligent\u0103\u201d a cur\u0103\u021b\u0103rii imaginilor containerelor \u0219i solu\u021bia acesteia \u00een werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Problema
\n
\nArticolul abordeaz\u0103 problematica cur\u0103\u021b\u0103rii imaginilor care se acumuleaz\u0103 \u00een registrele containerelor (Docker Registry \u0219i omologii s\u0103i) \u00een contextul pipeline-urilor CI\/CD actuale pentru aplica\u021bii cloud native livrate \u00een Kubernetes. Sunt prezentate principalele criterii de actualitate a imaginilor \u0219i dificult\u0103\u021bile care decurg din acestea \u00een automatizarea cur\u0103\u021b\u0103rii, economisirea spa\u021biului \u0219i satisfacerea nevoilor echipelor. \u00cen final, vom ar\u0103ta, prin exemplul unui proiect Open Source specific, cum pot fi dep\u0103\u0219ite aceste dificult\u0103\u021bi.<\/p>\n

Introducere<\/h2>\n

\nNum\u0103rul imaginilor din registrul containerelor poate cre\u0219te rapid, ocup\u00e2nd mai mult spa\u021biu de stocare \u0219i, \u00een consecin\u021b\u0103, cresc\u00e2nd semnificativ costul acestuia. Pentru a controla, limita sau men\u021bine o cre\u0219tere acceptabil\u0103 a spa\u021biului ocupat \u00een registry, este obi\u0219nuit s\u0103:<\/p>\n

    \n
  1. folose\u0219ti un num\u0103r fix de etichete pentru imagini;<\/li>\n
  2. cur\u0103\u021bi imaginile \u00een vreun fel.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nPrima limitare este uneori acceptabil\u0103 pentru echipe mici. Dac\u0103 dezvoltatorilor le sunt suficiente etichetele permanente (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> etc.), registrul nu se va extinde ca volum \u0219i o lung\u0103 perioad\u0103 de timp nu va fi necesar s\u0103 te g\u00e2nde\u0219ti la cur\u0103\u021bare. Toate imaginile neactualizate sunt \u00eenlocuite, a\u0219a c\u0103 nu r\u0103m\u00e2ne munc\u0103 de cur\u0103\u021bare (totul se face de c\u0103tre colectorul standard de de\u0219euri).<\/p>\n

    Cu toate acestea, aceast\u0103 abordare limiteaz\u0103 semnificativ dezvoltarea \u0219i este rar aplicabil\u0103 \u00een CI\/CD pentru proiectele moderne. O parte integrant\u0103 a dezvolt\u0103rii a devenit automatizarea<\/strong>, care permite testarea, desf\u0103\u0219urarea \u0219i livrarea mai rapid\u0103 a noilor func\u021bionalit\u0103\u021bi utilizatorilor. De exemplu, \u00een toate proiectele noastre, la fiecare commit se creeaz\u0103 automat un pipeline CI. Aici se construie\u0219te imaginea, se testeaz\u0103, se lanseaz\u0103 \u00een diverse medii Kubernetes pentru debugging \u0219i verific\u0103ri suplimentare, iar dac\u0103 totul este \u00een regul\u0103 \u2014 modific\u0103rile ajung la utilizatorul final. \u0218i aceasta nu mai este o \u0219tiin\u021b\u0103 a rachetelor, ci o cotidian\u0103 pentru mul\u021bi \u2014 probabil \u0219i pentru tine, av\u00e2nd \u00een vedere c\u0103 cite\u0219ti acest articol.<\/p>\n

    Deoarece eliminarea bug-urilor \u0219i dezvoltarea de noi func\u021bionalit\u0103\u021bi se desf\u0103\u0219oar\u0103 \u00een paralel, iar lans\u0103rile pot avea loc de mai multe ori pe zi, este evident c\u0103 procesul de dezvoltare este \u00eenso\u021bit de un num\u0103r semnificativ de commit-uri, ceea ce \u00eenseamn\u0103 \u2014 un num\u0103r mare de imagini \u00een registry.<\/strong>Ca urmare, apare cu urgen\u021b\u0103 problema organiz\u0103rii unei cur\u0103\u021b\u0103ri eficiente a registry-ului, adic\u0103 eliminarea imaginilor neactualizate.<\/p>\n

    Dar cum putem determina dac\u0103 imaginea este relevant\u0103?<\/p>\n

    Criteriile de relevan\u021b\u0103 a imaginii<\/h2>\n

    \n\u00cen cele mai multe cazuri, principalele criterii vor fi urm\u0103toarele:<\/p>\n

    1. Primul (cel mai evident \u0219i cel mai critic dintre toate) \u2014 sunt imaginile care \u00een prezent sunt utilizate \u00een Kubernetes<\/strong>. Eliminarea acestor imagini poate duce la costuri serioase din cauza timpului de nefunc\u021bionare a produc\u021biei (de exemplu, imaginile pot fi necesare pentru replicare) sau poate anula eforturile echipei responsabile cu depanarea \u00een oricare dintre medii. (Din acest motiv, am creat chiar un <\/i>exportator Prometheus<\/i><\/a><\/noindex>, care monitorizeaz\u0103 absen\u021ba acestor imagini \u00een oricare cluster Kubernetes.)<\/i><\/p>\n

    2. Al doilea (mai pu\u021bin evident, dar totu\u0219i foarte important \u0219i din nou legat de exploatare) \u2014 imaginile care sunt necesare pentru restaurare \u00een cazul identific\u0103rii problemelor serioase<\/strong> \u00een versiunea curent\u0103. De exemplu, \u00een cazul Helm, acestea sunt imaginile utilizate \u00een versiunile salvate ale lans\u0103rii. (Apropo, implicit \u00een Helm exist\u0103 o limit\u0103 de 256 de revizuiri, dar cineva are \u00eentr-adev\u0103r nevoie de salvarea a\u0219a de<\/i> multor versiuni?..) Totu\u0219i, noi, printre altele, p\u0103str\u0103m versiuni pentru a le putea utiliza ulterior, adic\u0103 pentru a putea \"revine\" la ele \u00een caz de necesitate.<\/p>\n

    3. Al treilea \u2014 nevoile dezvoltatorilor<\/strong>: toate imaginile legate de lucr\u0103rile lor curente. De exemplu, dac\u0103 examin\u0103m un PR, are sens s\u0103 l\u0103s\u0103m imaginea care corespunde ultimei modific\u0103ri \u0219i, s\u0103 zicem, modific\u0103rii anterioare: astfel, dezvoltatorul poate reveni rapid la orice sarcin\u0103 \u0219i lucra cu ultimele actualiz\u0103ri. <\/p>\n

    4. Al patrulea \u2014 imaginile care corespund versiunilor aplica\u021biei noastre<\/strong>, adic\u0103 sunt produsul final: v1.0.0, 20.04.01, sierra etc.<\/p>\n

    NB: Criteriile formulate aici au fost stabilite pe baza experien\u021bei de colaborare cu zeci de echipe de dezvoltare din diferite companii. Cu toate acestea, desigur, \u00een func\u021bie de particularit\u0103\u021bile proceselor de dezvoltare \u0219i de infrastructura utilizat\u0103 (de exemplu, \u00een cazul \u00een care nu se utilizeaz\u0103 Kubernetes), aceste criterii pot varia. <\/p>\n

    Conformitatea cu criteriile \u0219i solu\u021biile existente<\/h2>\n

    \nServiciile populare cu registry de containere ofer\u0103, de obicei, propriile politici de cur\u0103\u021bare a imaginilor: \u00een acestea, pute\u021bi defini condi\u021biile \u00een care un tag este \u0219ters din registry. Totu\u0219i, op\u021biunile acestor condi\u021bii sunt limitate la parametrii precum numele, timpul de creare \u0219i num\u0103rul de taguri.<\/p>\n

    * Depinde de implement\u0103rile specifice ale registrului de containere. Am analizat capabilit\u0103\u021bile urm\u0103toarelor solu\u021bii: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 \u00eencep\u00e2nd cu septembrie 2020.<\/i><\/p>\n

    Aceast\u0103 setare de parametri este suficient\u0103 pentru a \u00eendeplini cea de-a patra criteriu - adic\u0103 pentru a selecta imaginile care corespund versiunilor. Cu toate acestea, pentru toate celelalte criterii, trebuie s\u0103 alegem o solu\u021bie de compromis (o politic\u0103 mai strict\u0103 sau, dimpotriv\u0103, mai permisiv\u0103) - \u00een func\u021bie de a\u0219tept\u0103ri \u0219i posibilit\u0103\u021bile financiare.<\/p>\n

    De exemplu, al treilea criteriu - legat de nevoile dezvoltatorilor - poate fi rezolvat prin organizarea proceselor \u00een interiorul echipelor: denumirea specific\u0103 a imaginilor, men\u021binerea unor liste de permisiuni speciale \u0219i acorduri interne. \u00cens\u0103, \u00een cele din urm\u0103, acesta trebuie automatizat. \u0218i dac\u0103 capacit\u0103\u021bile solu\u021biilor existente nu sunt suficiente, trebuie s\u0103 realiz\u0103m ceva propriu.<\/p>\n

    Situa\u021bia este similar\u0103 cu cele dou\u0103 prime criterii: nu pot fi \u00eendeplinite f\u0103r\u0103 a ob\u021bine date dintr-un sistem extern - tocmai acela unde se desf\u0103\u0219oar\u0103 implementarea aplica\u021biilor (\u00een cazul nostru, acesta este Kubernetes).<\/p>\n

    Ilustrarea fluxului de lucru \u00een Git<\/h3>\n

    \nS\u0103 presupunem c\u0103 lucra\u021bi aproximativ dup\u0103 acest model \u00een Git:<\/p>\n

    \"Problema
    \n
    \n\u00cen diagram\u0103, cu iconi\u021ba capului sunt marcate imaginile containerelor care sunt \u00een prezent implementate \u00een Kubernetes pentru diferi\u021bi utilizatori (utilizatori finali, testeri, manageri etc.) sau folosite de dezvoltatori pentru depanare \u0219i scopuri similare.<\/i><\/p>\n

    Ce se va \u00eent\u00e2mpla dac\u0103 politicile de cur\u0103\u021bare permit p\u0103strarea (ne\u0219tergerea) imaginilor doar dup\u0103 numele de taguri specificate<\/b>?<\/p>\n

    \"Problema
    \n
    \nEste evident c\u0103 un astfel de scenariu nu va bucura pe nimeni.<\/p>\n

    Ce se va schimba dac\u0103 politicile permit ne\u0219tergerea imaginilor dup\u0103 un interval de timp specificat \/ num\u0103rul ultimelor comituri<\/b>?<\/p>\n

    \"Problema
    \n
    \nRezultatul a devenit semnificativ mai bun, totu\u0219i este \u00eenc\u0103 departe de ideal. Deoarece avem \u00een continuare dezvoltatori care au nevoie de imagini \u00een registry (sau chiar implementate \u00een K8s) pentru a depana bug-uri...<\/p>\n

    Rezumatul situa\u021biei actuale de pe pia\u021b\u0103: func\u021biile disponibile \u00een registrele de containere nu ofer\u0103 suficient\u0103 flexibilitate \u00een ceea ce prive\u0219te cur\u0103\u021barea, iar motivul principal este lipsa posibilit\u0103\u021bii de interac\u021biune cu lumea exterioar\u0103<\/strong>. Deci, echipele care necesit\u0103 o astfel de flexibilitate trebuie s\u0103 implementeze singure \u0219tergerea imaginilor \"din exterior\", folosind Docker Registry API (sau API-ul nativ al implement\u0103rii respective).<\/p>\n

    Cu toate acestea, noi am c\u0103utat o solu\u021bie universal\u0103, care s\u0103 automatizeze cur\u0103\u021barea imaginilor pentru diferite echipe care folosesc registre variate...<\/p>\n

    Drumul nostru c\u0103tre cur\u0103\u021barea universal\u0103 a imaginilor<\/h2>\n

    \nDe unde provine aceast\u0103 necesitate? Faptul este c\u0103 nu suntem o echip\u0103 de dezvoltatori izolat\u0103, ci o echip\u0103 care sprijin\u0103 simultan mai multe asemenea grupuri, ajut\u00e2nd la solu\u021bionarea complet\u0103 a problemelor CI\/CD. Iar principalul instrument tehnic pentru aceasta este o unealt\u0103 Open Source werf<\/a><\/noindex>. Caracteristica sa este c\u0103 nu execut\u0103 o func\u021bie unic\u0103, ci sus\u021bine procesele de livrare continu\u0103 pe toate etapele: de la construire la implementare.<\/p>\n

    Publicarea \u00een registrul* imaginilor (imediat dup\u0103 ce acestea sunt construite) este o func\u021bie evident\u0103 a unei astfel de unelte. \u0218i, deoarece imaginile sunt stocate acolo, iar dac\u0103 stocarea ta nu este nelimitat\u0103, trebuie s\u0103 te ocupi \u0219i de cur\u0103\u021barea ulterioar\u0103 a acestora. Despre cum am reu\u0219it s\u0103 avem succes \u00een acest sens, respect\u00e2nd toate criteriile impuse, voi vorbi \u00een continuare.<\/p>\n

    * De\u0219i registrele \u00een sine pot fi diverse (Docker Registry, GitLab Container Registry, Harbor etc.), utilizatorii lor se confrunt\u0103 cu acelea\u0219i probleme. Solu\u021bia universal\u0103 \u00een cazul nostru nu depinde de implementarea registrului, deoarece este executat\u0103 \u00een afara registrelor \u0219i ofer\u0103 un comportament uniform pentru toate.<\/i><\/p>\n

    De\u0219i folosim werf ca exemplu de implementare, sper\u0103m c\u0103 abord\u0103rile utilizate vor fi utile \u0219i altor echipe care se confrunt\u0103 cu dificult\u0103\u021bi similare.<\/p>\n

    A\u0219adar, ne-am ocupat de implementarea extern\u0103<\/i> a unui mecanism de cur\u0103\u021bare a imaginilor \u2014 \u00een locul posibilit\u0103\u021bilor care sunt deja integrate \u00een registrele de containere. Primul pas a fost utilizarea Docker Registry API pentru a crea acelea\u0219i politici primitive referitoare la num\u0103rul de etichete \u0219i timpul de creare a acestora (men\u021bionate mai sus). Acestea au fost completate cu o list\u0103 permisiv\u0103 bazat\u0103 pe imaginile utilizate \u00een infrastructura desf\u0103\u0219urat\u0103<\/strong>, adic\u0103 Kubernetes. Pentru acesta, a fost suficient s\u0103 parcurgem toate resursele implementate prin API-ul Kubernetes \u0219i s\u0103 ob\u021binem o list\u0103 de valori. imagine<\/code>.<\/p>\n

    Aceast\u0103 solu\u021bie trivial\u0103 a rezolvat cea mai critic\u0103 problem\u0103 (criteriul nr. 1), dar a fost doar \u00eenceputul c\u0103l\u0103toriei noastre pentru \u00eembun\u0103t\u0103\u021birea mecanismului de cur\u0103\u021bare. Urm\u0103torul \u2014 \u0219i mult mai interesant \u2014 pas a fost solu\u021bia de a lega imaginile publicate de istoricul Git<\/strong>.<\/p>\n

    Scheme de etichetare<\/h3>\n

    \nLa \u00eenceput, am ales o abordare \u00een care imaginea final\u0103 trebuia s\u0103 stocheze informa\u021biile necesare pentru cur\u0103\u021bare, \u0219i am construit procesul pe baza schemelor de etichetare. La publicarea imaginii, utilizatorul a ales o anumit\u0103 op\u021biune de etichetare (git-branch<\/code>, git-commit<\/code> sau git-tag<\/code>) \u0219i a folosit valoarea corespunz\u0103toare. \u00cen sistemele CI, setarea acestor valori a fost realizat\u0103 automat pe baza variabilelor de mediu. Practic imaginea final\u0103 a fost legat\u0103 de un anumit element Git<\/strong>, p\u0103str\u00e2nd datele necesare pentru cur\u0103\u021bare \u00een etichete.<\/p>\n

    \u00cen cadrul acestei abord\u0103ri, a rezultat un set de politici care permitea utilizarea Git ca singur\u0103 surs\u0103 de adev\u0103r:<\/p>\n