Topik monorepositori telah dibahas lebih dari satu kali dan, sebagai suatu peraturan, menyebabkan perdebatan yang sangat aktif. Membuat
werf sebagai alat Open Source yang dirancang untuk meningkatkan proses
kompilasi kode aplikasi dari Git ke Docker gambar (dan pengiriman berikutnya ke Kubernetes), kami tidak terlalu memikirkan pilihan mana yang lebih baik. Bagi kami, sangat penting untuk menyediakan segala yang diperlukan untuk para pendukung berbagai pendapat (jika ini tentu saja tidak bertentangan dengan akal sehat).
Dukungan terkini untuk mono-repo di werf adalah contoh yang baik. Tetapi pertama-tama, mari kita lihat bagaimana dukungan ini umumnya dikaitkan dengan penggunaan werf dan apa yang harus dilakukan oleh Docker Registry dengan itu ...
Masalah
Bayangkan situasi ini. Perusahaan memiliki banyak tim pengembangan yang terlibat dalam proyek-proyek independen. Sebagian besar aplikasi berjalan pada Kubernet dan, karenanya, dipaketkan. Untuk menyimpan kontainer, gambar, diperlukan pendaftaran. Perusahaan menggunakan Docker Hub dengan satu akun
COMPANY sebagai registri. Mirip dengan kebanyakan sistem penyimpanan kode sumber,
Docker Hub tidak memungkinkan Anda untuk membuat hierarki bersarang dari repositori seperti
COMPANY/PROJECT/IMAGE . Dalam hal ini ... bagaimana seseorang dapat menyimpan aplikasi non-monolitik dalam registri dengan pembatasan ini tanpa membuat akun terpisah untuk setiap proyek?
Mungkin situasi yang dideskripsikan tidak asing bagi seseorang secara langsung, tetapi mari kita pertimbangkan masalah mengatur penyimpanan aplikasi secara umum, mis. tanpa merujuk pada contoh di atas dan Docker Hub.
Solusi
Jika aplikasi ini
monolitik , hadir dalam satu gambar, maka tidak ada pertanyaan dan kami hanya menyimpan gambar dalam repositori proyek.
Ketika suatu aplikasi disajikan dalam bentuk beberapa komponen, layanan-layanan
mikro , diperlukan untuk memilih pendekatan tertentu. Menggunakan contoh aplikasi web khas yang terdiri dari dua gambar:
frontend dan
backend , opsi yang memungkinkan adalah sebagai berikut:
- Simpan gambar dalam repositori bersarang terpisah:
- Simpan semua dalam satu repositori, dan ambil nama gambar ke dalam tag, misalnya, sebagai berikut:
NB : Sebenarnya, masih ada opsi untuk menyimpan PROJECT-frontend dan PROJECT-backend dalam berbagai repositori, tetapi kami tidak akan mempertimbangkannya karena kerumitan dukungan, organisasi, dan distribusi hak antara pengguna.Dukungan kami
Awalnya, werf membatasi diri pada repositori bersarang - untungnya, sebagian besar pendaftar mendukung fitur ini. Dimulai dengan versi
v1.0.4-alpha.3 , pekerjaan telah ditambahkan dengan pendaftar di mana
bersarang tidak didukung , dan Docker Hub di antara mereka. Mulai saat ini, pengguna memiliki pilihan bagaimana menyimpan gambar aplikasi.
Implementasi tersedia sebagai bagian dari opsi
--images-repo-mode=multirepo|monorepo (secara default
multirepo , mis. Penyimpanan dalam repositori bersarang). Ini mendefinisikan pola penyimpanan gambar dalam registri. Cukup memilih mode yang diinginkan saat menggunakan perintah dasar, dan yang lainnya tidak akan berubah.
Karena sebagian besar opsi werf dapat diatur
dengan variabel lingkungan , dalam sistem CI / CD, mode penyimpanan biasanya mudah diatur secara global untuk seluruh proyek. Misalnya,
dalam kasus GitLab, tambahkan saja variabel lingkungan di pengaturan proyek:
Pengaturan -> CI / CD -> Variabel: WERF_IMAGES_REPO_MODE: multirepo|monorepo .
Jika kita berbicara tentang menerbitkan gambar dan meluncurkan aplikasi (Anda dapat membaca lebih lanjut tentang proses-proses ini dalam artikel yang sesuai dari dokumentasi:
Proses penerbitan dan
Deploy ), maka mode secara eksklusif menentukan templat yang dengannya Anda dapat bekerja dengan gambar tersebut.
Setan secara detail
Perbedaan dan kesulitan utama saat menambahkan metode penyimpanan baru adalah selama proses pembersihan registri
(untuk opsi pembersihan yang didukung oleh werf, lihat proses Pembersihan ) .
Saat membersihkan, werf memperhitungkan gambar yang digunakan dalam kelompok Kubernetes, serta kebijakan yang dikonfigurasi pengguna. Kebijakan didasarkan pada membagi tag ke dalam strategi. Strategi yang saat ini didukung:
- 3 strategi yang terkait dengan primitif Git, seperti tag, cabang dan komit;
- 1 strategi untuk tag khusus.
Kami menyimpan informasi tentang strategi tag saat menerbitkan gambar di label gambar akhir. Makna itu sendiri - yang disebut
tag meta - diperlukan untuk penerapan beberapa kebijakan. Misalnya, ketika menghapus cabang atau tag dari repositori Git, logis untuk menghapus gambar yang
tidak digunakan terkait dari registri, yang dicakup oleh bagian dari kebijakan kami.
Saat menyimpan dalam satu repositori (
monorepo ), selain tag meta, nama gambar juga dapat disimpan dalam tag gambar:
PROJECT: frontend -META-TAG . Untuk memisahkannya, kami tidak memperkenalkan pemisah spesifik apa pun, tetapi cukup menambahkan nilai yang diperlukan ke label gambar akhir saat penerbitan.
NB : Jika Anda tertarik untuk melihat segala sesuatu yang dijelaskan dalam kode sumber werf, maka PR 1684 dapat berfungsi sebagai titik awal.Dalam artikel ini, kami tidak akan lebih memperhatikan masalah dan pembenaran dari pendekatan kami: tentang strategi penandaan, penyimpanan data dalam label dan proses publikasi secara keseluruhan - semua ini dijelaskan secara rinci dalam laporan terbaru oleh Dmitry Stolyarov: “
werf adalah alat kami untuk CI / CD di Kubernetes . "
Meringkas
Kurangnya dukungan registri tanpa bersarang bukanlah faktor pemblokiran bagi kami atau pengguna werf yang kami kenal - Anda selalu dapat meningkatkan registri gambar terpisah (atau beralih ke Registry Kontainer bersyarat di Google Cloud) ... Namun, menghapus batasan ini tampaknya logis untuk membuat alat lebih nyaman komunitas DevOps yang luas. Saat menerapkannya, kami menghadapi kesulitan utama dalam memproses mekanisme pembersihan registri kontainer. Sekarang semuanya sudah siap, senang menyadari bahwa telah menjadi lebih mudah bagi seseorang, dan kami (sebagai pengembang utama proyek) tidak memiliki kesulitan yang signifikan dalam mendukung fitur ini lebih jauh.
Tetap bersama kami dan segera kami akan memberitahu Anda tentang inovasi lain di
werf !
PS
Baca juga di blog kami: