Masalah "pinter" beberesih gambar wadahna jeung solusi na di werf

Tulisan ngabahas masalah ngabersihkeun gambar anu ngumpulkeun dina pendaptaran wadahna (Docker Registry sareng analogna) dina realitas pipa CI / CD modéren pikeun aplikasi asli awan anu dikirimkeun ka Kubernetes. Kriteria utama pikeun relevansi gambar sareng kasulitan anu ditimbulkeun pikeun ngajadikeun otomatis beberesih, ngahemat rohangan sareng nyumponan kabutuhan tim dipasihkeun. Tungtungna, nganggo conto proyék Open Source khusus, kami bakal nyarioskeun ka anjeun kumaha kasusah ieu tiasa diatasi.

perkenalan

Jumlah gambar dina pendaptaran wadahna bisa tumuwuh gancang, nyokot up leuwih spasi gudang sahingga nyata ngaronjatkeun biaya na. Pikeun ngadalikeun, ngawatesan atawa ngajaga tumuwuhna ditarima tina spasi nempatan dina pendaptaran, éta ditarima:

1. make sajumlah tetep tag pikeun gambar;
2. ngabersihan gambar dina sababaraha cara.

Watesan kahiji kadang ditarima pikeun tim leutik. Lamun pamekar boga cukup tag permanén (latest, main, test, boris jsb), pendaptaran moal ngabareuhan dina ukuran sarta pikeun lila anjeun teu kudu mikir ngeunaan meresihan eta. Barina ogé, sadaya gambar anu teu aya hubunganana dipupus, sareng teu aya deui padamelan pikeun beberesih (sadayana dilakukeun ku tukang sampah biasa).

Sanajan kitu, pendekatan ieu greatly ngawatesan ngembangkeun sarta jarang lumaku pikeun CI modern / proyék CD. Bagian integral tina pangwangunan éta otomatisasi, anu ngamungkinkeun anjeun nguji, nyebarkeun sareng nganteurkeun fungsionalitas énggal ka pangguna langkung gancang. Contona, dina sakabéh proyék urang, pipa CI otomatis dijieun kalawan unggal komitmen. Di jerona, gambar dirakit, diuji, digulung ka sababaraha sirkuit Kubernetes pikeun debugging sareng sésa cék, sareng upami sadayana saé, parobihan ngahontal pangguna akhir. Sareng ieu sanés élmu rokét, tapi kajadian sapopoé pikeun seueur - paling dipikaresep pikeun anjeun, sabab anjeun maca tulisan ieu.

Kusabab ngalereskeun bug sareng ngembangkeun fungsionalitas énggal dilaksanakeun sacara paralel, sareng sékrési tiasa dilakukeun sababaraha kali sadinten, écés yén prosés pamekaran dibarengan ku sajumlah ageung komitmen, anu hartosna angka nu gede ngarupakeun gambar dina pendaptaran. Hasilna, masalah pangatur beberesih éféktif pendaptaran timbul, i.e. miceun gambar teu relevan.

Tapi kumaha anjeun malah nangtukeun naha hiji gambar téh relevan?

Kriteria pikeun relevansi gambar

Dina kalolobaan kasus, kriteria utama bakal kieu:

1. Kahiji (paling atra tur paling kritis sadaya) nyaéta gambar éta ayeuna dipaké dina Kubernetes. Nyoplokkeun gambar ieu bisa ngahasilkeun waragad downtime produksi signifikan (contona, gambar bisa jadi diperlukeun pikeun réplikasi) atawa negate usaha tim debugging on salah sahiji loop. (Ku sabab kitu urang malah nyieun husus Éksportir Prometheus, anu ngalacak henteuna gambar sapertos kitu dina sagala klaster Kubernetes.)

2. Kadua (kirang atra, tapi ogé pohara penting jeung deui relates to eksploitasi) - gambar éta diperlukeun pikeun rollback bisi deteksi masalah serius dina versi ayeuna. Salaku conto, dina kasus Helm, ieu mangrupikeun gambar anu dianggo dina versi pelepasan anu disimpen. (Ku jalan kitu, sacara standar dina Helm watesna nyaéta 256 révisi, tapi sigana mah aya anu leres-leres kedah nyimpen. ieu angka nu gede ngarupakeun versi?..) Barina ogé, urang, hususna, nyimpen versi ku kituna urang bisa make eta engké, i.e. "gulung deui" ka aranjeunna lamun perlu.

