Тагване, базирано на съдържание в werf builder: защо и как работи?

werf е нашата помощна програма GitOps CLI с отворен код за изграждане и доставяне на приложения до Kubernetes. IN версия v1.1 беше въведена нова функция в колектора на изображения: маркиране на изображения по съдържание или маркиране, базирано на съдържание. Досега типичната схема за маркиране в werf включваше маркиране на Docker изображения чрез Git tag, Git клон или Git commit. Но всички тези схеми имат недостатъци, които са напълно разрешени от новата стратегия за маркиране. Подробности за него и защо е толкова добър са под изрезката.

Разгръщане на набор от микроуслуги от едно Git хранилище

Често възниква ситуация, когато едно приложение е разделено на много повече или по-малко независими услуги. Изданията на тези услуги могат да се извършват независимо: една или повече услуги могат да бъдат пуснати наведнъж, докато останалите трябва да продължат да работят без никакви промени. Но от гледна точка на съхранение на код и управление на проекти е по-удобно да се съхраняват такива услуги за приложения в едно хранилище.

Има ситуации, когато услугите са наистина независими и не са свързани с едно приложение. В този случай те ще бъдат разположени в отделни проекти и освобождаването им ще се извършва чрез отделни CI/CD процеси във всеки от проектите.

В действителност обаче разработчиците често разделят едно приложение на няколко микроуслуги, но създаването на отделно хранилище и проект за всяка... е явно прекаляване. Именно тази ситуация ще бъде обсъдена по-нататък: няколко такива микроуслуги се намират в едно хранилище на проекта и изданията се извършват чрез един процес в CI/CD.

Маркиране чрез Git клон и Git таг

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

Когато се създаде нов Git таг – например, когато се пусне нова версия – ще бъде създаден нов Docker таг за всички изображения на проекта в регистъра на 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

Тези нови имена на изображения се предават през Helm шаблони към конфигурацията на Kubernetes. При стартиране на разгръщането с командата werf deploy полето се актуализира image в манифести на ресурс на Kubernetes и рестартиране на съответните ресурси поради промененото име на изображението.

проблем: в случай, че всъщност съдържанието на изображението не се е променило от предишното внедряване (Git таг), а само неговия Docker таг, това се случва екстра рестартиране на това приложение и съответно е възможен известен престой. Въпреки че нямаше реална причина да се извърши това рестартиране.

В резултат на това с настоящата схема за маркиране е необходимо да се оградят няколко отделни Git хранилища и възниква проблемът с организирането на внедряването на тези няколко хранилища. Като цяло подобна схема се оказва претоварена и сложна. По-добре е да комбинирате много услуги в едно хранилище и да създадете Docker тагове, така че да няма ненужни рестартирания.

Маркиране чрез Git commit

werf също има стратегия за маркиране, свързана с Git ангажименти.

Git-commit е идентификатор за съдържанието на Git хранилище и зависи от хронологията на редактирането на файлове в Git хранилището, така че изглежда логично да се използва за маркиране на изображения в регистъра на Docker.

Въпреки това, маркирането чрез Git commit има същите недостатъци като маркирането чрез Git клонове или Git тагове:

• Може да се създаде празен комит, който не променя никакви файлове, но Docker тагът на изображението ще бъде променен.
• Може да се създаде ангажимент за сливане, който не променя файловете, но Docker тагът на изображението ще бъде променен.
• Може да се направи ангажимент, който променя онези файлове в Git, които не са импортирани в изображението, и маркерът Docker на изображението ще бъде променен отново.

Маркирането на име на клон на Git не отразява версията на изображението

Има друг проблем, свързан със стратегията за маркиране за Git клонове.

Маркирането по име на клон работи, докато ангажиментите на този клон се събират последователно в хронологичен ред.

