🥇Dhukungan kanggo monorepo lan multirepo ing werf lan apa hubungane Docker Registry

Topik monorepo wis dibahas kaping pirang-pirang lan, minangka aturan, nyebabake debat sing cukup aktif. Nggawe werf Minangka alat open source sing dirancang kanggo nambah proses mbangun kode aplikasi saka Git menyang gambar Docker (banjur dikirim menyang Kubernetes), kita mung mikir babagan pilihan sing paling apik. Keprigelan utama kita yaiku kanggo nampung panemu sing beda-beda (anggere ora mbantah akal sehat, mesthi).

Dhukungan mono-repo anyar ing werf minangka conto sing apik babagan iki. Nanging pisanan, ayo ngerteni kepiye dhukungan iki ana gandhengane karo nggunakake werf lan apa sing kudu ditindakake Docker Registry ...

Masalah

Ayo mbayangno kahanan iki. Perusahaan iki duwe akeh tim pangembang sing nggarap proyek independen. Umume aplikasi beroperasi ing Kubernetes, lan mulane dikontainer. Kanggo nyimpen wadhah lan gambar, registri dibutuhake. Perusahaan kasebut nggunakake Docker Hub kanthi akun siji minangka registri kasebut. COMPANY. Kaya sistem panyimpenan kode sumber, Docker Hub ora ngidini hierarki repositori bersarang, kayata COMPANY/PROJECT/IMAGE. Ing kasus kasebut ... kepiye carane bisa nyimpen aplikasi non-monolitik ing registri kanthi watesan iki, tanpa nggawe akun sing kapisah kanggo saben proyek?

Mbok menawa kahanan sing diterangake wis akrab karo wong liya, nanging ayo nimbang masalah ngatur panyimpenan aplikasi ing umum, yaiku tanpa referensi ing conto ing ndhuwur lan Docker Hub.

Solusi

Yen aplikasi kanthi monolitik, diwenehake ing siji gambar, banjur ora ana pitakonan lan kita mung nyimpen gambar kasebut menyang registri wadhah proyek.

Nalika aplikasi ditampilake minangka macem-macem komponen, layanan mikro, banjur sampeyan kudu milih pendekatan tartamtu. Nggunakake conto aplikasi web khas sing dumadi saka rong gambar: frontend и backend - pilihan sing bisa ditindakake yaiku:

Simpen gambar ing repositori nested sing kapisah:
Simpen kabeh ing siji gudang, lan lebokake jeneng gambar ing tag, contone, kaya ing ngisor iki:

NB: Bener, ana pilihan liyane kanthi nyimpen ing macem-macem repositori, PROJECT-frontend и PROJECT-backend, nanging kita ora bakal nganggep amarga kerumitan dhukungan, organisasi lan distribusi hak antarane pangguna.

Dhukungan ing werf

Kaping pisanan, werf mbatesi dhewe menyang repositori bersarang - untunge, umume registri ndhukung fitur iki. Miwiti karo versi v1.0.4-alpha.3, ditambahake karya karo registries kang nesting ora didhukung, lan Docker Hub minangka salah sawijining. Wiwit saiki, pangguna duwe pilihan carane nyimpen gambar aplikasi.

Implementasi kasedhiya minangka pilihan --images-repo-mode=multirepo|monorepo (kanthi standar multirepo, yaiku panyimpenan ing repositori nested). Iki nemtokake cithakan sing gambar disimpen ing registri. Cukup kanggo milih mode sing dikarepake nalika nggunakake printah utama, lan kabeh liya bakal tetep ora owah.

Wiwit paling opsi werf bisa disetel variabel lingkungan, ing sistem CI/CD, mode panyimpenan biasane gampang disetel sacara global kanggo kabeh proyek. Contone, ing kasus GitLab cukup kanggo nambah variabel lingkungan ing setelan proyek: Setelan -> CI / CD -> Variabel: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Yen kita ngomong babagan nerbitake gambar lan ngluncurake aplikasi (sampeyan bisa maca babagan proses kasebut kanthi rinci ing artikel dokumentasi sing cocog: Proses nerbitake и Proses penyebaran), banjur mode khusus nemtokake cithakan sing sampeyan bisa nggarap gambar kasebut.

Iblis ana ing rincian

Bentenipun lan kangelan utama nalika nambah cara panyimpenan anyar ing proses reresik pendaptaran (kanggo kemampuan reresik sing didhukung dening werf, deleng Proses reresik).

Nalika ngresiki, werf nganggep gambar sing digunakake ing kluster Kubernetes, uga kabijakan sing bisa dikonfigurasi pangguna. Kabijakan kasebut adhedhasar pamisah tag dadi strategi. Strategi sing didhukung saiki:

3 strategi sing ana gandhengane karo primitif Git kayata tag, branch, lan commit;
1 strategi kanggo tag khusus.

Kita nyimpen informasi strategi tag nalika nerbitake gambar ing label gambar pungkasan. Nilai dhewe sing disebut meta tag - perlu kanggo aplikasi sawetara kawicaksanan. Contone, nalika mbusak cabang utawa tag saka repositori Git, iku uga perlu kanggo mbusak sing gegandhengan. ora dienggo gambar saka pendaptaran, kang dijamin dening bagéan saka kawicaksanan kita.

Nalika nyimpen ing siji repositori (monorepo), ing tag gambar, saliyane tag meta, jeneng gambar uga bisa disimpen: PROJECT:frontend-META-TAGKanggo misahake, kita ora ngenalake pemisah tartamtu, nanging mung nambahake nilai sing dibutuhake ing label gambar pungkasan nalika nerbitake.

NB: Yen sampeyan kasengsem ing dipikir kabeh diterangake ing kode sumber werf, banjur titik wiwitan bisa PR 1684.

Ing artikel iki, kita ora bakal menehi perhatian luwih akeh babagan masalah lan kabeneran pendekatan kita: babagan strategi menehi tag, nyimpen data ing label lan proses penerbitan umume - kabeh iki diterangake kanthi rinci ing laporan anyar Dmitry Stolyarov: "werf minangka alat kanggo CI/CD ing Kubernetes".

Kanggo ngringkes

Kurang dhukungan kanggo registri non-nested ora dadi faktor pamblokiran kanggo kita utawa pangguna werf sing kita kenal - sawise kabeh, sampeyan bisa tansah nyetel registri gambar sing kapisah (utawa ngalih menyang Registry Container bersyarat ing Google Cloud) ... Nanging, mbusak watesan kasebut katon logis supaya alat kasebut trep kanggo komunitas DevOps sing luwih akeh. Nalika ngleksanakake, kita nemu kangelan utama ing reworking mekanisme reresik pendaptaran wadhah. Saiki kabeh wis siyap, iku becik kanggo éling sing wis dadi luwih gampang kanggo wong, lan kita (minangka pangembang utama project) ora nyana sembarang kangelan ngelingke ing support luwih saka fitur iki.

Tetep dirungokake lan kita bakal ngandhani babagan inovasi liyane ing mangsa ngarep. werf!