Ժամանակակից ենթակառուցվածքներ. խնդիրներ և հեռանկարներ

Մայիսի վերջին մենք թեմայի շուրջ առցանց հանդիպում է անցկացրել «Ժամանակակից ենթակառուցվածքներ և բեռնարկղեր. խնդիրներ և հեռանկարներ». Մենք խոսեցինք կոնտեյներների, Kubernetes-ի և սկզբունքորեն նվագախմբի մասին, ենթակառուցվածքների ընտրության չափանիշների և շատ ավելին: Մասնակիցները կիսվեցին դեպքերով իրենց սեփական պրակտիկայից:

Մասնակիցները.

• Եվգենի Պոտապով, ITSumma-ի գործադիր տնօրեն. Նրա հաճախորդների կեսից ավելին կա՛մ արդեն տեղափոխվում է, կա՛մ ցանկանում է անցնել Kubernetes-ին:
• Դմիտրի Ստոլյարով, CTO «Flant». Ունի կոնտեյներային համակարգերի հետ աշխատելու 10+ տարվա փորձ։
• Դենիս Ռեմչուկով (նույն ինքը՝ Էրիկ Օլդման), COO argotech.io, նախկին ՌԱՕ ԵԷՍ. Նա խոստացավ խոսել «արյունոտ» ձեռնարկության դեպքերի մասին։
• Անդրեյ Ֆեդորովսկի, CTO «News360.com»Մեկ այլ խաղացողի կողմից ընկերությունը գնելուց հետո նա պատասխանատու է մի շարք ML և AI նախագծերի և ենթակառուցվածքների համար:
• Իվան Կրուգլով, համակարգերի ինժեներ, նախկին Booking.com.Նույն մարդը, ով իր ձեռքով շատ բան արեց Կուբերնետեսի հետ։

Թեմաներ:

• Մասնակիցների պատկերացումները կոնտեյներների և նվագախմբի մասին (Docker, Kubernetes և այլն); այն, ինչ փորձարկվեց կամ վերլուծվեց:
• Դեպք. Ընկերությունը տարիներ շարունակ ենթակառուցվածքի զարգացման ծրագիր է կառուցում: Ինչպե՞ս է որոշում կայացվում՝ կառուցել (կամ տեղափոխել ներկայիս) ենթակառուցվածքը կոնտեյներներ և Kuber, թե ոչ:
• Խնդիրներ ամպային մայրենի աշխարհում, ինչ է պակասում, եկեք պատկերացնենք, թե ինչ կլինի վաղը:

Հետաքրքիր քննարկում ծավալվեց, մասնակիցների կարծիքներն այնքան տարբեր էին և այնքան մեկնաբանությունների տեղիք տվեցին, որ ուզում եմ կիսվել ձեզ հետ։ Ուտել երեք ժամ տեսանյութ, իսկ ստորև ներկայացնում ենք քննարկման ամփոփագիրը։

Արդյո՞ք Kubernetes-ը արդեն ստանդարտ կամ հիանալի մարքեթինգ է:

«Մենք եկանք դրան (Kubernetes. - Ed.), երբ դեռ ոչ ոք չգիտեր դրա մասին: Մենք եկանք նրա մոտ նույնիսկ այն ժամանակ, երբ նա չկար։ Մենք դա նախկինում էինք ուզում» - Դմիտրի Ստոլյարով

Լուսանկարը՝ Reddit.com-ից

5-10 տարի առաջ հսկայական թվով գործիքներ կային, և չկար մեկ ստանդարտ: Յուրաքանչյուր վեց ամիսը մեկ նոր ապրանք էր հայտնվում, կամ նույնիսկ մեկից ավելի: Սկզբում թափառաշրջիկ, հետո աղ, խոհարար, տիկնիկ,... «և վեց ամիսը մեկ վերակառուցում եք ձեր ենթակառուցվածքը: Դուք ունեք հինգ ադմինիստրատորներ, որոնք անընդհատ զբաղված են կոնֆիգուրացիաների վերաշարադրմամբ», - հիշում է Անդրեյ Ֆեդորովսկին: Նա կարծում է, որ Docker-ը և Kubernetes-ը «դուրս են քաշել» մնացածներին: Docker-ը դարձել է ստանդարտ վերջին հինգ տարում, Kubernetes-ը՝ վերջին երկու տարում: Եվ դա լավ է ոլորտի համար:.

