Topik repositori mono telah dibincangkan lebih daripada sekali dan, sebagai peraturan, menyebabkan kontroversi yang sangat aktif. Dengan mencipta sebagai alat sumber terbuka yang direka untuk menambah baik proses membina kod aplikasi daripada imej Git ke Docker (dan kemudian menghantarnya ke Kubernetes), kami tidak terlalu memikirkan pilihan mana yang terbaik. Bagi kami, adalah yang utama untuk menyediakan segala yang diperlukan untuk penyokong yang berbeza pendapat (jika ini tidak bercanggah dengan akal sehat, sudah tentu).
Sokongan mono-repo werf baru-baru ini adalah contoh yang baik untuk ini. Tetapi pertama-tama, mari kita fikirkan bagaimana sokongan ini secara amnya berkaitan dengan menggunakan werf dan apa kaitan Docker Registry dengannya ...
Isu
Cuba kita bayangkan keadaan sedemikian. Syarikat itu mempunyai banyak pasukan pembangunan yang bekerja pada projek bebas. Kebanyakan aplikasi dijalankan pada Kubernetes dan oleh itu disimpan dalam bekas. Untuk menyimpan bekas, imej, anda memerlukan pendaftaran (pendaftaran). Sebagai pendaftaran sedemikian, syarikat menggunakan Docker Hub dengan satu akaun COMPANY. Sama seperti kebanyakan sistem penyimpanan kod sumber, Docker Hub tidak membenarkan hierarki repositori bersarang, seperti COMPANY/PROJECT/IMAGE. Dalam kes itu⦠bagaimanakah anda boleh menyimpan aplikasi bukan monolitik dalam pendaftaran dengan pengehadan ini tanpa membuat akaun berasingan untuk setiap projek?
Mungkin, situasi yang diterangkan itu biasa kepada seseorang secara langsung, tetapi mari kita pertimbangkan isu mengatur storan aplikasi secara umum, i.e. tanpa merujuk kepada contoh di atas dan Docker Hub.
Penyelesaian
Jika permohonan monolitik, datang dalam satu imej, maka tiada soalan dan kami hanya menyimpan imej itu ke daftar kontena projek.
Apabila aplikasi dibentangkan sebagai berbilang komponen, perkhidmatan mikro, maka pendekatan tertentu diperlukan. Pada contoh aplikasi web biasa yang terdiri daripada dua imej: frontend ΠΈ backend - pilihan yang mungkin adalah:
- Simpan imej dalam repositori bersarang yang berasingan:
- Simpan semuanya dalam satu repositori dan pertimbangkan nama imej dalam teg, sebagai contoh, seperti berikut:
NB: Sebenarnya, terdapat pilihan lain dengan menyimpan dalam repositori yang berbeza, PROJECT-frontend ΠΈ PROJECT-backend, tetapi kami tidak akan menganggapnya kerana kerumitan sokongan, organisasi dan pengagihan hak antara pengguna.
sokongan werf
Pada mulanya, werf mengehadkan dirinya kepada repositori bersarang - mujurlah, kebanyakan pendaftaran menyokong ciri ini. Bermula dari versi , menambah kerja dengan pendaftaran di mana bersarang tidak disokong, dan Docker Hub adalah salah satu daripadanya. Sejak itu, pengguna mempunyai pilihan bagaimana untuk menyimpan imej aplikasi.
Pelaksanaan tersedia di bawah pilihan --images-repo-mode=multirepo|monorepo (lalai multirepo, iaitu penyimpanan dalam repositori bersarang). Ia mentakrifkan corak yang mana imej disimpan dalam pendaftaran. Ia cukup untuk memilih mod yang dikehendaki apabila menggunakan arahan asas, dan segala-galanya akan kekal tidak berubah.
Kerana kebanyakan pilihan werf boleh ditetapkan pembolehubah persekitaran, dalam sistem CI / CD, mod storan biasanya mudah ditetapkan secara global untuk keseluruhan projek. Sebagai contoh, dalam kes GitLab cuma tambah pembolehubah persekitaran dalam tetapan projek: Tetapan -> CI / CD -> Pembolehubah: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Jika kita bercakap tentang menerbitkan imej dan melancarkan aplikasi (anda boleh membaca tentang proses ini secara terperinci dalam artikel dokumentasi yang berkaitan: ΠΈ ), maka mod semata-mata menentukan templat yang anda boleh bekerja dengan imej.
Syaitan ada dalam butirannya
Perbezaan dan kesukaran utama apabila menambah kaedah storan baru adalah dalam proses membersihkan pendaftaran (untuk ciri pembersihan yang disokong oleh werf, lihat ).
Semasa pembersihan, werf mengambil kira imej yang digunakan dalam kelompok Kubernetes, serta dasar yang dikonfigurasikan oleh pengguna. Dasar adalah berdasarkan pembahagian tag kepada strategi. Strategi yang disokong pada masa ini:
- 3 strategi yang dipautkan oleh primitif Git seperti tag, cawangan dan komit;
- 1 strategi untuk teg tersuai sewenang-wenangnya.
Kami menyimpan maklumat tentang strategi teg apabila menerbitkan imej dalam label imej akhir. Makna itu sendiri adalah yang dipanggil tag meta - Diperlukan untuk menggunakan beberapa dasar. Sebagai contoh, apabila memadamkan cawangan atau teg daripada repositori Git, adalah logik untuk memadam yang berkaitan tidak digunakan imej daripada pendaftaran, yang dilindungi oleh sebahagian daripada dasar kami.
Apabila disimpan dalam satu repositori (monorepo), dalam teg imej, sebagai tambahan kepada teg meta, nama imej juga boleh disimpan: PROJECT:frontend-META-TAG. Untuk memisahkannya, kami tidak memperkenalkan sebarang pemisah khusus, tetapi hanya menambah nilai yang diperlukan pada label imej akhir semasa menerbitkan.
NB: Jika anda berminat untuk melihat semua yang diterangkan dalam kod sumber werf, maka titik permulaan boleh .
Dalam artikel ini, kami tidak akan memberi perhatian lebih kepada masalah dan justifikasi pendekatan kami: mengenai strategi penandaan, menyimpan data dalam label dan proses penerbitan secara keseluruhan - semua ini diterangkan secara terperinci dalam laporan terbaru oleh Dmitry Stolyarov: β'.
Untuk Meringkaskan
Kekurangan sokongan untuk pendaftaran tidak bersarang bukanlah faktor penyekat bagi kami atau pengguna werf yang kami kenali - lagipun, anda sentiasa boleh menaikkan pendaftaran imej yang berasingan (atau bertukar kepada Pendaftaran Kontena bersyarat dalam Google Cloud) ... Walau bagaimanapun, mengalih keluar sekatan sedemikian nampaknya logik agar alat itu lebih memudahkan komuniti DevOps yang lebih luas. Melaksanakannya, kami menghadapi kesukaran utama dalam mengolah semula mekanisme pembersihan pendaftaran kontena. Memandangkan segala-galanya sudah sedia, adalah baik untuk menyedari bahawa ia telah menjadi lebih mudah untuk seseorang, dan kami (sebagai pemaju utama projek) tidak akan mengalami sebarang kesulitan yang ketara dalam menyokong lagi ciri ini.
Kekal bersama kami dan tidak lama lagi kami akan memberitahu anda tentang inovasi lain dalam !
PS
Baca juga di blog kami:
- «»;
- Β«'.
Sumber: www.habr.com