🥇Masalah "pinter" ngresiki gambar wadhah lan solusi ing werf

Artikel kasebut mbahas masalah reresik gambar sing nglumpukake registri kontainer (Docker Registry lan analoge) ing kasunyatan CI / CD pipeline modern kanggo aplikasi asli awan sing dikirim menyang Kubernetes. Kritéria utama kanggo relevansi gambar lan kesulitan kanggo ngotomatisasi, ngirit ruang lan nyukupi kabutuhan tim diwenehake. Pungkasan, nggunakake conto proyek Open Source tartamtu, kita bakal pitutur marang kowe carane kesulitan iki bisa diatasi.

Pambuka

Jumlah gambar ing registri wadhah bisa tuwuh kanthi cepet, njupuk luwih akeh ruang panyimpenan lan kanthi mangkono nambah biaya. Kanggo ngontrol, matesi utawa njaga wutah spasi sing dikuwasani ing registri, ditampa:

nggunakake nomer tetep tag kanggo gambar;
ngresiki gambar ing sawetara cara.

Watesan pisanan kadhangkala bisa ditampa kanggo tim cilik. Yen pangembang duwe cukup tag permanen (latest, main, test, boris etc.), pendaptaran ora bakal swell ing ukuran lan kanggo dangu sampeyan ora kudu mikir bab ngresiki ing kabeh. Sawise kabeh, kabeh gambar sing ora ana gandhengane bakal dibusak, lan ora ana gaweyan kanggo ngresiki (kabeh ditindakake dening tukang sampah biasa).

Nanging, pendekatan iki mbatesi pembangunan lan arang ditrapake kanggo proyek CI / CD modern. Bagéyan integral saka pembangunan ana otomatisasi, sing ngidini sampeyan nyoba, nyebarake lan ngirim fungsi anyar menyang pangguna luwih cepet. Contone, ing kabeh proyek kita, pipa CI digawe kanthi otomatis karo saben komitmen. Ing kono, gambar kasebut dirakit, diuji, diluncurake menyang macem-macem sirkuit Kubernetes kanggo debugging lan cek sing isih ana, lan yen kabeh apik, owah-owahan kasebut tekan pangguna pungkasan. Lan iki dudu ilmu roket, nanging kedadeyan saben dina kanggo akeh - paling kamungkinan kanggo sampeyan, amarga sampeyan maca artikel iki.

Wiwit mbenakake kewan omo lan ngembangake fungsi anyar ditindakake kanthi podo karo, lan rilis bisa ditindakake kaping pirang-pirang dina, jelas manawa proses pangembangan kasebut diiringi akeh komitmen, tegese nomer akeh gambar ing pendaptaran. Akibaté, masalah ngatur reresik registri sing efektif muncul, i.e. mbusak gambar sing ora cocog.

Nanging kepiye sampeyan nemtokake manawa gambar kasebut cocog?

Kriteria kanggo relevansi gambar

Ing mayoritas kasus, kritéria utama yaiku:

1. Pisanan (paling ketok lan paling kritis kabeh) iku gambar sing saiki digunakake ing Kubernetes. Mbusak gambar kasebut bisa nyebabake biaya downtime produksi sing signifikan (contone, gambar kasebut bisa uga dibutuhake kanggo replikasi) utawa negate upaya debugging tim ing salah sawijining puteran. (Kanggo alasan iki, kita malah nggawe khusus Prometheus eksportir, sing nglacak ora ana gambar kasebut ing kluster Kubernetes.)

2. Kapindho (kurang ketok, nanging uga penting banget lan maneh hubungane karo eksploitasi) - gambar sing dibutuhake kanggo muter maneh yen deteksi masalah serius ing versi saiki. Contone, ing kasus Helm, iki minangka gambar sing digunakake ing versi rilis sing disimpen. (Oalah, kanthi standar ing Helm, watesan yaiku 256 revisi, nanging ora ana sing kudu nyimpen. kaya mengkono nomer akeh versi?..) Sawise kabeh, kita, utamané, nyimpen versi supaya kita bisa nggunakake mengko, i.e. "muter maneh" kanggo wong-wong mau yen perlu.