Դմիտրի Ստոլյարովն ու նրա թիմը սիրում են Կուբերին։ Նրանք ցանկանում էին նման գործիք ստեղծել նախքան դրա հայտնվելը, և եկան դրան, երբ ոչ ոք չգիտեր դրա մասին: Ներկայումս, հարմարության նկատառումներից ելնելով, հաճախորդ չեն վերցնում, եթե հասկանում են, որ նրա հետ չեն իրականացնելու Kubernetes-ը։ Միևնույն ժամանակ, ըստ Դմիտրիի, ընկերությունն ունի «բազմաթիվ հսկա հաջողության պատմություններ սարսափելի ժառանգությունը վերականգնելու վերաբերյալ»:

Kubernetes-ը ոչ միայն կոնտեյներների կազմակերպում է, այլ նաև կոնֆիգուրացիայի կառավարման համակարգ՝ զարգացած API-ով, ցանցային բաղադրիչով, L3 հավասարակշռող և Ingress կարգավորիչներով, ինչը համեմատաբար հեշտացնում է ռեսուրսների, մասշտաբների և ենթակառուցվածքի ստորին շերտերից վերացական կառավարումը:

Ցավոք սրտի, մեր կյանքում մենք պետք է վճարենք ամեն ինչի համար։ Եվ այս հարկը մեծ է, հատկապես, եթե խոսենք զարգացած ենթակառուցվածքով ընկերության Kubernetes-ին անցնելու մասին, ինչպես կարծում է Իվան Կրուգլովը։ Նա կարող էր ազատորեն աշխատել ինչպես ավանդական ենթակառուցվածք ունեցող ընկերությունում, այնպես էլ Կուբերի հետ։ Հիմնական բանը ընկերության և շուկայի բնութագրերը հասկանալն է: Բայց, օրինակ, Եվգենի Պոտապովի համար, ով Կուբերնետեսը ընդհանրացնում է կոնտեյներային նվագախմբային ցանկացած գործիքի, նման հարց չի առաջանում։

Եվգենին անալոգիա է արել 1990-ականների իրավիճակի հետ, երբ օբյեկտի վրա հիմնված ծրագրավորումը հայտնվեց որպես բարդ հավելվածների ծրագրավորման միջոց։ Այդ ժամանակ բանավեճը շարունակվեց, և նոր գործիքներ հայտնվեցին OOP-ին աջակցելու համար: Հետո ի հայտ եկան միկրոսերվիսները՝ որպես մոնոլիտ հայեցակարգից հեռանալու միջոց։ Սա իր հերթին հանգեցրեց բեռնարկղերի և բեռնարկղերի կառավարման գործիքների առաջացմանը: «Կարծում եմ, որ մենք շուտով կգանք մի ժամանակ, երբ հարց չի լինի, թե արժե՞ փոքր միկրոսերվիսային հավելված գրել, այն լռելյայն կգրվի որպես միկրոսերվիս»,- կարծում է նա։ Նմանապես, Docker-ը և Kubernetes-ը ի վերջո կդառնան ստանդարտ լուծում՝ առանց ընտրության անհրաժեշտության:

Քաղաքացիություն չունեցող անձանց տվյալների բազաների խնդիրը

Photo by Twitter՝ @jankolario Unsplash-ում

