🥇 Werf toplayıcıda içerik tabanlı etiketleme: neden ve nasıl çalışıyor?

Werf Kubernetes'e uygulamalar oluşturmaya ve sunmaya yönelik açık kaynaklı GitOps CLI yardımcı programımızdır. İÇİNDE v1.1'i yayınla görüntü toplayıcıya yeni bir özellik eklendi: görüntüleri içeriğe göre etiketlemek veya içerik tabanlı etiketleme. Şimdiye kadar werf'teki tipik etiketleme şeması, Docker görüntülerinin Git etiketi, Git şubesi veya Git taahhüdü ile etiketlenmesini içeriyordu. Ancak tüm bu planların, yeni etiketleme stratejisiyle tamamen çözülen dezavantajları vardır. Bununla ilgili ayrıntılar ve neden bu kadar iyi olduğu kesim altında.

Bir Git deposundan bir dizi mikro hizmetin kullanıma sunulması

Bir uygulamanın az çok bağımsız hizmetlere bölünmesiyle sık sık bir durum ortaya çıkar. Bu hizmetlerin sürümleri bağımsız olarak gerçekleşebilir: aynı anda bir veya daha fazla hizmet yayınlanabilirken geri kalanların herhangi bir değişiklik olmadan çalışmaya devam etmesi gerekir. Ancak kod depolama ve proje yönetimi açısından bu tür uygulama hizmetlerinin tek bir depoda tutulması daha uygundur.

Hizmetlerin gerçekten bağımsız olduğu ve tek bir uygulamayla ilişkilendirilmediği durumlar vardır. Bu durumda, bunlar ayrı projelerde yer alacak ve yayınları her projede ayrı CI/CD süreçleriyle gerçekleştirilecektir.

Ancak gerçekte geliştiriciler genellikle tek bir uygulamayı birkaç mikro hizmete bölerler, ancak her biri için ayrı bir depo ve proje oluşturmak açık bir şekilde aşırılıktır. Bu durum daha ayrıntılı olarak tartışılacaktır: Bu tür birkaç mikro hizmet tek bir proje deposunda bulunur ve sürümler CI/CD'deki tek bir süreç aracılığıyla gerçekleşir.

Git şubesine ve Git etiketine göre etiketleme

En yaygın etiketleme stratejisinin kullanıldığını varsayalım: etiket veya şube. Git şubeleri için resimler şubenin adıyla etiketlenir; aynı anda bir şube için, o şubenin adına göre yayınlanmış yalnızca bir resim bulunur. Git etiketleri için resimler etiket adına göre etiketlenir.

Yeni bir Git etiketi oluşturulduğunda (örneğin, yeni bir sürüm yayınlandığında), Docker Kayıt Defterindeki tüm proje görüntüleri için yeni bir Docker etiketi oluşturulacaktır:

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

Bu yeni görüntü adları, Helm şablonları aracılığıyla Kubernetes yapılandırmasına aktarılır. Komutla dağıtımı başlatırken werf deploy alan güncelleniyor image Kubernetes'te kaynak, değişen görüntü adı nedeniyle ilgili kaynakları gösterir ve yeniden başlatır.

Sorun: aslında görüntünün içeriğinin önceki kullanıma sunulmasından bu yana değişmediği (Git etiketi) ancak yalnızca Docker etiketinin değiştiği durumda, bu durum gerçekleşir fazlalık bu uygulamayı yeniden başlatmak ve buna bağlı olarak bir miktar kesinti mümkündür. Bu yeniden başlatmayı gerçekleştirmek için gerçek bir neden olmamasına rağmen.

Sonuç olarak, mevcut etiketleme şemasıyla birkaç ayrı Git deposunun çitlenmesi gerekiyor ve bu çeşitli depoların kullanıma sunulmasının organize edilmesinde sorun ortaya çıkıyor. Genel olarak böyle bir planın aşırı yüklü ve karmaşık olduğu ortaya çıkıyor. Gereksiz yeniden başlatmaların önlenmesi için birçok hizmeti tek bir depoda birleştirmek ve Docker etiketleri oluşturmak daha iyidir.

