🥇Teg berasaskan kandungan dalam pengumpul werf: mengapa dan bagaimana ia berfungsi?

werf ialah utiliti GitOps CLI sumber terbuka kami untuk membina dan menghantar aplikasi kepada Kubernetes. DALAM keluarkan v1.1 ciri baharu telah diperkenalkan dalam pengumpul imej: menandai imej mengikut kandungan atau penandaan berasaskan kandungan. Sehingga kini, skema penandaan biasa dalam werf melibatkan penandaan imej Docker dengan tag Git, cawangan Git atau komit Git. Tetapi semua skim ini mempunyai kelemahan yang diselesaikan sepenuhnya oleh strategi penandaan baharu. Butiran mengenainya dan mengapa ia begitu baik adalah di bawah potongan.

Melancarkan satu set perkhidmatan mikro daripada satu repositori Git

Situasi sering berlaku apabila aplikasi dibahagikan kepada lebih banyak atau kurang perkhidmatan bebas. Pengeluaran perkhidmatan ini boleh berlaku secara bebas: satu atau lebih perkhidmatan boleh dikeluarkan pada satu masa, manakala selebihnya mesti terus berfungsi tanpa sebarang perubahan. Tetapi dari sudut penyimpanan kod dan pengurusan projek, adalah lebih mudah untuk menyimpan perkhidmatan aplikasi sedemikian dalam satu repositori.

Terdapat situasi apabila perkhidmatan benar-benar bebas dan tidak dikaitkan dengan satu aplikasi. Dalam kes ini, mereka akan ditempatkan dalam projek yang berasingan dan pelepasan mereka akan dijalankan melalui proses CI/CD yang berasingan dalam setiap projek.

Walau bagaimanapun, pada hakikatnya, pembangun sering membahagikan satu aplikasi kepada beberapa perkhidmatan mikro, tetapi mencipta repositori dan projek berasingan untuk setiap... adalah keterlaluan yang jelas. Situasi inilah yang akan dibincangkan lebih lanjut: beberapa perkhidmatan mikro tersebut terletak dalam satu repositori projek dan keluaran berlaku melalui satu proses dalam CI/CD.

Penandaan oleh cawangan Git dan tag Git

Katakan strategi penandaan yang paling biasa digunakan - tag-atau-cawangan. Untuk cawangan Git, imej ditandakan dengan nama cawangan, untuk satu cawangan pada satu masa hanya terdapat satu imej yang diterbitkan dengan nama cawangan itu. Untuk teg Git, imej ditag mengikut nama teg.

Apabila teg Git baharu dibuat—contohnya, apabila versi baharu dikeluarkan—teg Docker baharu akan dibuat untuk semua imej projek dalam Pendaftaran Docker:

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 imej baharu ini dihantar melalui templat Helm ke konfigurasi Kubernetes. Apabila memulakan penggunaan dengan arahan werf deploy medan sedang dikemas kini image dalam sumber Kubernetes manifes dan memulakan semula sumber yang sepadan disebabkan nama imej yang ditukar.

masalah: dalam kes apabila, sebenarnya, kandungan imej tidak berubah sejak pelancaran sebelumnya (Git tag), tetapi hanya teg Dockernya, ini berlaku tambahan memulakan semula aplikasi ini dan, oleh itu, beberapa masa henti mungkin mungkin. Walaupun tidak ada sebab sebenar untuk melakukan mula semula ini.

Akibatnya, dengan skim penandaan semasa adalah perlu untuk memagar beberapa repositori Git yang berasingan dan masalah timbul untuk mengatur pelancaran beberapa repositori ini. Secara umum, skim sedemikian ternyata terlalu banyak dan kompleks. Adalah lebih baik untuk menggabungkan banyak perkhidmatan ke dalam satu repositori dan mencipta tag Docker supaya tiada restart yang tidak perlu.

Penandaan oleh Git commit

werf juga mempunyai strategi penandaan yang dikaitkan dengan komitmen Git.

Git-commit ialah pengecam untuk kandungan repositori Git dan bergantung pada sejarah suntingan fail dalam repositori Git, jadi nampaknya logik untuk menggunakannya untuk menandai imej dalam Docker Registry.

Walau bagaimanapun, penandaan oleh Git commit mempunyai kelemahan yang sama seperti penandaan oleh cawangan Git atau tag Git:

Komit kosong boleh dibuat yang tidak mengubah sebarang fail, tetapi teg Docker pada imej akan ditukar.
Komit gabungan boleh dibuat yang tidak mengubah fail, tetapi teg Docker bagi imej akan ditukar.
Komit boleh dibuat yang mengubah fail tersebut dalam Git yang tidak diimport ke dalam imej, dan teg Docker bagi imej akan ditukar semula.

Menandai nama cawangan Git tidak menggambarkan versi imej

Terdapat satu lagi masalah yang berkaitan dengan strategi penandaan untuk cawangan Git.

Penandaan nama cawangan berfungsi selagi komitmen pada cawangan itu dikumpulkan secara berurutan dalam susunan kronologi.

Jika dalam skema semasa pengguna mula membina semula komit lama yang dikaitkan dengan cawangan tertentu, maka werf akan menulis semula imej menggunakan tag Docker yang sepadan dengan versi imej yang baru dibina untuk komit lama. Penerapan menggunakan teg ini mulai sekarang berisiko menarik versi imej yang berbeza apabila memulakan semula pod, akibatnya aplikasi kami akan kehilangan sambungan dengan sistem CI dan menjadi tidak segerak.