Ներկայումս Kubernetes-ում տվյալների բազաները գործարկելու բազմաթիվ բաղադրատոմսեր կան: Նույնիսկ ինչպես կարելի է առանձնացնել I/O սկավառակի հետ աշխատող մասը, պայմանականորեն, տվյալների բազայի կիրառական մասից։ Հնարավո՞ր է, որ ապագայում տվյալների շտեմարաններն այնքան փոխվեն, որ առաքվեն տուփով, որտեղ մի մասը կկազմակերպվի Docker-ի և Kubernetes-ի միջոցով, իսկ ենթակառուցվածքի մեկ այլ մասում՝ առանձին ծրագրային ապահովման միջոցով, տրամադրվի պահեստային մասը։ ? Հիմքերը որպես ապրանք կփոխվե՞ն։

Այս նկարագրությունը նման է հերթերի կառավարմանը, սակայն ավանդական տվյալների բազաներում տեղեկատվության հուսալիության և համաժամացման պահանջները շատ ավելի բարձր են, կարծում է Անդրեյը: Քեշի հարվածների հարաբերակցությունը նորմալ տվյալների բազաներում մնում է 99%: Եթե ​​աշխատողը իջնում ​​է, գործարկվում է նորը, և քեշը «տաքանում է» զրոյից: Քանի դեռ քեշը չի տաքացել, աշխատողը դանդաղ է աշխատում, ինչը նշանակում է, որ այն չի կարող բեռնվել օգտագործողի բեռնվածությամբ: Մինչ օգտվողի բեռնվածություն չկա, քեշը չի տաքանում: Դա արատավոր շրջան է:

Դմիտրին սկզբունքորեն համաձայն չէ՝ քվորումներն ու շարդինգը լուծում են խնդիրը: Բայց Անդրեյը պնդում է, որ լուծումը բոլորին հարմար չէ։ Որոշ իրավիճակներում քվորումը հարմար է, բայց դա լրացուցիչ բեռ է դնում ցանցի վրա: NoSQL տվյալների բազան հարմար չէ բոլոր դեպքերում:

Հանդիպման մասնակիցները բաժանվել են երկու ճամբարի.