3. Katelu - kabutuhan pangembang: Kabeh gambar sing ana hubungane karo karya saiki. Contone, yen kita ngelingi PR, banjur nggawe akal kanggo ninggalake gambar sing cocog karo komitmen pungkasan lan, ucapake, komitmen sadurunge: kanthi cara iki pangembang bisa cepet bali menyang tugas apa wae lan nggarap owah-owahan paling anyar.

4. Papat - gambar sing cocog karo versi aplikasi kita, i.e. minangka produk pungkasan: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, etc.

NB: Kriteria sing ditetepake ing kene dirumusake adhedhasar pengalaman sesambungan karo puluhan tim pangembangan saka macem-macem perusahaan. Nanging, mesthi, gumantung saka spesifik ing proses pangembangan lan infrastruktur sing digunakake (contone, Kubernetes ora digunakake), kritéria kasebut bisa beda-beda.

Kelayakan lan solusi sing wis ana

Layanan populer karo registri wadhah, minangka aturan, nawakake kabijakan pembersihan gambar dhewe: sampeyan bisa nemtokake kahanan ing ngendi tag dibusak saka registri. Nanging, kahanan iki diwatesi dening paramèter kayata jeneng, wektu nggawe, lan nomer tag*.

* Gumantung ing implementasine pendaptaran wadhah tartamtu. Kita nimbang kemungkinan solusi ing ngisor iki: Azure CR, Docker Hub, ECR, GCR, Paket GitHub, GitLab Container Registry, Harbour Registry, JFrog Artifactory, Quay.io - ing September'2020.

Setel paramèter iki cukup kanggo nyukupi kritéria kaping papat - yaiku, kanggo milih gambar sing cocog karo versi. Nanging, kanggo kabeh kritéria liyane, siji kudu milih sawetara jinis solusi kompromi (kabijakan sing luwih angel utawa, kosok balene, luwih entheng) - gumantung saka pangarepan lan kemampuan finansial.

Contone, kritéria katelu - related kanggo kabutuhan pangembang - bisa ditanggulangi dening ngatur pangolahan ing tim: jeneng tartamtu saka gambar, ngramut khusus ngidini dhaftar lan persetujuan internal. Nanging pungkasane isih kudu otomatis. Lan yen kemampuan solusi siap-siap ora cukup, sampeyan kudu nindakake dhewe.

Kahanan karo rong kritéria pisanan padha: padha ora bisa wareg tanpa nampa data saka sistem external - kang aplikasi sing disebarake (ing kasus kita, Kubernetes).

Ilustrasi alur kerja ing Git

Contone, sampeyan nindakake kaya iki ing Git:

Lambang karo sirah ing diagram nuduhake gambar wadhah sing saiki disebarake ing Kubernetes kanggo pangguna (pangguna pungkasan, penguji, manajer, lsp.) utawa digunakake dening pangembang kanggo debugging lan tujuan sing padha.

Apa sing kedadeyan yen kabijakan pembersihan mung ngidini gambar disimpen (ora dibusak) dening diwenehi jeneng tag?

Temenan, skenario kaya ngono ora bakal nggawe wong seneng.

Apa sing bakal diganti yen kabijakan ngidini gambar ora dibusak? miturut interval wektu tartamtu / nomer commit pungkasan?

Asil wis dadi luwih apik, nanging isih adoh saka ideal. Sawise kabeh, kita isih duwe pangembang sing butuh gambar ing registri (utawa malah disebarake ing K8s) kanggo debug bug ...

Kanggo ngringkes kahanan pasar saiki: fungsi sing kasedhiya ing registri wadhah ora menehi keluwesan sing cukup nalika ngresiki, lan alasan utama yaiku ora ana cara kanggo sesambungan karo donya njaba. Pranyata tim sing mbutuhake keluwesan kasebut dipeksa kanthi mandiri ngetrapake pambusakan gambar "saka njaba", nggunakake Docker Registry API (utawa API asli saka implementasine sing cocog).

