Topik monorepository wis dibahas luwih saka sepisan lan, minangka aturan, nyebabake debat sing aktif banget. Nggawe Minangka alat Open Source sing dirancang kanggo nambah proses mbangun kode aplikasi saka Git menyang gambar Docker (banjur dikirim menyang Kubernetes), kita ora mikir babagan pilihan sing paling apik. Kanggo kita, utamane kanggo nyedhiyakake kabeh sing dibutuhake kanggo para panyengkuyung sing beda-beda pendapat (yen iki ora mbantah akal sehat, mesthi).
Dhukungan mono-repo ing werf sing mentas dikenalake minangka conto sing apik babagan iki. Nanging pisanan, ayo ngerteni kepiye dhukungan iki umume ana gandhengane karo panggunaan werf lan apa sing kudu ditindakake Docker Registry ...
Masalah
Ayo mbayangno kahanan iki. Perusahaan iki duwe akeh tim pangembangan sing nggarap proyek independen. Umume aplikasi beroperasi ing Kubernetes lan, kanthi mangkono, 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 sampeyan nggawe hirarki repositori bersarang, kayata COMPANY/PROJECT/IMAGE. Ing kasus iki ... carane kita bisa nyimpen aplikasi non-monolitik ing pendaptaran karo watesan iki tanpa nggawe akun kapisah kanggo saben project?
Mbok kahanan diterangake menowo kanggo wong pisanan, nanging ayo kang katon ing Jeksa Agung bisa ngetokake saka ngatur panyimpenan aplikasi ing umum, i.e. tanpa referensi kanggo conto ing ndhuwur lan Docker Hub.
Solusi
Yen aplikasi kanthi monolitik, teka ing siji gambar, banjur ora ana pitakonan lan kita mung nyimpen gambar 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 opsi 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 werf
Wiwitane, werf diwatesi kanggo repositori bersarang - untunge, umume registri ndhukung fitur iki. Wiwit versi , ditambahake karya karo registri kang nesting ora didhukung, lan Docker Hub minangka salah sawijining. Wiwit saiki, pangguna duwe pilihan carane nyimpen gambar aplikasi.
Implementasi kasedhiya minangka bagΓ©an saka pilihan --images-repo-mode=multirepo|monorepo (standar multirepo, i.e. panyimpenan ing repositori nested). Iki nemtokake pola gambar sing disimpen ing registri. Cukup kanggo milih mode sing dikarepake nalika nggunakake printah dhasar, 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. Tuladhane, ing kasus GitLab Cukup tambahake variabel lingkungan ing setelan proyek: Setelan -> CI / CD -> Variabel: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Yen kita ngomong babagan nerbitake gambar lan nggulung aplikasi (sampeyan bisa maca babagan proses kasebut kanthi rinci ing artikel dokumentasi sing cocog: ΠΈ ), banjur mode mung nemtokake cithakan sing bisa digunakake karo gambar kasebut.
Iblis ana ing rincian
Bentenipun lan kangelan utama nalika nambah cara panyimpenan anyar ing proses ngresiki pendaptaran (fitur reresik sing didhukung ing werf, deleng ).
Nalika ngresiki, werf nganggep gambar sing digunakake ing klompok Kubernetes, uga kabijakan sing dikonfigurasi pangguna. Kabijakan adhedhasar pamisah tag dadi strategi. Strategi sing didhukung saiki:
- 3 strategi sing ana gandhengane karo primitif Git kayata tag, cabang lan komitmen;
- 1 strategi kanggo tag khusus khusus.
Kita nyimpen informasi babagan strategi tag nalika nerbitake gambar ing label gambar pungkasan. Tegesipun piyambak ingkang dipunwastani meta tag - perlu kanggo aplikasi sawetara kawicaksanan. Contone, nalika mbusak cabang utawa tag saka repositori Git, iku logis kanggo mbusak gadhah 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-TAG. Kanggo 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 .
Ing artikel iki, kita ora bakal menehi perhatian luwih akeh babagan masalah lan kabeneran pendekatan kita: babagan strategi menehi tag, panyimpenan data ing label lan proses penerbitan umume - kabeh iki diterangake kanthi rinci ing laporan anyar dening Dmitry Stolyarov: "".
Kanggo ngringkes
Kurang dhukungan kanggo registri tanpa nesting ora dadi faktor pamblokiran kanggo kita utawa pangguna werf sing kita kenal - sawise kabeh, sampeyan bisa tansah ngunggahake registri gambar sing kapisah (utawa ngalih menyang Registry Container bersyarat ing Google Cloud) ... Nanging , mbusak watesan kasebut katon logis supaya alat kasebut luwih trep kanggo komunitas DevOps sing luwih akeh. Nalika ngleksanakake, kita nemu kangelan utama ing reworking mekanisme reresik pendaptaran wadhah. Saiki kabeh wis siyap, luwih becik ngerti manawa wis dadi luwih gampang kanggo wong liya, lan kita (minangka pangembang utama proyek kasebut) ora ngira-ngira kesulitan sing bisa dingerteni kanggo ndhukung fitur iki.
Tetep karo kita lan enggal kita bakal pitutur marang kowe bab inovasi liyane ing !
PS
Waca uga ing blog kita:
- Β«";
- Β«".
Source: www.habr.com