3. katilu- kabutuhan pamekar: Sadaya gambar nu patali jeung karya maranéhanana ayeuna. Salaku conto, upami urang nganggap PR, maka masuk akal pikeun ngantunkeun gambar anu cocog sareng komitmen anu terakhir sareng, sebutkeun, komitmen sateuacana: ku cara ieu pamekar tiasa gancang uih deui ka tugas naon waé sareng damel sareng parobihan panganyarna.

4. Kaopat - gambar éta pakait sareng versi aplikasi urang, i.e. mangrupa produk ahir: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, jsb.

NB: Kriteria anu ditetepkeun di dieu dirumuskeun dumasar kana pangalaman berinteraksi sareng puluhan tim pangembangan ti perusahaan anu béda. Nanging, tangtosna, gumantung kana spésifik dina prosés pamekaran sareng infrastruktur anu dianggo (contona, Kubernetes henteu dianggo), kriteria ieu tiasa bénten.

Eligibility jeung solusi aya

Ladenan populér kalayan pendaptaran wadahna, sakumaha aturan, nawiskeun kabijakan ngabersihan gambar sorangan: di antarana anjeun tiasa nangtukeun kaayaan dimana tag dihapus tina pendaptaran. Tapi, kaayaan ieu diwatesan ku parameter sapertos nami, waktos nyiptakeun, sareng jumlah tag*.

* Gumantung kana palaksanaan pendaptaran wadahna husus. Kami nganggap kamungkinan solusi ieu: Azure CR, Docker Hub, ECR, GCR, Paket GitHub, GitLab Container Registry, Harbour Registry, JFrog Artifactory, Quay.io - dina Séptémber'2020.

Set parameter ieu cukup pikeun nyugemakeun kriteria kaopat - nyaéta, pikeun milih gambar anu cocog sareng versi. Najan kitu, pikeun sakabéh kriteria sejen, hiji kudu milih sababaraha jenis solusi kompromi (a tougher atawa, Sabalikna, kawijakan leuwih toleran) - gumantung kana ekspektasi sarta kamampuhan finansial.

Contona, kriteria katilu - patali jeung kabutuhan pamekar - bisa direngsekeun ku pangatur prosés dina tim: ngaran husus gambar, ngajaga husus ngidinan daptar tur pasatujuan internal. Tapi pamustunganana éta masih kedah otomatis. Sareng upami kamampuan solusi anu siap-siap henteu cekap, anjeun kedah ngalakukeun hal anjeun nyalira.

Kaayaan sareng dua kritéria anu munggaran sami: aranjeunna henteu tiasa puas tanpa nampi data tina sistem éksternal - hiji tempat aplikasi dipasang (dina kasus urang, Kubernetes).

Ilustrasi alur kerja di Git

Anggap anjeun damel sapertos kieu di Git:

Ikon sareng sirah dina diagram nunjukkeun gambar wadahna anu ayeuna dipasang dina Kubernetes pikeun pangguna naon waé (pamaké tungtung, panguji, manajer, jsb) atanapi dianggo ku pamekar pikeun debugging sareng tujuan anu sami.

Naon anu bakal kajadian upami kabijakan beberesih ngan ukur ngantepkeun gambar disimpen (henteu dihapus) ku dibéré ngaran tag?

Jelas, skenario kitu moal nyieun saha senang.

Naon anu bakal robih upami kabijakan ngamungkinkeun gambar henteu dihapus? nurutkeun interval waktu nu tangtu / Jumlah commits panungtungan?

Hasilna parantos langkung saé, tapi masih jauh tina idéal. Barina ogé, urang masih boga pamekar anu peryogi gambar dina pendaptaran (atawa malah deployed di K8s) pikeun debug bug ...

Pikeun nyimpulkeun kaayaan pasar ayeuna: fungsi anu aya dina pendaptaran wadahna henteu nawiskeun kalenturan anu cukup nalika ngabersihkeun, sareng alesan utama ieu nyaéta euweuh cara pikeun berinteraksi sareng dunya luar. Tétéla yén tim anu meryogikeun kalenturan sapertos kapaksa ngalaksanakeun ngahapus gambar sacara mandiri "ti luar", nganggo API Docker Registry (atanapi API asli tina palaksanaan anu saluyu).

Nanging, kami milarian solusi universal anu bakal ngajadikeun otomatis ngabersihan gambar pikeun tim anu béda-béda nganggo pendaptaran anu béda ...

