🥇Werf коллекторындағы мазмұнға негізделген тегтеу: ол неге және қалай жұмыс істейді?

верф бұл Kubernetes қолданбаларын құруға және жеткізуге арналған ашық бастапқы GitOps CLI утилитасы. IN v1.1 шығарылымы Суреттер коллекторында жаңа мүмкіндік енгізілді: суреттерді мазмұны бойынша тегтеу немесе мазмұнға негізделген тегтеу. Осы уақытқа дейін werf-тегі әдеттегі тегтеу схемасы Docker кескіндерін Git тегі, 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 тегін пайдаланып кескінді қайта жазады. Енді осы тегті қолданатын орналастырулар подкасттарды қайта іске қосқан кезде кескіннің басқа нұсқасын тартып алу қаупін тудырады, нәтижесінде біздің қолданба 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 тапсырмалары үшін құрастыруды қайта іске қосу кезінде кескіннің ағымдағы нұсқасын күрделі жөндеу мәселесіне әкелмейді.

Бұл енді ұсынылатын тегтеу стратегиясы және барлық CI жүйелері үшін werf ішіндегі әдепкі болып табылады.

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 нұсқасына көшкен кезде ескі жобаларды жаңа тегтеу схемасына ауыстырған жөн, бірақ ескі тег-немесе-тармақ әлі де қолдау көрсетеді.

Мазмұнға негізделген тегтеу мақалада қарастырылған барлық мәселелерді шешеді:

Docker тег атауының бос Git тапсырмаларына қарсылығы.
Docker тег атауының Git-ке төзімділігі кескінге қатысы жоқ файлдарды өзгертеді.
Git филиалдары үшін ескі Git келісімдері үшін құрастыруды қайта іске қосу кезінде кескіннің ағымдағы нұсқасын күрделі жөндеу мәселесіне әкелмейді.

Оны қолданыңыз! Бізге келуді ұмытпаңыз GitHubмәселе жасау немесе барын табу, плюс беру, PR жасау немесе жай ғана жобаның дамуын қарау.

PS

Біздің блогта да оқыңыз:

Ақпарат көзі: www.habr.com

werf құрастырушысында мазмұнға негізделген тегтеу: ол неге және қалай жұмыс істейді?