🥇Dukungan pikeun monorepo sareng multirepo di werf sareng naon hubunganna Docker Registry

Topik ngeunaan hiji repositori mono geus dibahas leuwih ti sakali sarta, sakumaha aturan, ngabalukarkeun kontrovérsi pisan aktif. Ku nyiptakeun werf salaku alat open source anu dirancang pikeun ningkatkeun prosés ngawangun kode aplikasi tina Git ka gambar Docker (teras ngirimkeunana ka Kubernetes), kami henteu mikir pisan ngeunaan pilihan mana anu pangsaéna. Pikeun urang, éta primér nyadiakeun sagalana dipikabutuh pikeun ngarojong pamadegan béda (lamun ieu teu contradict common sense, tangtu).

Pangrojong mono-repo werf panganyarna mangrupikeun conto anu saé ieu. Tapi ke heula, hayu urang terangkeun kumaha dukungan ieu umumna aya hubunganana sareng nganggo werf sareng naon hubunganna Docker Registry sareng éta ...

Isu

Hayu urang ngabayangkeun kaayaan kitu. Perusahaan ngagaduhan seueur tim pangembangan anu damel dina proyék mandiri. Paling aplikasi dijalankeun dina Kubernetes sahingga wadahna. Pikeun nyimpen wadah, gambar, anjeun peryogi pendaptaran (pendaptaran). Salaku pendaptaran sapertos kitu, perusahaan nganggo Docker Hub sareng hiji akun COMPANY. Sarupa jeung kalolobaan sistem panyimpen kode sumber, Docker Hub henteu ngijinkeun hierarki gudang nested, sapertos COMPANY/PROJECT/IMAGE. Dina hal éta… kumaha anjeun tiasa nyimpen aplikasi non-monolitik dina pendaptaran kalayan watesan ieu tanpa nyiptakeun akun anu misah pikeun unggal proyék?

Panginten, kaayaan anu dijelaskeun wawuh ka batur sacara langsung, tapi hayu urang pertimbangkeun masalah pangatur neundeun aplikasi sacara umum, i.e. tanpa ngarujuk kana conto di luhur sareng Docker Hub.

Solusi

Lamun aplikasi monolitik, asalna dina hiji gambar, teras teu aya patarosan sareng urang ngan saukur nyimpen gambar kana pendaptaran wadahna proyék.

Nalika hiji aplikasi dibere salaku sababaraha komponén, microservices, mangka pendekatan tangtu diperlukeun. Dina conto aplikasi wéb has anu diwangun ku dua gambar: frontend и backend - pilihan anu mungkin nyaéta:

Nyimpen gambar dina repositories nested misah:
Simpen sadayana dina hiji gudang, sareng pertimbangkeun nami gambar dina tag, contona, sapertos kieu:

NB: Sabenerna, aya pilihan sejen kalawan nyimpen dina repositories béda, PROJECT-frontend и PROJECT-backend, tapi urang moal nganggap hal éta kusabab pajeulitna rojongan, organisasi jeung distribusi hak antara pamaké.

rojongan werf

Mimitina, werf ngawatesan diri kana repositori nested - untungna, kalolobaan pendaptaran ngadukung fitur ieu. Dimimitian ti versi v1.0.4-alfa.3, ditambahkeun karya kalawan registries nu nyarang teu didukung, sareng Docker Hub mangrupikeun salah sahijina. Ti titik éta, pamaké boga pilihan kumaha nyimpen gambar aplikasi.

Palaksanaan sadia dina pilihan --images-repo-mode=multirepo|monorepo (standar multirepo, i.e. neundeun dina repositories nested). Éta ngahartikeun pola dimana gambar disimpen dina pendaptaran. Cukup pikeun milih mode anu dipikahoyong nalika nganggo paréntah dasar, sareng anu sanésna bakal tetep teu robih.

Kusabab paling pilihan werf bisa diatur variabel lingkungan, dina sistem CI / CD, modeu panyimpenan biasana gampang diatur sacara global pikeun sakabéh proyék. Salaku conto, dina kasus GitLab ngan tambahkeun variabel lingkungan dina setélan proyék: Setélan -> CI / CD -> Variabel: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Upami urang ngobrol ngeunaan nyebarkeun gambar sareng ngaluncurkeun aplikasi (anjeun tiasa maca ngeunaan prosés ieu sacara rinci dina tulisan dokuméntasi anu relevan: Prosés nyebarkeun и Prosés nyebarkeun), maka modeu ngan ukur nangtukeun template anu anjeun tiasa damel sareng gambar.

Iblis aya dina detil

Beda sareng kasusah utama nalika nambihan metode panyimpen énggal dina prosés ngabersihkeun pendaptaran (pikeun fitur ngabersihan anu dirojong ku werf, tingali Prosés beberesih).

Nalika ngabersihkeun, werf merhatikeun gambar anu dianggo dina klaster Kubernetes, kitu ogé kawijakan anu dikonpigurasi ku pangguna. Kawijakan dumasar kana ngabagi tag kana strategi. Strategi anu dirojong ayeuna:

3 strategi dikaitkeun ku primitif Git sapertos tag, branch, sareng commit;
1 strategi pikeun tag custom sawenang.

Kami nyimpen inpormasi ngeunaan strategi tag nalika nyebarkeun gambar dina labél gambar ahir. Harti sorangan nu disebut meta tag - Diperlukeun pikeun nerapkeun sababaraha kawijakan. Salaku conto, nalika ngahapus cabang atanapi tag tina gudang Git, logis pikeun ngahapus anu aya hubunganana henteu kapake gambar ti pendaptaran, nu katutupan ku bagian tina kawijakan urang.

Nalika disimpen dina hiji gudang (monorepo), dina tag gambar, salian ti meta tag, nami gambar ogé tiasa disimpen: PROJECT:frontend-META-TAG. Pikeun misahkeun aranjeunna, kami henteu ngenalkeun pemisah khusus, tapi ngan ukur nambihan nilai anu diperyogikeun kana labél gambar ahir nalika nyebarkeun.

NB: Lamun museurkeun katingal dina sagalana dijelaskeun dina kode sumber werf, lajeng titik awal bisa jadi PR 1684.

Dina tulisan ieu, urang moal nengetan langkung seueur kana masalah sareng leresan pendekatan urang: ngeunaan strategi méré tag, nyimpen data dina labél sareng prosés penerbitan sacara gembleng - sadayana ieu dijelaskeun sacara rinci dina laporan panganyarna ku Dmitry Stolyarov: "werf mangrupikeun alat kami pikeun CI / CD di Kubernetes".

Pikeun nyimpulkeun

Kurangna pangrojong pikeun pendaptaran anu teu aya sanés mangrupikeun faktor anu ngahalangan pikeun urang atanapi pangguna werf anu dipikanyaho ku urang - barina ogé, anjeun salawasna tiasa ngangkat pendaptaran gambar anu misah (atanapi ngalih ka Pendaptaran Wadah bersyarat dina Google Cloud) ... ngaleungitkeun larangan sapertos kitu logis supados alatna langkung merenah pikeun komunitas DevOps anu langkung lega. Ngalaksanakeun éta, urang nyanghareupan kasusah utama dina reworking mékanisme cleanup pendaptaran wadahna. Ayeuna sagalana geus siap, éta nice pikeun nyadar yén éta geus jadi gampang pikeun batur, sarta kami (salaku pamekar utama proyék) moal boga kasusah noticeable dina salajengna ngarojong fitur ieu.

Cicing jeung kami sarta geura-giru kami bakal ngabejaan Anjeun tentang inovasi séjén di werf!