մեր բաց կոդով GitOps CLI կոմունալն է՝ հավելվածներ ստեղծելու և Kubernetes-ին առաքելու համար: Ինչպես խոստացել էի, նշանավորվեց werf-ին նոր հնարավորություններ ավելացնելու և ավանդական մոտեցումների վերանայման սկիզբը: Այժմ մենք ուրախ ենք ներկայացնել v1.1 թողարկումը, որը զարգացման մեծ քայլ է և հիմք ապագայի համար կոլեկցիոներ վերֆ. Տարբերակը ներկայումս հասանելի է .
Թողարկման հիմքը բեմական պահեստավորման նոր ճարտարապետությունն է և երկու կոլեկցիոներների աշխատանքի օպտիմալացումը (Stapel-ի և Dockerfile-ի համար): Պահպանման նոր ճարտարապետությունը բացում է միևնույն հյուրընկալողի վրա մի քանի հոսթից և զուգահեռ հավաքների բաշխված հավաքներ իրականացնելու հնարավորությունը:
Աշխատանքի օպտիմիզացումը ներառում է փուլային ստորագրությունների հաշվարկման փուլում անհարկի հաշվարկներից ազատվելը և ֆայլերի ստուգման գումարների հաշվարկման մեխանիզմները ավելի արդյունավետ դարձնելու համար: Այս օպտիմիզացումը նվազեցնում է նախագծերի կառուցման միջին ժամանակը, օգտագործելով werf-ը: Եվ անգործուն կառուցումներ, երբ բոլոր փուլերը կան քեշում փուլեր-պահեստավորում, այժմ իսկապես արագ են: Շատ դեպքերում, կառուցման վերագործարկումը կտևի 1 վայրկյանից պակաս: Սա վերաբերում է նաև թիմերի աշխատանքի գործընթացի փուլերի ստուգման ընթացակարգերին: werf deploy и werf run.
Նաև այս թողարկումում հայտնվեց պատկերները ըստ բովանդակության հատկորոշելու ռազմավարություն. բովանդակության վրա հիմնված հատկորոշում, որն այժմ միացված է լռելյայն և միակն է առաջարկվում:
Եկեք մանրամասն նայենք werf v1.1-ի հիմնական նորամուծություններին և միևնույն ժամանակ պատմենք ապագայի պլանների մասին:
Ի՞նչ է փոխվել werf v1.1-ում:
Փուլերի անվանման նոր ձևաչափ և ալգորիթմ՝ քեշից փուլեր ընտրելու համար
Նոր բեմական անունների ստեղծման կանոն. Այժմ յուրաքանչյուր փուլի կառուցում առաջացնում է եզակի բեմական անուն, որը բաղկացած է 2 մասից՝ ստորագրություն (ինչպես եղել է v1.0-ում) և եզակի ժամանակավոր նույնացուցիչ:
Օրինակ, ամբողջական բեմական պատկերի անունը կարող է այսպիսի տեսք ունենալ.
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
կամ ընդհանրապես.
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Այստեղ:
-
SIGNATUREբեմական ստորագրություն է, որը ներկայացնում է բեմի բովանդակության նույնացուցիչը և կախված է Git-ում կատարված խմբագրումների պատմությունից, որոնք հանգեցրել են այս բովանդակությանը. -
TIMESTAMP_MILLISECերաշխավորված եզակի պատկերի նույնացուցիչ է, որը ստեղծվում է նոր պատկեր ստեղծելու պահին:
Քեշից փուլեր ընտրելու ալգորիթմը հիմնված է Git-ի պարտավորությունների փոխհարաբերությունների ստուգման վրա.
- Վերֆը հաշվարկում է որոշակի փուլի ստորագրությունը։
- В փուլեր-պահեստավորում Տվյալ ստորագրության համար կարող են լինել մի քանի փուլ: Werf-ը ընտրում է բոլոր փուլերը, որոնք համապատասխանում են ստորագրությանը:
- Եթե ընթացիկ փուլը կապված է Git-ի հետ (git-արխիվ, հատուկ փուլ Git patches-ով.
install,beforeSetup,setup; կամ git-latest-patch), այնուհետև werf-ն ընտրում է միայն այն փուլերը, որոնք կապված են commit-ի հետ, որը ներկայիս commit-ի նախահայրն է (որի համար կոչվում է build): - Մնացած հարմար փուլերից ընտրվում է մեկը՝ ստեղծման ամսաթվով ամենահինը:
Git-ի տարբեր ճյուղերի բեմը կարող է ունենալ նույն ստորագրությունը: Բայց werf-ը կկանխի տարբեր ճյուղերի հետ կապված քեշի օգտագործումը այս ճյուղերի միջև, նույնիսկ եթե ստորագրությունները համընկնում են:
.
Նոր ալգորիթմ բեմական պահեստում փուլերի ստեղծման և պահպանման համար
Եթե քեշից փուլեր ընտրելիս werf-ը չի գտնում համապատասխան փուլ, ապա սկսվում է նոր փուլի հավաքման գործընթացը։
Նկատի ունեցեք, որ մի քանի պրոցեսներ (մեկ կամ մի քանի հոստերի վրա) կարող են սկսել նույն փուլի կառուցումը մոտավորապես նույն ժամանակ: Werf-ն օգտագործում է լավատեսական արգելափակման ալգորիթմ փուլեր-պահեստավորում թարմ հավաքված պատկերը պահելու պահին փուլեր-պահեստավորում. Այս կերպ, երբ նոր փուլի կառուցումը պատրաստ է, վերֆ բլոկները փուլեր-պահեստավորում և այնտեղ պահպանում է թարմ հավաքված պատկերը միայն այն դեպքում, եթե այնտեղ այլևս չկա համապատասխան պատկեր (ստորագրությամբ և այլ պարամետրերով - տես քեշից փուլերը ընտրելու նոր ալգորիթմը).
Թարմ հավաքված պատկերը երաշխավորված է եզակի նույնացուցիչ ունենալու համար TIMESTAMP_MILLISEC (տես նոր փուլի անվանման ձևաչափը). Այն դեպքում, երբ փուլեր-պահեստավորում կգտնվի համապատասխան պատկեր, werf-ը կհեռացնի թարմ կազմված պատկերը և կօգտագործի պատկերը քեշից:
Այլ կերպ ասած՝ պատկերի կառուցումն ավարտելու առաջին պրոցեսը (ամենաարագը) իրավունք կստանա այն պահելու փուլերով՝ պահեստավորում (և այնուհետև հենց այս մեկ պատկերն է, որը կօգտագործվի բոլոր կառուցումների համար): Դանդաղ կառուցման գործընթացը երբեք չի խանգարի ավելի արագ գործընթացին պահպանել ընթացիկ փուլի կառուցման արդյունքները և անցնել հաջորդ կառուցմանը:
.
Բարելավված Dockerfile builder-ի կատարումը
Այս պահին Dockerfile-ից կառուցված պատկերի փուլերի խողովակաշարը բաղկացած է մեկ փուլից. dockerfile. Ստորագրությունը հաշվարկելիս հաշվարկվում է ֆայլերի ստուգման գումարը context, որը կօգտագործվի հավաքման ժամանակ։ Մինչ այս բարելավումը, werf-ը ռեկուրսիվ կերպով քայլեց բոլոր ֆայլերի միջով և ստացավ ստուգիչ գումար՝ ամփոփելով յուրաքանչյուր ֆայլի համատեքստը և ռեժիմը: Սկսած v1.1-ից, werf-ը կարող է օգտագործել Git պահոցում պահված հաշվարկված չեկային գումարներ:
Ալգորիթմը հիմնված է . Ալգորիթմը հաշվի է առնում գրառումները .dockerignore և ֆայլի ծառը ռեկուրսիվ կերպով անցնում է միայն անհրաժեշտության դեպքում: Այսպիսով, մենք անջատեցինք ֆայլային համակարգը կարդալուց և ալգորիթմի կախվածությունը չափից context էական չէ։
Ալգորիթմը ստուգում է նաև չհետևված ֆայլերը և անհրաժեշտության դեպքում դրանք հաշվի է առնում չեկային գումարում։
Բարելավված կատարողականություն ֆայլեր ներմուծելիս
werf v1.1-ի տարբերակներն օգտագործում են rsync սերվեր, երբ . Նախկինում ներմուծումն իրականացվում էր երկու քայլով՝ օգտագործելով հոսթ համակարգից գրացուցակի տեղադրումը:
macOS-ի ներմուծման արդյունավետությունն այլևս չի սահմանափակվում Docker-ի ծավալներով, և ներմուծումն ավարտվում է նույն ժամանակահատվածում, ինչ Linux-ը և Windows-ը:
Բովանդակության վրա հիմնված հատկորոշում
Werf v1.1-ն աջակցում է այսպես կոչված պիտակավորումն ըստ պատկերի բովանդակության. բովանդակության վրա հիմնված հատկորոշում. Ստացված Docker պատկերների պիտակները կախված են այդ պատկերների բովանդակությունից:
Հրամանը գործարկելիս werf publish --tags-by-stages-signature կամ werf ci-env --tagging-strategy=stages-signature հրապարակված պատկերներ այսպես կոչված բեմական ստորագրություն պատկեր. Յուրաքանչյուր պատկեր հատկորոշված է այս պատկերի փուլերի իր ստորագրությամբ, որը հաշվարկվում է ըստ նույն կանոնների, ինչ յուրաքանչյուր փուլի սովորական ստորագրությունը առանձին, բայց պատկերի ընդհանուր նույնացուցիչն է:
Պատկերի փուլերի ստորագրությունը կախված է.
- այս պատկերի բովանդակությունը;
- Git-ի փոփոխությունների պատմությունները, որոնք հանգեցրել են այս բովանդակությանը:
Git պահոցը միշտ ունի կեղծ պարտավորություններ, որոնք չեն փոխում պատկերային ֆայլերի բովանդակությունը: Օրինակ՝ կատարում է միայն մեկնաբանություններով կամ միաձուլման հանձնարարականներով, կամ պարտավորություններ, որոնք փոխում են այն ֆայլերը Git-ում, որոնք չեն ներմուծվի պատկերի մեջ:
Բովանդակության վրա հիմնված հատկորոշում օգտագործելիս լուծվում են Kubernetes-ում հավելվածի փոդերի անհարկի վերագործարկման խնդիրները՝ կապված պատկերի անվան փոփոխության հետ, նույնիսկ եթե պատկերի բովանդակությունը չի փոխվել: Ի դեպ, սա այն պատճառներից մեկն է, որը թույլ չի տալիս մեկ հավելվածի բազմաթիվ միկրոծառայություններ պահել մեկ Git պահոցում։
Բացի այդ, բովանդակության վրա հիմնված պիտակավորումն ավելի հուսալի հատկորոշման մեթոդ է, քան Git ճյուղերի վրա հատկորոշելը, քանի որ ստացված պատկերների բովանդակությունը կախված չէ CI համակարգում խողովակաշարերի կատարման հաջորդականությունից՝ միևնույն ճյուղի մի քանի պարտավորությունների հավաքման համար:
Կարեւոր է,: սկսած այս պահից փուլեր-ստորագրություն - Ից միակ առաջարկվող պիտակավորման ռազմավարությունը. Այն կօգտագործվի լռելյայն հրամանում werf ci-env (եթե դուք հստակորեն նշում եք պիտակավորման այլ սխեման):
. Առանձին հրապարակում նույնպես կնվիրվի այս հատկանիշին։ ԹԱՐՄԱՑՎԱԾ (ապրիլի 3). Մանրամասն հոդվածով .
Հատումների մակարդակները
Օգտագործողն այժմ հնարավորություն ունի վերահսկել ելքը, սահմանել գրանցման մակարդակը և աշխատել վրիպազերծման տեղեկատվության հետ: Ընտրանքներ ավելացվել են --log-quiet, --log-verbose, --log-debug.
Լռելյայնորեն, ելքը պարունակում է նվազագույն տեղեկատվությունը.
Բազմակողմանի ելք օգտագործելիս (--log-verbose) կարող եք տեսնել, թե ինչպես է աշխատում werf-ը.
Մանրամասն արդյունք (--log-debug), բացի werf-ի վրիպազերծման տեղեկատվությունից, պարունակում է նաև օգտագործված գրադարանների տեղեկամատյաններ։ Օրինակ, դուք կարող եք տեսնել, թե ինչպես է տեղի ունենում Docker Registry-ի հետ փոխազդեցությունը, ինչպես նաև գրանցել այն վայրերը, որտեղ զգալի ժամանակ է ծախսվում.
Ապագա պլաններ
Զգուշացում! Ստորև նկարագրված տարբերակները նշված են v1.1 հասանելի կդառնա այս տարբերակով, որոնցից շատերը մոտ ապագայում: Թարմացումները կգան ավտոմատ թարմացումների միջոցով . Այս հատկանիշները չեն ազդում v1.1 գործառույթների կայուն մասի վրա, դրանց տեսքը չի պահանջում օգտագործողի ձեռքով միջամտություն գոյություն ունեցող կոնֆիգուրացիաներում:
Ամբողջական աջակցություն Docker Registry-ի տարբեր ներդրման համար (ՆՈՐ)
- Տարբերակ՝ v1.1
- Ամսաթվերը՝ մարտ
Նպատակն այն է, որ օգտագործողը օգտագործի մաքսային իրականացում առանց սահմանափակումների, երբ օգտագործում է werf-ը:
Ներկայումս մենք հայտնաբերել ենք լուծումների հետևյալ փաթեթը, որոնց համար մենք պատրաստվում ենք երաշխավորել ամբողջական աջակցություն.
- Կանխադրված (գրադարան/գրանցամատյան)*,
- AWS ECR
- Լազուր *,
- Docker Hub
- GCR*,
- GitHub փաթեթներ
- GitLab Registry*,
- Նավահանգիստ *,
- Նավահանգիստ.
Լուծումները, որոնք ներկայումս ամբողջությամբ ապահովված են werf-ի կողմից, նշվում են աստղանիշով: Մյուսների համար կա աջակցություն, բայց սահմանափակումներով:
Երկու հիմնական խնդիր կարելի է առանձնացնել.
- Որոշ լուծումներ չեն աջակցում պիտակների հեռացմանը Docker Registry API-ի միջոցով՝ թույլ չտալով օգտվողներին օգտագործել werf-ի ավտոմատ մաքրումը: Սա ճիշտ է AWS ECR, Docker Hub և GitHub փաթեթների համար:
- Որոշ լուծումներ չեն աջակցում, այսպես կոչված, տեղադրված պահեստարաններին (Docker Hub, GitHub Packages և Quay), սակայն օգտագործողը պետք է դրանք ստեղծի ձեռքով, օգտագործելով UI կամ API (AWS ECR):
Մենք պատրաստվում ենք լուծել այս և այլ խնդիրներ՝ օգտագործելով լուծումների բնիկ API-ները: Այս առաջադրանքը ներառում է նաև «werf»-ի գործողության ամբողջական ցիկլը դրանցից յուրաքանչյուրի համար թեստերով ծածկելը:
Բաշխված պատկերի ձևավորում (↑)
- Տարբերակ՝ v1.2 v1.1 (այս գործառույթի իրականացման առաջնահերթությունը մեծացել է)
- Ժամկետները՝ մարտ-ապրիլ մարտ
Այս պահին werf v1.0 և v1.1-ը կարող են օգտագործվել միայն մեկ հատուկ հոսթի վրա՝ պատկերներ կառուցելու և հրապարակելու և հավելվածը Kubernetes-ում տեղակայելու գործառնությունների համար:
Werf-ի բաշխված աշխատանքի հնարավորությունները բացելու համար, երբ Kubernetes-ում հավելվածների ստեղծումն ու տեղակայումը գործարկվում է մի քանի կամայական հոսթների վրա, և այդ հոսթները չեն պահպանում իրենց վիճակը build-ների միջև (ժամանակավոր վազորդներ), werf-ը պահանջվում է օգտագործելու հնարավորությունը: Docker Registry-ը որպես բեմական խանութ:
Նախկինում, երբ werf նախագիծը դեռ կոչվում էր dapp, այն ուներ նման հնարավորություն։ Այնուամենայնիվ, մենք բախվել ենք մի շարք խնդիրների, որոնք պետք է հաշվի առնել werf-ում այս ֆունկցիոնալությունն իրականացնելիս:
Նշում. Այս հատկությունը չի պահանջում կոլեկցիոներից աշխատել Kubernetes pods-ի ներսում, քանի որ Դա անելու համար դուք պետք է ձերբազատվեք տեղական Docker սերվերից կախվածությունից (Kubernetes pod-ում մուտք չկա դեպի տեղական Docker սերվեր, քանի որ գործընթացն ինքնին աշխատում է կոնտեյներով, և werf-ը չի աջակցում և չի աջակցի աշխատել Docker սերվերի հետ ցանցի միջոցով): Kubernetes-ի գործարկման աջակցությունը կիրականացվի առանձին:
GitHub Actions-ի պաշտոնական աջակցություն (ՆՈՐ)
- Տարբերակ՝ v1.1
- Ամսաթվերը՝ մարտ
Ներառում է «werf» փաստաթղթերը (բաժիններ վկայակոչելը и առաջնորդելու), ինչպես նաև պաշտոնական GitHub Action-ը՝ werf-ի հետ աշխատելու համար։
Բացի այդ, դա թույլ կտա werf-ին աշխատել ժամանակավոր վազորդների վրա:
CI համակարգի հետ օգտատերերի փոխազդեցության մեխանիզմը հիմնված կլինի պիտակների տեղադրման վրա՝ ձգվող հարցումների վրա՝ որոշակի գործողություններ նախաձեռնելու՝ հավելվածը ստեղծելու/տարածելու համար:
Տեղական մշակում և հավելվածների տեղակայում werf-ով (↓)
- Տարբերակ՝ v1.1
- Ժամկետները՝ հունվար-փետրվար ապրիլ
Հիմնական նպատակն է հասնել միասնական կոնֆիգուրացիայի՝ հավելվածների տեղակայման համար և՛ տեղական, և՛ արտադրության մեջ, առանց բարդ գործողությունների, արկղից դուրս:
werf-ից պահանջվում է նաև գործառնական ռեժիմ, որում հարմար կլինի խմբագրել հավելվածի կոդը և ակնթարթորեն ստանալ հետադարձ կապ գործող հավելվածից վրիպազերծման համար:
Մաքրման նոր ալգորիթմ (ՆՈՐ)
- Տարբերակ՝ v1.1
- Ամսաթվերը՝ ապրիլ
Ընթացիկ տարբերակում werf v1.1 ընթացակարգում cleanup Բովանդակության վրա հիմնված հատկորոշման սխեմայի համար պատկերների մաքրման դրույթ չկա. այս պատկերները կկուտակվեն:
Բացի այդ, werf-ի ներկայիս տարբերակը (v1.0 և v1.1) օգտագործում է մաքրման տարբեր քաղաքականություններ պիտակավորման սխեմաների ներքո հրապարակված պատկերների համար՝ Git ճյուղ, Git tag կամ Git commit:
Ստեղծվել է պատկերների մաքրման նոր ալգորիթմ, որը հիմնված է Git-ում կատարվող պարտավորությունների պատմության վրա, որը միավորված է պիտակավորման բոլոր սխեմաների համար.
- Պահպանեք ոչ ավելի, քան N1 պատկերներ, որոնք կապված են N2 ամենավերջին պարտավորությունների հետ յուրաքանչյուր git HEAD-ի համար (ճյուղեր և պիտակներ):
- Պահպանեք ոչ ավելի, քան N1 փուլի պատկերներ, որոնք կապված են N2 ամենավերջին պարտավորությունների հետ յուրաքանչյուր git HEAD-ի համար (ճյուղեր և պիտակներ):
- Պահպանեք բոլոր պատկերները, որոնք օգտագործվում են Kubernetes-ի ցանկացած կլաստերային ռեսուրսներում (կազմաձևման ֆայլի և անվանատարածքների բոլոր kube համատեքստերը սկանավորվում են, դուք կարող եք սահմանափակել այս վարքագիծը հատուկ ընտրանքներով):
- Պահպանեք բոլոր պատկերները, որոնք օգտագործվում են ռեսուրսների կազմաձևման մանիֆեստներում, որոնք պահպանված են Helm թողարկումներում:
- Պատկերը կարող է ջնջվել, եթե այն կապված չէ git-ից որևէ HEAD-ի հետ (օրինակ, քանի որ համապատասխան HEAD-ն ինքնին ջնջվել է) և չի օգտագործվում Kubernetes կլաստերի և Helm թողարկումներում որևէ մանիֆեստում:
Զուգահեռ պատկերի կառուցում (↓)
- Տարբերակ՝ v1.1
- Ամսաթվեր՝ հունվար-փետրվար ապրիլ*
Werf-ի ներկայիս տարբերակը հավաքում է նկարագրված պատկերներն ու արտեֆակտները werf.yaml, հաջորդաբար։ Անհրաժեշտ է զուգահեռացնել պատկերների և արտեֆակտների անկախ փուլերի հավաքման գործընթացը, ինչպես նաև ապահովել հարմար և տեղեկատվական արդյունք:
* Նշում. վերջնաժամկետը փոխվել է բաշխված հավաքման իրականացման առաջնահերթության բարձրացման պատճառով, ինչը կավելացնի հորիզոնական մասշտաբավորման ավելի շատ հնարավորություններ, ինչպես նաև gitHub գործողությունների հետ werf-ի օգտագործումը: Զուգահեռ հավաքումը օպտիմալացման հաջորդ քայլն է, որն ապահովում է ուղղահայաց մասշտաբայնություն մեկ նախագիծ հավաքելիս:
Անցում դեպի Helm 3 (↓)
- Տարբերակ՝ v1.2
- Ամսաթվեր՝ փետրվար-մարտ մայիս*
Ներառում է միգրացիա նոր կոդերի բազա և գոյություն ունեցող կայանքները տեղափոխելու ապացուցված, հարմար միջոց:
* Նշում. Helm 3-ին անցնելը չի ավելացնի զգալի հնարավորություններ werf-ին, քանի որ Helm 3-ի բոլոր հիմնական հատկանիշները (3-way-միաձուլում և առանց մշակման) արդեն ներդրված են werf-ում: Ավելին, werf-ն ունի նշվածներից բացի: Սակայն այս անցումը մնում է մեր ծրագրերում և կիրականացվի։
Jsonnet Kubernetes կոնֆիգուրացիան նկարագրելու համար (↓)
- Տարբերակ՝ v1.2
- Ժամկետները՝ հունվար-փետրվար ապրիլ-մայիս
Werf-ը կաջակցի Kubernetes-ի կազմաձևման նկարագրություններին Jsonnet ձևաչափով: Միևնույն ժամանակ, werf-ը կմնա համատեղելի Helm-ի հետ և կլինի նկարագրության ձևաչափի ընտրություն:
Պատճառն այն է, որ Go կաղապարները, շատերի կարծիքով, ունեն մուտքի բարձր արգելք, և տուժում է նաև այս կաղապարների կոդի հասկանալիությունը։
Դիտարկվում է նաև Kubernetes կոնֆիգուրացիայի նկարագրության այլ համակարգերի (օրինակ՝ Kustomize) ներդրման հնարավորությունը։
Աշխատում է Kubernetes-ի ներսում (↓)
- Տարբերակ՝ v1.2
- Ժամկետները՝ ապրիլ-մայիս մայիս-հունիս
Նպատակը. Համոզվեք, որ պատկերները կառուցված են և հավելվածը առաքվում է Kubernetes-ի վազորդների միջոցով: Նրանք. Նոր պատկերները կարող են ստեղծվել, հրապարակվել, մաքրվել և տեղակայվել անմիջապես Kubernetes pods-ից:
Այս հնարավորությունն իրականացնելու համար նախ պետք է կարողանաք ստեղծել բաշխված պատկերներ (տե՛ս վերը նշված կետը).
Այն նաև պահանջում է շինարարի գործառնական ռեժիմի աջակցություն՝ առանց Docker սերվերի (այսինքն՝ Kaniko-ի նման կառուցում կամ կառուցում օգտվողների տարածքում):
Werf-ը կաջակցի Kubernetes-ի վրա կառուցել ոչ միայն Dockerfile-ի, այլև իր Stapel Builder-ի հետ՝ աստիճանական վերակառուցումներով և Ansible-ով:
Քայլ դեպի բաց զարգացում
Մենք սիրում ենք մեր համայնքը (, ) և մենք ցանկանում ենք, որ ավելի ու ավելի շատ մարդիկ օգնեն վերֆը ավելի լավը դարձնել, հասկանալ այն ուղղությունը, որով մենք շարժվում ենք և մասնակցեն զարգացմանը:
Բոլորովին վերջերս որոշվեց անցնել մեր թիմի աշխատանքային ընթացքը բացահայտելու նպատակով։ Այժմ դուք կարող եք տեսնել անմիջական պլանները, ինչպես նաև ընթացիկ աշխատանքները հետևյալ ոլորտներում.
- ;
- ;
- ;
- .
Բավականին աշխատանք է տարվել հետևյալ հարցերի շուրջ.
- Անկապները հանվել են։
- Եղածները բերված են միասնական ձևաչափով, բավարար քանակությամբ մանրամասներով և մանրամասներով։
- Ավելացվել են նոր հարցեր՝ գաղափարներով և առաջարկություններով։
Ինչպես միացնել v1.1 տարբերակը
Տարբերակը ներկայումս հասանելի է (ալիքներում կայուն и քարքարոտ Այնուամենայնիվ, թողարկումները կհայտնվեն, քանի որ կայունացումը տեղի է ունենում ea ինքն արդեն բավականաչափ կայուն է օգտագործման համար, քանի որ անցավ ալիքներով ալֆա и ալբոմներԾանոթություններՄեսսենջերՕգտվող). Ակտիվացված է հետևյալ կերպ.
source $(multiwerf use 1.1 ea)
werf COMMAND ...Ամփոփում
Stapel-ի և Dockerfile-ի շինարարների համար նոր փուլային պահպանման ճարտարապետությունը և շինարարների օպտիմալացումները բացում են werf-ում բաշխված և զուգահեռ կառուցումներ իրականացնելու հնարավորությունը: Այս հատկանիշները շուտով կհայտնվեն նույն v1.1 թողարկումում և ավտոմատ կերպով հասանելի կդառնան ավտոմատ թարմացման մեխանիզմի միջոցով (օգտատերերի համար ).
Այս թողարկումում ավելացվել է պատկերի բովանդակության վրա հիմնված հատկորոշման ռազմավարություն. բովանդակության վրա հիմնված հատկորոշում, որը դարձել է լռելյայն ռազմավարություն։ Հիմնական հրամանների մատյանը նույնպես վերամշակվել է. werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Հաջորդ նշանակալից քայլը բաշխված հավաքների ավելացումն է: Բաշխված կառուցումները դարձել են ավելի առաջնահերթություն, քան զուգահեռ կառուցումները v1.0-ից ի վեր, քանի որ դրանք ավելի մեծ արժեք են հաղորդում werf-ին. շինարարների ուղղահայաց մասշտաբավորում և տարբեր CI/CD համակարգերում ժամանակավոր շինարարների աջակցություն, ինչպես նաև GitHub Actions-ի համար պաշտոնական աջակցություն ցուցաբերելու հնարավորություն: . Ուստի զուգահեռ հավաքների իրականացման ժամկետները տեղափոխվեցին: Այնուամենայնիվ, մենք աշխատում ենք երկու հնարավորություններն էլ որքան հնարավոր է շուտ իրականացնել։
Հետևե՛ք նորություններին։ Եվ մի մոռացեք այցելել մեզ խնդիր ստեղծելու, գոյություն ունեցողը գտնելու և պլյուս ավելացնելու, PR ստեղծելու կամ պարզապես հետևելու նախագծի զարգացմանը:
PS
Կարդացեք նաև մեր բլոգում.
- «»
- «";
- Werf-ում նորարարությունների մասին մի շարք նշումներ.
- «";
- «";
- «";
- «.
Source: www.habr.com