մեր բաց կոդով GitOps CLI կոմունալն է՝ հավելվածներ ստեղծելու և Kubernetes-ին առաքելու համար: IN Պատկերների հավաքագրիչում ներդրվել է նոր գործառույթ՝ պատկերների պիտակավորում ըստ բովանդակության կամ բովանդակության վրա հիմնված հատկորոշում. Մինչ այժմ, werf-ի բնորոշ հատկորոշման սխեման ներառում էր Docker պատկերների պիտակավորումը Git tag-ով, Git ճյուղով կամ Git commit-ով: Բայց այս բոլոր սխեմաներն ունեն թերություններ, որոնք ամբողջությամբ լուծվում են պիտակավորման նոր ռազմավարությամբ: Մանրամասներն այն մասին, թե ինչու է այն այդքան լավը, կտրվածքի տակ են:
Մի Git-ի մեկ պահոցից միկրոծառայությունների փաթեթի ստեղծում
Հաճախ իրավիճակ է առաջանում, երբ հավելվածը բաժանվում է շատ թե քիչ անկախ ծառայությունների: Այս ծառայությունների թողարկումը կարող է տեղի ունենալ ինքնուրույն. մեկ կամ մի քանի ծառայություններ կարող են միաժամանակ թողարկվել, մինչդեռ մնացածը պետք է շարունակեն աշխատել առանց որևէ փոփոխության: Բայց կոդերի պահպանման և նախագծերի կառավարման տեսանկյունից ավելի հարմար է նման հավելվածների ծառայությունները պահել մեկ պահոցում։
Կան իրավիճակներ, երբ ծառայություններն իսկապես անկախ են և կապված չեն մեկ հավելվածի հետ: Այս դեպքում դրանք կտեղակայվեն առանձին նախագծերում և դրանց թողարկումը կիրականացվի նախագծերից յուրաքանչյուրում առանձին CI/CD գործընթացների միջոցով:
Այնուամենայնիվ, իրականում ծրագրավորողները հաճախ մեկ հավելվածը բաժանում են մի քանի միկրոսերվիսների, սակայն յուրաքանչյուրի համար առանձին պահեստ և նախագիծ ստեղծելը ակնհայտ գերակատարում է: Այս իրավիճակն է, որը կքննարկվի հետագա. մի քանի նման միկրոծառայություններ տեղակայված են մեկ նախագծի պահեստում և թողարկումները տեղի են ունենում CI/CD-ում մեկ գործընթացի միջոցով:
Նշում ըստ Git ճյուղի և Git թեգի
Ենթադրենք, որ օգտագործվում է պիտակավորման ամենատարածված ռազմավարությունը. պիտակ կամ ճյուղ. Git մասնաճյուղերի համար պատկերները պիտակվում են մասնաճյուղի անունով, մեկ մասնաճյուղի համար մեկ անգամ կա միայն մեկ հրապարակված պատկեր այդ մասնաճյուղի անունով: Git պիտակների համար պատկերները հատկորոշվում են ըստ թեգի անվան:
Երբ ստեղծվում է նոր Git թեգ, օրինակ, երբ թողարկվում է նոր տարբերակ, Docker Registry-ում բոլոր նախագծի պատկերների համար կստեղծվի նոր 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 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-ին փոխանցելիս խորհուրդ է տրվում հին նախագծերը փոխել պիտակավորման նոր սխեմայի, բայց հին պիտակ կամ ճյուղ դեռ աջակցվում է:
Բովանդակության վրա հիմնված հատկորոշումը լուծում է հոդվածում ընդգրկված բոլոր խնդիրները.
- Docker պիտակի անվան դիմադրություն դատարկ Git պարտավորություններին:
- Docker պիտակի անվան դիմացկունությունը Git-ին պարտավորեցնում է փոխել պատկերի հետ կապ չունեցող ֆայլերը:
- Չի հանգեցնում պատկերի ընթացիկ տարբերակի հիմնանորոգման խնդրին Git-ի ճյուղերի համար հին Git commit-ների համար կառուցումները վերագործարկելու ժամանակ:
Օգտագործիր դա! Եվ մի մոռացեք այցելել մեզ ստեղծել խնդիր կամ գտնել գոյություն ունեցողը, ավելացնել պլյուս, ստեղծել PR կամ պարզապես հետևել նախագծի զարգացմանը:
PS
Կարդացեք նաև մեր բլոգում.
- «»
- «»
- «";
- Werf-ում նորարարությունների մասին մի շարք նշումներ.
- «";
- «";
- «";
- «.
Source: www.habr.com