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

верф је наш опен соурце ГитОпс ЦЛИ услужни програм за прављење и испоруку апликација у Кубернетес. ИН издање в1.1 у колектору слика уведена је нова функција: означавање слика по садржају или означавање засновано на садржају. До сада је типична шема означавања у верф-у укључивала означавање Доцкер слика помоћу Гит ознаке, Гит гране или Гит урезивања. Али све ове шеме имају недостатке који су потпуно решени новом стратегијом означавања. Детаљи о томе и зашто је тако добар су испод.

Увођење скупа микросервиса из једног Гит спремишта

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

Постоје ситуације када су услуге заиста независне и нису повезане са једном апликацијом. У овом случају, они ће се налазити у засебним пројектима и њихово објављивање ће се вршити кроз засебне ЦИ/ЦД процесе у сваком од пројеката.

Међутим, у стварности, програмери често деле једну апликацију на неколико микросервиса, али креирање посебног спремишта и пројекта за сваку... је очигледно претерано. О овој ситуацији ће се даље расправљати: неколико таквих микросервиса се налази у једном спремишту пројекта и издања се дешавају кроз један процес у ЦИ/ЦД-у.

Означавање по Гит грани и Гит ознаци

Рецимо да се користи најчешћа стратегија означавања - ознака-или-грана. За гране Гит-а, слике су означене именом гране, за једну по једну грану постоји само једна објављена слика по имену те гране. За Гит ознаке, слике су означене према имену ознаке.

Када се креира нова Гит ознака — на пример, када се објави нова верзија — биће креирана нова Доцкер ознака за све слике пројекта у Доцкер регистру:

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

Ова нова имена слика се прослеђују кроз Хелм шаблоне у Кубернетес конфигурацију. Приликом покретања распоређивања са командом werf deploy поље се ажурира image у манифесту ресурса Кубернетес и поновном покретању одговарајућих ресурса због промењеног назива слике.

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

Као резултат тога, са тренутном шемом означавања потребно је оградити неколико засебних Гит спремишта и настаје проблем организовања увођења ових неколико спремишта. Генерално, таква шема се испоставља преоптерећеном и сложеном. Боље је комбиновати многе услуге у једно спремиште и креирати Доцкер ознаке тако да нема непотребних поновних покретања.

Означавање помоћу Гит урезивања

верф такође има стратегију означавања повезану са Гит урезивањем.

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

Међутим, означавање Гит урезивањем има исте недостатке као означавање Гит гранама или Гит ознакама:

Могло би се направити празна урезивање која не мења ниједну датотеку, али ће Доцкер ознака слике бити промењена.
Могло би се направити урезивање спајањем које не мења датотеке, али ће Доцкер ознака слике бити промењена.
Могло би се направити урезивање које мења оне датотеке у Гиту које нису увезене у слику, а Доцкер ознака слике ће бити поново промењена.

Означавање имена Гит гране не одражава верзију слике

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

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

Ако у тренутној шеми корисник почне да поново прави старо урезивање повезано са одређеном граном, онда ће верф поново написати слику користећи одговарајућу Доцкер ознаку са новоизграђеном верзијом слике за старо урезивање. Примене које од сада користе ову ознаку ризикују да повуку другу верзију слике приликом поновног покретања подова, због чега ће наша апликација изгубити везу са ЦИ системом и постати десинхронизована.

Поред тога, са узастопним гурањем у једну грану са кратким временским периодом између њих, старо урезивање може бити преведено касније од новије: стара верзија слике ће преписати нову користећи Гит ознаку гране. Такви проблеми се могу решити помоћу ЦИ/ЦД система (на пример, у ГитЛаб ЦИ цевовод овог последњег се покреће за серију урезивања). Међутим, не подржавају сви системи ово и мора постојати поузданији начин да се спречи такав фундаментални проблем.

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

Дакле, шта је означавање засновано на садржају – означавање слика по садржају.

За креирање Доцкер ознака не користе се Гит примитиви (Гит грана, Гит ознака...), већ контролни збир повезан са:

садржај слике. Ознака ИД слике одражава њен садржај. Када правите нову верзију, овај идентификатор се неће променити ако се датотеке на слици нису промениле;
историја стварања ове слике у Гиту. Слике повезане са различитим Гит гранама и различитом историјом изградње преко верф-а ће имати различите ИД ознаке.

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

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

Коначна слика, која се састоји од ових фаза, означена је такозваним потписом скупа ових фаза - фазе потпис, - који је генерализујући за све фазе слике.

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

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

Отпоран на празна Гит урезивања.
Отпоран на Гит урезивање које мења датотеке које нису релевантне за слику.
Не доводи до проблема ремонта тренутне верзије слике приликом поновног покретања буилд-а за старе Гит урезивање гране.

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

Како омогућити и користити у верф-у

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

У ЦИ систему, стратегија означавања је одређена командом werf ci-env. Раније је за њега дефинисан параметар werf ci-env --tagging-strategy=tag-or-branch. Сада, ако наведете werf ci-env --tagging-strategy=stages-signature или не наведите ову опцију, верф ће подразумевано користити стратегију означавања 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 Нема потребе да мењате било шта у шаблонима Хелм: ове функције ће аутоматски генерисати тачна имена слика.

Пример конфигурације у ЦИ систему:

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).
Ако сте раније користили опције означавања за Гит урезивање (WERF_TAG_GIT_COMMIT или опција werf publish --tag-git-commit COMMIT), а затим обавезно пређите на стратегију означавања етапе-потпис.
Боље је одмах пребацити нове пројекте на нову шему означавања.
Приликом преласка на верф 1.1, препоручљиво је пребацити старе пројекте на нову шему означавања, али стару ознака-или-грана је још увек подржан.

Означавање засновано на садржају решава све проблеме обрађене у чланку:

Отпор имена Доцкер ознаке на празна Гит урезивања.
Отпорност имена Доцкер ознаке на Гит урезује те промене у датотеке које нису релевантне за слику.
Не доводи до проблема ремонта тренутне верзије слике приликом поновног покретања буилд-а за старе Гит урезивање за Гит гране.

Искористи то! И не заборавите да нас посетите на ГитХубда бисте креирали проблем или пронашли постојећи, додајте плус, креирајте ПР или једноставно посматрајте развој пројекта.

ПС

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

Извор: ввв.хабр.цом

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