🥇Werf kollektorunda məzmuna əsaslanan etiketləmə: niyə və necə işləyir?

werf proqramların yaradılması və Kubernetes-ə çatdırılması üçün açıq mənbəli GitOps CLI yardım proqramımızdır. IN buraxılış v1.1 Şəkil kollektorunda yeni funksiya təqdim edildi: şəkilləri məzmuna görə etiketləmək və ya məzmuna əsaslanan etiketləmə. İndiyə qədər werf-də tipik etiketləmə sxemi Docker şəkillərinin Git teqi, Git filialı və ya Git commit ilə etiketlənməsini nəzərdə tuturdu. Ancaq bütün bu sxemlərin yeni etiketləmə strategiyası ilə tamamilə həll olunan çatışmazlıqları var. Onun haqqında təfərrüatlar və niyə bu qədər yaxşı olduğu kəsik altındadır.

Bir Git deposundan bir sıra mikroxidmətlərin yayılması

Tətbiq daha çox və ya daha az müstəqil xidmətlərə bölündükdə vəziyyət tez-tez baş verir. Bu xidmətlərin buraxılışları müstəqil şəkildə baş verə bilər: bir və ya bir neçə xidmət bir anda buraxıla bilər, qalanları isə heç bir dəyişiklik olmadan işləməyə davam etməlidir. Amma kodun saxlanması və layihənin idarə edilməsi baxımından bu cür tətbiq xidmətlərini vahid depoda saxlamaq daha rahatdır.

Xidmətlərin həqiqətən müstəqil olduğu və tək bir tətbiqlə əlaqəli olmadığı vəziyyətlər var. Bu halda, onlar ayrı-ayrı layihələrdə yerləşdiriləcək və onların buraxılması layihələrin hər birində ayrıca CI/CD prosesləri vasitəsilə həyata keçiriləcək.

Bununla belə, reallıqda tərtibatçılar tez-tez bir tətbiqi bir neçə mikroservisə bölürlər, lakin hər biri üçün ayrıca repozitoriya və layihə yaratmaq... açıq-aşkar həddən artıq işdir. Məhz bu vəziyyət daha sonra müzakirə olunacaq: bir neçə belə mikroservis bir layihə deposunda yerləşir və buraxılışlar CI/CD-də bir proses vasitəsilə baş verir.

Git filialı və Git teqi ilə etiketləmə

Deyək ki, ən çox yayılmış etiketləmə strategiyası istifadə olunur - etiket və ya filial. Git filialları üçün şəkillər filialın adı ilə etiketlənir, bir filial üçün hər dəfə bu filialın adı ilə dərc edilmiş yalnız bir şəkil var. Git teqləri üçün şəkillər teq adına uyğun olaraq etiketlənir.

Yeni Git teqi yaradıldıqda, məsələn, yeni versiya buraxıldıqda, Docker Registry-də bütün layihə şəkilləri üçün yeni Docker teqi yaradılacaq:

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 şəkil adları Helm şablonlarından Kubernetes konfiqurasiyasına ötürülür. Komanda ilə yerləşdirməyə başladıqda werf deploy sahə yenilənir image Kubernetes resursunda dəyişdirilmiş şəkil adına görə müvafiq resursları göstərir və yenidən işə salır.

problem: əslində şəklin məzmunu əvvəlki buraxılışdan (Git teqi) dəyişməyib, ancaq onun Docker teqi olduqda bu baş verir. həddən artıq bu tətbiqin yenidən başlaması və buna uyğun olaraq müəyyən fasilələr mümkündür. Baxmayaraq ki, bu yenidən başlamanı həyata keçirmək üçün heç bir real səbəb yox idi.

Nəticədə, mövcud etiketləmə sxemi ilə bir neçə ayrı Git deposunu hasarlamaq lazımdır və bu bir neçə deponun yayılmasının təşkili problemi yaranır. Ümumiyyətlə, belə bir sxem həddindən artıq yüklənmiş və mürəkkəbdir. Bir çox xidmətləri bir repozitoriyada birləşdirib Docker teqlərini yaratmaq daha yaxşıdır ki, lazımsız yenidən işə salınmasın.

