🥇Означување засновано на содржина во колекторот на верф: зошто и како функционира?

верф е нашата алатка со отворен код GitOps CLI за градење и доставување апликации до Kubernetes. ВО ослободување v1.1 беше воведена нова функција во собирачот на слики: означување на слики по содржина или означување базирано на содржина. Досега, типичната шема за означување во werf вклучуваше означување на сликите на Docker со Git tag, Git branch или Git commit. Но, сите овие шеми имаат недостатоци кои се целосно решени со новата стратегија за означување. Детали за тоа и зошто е толку добар се под рез.

Распоредување на збир на микроуслуги од едно складиште на Git

Често се случува ситуација кога апликацијата е поделена на многу повеќе или помалку независни услуги. Издавањата на овие услуги може да се појават независно: една или повеќе услуги може да се пуштат истовремено, додека останатите мора да продолжат да работат без никакви промени. Но, од гледна точка на складирање на код и управување со проекти, попогодно е да се чуваат такви апликациски услуги во едно складиште.

Постојат ситуации кога услугите се навистина независни и не се поврзани со една апликација. Во овој случај, тие ќе бидат лоцирани во посебни проекти и нивното ослободување ќе се врши преку посебни CI/CD процеси во секој од проектите.

Меѓутоа, во реалноста, програмерите често ја делат една апликација на неколку микроуслуги, но создавањето посебно складиште и проект за секој... е јасно претерување. Токму оваа ситуација ќе се дискутира понатаму: неколку такви микроуслуги се наоѓаат во едно складиште на проекти и објавувањата се случуваат преку еден процес во CI/CD.

Означување по Git гранка и Git ознака

Да речеме дека се користи најчестата стратегија за означување - ознака-или-гранка. За гранките на Git, сликите се означени со името на гранката, за една гранка во исто време има само една објавена слика со името на таа гранка. За Git ознаките, сликите се означени според името на ознаката.

Кога ќе се создаде нова ознака Git - на пример, кога е објавена нова верзија - ќе се создаде нова ознака Docker за сите слики на проектот во 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

Овие нови имиња на слики се пренесуваат преку шаблоните на Helm до конфигурацијата на Kubernetes. При започнување на распоредувањето со командата werf deploy полето се ажурира image во Kubernetes ресурсот се манифестира и рестартирање на соодветните ресурси поради променетото име на сликата.

проблем: во случај кога, всушност, содржината на сликата не е променета од претходното објавување (Git tag), туку само нејзината ознака Docker, тоа се случува вишок рестартирање на оваа апликација и, соодветно, можно е одредено време на застој. Иако немаше вистинска причина да се изврши овој рестарт.

Како резултат на тоа, со тековната шема за означување потребно е да се оградат неколку одделни складишта на Git и се јавува проблемот со организирање на ширењето на овие неколку складишта. Во принцип, таквата шема се покажува како преоптоварена и сложена. Подобро е да се комбинираат многу услуги во едно складиште и да се создадат ознаки на Docker за да нема непотребни рестартирање.

Означување од страна на Git commit

werf исто така има стратегија за означување поврзана со Git commits.

Git-commit е идентификатор за содржината на складиштето Git и зависи од историјата на уредување на датотеките во складиштето Git, па се чини логично да се користи за означување на слики во Docker Registry.

Сепак, означувањето со Git commit ги има истите недостатоци како означувањето со Git гранки или Git ознаки:

Може да се создаде празна заложба што не менува ниедна датотека, но ознаката Docker на сликата ќе се смени.
Може да се создаде обврзување за спојување што не ги менува датотеките, но ознаката Docker на сликата ќе се смени.
Може да се направи заложба што ги менува оние датотеки во Git што не се увезени во сликата, а ознаката Docker на сликата повторно ќе се смени.

Означувањето на името на филијалата на Git не ја одразува верзијата на сликата

Постои уште еден проблем поврзан со стратегијата за означување на Git гранките.

Означувањето по име на гранка функционира се додека задолжувањата на таа гранка се собираат последователно по хронолошки редослед.

Ако во тековната шема корисникот почне да обновува стар commit поврзан со одредена гранка, тогаш werf ќе ја преработи сликата користејќи ја соодветната ознака Docker со новоизградена верзија на сликата за стариот commit. Распоредувањата што ја користат оваа ознака од сега па натаму имаат ризик да повлечат друга верзија на сликата при рестартирање на подлоги, како резултат на што нашата апликација ќе ја изгуби врската со системот CI и ќе се десинхронизира.