Jalan urang pikeun meresihan gambar universal

Ti mana datangna kabutuhan ieu? Nyatana yén kami sanés grup pamekar anu misah, tapi tim anu ngalayanan seueur di antarana sakaligus, ngabantosan sacara komprehensif ngarengsekeun masalah CI / CD. Sareng alat téknis utama pikeun ieu nyaéta utilitas Open Source werf. Kaseueuranna nyaéta yén éta henteu ngalaksanakeun hiji fungsi, tapi ngiringan prosés pangiriman kontinyu dina sadaya tahapan: ti assembly ka deployment.

Nyebarkeun gambar kana pendaptaran * (langsung saatos aranjeunna diwangun) mangrupikeun fungsi anu jelas tina utiliti sapertos kitu. Sareng saprak gambar disimpen di dinya pikeun neundeun, maka - upami panyimpen anjeun henteu terbatas - anjeun kedah nanggung jawab pikeun beberesih salajengna. Kumaha urang ngahontal kasuksésan dina ieu, satisfying sakabeh kriteria dieusian, bakal dibahas salajengna.

* Sanajan pendaptaran sorangan bisa jadi béda (Docker Registry, GitLab Container Registry, Harbour, jsb), pamaké maranéhanana nyanghareupan masalah anu sarua. Solusi universal dina hal urang henteu gumantung kana palaksanaan pendaptaran, sabab dijalankeun di luar pendaptaran sorangan sareng nawiskeun paripolah anu sami pikeun sadayana.

Sanaos kami nganggo werf salaku conto palaksanaan, kami ngarepkeun pendekatan anu dianggo bakal mangpaat pikeun tim sanés anu nyanghareupan kasusah anu sami.

Janten urang sibuk jaba palaksanaan mékanisme pikeun meresihan gambar - tinimbang maranéhanana kamampuhan anu geus diwangun kana registries pikeun peti. Léngkah munggaran nyaéta ngagunakeun Docker Registry API pikeun nyiptakeun kawijakan primitif anu sami pikeun jumlah tag sareng waktos nyiptakeunana (disebutkeun di luhur). Ditambahkeun ka aranjeunna ngidinan daptar dumasar kana gambar dipaké dina infrastruktur deployed, i.e. Kubernetes. Pikeun anu terakhir, éta cekap nganggo API Kubernetes pikeun ngulik sadaya sumber daya anu disebarkeun sareng kéngingkeun daptar nilai. image.

Leyuran trivial Ieu direngsekeun masalah paling kritis (kriteria No. 1), tapi éta ngan awal lalampahan urang pikeun ngaronjatkeun mékanisme beberesih. Lengkah salajengna - sareng langkung narik - nyaéta kaputusan gaulkeun gambar anu diterbitkeun sareng sajarah Git.

Skéma tagging

Pikeun mimitian ku, urang milih hiji pendekatan nu gambar final kedah nyimpen informasi diperlukeun pikeun beberesih, sarta diwangun prosés on schemes tagging. Nalika nyebarkeun gambar, pangguna milih pilihan tagging khusus (git-branch, git-commit atawa git-tag) sarta dipaké nilai pakait. Dina sistem CI, nilai-nilai ieu diatur sacara otomatis dumasar kana variabel lingkungan. Kanyataanna gambar ahir ieu pakait sareng primitif Git husus, nyimpen data diperlukeun pikeun beberesih dina labél.

Pendekatan ieu nyababkeun sakumpulan kawijakan anu ngamungkinkeun Git dianggo salaku sumber bebeneran tunggal:

• Nalika ngahapus cabang / tag dina Git, gambar anu aya dina pendaptaran otomatis dihapus.
• Jumlah gambar anu aya hubunganana sareng tag Git sareng komitmen tiasa dikontrol ku jumlah tag anu dianggo dina skéma anu dipilih sareng waktos nalika komitmen anu aya hubunganana diciptakeun.

Gemblengna, palaksanaan anu hasilna nyugemakeun kabutuhan urang, tapi tangtangan énggal ngantosan urang. Kanyataanna nyaéta nalika nganggo skéma tagging dumasar kana primitif Git, urang mendakan sababaraha kakurangan. (Kusabab pedaranana di luar ruang lingkup tulisan ieu, sadayana tiasa familiarize diri sareng detilna di dieu.) Ku alatan éta, sanggeus mutuskeun pikeun pindah ka pendekatan leuwih efisien keur méré tag (eusi basis tagging), urang kudu nimbangkeun balik palaksanaan beberesih gambar.