Git commit tərəfindən etiketləmə

werf də Git öhdəliyi ilə əlaqəli etiketləmə strategiyasına malikdir.

Git-commit Git repozitoriyasının məzmunu üçün identifikatordur və Git repozitoriyasındakı faylların redaktə tarixindən asılıdır, ona görə də ondan Docker Reyestrində şəkilləri etiketləmək üçün istifadə etmək məntiqli görünür.

Bununla belə, Git commit tərəfindən etiketləmə Git filialları və ya Git teqləri ilə etiketləmə ilə eyni çatışmazlıqlara malikdir:

Heç bir faylı dəyişdirməyən boş öhdəlik yaradıla bilər, lakin şəklin Docker teqi dəyişdiriləcək.
Faylları dəyişdirməyən birləşmə öhdəliyi yaradıla bilər, lakin şəklin Docker teqi dəyişdiriləcək.
Git-də şəkilə idxal edilməyən faylları dəyişdirən bir öhdəlik götürülə bilər və şəklin Docker teqi yenidən dəyişdiriləcəkdir.

Git filialının adının etiketlənməsi şəkil versiyasını əks etdirmir

Git filialları üçün etiketləmə strategiyası ilə bağlı başqa bir problem var.

Filial adı ilə etiketləmə, həmin filial üzrə öhdəliklər xronoloji ardıcıllıqla ardıcıl olaraq toplandığı müddətcə işləyir.

Əgər cari sxemdə istifadəçi müəyyən filialla əlaqəli köhnə öhdəliyi yenidən qurmağa başlayırsa, onda werf köhnə öhdəlik üçün təsvirin yeni qurulmuş versiyası ilə uyğun Docker teqindən istifadə edərək şəkli yenidən yazacaq. Bundan sonra bu teqdən istifadə edən yerləşdirmələr podları yenidən işə salarkən təsvirin fərqli versiyasını çəkmə riskini daşıyır, nəticədə tətbiqimiz CI sistemi ilə əlaqəni itirəcək və sinxronizasiya olunmayacaq.

Bundan əlavə, aralarında qısa müddət olan bir budaqda ardıcıl itələmələrlə köhnə öhdəlik yenidən daha gec tərtib edilə bilər: şəklin köhnə versiyası Git filial teqindən istifadə edərək yenisinin üzərinə yazacaq. Bu cür problemlər CI/CD sistemi ilə həll edilə bilər (məsələn, GitLab CI-də sonuncunun boru kəməri bir sıra öhdəliklər üçün işə salınır). Ancaq bütün sistemlər bunu dəstəkləmir və belə bir fundamental problemin qarşısını almaq üçün daha etibarlı yol olmalıdır.

Məzmun əsaslı etiketləmə nədir?

Beləliklə, məzmuna əsaslanan etiketləmə nədir - şəkilləri məzmuna görə etiketləmək.

Docker teqlərini yaratmaq üçün Git primitivləri (Git filialı, Git teqi...) deyil, aşağıdakılarla əlaqəli yoxlama cəmi istifadə olunur:

şəklin məzmunu. Şəkil ID etiketi onun məzmununu əks etdirir. Yeni versiya qurarkən, təsvirdəki fayllar dəyişməyibsə, bu identifikator dəyişməyəcək;
Git-də bu görüntünün yaradılması tarixi. Fərqli Git filialları və werf vasitəsilə fərqli tikinti tarixçələri ilə əlaqəli şəkillərdə fərqli ID teqləri olacaq.

Belə bir identifikator etiketi sözdə deyilir görüntü səhnə imzası.

Hər bir şəkil bir sıra mərhələlərdən ibarətdir: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch və s. Hər bir mərhələnin məzmununu əks etdirən identifikatoru var - səhnə imzası (mərhələ imzası).

Bu mərhələlərdən ibarət olan son şəkil, bu mərhələlər dəstinin sözdə imzası ilə işarələnir - imza mərhələləri, - təsvirin bütün mərhələləri üçün ümumiləşdirici olan.