Дополнително, со последователни туркања во една гранка со краток временски период помеѓу нив, старата заложба може да се состави подоцна од поновата: старата верзија на сликата ќе ја презапише новата со помош на ознаката за гранка Git. Ваквите проблеми може да се решат со CI/CD систем (на пример, во GitLab CI гасоводот на вториот е лансиран за серија обврски). Сепак, не сите системи го поддржуваат ова и мора да постои посигурен начин да се спречи таков фундаментален проблем.

Што е означување базирано на содржина?

Значи, што е означување базирано на содржина - означување на слики по содржина.

За да се создадат ознаки на Docker, не се користат примитивите на Git (гранка на Git, ознака Git...), туку контролна сума поврзана со:

содржината на сликата. Ознаката за ID на сликата ја рефлектира нејзината содржина. При изградба на нова верзија, овој идентификатор нема да се промени ако датотеките на сликата не се променети;
историја на создавање на оваа слика во Git. Сликите поврзани со различни Git гранки и различна историја на градење преку werf ќе имаат различни ID ознаки.

Таков идентификациски таг е т.н потпис на сцената на сликата.

Секоја слика се состои од збир на фази: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch итн. Секоја фаза има идентификатор што ја рефлектира неговата содржина − сценски потпис (сценски потпис).

Конечната слика, која се состои од овие фази, е означена со т.н. потпис на множеството од овие фази - фази потпис, - што е генерализирање за сите фази на сликата.

За секоја слика од конфигурацијата werf.yaml во општиот случај, ќе има свој потпис и, соодветно, ознака на Docker.

Сценскиот потпис ги решава сите овие проблеми:

Отпорен на празни Git обврзници.
Resistant to Git обврзува да менува датотеки што не се релевантни за сликата.
Не доведува до проблем со ремонт на тековната верзија на сликата при рестартирање на градбите за стари Git обврзувања на гранка.

Ова сега е препорачаната стратегија за означување и е стандардна во werf за сите CI системи.

Како да се овозможи и користи во werf

Командата сега има соодветна опција werf publish: --tag-by-stages-signature=true|false

Во системот CI, стратегијата за означување е одредена со командата werf ci-env. Претходно, параметарот беше дефиниран за него werf ci-env --tagging-strategy=tag-or-branch. Сега, ако наведете werf ci-env --tagging-strategy=stages-signature или не ја одредувајте оваа опција, werf стандардно ќе ја користи стратегијата за означување stages-signature. Тим werf ci-env автоматски ќе ги постави потребните знаменца за командата werf build-and-publish (Или werf publish), така што не треба да се специфицираат дополнителни опции за овие команди.

На пример, командата:

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

...може да ги создаде следните слики:

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

Тука 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d е потпис на фазите на сликата backendИ f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - потпис на фазите на сликата frontend.

Кога користите специјални функции werf_container_image и werf_container_env Нема потреба да менувате ништо во шаблоните на Helm: овие функции автоматски ќе ги генерираат точните имиња на сликите.

Пример за конфигурација во CI систем:

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

Повеќе информации за конфигурацијата се достапни во документацијата:

Во вкупен

Нова опција werf publish --tag-by-stages-signature=true|false.
Нова вредност на опцијата werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ако не е одредено, стандардното ќе биде stages-signature).
Ако претходно сте ги користеле опциите за означување за Git commits (WERF_TAG_GIT_COMMIT или опција werf publish --tag-git-commit COMMIT), тогаш не заборавајте да се префрлите на стратегијата за означување фази-потпис.
Подобро е веднаш да се префрлат новите проекти на новата шема за означување.
Кога се префрлате на werf 1.1, препорачливо е старите проекти да се префрлат на новата шема за означување, но старата ознака-или-гранка сè уште е поддржан.

Означувањето засновано на содржина ги решава сите проблеми опфатени во статијата:

Отпорност на името на докерската ознака на празни Git обврзници.
Отпорот на името на ознаката Docker на Git обврзува дека ги менува датотеките што не се важни за сликата.
Не доведува до проблем со ремонт на тековната верзија на сликата при рестартирање на градбите за старите обврзувања на Git за гранките на Git.

Користи го! И не заборавајте да не посетите на GitHubда се создаде проблем или да се најде постоечко, да се даде плус, да се создаде ПР или едноставно да се следи развојот на проектот.

PS

Прочитајте и на нашиот блог:

Извор: www.habr.com

Означување засновано на содржина во колекторот werf: зошто и како функционира?