«Cloud native» կամ պարզապես «ամպային» հավելվածները ստեղծվել են հատուկ ամպային ենթակառուցվածքներում աշխատելու համար: Դրանք սովորաբար կառուցվում են որպես բեռնարկղերի մեջ փաթեթավորված մանր զուգակցված միկրոծառայությունների մի շարք, որոնք իրենց հերթին կառավարվում են ամպային հարթակի միջոցով: Նման հավելվածները լռելյայն պատրաստված են խափանումների համար, ինչը նշանակում է, որ դրանք աշխատում են հուսալիորեն և մասշտաբային նույնիսկ ենթակառուցվածքի մակարդակի լուրջ խափանումների դեպքում: Մետաղադրամի մյուս կողմը սահմանափակումների (պայմանագրերի) հավաքածուն է, որը ամպային հարթակը սահմանում է կոնտեյներային հավելվածների վրա, որպեսզի կարողանա դրանք ավտոմատ կերպով կառավարել։
Թեև լիովին գիտակցում են ամպի վրա հիմնված հավելվածներին անցնելու անհրաժեշտությունն ու կարևորությունը, շատ կազմակերպություններ դեռ չգիտեն, թե որտեղից սկսել: Այս գրառման մեջ մենք կանդրադառնանք մի շարք սկզբունքների, որոնք, եթե պահպանվեն կոնտեյներային հավելվածներ մշակելիս, թույլ կտան գիտակցել ամպային հարթակների ներուժը և հասնել հավելվածների հուսալի շահագործման և մասշտաբացման նույնիսկ ՏՏ ենթակառուցվածքում լուրջ խափանումների դեպքում: մակարդակ. Այստեղ նկարագրված սկզբունքների վերջնական նպատակն է սովորել, թե ինչպես ստեղծել հավելվածներ, որոնք կարող են ավտոմատ կերպով կառավարվել ամպային հարթակների կողմից, ինչպիսին է Kubernetes-ը:
Ծրագրային նախագծման սկզբունքներ
Ծրագրավորման աշխարհում սկզբունքները վերաբերում են բավականին ընդհանուր կանոններին, որոնք պետք է պահպանվեն ծրագրակազմ մշակելիս: Դրանք կարող են օգտագործվել ծրագրավորման ցանկացած լեզվով աշխատելիս։ Յուրաքանչյուր սկզբունք ունի իր նպատակները, որոնց հասնելու գործիքները սովորաբար ձևանմուշներն ու պրակտիկաներն են: Գոյություն ունեն նաև մի շարք հիմնարար սկզբունքներ բարձրորակ ծրագրեր ստեղծելու համար, որոնցից բխում են մնացած բոլորը։ Ահա հիմնարար սկզբունքների մի քանի օրինակ.
- (Պահպանեք այն պարզ, հիմար) - մի բարդացրեք այն;
- (Մի կրկնիր ինքդ քեզ) - մի կրկնիր ինքդ քեզ;
- (Դա ձեզ պետք չի լինի) - մի ստեղծեք մի բան, որն անհապաղ անհրաժեշտ չէ.
- Մտահոգությունների տարանջատում – բաշխել պարտականությունները:
Ինչպես տեսնում եք, այս սկզբունքները չեն սահմանում որևէ կոնկրետ կանոն, այլ պատկանում են այսպես կոչված ողջախոհության նկատառումների կատեգորիային, որոնք հիմնված են գործնական փորձի վրա, որոնք կիսում են բազմաթիվ մշակողներ և որոնց նրանք պարբերաբար հղում են անում:
Բացի այդ, կա – Օբյեկտ-կողմնորոշված ծրագրավորման և դիզայնի առաջին հինգ սկզբունքների հավաքածու, որը ձևակերպվել է Ռոբերտ Մարտինի կողմից: SOLID-ը ներառում է լայն, բաց, փոխլրացնող սկզբունքներ, որոնք համատեղ կիրառման դեպքում օգնում են ստեղծել ավելի լավ ծրագրային համակարգեր և ավելի լավ պահպանել դրանք երկարաժամկետ հեռանկարում:
SOLID սկզբունքները պատկանում են OOP-ի ոլորտին և ձևակերպված են այնպիսի հասկացությունների և հասկացությունների լեզվով, ինչպիսիք են դասերը, միջերեսները և ժառանգությունը: Ըստ անալոգիայի, զարգացման սկզբունքները կարող են ձևակերպվել նաև ամպային հավելվածների համար, միայն այստեղ հիմնական տարրը կլինի ոչ թե դաս, այլ կոնտեյներ: Հետևելով այս սկզբունքներին՝ դուք կարող եք ստեղծել կոնտեյներային հավելվածներ, որոնք ավելի լավ են համապատասխանում Kubernetes-ի նման ամպային հարթակների նպատակներին և խնդիրներին:
Ամպային բնիկ տարաներ. Կարմիր գլխարկի մոտեցումը
Այսօր գրեթե ցանկացած հավելված կարելի է համեմատաբար հեշտությամբ փաթեթավորել տարաների մեջ: Բայց որպեսզի հավելվածները արդյունավետորեն ավտոմատացվեն և կազմակերպվեն Kubernetes-ի պես ամպային հարթակում, լրացուցիչ ջանքեր են պահանջվում:
Ստորև ներկայացված գաղափարների համար հիմք է հանդիսացել մեթոդաբանությունը և շատ այլ աշխատանքներ վեբ հավելվածների կառուցման տարբեր ասպեկտների վերաբերյալ՝ սկզբնաղբյուրի կոդերի կառավարումից մինչև մասշտաբային մոդելներ: Նկարագրված սկզբունքները վերաբերում են միայն կոնտեյներային հավելվածների մշակմանը, որոնք կառուցված են միկրոծառայությունների վրա և նախատեսված են ամպային հարթակների համար, ինչպիսին է Kubernetes-ը: Մեր քննարկման հիմնական տարրը կոնտեյների պատկերն է, իսկ թիրախային կոնտեյների գործարկման ժամանակը կոնտեյների նվագախմբային հարթակն է: Առաջարկվող սկզբունքների նպատակն է ստեղծել կոնտեյներներ, որոնց պլանավորման, մասշտաբավորման և մոնիտորինգի առաջադրանքները կարող են ավտոմատացվել նվագախմբային հարթակների մեծ մասում: Սկզբունքները ներկայացված են առանց հատուկ հերթականության։
Մեկ մտահոգության սկզբունք (SCP)
Այս սկզբունքը շատ առումներով նման է Միասնական պատասխանատվության սկզբունքին: ), որը SOLID հավաքածուի մի մասն է և նշում է, որ յուրաքանչյուր օբյեկտ պետք է ունենա մեկ պատասխանատվություն, և այդ պատասխանատվությունը պետք է ամբողջությամբ ներառվի դասի մեջ: SRP-ի իմաստն այն է, որ յուրաքանչյուր պատասխանատվություն փոփոխության պատճառ է, և դասակարգը պետք է ունենա փոփոխության մեկ և միայն մեկ պատճառ:
SCP-ում մենք օգտագործում ենք «մտահոգություն» բառը «պատասխանատվություն» բառի փոխարեն՝ ցույց տալու համար կոնտեյների վերացականության ավելի բարձր մակարդակը և ավելի լայն նպատակը՝ համեմատած OOP դասի հետ: Եվ եթե SRP-ի նպատակը փոփոխության միայն մեկ պատճառ ունենալն է, ապա SCP-ի հետևում կանգնած է բեռնարկղերի վերօգտագործման և փոխարինման հնարավորությունը ընդլայնելու ցանկությունը: Հետևելով SRP-ին և ստեղծելով կոնտեյներ, որը լուծում է մեկ խնդիր և կատարում է այն ֆունկցիոնալ ամբողջական ձևով, դուք մեծացնում եք այդ կոնտեյների պատկերը տարբեր կիրառական համատեքստերում կրկին օգտագործելու հնարավորությունները:
SCP սկզբունքն ասում է, որ յուրաքանչյուր կոնտեյներ պետք է լուծի մեկ խնդիր և լավ անի: Ավելին, SCP-ն բեռնարկղերի աշխարհում ավելի հեշտ է հասնել, քան SRP-ն OOP աշխարհում, քանի որ կոնտեյներները սովորաբար կատարում են մեկ գործընթաց, և շատ ժամանակ այս գործընթացը լուծում է մեկ խնդիր:
Եթե կոնտեյներային միկրոսերվիսը պետք է միանգամից մի քանի խնդիր լուծի, ապա այն կարելի է բաժանել մեկ առաջադրանքով բեռնարկղերի և միավորել մեկ պատիճ (կոնտեյների հարթակի տեղակայման միավոր)՝ օգտագործելով կողային և սկզբնական կոնտեյների կաղապարներ: Բացի այդ, SCP-ն հեշտացնում է հին կոնտեյների փոխարինումը (օրինակ՝ վեբ սերվերը կամ հաղորդագրության միջնորդը) նորով, որը լուծում է նույն խնդիրը, բայց ունի ընդլայնված ֆունկցիոնալություն կամ ավելի լավ մասշտաբներ:
Բարձր դիտարկելիության սկզբունք (HOP)
Երբ կոնտեյներներն օգտագործվում են որպես հավելվածներ փաթեթավորելու և գործարկելու միասնական միջոց, հավելվածներն իրենք դիտվում են որպես սև արկղ: Այնուամենայնիվ, եթե դրանք ամպային կոնտեյներներ են, ապա նրանք պետք է հատուկ API-ներ տրամադրեն գործարկման ժամանակին՝ վերահսկելու բեռնարկղերի առողջությունը և, անհրաժեշտության դեպքում, համապատասխան գործողություններ ձեռնարկելու համար: Առանց դրա հնարավոր չի լինի միավորել բեռնարկղերի թարմացման և դրանց կյանքի ցիկլը կառավարելու ավտոմատացումը, ինչը, իր հերթին, կվատթարացնի ծրագրային համակարգի կայունությունն ու օգտագործելիությունը։
Գործնականում կոնտեյներային հավելվածը պետք է առնվազն ունենա API տարբեր տեսակի առողջական ստուգումների համար՝ աշխուժության թեստեր և պատրաստության թեստեր: Եթե դիմումը պնդում է, որ ավելին է անում, այն պետք է տրամադրի իր վիճակը վերահսկելու այլ միջոցներ: Օրինակ, կարևոր իրադարձությունների գրանցում STDERR-ի և STDOUT-ի միջոցով տեղեկամատյանների ագրեգացման համար՝ օգտագործելով Fluentd, Logstash և այլ նմանատիպ գործիքներ: Ինչպես նաև ինտեգրում հետագծման և չափումների հավաքածուների գրադարաններին, ինչպիսիք են OpenTracing-ը, Prometheus-ը և այլն:
Ընդհանրապես, հավելվածը դեռևս կարող է դիտվել որպես սև արկղ, սակայն այն պետք է ապահովված լինի բոլոր API-ներով, որոնք անհրաժեշտ են հարթակին՝ այն լավագույնս վերահսկելու և կառավարելու համար:
Կյանքի ցիկլի համապատասխանության սկզբունք (LCP)
LCP-ն ՀՕՊ-ի հակաթեզն է: Թեև HOP-ը նշում է, որ բեռնարկղը պետք է ցուցադրի ընթերցված API-ները հարթակին, LCP-ն պահանջում է, որ հավելվածը կարողանա տեղեկատվություն ընդունել հարթակից: Ընդ որում, կոնտեյները պետք է ոչ միայն ստանա իրադարձություններ, այլեւ հարմարվի, այլ կերպ ասած՝ արձագանքի դրանց։ Այստեղից էլ առաջացել է սկզբունքի անվանումը, որը կարելի է դիտարկել որպես հարթակին գրավոր API-ներով ապահովելու պահանջ։
Պլատֆորմներն ունեն տարբեր տեսակի միջոցառումներ, որոնք կօգնեն կառավարել կոնտեյների կյանքի ցիկլը: Բայց դիմումն ինքը պետք է որոշի, թե դրանցից ում ընկալի և ինչպես արձագանքի։
Պարզ է, որ որոշ իրադարձություններ ավելի կարևոր են, քան մյուսները: Օրինակ, եթե հավելվածը լավ չի հանդուրժում խափանումները, այն պետք է ընդունի ազդանշան՝ դադարեցնել (SIGTERM) հաղորդագրությունները և հնարավորինս արագ սկսել դրա դադարեցման ռեժիմը՝ SIGTERM-ից հետո ստացվող ազդանշանը՝ սպանել (SIGKILL):
Բացի այդ, իրադարձությունները, ինչպիսիք են PostStart-ը և PreStop-ը, կարող են կարևոր լինել հավելվածի կյանքի ցիկլի համար: Օրինակ, հավելվածը գործարկելուց հետո այն կարող է պահանջել որոշակի տաքացման ժամանակ, որպեսզի կարողանա պատասխանել հարցումներին: Կամ հավելվածը պետք է անջատի ռեսուրսները ինչ-որ հատուկ ձևով:
Պատկերի անփոփոխելիության սկզբունքը (IIP)
Ընդհանրապես ընդունված է, որ կոնտեյներային հավելվածները պետք է մնան անփոփոխ կառուցվելուց հետո, նույնիսկ եթե դրանք գործարկվեն տարբեր միջավայրերում: Սա պահանջում է տվյալների պահեստավորման արտաքին տեսքը գործարկման ժամանակ (այլ կերպ ասած՝ դրա համար օգտագործել արտաքին գործիքներ) և ապավինել արտաքին, գործարկման ժամանակին հատուկ կոնֆիգուրացիաներին, այլ ոչ թե փոփոխել կամ ստեղծել եզակի կոնտեյներներ յուրաքանչյուր միջավայրի համար: Հավելվածի ցանկացած փոփոխությունից հետո կոնտեյների պատկերը պետք է վերակառուցվի և տեղադրվի օգտագործվող բոլոր միջավայրերում: Ի դեպ, ՏՏ համակարգերը կառավարելիս կիրառվում է նմանատիպ սկզբունք, որը հայտնի է որպես սերվերների և ենթակառուցվածքների անփոփոխության սկզբունք։
IIP-ի նպատակն է կանխել առանձին կոնտեյների պատկերների ստեղծումը տարբեր գործարկման միջավայրերի համար և օգտագործել նույն պատկերն ամենուր՝ համապատասխան միջավայրին հատուկ կոնֆիգուրացիայի հետ մեկտեղ: Այս սկզբունքին հետևելը թույլ է տալիս իրականացնել այնպիսի կարևոր պրակտիկաներ ամպային համակարգերի ավտոմատացման տեսանկյունից, ինչպիսիք են հավելվածների թարմացումների հետադարձ և առաջ անցնելը:
Գործընթացի միանգամյա օգտագործման սկզբունքը (PDP)
Կոնտեյների ամենակարևոր բնութագրիչներից մեկը դրա անցողիկությունն է. կոնտեյների օրինակը հեշտ է ստեղծել և հեշտ է ոչնչացնել, ուստի ցանկացած պահի այն հեշտությամբ կարող է փոխարինվել մեկ այլ օրինակով: Նման փոխարինման համար շատ պատճառներ կարող են լինել՝ սպասարկման թեստի ձախողում, հավելվածի մասշտաբացում, տեղափոխում այլ հոսթին, հարթակի ռեսուրսների սպառում կամ այլ իրավիճակներ։
Որպես հետևանք, կոնտեյներային հավելվածները պետք է պահպանեն իրենց վիճակը՝ օգտագործելով որոշ արտաքին միջոցներ, կամ դրա համար օգտագործեն ներքին բաշխված սխեմաներ՝ ավելորդությամբ: Բացի այդ, հավելվածը պետք է արագ գործարկվի և արագ փակվի, ինչպես նաև պատրաստ լինի ապարատային հանկարծակի մահացու ձախողման:
Պրակտիկաներից մեկը, որն օգնում է իրականացնել այս սկզբունքը, տարաները փոքր պահելն է: Ամպային միջավայրերը կարող են ավտոմատ կերպով ընտրել հյուրընկալող՝ կոնտեյների օրինակ գործարկելու համար, այնպես որ որքան փոքր է կոնտեյները, այնքան ավելի արագ կսկսվի այն. այն պարզապես ավելի արագ կպատճենվի թիրախային հոսթին ցանցի միջոցով:
Ինքնազսպման սկզբունք (S-CP)
Այս սկզբունքի համաձայն, հավաքման փուլում բոլոր անհրաժեշտ բաղադրիչները ներառված են տարայի մեջ: Կոնտեյները պետք է կառուցվի այն ենթադրության հիման վրա, որ համակարգն ունի միայն մաքուր Linux միջուկ, ուստի բոլոր անհրաժեշտ լրացուցիչ գրադարանները պետք է տեղադրվեն հենց կոնտեյների մեջ: Այն պետք է նաև պարունակի այնպիսի բաներ, ինչպիսիք են համապատասխան ծրագրավորման լեզվի գործարկման ժամանակը, հավելվածի հարթակը (անհրաժեշտության դեպքում) և այլ կախվածություններ, որոնք կպահանջվեն մինչ բեռնարկղային հավելվածն աշխատում է:
Բացառություններ են արվում այն կոնֆիգուրացիաների համար, որոնք տարբերվում են միջավայրից միջավայր և պետք է տրամադրվեն գործարկման ժամանակ, օրինակ Kubernetes ConfigMap-ի միջոցով:
Հավելվածը կարող է ներառել մի քանի կոնտեյներացված բաղադրիչներ, օրինակ՝ առանձին DBMS կոնտեյներ կոնտեյներացված վեբ հավելվածում: S-CP սկզբունքի համաձայն, այս բեռնարկղերը չպետք է միավորվեն մեկի մեջ, այլ պետք է այնպես արվեն, որ DBMS կոնտեյները պարունակի այն ամենը, ինչ անհրաժեշտ է տվյալների բազայի աշխատանքի համար, իսկ վեբ հավելվածի կոնտեյները պարունակում է այն ամենը, ինչ անհրաժեշտ է վեբի գործարկման համար: հավելվածը, նույն վեբ սերվերը: Արդյունքում, գործարկման ժամանակ վեբ հավելվածի կոնտեյները կախված կլինի DBMS կոնտեյներից և անհրաժեշտության դեպքում հասանելի կլինի դրան:
Runtime Confinement Principle (RCP)
S-CP սկզբունքը սահմանում է, թե ինչպես պետք է կառուցվի կոնտեյները և ինչ պետք է պարունակի պատկերի երկուական տարբերակը: Բայց կոնտեյները պարզապես «սև արկղ» չէ, որն ունի միայն մեկ հատկանիշ՝ ֆայլի չափը: Կատարման ընթացքում կոնտեյները ստանում է այլ չափսեր՝ օգտագործվող հիշողության ծավալը, պրոցեսորի ժամանակը և համակարգի այլ ռեսուրսները:
Եվ այստեղ օգտակար է RCP սկզբունքը, ըստ որի կոնտեյները պետք է գլխատել համակարգի ռեսուրսների իր պահանջները և դրանք փոխանցել հարթակ: Յուրաքանչյուր կոնտեյների ռեսուրսների պրոֆիլներով (որքան պրոցեսոր, հիշողություն, ցանց և սկավառակի ռեսուրսներ է անհրաժեշտ), հարթակը կարող է օպտիմալ կերպով կատարել պլանավորում և ավտոմատ մասշտաբավորում, կառավարել ՏՏ հզորությունը և պահպանել բեռնարկղերի SLA մակարդակները:
Բացի կոնտեյների ռեսուրսների պահանջները բավարարելուց, նաև կարևոր է, որ հավելվածը դուրս չգա իր սահմաններից: Հակառակ դեպքում, երբ ռեսուրսների պակաս է առաջանում, հարթակն ավելի հավանական է, որ այն ներառի այն հավելվածների ցանկում, որոնք պետք է դադարեցվեն կամ տեղափոխվեն:
Երբ մենք խոսում ենք ամպային առաջին լինելու մասին, մենք խոսում ենք մեր աշխատանքի ձևի մասին:
Վերևում մենք ձևակերպեցինք մի շարք ընդհանուր սկզբունքներ, որոնք մեթոդաբանական հիմք են դնում ամպային միջավայրերի համար բարձրորակ կոնտեյներային հավելվածներ ստեղծելու համար:
Նկատի ունեցեք, որ բացի այս ընդհանուր սկզբունքներից, ձեզ անհրաժեշտ կլինեն նաև տարաների հետ աշխատելու լրացուցիչ առաջադեմ մեթոդներ և տեխնիկա: Բացի այդ, մենք ունենք մի քանի կարճ առաջարկություններ, որոնք ավելի կոնկրետ են և պետք է կիրառվեն (կամ չկիրառվեն) կախված իրավիճակից.
- Փորձեք նվազեցնել պատկերների չափը. ջնջեք ժամանակավոր ֆայլերը և մի տեղադրեք ավելորդ փաթեթներ. որքան փոքր է կոնտեյների չափը, այնքան ավելի արագ է այն հավաքվում և պատճենվում թիրախային հոսթին ցանցի միջոցով:
- Կենտրոնացեք կամայական User-ID-ների վրա. մի օգտագործեք sudo հրամանը կամ որևէ հատուկ userid ձեր բեռնարկղերը գործարկելու համար:
- Նշեք կարևոր նավահանգիստները. դուք կարող եք սահմանել նավահանգիստների համարները գործարկման ժամանակ, բայց ավելի լավ է դրանք նշել՝ օգտագործելով EXPOSE հրամանը. դա կհեշտացնի այլ մարդկանց և ծրագրերի համար ձեր պատկերներն օգտագործելը:
- Պահպանեք մշտական տվյալները ծավալների վերաբերյալ. Տվյալները, որոնք պետք է մնան բեռնարկղի ոչնչացումից հետո, պետք է գրվեն հատորների վրա:
- Գրեք պատկերների մետատվյալներ. պիտակները, պիտակները և ծանոթագրությունները հեշտացնում են պատկերների օգտագործումը. մյուս մշակողները շնորհակալություն կհայտնեն ձեզ:
- Համաժամացնել հաղորդավարը և պատկերները. որոշ կոնտեյներային հավելվածներ պահանջում են, որ կոնտեյները համաժամացվի հյուրընկալողի հետ որոշակի ատրիբուտներով, ինչպիսիք են ժամանակը կամ մեքենայի ID-ն:
- Եզրափակելով՝ մենք կիսվում ենք ձևանմուշներով և լավագույն փորձով, որոնք կօգնեն ձեզ ավելի արդյունավետ իրականացնել վերը թվարկված սկզբունքները.
հունիսի 11-ին ժամը 11.00-ին
Ինչ դուք կսովորեք.
- Անփոփոխ Red Hat Enterprise Linux CoreOS
- OpenShift ծառայության ցանց
- Օպերատորի շրջանակ
- Knative շրջանակ
Source: www.habr.com