{"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\/sq\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Problemi i 'p\u00ebrgjithsh\u00ebm' t\u00eb pastrimit t\u00eb imazheve t\u00eb kontejner\u00ebve dhe zgjidhja e tij n\u00eb werf.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Problemi
\n
\nArtikulli shqyrton problematik\u00ebn e pastrimit t\u00eb imazheve q\u00eb grumbullohen n\u00eb regjistrat e kontejner\u00ebve (Docker Registry dhe analog\u00ebt e tij) n\u00eb kontekstin e pipeline-ve moderne CI\/CD p\u00ebr aplikacione cloud native, t\u00eb shp\u00ebrndara n\u00eb Kubernetes. Paraqiten kritere kryesore t\u00eb relevanc\u00ebs s\u00eb imazheve dhe v\u00ebshtir\u00ebsit\u00eb q\u00eb rrjedhin prej tyre gjat\u00eb automatizimit t\u00eb pastrimit, ruajtjes s\u00eb hap\u00ebsir\u00ebs dhe p\u00ebrmbushjes s\u00eb nevojave t\u00eb ekipeve. N\u00eb fund, me shembuj nga nj\u00eb projekt konkret Open Source, do t\u00eb tregojm\u00eb se si mund t\u00eb kap\u00ebrcehen k\u00ebto sfida.<\/p>\n

Hyrje<\/h2>\n

\nNumri i imazheve n\u00eb regjistrin e kontejner\u00ebve mund t\u00eb rritet shpejt, duke z\u00ebn\u00eb m\u00eb shum\u00eb hap\u00ebsir\u00eb n\u00eb ruajtje dhe, p\u00ebr pasoj\u00eb, duke rritur ndjesh\u00ebm koston e saj. P\u00ebr t\u00eb kontrolluar, kufizuar ose mbajtur nj\u00eb rritje t\u00eb pranueshme t\u00eb hap\u00ebsir\u00ebs q\u00eb z\u00eb n\u00eb registry, miratohet:<\/p>\n

    \n
  1. t\u00eb p\u00ebrdoren nj\u00eb num\u00ebr fikse etiketash p\u00ebr imazhet;<\/li>\n
  2. ndonj\u00eb m\u00ebnyr\u00eb p\u00ebr t\u00eb pastruar imazhet.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nKufizimi i par\u00eb ndonj\u00ebher\u00eb \u00ebsht\u00eb i pranuesh\u00ebm p\u00ebr ekipe t\u00eb vogla. N\u00ebse zhvilluesve u mjaftojn\u00eb etiketat e p\u00ebrhershme (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> dhe t\u00eb tilla), regjistri nuk do t\u00eb fryhet n\u00eb p\u00ebrmasa dhe p\u00ebr nj\u00eb periudh\u00eb t\u00eb gjat\u00eb nuk do t\u00eb mendoni fare p\u00ebr pastrimin. T\u00eb gjitha imazhet e pasakt\u00ebsuara shuhen, dhe p\u00ebr pastrimin nuk mbetet asnj\u00eb pun\u00eb (gjith\u00e7ka b\u00ebhet nga mbledh\u00ebsi i zakonsh\u00ebm i mbeturinave).<\/p>\n

    Megjithat\u00eb, ky qasje kufizon shum\u00eb zhvillimin dhe \u00ebsht\u00eb rrall\u00eb e aplikueshme p\u00ebr CI\/CD-t\u00eb e projekteve moderne. Nj\u00eb pjes\u00eb e pandashme e zhvillimit \u00ebsht\u00eb b\u00ebr\u00eb automatizimi<\/strong>, q\u00eb lejon testimin, implementimin dhe shp\u00ebrndarjen e funksionaliteteve t\u00eb reja p\u00ebr p\u00ebrdoruesit shum\u00eb m\u00eb shpejt. P\u00ebr shembull, n\u00eb t\u00eb gjitha projektet tona, me \u00e7do komit automatikisht krijohet nj\u00eb pipeline CI. Aty krijohet imazhi, testohet, vendoset n\u00eb kontejner\u00ebt e ndrysh\u00ebm Kubernetes p\u00ebr debugim dhe kontroll t\u00eb mbetur, dhe n\u00ebse gjith\u00e7ka shkon mir\u00eb \u2014 ndryshimet arrijn\u00eb deri te p\u00ebrdoruesi p\u00ebrfundimtar. Dhe kjo nuk \u00ebsht\u00eb m\u00eb rocket science, por nj\u00eb gj\u00eb e zakonshme p\u00ebr shum\u00eb - ndoshta edhe p\u00ebr ju, q\u00eb po e lexoni k\u00ebt\u00eb artikull.<\/p>\n

    Duke pasur parasysh q\u00eb eliminimi i gabimeve dhe zhvillimi i funksionaliteteve t\u00eb reja b\u00ebhet paralelisht, dhe l\u00ebshimet mund t\u00eb kryhen disa her\u00eb n\u00eb dit\u00eb, \u00ebsht\u00eb e qart\u00eb se procesi i zhvillimit shoq\u00ebrohet me nj\u00eb num\u00ebr t\u00eb konsideruesh\u00ebm komit\u00ebsh, dhe kjo do t\u00eb thot\u00eb \u2014 numri i madh i imazheve n\u00eb registry<\/strong>. Si rezultat, lind me urgjenc\u00eb \u00e7\u00ebshtja e organizimit t\u00eb nj\u00eb pastrimi efektiv t\u00eb registry-t, dmth, eliminimi i imazheve jo relevante.<\/p>\n

    Por si t\u00eb p\u00ebrcaktojm\u00eb n\u00eb t\u00eb v\u00ebrtet\u00eb, a \u00ebsht\u00eb imazhi i r\u00ebnd\u00ebsish\u00ebm?<\/p>\n

    Kriteret e r\u00ebnd\u00ebsishm\u00ebris\u00eb s\u00eb imazhit<\/h2>\n

    \nN\u00eb shumic\u00ebn d\u00ebrrmuese t\u00eb rasteve, kriteret kryesore do t\u00eb jen\u00eb si m\u00eb posht\u00eb:<\/p>\n

    1. E para (m\u00eb e dukshme dhe m\u00eb kritike nga t\u00eb gjitha) \u2014 jan\u00eb imazhet q\u00eb n\u00eb k\u00ebt\u00eb moment po p\u00ebrdoren n\u00eb Kubernetes<\/strong>. Eliminimi i k\u00ebtyre imazheve mund t\u00eb \u00e7oj\u00eb n\u00eb kosto t\u00eb r\u00ebnd\u00ebsishme p\u00ebr shkak t\u00eb nd\u00ebrprerjes s\u00eb prodhimit (p\u00ebr shembull, imazhet mund t\u00eb nevojiten p\u00ebr replikim) ose t\u00eb minoj\u00eb p\u00ebrpjekjet e ekipit q\u00eb merret me debugimin n\u00eb ndonj\u00eb nga sektor\u00ebt. (P\u00ebr k\u00ebt\u00eb arsye, ne madje krijuam nj\u00eb <\/i>Prometheus exporter<\/i><\/a><\/noindex>, q\u00eb monitoron munges\u00ebn e imazheve t\u00eb tilla n\u00eb \u00e7do klaster Kubernetes.)<\/i><\/p>\n

    2. E dyta (m\u00eb pak e dukshme, por gjithashtu shum\u00eb e r\u00ebnd\u00ebsishme dhe p\u00ebrs\u00ebri lidhur me operimin) \u2014 imazhet q\u00eb nevojiten p\u00ebr kthim mbrapa n\u00eb rast se zbulohet ndonj\u00eb problem serioz<\/strong> n\u00eb versionin aktual. P\u00ebr shembull, n\u00eb rastin e Helm, k\u00ebto jan\u00eb imazhet q\u00eb p\u00ebrdoren n\u00eb versionet e ruajtura t\u00eb l\u00ebshimit. (P\u00ebr not\u00eb, me default n\u00eb Helm ka nj\u00eb limit prej 256 rishikimesh, por ndoshta askush nuk ka nevoj\u00eb realisht p\u00ebr ruajtjen e tillave<\/i> nj\u00eb numri t\u00eb till\u00eb t\u00eb madh versionesh?..) Ajo q\u00eb ne, p\u00ebr shembull, i ruajm\u00eb versionet \u00ebsht\u00eb p\u00ebr t'i p\u00ebrdorur m\u00eb von\u00eb, dmth. \"t\u00eb kthehemi\" n\u00eb to n\u00eb rast nevoje.<\/p>\n

    3. T\u00eb tretin \u2014 nevojat e zhvilluesve<\/strong>: t\u00eb gjitha imazhet q\u00eb lidhen me pun\u00ebt e tyre t\u00eb tanishme. P\u00ebr shembull, n\u00ebse po shqyrtojm\u00eb PR, ka kuptim t\u00eb l\u00ebshohet nj\u00eb imazh q\u00eb p\u00ebrkon me commitin m\u00eb t\u00eb fundit dhe, le t\u00eb themi, commitin e m\u00ebparsh\u00ebm: k\u00ebshtu zhvilluesi do t\u00eb mund t\u00eb kthehet shpejt n\u00eb \u00e7do detyr\u00eb dhe t\u00eb punoj\u00eb me ndryshimet e fundit. <\/p>\n

    4. T\u00eb kat\u00ebrtin \u2014 imazhet q\u00eb p\u00ebrkojn\u00eb me versionet e aplikacionit ton\u00eb<\/strong>, dmth. jan\u00eb produkti p\u00ebrfundimtar: v1.0.0, 20.04.01, sierra etj.<\/p>\n

    NB: Kritere q\u00eb jan\u00eb p\u00ebrcaktuar k\u00ebtu jan\u00eb formuluar n\u00eb baz\u00eb t\u00eb p\u00ebrvoj\u00ebs s\u00eb bashk\u00ebpunimit me nj\u00ebzetra ekipe zhvilluesish nga kompani t\u00eb ndryshme. Megjithat\u00eb, natyrisht, n\u00eb var\u00ebsi t\u00eb ve\u00e7antive n\u00eb proceset e zhvillimit dhe infrastruktur\u00ebs s\u00eb p\u00ebrdorur (p.sh., n\u00ebse Kubernetes nuk p\u00ebrdoret), k\u00ebto kritere mund t\u00eb ndryshojn\u00eb. <\/p>\n

    P\u00ebrputhshm\u00ebria me kriteret dhe zgjidhjet ekzistuese<\/h2>\n

    \nSh\u00ebrbimet e njohura me registry t\u00eb kontejner\u00ebve, zakonisht ofrojn\u00eb politikat e tyre p\u00ebr pastrimin e imazheve: n\u00eb to mund t\u00eb p\u00ebrcaktoni kushtet n\u00eb t\u00eb cilat nj\u00eb etiket\u00eb largohet nga registry. Megjithat\u00eb, mund\u00ebsit\u00eb e k\u00ebtyre kushteve kufizohen deri n\u00eb parametra t\u00eb till\u00eb si emrat, koha e krijimit dhe numri i etiketave*.<\/p>\n

    * Varet nga zbatimet specifike t\u00eb container registry. Ne shqyrtuam mund\u00ebsit\u00eb e zgjidhjeve t\u00eb m\u00ebposhtme: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 n\u00eb gjendje deri m\u00eb shtator 2020.<\/i><\/p>\n

    Ky set parametrash \u00ebsht\u00eb mjaft i mjaftuesh\u00ebm p\u00ebr t\u00eb p\u00ebrmbushur kriterin e kat\u00ebrt \u2014 q\u00eb do t\u00eb thot\u00eb t\u00eb zgjedh\u00ebsh imazhe q\u00eb p\u00ebrputhen me versionet. Megjithat\u00eb, p\u00ebr t\u00eb gjitha kriteret e tjera, duhet t\u00eb zgjidhni nj\u00eb zgjidhje kompromisi (nj\u00eb politik\u00eb m\u00eb t\u00eb ashp\u00ebr ose, p\u00ebrkundrazi, m\u00eb leht\u00ebsuese) \u2014 var\u00ebsisht nga pritshm\u00ebrit\u00eb dhe mund\u00ebsit\u00eb financiare.<\/p>\n

    P\u00ebr shembull, kriteri i tret\u00eb \u2014 i lidhur me nevojat e zhvilluesve \u2014 mund t\u00eb zgjidhet p\u00ebrmes organizimit t\u00eb proceseve brenda ekipeve: em\u00ebrtimi specifik i imazheve, mbajtja e listave t\u00eb lejuara dhe marr\u00ebveshjet e brendshme. Por, n\u00eb fund t\u00eb fundit, \u00ebsht\u00eb e nevojshme ta automatizoni at\u00eb. Dhe n\u00ebse mund\u00ebsit\u00eb e zgjidhjeve t\u00eb gatshme nuk mjaftojn\u00eb, duhet t\u00eb b\u00ebni di\u00e7ka t\u00eb vetme.<\/p>\n

    Situata me dy kriteret e para \u00ebsht\u00eb e ngjashme: ato nuk mund t\u00eb p\u00ebrmbushen pa marr\u00eb t\u00eb dh\u00ebna nga nj\u00eb sistem t\u00eb jasht\u00ebm \u2014 ai q\u00eb zhvillohet aplikacioneve (n\u00eb rastin ton\u00eb, kjo \u00ebsht\u00eb Kubernetes).<\/p>\n

    Ilustrimi i fluksit t\u00eb pun\u00ebs n\u00eb Git<\/h3>\n

    \nSupozoni se punoni p\u00ebraf\u00ebrsisht sipas k\u00ebsaj skeme n\u00eb Git:<\/p>\n

    \"Problemi
    \n
    \nIkona me kok\u00eb n\u00eb diagram tregon imazhet e konteiner\u00ebve, t\u00eb cilat jan\u00eb aktualisht t\u00eb vendosura n\u00eb Kubernetes p\u00ebr disa p\u00ebrdorues (p\u00ebrdoruesit e fundit, testuesit, menaxher\u00ebt etj.) ose p\u00ebrdoren nga zhvilluesit p\u00ebr debug dhe q\u00ebllime t\u00eb ngjashme.<\/i><\/p>\n

    \u00c7far\u00eb do t\u00eb ndodh\u00eb n\u00ebse politikat e pastrimit lejojn\u00eb q\u00eb t\u00eb lihen (nuk fshihen) imazhe vet\u00ebm p\u00ebr emrat e etiketave t\u00eb caktuara<\/b>?<\/p>\n

    \"Problemi
    \n
    \nSikur nj\u00eb skenar i till\u00eb nuk do t\u00eb g\u00ebzonte ask\u00ebnd.<\/p>\n

    \u00c7far\u00eb do t\u00eb ndryshoj\u00eb n\u00ebse politikat lejojn\u00eb t\u00eb mos fshihen imazhet p\u00ebr nj\u00eb interval t\u00eb caktuar kohor \/ numrin e komiteteve m\u00eb t\u00eb fundit<\/b>?<\/p>\n

    \"Problemi
    \n
    \nRezultati \u00ebsht\u00eb p\u00ebrmir\u00ebsuar ndjesh\u00ebm, megjithat\u00eb, ende \u00ebsht\u00eb larg idealit. Sepse kemi ende zhvillues q\u00eb kan\u00eb nevoj\u00eb p\u00ebr imazhe n\u00eb regjistrin (ose madje t\u00eb vendosura n\u00eb K8s) p\u00ebr debug t\u00eb gabimeve\u2026<\/p>\n

    Duke p\u00ebrmbledhur situat\u00ebn aktuale n\u00eb treg: funksionet e disponueshme n\u00eb regjistrat e konteiner\u00ebve nuk ofrojn\u00eb fleksibilitet t\u00eb mjaftuesh\u00ebm gjat\u00eb pastrimit, dhe shkaku kryesor \u00ebsht\u00eb nuk ka mund\u00ebsi p\u00ebr t\u00eb bashk\u00ebvepruar me bot\u00ebn e jashtme<\/strong>. K\u00ebshtu q\u00eb ekipet q\u00eb kan\u00eb nevoj\u00eb p\u00ebr nj\u00eb fleksibilitet t\u00eb till\u00eb, jan\u00eb t\u00eb detyruara t\u00eb implementojn\u00eb vet\u00eb fshirjen e imazheve \"jasht\u00eb\", duke p\u00ebrdorur API-n\u00eb e Docker Registry (ose API-n\u00eb native t\u00eb implementimit p\u00ebrkat\u00ebs).<\/p>\n

    Megjithat\u00eb, ne k\u00ebrkonim nj\u00eb zgjidhje universale q\u00eb do t\u00eb automatizonte procesin e pastrimit t\u00eb imazheve p\u00ebr grupe t\u00eb ndryshme, duke p\u00ebrdorur regjistra t\u00eb ndrysh\u00ebm...<\/p>\n

    Rruga jon\u00eb drejt nj\u00eb pastrimi universale t\u00eb imazheve<\/h2>\n

    \nPse ka nj\u00eb nevoj\u00eb t\u00eb till\u00eb? Kjo ndodh sepse ne nuk jemi vet\u00ebm nj\u00eb grup zhvilluesish, por nj\u00eb ekip q\u00eb sh\u00ebrben menj\u00ebher\u00eb p\u00ebr shum\u00eb grupe, duke ndihmuar n\u00eb zgjidhjen e pyetjeve CI\/CD n\u00eb m\u00ebnyr\u00eb gjith\u00ebp\u00ebrfshir\u00ebse. Dhe mjeti yn\u00eb kryesor teknik p\u00ebr k\u00ebt\u00eb \u00ebsht\u00eb nj\u00eb mjet Open Source. werf<\/a><\/noindex>. Karakteristika e tij \u00ebsht\u00eb se ai nuk kryen nj\u00eb funksion t\u00eb vet\u00ebm, por shoq\u00ebron proceset e dor\u00ebzimit t\u00eb vazhduesh\u00ebm n\u00eb t\u00eb gjitha etapet: nga nd\u00ebrtimi deri n\u00eb implementim.<\/p>\n

    D\u00ebrgimi n\u00eb regjistrin* e imazheve (menj\u00ebher\u00eb pas nd\u00ebrtimit t\u00eb tyre) \u00ebsht\u00eb nj\u00eb funksion i duksh\u00ebm i k\u00ebtij mjeti. Dhe n\u00ebse imazhet ruhen atje, at\u00ebher\u00eb - n\u00ebse depoja juaj nuk \u00ebsht\u00eb e pafund - duhet t\u00eb merrni p\u00ebrgjegj\u00ebsi edhe p\u00ebr pastrimin e m\u00ebtejsh\u00ebm t\u00eb tyre. M\u00eb tej do t\u00eb tregojm\u00eb se si arrit\u00ebm t\u00eb kemi sukses n\u00eb k\u00ebt\u00eb, duke p\u00ebrmbushur t\u00eb gjith\u00eb kriteret e caktuara.<\/p>\n

    * Edhe pse regjistrat vet\u00eb mund t\u00eb jen\u00eb t\u00eb ndrysh\u00ebm (Docker Registry, GitLab Container Registry, Harbor etj.), p\u00ebrdoruesit e tyre p\u00ebrballen me t\u00eb nj\u00ebjtat probleme. Nj\u00eb zgjidhje universale n\u00eb rastin ton\u00eb nuk varet nga implementimi i regjistrit, pasi ekzekutohet jasht\u00eb vet\u00eb regjistrave dhe ofron t\u00eb nj\u00ebjtin sjellje p\u00ebr t\u00eb gjith\u00eb.<\/i><\/p>\n

    Megjithat\u00eb, ne p\u00ebrdorim werf si nj\u00eb shembull t\u00eb implementimit, shpresojm\u00eb q\u00eb qasjet e p\u00ebrdorura do t\u00eb jen\u00eb t\u00eb dobishme edhe p\u00ebr ekipet e tjera q\u00eb p\u00ebrballen me v\u00ebshtir\u00ebsi t\u00eb ngjashme.<\/p>\n

    K\u00ebshtu, ne u mor\u00ebm me implementimin<\/i> e nj\u00eb mekanizmi p\u00ebr pastrimin e imazheve \u2014 n\u00eb vend t\u00eb mund\u00ebsive q\u00eb jan\u00eb tashm\u00eb t\u00eb nd\u00ebrtuara n\u00eb regjistrat p\u00ebr kontejner\u00ebt. Hapi i par\u00eb ishte p\u00ebrdorimi i API-t t\u00eb Docker Registry p\u00ebr t\u00eb krijuar ato politika primitive mbi numrin e etiketimeve dhe koh\u00ebn e krijimit t\u00eb tyre (t\u00eb p\u00ebrmendura m\u00eb par\u00eb). Ata mor\u00ebn nj\u00eb list\u00eb lejesh t\u00eb bazuar n\u00eb imazhet q\u00eb p\u00ebrdoren n\u00eb infrastruktur\u00ebn e vendosur<\/strong>, pra, Kubernetes. P\u00ebr k\u00ebt\u00eb t\u00eb fundit, ishte e mjaftueshme q\u00eb p\u00ebrmes API-t t\u00eb Kubernetes t\u00eb kalonim p\u00ebrmes t\u00eb gjitha burimeve t\u00eb vendosura dhe t\u00eb merrnim nj\u00eb list\u00eb me vlera. image<\/code>.<\/p>\n

    Ky zgjidhje triviale zgjidhi problemin m\u00eb kritik (kriteri nr. 1), por ishte vet\u00ebm fillimi i rrug\u00ebtimit ton\u00eb p\u00ebr p\u00ebrmir\u00ebsimin e mekanizmit t\u00eb pastrimit. Hapi tjet\u00ebr \u2014 dhe shum\u00eb m\u00eb interesant \u2014 ishte zgjidhja p\u00ebr t\u00eb lidhur imazhet e publikuara me historin\u00eb e Git<\/strong>.<\/p>\n

    Skemat e etiketimit<\/h3>\n

    \nP\u00ebr t\u00eb filluar, ne zgjodh\u00ebm nj\u00eb qasje ku imazhi p\u00ebrfundimtar duhet t\u00eb ruaj\u00eb informacionin e nevojsh\u00ebm p\u00ebr pastrimin, dhe nd\u00ebrtuam procesin mbi skemat e etiketimit. Gjat\u00eb publikimit t\u00eb imazhit, p\u00ebrdoruesi zgjidhte nj\u00eb opsion t\u00eb caktuar etiketimi (git-branch<\/code>, git-commit<\/code> ose git-tag<\/code>) dhe p\u00ebrdorte vler\u00ebn p\u00ebrkat\u00ebse. N\u00eb sistemet CI, vendosja e k\u00ebtyre vlerave b\u00ebhej automatikisht n\u00eb p\u00ebrputhje me variablat e mjedisit. N\u00eb thelb imazhi p\u00ebrfundimtar lidhej me nj\u00eb primitiv t\u00eb caktuar Git<\/strong>, duke ruajtur t\u00eb dh\u00ebnat e nevojshme p\u00ebr pastrimin n\u00eb etiketa.<\/p>\n

    N\u00eb kuad\u00ebr t\u00eb k\u00ebsaj qasje u krijua nj\u00eb grup politikash q\u00eb lejonin p\u00ebrdorimin e Git si burimi i vet\u00ebm i s\u00eb v\u00ebrtet\u00ebs:<\/p>\n