Git taahhütüne göre etiketleme

werf'in ayrıca Git taahhütleriyle ilişkili bir etiketleme stratejisi vardır.

Git-commit, Git deposunun içeriğine yönelik bir tanımlayıcıdır ve Git deposundaki dosyaların düzenleme geçmişine bağlıdır, bu nedenle Docker Kayıt Defterindeki görüntüleri etiketlemek için bunu kullanmak mantıklı görünüyor.

Ancak Git işlemine göre etiketleme, Git dallarına veya Git etiketlerine göre etiketlemeyle aynı dezavantajlara sahiptir:

Hiçbir dosyayı değiştirmeyen boş bir taahhüt oluşturulabilir, ancak görüntünün Docker etiketi değiştirilecektir.
Dosyaları değiştirmeyen bir birleştirme işlemi oluşturulabilir ancak görüntünün Docker etiketi değiştirilecektir.
Git'te görüntüye aktarılmayan dosyaları değiştiren bir taahhüt yapılabilir ve görüntünün Docker etiketi yeniden değiştirilir.

Git şube adının etiketlenmesi görsel sürümünü yansıtmıyor

Git dallarına yönelik etiketleme stratejisiyle ilgili başka bir sorun daha var.

Şube adına göre etiketleme, o daldaki taahhütler kronolojik sırayla toplandığı sürece çalışır.

Mevcut şemada kullanıcı belirli bir dalla ilişkili eski bir işlemi yeniden oluşturmaya başlarsa, werf, ilgili Docker etiketini kullanarak görüntüyü eski işleme için görüntünün yeni oluşturulmuş bir sürümüyle yeniden yazacaktır. Artık bu etiketi kullanan dağıtımlar, pod'ları yeniden başlatırken görüntünün farklı bir versiyonunu çekme riskiyle karşı karşıya kalacak ve bunun sonucunda uygulamamız CI sistemiyle bağlantısını kaybedecek ve senkronizasyonu bozulacaktır.