Algoritma anyar

Naha? Kalayan tagging dumasar kana eusi, unggal tag tiasa nyugemakeun sababaraha komitmen dina Git. Nalika ngabersihan gambar, anjeun moal tiasa deui nganggap ngan ti commit mana tag anyar ieu ditambahkeun kana pendaptaran.

Pikeun algoritma beberesih anyar, éta diputuskeun pikeun ngajauhan skéma tagging sareng ngawangun prosés meta-gambar, anu masing-masing nyimpen sakumpulan:

• komitmen nu publikasi ieu dipigawé (henteu masalah naha gambar ditambahkeun, robah atawa tetep sarua dina pendaptaran wadahna);
• jeung identifier internal urang pakait jeung gambar dirakit.

Dina basa sejen, éta disadiakeun linking tag diterbitkeun kalawan commits di Git.

Konfigurasi final sarta algoritma umum

Nalika ngonpigurasikeun beberesih, pangguna ayeuna gaduh aksés kana kawijakan anu milih gambar ayeuna. Unggal kawijakan ieu ditetepkeun:

• loba rujukan, i.e. Tag Git atanapi cabang Git anu dianggo nalika nyeken;
• jeung wates gambar searched pikeun tiap rujukan ti set teh.

Pikeun ngagambarkeun, ieu mangrupikeun konfigurasi kawijakan standar sapertos kieu:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

Konfigurasi ieu ngandung tilu kawijakan anu sasuai jeung aturan ieu:

1. Simpen gambar pikeun 10 tag Git anu terakhir (ku tanggal nyiptakeun tag).
2. Simpen henteu langkung ti 2 gambar anu diterbitkeun dina minggu kamari pikeun henteu langkung ti 10 utas anu gaduh kagiatan dina minggu kamari.
3. Simpen 10 gambar pikeun cabang main, staging и production.

Algoritma ahir bisul kana léngkah-léngkah ieu:

• Retrieving manifests tina pendaptaran wadahna.
• Teu kaasup gambar dipaké dina Kubernetes, sabab Kami parantos milih aranjeunna ku polling API K8s.
• Nyeken sajarah Git sareng ngaluarkeun gambar dumasar kana kawijakan anu ditangtukeun.
• Nyoplokkeun gambar sésana.

Balik deui ka ilustrasi urang, ieu anu lumangsung kalawan werf:

Nanging, sanaos anjeun henteu nganggo werf, pendekatan anu sami sareng beberesih gambar canggih - dina hiji palaksanaan atanapi anu sanés (nurutkeun pendekatan anu dipikaresep pikeun méré tag gambar) - tiasa diterapkeun ka sistem / utiliti anu sanés. Jang ngalampahkeun ieu, cukup pikeun nginget masalah anu timbul sareng mendakan kasempetan éta dina tumpukan anjeun anu ngamungkinkeun anjeun ngahijikeun solusina salancar-gancang. Kami ngarepkeun yén jalur anu kami lalui bakal ngabantosan anjeun ningali kasus khusus anjeun kalayan detil sareng pikiran anyar.

kacindekan

• Moal lami deui atanapi engké, kalolobaan tim mendakan masalah pendaptaran pendaptaran.
• Nalika milarian solusi, mimitina kedah nangtukeun kriteria pikeun relevansi gambar.
• Alat anu ditawarkeun ku jasa pendaptaran wadahna populér ngamungkinkeun anjeun pikeun ngatur ngabersihan anu saderhana pisan anu henteu nganggap "dunya luar": gambar anu dianggo dina Kubernetes sareng ciri-ciri alur kerja tim.
• Algoritma anu fleksibel sareng efisien kedah gaduh pamahaman prosés CI / CD sareng beroperasi henteu ngan ukur nganggo data gambar Docker.

PS

Baca ogé dina blog urang:

• «Tagging dumasar eusi dina kolektor werf: naha sareng kumaha jalanna?";
• «3-jalan ngagabung ka werf: deployment ka Kubernetes kalawan Helm "dina stéroid"";
• «Rojongan pikeun monorepo sareng multirepo di werf sareng naon hubunganna Docker Registry";
• «werf 1.1 release: perbaikan ka pembina kiwari sarta rencana pikeun mangsa nu bakal datang".

sumber: www.habr.com