Topik mono-repositori telah dibahas lebih dari satu kali dan, biasanya, menimbulkan kontroversi yang sangat aktif. Dengan menciptakan sebagai alat open source yang dirancang untuk meningkatkan proses pembuatan kode aplikasi dari gambar Git ke Docker (dan kemudian mengirimkannya ke Kubernetes), kami tidak terlalu memikirkan pilihan mana yang terbaik. Bagi kami, yang utama adalah menyediakan semua yang diperlukan untuk pendukung pendapat yang berbeda (jika ini tidak bertentangan dengan akal sehat, tentu saja).
dukungan mono-repo werf baru-baru ini adalah contoh yang bagus untuk ini. Tapi pertama-tama, mari kita cari tahu bagaimana dukungan ini umumnya terkait dengan penggunaan werf dan apa hubungannya Docker Registry dengannya ...
Bermasalah
Bayangkan situasi seperti itu. Perusahaan memiliki banyak tim pengembangan yang mengerjakan proyek independen. Sebagian besar aplikasi berjalan di Kubernetes dan oleh karena itu di-container. Untuk menyimpan wadah, gambar, Anda memerlukan registri (registri). Sebagai registri seperti itu, perusahaan menggunakan Docker Hub dengan satu akun COMPANY. Mirip dengan kebanyakan sistem penyimpanan kode sumber, Docker Hub tidak mengizinkan hierarki repositori bersarang, seperti COMPANY/PROJECT/IMAGE. Dalam hal itu⦠bagaimana Anda bisa menyimpan aplikasi non-monolitik di registri dengan batasan ini tanpa membuat akun terpisah untuk setiap proyek?
Mungkin, situasi yang dijelaskan sudah tidak asing lagi bagi seseorang secara langsung, tetapi mari pertimbangkan masalah pengorganisasian penyimpanan aplikasi secara umum, mis. tanpa mengacu pada contoh di atas dan Docker Hub.
Solusi
Jika aplikasi monolitis, datang dalam satu gambar, maka tidak ada pertanyaan dan kami cukup menyimpan gambar ke registri wadah proyek.
Ketika sebuah aplikasi disajikan sebagai beberapa komponen, layanan mikro, maka diperlukan pendekatan tertentu. Pada contoh aplikasi web tipikal yang terdiri dari dua gambar: frontend ΠΈ backend - opsi yang mungkin adalah:
- Simpan gambar dalam repositori bersarang yang terpisah:
- Simpan semuanya dalam satu repositori, dan pertimbangkan nama gambar di tag, misalnya, sebagai berikut:
NB: Sebenarnya, ada opsi lain dengan menyimpan di berbagai repositori, PROJECT-frontend ΠΈ PROJECT-backend, tetapi kami tidak akan mempertimbangkannya karena kerumitan dukungan, pengaturan, dan distribusi hak antar pengguna.
dukungan werf
Awalnya, werf membatasi diri pada repositori bersarang - untungnya, sebagian besar pendaftar mendukung fitur ini. Mulai dari versi , menambahkan pekerjaan dengan pendaftar di mana bersarang tidak didukung, dan Docker Hub adalah salah satunya. Sejak saat itu, pengguna memiliki pilihan untuk menyimpan gambar aplikasi.
Implementasi tersedia di bawah opsi --images-repo-mode=multirepo|monorepo (bawaan multirepo, yaitu penyimpanan di repositori bersarang). Ini mendefinisikan pola dimana gambar disimpan dalam registri. Cukup memilih mode yang diinginkan saat menggunakan perintah dasar, dan yang lainnya tidak akan berubah.
Karena sebagian besar opsi werf dapat diatur variabel lingkungan, dalam sistem CI / CD, mode penyimpanan biasanya mudah diatur secara global untuk keseluruhan proyek. Misalnya, dalam kasus GitLab cukup tambahkan 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 tentang proses ini secara mendetail di artikel dokumentasi yang relevan: ΠΈ ), maka mode hanya menentukan template yang dapat digunakan untuk bekerja dengan gambar.
Iblis ada dalam detailnya
Perbedaan dan kesulitan utama saat menambahkan metode penyimpanan baru adalah pada proses pembersihan registri (untuk fitur pembersihan yang didukung oleh werf, lihat ).
Saat membersihkan, werf memperhitungkan gambar yang digunakan di kluster Kubernetes, serta kebijakan yang dikonfigurasi oleh pengguna. Kebijakan didasarkan pada pembagian tag menjadi strategi. Strategi yang didukung saat ini:
- 3 strategi yang dihubungkan oleh primitif Git seperti tag, cabang, dan komit;
- 1 strategi untuk tag khusus arbitrer.
Kami menyimpan informasi tentang strategi tag saat memublikasikan gambar di label gambar akhir. Makna itu sendiri adalah yang disebut tag meta - Diperlukan untuk menerapkan beberapa kebijakan. Misalnya, saat menghapus cabang atau tag dari repositori Git, logis untuk menghapus yang terkait tidak terpakai gambar dari registri, yang dicakup oleh bagian dari kebijakan kami.
Saat disimpan dalam satu repositori (monorepo), di tag gambar, selain tag meta, nama gambar juga bisa disimpan: PROJECT:frontend-META-TAG. Untuk memisahkannya, kami tidak memperkenalkan pemisah khusus apa pun, tetapi hanya menambahkan nilai yang diperlukan ke label gambar akhir saat menerbitkan.
NB: Jika Anda tertarik untuk melihat semua yang dijelaskan dalam kode sumber werf, maka titik awalnya adalah .
Dalam artikel ini, kami tidak akan lebih memperhatikan masalah dan pembenaran pendekatan kami: tentang strategi penandaan, penyimpanan data dalam label, dan proses penerbitan secara keseluruhan - semua ini dijelaskan secara rinci dalam laporan terbaru oleh Dmitry Stolyarov: β'.
Meringkas
Kurangnya dukungan untuk registri yang tidak bersarang bukanlah faktor pemblokiran bagi kami atau pengguna werf yang kami kenal - lagipula, Anda selalu dapat menaikkan registri gambar terpisah (atau beralih ke Container Registry bersyarat di Google Cloud) ... Namun, menghapus batasan seperti itu tampaknya logis agar alat tersebut menjadi lebih nyaman bagi komunitas DevOps yang lebih luas. Menerapkannya, kami menghadapi kesulitan utama dalam mengerjakan ulang mekanisme pembersihan registri kontainer. Sekarang semuanya sudah siap, senang menyadari bahwa ini menjadi lebih mudah bagi seseorang, dan kami (sebagai pengembang utama proyek) tidak akan mengalami kesulitan yang nyata dalam mendukung fitur ini lebih lanjut.
Tetap bersama kami dan segera kami akan memberi tahu Anda tentang inovasi lain di !
PS
Baca juga di blog kami:
- «»;
- Β«'.
Sumber: www.habr.com