Buna ek olarak, aralarında kısa bir süre bulunan bir şubeye art arda itmeler yapıldığında, eski kayıt yenisinden daha sonra derlenebilir: Git şube etiketini kullanarak görüntünün eski sürümü yenisinin üzerine yazacaktır. Bu tür sorunlar bir CI/CD sistemi tarafından çözülebilir (örneğin, GitLab CI'da ikincisinin işlem hattı bir dizi taahhüt için başlatılır). Ancak tüm sistemler bunu desteklemiyor ve bu kadar temel bir sorunu önlemenin daha güvenilir bir yolu olması gerekiyor.

İçerik tabanlı etiketleme nedir?

Peki, içerik tabanlı etiketleme nedir, yani görselleri içeriğe göre etiketlemek.

Docker etiketleri oluşturmak için kullanılan Git ilkelleri (Git dalı, Git etiketi...) değil, aşağıdakilerle ilişkili bir sağlama toplamıdır:

görselin içeriği. Resim kimlik etiketi, içeriğini yansıtır. Yeni bir sürüm oluştururken, görüntüdeki dosyalar değişmediyse bu tanımlayıcı değişmeyecektir;
Git'te bu görüntüyü oluşturmanın geçmişi. Werf aracılığıyla farklı Git dalları ve farklı derleme geçmişiyle ilişkilendirilen görseller, farklı kimlik etiketlerine sahip olacaktır.

Böyle bir tanımlayıcı etikete sözde resim sahne imzası.

Her görüntü bir dizi aşamadan oluşur: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch vesaire. Her aşamanın içeriğini yansıtan bir tanımlayıcısı vardır – sahne imzası (sahne imzası).

Bu aşamalardan oluşan son görüntü, bu aşamaların imzası olarak adlandırılan etiketle etiketlenmiştir. aşama imzası, - görüntünün tüm aşamaları için genelleme yapan.

Yapılandırmadaki her görüntü için werf.yaml genel durumda kendi imzası ve buna göre bir Docker etiketi olacaktır.

Sahne imzası tüm bu sorunları çözer:

Boş Git taahhütlerine karşı dayanıklıdır.
Git'e dayanıklı, görüntüyle alakalı olmayan dosyaları değiştiren taahhütlerdir.
Bir dalın eski Git taahhütleri için derlemeleri yeniden başlatırken görüntünün geçerli sürümünün elden geçirilmesi sorununa yol açmaz.

Bu artık önerilen etiketleme stratejisidir ve tüm CI sistemleri için werf'te varsayılandır.

Werf'te nasıl etkinleştirilir ve kullanılır?

Komutun artık karşılık gelen bir seçeneği var werf publish: --tag-by-stages-signature=true|false

Bir CI sisteminde etiketleme stratejisi komut tarafından belirtilir. werf ci-env. Daha önce bunun için parametre tanımlanmıştı werf ci-env --tagging-strategy=tag-or-branch. Şimdi belirtirseniz werf ci-env --tagging-strategy=stages-signature veya bu seçeneği belirtmeyin, werf varsayılan olarak etiketleme stratejisini kullanacaktır stages-signature. Takım werf ci-env komut için gerekli bayrakları otomatik olarak ayarlayacaktır werf build-and-publish (ya werf publish), dolayısıyla bu komutlar için ek seçeneklerin belirtilmesine gerek yoktur.

Örneğin, komut:

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

...aşağıdaki görüntüleri oluşturabilir:

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

öyle 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d görüntünün aşamalarının bir imzasıdır backendVe f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - görüntü aşamalarının imzası frontend.

Özel işlevleri kullanırken werf_container_image и werf_container_env Helm şablonlarında herhangi bir şeyi değiştirmenize gerek yoktur: bu işlevler otomatik olarak doğru görüntü adlarını oluşturacaktır.

Bir CI sisteminde örnek konfigürasyon:

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

Yapılandırma hakkında daha fazla bilgiyi belgelerde bulabilirsiniz:

Toplam

Yeni seçenek werf publish --tag-by-stages-signature=true|false.
Yeni seçenek değeri werf ci-env --tagging-strategy=stages-signature|tag-or-branch (belirtilmemişse, varsayılan stages-signature).
Daha önce Git taahhütleri için etiketleme seçeneklerini kullandıysanız (WERF_TAG_GIT_COMMIT veya seçenek werf publish --tag-git-commit COMMIT), ardından etiketleme stratejisine geçtiğinizden emin olun. aşama-imza.
Yeni projeleri hemen yeni etiketleme şemasına geçirmek daha iyidir.
Werf 1.1'e geçiş yaparken eski projelerin yeni etiketleme şemasına geçirilmesi tavsiye edilir, ancak eski proje etiket veya şube hala desteklenmektedir.

İçerik tabanlı etiketleme, makalede ele alınan tüm sorunları çözer:

Boş Git taahhütlerine karşı Docker etiketi adı direnci.
Docker etiketi adının Git'e dayanıklılığı, görüntüyle ilgisi olmayan dosyaları değiştiren taahhütlerdir.
Git dalları için eski Git taahhütlerine yönelik derlemeleri yeniden başlatırken görüntünün geçerli sürümünün elden geçirilmesi sorununa yol açmaz.

Kullan onu! Bizi ziyaret etmeyi unutmayın GitHubbir sorun oluşturmak veya mevcut bir sorunu bulmak, bir artı eklemek, bir PR oluşturmak veya yalnızca projenin gelişimini izlemek için.

PS

Blogumuzda da okuyun:

Kaynak: habr.com

Werf toplayıcıda içerik tabanlı etiketleme: neden ve nasıl çalışıyor?