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

wer adalah utilitas GitOps CLI open source kami untuk membangun dan mengirimkan aplikasi ke Kubernetes. DI DALAM rilis v1.1 fitur baru diperkenalkan di pengumpul gambar: menandai gambar berdasarkan konten atau penandaan berbasis konten. Hingga saat ini, skema penandaan khas di werf melibatkan penandaan gambar Docker dengan tag Git, cabang Git, atau komitmen Git. Namun semua skema ini memiliki kelemahan yang dapat diatasi sepenuhnya dengan strategi penandaan baru. Detail tentangnya dan mengapa ini begitu bagus masih dalam tahap pembahasan.

Meluncurkan serangkaian layanan mikro dari satu repositori Git

Situasi yang sering terjadi ketika sebuah aplikasi dibagi menjadi beberapa layanan yang kurang lebih independen. Pelepasan layanan ini dapat terjadi secara independen: satu atau lebih layanan dapat dirilis pada satu waktu, sedangkan layanan lainnya harus terus berfungsi tanpa perubahan apa pun. Namun dari sudut pandang penyimpanan kode dan manajemen proyek, akan lebih mudah untuk menyimpan layanan aplikasi tersebut dalam satu repositori.

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

Namun, pada kenyataannya, pengembang sering kali membagi satu aplikasi menjadi beberapa layanan mikro, namun membuat repositori dan proyek terpisah untuk masing-masing aplikasi... jelas merupakan tindakan yang berlebihan. Situasi inilah yang akan dibahas lebih lanjut: beberapa layanan mikro ditempatkan dalam satu repositori proyek dan rilis terjadi melalui satu proses di CI/CD.

Pemberian tag berdasarkan cabang Git dan tag Git

Katakanlah strategi pemberian tag 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 dipublikasikan dengan nama cabang tersebut. Untuk tag Git, gambar diberi tag sesuai dengan nama tag.

Saat tag Git baru dibuat—misalnya, saat versi baru dirilis—tag Docker baru akan dibuat untuk semua image 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 diteruskan melalui templat Helm ke konfigurasi Kubernetes. Saat memulai penerapan dengan perintah werf deploy bidang sedang diperbarui image dalam manifes sumber daya Kubernetes dan memulai ulang sumber daya terkait karena nama gambar yang diubah.

masalah: jika sebenarnya konten gambar tidak berubah sejak peluncuran sebelumnya (tag Git), tetapi hanya tag Dockernya, ini terjadi aneh memulai ulang aplikasi ini dan, karenanya, beberapa waktu henti mungkin terjadi. Meskipun tidak ada alasan nyata untuk melakukan restart ini.

Akibatnya, dengan skema penandaan saat ini, perlu untuk memagari beberapa repositori Git yang terpisah dan muncul masalah dalam mengatur peluncuran beberapa repositori ini. Secara umum, skema seperti itu ternyata kelebihan beban dan rumit. Lebih baik menggabungkan banyak layanan ke dalam satu repositori dan membuat tag Docker sehingga tidak ada restart yang tidak perlu.

Pemberian tag oleh Git commit

werf juga memiliki strategi penandaan yang terkait dengan komitmen Git.

Git-commit adalah pengidentifikasi untuk konten repositori Git dan bergantung pada riwayat edit file di repositori Git, jadi tampaknya logis untuk menggunakannya untuk menandai gambar di Docker Registry.

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

Komit kosong dapat dibuat yang tidak mengubah file apa pun, tetapi tag Docker pada gambar akan diubah.
Komit gabungan dapat dibuat yang tidak mengubah file, tetapi tag Docker pada gambar akan diubah.
Komit dapat dilakukan untuk mengubah file-file di Git yang tidak diimpor ke dalam image, dan tag Docker pada image tersebut akan diubah lagi.

Memberi tag pada nama cabang Git tidak mencerminkan versi gambar

Ada masalah lain yang terkait dengan strategi penandaan untuk cabang Git.

Pemberian tag berdasarkan nama cabang berfungsi selama komitmen pada cabang tersebut dikumpulkan secara berurutan dalam urutan kronologis.

Jika dalam skema saat ini pengguna mulai membangun kembali komit lama yang terkait dengan cabang tertentu, maka werf akan menulis ulang gambar menggunakan tag Docker yang sesuai dengan versi gambar yang baru dibuat untuk komit lama. Penerapan yang menggunakan tag ini mulai sekarang berisiko menarik versi image yang berbeda saat memulai ulang pod, akibatnya aplikasi kita akan kehilangan koneksi dengan sistem CI dan menjadi tidak sinkron.

