🛤️ 🌘 👇 Penandaan berbasis konten di pengumpul werf: mengapa dan bagaimana cara kerjanya? 🕴🏿 🔦 🃏

werf adalah utilitas GitOps CLI open source kami untuk membangun dan mengirimkan aplikasi ke Kubernetes. Dalam rilis v1.1 memiliki fitur baru untuk pengumpul gambar: penandaan gambar berdasarkan konten, atau penandaan berbasis konten . Sampai sekarang, skema penandaan khusus di werf melibatkan penandaan gambar Docker dengan tag Git, cabang Git, atau komit Git. Tetapi semua skema ini memiliki kelemahan yang sepenuhnya dipecahkan oleh strategi penandaan baru. Rincian tentang dia dan mengapa dia begitu baik - di bawah potongan.

Kembalikan seperangkat layanan microser dari satu repositori Git

Seringkali ada situasi di mana aplikasi dibagi menjadi lebih atau kurang layanan independen. Rilis layanan ini dapat terjadi secara independen: satu atau beberapa layanan dapat dirilis sekaligus, sementara sisanya harus terus bekerja tanpa perubahan. Tetapi dari sudut pandang penyimpanan kode dan manajemen proyek, lebih mudah untuk menyimpan layanan aplikasi seperti itu dalam satu repositori.

Ada situasi ketika layanan benar-benar independen dan tidak terhubung dengan satu aplikasi. Dalam hal ini, mereka akan ditempatkan di proyek yang terpisah dan rilis mereka akan melalui proses CI / CD terpisah di masing-masing proyek.

Namun, pada kenyataannya, pengembang sering memecah satu aplikasi menjadi beberapa layanan microser, tetapi memiliki repositori dan proyek yang terpisah untuk masing-masing ... jelas merupakan suatu keharusan. Tentang situasi inilah yang akan dibahas lebih lanjut: beberapa layanan microser seperti itu terletak di satu repositori proyek dan pelepasan terjadi melalui satu proses tunggal dalam CI / CD.

Tag Git dan Tag Git

Katakanlah strategi penandaan yang paling umum digunakan - tag-atau-cabang . Untuk cabang Git, gambar ditandai dengan nama cabang, untuk satu cabang pada satu waktu hanya ada satu gambar yang diterbitkan dinamai untuk cabang ini. Untuk Git tag, gambar diberi tag sesuai dengan nama tag.

Saat membuat tag Git baru - misalnya, ketika versi baru dirilis - tag Docker baru akan dibuat untuk semua gambar proyek di Docker Registry:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Nama-nama gambar baru ini melewati pola Helm ke dalam konfigurasi Kubernetes. Ketika penyebaran dimulai, tim werf deploymemperbarui bidang imagedi sumber daya Kubernetes memanifestasikan dan me-restart sumber daya yang sesuai karena nama gambar yang diubah.

Masalah : Dalam kasus di mana vykata aktual sebelumnya (Git-tag) tidak mengubah konten gambar, tetapi hanya Docker-tag yang terjadi setelah restart Aplikasi ini dan, karenanya, beberapa kemungkinan sederhana. Meskipun tidak ada alasan nyata untuk melakukan restart ini.

Akibatnya, dengan skema pemberian tag saat ini, Anda harus memagari beberapa repositori Git yang terpisah dan timbul masalah dalam mengatur peluncuran beberapa repositori ini. Secara umum, skema seperti itu kelebihan beban dan kompleks. Lebih baik menggabungkan banyak layanan ke dalam satu repositori dan membuat tag Docker sedemikian sehingga tidak ada restart yang tidak perlu.

Git melakukan penandaan

Werf juga memiliki strategi penandaan terkait dengan komitmen Git.

Git-commit adalah pengidentifikasi dari isi repositori Git dan tergantung pada riwayat edit file dalam repositori Git, jadi sepertinya logis untuk menggunakannya untuk menandai gambar di Docker Registry.

Namun, pemberian tag oleh Git commit memiliki kelemahan yang sama seperti oleh cabang Git atau tag Git:

, , Docker- .
merge-, , Docker- .
, Git, , Docker- .

Git-

Ada masalah lain terkait dengan strategi pemberian tag untuk cabang Git.

Penandaan dengan nama cabang bekerja selama komit cabang ini dikumpulkan secara berurutan dalam urutan kronologis.

Jika dalam skema saat ini pengguna mulai membangun kembali komit lama yang terkait dengan beberapa cabang, maka werf akan menghapus gambar menggunakan tag Docker yang sesuai dengan versi gambar yang baru dirakit untuk komit lama. Penyebaran yang menggunakan tag ini mulai sekarang berisiko selama pod restart untuk menarik versi gambar lain, sehingga aplikasi kami akan kehilangan koneksi dengan sistem CI dan tidak akan sinkron.