Դենիսը և Անդրեյը պնդում են, որ այն ամենը, ինչ գրված է սկավառակի վրա՝ տվյալների բազաներ և այլն, անհնար է անել ներկայիս Kuber էկոհամակարգում: Kubernetes-ում անհնար է պահպանել արտադրության տվյալների ամբողջականությունն ու հետևողականությունը: Սա հիմնարար հատկանիշ է: Լուծում` հիբրիդային ենթակառուցվածք:

Նույնիսկ ժամանակակից ամպային բնիկ տվյալների բազաները, ինչպիսիք են MongoDB-ն և Cassandra-ն, կամ հաղորդագրությունների հերթերը, ինչպիսիք են Kafka-ն կամ RabbitMQ-ը, պահանջում են մշտական ​​տվյալների պահեստներ Kubernetes-ից դուրս:

Եվգենին առարկում է. «Կուբերայի բազաները մերձռուսական կամ ձեռնարկատիրական վնասվածք են, ինչը կապված է այն փաստի հետ, որ Ռուսաստանում ամպերի ընդունում չկա»: Արևմուտքում փոքր կամ միջին ընկերությունները Cloud են: Amazon RDS տվյալների շտեմարաններն ավելի հեշտ են օգտագործել, քան Kubernetes-ի հետ աշխատելը: Ռուսաստանում նրանք օգտագործում են Kuber-ը «in-premise» և տեղափոխում են բազաներ, երբ փորձում են ազատվել կենդանաբանական այգուց:

Դմիտրին նաև չհամաձայնեց այն պնդման հետ, որ Kubernetes-ում տվյալների շտեմարաններ չեն կարող պահպանվել. «Base-ը տարբերվում է բազայից: Եվ եթե դուք մղում եք հսկա հարաբերական տվյալների բազա, ապա ոչ մի դեպքում: Եթե ​​ինչ-որ փոքրիկ ու ամպամած բնիկ բան հրես, որը մտավոր պատրաստված է կիսամյակային կյանքի համար, ամեն ինչ լավ կլինի»։ Դմիտրին նշեց նաև, որ տվյալների բազայի կառավարման գործիքները պատրաստ չեն ոչ Docker-ի, ոչ Kuber-ի համար, ուստի մեծ դժվարություններ են առաջանում։

Իվանն իր հերթին վստահ է, որ եթե նույնիսկ վերացվենք պետական ​​և քաղաքացիություն չունեցող հասկացություններից, Կուբերնետեսում ձեռնարկությունների լուծումների էկոհամակարգը դեռ պատրաստ չէ։ Կուբերի հետ դժվար է պահպանել օրենսդրական և կարգավորող պահանջները: Օրինակ, անհնար է ինքնության ապահովման լուծում ստեղծել, որտեղ սերվերի նույնականացման խիստ երաշխիքներ են պահանջվում, ընդհուպ մինչև սերվերների մեջ տեղադրված սարքաշարը: Այս ոլորտը զարգանում է, բայց լուծում դեռ չկա։
Մասնակիցները չեն կարողացել համաձայնության գալ, ուստի այս մասով եզրակացություններ չեն արվելու։ Բերենք մի քանի գործնական օրինակ։

Դեպք 1. «Մեգակարգավորիչի» կիբերանվտանգություն՝ Կուբերայից դուրս գտնվող բազաներով

Զարգացած կիբերանվտանգության համակարգի դեպքում կոնտեյներների և նվագախմբի օգտագործումը հնարավորություն է տալիս պայքարել հարձակումների և ներխուժումների դեմ: Օրինակ, մեկ մեգակարգավորիչում Դենիսը և նրա թիմը ներդրեցին նվագախմբի համակցությունը վերապատրաստված SIEM ծառայության հետ, որը վերլուծում է տեղեկամատյանները իրական ժամանակում և որոշում հարձակման, հակերության կամ ձախողման գործընթացը: Հարձակման, ինչ-որ բան տեղադրելու փորձի դեպքում կամ փրկագին վիրուսի ներխուժման դեպքում այն ​​նվագախմբի միջոցով վերցնում է հավելվածներով բեռնարկղերը ավելի արագ, քան դրանք վարակվում են, կամ ավելի արագ, քան հարձակվողը հարձակվում է դրանց վրա:

Դեպք 2. Booking.com-ի տվյալների բազաների մասնակի տեղափոխում Kubernetes

Booking.com-ում հիմնական տվյալների բազան MySQL-ն է՝ ասինխրոն կրկնօրինակմամբ. կա վարպետ և ստրուկների մի ամբողջ հիերարխիա: Այն պահին, երբ Իվանը լքեց ընկերությունը, սկսվեց ստրուկների տեղափոխման նախագիծը, որոնք կարող էին «գնդակահարվել» որոշակի վնասով:

Բացի հիմնական բազայից, կա Կասանդրայի ինստալացիա՝ ինքնուրույն գրված նվագախմբով, որը գրվել է դեռևս Կուբերի հիմնական հոսք մտնելուց առաջ։ Այս առումով խնդիրներ չկան, բայց դա համառ է տեղական SSD-ների վրա: Հեռավոր պահեստավորումը, նույնիսկ նույն տվյալների կենտրոնում, չի օգտագործվում բարձր հետաձգման խնդրի պատճառով:

Տվյալների բազաների երրորդ դասը Booking.com որոնման ծառայությունն է, որտեղ յուրաքանչյուր սպասարկման հանգույց տվյալների բազա է։ Որոնման ծառայությունը Kuber-ին փոխանցելու փորձերը ձախողվեցին, քանի որ յուրաքանչյուր հանգույց ունի 60-80 ԳԲ տեղական պահեստ, որը դժվար է «բարձրացնել» և «տաքացնել»:

Արդյունքում որոնողական համակարգը չի փոխանցվել Kubernetes-ին, իսկ Իվանը չի կարծում, որ մոտ ապագայում նոր փորձեր կլինեն։ MySQL տվյալների բազան կիսով չափ փոխանցվեց. միայն ստրուկներ, որոնք չեն վախենում «կրակվելուց»: Կասանդրան հիանալի տեղավորվել է:

Ենթակառուցվածքների ընտրությունը որպես խնդիր՝ առանց ընդհանուր լուծման

Photo by Մանուել Գեյսինգերը Pexels-ից

Ասենք՝ ունենք նոր ընկերություն, կամ ընկերություն, որտեղ ենթակառուցվածքների մի մասը կառուցված է հին ձևով։ Տարիներ շարունակ ենթակառուցվածքների զարգացման ծրագիր է կառուցում։ Ինչպե՞ս է որոշում կայացվում՝ կոնտեյներների և Kuber-ի վրա ենթակառուցվածք կառուցել, թե ոչ։

Այն ընկերությունները, որոնք պայքարում են նանվայրկյանների համար, դուրս են մնում քննարկումից։ Առողջ պահպանողականությունն արդյունք է տալիս հուսալիության տեսանկյունից, սակայն դեռ կան ընկերություններ, որոնք պետք է դիտարկեն նոր մոտեցումներ:

Իվան. «Ես հիմա հաստատ ընկերություն կհիմնեի ամպի վրա, պարզապես այն պատճառով, որ այն ավելի արագ է», թեև պարտադիր չէ, որ ավելի էժան: Վենչուրային կապիտալիզմի զարգացման հետ մեկտեղ ստարտափները փողի հետ կապված մեծ խնդիրներ չունեն, և հիմնական խնդիրը շուկան նվաճելն է։

Իվանն այն կարծիքին է, որ ներկայիս ենթակառուցվածքի զարգացումը ընտրության չափանիշ է. Եթե ​​նախկինում լուրջ ներդրում է եղել, և այն աշխատում է, ապա դա նորից անելն իմաստ չունի։ Եթե ​​ենթակառուցվածքը զարգացած չէ, և խնդիրներ կան գործիքների, անվտանգության և մոնիտորինգի հետ, ապա իմաստ ունի նայել բաշխված ենթակառուցվածքին:

Հարկը պետք է վճարվի ամեն դեպքում, և Իվանը կվճարեր նրան, ով թույլ էր տալիս հետագայում ավելի քիչ վճարել։ «Որովհետև պարզապես այն պատճառով, որ ես նստում եմ այն ​​գնացքը, որով ուրիշներն են շարժվում, ես շատ ավելի հեռու եմ ճանապարհորդելու, քան եթե նստեմ մեկ այլ գնացքում, որի մեջ ես ինքս պետք է վառելիք լցնեմ։- ասում է Իվանը: Երբ ընկերությունը նոր է, իսկ հետաձգման պահանջները տասնյակ միլիվայրկյաններ են, ապա Իվանը կնայեր այն «օպերատորներին», որոնց մեջ այսօր «փաթաթված» են դասական տվյալների բազաները: Նրանք բարձրացնում են կրկնօրինակման շղթա, որն ինքնին անջատվում է ձախողման դեպքում և այլն...

Մի քանի սերվեր ունեցող փոքր ընկերության համար Kubera-ն իմաստ չունի»,- ասում է Անդրեյը: Բայց եթե այն նախատեսում է աճել մինչև հարյուրավոր կամ ավելի սերվերներ, ապա դրա կարիքն ունի ավտոմատացում և ռեսուրսների կառավարման համակարգ: Դեպքերի 90%-ը արժե ծախսել: Ընդ որում, անկախ բեռի և ռեսուրսների մակարդակից։ Բոլորի համար՝ սկսած ստարտափներից մինչև միլիոնավոր լսարան ունեցող խոշոր ընկերություններ, իմաստ ունի աստիճանաբար նայել դեպի կոնտեյներային նվագախմբային արտադրանք: «Այո, սա իսկապես ապագան է», - վստահ է Անդրեյը:

Դենիսը նախանշեց երկու հիմնական չափանիշ. լայնածավալություն և շահագործման կայունություն: Նա կընտրի այն գործիքները, որոնք լավագույնս համապատասխանում են առաջադրանքին: «Դա կարող է լինել ձեր ծնկների վրա հավաքված անանուն, և դրա վրա կա Nutanix Community Edition: Սա կարող է լինել երկրորդ տող Kuber-ի վրա հավելվածի տեսքով՝ հետին մասում գտնվող տվյալների բազայով, որը կրկնօրինակված է և ունի RTO և RPO պարամետրեր» (վերականգնման ժամանակ/կետ նպատակներ. մոտ.).

Եվգենին հայտնաբերել է անձնակազմի հետ կապված հնարավոր խնդիր. Այս պահին շուկայում չկան շատ բարձր որակավորում ունեցող մասնագետներ, ովքեր հասկանում են «աղիքները»: Իսկապես, եթե ընտրված տեխնոլոգիան հին է, ապա դժվար է աշխատանքի ընդունել մեկին, բացի միջին տարիքի մարդկանցից, ովքեր ձանձրացել են և հոգնել կյանքից։ Թեև մյուս մասնակիցները կարծում են, որ սա կադրերի պատրաստման խնդիր է։
Եթե ​​ընտրության հարցը դնենք՝ Հանրային ամպում փոքր ընկերություն բացել՝ Amazon RDS-ի տվյալների բազաներով կամ «հաստատված»՝ Kubernetes-ի տվյալների բազաներով, ապա, չնայած որոշ թերություններին, Amazon RDS-ը դարձավ մասնակիցների ընտրությունը:

Քանի որ հանդիպման ունկնդիրների մեծ մասը «արյունոտ» ձեռնարկությունից չէ, ուրեմն բաշխված լուծումներն այն են, ինչին մենք պետք է ձգտենք: Տվյալների պահպանման համակարգերը պետք է լինեն բաշխված, հուսալի և ստեղծեն ուշացում, որը չափվում է միլիվայրկյաններով, առավելագույնը տասնյակներով:- ամփոփեց Անդրեյը:

Kubernetes-ի օգտագործման գնահատում

Լսող Անտոն Ժբանկովը թակարդի հարց ուղղեց Kubernetes-ի ապոլոգետներին. ինչպե՞ս եք ընտրել և իրականացրել տեխնիկատնտեսական հիմնավորումը: Ինչու՞ Kubernetes, ինչու ոչ, օրինակ, վիրտուալ մեքենաներ:

Photo by Տատյանա Էրեմինան Unsplash-ում

Դմիտրին և Իվանը պատասխանեցին դրան. Երկու դեպքում էլ փորձության և սխալի միջոցով կայացվել է որոշումների հաջորդականություն, որի արդյունքում երկու մասնակիցներն էլ ժամանել են Կուբերնետես։ Այժմ բիզնեսները սկսում են ինքնուրույն մշակել ծրագրակազմ, որն իմաստ ունի փոխանցել Kuber-ին: Մենք չենք խոսում դասական երրորդ կողմի համակարգերի մասին, ինչպիսին է 1C-ը: Kubernetes-ը օգնում է, երբ մշակողները պետք է արագ թողարկեն թողարկումները՝ անդադար շարունակական բարելավմամբ:

Անդրեյի թիմը փորձել է վիրտուալ մեքենաների վրա հիմնված մասշտաբային կլաստեր ստեղծել։ Հանգույցները ընկնում էին դոմինոյի նման, ինչը երբեմն հանգեցնում էր կլաստերի փլուզմանը: «Տեսականորեն, դուք կարող եք ավարտել այն և աջակցել ձեր ձեռքերով, բայց դա հոգնեցուցիչ է: Եվ եթե շուկայում կա լուծում, որը թույլ է տալիս աշխատել առանց տուփի, ապա մենք ուրախ ենք գնալ դրան: Եվ արդյունքում մենք փոխվեցինք»,- ասում է Անդրեյը։

Նման վերլուծության և հաշվարկի ստանդարտներ կան, բայց ոչ ոք չի կարող ասել, թե որքանով են դրանք ճիշտ գործող իրական սարքաշարի վրա: Հաշվարկների համար կարևոր է նաև հասկանալ յուրաքանչյուր գործիք և էկոհամակարգ, բայց դա հնարավոր չէ:

Ինչ է մեզ սպասում

Photo by Դրյու Բիմերը Unsplash-ի վրա

Քանի որ տեխնոլոգիան զարգանում է, ավելի ու ավելի շատ տարբեր կտորներ են հայտնվում, և հետո փուլային անցում է տեղի ունենում, հայտնվում է մի վաճառող, ով այնքան խմոր է սպանել, որպեսզի ամեն ինչ միավորվի մեկ գործիքի մեջ:

Ի՞նչ եք կարծում, կգա՞ ժամանակ, երբ Ubuntu-ի նման գործիք կլինի Linux աշխարհի համար: Թերևս մեկ կոնտեյներացման և նվագախմբի գործիք կներառի Kuber-ը: Դա կհեշտացնի տեղում ամպեր կառուցելը:

Պատասխանը տվել է Իվանը. «Google-ն այժմ կառուցում է Anthos-ը, սա նրանց փաթեթավորված առաջարկն է, որը տեղակայում է ամպը և ներառում է Kuber, Service Mesh, մոնիտորինգ՝ ամբողջ սարքավորումը, որն անհրաժեշտ է ներքին միկրոծառայությունների համար»: Մենք գրեթե ապագայում ենք»:

Դենիսը նաև նշել է Nutanix-ը և VMWare-ը vRealize Suite արտադրանքի հետ, որոնք կարող են հաղթահարել նմանատիպ առաջադրանքը առանց կոնտեյներացման:

Դմիտրին կիսեց իր կարծիքը, որ «ցավի» նվազեցումը և հարկերի նվազեցումը երկու ոլորտներ են, որտեղ կարելի է բարելավումներ ակնկալել։

Քննարկումն ամփոփելու համար մենք առանձնացնում ենք ժամանակակից ենթակառուցվածքների հետևյալ խնդիրները.

• Երեք մասնակից անմիջապես հայտնաբերեցին պետականության հետ կապված խնդիր:
• Անվտանգության աջակցության տարբեր խնդիրներ, ներառյալ հավանականությունը, որ Docker-ը կհայտնվի Python-ի բազմաթիվ տարբերակների, հավելվածի սերվերների և բաղադրիչների հետ:
  Գերծախսեր, որոնք ավելի լավ է քննարկել առանձին հանդիպման ժամանակ։
  Ուսուցման մարտահրավերը, որպես նվագախումբ, բարդ էկոհամակարգ է:
  Արդյունաբերության մեջ տարածված խնդիր է գործիքների սխալ օգտագործումը:

  Մնացած եզրակացությունները կախված են ձեզանից: Դեռևս զգացողություն կա, որ Docker+Kubernetes համակցության համար հեշտ չէ դառնալ համակարգի «կենտրոնական» մաս։ Օրինակ, օպերացիոն համակարգերը տեղադրվում են նախ սարքաշարի վրա, ինչը չի կարելի ասել կոնտեյների և նվագախմբի մասին: Միգուցե ապագայում օպերացիոն համակարգերը և կոնտեյներները կմիավորվեն ամպային կառավարման ծրագրային ապահովման հետ:

  
  Photo by Gabriel Santos Fotografia Pexels-ից

  Օգտվելով առիթից՝ ցանկանում եմ ողջունել մայրիկիս և հիշեցնել, որ մենք ֆեյսբուքյան խումբ ունենք «ՏՏ խոշոր նախագծերի կառավարում և զարգացում»., ալիք @feedmeto տարբեր տեխնոլոգիական բլոգներից հետաքրքիր հրապարակումներով: Եվ իմ ալիքը @rybakalexey, որտեղ ես խոսում եմ ապրանքային ընկերություններում զարգացման կառավարման մասին:

Source: www.habr.com