Nanging, kita nggoleki solusi universal sing bakal ngotomatisasi pembersihan gambar kanggo tim sing beda nggunakake registri sing beda-beda ...

Path kita kanggo ngresiki gambar universal

Saka endi kabutuhan iki? Kasunyatane, kita dudu klompok pangembang sing kapisah, nanging tim sing nglayani akeh wong sekaligus, mbantu ngrampungake masalah CI / CD kanthi lengkap. Lan alat teknis utama kanggo iki yaiku sarana Open Source werf. Keanehane yaiku ora nindakake fungsi siji, nanging ngiringi proses pangiriman sing terus-terusan ing kabeh tahapan: saka perakitan nganti penyebaran.

Nerbitake gambar menyang registri * (sawise dibangun) minangka fungsi sing jelas saka sarana kasebut. Lan wiwit gambar diselehake ing kono kanggo panyimpenan, banjur - yen panyimpenan sampeyan ora winates - sampeyan kudu tanggung jawab kanggo reresik sakteruse. Kepiye carane kita bisa sukses ing babagan iki, nyukupi kabeh kritéria sing ditemtokake, bakal dibahas luwih lanjut.

* Sanajan registri dhewe bisa uga beda-beda (Docker Registry, GitLab Container Registry, Harbour, lsp), para pangguna ngadhepi masalah sing padha. Solusi universal ing kasus kita ora gumantung ing implementasine registri, amarga mlaku ing njaba registri dhewe lan nawakake prilaku sing padha kanggo kabeh wong.

Sanajan kita nggunakake werf minangka conto implementasine, kita ngarep-arep pendekatan sing digunakake bakal migunani kanggo tim liyane sing ngadhepi kesulitan sing padha.

Dadi kita dadi sibuk eksternal implementasine saka mekanisme kanggo reresik gambar - tinimbang sing Kapabilitas sing wis dibangun menyang registries kanggo kontaner. Langkah pisanan yaiku nggunakake Docker Registry API kanggo nggawe kabijakan primitif sing padha kanggo jumlah tag lan wektu nggawe (kasebut ing ndhuwur). Ditambahake kanggo wong-wong mau ngidini dhaptar adhedhasar gambar sing digunakake ing infrastruktur sing disebarake, i.e. Kubernetes. Kanggo sing terakhir, cukup nggunakake API Kubernetes kanggo ngulang kabeh sumber daya sing disebarake lan entuk dhaptar nilai. image.

Solusi sepele iki ngrampungake masalah sing paling kritis (kriteria No. 1), nanging mung minangka wiwitan perjalanan kanggo nambah mekanisme reresik. Langkah sabanjure - lan luwih menarik - yaiku keputusane nggandhengake gambar sing diterbitake karo riwayat Git.

Skema tagging

Kanggo miwiti, kita milih pendekatan ing ngendi gambar pungkasan kudu nyimpen informasi sing dibutuhake kanggo ngresiki, lan mbangun proses kasebut ing skema menehi tag. Nalika nerbitake gambar, pangguna milih pilihan menehi tag tartamtu (git-branch, git-commit utawa git-tag) lan nggunakake nilai sing cocog. Ing sistem CI, nilai kasebut disetel kanthi otomatis adhedhasar variabel lingkungan. Nyatane gambar pungkasan digandhengake karo primitif Git tartamtu, nyimpen data sing perlu kanggo reresik ing label.

Pendekatan iki ngasilake sakumpulan kabijakan sing ngidini Git digunakake minangka sumber siji bebener:

Nalika mbusak cabang / tag ing Git, gambar sing ana gandhengane ing registri kanthi otomatis dibusak.
Jumlah gambar sing digandhengake karo tag Git lan commit bisa dikontrol kanthi jumlah tag sing digunakake ing skema sing dipilih lan wektu nalika komit sing gegandhengan digawe.