Di samping itu, dengan tolakan berturut-turut ke dalam satu cawangan dengan tempoh masa yang singkat di antara mereka, komit lama mungkin disusun kemudian daripada yang lebih baharu: versi lama imej akan menimpa yang baharu menggunakan teg cawangan Git. Masalah sedemikian boleh diselesaikan dengan sistem CI/CD (contohnya, dalam GitLab CI saluran paip yang terakhir dilancarkan untuk satu siri komit). Walau bagaimanapun, tidak semua sistem menyokong ini dan mesti ada cara yang lebih dipercayai untuk mencegah masalah asas tersebut.

Apakah penandaan berasaskan kandungan?

Jadi, apakah itu penandaan berasaskan kandungan - penandaan imej mengikut kandungan.

Untuk membuat teg Docker, bukan primitif Git (cawangan Git, teg Git...) yang digunakan, tetapi checksum yang dikaitkan dengan:

kandungan imej. Teg ID imej mencerminkan kandungannya. Apabila membina versi baharu, pengecam ini tidak akan berubah jika fail dalam imej tidak berubah;
sejarah mencipta imej ini dalam Git. Imej yang dikaitkan dengan cawangan Git yang berbeza dan sejarah binaan yang berbeza melalui werf akan mempunyai tag ID yang berbeza.

Tag pengecam sebegitu adalah yang dipanggil tandatangan pentas imej.

Setiap imej terdiri daripada satu set peringkat: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch dan lain-lain. Setiap peringkat mempunyai pengecam yang mencerminkan kandungannya − tandatangan pentas (tandatangan pentas).

Imej akhir, yang terdiri daripada peringkat ini, ditandakan dengan apa yang dipanggil tandatangan set peringkat ini - tandatangan peringkat, - yang membuat generalisasi untuk semua peringkat imej.

Untuk setiap imej daripada konfigurasi werf.yaml dalam kes umum, akan ada tandatangannya sendiri dan, oleh itu, tag Docker.

Tandatangan pentas menyelesaikan semua masalah ini:

Tahan terhadap komit Git kosong.
Resistant to Git commit yang menukar fail yang tidak berkaitan dengan imej.
Tidak membawa kepada masalah membaik pulih versi semasa imej apabila memulakan semula binaan untuk komit Git lama bagi cawangan.

Ini kini merupakan strategi penandaan yang disyorkan dan merupakan lalai dalam werf untuk semua sistem CI.

Bagaimana untuk membolehkan dan menggunakan dalam werf

Perintah itu kini mempunyai pilihan yang sepadan werf publish: --tag-by-stages-signature=true|false

Dalam sistem CI, strategi penandaan ditentukan oleh arahan werf ci-env. Sebelum ini, parameter telah ditakrifkan untuknya werf ci-env --tagging-strategy=tag-or-branch. Sekarang, jika anda nyatakan werf ci-env --tagging-strategy=stages-signature atau jangan nyatakan pilihan ini, werf akan menggunakan strategi penandaan secara lalai stages-signature. Pasukan werf ci-env akan secara automatik menetapkan bendera yang diperlukan untuk arahan itu werf build-and-publish (Atau werf publish), jadi tiada pilihan tambahan perlu ditentukan untuk arahan ini.

Sebagai contoh, arahan:

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

...boleh mencipta imej berikut:

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

ia adalah 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d adalah tandatangan peringkat-peringkat imej backendDan f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - tandatangan peringkat imej frontend.

Apabila menggunakan fungsi khas werf_container_image и werf_container_env Tidak perlu menukar apa-apa dalam templat Helm: fungsi ini akan menjana nama imej yang betul secara automatik.

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

Maklumat lanjut tentang konfigurasi tersedia dalam dokumentasi:

Dalam jumlah

Pilihan baharu werf publish --tag-by-stages-signature=true|false.
Nilai pilihan baharu werf ci-env --tagging-strategy=stages-signature|tag-or-branch (jika tidak dinyatakan, lalainya ialah stages-signature).
Jika anda sebelum ini menggunakan pilihan penandaan untuk Git commit (WERF_TAG_GIT_COMMIT atau pilihan werf publish --tag-git-commit COMMIT), kemudian pastikan anda beralih kepada strategi penandaan peringkat-tandatangan.
Adalah lebih baik untuk segera menukar projek baharu kepada skim penandaan baharu.
Apabila memindahkan ke werf 1.1, adalah dinasihatkan untuk menukar projek lama kepada skim penandaan baharu, tetapi projek lama tag-atau-cawangan masih disokong.

Pengetegan berasaskan kandungan menyelesaikan semua masalah yang diliputi dalam artikel:

Rintangan nama tag Docker terhadap komit Git kosong.
Rintangan nama tag Docker kepada Git melakukan yang menukar fail yang tidak berkaitan dengan imej.
Tidak membawa kepada masalah membaik pulih versi semasa imej apabila memulakan semula binaan untuk komit Git lama untuk cawangan Git.

Gunakannya! Dan jangan lupa kunjungi kami di GitHubuntuk mencipta isu atau mencari isu sedia ada, menambah tambah, mencipta PR atau hanya menonton pembangunan projek.

Pengetegan berasaskan kandungan dalam pembina werf: mengapa dan bagaimana ia berfungsi?