Selain itu, dengan push'ah berurutan dalam satu cabang dengan interval waktu yang kecil di antara mereka, komit yang lama dapat dikumpulkan lebih lambat dari komit yang lebih baru: versi gambar yang lama akan menghapus yang baru menggunakan tag cabang Git. Masalah tersebut dapat diselesaikan dengan sistem CI / CD (misalnya, di GitLab CI, pipa yang terakhir diluncurkan untuk serangkaian komitmen). Namun, ini tidak didukung oleh semua sistem dan harus ada cara yang lebih dapat diandalkan untuk mencegah masalah mendasar tersebut.

Apa itu penandaan berbasis konten?

Jadi, apa sebenarnya penandaan berbasis konten - penandaan gambar berdasarkan konten.

Untuk membuat tag Docker, bukan Git primitif (Cabang Git, Git tag ...) digunakan, tetapi checksum yang terkait dengan:

. - . , ;
Git. , Git- werf, -.

Apa yang disebut tanda tangan dari tahapan gambar bertindak sebagai tag pengenal .

Setiap gambar terdiri dari serangkaian langkah-langkah: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patchdll Setiap tahap memiliki pengenal, yang mencerminkan kontennya - tahap tanda tangan (stage signature) .

Gambar akhir, yang terdiri dari tahapan-tahapan ini, ditandai dengan apa yang disebut tanda tangan dari set tahapan ini - signature tahapan - yang digeneralisasi untuk semua tahapan gambar.

Setiap gambar dari konfigurasi werf.yamlumumnya akan memiliki tanda tangan sendiri dan, karenanya, tag Docker.

Tanda tangan panggung menyelesaikan semua masalah ini:

Tahan terhadap komit git yang kosong.
Tahan terhadap git yang mengubah file yang tidak relevan dengan gambar.
Tidak menyebabkan masalah dengan menggiling versi gambar saat ini ketika me-restart majelis untuk komit Git lama dari cabang.

Ini sekarang merupakan strategi penandaan yang direkomendasikan dan digunakan secara default di werf untuk semua sistem CI.

Cara mengaktifkan dan menggunakan di werf

Opsi yang sesuai muncul untuk tim werf publish: --tag-by-stages-signature=true|false

Dalam sistem CI, strategi pemberian tag diatur oleh perintah werf ci-env. Sebelumnya, sebuah parameter telah ditentukan untuknya werf ci-env --tagging-strategy=tag-or-branch. Sekarang, jika Anda menentukan werf ci-env --tagging-strategy=stages-signatureopsi ini atau tidak, werf akan menggunakan strategi pemberian tag secara default stages-signature. Perintah werf ci-envakan secara otomatis mengatur tanda yang diperlukan untuk perintah werf build-and-publish(atau werf publish), oleh karena itu, tidak ada opsi tambahan untuk perintah ini yang perlu ditentukan.

Misalnya, perintahnya:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... dapat membuat gambar berikut:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

Berikut 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386dadalah tanda tangan dari tahapan gambar backend, dan f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6merupakan tanda tangan dari tahapan gambar frontend.

Saat menggunakan fungsi khusus werf_container_imagedan werf_container_envdalam templat Helm, tidak ada yang perlu diubah: fungsi ini akan secara otomatis menghasilkan nama gambar yang benar.

Contoh konfigurasi dalam sistem CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Informasi konfigurasi lebih lanjut tersedia dalam dokumentasi:

Total

Opsi baru werf publish --tag-by-stages-signature=true|false.
Nilai baru opsi werf ci-env --tagging-strategy=stages-signature|tag-or-branch(jika tidak ditentukan, itu akan secara default stages-signature).
Jika opsi penandaan untuk Git digunakan sebelumnya ( WERF_TAG_GIT_COMMITatau opsi werf publish --tag-git-commit COMMIT), maka pastikan untuk beralih ke strategi penandaan tahap-tanda tangan .
Proyek-proyek baru lebih baik segera beralih ke skema pemberian tag baru.
Saat menerjemahkan ke werf 1.1, disarankan untuk mengalihkan proyek lama ke skema pemberian tag baru, namun tag-atau-cabang lama masih didukung.

Penandaan berbasis konten memecahkan semua masalah yang disorot dalam artikel:

Stabilitas nama tag Docker untuk mengosongkan komit git.
Stabilitas nama tag Docker ke Git berkomitmen untuk mengubah file yang tidak relevan dengan gambar.
Tidak mengarah ke masalah dengan menggiling versi gambar saat ini ketika me-restart majelis untuk Git lama berkomitmen untuk cabang Git.

Gunakan! Dan jangan lupa mampir ke GitHub kami untuk membuat masalah atau menemukan yang sudah ada, memberi nilai tambah, membuat PR, atau hanya menonton perkembangan proyek.

Penandaan berbasis konten di pengumpul werf: mengapa dan bagaimana cara kerjanya?