is ús iepen boarne GitOps CLI-hulpprogramma foar it bouwen en leverjen fan applikaasjes nei Kubernetes. YN in nije funksje waard yntrodusearre yn de ôfbylding samler: tagging ôfbyldings troch ynhâld of ynhâld-basearre tagging. Oant no ta wie it typyske taggingskema yn werf it tagjen fan Docker-ôfbyldings mei Git tag, Git branch of Git commit. Mar al dizze regelingen hawwe neidielen dy't folslein oplost wurde troch de nije taggingstrategy. Details deroer en wêrom't it sa goed is binne ûnder de besuniging.
In set fan mikrotsjinsten útrolje fan ien Git-repository
In situaasje komt faak foar as in applikaasje ferdield is yn in protte min of mear selsstannige tsjinsten. Utjeften fan dizze tsjinsten kinne selsstannich foarkomme: ien of mear tsjinsten kinne tagelyk frijlitten wurde, wylst de rest sûnder feroaringen fierder wurkje moat. Mar út it eachpunt fan koade-opslach en projektbehear is it handiger om sokke applikaasjetsjinsten yn ien repository te hâlden.
D'r binne situaasjes as tsjinsten wirklik ûnôfhinklik binne en net ferbûn binne mei ien applikaasje. Yn dit gefal sille se yn aparte projekten lizze en har frijlitting sil wurde útfierd troch aparte CI / CD-prosessen yn elk fan 'e projekten.
Yn 'e realiteit splitten ûntwikkelders lykwols faak in inkele applikaasje yn ferskate mikrotsjinsten, mar it meitsjen fan in aparte repository en projekt foar elk ... is in dúdlike overkill. It is dizze situaasje dy't fierder sil wurde besprutsen: ferskate sokke mikrotsjinsten lizze yn ien projektopslach en releases komme troch ien proses yn CI / CD.
Tagging troch Git branch en Git tag
Litte wy sizze dat de meast foarkommende taggingstrategy wurdt brûkt - tag-of-tûke. Foar Git-tûken wurde ôfbyldings tagged mei de namme fan 'e branch, foar ien branch tagelyk is d'r mar ien publisearre ôfbylding mei de namme fan dy branch. Foar Git-tags wurde ôfbyldings tagged neffens de tagnamme.
As in nije Git-tag wurdt oanmakke - bygelyks as in nije ferzje wurdt frijjûn - sil in nije Docker-tag makke wurde foar alle projektôfbyldings yn 'e 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
Dizze nije ôfbyldingsnammen wurde troch Helm-sjabloanen trochjûn nei de Kubernetes-konfiguraasje. By it starten fan de ynset mei it kommando werf deploy fjild wurdt bywurke image yn Kubernetes boarne manifestearret en opnij starte de oerienkommende boarnen fanwege de feroare ôfbylding namme.
probleem: yn it gefal as, yn feite, de ynhâld fan 'e ôfbylding net feroare is sûnt de foarige útrol (Git-tag), mar allinich de Docker-tag, dit bart ekstra dizze applikaasje opnij starte en dêrtroch is wat downtime mooglik. Hoewol d'r gjin echte reden wie om dizze trochstart út te fieren.
As gefolch, mei it hjoeddeistige taggingskema is it nedich om ferskate aparte Git-repositories te fence en it probleem ûntstiet fan it organisearjen fan de útrol fan dizze ferskate repositories. Yn it algemien, sa'n skema blykt te wêzen oerladen en kompleks. It is better om in protte tsjinsten te kombinearjen yn ien repository en Docker-tags te meitsjen sadat d'r gjin ûnnedige opstarten binne.
Tagging troch Git commit
werf hat ek in taggingstrategy ferbûn mei Git-commits.
Git-commit is in identifier foar de ynhâld fan in Git-repository en hinget ôf fan 'e bewurkingsskiednis fan bestannen yn' e Git-repository, dus it liket logysk om it te brûken foar it tagjen fan ôfbyldings yn 'e Docker Registry.
Tagging troch Git commit hat lykwols deselde neidielen as tagging troch Git-tûken of Git-tags:
- In lege commit koe wurde makke dy't gjin bestannen feroaret, mar de Docker-tag fan 'e ôfbylding sil feroare wurde.
- In gearfoeging kin makke wurde dy't de bestannen net feroaret, mar de Docker-tag fan 'e ôfbylding sil wizige wurde.
- In commit koe wurde makke dy't dizze bestannen yn Git feroaret dy't net yn 'e ôfbylding binne ymporteare, en de Docker-tag fan' e ôfbylding sil opnij wizige wurde.
Tagging Git branch namme wjerspegelet gjin ôfbylding ferzje
D'r is in oar probleem ferbûn mei de taggingstrategy foar Git-tûken.
Tagging op branch namme wurket salang't de commits op dy branch wurde sammele sequentially yn gronologyske folchoarder.
As yn it hjoeddeiske skema de brûker begjint mei it werbouwen fan in âlde commit dy't ferbûn is mei in bepaalde branch, dan sil werf de ôfbylding oerskriuwe mei de korrespondearjende Docker-tag mei in nij boud ferzje fan de ôfbylding foar de âlde commit. Ynset dy't dizze tag fan no ôf brûke, rinne it risiko om in oare ferzje fan 'e ôfbylding te lûken by it opnij starte fan pods, wêrtroch't ús applikaasje de ferbining mei it CI-systeem ferliest en desyngronisearre wurdt.
Derneist, mei opienfolgjende triuwkes yn ien tûke mei in koarte perioade tusken har, kin de âlde commit letter kompilearre wurde as de nijere: de âlde ferzje fan 'e ôfbylding sil de nije oerskriuwe mei de Git branch tag. Sokke problemen kinne wurde oplost troch in CI / CD systeem (bygelyks, yn GitLab CI de pipeline fan de lêste wurdt lansearre foar in rige fan commits). Net alle systemen stypje dit lykwols en d'r moat in betrouberere manier wêze om sa'n fûnemintele probleem te foarkommen.
Wat is ynhâld-basearre tagging?
Dus, wat is ynhâld-basearre tagging - tagging fan ôfbyldings troch ynhâld.
Om Docker-tags te meitsjen, binne it gjin Git-primitiven (Git branch, Git tag ...) dy't wurde brûkt, mar in kontrôlesum ferbûn mei:
- ynhâld fan it byld. De ôfbylding ID-tag wjerspegelet de ynhâld. By it bouwen fan in nije ferzje sil dizze identifier net feroarje as de bestannen yn 'e ôfbylding net feroare binne;
- skiednis fan it meitsjen fan dizze ôfbylding yn Git. Ofbyldings ferbûn mei ferskate Git-tûken en ferskate bouskiednis fia werf sille ferskate ID-tags hawwe.
Sa'n identifier tag is de saneamde image poadium hantekening.
Elke ôfbylding bestiet út in set fan stadia: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch ensfh. Elke poadium hat in identifier dy't de ynhâld reflektearret - poadium hantekening (poadiumhantekening).
It definitive byld, besteande út dizze stadia, is tagged mei de saneamde hantekening fan 'e set fan dizze stadia - stadia hântekening, - dat is generalisearjend foar alle stadia fan it byld.
Foar elke ôfbylding út 'e konfiguraasje werf.yaml yn it algemiene gefal sil d'r in eigen hantekening wêze en, sadwaande, in Docker-tag.
De poadiumhantekening lost al dizze problemen op:
- Resistint foar lege Git commits.
- Resistant to Git commits dy't bestannen feroarje dy't net relevant binne foar de ôfbylding.
- Liedt net ta it probleem fan it oersjen fan 'e hjoeddeistige ferzje fan' e ôfbylding by it opnij begjinnen fan builds foar âlde Git-commits fan in branch.
Dit is no de oanrikkemandearre taggingstrategy en is de standert yn werf foar alle CI-systemen.
Hoe ynskeakelje en brûke yn werf
It kommando hat no in oerienkommende opsje werf publish: --tag-by-stages-signature=true|false
Yn in CI-systeem wurdt de taggingstrategy oantsjutte troch it kommando werf ci-env. Earder waard de parameter dêrfoar definiearre werf ci-env --tagging-strategy=tag-or-branch. No, as jo spesifisearje werf ci-env --tagging-strategy=stages-signature of spesifisearje dizze opsje net, werf sil standert de taggingstrategy brûke stages-signature. Ploech werf ci-env sil automatysk de nedige flaggen foar it kommando ynstelle werf build-and-publish (of werf publish), sadat gjin ekstra opsjes moatte wurde opjûn foar dizze kommando's.
Bygelyks, it kommando:
werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature... kin de folgjende ôfbyldings oanmeitsje:
-
registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d -
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6
it is 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d is in hantekening fan de stadia fan it byld backenden f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - hantekening fan byldstadia frontend.
By it brûken fan spesjale funksjes werf_container_image и werf_container_env D'r is net nedich om neat te feroarjen yn 'e Helm-sjabloanen: dizze funksjes sille automatysk de juste ôfbyldingsnammen generearje.
Foarbyld konfiguraasje yn in CI systeem:
type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deployMear ynformaasje oer konfiguraasje is beskikber yn 'e dokumintaasje:
- ;
- ;
- .
Totaal
- Nije opsje
werf publish --tag-by-stages-signature=true|false. - Nije opsje wearde
werf ci-env --tagging-strategy=stages-signature|tag-or-branch(as net oantsjutte, sil de standert wêzestages-signature). - As jo earder de tagging-opsjes brûkten foar Git-commits (
WERF_TAG_GIT_COMMITof opsjewerf publish --tag-git-commit COMMIT), wês dan wis om te wikseljen nei de taggingstrategy stadia-hântekening. - It is better om nije projekten daliks te wikseljen nei it nije taggingskema.
- By oerstap nei werf 1.1 is it oan te rieden om âlde projekten oer te setten nei it nije taggingskema, mar de âlde tag-of-tûke wurdt noch altyd stipe.
Ynhâld-basearre tagging lost alle problemen op yn it artikel:
- Docker tag namme ferset tsjin lege Git commits.
- Wjerstân fan 'e Docker-tagnamme nei Git commits dy't bestannen feroarje dy't irrelevant binne foar de ôfbylding.
- Liet net ta it probleem fan it oersjen fan 'e hjoeddeistige ferzje fan' e ôfbylding by it opnij begjinnen fan builds foar âlde Git-commits foar Git-tûken.
Brûk it! En ferjit net om ús te besykjen by om in probleem te meitsjen of in besteande te finen, in plus tafoegje, in PR meitsje of gewoan de ûntwikkeling fan it projekt besjen.
PS
Lês ek op ús blog:
- «»
- «»
- «";
- In rige notysjes oer ynnovaasjes yn werf:
- «";
- «";
- «";
- «".
Boarne: www.habr.com