Selain itu, dengan dorongan berturut-turut ke dalam satu cabang dengan periode waktu yang singkat di antara keduanya, komit lama dapat dikompilasi lebih lambat dari komit yang lebih baru: versi gambar yang lama akan menimpa yang baru menggunakan tag cabang Git. Masalah seperti itu dapat diselesaikan dengan sistem CI/CD (misalnya, di GitLab CI, pipeline sistem CI/CD diluncurkan untuk serangkaian penerapan). Namun, tidak semua sistem mendukung hal ini dan harus ada cara yang lebih dapat diandalkan untuk mencegah masalah mendasar tersebut.

Apa itu penandaan berbasis konten?

Jadi, apa itu penandaan berbasis konten - menandai gambar berdasarkan konten.

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

isi gambar. Tag ID gambar mencerminkan isinya. Saat membuat versi baru, pengidentifikasi ini tidak akan berubah jika file dalam gambar tidak berubah;
sejarah pembuatan gambar ini di Git. Gambar yang terkait dengan cabang Git berbeda dan riwayat pembuatan berbeda melalui werf akan memiliki tag ID berbeda.

Tag pengidentifikasi seperti itu disebut tanda tangan panggung gambar.

Setiap gambar terdiri dari serangkaian tahapan: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch dll. Setiap tahap memiliki pengidentifikasi yang mencerminkan isinya - tanda tangan panggung (tanda tangan panggung).

Gambar akhir, yang terdiri dari tahapan-tahapan ini, ditandai dengan apa yang disebut tanda tangan dari himpunan tahapan-tahapan ini - tanda tangan tahapan, - yang menggeneralisasi untuk semua tahapan gambar.

Untuk setiap gambar dari konfigurasi werf.yaml dalam kasus umum, akan ada tanda tangannya sendiri dan, karenanya, tag Docker.

Tanda tangan panggung menyelesaikan semua masalah ini:

Tahan terhadap komitmen Git yang kosong.
Tahan terhadap komitmen Git yang mengubah file yang tidak relevan dengan gambar.
Tidak menyebabkan masalah merombak versi gambar saat ini ketika memulai ulang build untuk komitmen Git lama di suatu cabang.

Ini sekarang merupakan strategi pemberian tag yang direkomendasikan dan merupakan default di werf untuk semua sistem CI.

Cara mengaktifkan dan menggunakan di werf

Perintah tersebut sekarang memiliki opsi yang sesuai werf publish: --tag-by-stages-signature=true|false

Dalam sistem CI, strategi penandaan ditentukan oleh perintah werf ci-env. Sebelumnya, parameter telah ditentukan untuknya werf ci-env --tagging-strategy=tag-or-branch. Sekarang, jika Anda menentukannya werf ci-env --tagging-strategy=stages-signature atau jangan tentukan opsi ini, werf akan menggunakan strategi penandaan secara default stages-signature. Tim werf ci-env akan secara otomatis menyetel tanda yang diperlukan untuk perintah tersebut werf build-and-publish (Atau werf publish), jadi tidak ada opsi tambahan yang perlu ditentukan untuk perintah ini.

Misalnya perintah:

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

Di sini 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d merupakan tanda tangan dari tahapan gambar backendDan f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - tanda tangan tahapan gambar frontend.

Saat menggunakan fungsi khusus werf_container_image и werf_container_env Tidak perlu mengubah apa pun di templat Helm: 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 lebih lanjut tentang konfigurasi tersedia di dokumentasi:

Total

Pilihan baru werf publish --tag-by-stages-signature=true|false.
Nilai opsi baru werf ci-env --tagging-strategy=stages-signature|tag-or-branch (jika tidak ditentukan, defaultnya adalah stages-signature).
Jika sebelumnya Anda menggunakan opsi penandaan untuk penerapan Git (WERF_TAG_GIT_COMMIT atau pilihan werf publish --tag-git-commit COMMIT), lalu pastikan untuk beralih ke strategi pemberian tag tahapan-tanda tangan.
Sebaiknya segera alihkan proyek baru ke skema penandaan baru.
Saat mentransfer ke werf 1.1, disarankan untuk mengalihkan proyek lama ke skema penandaan baru, tetapi yang lama tag-atau-cabang masih didukung.

Pemberian tag berbasis konten menyelesaikan semua masalah yang tercakup dalam artikel:

Resistensi nama tag Docker terhadap komitmen Git kosong.
Ketahanan nama tag Docker terhadap Git melakukan perubahan file yang tidak relevan dengan image.
Tidak menyebabkan masalah merombak versi gambar saat ini ketika memulai ulang build untuk komitmen Git lama untuk cabang Git.

Gunakan! Dan jangan lupa kunjungi kami di GitHubuntuk membuat isu atau menemukan isu yang sudah ada, menambah nilai tambah, membuat PR atau sekadar melihat perkembangan proyek.

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