{"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 pastrimit \u201cinteligjent\u201d 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 homolog\u00ebt e tij) n\u00eb realitetin e pipelines moderne CI\/CD p\u00ebr aplikacione cloud native q\u00eb dor\u00ebzohen n\u00eb Kubernetes. Jan\u00eb paraqitur kriteret kryesore p\u00ebr relevanc\u00ebn e imazheve dhe v\u00ebshtir\u00ebsit\u00eb q\u00eb lindin nga ato gjat\u00eb automatizimit t\u00eb pastrimit, ruajtjes s\u00eb hap\u00ebsir\u00ebs dhe p\u00ebrmbushjes s\u00eb k\u00ebrkesave t\u00eb skuadrave. S\u00eb fundi, me shembuj konkret\u00eb nga nj\u00eb projekt Open Source, do t\u00eb tregojm\u00eb se si k\u00ebto v\u00ebshtir\u00ebsi mund t\u00eb tejkalohen.<\/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 shtuar ndjesh\u00ebm kostot e saj. P\u00ebr t\u00eb kontrolluar, kufizuar ose mbajtur nj\u00eb rritje t\u00eb pranueshme t\u00eb hap\u00ebsir\u00ebs s\u00eb z\u00ebn\u00eb n\u00eb registry, \u00ebsht\u00eb e zakonshme:<\/p>\n

    \n
  1. t\u00eb p\u00ebrdoren nj\u00eb num\u00ebr fikse etiketash p\u00ebr imazhet;<\/li>\n
  2. t\u00eb pastrohen imazhet n\u00eb nj\u00ebfar\u00eb m\u00ebnyre.<\/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 vazhdueshme (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> etj.), regjistri nuk do t\u00eb fryhet n\u00eb madh\u00ebsi dhe p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb nuk do t\u00eb mendohet as p\u00ebr pastrimin. N\u00eb fund t\u00eb fundit, t\u00eb gjith\u00eb imazhet jo-relevante p\u00ebrzihen dhe p\u00ebr pastrimin thjesht nuk mbetet pun\u00eb (gjith\u00e7ka b\u00ebhet nga mbledh\u00ebsi standard i mbeturinave).<\/p>\n

    Megjithat\u00eb, ky qasje e kufizon shum\u00eb zhvillimin dhe rrall\u00eb zbatohet n\u00eb CI\/CD t\u00eb projekteve moderne. Nj\u00eb pjes\u00eb e pandashme e zhvillimit \u00ebsht\u00eb automatizimi<\/strong>, i cili lejon q\u00eb t\u00eb testohet, zhvillohet dhe dor\u00ebzohet shum\u00eb m\u00eb shpejt funksionaliteti i ri p\u00ebr p\u00ebrdoruesit. P\u00ebr shembull, n\u00eb t\u00eb gjitha projektet tona, me \u00e7do commit, krijohet automatikisht nj\u00eb pipeline CI. N\u00eb t\u00eb, nd gathered imazhi, testohet, shp\u00ebrndahet n\u00eb konture t\u00eb ndryshme Kubernetes p\u00ebr debug dhe kontrollet e tjera, dhe n\u00ebse gjith\u00e7ka shkon mir\u00eb \u2014 ndryshimet arrijn\u00eb te p\u00ebrdoruesi i fundit. Dhe kjo nuk \u00ebsht\u00eb m\u00eb nj\u00eb shkenc\u00eb raketore, por nj\u00eb p\u00ebrditshm\u00ebri p\u00ebr shum\u00eb \u2014 ndoshta edhe p\u00ebr ju, pasi po lexoni k\u00ebt\u00eb artikull.<\/p>\n

    Duke pasur parasysh se eliminimi i bug-eve dhe zhvillimi i funksionalitetit t\u00eb ri b\u00ebhet paralelisht, dhe l\u00ebshimet mund t\u00eb realizohen 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 commit-esh, dhe p\u00ebr pasoj\u00eb \u2014 nj\u00eb num\u00ebr t\u00eb madh imazhesh n\u00eb registry<\/strong>. Si rezultat, ndodhet n\u00eb m\u00ebnyr\u00eb urgjente nevoja p\u00ebr organizimin e nj\u00eb pastrimi efektiv t\u00eb registry-t, dmth. eliminimin e imazheve jo-relevante.<\/p>\n

    Poros si t\u00eb p\u00ebrcaktohet n\u00ebse nj\u00eb imazh \u00ebsht\u00eb aktual?<\/p>\n

    Kriteret e aktualitetit t\u00eb imazhit<\/h2>\n

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

    1. E para (m\u00eb e dukshme dhe m\u00eb kritike nga t\u00eb gjitha) \u2014 jan\u00eb imazhet q\u00eb po p\u00ebrdoren n\u00eb Kubernetes<\/strong>. Eliminimi i k\u00ebtyre imazheve mund t\u00eb \u00e7oj\u00eb n\u00eb kosto t\u00eb m\u00ebdha p\u00ebr shkak t\u00eb pushimit t\u00eb production (p\u00ebr shembull, imazhet mund t\u00eb nevojiten gjat\u00eb replikimit) ose t\u00eb shfuqizoj\u00eb p\u00ebrpjekjet e ekipit q\u00eb merret me debug n\u00eb ndonj\u00eb nga linjat. (P\u00ebr k\u00ebt\u00eb arsye, ne madje kemi b\u00ebr\u00eb nj\u00eb <\/i>Prometheus exporter<\/i><\/a><\/noindex>, q\u00eb monitoron munges\u00ebn e k\u00ebtyre imazheve 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 lidhet me operimin) \u2014 jan\u00eb imazhet q\u00eb nevojiten p\u00ebr rikthim n\u00eb rast se shfaqen probleme serioze<\/strong> n\u00eb versionin aktual. P\u00ebr shembull, n\u00eb rastin e Helm-it, k\u00ebto jan\u00eb imazhet q\u00eb p\u00ebrdoren n\u00eb versionet e ruajtura t\u00eb l\u00ebshimit. (P\u00ebr t'u th\u00ebn\u00eb, si parazgjedhje n\u00eb Helm, ka nj\u00eb kufi prej 256 rishikimesh, por v\u00ebshtir\u00eb se dikush ka nevoj\u00eb reale p\u00ebr ruajtjen e nj\u00eb<\/i> kaq shum\u00eb versioneve?..) Sepse ne, p\u00ebr shembull, ruajm\u00eb versionet, q\u00eb t\u00eb mund t'i p\u00ebrdorim m\u00eb pas, dmth. 't\u00eb rikthemi' n\u00eb to kur t\u00eb jet\u00eb e nevojshme.<\/p>\n

    3. E treta \u2014 nevojat e zhvilluesve<\/strong>: t\u00eb gjith\u00eb imazhet q\u00eb lidhen me pun\u00ebt e tyre aktuale. P\u00ebr shembull, n\u00ebse po shqyrtojm\u00eb nj\u00eb PR, ka shum\u00eb kuptim t\u00eb l\u00ebm\u00eb nj\u00eb imazh q\u00eb korrespondon me commit-in e fundit dhe, le t\u00eb themi, commit-in e m\u00ebparsh\u00ebm: k\u00ebshtu zhvilluesi mund t\u00eb rikthehet shpejt te \u00e7do detyr\u00eb dhe t\u00eb punoj\u00eb me ndryshimet e fundit. <\/p>\n

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

    NB: Kriteret e p\u00ebrcaktuara k\u00ebtu jan\u00eb formuluar mbi p\u00ebrvoj\u00ebn e bashk\u00ebpunimit me dhjet\u00ebra ekipe zhvillimi nga kompani t\u00eb ndryshme. Megjithat\u00eb, sigurisht, n\u00eb var\u00ebsi t\u00eb ve\u00e7orive n\u00eb proceset e zhvillimit dhe infrastruktur\u00ebs s\u00eb p\u00ebrdorur (p\u00ebr shembull, n\u00ebse nuk p\u00ebrdoret Kubernetes), 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 container registry zakonisht ofrojn\u00eb politikat e tyre t\u00eb pastrimit t\u00eb imazheve: n\u00eb to mund t\u00eb p\u00ebrcaktoni kushtet n\u00ebn t\u00eb cilat etiketa fshihet nga registry. Megjithat\u00eb, mund\u00ebsit\u00eb e k\u00ebtyre kushteve jan\u00eb t\u00eb kufizuara nga parametra si emrat, koha e krijimit dhe numri i etiketimeve*.<\/p>\n

    * Varet nga realizimet e ve\u00e7anta 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 deri m\u00eb shtator 2020.<\/i><\/p>\n

    Ky grup parametrash \u00ebsht\u00eb mjaft i mjaftuesh\u00ebm p\u00ebr t\u00eb p\u00ebrmbushur kriterin e kat\u00ebrt \u2014 dometh\u00ebn\u00eb, p\u00ebr t\u00eb filtruar imazhet q\u00eb p\u00ebrkojn\u00eb me versionet. Megjithat\u00eb, p\u00ebr t\u00eb gjitha kriteret e tjera duhet t\u00eb zgjidhni ndonj\u00eb zgjidhje kompromisi (nj\u00eb politik\u00eb m\u00eb t\u00eb ashp\u00ebr ose p\u00ebrkundrazi, m\u00eb t\u00eb but\u00eb) \u2014 n\u00eb var\u00ebsi t\u00eb pritshm\u00ebrive dhe mund\u00ebsive financiare.<\/p>\n

    P\u00ebr shembull, kriteri i tret\u00eb \u2014 i lidhur me nevojat e zhvilluesve \u2014 mund t\u00eb zgjidhet n\u00ebp\u00ebrmjet organizimit t\u00eb proceseve brenda ekipeve: em\u00ebrtimi specifik i imazheve, mbajtja e listave t\u00eb miratuara dhe marr\u00ebveshjeve t\u00eb brendshme. Por n\u00eb fund t\u00eb fundit, p\u00ebrs\u00ebri duhet ta automatizoni. Dhe n\u00ebse mund\u00ebsit\u00eb e zgjidhjeve t\u00eb gatshme nuk jan\u00eb t\u00eb mjaftueshme, duhet t\u00eb b\u00ebni di\u00e7ka t\u00eb vet\u00ebzhb\u00ebsuar.<\/p>\n

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

    Ilustrimi i workflow n\u00eb Git<\/h3>\n

    \nSupozoni se punoni n\u00eb nj\u00eb skem\u00eb t\u00eb till\u00eb n\u00eb Git:<\/p>\n

    \"Problemi
    \n
    \nImazhet e kontejner\u00ebve q\u00eb jan\u00eb aktualisht t\u00eb implementuara n\u00eb Kubernetes p\u00ebr ndonj\u00eb p\u00ebrdorues (p\u00ebrdoruesit p\u00ebrfundimtar\u00eb, testuesit, menaxher\u00ebt etj.) ose p\u00ebrdoren nga zhvilluesit p\u00ebr debagimin dhe q\u00ebllime t\u00eb ngjashme sh\u00ebnohen me nj\u00eb ikon\u00eb t\u00eb kok\u00ebs n\u00eb diagram.<\/i><\/p>\n

    \u00c7far\u00eb do t\u00eb ndodhte n\u00ebse politikat e pastrimit lejojn\u00eb l\u00ebnien (mosfshirjen) e imazheve vet\u00ebm n\u00ebn emrat e caktuar t\u00eb etiketimeve<\/b>?<\/p>\n

    \"Problemi
    \n
    \nSigurisht, nj\u00eb skenar i till\u00eb nuk do t\u00eb k\u00ebnaqte ask\u00ebnd.<\/p>\n

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

    \"Problemi
    \n
    \nRezultati \u00ebsht\u00eb p\u00ebrmir\u00ebsuar ndjesh\u00ebm, megjithat\u00eb, ende \u00ebsht\u00eb larg nga ideali. Sepse kemi ende zhvillues q\u00eb kan\u00eb nevoj\u00eb p\u00ebr imazhe n\u00eb registrin (ose madje t\u00eb implementuara n\u00eb K8s) p\u00ebr t\u00eb debaguar gabimet...<\/p>\n

    P\u00ebrmbledhsh\u00ebm, situata e tregut tregon se funksionalitetet e disponueshme n\u00eb regjistrat e konteiner\u00ebve nuk ofrojn\u00eb mjaft fleksibilitet n\u00eb pastrimin, dhe arsyeja kryesore p\u00ebr k\u00ebt\u00eb \u00ebsht\u00eb mungesa e mund\u00ebsis\u00eb p\u00ebr t\u00eb nd\u00ebrvepruar me bot\u00ebn e jashtme<\/strong>. Nd\u00ebrsa ekipet q\u00eb kan\u00eb nevoj\u00eb p\u00ebr nj\u00eb fleksibilitet t\u00eb till\u00eb, detyrohen t\u00eb realizojn\u00eb vet\u00eb fshirjen e imazheve \"nga jasht\u00eb\", duke p\u00ebrdorur API-n\u00eb e Docker Registry (ose API-n\u00eb natyrore t\u00eb implementimit p\u00ebrkat\u00ebs).<\/p>\n

    Megjithat\u00eb, ne k\u00ebrkonim nj\u00eb zgjidhje universale q\u00eb do t\u00eb automatizonte pastrimin e imazheve p\u00ebr ekzistenc\u00eb t\u00eb ndryshme ekipesh q\u00eb p\u00ebrdorin regjistra t\u00eb ndrysh\u00ebm\u2026<\/p>\n

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

    \nNga ka lindur kjo nevoj\u00eb? \u00cbsht\u00eb se ne nuk jemi nj\u00eb grup zhvilluesish t\u00eb ve\u00e7ant\u00eb, por nj\u00eb ekip q\u00eb sh\u00ebrben nj\u00eb s\u00ebr\u00eb grupeve t\u00eb tilla, duke ndihmuar n\u00eb zgjidhjen e problemeve CI\/CD n\u00eb m\u00ebnyr\u00eb gjith\u00ebp\u00ebrfshir\u00ebse. Dhe instrumenti yn\u00eb teknik kryesor p\u00ebr k\u00ebt\u00eb \u00ebsht\u00eb utilitarja Open Source werf<\/a><\/noindex>. Ve\u00e7oria e saj \u00ebsht\u00eb se ajo nuk realizon nj\u00eb funksion t\u00eb vet\u00ebm, por shoq\u00ebron proceset e d\u00ebrgimit t\u00eb vazhduesh\u00ebm n\u00eb t\u00eb gjitha fazat: nga nd\u00ebrtimi deri tek vendosja.<\/p>\n

    Publikimi i imazheve n\u00eb regjist\u00ebr* (menj\u00ebher\u00eb pas nd\u00ebrtimit t\u00eb tyre) \u00ebsht\u00eb nj\u00eb funksion i qart\u00eb i nj\u00eb utilitare t\u00eb till\u00eb. Dhe p\u00ebr sa koh\u00eb q\u00eb imazhet ruhen aty, n\u00ebse ruajtja juaj nuk \u00ebsht\u00eb e pafund, \u00ebsht\u00eb e nevojshme t\u00eb merret gjithashtu me pastrimin e tyre t\u00eb m\u00ebvonsh\u00ebm. Si arrit\u00ebm suksese n\u00eb k\u00ebt\u00eb, duke plot\u00ebsuar t\u00eb gjitha kriteret e caktuara, do t\u00eb flasim m\u00eb posht\u00eb.<\/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. Zgjidhja universale n\u00eb rastin ton\u00eb nuk varet nga implementimi i regjistrit, pasi realizohet jasht\u00eb vet\u00eb regjistrave dhe ofron nj\u00eb sjellje t\u00eb nj\u00ebjt\u00eb p\u00ebr t\u00eb gjith\u00eb.<\/i><\/p>\n

    Megjith\u00ebse 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 p\u00ebr ekipe t\u00eb tjera q\u00eb hasin v\u00ebshtir\u00ebsi t\u00eb ngjashme.<\/p>\n

    Pra, ne u angazhuam n\u00eb<\/i> implementimin e mekanizmit p\u00ebr pastrimin e imazheve \u2014 n\u00eb vend t\u00eb mund\u00ebsive q\u00eb tashm\u00eb jan\u00eb t\u00eb integruara n\u00eb regjistrat e konteiner\u00ebve. Hapi i par\u00eb ishte p\u00ebrdorimi i API-s\u00eb s\u00eb Docker Registry p\u00ebr t\u00eb krijuar disa politika primitive n\u00eb lidhje me numrin e etiketave dhe koh\u00ebn e krijimit t\u00eb tyre (t\u00eb p\u00ebrmendura m\u00eb lart). K\u00ebtyre iu shtua lista e lejuar bazuar n\u00eb imazhet q\u00eb p\u00ebrdoren n\u00eb infrastruktur\u00ebn e vendosur<\/strong>, pra Kubernetes. P\u00ebr t\u00eb fundit, ishte e mjaftueshme t\u00eb kalonim p\u00ebrmes API-s\u00eb Kubernetes p\u00ebr t\u00eb skanuar t\u00eb gjith\u00eb burimet e derdhura dhe p\u00ebr t\u00eb marr\u00eb 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 t\u00eb p\u00ebrmir\u00ebsuar mekanizmin e pastrimit. Hapi tjet\u00ebr \u2014 dhe m\u00eb interesanti \u2014 ishte zgjidhja p\u00ebr t\u00eb lidhur imazhet publikuese me historin\u00eb e Git.<\/strong>.<\/p>\n

    Skemat e etiketimit.<\/h3>\n

    \nN\u00eb fillim, ne zgjodh\u00ebm nj\u00eb qasje ku imazhi p\u00ebrfundimtar duhet t\u00eb mbante informacionin e nevojsh\u00ebm p\u00ebr pastrimin dhe organizuam procesin mbi skemat e etiketimit. Kur b\u00ebhej publikimi i imazhit, p\u00ebrdoruesi zgjidhte nj\u00eb opsion t\u00eb ve\u00e7ant\u00eb 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 baz\u00eb t\u00eb variablave t\u00eb ambientit. N\u00eb thelb imazhi p\u00ebrfundimtar lidhej me nj\u00eb primitiv t\u00eb caktuar t\u00eb 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