Konfiqurasiyadan hər bir şəkil üçün werf.yaml ümumi halda öz imzası və müvafiq olaraq Docker teqi olacaq.

Səhnə imzası bütün bu problemləri həll edir:

Boş Git öhdəliklərinə davamlıdır.
Git-ə qarşı müqavimət, şəkilə uyğun olmayan faylları dəyişdirməyi öhdəsinə götürür.
Bir filialın köhnə Git öhdəliyi üçün konstruksiyaları yenidən başladarkən təsvirin cari versiyasının əsaslı təmiri probleminə səbəb olmur.

Bu, indi tövsiyə olunan etiketləmə strategiyasıdır və bütün CI sistemləri üçün werf-də defoltdur.

werf-də necə aktivləşdirmək və istifadə etmək olar

Komanda indi müvafiq seçimə malikdir werf publish: --tag-by-stages-signature=true|false

CI sistemində etiketləmə strategiyası komanda tərəfindən müəyyən edilir werf ci-env. Əvvəllər bunun üçün parametr müəyyən edilmişdi werf ci-env --tagging-strategy=tag-or-branch. İndi müəyyən etsəniz werf ci-env --tagging-strategy=stages-signature və ya bu seçimi qeyd etməsəniz, werf standart olaraq etiketləmə strategiyasından istifadə edəcək stages-signature. Komanda werf ci-env əmr üçün lazımi bayraqları avtomatik təyin edəcək werf build-and-publish (Və ya werf publish), buna görə də bu əmrlər üçün heç bir əlavə seçim göstərilməsinə ehtiyac yoxdur.

Məsələn, əmr:

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

...aşağıdakı şəkilləri yarada bilər:

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

Burada 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d təsvirin mərhələlərinin imzasıdır backendVə f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - şəkil mərhələlərinin imzası frontend.

Xüsusi funksiyalardan istifadə edərkən werf_container_image и werf_container_env Helm şablonlarında heç nəyi dəyişməyə ehtiyac yoxdur: bu funksiyalar avtomatik olaraq düzgün təsvir adlarını yaradacaq.

CI sistemində konfiqurasiya nümunəsi:

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

Konfiqurasiya haqqında daha çox məlumat sənədlərdə mövcuddur:

Ümumi

Yeni seçim werf publish --tag-by-stages-signature=true|false.
Yeni seçim dəyəri werf ci-env --tagging-strategy=stages-signature|tag-or-branch (müəyyən edilməmişsə, defolt olacaq stages-signature).
Əgər əvvəllər Git commits üçün etiketləmə seçimlərindən istifadə etmisinizsə (WERF_TAG_GIT_COMMIT və ya seçim werf publish --tag-git-commit COMMIT), sonra etiketləmə strategiyasına keçdiyinizə əmin olun mərhələlər-imza.
Yeni layihələri dərhal yeni etiketləmə sxeminə keçirmək daha yaxşıdır.
werf 1.1-ə keçərkən köhnə layihələri yeni etiketləmə sxeminə keçirmək məsləhətdir, lakin köhnə etiket və ya filial hələ də dəstəklənir.

Məzmun əsaslı etiketləmə məqalədə əhatə olunan bütün problemləri həll edir:

Boş Git öhdəliyinə Docker teq adı müqaviməti.
Docker teq adının Git-ə davamlılığı təsvirə aidiyyatı olmayan faylları dəyişdirən öhdəlikləri yerinə yetirir.
Git filialları üçün köhnə Git öhdəliyi üçün konstruksiyaları yenidən işə salarkən təsvirin cari versiyasının əsaslı təmiri probleminə səbəb olmur.

İstifadə edin! Bizi ziyarət etməyi unutmayın Githubproblem yaratmaq və ya mövcud olanı tapmaq, bir artı əlavə etmək, PR yaratmaq və ya sadəcə olaraq layihənin inkişafını izləmək.

PS

Bloqumuzda da oxuyun:

Mənbə: www.habr.com

Werf kollektorunda məzmun əsaslı etiketləmə: niyə və necə işləyir?