Ако в текущата схема потребителят започне да изгражда отново стар комит, свързан с определен клон, тогава werf ще пренапише изображението, използвайки съответния Docker таг с новоизградена версия на изображението за стария комит. Внедряванията, използващи този маркер от сега нататък, рискуват да изтеглят различна версия на изображението при рестартиране на pods, в резултат на което нашето приложение ще загуби връзка с CI системата и ще се десинхронизира.

В допълнение, с последователни натискания в един клон с кратък период от време между тях, старият комит може да бъде компилиран по-късно от по-новия: старата версия на изображението ще презапише новата с помощта на маркера за клон Git. Такива проблеми могат да бъдат решени чрез CI/CD система (например в GitLab CI тръбопроводът на последната се стартира за поредица от ангажименти). Въпреки това, не всички системи поддържат това и трябва да има по-надежден начин за предотвратяване на такъв основен проблем.

Какво е маркиране, базирано на съдържание?

И така, какво е маркиране, базирано на съдържанието – маркиране на изображения по съдържание.

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

• съдържанието на изображението. Идентификационният етикет на изображението отразява неговото съдържание. Когато създавате нова версия, този идентификатор няма да се промени, ако файловете в изображението не са променени;
• история на създаването на това изображение в Git. Изображенията, свързани с различни клонове на Git и различна история на изграждане чрез werf, ще имат различни ID тагове.

Такъв идентификатор идентификатор е т.нар сценичен подпис на изображението.

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

Крайното изображение, състоящо се от тези етапи, е маркирано с така наречения подпис на набора от тези етапи - етапи подпис, - което е обобщаващо за всички етапи на изображението.

За всяко изображение от конфигурацията werf.yaml в общия случай ще има собствен подпис и съответно Docker таг.

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

• Устойчив на празни Git ангажименти.
• Устойчив на 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 (Or 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

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

• Директория → Публикация (публикуване);
• Работа с CI/CD → Обща информация → етапи-сигнатура;
• Интегриране с GitLab CI/CD → .gitlab-ci.yml.

Общо

• Нова опция werf publish --tag-by-stages-signature=true|false.
• Нова стойност на опцията werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ако не е посочено, по подразбиране ще бъде stages-signature).
• Ако преди сте използвали опциите за маркиране за Git ангажименти (WERF_TAG_GIT_COMMIT или опция werf publish --tag-git-commit COMMIT), тогава не забравяйте да преминете към стратегията за маркиране етапи-подпис.
• По-добре е незабавно да превключите новите проекти към новата схема за маркиране.
• При прехвърляне към werf 1.1 е препоръчително да превключите старите проекти към новата схема за маркиране, но старата етикет или клон все още се поддържа.

Маркирането, базирано на съдържание, решава всички проблеми, разгледани в статията:

• Устойчивост на името на етикета на Docker срещу празни ангажименти на Git.
• Устойчивост на името на маркера на Docker спрямо Git ангажименти, които променят файловете без значение за изображението.
• Не води до проблема с преразглеждане на текущата версия на изображението при рестартиране на компилации за стари Git ангажименти за Git клонове.

Използваи го! И не забравяйте да ни посетите на GitHubда създадете проблем или да намерите съществуващ, да дадете плюс, да създадете PR или просто да наблюдавате развитието на проекта.

PS

Прочетете също в нашия блог:

• «Версия на werf 1.1: подобрения в създателя днес и планове за бъдещето»
• «Представяне на werf 1.0 stable: какво общо има GitOps с него, статус и планове»
• «werf - нашият инструмент за CI / CD в Kubernetes (общ преглед и видео отчет)»;
• Поредица от бележки за иновациите в werf:
  • «3-посочно сливане към werf: внедряване в Kubernetes с Helm „на стероиди“»;
  • «Използване на werf за внедряване на сложни диаграми на Helm»;
  • «Поддръжка за monorepo и multirepo в werf и какво общо има Docker Registry с това»;
  • «Вече можете да създавате Docker изображения в werf, като използвате обикновен Dockerfile".

Източник: www.habr.com