Նշում. թարգմ.Այս տարվա մայիսի 16-ը նշանակալի իրադարձություն է Kubernetes - Helm-ի փաթեթների կառավարչի մշակման գործում: Այս օրը ներկայացվեց նախագծի ապագա հիմնական տարբերակի՝ 3.0-ի առաջին ալֆա թողարկումը։ Դրա թողարկումը զգալի և երկար սպասված փոփոխություններ կբերի Helm-ում, որի հետ Կուբերնետես համայնքում շատերը մեծ հույսեր են կապում: Մենք ինքներս դրանցից մեկն ենք, քանի որ մենք ակտիվորեն օգտագործում ենք Helm-ը հավելվածների տեղակայման համար. մենք այն ինտեգրել ենք CI/CD-ի ներդրման մեր գործիքին: և ժամանակ առ ժամանակ մենք մեր ներդրումն ենք ունենում հոսանքին հակառակ զարգացման գործում։ Այս թարգմանությունը միավորում է 7 նշում պաշտոնական Helm բլոգից, որոնք նվիրված են Helm 3-ի առաջին ալֆա թողարկմանը և խոսում են նախագծի պատմության և Helm 3-ի հիմնական հատկանիշների մասին: Դրանց հեղինակը Մեթ «bacongobbler» Ֆիշերն է, Microsoft-ի աշխատակից: և Հելմի հիմնական պահպանողներից մեկը:
15 թվականի հոկտեմբերի 2015-ին ծնվեց նախագիծը, որն այժմ հայտնի է որպես Հելմ: Իր հիմնադրումից ընդամենը մեկ տարի անց Հելմի համայնքը միացավ Kubernetes-ին, մինչդեռ ակտիվորեն աշխատում էր Helm 2-ի վրա: 2018 թվականի հունիսին Հելմը որպես զարգացող (ինկուբացիոն) նախագիծ։ Արագ առաջ դեպի ներկա, և նոր Helm 3-ի առաջին ալֆա թողարկումը ճանապարհին է: (այս թողարկումը մայիսի կեսերին - մոտ. թարգմ.).
Այս հոդվածում ես կխոսեմ այն մասին, թե որտեղից սկսվեց ամեն ինչ, ինչպես մենք հասանք այնտեղ, որտեղ մենք այսօր ենք, կներկայացնեմ Helm 3-ի առաջին ալֆա թողարկումում առկա որոշ եզակի առանձնահատկություններ և կբացատրեմ, թե ինչպես ենք մենք նախատեսում առաջ շարժվել:
Ամփոփում
- Հելմի ստեղծման պատմությունը;
- քնքուշ հրաժեշտ Թիլերին;
- գծապատկերների պահոցներ;
- թողարկման կառավարում;
- գծապատկերների կախվածության փոփոխություններ;
- գրադարանի գծապատկերներ;
- ինչ է հաջորդը
Հելմի պատմությունը
Ծնունդը
Helm 1-ը սկսվել է որպես բաց կոդով նախագիծ՝ ստեղծված Deis-ի կողմից: Մենք փոքր ստարտափ էինք Microsoft-ը 2017 թվականի գարնանը. Մեր մյուս բաց կոդով նախագիծը, որը նույնպես կոչվում է Deis, ուներ գործիք deisctl, որն օգտագործվել է (ի թիվս այլ բաների)՝ Deis հարթակը տեղադրելու և գործարկելու համար . Այդ ժամանակ Fleet-ը կոնտեյներային նվագախմբային առաջին հարթակներից մեկն էր:
2015 թվականի կեսերին մենք որոշեցինք փոխել ընթացքը և Deis-ը (այն ժամանակ վերանվանվեց Deis Workflow) Fleet-ից տեղափոխեցինք Kubernetes։ Առաջիններից մեկը, որը վերանախագծվեց, տեղադրման գործիքն էր: deisctl. Մենք այն օգտագործել ենք Fleet կլաստերում Deis Workflow-ը տեղադրելու և կառավարելու համար:
Helm 1-ը ստեղծվել է այնպիսի հայտնի փաթեթների մենեջերների կերպարով, ինչպիսիք են Homebrew, apt և yum: Դրա հիմնական նպատակն էր պարզեցնել այնպիսի առաջադրանքներ, ինչպիսիք են փաթեթավորումը և հավելվածների տեղադրումը Kubernetes-ում: Helm-ը պաշտոնապես ներկայացվել է 2015 թվականին Սան Ֆրանցիսկոյի KubeCon համաժողովում:
Հելմի հետ մեր առաջին փորձը ստացվեց, բայց դա առանց լուրջ սահմանափակումների չէր: Նա վերցրեց մի շարք Kubernetes մանիֆեստներ՝ համեմված գեներատորներով՝ որպես YAML ներածական բլոկներ (առջևի նյութ)* և արդյունքները բեռնեց Kubernetes-ում:
* Նշում. թարգմ.Helm-ի առաջին տարբերակից YAML-ի շարահյուսությունն ընտրվել է Kubernetes-ի ռեսուրսները նկարագրելու համար, իսկ Jinja կաղապարներն ու Python սկրիպտներն ապահովվել են կոնֆիգուրացիաներ գրելիս: Այս և ընդհանրապես Հելմի առաջին տարբերակի կառուցվածքի մասին մենք ավելին գրել ենք «Հելմի համառոտ պատմություն» գլխում։ .
Օրինակ, YAML ֆայլում դաշտը փոխարինելու համար դուք պետք է ավելացնեիք հետևյալ կառուցվածքը մանիֆեստին.
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yamlՀիանալի է, որ կաղապարային շարժիչներ գոյություն ունեն այսօր, այնպես չէ՞:
Շատ պատճառներով Kubernetes-ի այս վաղ տեղադրիչը պահանջում էր մանիֆեստի ֆայլերի կոշտ կոդավորված ցուցակ և կատարում էր միայն իրադարձությունների փոքր, ֆիքսված հաջորդականություն: Այն այնքան դժվար էր օգտագործել, որ Deis Workflow R&D թիմը դժվար ժամանակ ունեցավ, երբ նրանք փորձեցին իրենց արտադրանքը տեղափոխել այս հարթակ, այնուամենայնիվ, գաղափարի սերմերը արդեն ցանվել էին: Մեր առաջին փորձը սովորելու հիանալի հնարավորություն էր. մենք հասկացանք, որ իսկապես կրքոտ ենք ստեղծելու պրագմատիկ գործիքներ, որոնք լուծում են մեր օգտատերերի առօրյա խնդիրները:
Հիմնվելով անցյալի սխալների փորձի վրա՝ մենք սկսեցինք մշակել Helm 2-ը:
Սաղավարտի պատրաստում 2
2015 թվականի վերջին Google-ի թիմը կապ հաստատեց մեզ հետ։ Նրանք աշխատում էին Kubernetes-ի համար նմանատիպ գործիքի վրա։ Kubernetes-ի տեղակայման կառավարիչը գոյություն ունեցող գործիքի մի նավահանգիստ էր, որն օգտագործվում էր Google Cloud Platform-ի համար: «Կցանկանա՞նք,— հարցրին նրանք,— մի քանի օր անցկացնել՝ քննարկելու նմանություններն ու տարբերությունները»։
2016 թվականի հունվարին Helm-ի և Deployment Manager-ի թիմերը հանդիպեցին Սիեթլում՝ մտքեր փոխանակելու համար: Բանակցություններն ավարտվեցին հավակնոտ ծրագրով. համատեղել երկու նախագծերը՝ ստեղծելու Helm 2-ը: Deis-ի և Google-ի հետ միասին տղաները (այժմ Բիթնամիի մի մասն է - մոտավորապես թարգմ.), և մենք սկսեցինք աշխատել Helm 2-ի վրա։
Մենք ցանկանում էինք պահպանել Հելմի օգտագործման հեշտությունը, բայց ավելացրինք հետևյալը.
- գծապատկերների ձևանմուշներ հարմարեցման համար;
- թիմերի ներկլաստերի կառավարում;
- համաշխարհային կարգի գծապատկերների պահեստ;
- կայուն փաթեթի ձևաչափ՝ ստորագրության տարբերակով;
- իմաստային տարբերակման և տարբերակների միջև հետադարձ համատեղելիության պահպանման ամուր հանձնառություն:
Այս նպատակներին հասնելու համար Helm էկոհամակարգին ավելացվել է երկրորդ տարրը: Այս ներկլաստերային բաղադրիչը կոչվում էր Tiller և պատասխանատու էր Helm գծապատկերների տեղադրման և դրանց կառավարման համար:
2 թվականին Helm 2016-ի թողարկումից ի վեր, Kubernetes-ն ավելացրել է մի քանի հիմնական նորամուծություններ: Ավելացվեց դերի վրա հիմնված մուտքի հսկողություն (), որն ի վերջո փոխարինեց ատրիբուտների վրա հիմնված մուտքի հսկողությունը (ABAC): Ներդրվեցին ռեսուրսների նոր տեսակներ (տեղակայումը դեռ բետա էր այդ ժամանակ): Ստեղծվել են հատուկ ռեսուրսների սահմանումներ (ի սկզբանե կոչվում են երրորդ կողմի ռեսուրսներ կամ TPR): Եվ ամենակարևորը, ի հայտ է եկել լավագույն փորձի մի շարք:
Այս բոլոր փոփոխությունների ֆոնին Հելմը շարունակեց հավատարմորեն ծառայել Kubernetes-ի օգտատերերին: Երեք տարի և բազմաթիվ նոր հավելումներից հետո պարզ էր, որ ժամանակն է էական փոփոխություններ կատարել կոդերի բազայում՝ ապահովելու համար, որ Հելմը կարող է շարունակել բավարարել զարգացող էկոհամակարգի աճող կարիքները:
Քնքուշ հրաժեշտ Թիլերին
Helm 2-ի մշակման ընթացքում մենք ներկայացրել ենք Tiller-ը որպես Google-ի տեղակայման մենեջերի հետ մեր ինտեգրման մաս: Tiller-ը կարևոր դեր է խաղացել ընդհանուր կլաստերի շրջանակներում աշխատող թիմերի համար. այն թույլ է տվել ենթակառուցվածքով աշխատող տարբեր մասնագետների համագործակցել թողարկումների միևնույն շարքի հետ:
Քանի որ դերի վրա հիմնված մուտքի վերահսկումը (RBAC) լռելյայն միացված էր Kubernetes 1.6-ում, արտադրության մեջ Tiller-ի հետ աշխատելն ավելի դժվարացավ: Անվտանգության հնարավոր քաղաքականության հսկայական քանակի պատճառով մեր դիրքորոշումը եղել է լռելյայն թույլատրելի կոնֆիգուրացիա առաջարկելը: Սա թույլ տվեց նորեկներին փորձարկել Helm-ի և Kubernetes-ի հետ՝ առանց նախապես սուզվելու անվտանգության կարգավորումները: Ցավոք, թույլտվության այս կոնֆիգուրացիան կարող է օգտվողին օժտել թույլտվությունների չափազանց լայն շրջանակով, որոնք նա կարիք չուներ: DevOps-ի և SRE-ի ինժեներները պետք է սովորեին լրացուցիչ գործառնական քայլեր՝ Tiller-ը բազմաբնակարան վարձակալող կլաստերում տեղադրելիս:
Իմանալով, թե ինչպես է համայնքն օգտագործում Helm-ը կոնկրետ իրավիճակներում, մենք հասկացանք, որ Tiller-ի թողարկման կառավարման համակարգը կարիք չունի ապավինել ներ-կլաստերային բաղադրիչին՝ վիճակը պահպանելու կամ որպես կենտրոնական հանգույց՝ թողարկման տեղեկատվության համար: Փոխարենը, մենք կարող էինք պարզապես տեղեկատվություն ստանալ Kubernetes API սերվերից, ստեղծել գծապատկեր հաճախորդի կողմից և տեղադրել տեղադրման գրառումը Kubernetes-ում:
Թիլերի հիմնական նպատակին կարելի էր հասնել առանց Թիլերի, ուստի Helm 3-ի հետ կապված մեր առաջին որոշումներից մեկը Թիլլերին ամբողջությամբ հրաժարվելն էր:
Թիլերի հեռանալով Հելմի անվտանգության մոդելը արմատապես պարզեցվել է: Helm 3-ն այժմ աջակցում է ներկայիս Kubernetes-ի անվտանգության, ինքնության և թույլտվության բոլոր ժամանակակից մեթոդներին: Ղեկի թույլտվությունները որոշվում են օգտագործելով . Կլաստերների ադմինիստրատորները կարող են սահմանափակել օգտատերերի իրավունքները մինչև ցանկացած մակարդակի հստակություն: Թողարկումները դեռ պահպանվում են կլաստերի ներսում, իսկ Helm-ի մնացած ֆունկցիոնալությունը մնում է անփոփոխ:
Գծապատկերների պահոցներ
Բարձր մակարդակով գծապատկերների պահոցը այն վայրն է, որտեղ գծապատկերները կարող են պահվել և տարածվել: Helm հաճախորդը փաթեթավորում և ուղարկում է գծապատկերները պահեստ: Պարզ ասած, գծապատկերների պահեստը պարզունակ HTTP սերվեր է՝ index.yaml ֆայլով և որոշ փաթեթավորված գծապատկերներով:
Թեև Charts Repository API-ն ունի որոշ առավելություններ, որոնք համապատասխանում են պահեստավորման հիմնական պահանջներին, կան նաև մի քանի թերություններ.
- Գծապատկերների պահոցները համատեղելի չեն արտադրական միջավայրում պահանջվող անվտանգության իրականացման մեծ մասի հետ: Նույնականացման և թույլտվության համար ստանդարտ API ունենալը չափազանց կարևոր է արտադրության սցենարներում:
- Հելմի գծապատկերների ծագման գործիքները, որոնք օգտագործվում են գծապատկերի ամբողջականությունն ու ծագումը ստորագրելու, ստուգելու համար, գծապատկերի հրապարակման գործընթացի կամընտիր մաս են:
- Բազմ օգտատերերի սցենարներում նույն գծապատկերը կարող է վերբեռնվել մեկ այլ օգտատիրոջ կողմից՝ կրկնապատկելով նույն բովանդակությունը պահելու համար պահանջվող տարածքը: Այս խնդիրը լուծելու համար մշակվել են ավելի խելացի պահոցներ, սակայն դրանք պաշտոնական ճշգրտման մաս չեն կազմում:
- Մեկ ինդեքսային ֆայլի օգտագործումը որոնման, մետատվյալների պահպանման և գծապատկերների առբերման համար դժվարացրել է անվտանգ բազմաբնակարան օգտատերերի իրականացումը:
Ծրագիր (հայտնի է նաև որպես Docker Registry v2) Docker Registry-ի իրավահաջորդն է և ըստ էության գործում է որպես Docker պատկերների փաթեթավորման, առաքման, պահպանման և առաքման գործիքների հավաքածու: Շատ խոշոր ամպային ծառայություններ առաջարկում են բաշխման վրա հիմնված ապրանքներ: Այս մեծացված ուշադրության շնորհիվ «Distribution» նախագիծը շահել է տարիների բարելավումներից, անվտանգության լավագույն փորձից և դաշտային փորձարկումներից, որոնք այն դարձրել են բաց կոդով աշխարհի ամենահաջողակ հերոսներից մեկը:
Բայց դուք գիտեի՞ք, որ բաշխման նախագիծը նախատեսված էր ցանկացած ձևի բովանդակություն տարածելու համար, այլ ոչ միայն կոնտեյների պատկերներ:
ջանքերի շնորհիվ (կամ OCI), Ղեկի գծապատկերները կարող են տեղադրվել բաշխման ցանկացած օրինակի վրա: Առայժմ այս գործընթացը փորձնական է։ Մուտք գործելու աջակցությունը և ամբողջական Helm 3-ի համար անհրաժեշտ այլ հնարավորություններ դեռևս ընթացքի մեջ են, բայց մենք ուրախ ենք սովորել OCI-ի և Distribution թիմերի կողմից տարիների ընթացքում կատարած հայտնագործություններից: Եվ նրանց մենթորության և առաջնորդության միջոցով մենք սովորում ենք, թե ինչպիսին է լայնածավալ մատչելի ծառայություն գործելը:
Հասանելի է Helm աղյուսակի պահոցների որոշ առաջիկա փոփոխությունների ավելի մանրամասն նկարագրությունը .
Թողարկման կառավարում
Helm 3-ում հավելվածի վիճակը հետևվում է կլաստերի ներսում մի զույգ օբյեկտների միջոցով.
- թողարկման օբյեկտ - ներկայացնում է հավելվածի օրինակ.
- թողարկման տարբերակի գաղտնիքը - ներկայացնում է հավելվածի ցանկալի վիճակը ժամանակի որոշակի կետում (օրինակ, նոր տարբերակի թողարկում):
Մարտահրավեր helm install ստեղծում է թողարկման օբյեկտ և թողարկման տարբերակի գաղտնիք: Զանգահարեք helm upgrade պահանջում է թողարկման օբյեկտ (որը կարող է փոխել) և ստեղծում է նոր թողարկման տարբերակի գաղտնիք, որը պարունակում է նոր արժեքներ և պատրաստված մանիֆեստ:
Թողարկման օբյեկտը պարունակում է տեղեկատվություն թողարկման մասին, որտեղ թողարկումը անվանված գծապատկերի և արժեքների հատուկ տեղադրումն է: Այս օբյեկտը նկարագրում է թողարկման վերաբերյալ վերին մակարդակի մետատվյալները: Թողարկման օբյեկտը պահպանվում է հավելվածի կյանքի ցիկլի ընթացքում և հանդիսանում է թողարկման տարբերակի բոլոր գաղտնիքների, ինչպես նաև բոլոր օբյեկտների, որոնք ուղղակիորեն ստեղծված են Helm աղյուսակի կողմից:
Թողարկման տարբերակի գաղտնիքը թողարկումը կապում է մի շարք վերանայումների հետ (տեղադրում, թարմացումներ, հետադարձումներ, ջնջում):
Helm 2-ում վերանայումները չափազանց հետևողական էին: Զանգահարեք helm install ստեղծված v1, հետագա թարմացում (թարմացում)՝ v2 և այլն: Թողարկման և թողարկման տարբերակի գաղտնիքը վերածվել է մեկ օբյեկտի, որը հայտնի է որպես վերանայում: Վերանայումները պահվում էին Tiller-ի հետ նույն անվանատարածքում, ինչը նշանակում էր, որ յուրաքանչյուր թողարկում «գլոբալ» էր անվանատարածքի առումով. արդյունքում կարելի էր օգտագործել անվան միայն մեկ օրինակ։
Helm 3-ում յուրաքանչյուր թողարկում կապված է մեկ կամ մի քանի թողարկման տարբերակի գաղտնիքների հետ: Թողարկման օբյեկտը միշտ նկարագրում է Kubernetes-ում տեղադրված ընթացիկ թողարկումը: Յուրաքանչյուր թողարկման տարբերակի գաղտնիքը նկարագրում է այդ թողարկման միայն մեկ տարբերակ: Բարելավումը, օրինակ, կստեղծի նոր թողարկման տարբերակի գաղտնիք, այնուհետև կփոխի թողարկման օբյեկտը՝ մատնանշելով այդ նոր տարբերակը: Հետ վերադարձի դեպքում կարող եք օգտագործել նախորդ թողարկման տարբերակի գաղտնիքները՝ թողարկումը նախկին վիճակին վերադարձնելու համար:
Այն բանից հետո, երբ Tiller-ը լքված է, Helm 3 խանութները թողարկում են տվյալներ նույն անվանատարածքում, ինչ թողարկումը: Այս փոփոխությունը թույլ է տալիս տեղադրել նույն թողարկման անունով աղյուսակը մեկ այլ անվանատարածքում, և տվյալները պահվում են կլաստերի թարմացումների/վերագործարկման միջև և այլն: Օրինակ՝ կարող եք WordPress-ը տեղադրել «foo» անվանատարածքում, այնուհետև «bar» անվանատարածքում, և երկու թողարկումները կարող են անվանվել «wordpress»:
Փոփոխություններ գծապատկերների կախվածության մեջ
Գծապատկերները փաթեթավորված են (օգտագործելով helm package) Helm 2-ի հետ օգտագործման համար կարող է տեղադրվել Helm 3-ի հետ, սակայն գծապատկերների մշակման աշխատանքային հոսքը ամբողջությամբ վերանայվել է, ուստի որոշ փոփոխություններ պետք է կատարվեն Helm 3-ով գծապատկերների մշակումը շարունակելու համար: Մասնավորապես, փոխվել է գծապատկերների կախվածության կառավարման համակարգը:
Գծապատկերի կախվածության կառավարման համակարգը տեղափոխվել է requirements.yaml и requirements.lock մասին Chart.yaml и Chart.lock. Սա նշանակում է, որ գծապատկերները, որոնք օգտագործել են հրամանը helm dependency, պահանջում է որոշակի կարգավորում՝ Helm 3-ում աշխատելու համար:
Դիտարկենք մի օրինակ։ Եկեք կախվածություն ավելացնենք Helm 2-ի գծապատկերում և տեսնենք, թե ինչ է փոխվում Helm 3-ին տեղափոխվելիս:
Հելմում 2 requirements.yaml այսպիսի տեսք ուներ.
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
Հելմ 3-ում նույն կախվածությունը կարտացոլվի ձեր մեջ Chart.yaml:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
Դիագրամները դեռ ներբեռնվում և տեղադրվում են գրացուցակում charts/, ուստի ենթագծապատկերներ (ենթագծապատկերներ), կատալոգում ընկած charts/, կշարունակի աշխատել առանց փոփոխությունների։
Ներկայացնում ենք գրադարանային գծապատկերները
Helm 3-ն աջակցում է գծապատկերների դասի, որը կոչվում է գրադարանային գծապատկերներ (գրադարանի գծապատկեր). Այս աղյուսակը օգտագործվում է այլ գծապատկերների կողմից, բայց ինքնուրույն չի ստեղծում թողարկման որևէ արտեֆակտ: Գրադարանի գծապատկերների ձևանմուշները կարող են միայն տարրեր հայտարարել define. Այլ բովանդակությունը պարզապես անտեսվում է: Սա թույլ է տալիս օգտվողներին նորից օգտագործել և կիսել կոդի հատվածները, որոնք կարող են օգտագործվել բազմաթիվ գծապատկերներում՝ դրանով իսկ խուսափելով կրկնօրինակումից և հավատարիմ մնալով սկզբունքին: .
Գրադարանի գծապատկերները հայտարարված են բաժնում dependencies ֆայլում Chart.yaml. Դրանց տեղադրումն ու կառավարումը ոչնչով չի տարբերվում այլ գծապատկերներից:
dependencies:
- name: mylib
version: 1.x.x
repository: quay.ioՄենք ոգևորված ենք այս բաղադրիչի օգտագործման դեպքերով, որոնք կբացվեն գծապատկեր մշակողների համար, ինչպես նաև գրադարանային գծապատկերներից ի հայտ եկած լավագույն փորձը:
Ինչ հաջորդ?
Helm 3.0.0-alpha.1-ը այն հիմքն է, որի վրա մենք սկսում ենք կառուցել Helm-ի նոր տարբերակը: Հոդվածում ես նկարագրեցի Helm 3-ի մի քանի հետաքրքիր առանձնահատկություններ: Նրանցից շատերը դեռ զարգացման սկզբնական փուլում են, և դա նորմալ է. Ալֆա թողարկման իմաստը գաղափարը փորձարկելն է, վաղ օգտատերերից կարծիքներ հավաքելը և մեր ենթադրությունները հաստատելը:
Հենց որ թողարկվի ալֆա տարբերակը (հիշեք, որ սա է - մոտ. թարգմ.), մենք կսկսենք ընդունել համայնքից Helm 3-ի համար նախատեսված patches: Դուք պետք է ամուր հիմք ստեղծեք, որը թույլ կտա նոր ֆունկցիոնալություն մշակել և ընդունել, և օգտատերերին ներգրավված զգան գործընթացում՝ բացելով տոմսերը և ուղղումներ կատարելով:
Ես փորձել եմ ընդգծել Helm 3-ի որոշ հիմնական բարելավումներ, բայց այս ցանկը ոչ մի դեպքում սպառիչ չէ: Helm 3-ի ամբողջական ճանապարհային քարտեզը ներառում է այնպիսի առանձնահատկություններ, ինչպիսիք են բարելավված թարմացման ռազմավարությունները, OCI ռեգիստրների հետ ավելի խորը ինտեգրումը և գծապատկերների արժեքները վավերացնելու համար JSON սխեմաների օգտագործումը: Մենք նաև նախատեսում ենք մաքրել կոդերի բազան և թարմացնել դրա մասերը, որոնք անտեսվել են վերջին երեք տարիների ընթացքում:
Եթե կարծում եք, որ մենք ինչ-որ բան բաց ենք թողել, մենք ուրախ կլինենք լսել ձեր մտքերը:
Միացե՛ք մեր քննարկմանը :
-
#helm-usersհարցերի և համայնքի հետ պարզ շփման համար. -
#helm-devքաշելու հարցումները, ծածկագիրը և սխալները քննարկելու համար:
Կարող եք նաև զրուցել մեր ամենշաբաթյա հանրային ծրագրավորողների զանգերում հինգշաբթի օրերին, ժամը 19:30 MSK: Հանդիպումները նվիրված են հարցերի քննարկմանը, որոնց վրա աշխատում են հիմնական մշակողները և համայնքը, ինչպես նաև շաբաթվա քննարկման թեմաները: Հանդիպմանը կարող են միանալ և մասնակցել բոլոր ցանկացողները։ Հղումը հասանելի է Slack ալիքում #helm-dev.
PS թարգմանչից
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «";
- «";
- «.
Source: www.habr.com