Sakabèhé, asil implementasine nyukupi kabutuhan kita, nanging tantangan anyar wis nunggu kita. Kasunyatane yaiku nalika nggunakake skema tagging adhedhasar primitif Git, kita nemoni sawetara kekurangan. (Amarga deskripsi kasebut ngluwihi ruang lingkup artikel iki, kabeh wong bisa ngerti rincian kasebut kene.) Mulane, sawise mutusake kanggo ngalih menyang pendekatan sing luwih efisien kanggo menehi tag (tag adhedhasar konten), kita kudu nimbang maneh implementasi reresik gambar.

Algoritma anyar

Kenging punapa? Kanthi menehi tag adhedhasar konten, saben tag bisa gawe marem sawetara komitmen ing Git. Nalika ngresiki gambar, sampeyan ora bisa nganggep maneh mung saka commit ngendi tag anyar ditambahake menyang pendaptaran.

Kanggo algoritma reresik anyar, diputusake kanggo pindhah saka rencana menehi tag lan mbangun proses meta-gambar, sing saben nyimpen akeh:

komitmen sing diterbitake publikasi (ora ketompo apa gambar ditambahake, diganti utawa tetep padha ing registri wadhah);
lan pengenal internal kita cocog karo gambar nglumpuk.

Ing tembung liyane, diwenehake ngubungake tag sing diterbitake karo komitmen ing Git.

Konfigurasi pungkasan lan algoritma umum

Nalika ngatur reresik, pangguna saiki duwe akses menyang kabijakan sing milih gambar sing saiki. Saben kabijakan kasebut ditetepake:

akeh referensi, i.e. Tag Git utawa cabang Git sing digunakake nalika mindhai;
lan watesan gambar sing digoleki kanggo saben referensi saka set kasebut.

Kanggo ilustrasi, iki kaya konfigurasi kabijakan standar:

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 iki ngemot telung kabijakan sing tundhuk karo aturan ing ngisor iki:

Simpen gambar kanggo 10 tag Git pungkasan (miturut tanggal nggawe tag).
Simpen ora luwih saka 2 gambar sing diterbitake ing minggu kepungkur kanggo ora luwih saka 10 utas kanthi aktivitas ing minggu kepungkur.
Simpen 10 gambar kanggo cabang main, staging и production.

Algoritma pungkasan dadi langkah-langkah ing ngisor iki:

Njupuk manifests saka pendaptaran wadah.
Ora kalebu gambar sing digunakake ing Kubernetes, amarga Kita wis milih dheweke kanthi polling API K8s.
Mindai riwayat Git lan ora kalebu gambar adhedhasar kabijakan tartamtu.
Mbusak gambar sing isih ana.

Bali menyang ilustrasi, iki kedadeyan karo werf:

Nanging, sanajan sampeyan ora nggunakake werf, pendekatan sing padha kanggo reresik gambar sing luwih maju - ing siji implementasi utawa liyane (miturut pendekatan sing disenengi kanggo menehi tag gambar) - bisa ditrapake ing sistem/utilitas liyane. Kanggo nindakake iki, cukup kanggo ngelingi masalah sing muncul lan nemokake kesempatan kasebut ing tumpukan sampeyan sing ngidini sampeyan nggabungake solusi kasebut kanthi lancar. Muga-muga dalan sing wis kita lewati bakal mbantu sampeyan ndeleng kasus tartamtu kanthi rincian lan pikirane anyar.

kesimpulan

Cepet utawa mengko, umume tim nemoni masalah kebanjiran pendaptaran.
Nalika nggoleki solusi, pisanan perlu kanggo nemtokake kritéria kanggo relevansi gambar.
Piranti sing ditawakake layanan registri wadhah populer ngidini sampeyan ngatur pembersihan sing gampang banget sing ora nganggep "dunia njaba": gambar sing digunakake ing Kubernetes lan kekhasan alur kerja tim.
Algoritma sing fleksibel lan efisien kudu duwe pangerten babagan proses CI / CD lan ora mung nganggo data gambar Docker.

PS

Waca uga ing blog kita:

Source: www.habr.com

Masalah "pinter" ngresiki gambar wadhah lan solusi ing werf