Սպասման մեջ Վիտալի Խաբարով հարցազրույց Դմիտրի Ստոլյարով (Ֆլանտ ընկերության տեխնիկական տնօրեն և համահիմնադիր։ Վիտալին Դմիտրիին հարցրեց, թե ինչ է անում Ֆլանտը, Կուբերնետեսի, էկոհամակարգի զարգացման, աջակցության մասին: Մենք քննարկեցինք, թե ինչու է Kubernetes-ը անհրաժեշտ և արդյոք այն ընդհանրապես անհրաժեշտ է: Եվ նաև միկրոծառայությունների, Amazon AWS-ի, DevOps-ի «Ես բախտավոր կլինեմ» մոտեցման, Kubernetes-ի ապագայի, ինչու, երբ և ինչպես է այն գրավելու աշխարհը, DevOps-ի հեռանկարները և ինչին պետք է պատրաստվեն ինժեներները: լուսավոր և մոտ ապագա՝ պարզեցմամբ և նեյրոնային ցանցերով:
լսել որպես փոդքաստ DevOps Deflop-ում՝ ռուսալեզու փոդքասթ DevOps-ի մասին, իսկ ստորև՝ տեքստային տարբերակը:
Այստեղ և ստորև նա հարցեր է տալիս ինժեներ Express42-ից:
«Ֆլանտի» մասին
-Բարև Դիմա: Դուք տեխնիկական տնօրենն եք»», և նաև դրա հիմնադիրը։ Խնդրում եմ, ասեք մեզ, թե ինչ է անում ընկերությունը և ինչ եք դուք դրանում:
DmitryԱրտաքինից թվում է, թե մենք այն տղաներն ենք, ովքեր շրջում են՝ տեղադրելով Kubernetes-ը բոլորի համար և ինչ-որ բան անում դրա հետ: Բայց դա ճիշտ չէ: Մենք սկսել ենք որպես ընկերություն, որը զբաղվում է Linux-ով, բայց շատ երկար ժամանակ մեր հիմնական գործունեությունը եղել է արտադրական և մեծ բեռնվածությամբ նախագծերի սպասարկումը: Սովորաբար մենք ամբողջ ենթակառուցվածքը կառուցում ենք զրոյից, իսկ հետո երկար, երկար ժամանակ պատասխանատու ենք դրա համար: Ուստի «Ֆլանտը» անում է հիմնական գործը, որի համար գումար է ստանում պատասխանատվություն վերցնելը և բանտապահ արտադրություն իրականացնելը.
Ես՝ որպես տեխնիկական տնօրեն և ընկերության հիմնադիրներից մեկը, ամբողջ օր ու գիշեր փորձում եմ պարզել, թե ինչպես բարձրացնել արտադրության մատչելիությունը, պարզեցնել դրա գործունեությունը, հեշտացնել ադմինիստրատորների կյանքը, իսկ մշակողների կյանքը՝ ավելի հաճելի։ .
Kubernetes-ի մասին
— Վերջերս ես շատ զեկույցներ եմ տեսնում Ֆլանտից և Կուբերնետեսի մասին. Ինչպե՞ս հասաք դրան:
DmitryԵս արդեն բազմիցս խոսել եմ այս մասին, բայց ընդհանրապես դեմ չեմ կրկնել: Կարծում եմ, որ ճիշտ է այս թեման կրկնելը, քանի որ պատճառի և հետևանքի շփոթություն կա։
Մեզ իսկապես գործիք էր պետք: Բազմաթիվ խնդիրների առաջ կանգնեցինք, պայքարեցինք, տարբեր հենակներով հաղթահարեցինք դրանք ու զգացինք գործիքի կարիքը։ Մենք անցանք բազմաթիվ տարբեր տարբերակների միջով, կառուցեցինք մեր սեփական հեծանիվները և փորձ ձեռք բերեցինք: Աստիճանաբար մենք հասանք այն կետին, երբ սկսեցինք օգտագործել Docker-ը գրեթե հենց այն հայտնվեց՝ մոտ 2013թ. Դրա հայտնվելու պահին մենք արդեն մեծ փորձ ունեինք բեռնարկղերի հետ, մենք արդեն գրել էինք «Docker»-ի անալոգը՝ մեր սեփական հենակներից մի քանիսը Python-ում: Docker-ի գալուստով հնարավոր դարձավ դուրս նետել հենակները և օգտագործել հուսալի և համայնքի կողմից աջակցվող լուծում:
Kubernetes-ի դեպքում պատմությունը նման է. Այն պահին, երբ այն սկսեց թափ հավաքել, մեզ համար սա 1.2 տարբերակն է, մենք արդեն ունեինք մի փունջ հենակներ և՛ Shell-ի, և՛ Chef-ի վրա, որոնք ինչ-որ կերպ փորձում էինք կազմակերպել Docker-ի հետ: Մենք լրջորեն նայում էինք Rancher-ին և տարբեր այլ լուծումների, բայց հետո հայտնվեց Kubernetes-ը, որտեղ ամեն ինչ իրականացվում է ճիշտ այնպես, ինչպես մենք կանեինք կամ նույնիսկ ավելի լավ: Բողոքելու բան չկա։
Այո, այստեղ ինչ-որ անկատարություն կա, այնտեղ ինչ-որ անկատարություն կա - անկատարությունները շատ են, իսկ 1.2-ն ընդհանրապես սարսափելի է, բայց... Kubernetes-ը նման է կառուցվող շենքին. որ թույն կլինի։ Եթե շենքն այժմ ունի հիմք և երկու հարկ, ապա հասկանում եք, որ ավելի լավ է դեռ չտեղափոխվել, բայց ծրագրային ապահովման հետ կապված նման խնդիրներ չկան՝ արդեն կարող եք օգտագործել այն։
Մենք չենք ունեցել մի պահ, որ մտածենք Kubernetes-ի օգտագործման մասին, թե ոչ: Մենք երկար էինք սպասում դրան, երբ կհայտնվեր, և ինքներս փորձեցինք անալոգներ ստեղծել:
Kubernetes-ի մասին
— Դուք անմիջականորեն մասնակցու՞մ եք հենց Kubernetes-ի զարգացմանը:
Dmitry: Միջակ. Ավելի շուտ մենք մասնակցում ենք էկոհամակարգի զարգացմանը։ Մենք ուղարկում ենք որոշակի քանակությամբ ձգողականության հարցումներ՝ Պրոմեթևսին, տարբեր օպերատորներին, Հելմին՝ էկոհամակարգին: Ցավոք սրտի, ես ի վիճակի չեմ հետևել այն ամենին, ինչ մենք անում ենք, և ես կարող եմ սխալվել, բայց մեր միջից ոչ մի լողավազան չկա:
— Միևնույն ժամանակ, Դուք մշակում եք ձեր գործիքներից շատերը Kubernetes-ի շուրջ:
DmitryՌազմավարությունը սա է. մենք գնում ենք և դիմում ենք այն ամենին, ինչ արդեն կա: Եթե ձգման խնդրանքներն այնտեղ չեն ընդունվում, մենք ինքներս ենք դրանք պատառաքաղում և ապրում այնքան ժամանակ, մինչև որ դրանք ընդունվեն մեր կառուցվածքներով: Այնուհետև, երբ այն հասնում է վերին հոսանքին, մենք վերադառնում ենք դեպի վերին հոսանքի տարբերակ:
Օրինակ, մենք ունենք Prometheus օպերատոր, որով մենք ետ ու առաջ անցանք մեր հավաքի վերին հոսանքին, հավանաբար արդեն 5 անգամ։ Մեզ ինչ-որ հատկանիշ է պետք, մենք ուղարկել ենք ձգման հարցում, մենք պետք է այն թողարկենք վաղը, բայց մենք չենք ցանկանում սպասել, որ այն թողարկվի հոսանքին հակառակ: Համապատասխանաբար, մենք հավաքում ենք մեզ համար, գլորում մեր հավաքը մեր հատկանիշով, որը մեզ ինչ-ինչ պատճառներով անհրաժեշտ է, մեր բոլոր կլաստերների վրա: Այնուհետև, օրինակ, այն մեզ են հանձնում հոսանքին հակառակ՝ «Տղերք, եկեք դա անենք ավելի ընդհանուր գործի համար» բառերով, մենք կամ մեկ ուրիշը ավարտում ենք այն, և ժամանակի ընթացքում այն նորից միաձուլվում է:
Մենք փորձում ենք զարգացնել այն ամենը, ինչ կա. Շատ տարրեր, որոնք դեռ չկան, դեռ չեն հորինվել, կամ հորինված են, բայց ժամանակ չեն ունեցել իրագործելու՝ մենք դա անում ենք։ Եվ ոչ այն պատճառով, որ մեզ դուր է գալիս գործընթացը կամ հեծանիվ կառուցելը որպես արդյունաբերություն, այլ պարզապես այն պատճառով, որ մեզ անհրաժեշտ է այս գործիքը: Հաճախ հարց է տրվում՝ ինչո՞ւ ենք այս կամ այն բանն արել։ Պատասխանը պարզ է՝ այո, քանի որ մենք պետք է ավելի հեռու գնայինք, որոշ գործնական խնդիր լուծեինք, և մենք այն լուծեցինք այս տուլայով։
Ճանապարհը միշտ այսպիսին է.
Flanta գործիքներ
— Ես գիտեմ, որ Flant-ն այժմ ունի հավելումների օպերատորներ, shell օպերատորներ և dapp/werf գործիքներ: Ինչպես հասկանում եմ, սա նույն գործիքն է տարբեր մարմնավորումներում: Ես նաև հասկանում եմ, որ Flaunt-ում շատ ավելի տարբեր գործիքներ կան: Սա ճի՞շտ է:
DmitryՄենք շատ ավելին ունենք GitHub-ում: Ինչ ես հիմա հիշում եմ, մենք ունենք կարգավիճակի քարտեզ՝ Grafana-ի վահանակ, որին հանդիպել են բոլորը: Այն նշվում է Medium-ում Kubernetes-ի մոնիտորինգի մասին գրեթե յուրաքանչյուր երկրորդ հոդվածում։ Անհնար է հակիրճ բացատրել, թե ինչ է ստատուսի քարտեզը. դրա համար անհրաժեշտ է առանձին հոդված, բայց դա շատ օգտակար բան է ժամանակի ընթացքում կարգավիճակը մոնիտորինգի համար, քանի որ Kubernetes-ում մեզ հաճախ անհրաժեշտ է ժամանակի ընթացքում ցուցադրել կարգավիճակը: Մենք ունենք նաև LogHouse. սա մի բան է, որը հիմնված է ClickHouse-ի և սև մոգության վրա՝ Kubernetes-ում տեղեկամատյաններ հավաքելու համար:
Շատ կոմունալ ծառայություններ. Եվ դեռ ավելին կլինի, քանի որ այս տարի կթողարկվեն մի շարք ներքին լուծումներ։ Հավելվածի օպերատորի վրա հիմնված շատ մեծերից կան մի շարք հավելումներ Kubernetes-ի համար, հա, թե ինչպես ճիշտ տեղադրել sert manager՝ վկայագրերը կառավարելու գործիք, ինչպես ճիշտ տեղադրել Prometheus-ը մի շարք աքսեսուարներով. սրանք մոտ քսան տարբեր են։ Երկուական սարքեր, որոնք արտահանում են տվյալներ և ինչ-որ բան հավաքում, այս Պրոմեթևսն ունի ամենազարմանալի գրաֆիկան և ազդանշանները: Այս ամենը Kubernetes-ի հավելումների մի փունջ է, որոնք տեղադրվում են կլաստերի մեջ, և այն պարզից վերածվում է սառը, բարդ, ավտոմատ, որոնցում արդեն լուծված են բազմաթիվ խնդիրներ։ Այո, մենք շատ բան ենք անում:
Էկոհամակարգի զարգացում
«Ինձ թվում է, որ սա շատ մեծ ներդրում է այս գործիքի և դրա կիրառման մեթոդների զարգացման գործում»: Մոտավորապես կարո՞ղ եք գնահատել, թե էլ ո՞վ կարող է նույն ներդրումն ունենալ էկոհամակարգի զարգացման գործում։
Dmitry: Ռուսաստանում, մեր շուկայում գործող ընկերություններից, ոչ ոք նույնիսկ մտերիմ չէ. Իհարկե, սա ամպագոռգոռ հայտարարություն է, քանի որ կան խոշոր խաղացողներ, ինչպիսիք են Mail-ը և Yandex-ը. նրանք նույնպես ինչ-որ բան են անում Kubernetes-ի հետ, բայց նույնիսկ նրանք չեն մոտենում ամբողջ աշխարհի այն ընկերությունների ներդրմանը, որոնք մեզանից շատ ավելին են անում: Դժվար է համեմատել Flant-ին, որն ունի 80 հոգանոց անձնակազմ, և Red Hat-ին, որը միայն մեկ Kubernetes-ում ունի 300 ինժեներ, եթե չեմ սխալվում: Դժվար է համեմատել: RnD բաժնում ունենք 6 հոգի, այդ թվում՝ ես, ովքեր կտրում են մեր բոլոր գործիքները։ 6 հոգի ընդդեմ 300 Red Hat-ի ինժեների, ինչ-որ կերպ դժվար է համեմատել:
-Այնուամենայնիվ, երբ նույնիսկ այս 6 հոգին կարող են իսկապես օգտակար և օտարացնող բան անել, երբ գործնական խնդրի առաջ են կանգնել և լուծումը տալ համայնքին, հետաքրքիր դեպք։ Ես հասկանում եմ, որ խոշոր տեխնոլոգիական ընկերություններում, որտեղ նրանք ունեն իրենց սեփական Kubernetes-ի մշակման և աջակցման թիմը, սկզբունքորեն կարող են մշակվել նույն գործիքները: Սա նրանց համար օրինակ է այն բանի, թե ինչ կարելի է զարգացնել և տալ համայնքին՝ խթան հաղորդելով Kubernetes-ից օգտվող ողջ համայնքին:
DmitryՍա, հավանաբար, ինտեգրատորի առանձնահատկությունն է, նրա յուրահատկությունը։ Մենք բազմաթիվ նախագծեր ունենք և շատ տարբեր իրավիճակներ ենք տեսնում։ Մեզ համար հավելյալ արժեք ստեղծելու հիմնական միջոցը այս դեպքերը վերլուծելն է, ընդհանրություններ գտնելն ու դրանք մեզ համար հնարավորինս էժան դարձնելն է։ Մենք ակտիվորեն աշխատում ենք այս ուղղությամբ։ Ինձ համար դժվար է խոսել Ռուսաստանի և աշխարհի մասին, բայց մենք ընկերությունում ունենք մոտ 40 DevOps ինժեներ, ովքեր աշխատում են Kubernetes-ում: Չեմ կարծում, որ Ռուսաստանում կան շատ ընկերություններ, որոնք ունեն համեմատելի թվով մասնագետներ, ովքեր հասկանում են Kubernetes-ը, եթե ընդհանրապես այդպիսիք կան:
Ես ամեն ինչ հասկանում եմ DevOps ինժեներ աշխատանքի կոչման մասին, բոլորը հասկանում են ամեն ինչ և սովոր են DevOps ինժեներներին DevOps ինժեներներ անվանել, մենք դա չենք քննարկելու: Այս բոլոր 40 զարմանալի DevOps ինժեներները ամեն օր բախվում և լուծում են խնդիրների, մենք պարզապես վերլուծում ենք այս փորձը և փորձում ընդհանրացնել: Մենք հասկանում ենք, որ եթե այն մնա մեր ներսում, ապա մեկ-երկու տարի հետո գործիքն անօգուտ կլինի, քանի որ ինչ-որ տեղ համայնքում կհայտնվի պատրաստի տուլա։ Իմաստ չունի այս փորձը ներքուստ կուտակել. այն պարզապես էներգիա և ժամանակ է ծախսում dev/null-ի մեջ: Եվ մենք ընդհանրապես չենք ցավում դրա համար: Մենք մեծ հաճույքով հրապարակում ենք ամեն ինչ և հասկանում ենք, որ այն պետք է հրապարակել, զարգացնել, խթանել, առաջ մղել, որպեսզի մարդիկ օգտվեն դրանից և ավելացնեն իրենց փորձը, այնուհետև ամեն ինչ աճում և ապրում է: Հետո երկու տարի անց գործիքը չի գնում աղբարկղ։ Ցավալի չէ շարունակել ուժերը թափել, քանի որ պարզ է, որ ինչ-որ մեկը օգտագործում է ձեր գործիքը, և երկու տարի անց բոլորն օգտագործում են այն:
Սա dapp/werf-ի հետ մեր մեծ ռազմավարության մի մասն է. Չեմ հիշում, թե երբ սկսեցինք պատրաստել, կարծես 3 տարի առաջ է: Սկզբում այն հիմնականում եղել է պատյանի վրա։ Դա հայեցակարգի սուպեր ապացույց էր, մենք լուծեցինք մեր որոշակի խնդիրներ. այն աշխատեց: Բայց կեղևի հետ կապված խնդիրներ կան, այն ավելի ընդլայնելն անհնար է, կեղևի վրա ծրագրավորումը ևս մեկ խնդիր է: Մենք սովորություն ունեինք Ruby-ով գրել, համապատասխանաբար, մենք ինչ-որ բան վերափոխեցինք Ruby-ով, մշակեցինք, զարգացանք, զարգացանք և բախվեցինք այն փաստին, որ համայնքը, այն ամբոխը, որը չի ասում «մենք ուզում ենք, թե չենք ուզում, «Քիթն ուղղում է Ռուբին, որքան ծիծաղելի է դա: Մենք հասկացանք, որ այս ամենը պետք է գրենք Go-ում միայն ստուգաթերթի առաջին կետին համապատասխանելու համար. DevOps գործիքը պետք է լինի ստատիկ երկուական. Գո լինել-չլինելն այնքան էլ կարևոր չէ, բայց Go-ում գրված ստատիկ երկուականն ավելի լավ է:
Մենք ծախսեցինք մեր էներգիան, վերաշարադրեցինք dapp-ը Go-ում և այն անվանեցինք werf: Dapp-ն այլևս չի աջակցվում, մշակված չէ, աշխատում է որոշ վերջին տարբերակով, բայց կա բացարձակ թարմացման ճանապարհ դեպի վերև, և դուք կարող եք հետևել դրան:
Ինչու՞ ստեղծվեց dapp-ը:
— Կարո՞ղ եք հակիրճ պատմել, թե ինչու է ստեղծվել դափը, ի՞նչ խնդիրներ է այն լուծում։
DmitryԱռաջին պատճառը ժողովում է։ Սկզբում մենք լուրջ խնդիրներ ունեինք կառուցման հետ կապված, երբ Docker-ը չուներ բազմափուլ հնարավորություններ, ուստի մենք ինքնուրույն պատրաստեցինք բազմափուլ: Այնուհետև մենք ևս մի խումբ խնդիրներ ունեցանք պատկերը մաքրելու հետ կապված: Յուրաքանչյուր ոք, ով անում է CI/CD, ավելի շուտ, քան ուշ, բախվում է խնդրի հետ, որ կան հավաքված պատկերների մի փունջ, դուք պետք է ինչ-որ կերպ մաքրեք այն, ինչ պետք չէ և թողնել այն, ինչ անհրաժեշտ է:
Երկրորդ պատճառը տեղակայումն է։ Այո, կա Helm, բայց այն լուծում է միայն որոշ խնդիրներ: Զավեշտալիորեն գրված է, որ «Հելմը Kubernetes-ի փաթեթների կառավարիչն է»: Հենց այն, ինչ «այն»: Կան նաև «Փաթեթի կառավարիչ» բառերը. ո՞րն է սովորական ակնկալիքը Փաթեթի կառավարիչից: Մենք ասում ենք. «Փաթեթի կառավարիչ - տեղադրեք փաթեթը»: և մենք ակնկալում ենք, որ նա մեզ կասի. «Փաթեթը առաքվել է»:
Հետաքրքիր է, որ մենք ասում ենք. «Հելմ, տեղադրիր փաթեթը», և երբ նա պատասխանում է, որ տեղադրել է այն, պարզվում է, որ նոր է սկսել տեղադրումը, նա նշել է Kubernetes-ը. , աշխատում է, թե ոչ, Հելմը ընդհանրապես չի լուծում այս հարցը։
Պարզվում է, որ Helm-ը պարզապես տեքստային նախապրոցեսոր է, որը տվյալները բեռնում է Kubernetes-ում:
Բայց որպես ցանկացած տեղակայման մաս, մենք ուզում ենք իմանալ, թե արդյոք հավելվածը թողարկվել է արտադրության, թե ոչ: Գլորվել է արդյունահանման համար, նշանակում է, որ հավելվածը տեղափոխվել է այնտեղ, նոր տարբերակը տեղակայվել է, և առնվազն այն չի խափանում այնտեղ և ճիշտ է արձագանքում: Helm-ը ոչ մի կերպ չի լուծում այս խնդիրը։ Այն լուծելու համար պետք է շատ ջանք գործադրել, քանի որ պետք է Kubernetes-ին հրաման տալ՝ դուրս բերել և վերահսկել, թե ինչ է կատարվում այնտեղ՝ արդյոք այն տեղակայվել է, թե գլորվել: Եվ կան նաև բազմաթիվ առաջադրանքներ՝ կապված տեղակայման, մաքրման և հավաքման հետ:
Plans
Այս տարի մենք սկսելու ենք տեղական զարգացումը։ Մենք ցանկանում ենք հասնել նրան, ինչ նախկինում կար Vagrant-ում. մենք մուտքագրեցինք «vagrant up» և գործարկեցինք վիրտուալ մեքենաներ: Մենք ուզում ենք հասնել այն կետին, երբ Git-ում կա նախագիծ, այնտեղ գրում ենք «werf up», և այն բերում է այս նախագծի տեղական պատճենը՝ տեղակայված տեղական մինի-Kub-ում, զարգացման համար հարմար բոլոր դիրեկտորիաները միացված են։ . Կախված զարգացման լեզվից, դա արվում է այլ կերպ, բայց, այնուամենայնիվ, այնպես, որ տեղային զարգացումը կարող է հարմար կերպով իրականացվել տեղադրված ֆայլերի տակ:
Մեզ համար հաջորդ քայլն է ներդրումներ կատարել մշակողների համար հարմարության մեջ. Նախագիծը մեկ գործիքով արագ տեղակայելու համար, զարգացրեք այն, մղեք այն Git-ի մեջ, և այն նաև կտարածվի փուլի կամ փորձարկման՝ կախված խողովակաշարերից, այնուհետև օգտագործեք նույն գործիքը՝ արտադրության գնալու համար: Այս միասնությունը, միավորումը, ենթակառուցվածքների վերարտադրելիությունը տեղական միջավայրից մինչև վաճառք մեզ համար շատ կարևոր կետ է։ Բայց սա դեռևս վեճում չէ, մենք պարզապես պլանավորում ենք դա անել:
Բայց dapp/werf տանող ուղին միշտ եղել է նույնը, ինչ սկզբում Kubernetes-ի հետ: Մենք բախվեցինք խնդիրների, լուծեցինք դրանք լուծումներով. մենք մեզ համար որոշ լուծումներ գտանք պատյանի վրա, ցանկացած բանի համար: Այնուհետև նրանք փորձեցին ինչ-որ կերպ շտկել այս լուծումները, ընդհանրացնել և համախմբել դրանք երկուականների այս դեպքում, ինչը մենք պարզապես կիսում ենք:
Այս ամբողջ պատմությանը մեկ այլ տարբերակ էլ կա՝ անալոգիաներով:
Kubernetes-ը շարժիչով մեքենայի շրջանակ է: Չկան դռներ, ապակիներ, ռադիո, տոնածառ՝ ընդհանրապես ոչինչ: Միայն շրջանակն ու շարժիչը: Եվ կա Helm - սա ղեկ է: Թույն - կա ղեկ, բայց ձեզ նաև անհրաժեշտ է ղեկ, ղեկի դարակ, փոխանցումատուփ և անիվներ, և դուք չեք կարող անել առանց դրանց:
Werf-ի դեպքում սա Kubernetes-ի մեկ այլ բաղադրիչ է: Միայն հիմա werf-ի ալֆա տարբերակում, օրինակ, Helm-ը կազմված է werf-ի ներսում, քանի որ մենք հոգնել ենք ինքներս դա անելուց։ Դա անելու շատ պատճառներ կան, ես ձեզ մանրամասն կպատմեմ այն մասին, թե ինչու ենք մենք հավաքել ամբողջ ղեկը վերֆի ներսում գտնվող հողագործի հետ միասին: .
Այժմ werf-ն ավելի ինտեգրված բաղադրիչ է: Մենք ստանում ենք պատրաստի ղեկ, ղեկ - ես այնքան էլ լավ չեմ մեքենաներում, բայց սա մեծ բլոկ է, որն արդեն լուծում է խնդիրների բավականին լայն շրջանակ: Մեզ պետք չէ ինքներս անցնել կատալոգը, ընտրել մի մասը մյուսի համար, մտածել, թե ինչպես դրանք իրար պտուտակել: Ստանում ենք պատրաստի կոմբայն, որը միանգամից մեծ թվով խնդիրներ է լուծում։ Բայց ներսում այն կառուցված է նույն բաց կոդով բաղադրիչներից, այն դեռ օգտագործում է Docker-ը հավաքման համար, Helm-ը՝ որոշ գործառույթների համար, և կան մի քանի այլ գրադարաններ: Սա ինտեգրված գործիք է տուփից սառը CI/CD-ն արագ և հարմարավետ հանելու համար:
Դժվա՞ր է արդյոք պահպանել Kubernetes-ը:
— Դուք խոսում եք այն փորձի մասին, որ սկսել եք օգտագործել Kubernetes-ը, սա ձեզ համար շրջանակ է, շարժիչ, և որ դուք կարող եք շատ տարբեր բաներ կախել դրա վրա՝ թափք, ղեկ, ոտնակների պտուտակ, նստատեղեր: Հարց է ծագում՝ որքանո՞վ է դժվար Ձեզ համար Kubernetes-ի աջակցությունը։ Դուք մեծ փորձ ունեք, որքա՞ն ժամանակ և ռեսուրսներ եք ծախսում Kubernetes-ին աջակցելու վրա՝ մեկուսացված մնացած ամեն ինչից:
DmitryՍա շատ բարդ հարց է, և պատասխանելու համար մենք պետք է հասկանանք, թե ինչ է աջակցությունը և ինչ ենք ուզում Kubernetes-ից: Գուցե դուք կարող եք բացահայտել.
- Որքանով ես գիտեմ և ինչպես տեսնում եմ, այժմ շատ թիմեր ցանկանում են փորձել Կուբերնետեսը: Բոլորն իրեն ամրացնում են, ծնկի են դնում: Ես այնպիսի զգացողություն ունեմ, որ մարդիկ միշտ չէ, որ հասկանում են այս համակարգի բարդությունը:
Dmitry:Այդպես է։
— Որքա՞ն դժվար է զրոյից վերցնել և տեղադրել Kubernetes-ը, որպեսզի այն պատրաստ լինի:
DmitryԻ՞նչ եք կարծում, որքան դժվար է սիրտ փոխպատվաստելը: Ես հասկանում եմ, որ սա փոխզիջումային հարց է: Սկալպել օգտագործելն ու չսխալվելն այնքան էլ դժվար չէ։ Եթե նրանք ձեզ ասում են, թե որտեղ պետք է կտրել և որտեղ կարել, ապա ընթացակարգը ինքնին բարդ չէ: Դժվար է ժամանակ առ ժամանակ երաշխավորել, որ ամեն ինչ կստացվի։
Kubernetes-ի տեղադրումը և այն գործարկելը հեշտ է. — տեղադրված է, տեղադրման բազմաթիվ եղանակներ կան: Բայց ի՞նչ է լինում, երբ խնդիրներ են առաջանում։
Միշտ հարցեր են առաջանում՝ ի՞նչը մենք դեռ հաշվի չենք առել։ Ի՞նչ չենք արել դեռ։ Linux միջուկի ո՞ր պարամետրերն են սխալ նշված: Տեր, մենք նույնիսկ նրանց հիշատակե՞լ ենք: Kubernetes-ի ո՞ր բաղադրիչներն ենք մենք մատակարարել և որոնք՝ ոչ: Հազարավոր հարցեր են ծագում, որոնց պատասխանելու համար պետք է 15-20 տարի ծախսել այս ոլորտում։
Ես այս թեմայի վերաբերյալ վերջերս մի օրինակ ունեմ, որը կարող է բացահայտել «Արդյո՞ք Kubernetes-ը դժվար է պահպանել» խնդրի իմաստը: Որոշ ժամանակ առաջ մենք լրջորեն մտածում էինք, թե արդյոք պետք է փորձենք Cilium-ը որպես ցանց ներդնել Կուբերնետեսում։
Թույլ տվեք բացատրել, թե ինչ է Կիլիումը: Kubernetes-ն ունի ցանցային ենթահամակարգի բազմաթիվ տարբեր իրականացումներ, և դրանցից մեկը շատ հետաքրքիր է՝ Cilium-ը: Ո՞րն է դրա իմաստը։ Միջուկում որոշ ժամանակ առաջ հնարավոր դարձավ միջուկի համար գրել կեռիկներ, որոնք այս կամ այն կերպ ներխուժում են ցանցի ենթահամակարգ և տարբեր այլ ենթահամակարգեր և թույլ են տալիս շրջանցել միջուկի մեծ կտորները։
Linux-ի միջուկը պատմականորեն ունի ip երթուղի, գերֆիլտր, կամուրջներ և շատ տարբեր հին բաղադրիչներ, որոնք 15, 20, 30 տարեկան են: Ընդհանրապես աշխատում են, ամեն ինչ հիանալի է, բայց հիմա բեռնարկղեր են կուտակել, և կարծես 15 աղյուսից բաղկացած աշտարակ լինի իրար վրա, և դու կանգնում ես դրա վրա մի ոտքի վրա՝ տարօրինակ զգացողություն։ Այս համակարգը պատմականորեն զարգացել է բազմաթիվ նրբերանգներով, ինչպես մարմնի կույրաղիքը: Որոշ իրավիճակներում կան կատարողականի խնդիրներ, օրինակ.
Գոյություն ունի հիանալի BPF և միջուկի համար կեռիկներ գրելու ունակություն. տղաները գրել են իրենց սեփական կեռիկները միջուկի համար: Փաթեթը մտնում է Linux միջուկ, նրանք այն հանում են հենց մուտքի մոտ, իրենք մշակում են այնպես, ինչպես պետք է առանց կամուրջների, առանց TCP, առանց IP stack-ի, մի խոսքով, շրջանցելով այն ամենը, ինչ գրված է Linux միջուկում, և հետո թքել: այն դուրս բերեք տարայի մեջ:
Ինչ է պատահել? Շատ հիանալի կատարում, հիանալի առանձնահատկություններ - պարզապես հիանալի: Բայց մենք նայում ենք դրան և տեսնում ենք, որ յուրաքանչյուր մեքենայի վրա կա ծրագիր, որը միանում է Kubernetes API-ին և, հիմնվելով այս API-ից ստացած տվյալների վրա, ստեղծում է C կոդ և հավաքում երկուականներ, որոնք այն բեռնում է միջուկում, որպեսզի այս կեռիկները աշխատեն: միջուկի տարածքում:
Ի՞նչ է պատահում, եթե ինչ-որ բան սխալ է: Մենք չգիտենք. Սա հասկանալու համար հարկավոր է կարդալ այս ամբողջ ծածկագիրը, հասկանալ ողջ տրամաբանությունը, և զարմանալի է, թե որքան դժվար է դա: Բայց, մյուս կողմից, կան այս կամուրջները, ցանցի զտիչները, ip-ի երթևեկությունը. ես չեմ կարդացել դրանց սկզբնական կոդը, ինչպես նաև մեր ընկերությունում աշխատող 40 ինժեներները: Գուցե միայն քչերն են հասկանում որոշ հատվածներ։
Իսկ ո՞րն է տարբերությունը։ Պարզվում է, որ կա ip երթուղի, Linux միջուկ, և կա մի նոր գործիք՝ ինչ տարբերություն, մենք չենք հասկանում մեկը կամ մյուսը: Բայց մենք վախենում ենք նոր բան օգտագործել՝ ինչո՞ւ։ Որովհետև եթե գործիքը 30 տարեկան է, ապա 30 տարվա ընթացքում բոլոր սխալները հայտնաբերվել են, բոլոր սխալները ոտնահարվել են, և ամեն ինչի մասին պետք չէ իմանալ. այն աշխատում է սև արկղի պես և միշտ աշխատում է: Բոլորը գիտեն, թե որ դիագնոստիկ պտուտակահանը որ տեղում կպցնել, որ tcpdump-ը որ պահին աշխատի։ Բոլորը լավ գիտեն ախտորոշիչ կոմունալ ծառայությունները և հասկանում են, թե ինչպես է բաղադրիչների այս հավաքածուն աշխատում Linux միջուկում, ոչ թե ինչպես է այն աշխատում, այլ ինչպես օգտագործել այն:
Իսկ ահավոր զով Կիլիումը 30 տարեկան չէ, դեռ չի հնացել։ Կուբերնետեսը նույն խնդիրն ունի, պատճենեք։ Որ «Cilium»-ը կատարյալ է տեղադրված, որ Kubernetes-ը հիանալի է տեղադրված, բայց երբ արտադրության մեջ ինչ-որ բան սխալ է տեղի ունենում, կարո՞ղ եք կրիտիկական իրավիճակում արագ հասկանալ, թե ինչն է սխալ եղել:
Երբ ասում ենք՝ դժվա՞ր է պահպանել Kubernetes-ը, ոչ, դա շատ հեշտ է, և այո, դա աներևակայելի դժվար է: Kubernetes-ը հիանալի է աշխատում ինքնուրույն, բայց միլիարդ նրբերանգներով:
«Ինձ հաջողակ կլինի» մոտեցման մասին
— Կա՞ն ընկերություններ, որտեղ այս նրբերանգները գրեթե երաշխավորված են ի հայտ գալու։ Ենթադրենք, Yandex-ը հանկարծ բոլոր ծառայությունները փոխանցի Kubernetes-ին, այնտեղ հսկայական բեռ կլինի։
DmitryՉէ, սա ծանրաբեռնվածության մասին խոսակցություն չէ, այլ ամենապարզ բաների մասին։ Օրինակ, մենք ունենք Kubernetes, մենք այնտեղ տեղակայել ենք հավելվածը։ Ինչպե՞ս գիտեք, որ այն աշխատում է: Պարզապես չկա պատրաստի գործիք՝ հասկանալու համար, որ հավելվածը չի խափանում։ Չկա պատրաստի համակարգ, որն ուղարկում է ահազանգեր, դուք պետք է կազմաձևեք այս ազդանշանները և յուրաքանչյուր ժամանակացույց: Եվ մենք թարմացնում ենք Kubernetes-ը:
Ես ունեմ Ubuntu 16.04: Կարելի է ասել, որ սա հին տարբերակ է, բայց մենք դեռ դրա վրա ենք, քանի որ այն LTS է: Կա systemd, որի նրբությունն այն է, որ այն չի մաքրում C-խմբերը։ Kubernetes-ը գործարկում է pods, ստեղծում C-խմբեր, այնուհետև ջնջում է pods, և ինչ-որ կերպ պարզվում է, - մանրամասները չեմ հիշում, կներեք, որ համակարգված հատվածները մնացել են: Սա հանգեցնում է նրան, որ ժամանակի ընթացքում ցանկացած մեքենա սկսում է ուժեղ դանդաղեցնել: Սա նույնիսկ բարձր բեռնման մասին հարց չէ։ Եթե մշտական փոդներ գործարկվեն, օրինակ, եթե կա Cron Job-ը, որն անընդհատ պոդեր է ստեղծում, ապա Ubuntu 16.04-ով սարքը կսկսի դանդաղեցնել մեկ շաբաթ անց: Կլինի անընդհատ բարձր բեռնվածության միջին՝ պայմանավորված այն հանգամանքով, որ ստեղծվել են մի շարք C-խմբեր: Սա այն խնդիրն է, որին կբախվի ցանկացած մարդ, ով պարզապես տեղադրում է Ubuntu 16-ը և Kubernetes-ը վերևում:
Ենթադրենք, նա ինչ-որ կերպ թարմացնում է systemd-ը կամ այլ բան, բայց Linux-ի միջուկում մինչև 4.16-ն ավելի զվարճալի է. երբ ջնջում ես C-խմբերը, դրանք արտահոսում են միջուկում և իրականում չեն ջնջվում: Հետևաբար, այս մեքենայի վրա մեկ ամիս աշխատելուց հետո անհնար կլինի դիտարկել օջախների հիշողության վիճակագրությունը: Մենք հանում ենք մի ֆայլ, գլորում այն ծրագրում, և մեկ ֆայլ գլորվում է 15 վայրկյան, քանի որ միջուկը շատ երկար ժամանակ է պահանջում իր ներսում միլիոն C-խմբեր հաշվելու համար, որոնք կարծես ջնջված են, բայց ոչ, դրանք արտահոսում են: .
Նման մանրուքները դեռ շատ կան այստեղ-այնտեղ։ Սա այն խնդիրը չէ, որ հսկա ընկերությունները երբեմն կարող են բախվել շատ ծանր բեռների տակ. ոչ, դա առօրյա գործերի խնդիր է: Մարդիկ կարող են այսպես ապրել ամիսներ շարունակ. նրանք տեղադրել են Kubernetes-ը, տեղակայել հավելվածը, կարծես թե աշխատում է: Շատերի համար դա նորմալ է: Նրանք նույնիսկ չեն իմանա, որ այս հավելվածը ինչ-ինչ պատճառներով խափանվելու է, ահազանգ չեն ստանա, բայց նրանց համար դա նորմ է: Նախկինում մենք ապրում էինք վիրտուալ մեքենաներով առանց մոնիտորինգի, հիմա տեղափոխվեցինք Kubernetes, նաև առանց մոնիտորինգի. ո՞րն է տարբերությունը:
Հարցն այն է, որ երբ մենք քայլում ենք սառույցի վրայով, մենք երբեք չենք իմանում դրա հաստությունը, քանի դեռ այն նախապես չենք չափել: Շատերը քայլում են և չեն անհանգստանում, քանի որ նրանք նախկինում քայլել են:
Իմ տեսանկյունից, ցանկացած համակարգի գործարկման նրբությունն ու բարդությունը կայանում է նրանում, որ սառույցի հաստությունը լիովին բավարար է մեր խնդիրները լուծելու համար: Ահա թե ինչի մասին է խոսքը:
ՏՏ ոլորտում, ինձ թվում է, չափազանց շատ են «ես բախտավոր եմ լինելու» մոտեցումները։ Շատերը ծրագրային ապահովում են տեղադրում և օգտվում ծրագրային գրադարաններից՝ հույս ունենալով, որ իրենց բախտը կբերի: Ընդհանրապես շատերի բախտը բերել է։ Հավանաբար դա է պատճառը, որ այն աշխատում է:
— Իմ հոռետեսական գնահատականից երևում է, որ երբ ռիսկերը մեծ են, և հավելվածը պետք է աշխատի, ապա պետք է աջակցություն Flaunt-ից, գուցե Red Hat-ից, կամ ձեզ անհրաժեշտ է ձեր ներքին թիմը, որը նվիրված է հատուկ Kubernetes-ին, որը պատրաստ է։ քաշել այն:
DmitryՕբյեկտիվորեն այդպես է։ Փոքր թիմի համար Կուբերնետեսի պատմության մեջ ինքնուրույն մտնելը մի շարք ռիսկեր է պարունակում:
Մեզ պետք են տարաներ:
— Կարո՞ղ եք ասել, թե որքան տարածված է Kubernetes-ը Ռուսաստանում:
DmitryԵս չունեմ այս տվյալները, և վստահ չեմ, որ որևէ մեկը ունի դրանք: Մենք ասում ենք. «Kubernetes, Kubernetes», բայց կա այս հարցին նայելու այլ ձև: Ես նաև չգիտեմ, թե որքան տարածված են բեռնարկղերը, բայց ես գիտեմ մի թիվ ինտերնետում առկա զեկույցներից, որ բեռնարկղերի 70%-ը կազմակերպված է Kubernetes-ի կողմից: Այն հուսալի աղբյուր էր ամբողջ աշխարհում բավականին մեծ նմուշի համար:
Հետո մեկ այլ հարց՝ մեզ պե՞տք են տարաներ։ Իմ անձնական զգացողությունը և Flant ընկերության ընդհանուր դիրքորոշումն այն է, որ Kubernetes-ը դե ֆակտո ստանդարտ է:
Կուբերնետեսից բացի ոչինչ չի լինի։
Սա բացարձակ խաղ է փոխում ենթակառուցվածքների կառավարման ոլորտում։ Պարզապես բացարձակ. վերջ, այլևս չկա Ansible, Chef, վիրտուալ մեքենաներ, Terraform: Էլ չեմ խոսում հին կոլտնտեսության մեթոդների մասին։ Kubernetes-ը բացարձակ փոփոխող է, իսկ հիմա միայն այսպես է լինելու.
Հասկանալի է, որ ոմանց դա գիտակցելու համար պահանջվում է մի քանի տարի, իսկ ոմանց համար՝ մի քանի տասնամյակ։ Չեմ կասկածում, որ բացի Kubernetes-ից և այս նոր տեսքից ոչինչ չի լինի. մենք այլևս չենք վնասում օպերացիոն համակարգը, այլ օգտագործում ենք. ենթակառուցվածքը որպես ծածկագիր, միայն ոչ կոդով, այլ yml-ով` դեկլարատիվ նկարագրված ենթակառուցվածք։ Զգացողություն ունեմ, որ միշտ այսպես է լինելու.
— Այսինքն՝ այն ընկերությունները, որոնք դեռ չեն անցել Kubernetes-ին, անպայման կանցնեն դրան կամ կմնան մոռացության մեջ։ Ես քեզ ճիշտ հասկացա?
DmitryՍա նույնպես լիովին ճիշտ չէ: Օրինակ, եթե մենք ունենք DNS սերվեր գործարկելու խնդիր, ապա այն կարող է գործարկվել FreeBSD 4.10-ով և կարող է կատարելապես աշխատել 20 տարի: Պարզապես աշխատեք և վերջ: Երևի 20 տարի հետո ինչ-որ բան պետք է մեկ անգամ թարմացվի։ Եթե մենք խոսում ենք ծրագրային ապահովման մասին այն ձևաչափով, որը մենք գործարկել ենք, և այն իրականում աշխատում է երկար տարիներ առանց թարմացումների, առանց փոփոխություններ կատարելու, ապա, իհարկե, Kubernetes չի լինի: Նա այնտեղ պետք չէ:
CI/CD-ի հետ կապված ամեն ինչ՝ որտեղ էլ որ անհրաժեշտ է շարունակական առաքում, որտեղ դուք պետք է թարմացնեք տարբերակները, կատարեք ակտիվ փոփոխություններ, որտեղ դուք պետք է կառուցեք սխալների հանդուրժողականություն՝ միայն Kubernetes:
Միկրոծառայությունների մասին
-Այստեղ մի փոքր դիսոնանս ունեմ։ Kubernetes-ի հետ աշխատելու համար անհրաժեշտ է արտաքին կամ ներքին աջակցություն՝ սա առաջին կետն է: Երկրորդ, երբ մենք նոր ենք սկսում զարգացումը, մենք փոքր ստարտափ ենք, դեռ ոչինչ չունենք, Kubernetes-ի կամ ընդհանրապես միկրոսերվիսային ճարտարապետության զարգացումը կարող է բարդ լինել և ոչ միշտ է տնտեսապես արդարացված։ Ինձ հետաքրքրում է ձեր կարծիքը. արդյո՞ք ստարտափները պետք է անմիջապես սկսեն գրել Kubernetes-ի համար զրոյից, թե՞ նրանք դեռ կարող են գրել մոնոլիտ, այնուհետև միայն գալ Kubernetes:
Dmitry: Լավ հարց. Ես խոսակցություն ունեմ միկրոսերվիսների մասին Շատ անգամ եմ հանդիպել մարդկանց, ովքեր փորձում են մանրադիտակով մեխեր խփել։ Մոտեցումն ինքնին ճիշտ է, մենք ինքներս նախագծում ենք մեր ներքին ծրագրաշարը այս կերպ: Բայց երբ դուք դա անում եք, դուք պետք է հստակ հասկանաք, թե ինչ եք անում: Միկրոծառայությունների մասին ամենաշատը ատում եմ բառը «միկրո» է: Պատմականորեն այս բառը ծագել է այնտեղ, և չգիտես ինչու մարդիկ կարծում են, որ միկրոն շատ փոքր է, միլիմետրից պակաս, ինչպես միկրոմետրը։ Սա սխալ է.
Օրինակ, կա մի մոնոլիտ, որը գրված է 300 հոգու կողմից, և բոլորը, ովքեր մասնակցել են մշակմանը, հասկանում են, որ այնտեղ խնդիրներ կան, և այն պետք է մանրացնել՝ մոտ 10 կտոր, որոնցից յուրաքանչյուրը գրված է 30 հոգու կողմից։ նվազագույն տարբերակով: Սա կարևոր է, անհրաժեշտ և թույն: Բայց երբ մեզ մոտ մի ստարտափ է գալիս, որտեղ 3 շատ թույն ու տաղանդավոր տղաներ ծնկներին 60 միկրոսերվիս են գրել, ամեն անգամ Corvalol եմ փնտրում։
Ինձ թվում է՝ սրա մասին արդեն խոսվել է հազարավոր անգամներ՝ այս կամ այն ձևով ստացանք բաշխված մոնոլիտ։ Սա տնտեսապես արդարացված չէ, ընդհանրապես ամեն ինչում շատ դժվար է։ Ես պարզապես տեսել եմ սա այնքան անգամ, որ դա իսկապես ցավ է պատճառում ինձ, ուստի ես շարունակում եմ խոսել դրա մասին:
Նախնական հարցին՝ հակասություն կա այն փաստի միջև, որ մի կողմից՝ Kubernetes-ը սարսափելի է օգտագործել, քանի որ պարզ չէ, թե ինչն այնտեղ կարող է կոտրվել կամ չաշխատել, մյուս կողմից՝ պարզ է, որ ամեն ինչ այնտեղ է գնում։ և Կուբերնետեսից բացի ոչինչ գոյություն չի ունենա: Պատասխան - կշռադատեք օգուտի չափը, այն առաջադրանքների քանակը, որոնք դուք կարող եք լուծել. Սա կշեռքի մի կողմում է: Մյուս կողմից, կան ռիսկեր՝ կապված պարապուրդի կամ արձագանքման ժամանակի նվազման, հասանելիության մակարդակի հետ՝ կատարողականի ցուցանիշների նվազման հետ:
Ահա, կամ մենք արագ ենք շարժվում, և Kubernetes-ը մեզ թույլ է տալիս շատ բաներ անել շատ ավելի արագ և ավելի լավ, կամ մենք օգտագործում ենք հուսալի, ժամանակի փորձարկված լուծումներ, բայց շարժվում ենք շատ ավելի դանդաղ: Սա ընտրություն է, որը պետք է կատարի յուրաքանչյուր ընկերություն: Դուք կարող եք այն պատկերացնել որպես ջունգլիների ճանապարհ. երբ առաջին անգամ քայլում եք, կարող եք հանդիպել օձի, վագրի կամ խելագար փորսոցի, և երբ 10 անգամ քայլել եք, տրորել եք ճանապարհը, հեռացնել ճյուղերը և ավելի հեշտ քայլել: Ամեն անգամ ճանապարհն ավելի է լայնանում: Հետո ասֆալտապատ ճանապարհ է, իսկ հետո՝ գեղեցիկ բուլվար։
Kubernetes-ը տեղում չի կանգնում։ Կրկին հարց․ Kubernetes-ը մի կողմից 4-5 երկուական է, մյուս կողմից՝ ամբողջ էկոհամակարգն է։ Սա այն օպերացիոն համակարգն է, որը մենք ունենք մեր մեքենաների վրա: Ինչ է սա? Ubuntu, թե Curios. Սա Linux միջուկն է՝ լրացուցիչ բաղադրիչների մի փունջ։ Այս ամենը այստեղ, մեկ թունավոր օձը դուրս է շպրտվել ճանապարհից, այնտեղ պարիսպ է կանգնեցվել։ Kubernetes-ը զարգանում է շատ արագ և դինամիկ, և ամեն ամիս նվազում է ռիսկերի ծավալը, անհայտի ծավալը և, համապատասխանաբար, այդ կշեռքները վերաբալանսավորվում են։
Պատասխանելով այն հարցին, թե ինչ պետք է անի ստարտափը, ես կասեի՝ արի Flaunt, վճարիր 150 հազար ռուբլի և ստացիր բանտապահ DevOps հեշտ ծառայություն։ Եթե դուք փոքր ստարտափ եք մի քանի ծրագրավորողներով, սա աշխատում է: Ձեր սեփական DevOps-ները վարձելու փոխարեն, որոնք այս պահին պետք է սովորեն, թե ինչպես լուծել ձեր խնդիրները և վճարել աշխատավարձ, դուք կստանաք բանտապահ լուծում բոլոր հարցերի համար: Այո, կան որոշ թերություններ. Մենք՝ որպես աութսորսեր, չենք կարող այդքան ներգրավված լինել և արագ արձագանքել փոփոխություններին։ Բայց մենք ունենք մեծ փորձ և պատրաստի պրակտիկա։ Մենք երաշխավորում ենք, որ ցանկացած իրավիճակում մենք անպայման արագ կհասկանանք դա և մեռելներից կբարձրացնենք ցանկացած Kubernetes:
Ես խստորեն խորհուրդ եմ տալիս աութսորսինգ անել ստարտափներին և կայացած բիզնեսներին մինչև այն չափը, որտեղ դուք կարող եք 10 հոգանոց թիմ նվիրել գործառնություններին, քանի որ հակառակ դեպքում իմաստ չկա: Սա միանշանակ իմաստ ունի աութսորսինգ անել:
Amazon-ի և Google-ի մասին
— Կարո՞ղ է Amazon-ի կամ Google-ի լուծումներից հոսթինգը համարվել աութսորս:
DmitryԱյո, իհարկե, սա մի շարք հարցեր է լուծում։ Բայց կրկին կան նրբերանգներ. Դուք դեռ պետք է հասկանաք, թե ինչպես օգտագործել այն: Օրինակ, Amazon AWS-ի աշխատանքում հազարավոր մանրուք կա. Load Balancer-ը պետք է տաքացվի կամ նախապես խնդրանք գրվի, որ «տղերք, մենք կստանանք տրաֆիկ, տաքացրե՛ք Load Balancer-ը մեզ համար»: Դուք պետք է իմանաք այս նրբերանգները:
Երբ դուք դիմում եք մարդկանց, ովքեր մասնագիտանում են այս հարցում, գրեթե բոլոր բնորոշ բաները փակվում են: Մենք հիմա ունենք 40 ինժեներ, մինչև տարեվերջ երևի կլինի 60-ը, մենք այս ամենին միանշանակ հանդիպել ենք։ Նույնիսկ եթե մենք նորից բախվենք այս խնդրին ինչ-որ նախագծում, մենք արագ հարցնում ենք միմյանց և գիտենք, թե ինչպես լուծել այն:
Հավանաբար պատասխանը հետևյալն է. իհարկե, հյուրընկալված պատմությունը որոշ մասը հեշտացնում է: Հարցն այն է, թե պատրա՞ստ եք վստահել այս հոսթերներին և արդյոք նրանք կլուծեն ձեր խնդիրները: Amazon-ը և Google-ը լավ են աշխատել: Մեր բոլոր դեպքերի համար՝ ճիշտ: Մենք այլևս դրական փորձ չունենք: Մնացած բոլոր ամպերը, որոնց հետ մենք փորձեցինք աշխատել, շատ խնդիրներ են ստեղծում՝ Ager-ը, և այն ամենը, ինչ կա Ռուսաստանում, և OpenStack-ի բոլոր տեսակները տարբեր իրականացումներում՝ Headster, Overage՝ ինչ ուզում եք: Նրանք բոլորն էլ ստեղծում են խնդիրներ, որոնք դուք չեք ցանկանում լուծել:
Հետևաբար, պատասխանը այո է, բայց, ըստ էության, շատ հասուն հոսթինգ լուծումներ չկան:
Ո՞ւմ է պետք Kubernetes-ը:
— Եվ այնուամենայնիվ, ո՞ւմ է պետք Kubernetes-ը: Ո՞վ պետք է արդեն անցնի Kubernetes-ին, ով է Flaunt-ի տիպիկ հաճախորդը, ով գալիս է հատուկ Kubernetes-ի համար:
DmitryՍա հետաքրքիր հարց է, քանի որ հենց հիմա, Kubernetes-ի հետևանքով, շատ մարդիկ են գալիս մեզ մոտ. «Տղաներ, մենք գիտենք, որ դուք անում եք Kubernetes, արեք դա մեզ համար»: Մենք պատասխանում ենք նրանց. «Պարոնայք, մենք Կուբերնետես չենք անում, մենք խրախուսում ենք և դրա հետ կապված ամեն ինչ»: Որովհետև ներկայումս պարզապես անհնար է ապրանք պատրաստել առանց ամբողջ CI/CD-ն և այս ամբողջ պատմությունը կատարելու: Բոլորը հեռացել են այն բաժանումից, որ զարգացումով ունենք զարգացում, հետո շահագործում շահագործմամբ։
Մեր հաճախորդները սպասում են տարբեր բաների, բայց բոլորը սպասում են ինչ-որ լավ հրաշքի, որ ունեն որոշակի խնդիրներ, իսկ հիմա՝ հոփ: — Կուբերնետեսը կլուծի դրանք։ Մարդիկ հավատում են հրաշքներին. Իրենց մտքում նրանք հասկանում են, որ հրաշք չի լինի, բայց հոգու խորքում հույս ունեն. իսկ եթե այս Կուբերնետեսը հիմա մեզ համար ամեն ինչ լուծի, նրանք այնքան շատ են խոսում դրա մասին: Հանկարծ նա հիմա - փռշտալ: - և արծաթե փամփուշտ, փռշտացեք: — և մենք ունենք 100% գործարկման ժամանակ, բոլոր մշակողները կարող են թողարկել այն, ինչ մտնում է արտադրության մեջ 50 անգամ, և այն չի խափանում: Ընդհանրապես, հրաշք!
Երբ մեզ մոտ նման մարդիկ են գալիս, մենք ասում ենք. «Կներեք, բայց հրաշք չկա»: Առողջ լինելու համար հարկավոր է լավ սնվել և մարզվել։ Հուսալի արտադրանք ունենալու համար այն պետք է հուսալիորեն պատրաստվի: Հարմարավետ CI/CD ունենալու համար հարկավոր է այն պատրաստել այսպես. Դա մեծ աշխատանք է, որը պետք է կատարվի:
Պատասխանելով այն հարցին, թե ում է պետք Kubernetes-ը, Kubernetes-ը ոչ մեկին պետք չէ:
Որոշ մարդիկ թյուր կարծիք ունեն, որ իրենց պետք է Kubernetes: Մարդիկ կարիք ունեն, նրանք խորը կարիք ունեն դադարելու մտածել, ուսումնասիրել, հետաքրքրվել ենթակառուցվածքների բոլոր խնդիրներով և իրենց հավելվածների գործարկման խնդիրներով։ Նրանք ցանկանում են, որ հավելվածները պարզապես աշխատեն և պարզապես տեղակայվեն: Նրանց համար Kubernetes-ը հույս է, որ նրանք կդադարեն լսել պատմությունը, որ «մենք պառկած էինք այնտեղ», կամ «մենք չենք կարող դուրս գալ» կամ այլ բան:
Մեզ մոտ սովորաբար գալիս է տեխնիկական տնօրենը։ Նրան երկու բան են խնդրում՝ մի կողմից մեզ դիմագիծ տուր, մյուս կողմից՝ կայունություն։ Առաջարկում ենք դա վերցնել ձեր վրա և անել։ Արծաթե փամփուշտը, ավելի ճիշտ՝ արծաթապատ, այն է, որ դուք կդադարեք մտածել այս խնդիրների մասին և ժամանակ վատնել: Դուք կունենաք հատուկ մարդիկ, ովքեր կփակեն այս հարցը։
Այն ձևակերպումը, որ Kubernetes-ը մեզ կամ որևէ մեկին պետք է, ճիշտ չէ:
Ադմինները իսկապես Kubernetes-ի կարիքն ունեն, քանի որ դա շատ հետաքրքիր խաղալիք է, որի հետ կարելի է խաղալ և հարել: Եկեք անկեղծ լինենք, բոլորը սիրում են խաղալիքներ: Մենք բոլորս ինչ-որ տեղ երեխա ենք, և երբ նորը տեսնում ենք, ուզում ենք խաղալ: Ոմանց համար դա հուսահատվել է, օրինակ, վարչակազմում, քանի որ նրանք արդեն բավականաչափ խաղացել են և արդեն հոգնել են այն աստիճան, որ պարզապես չեն ուզում: Բայց սա ոչ մեկի համար ամբողջովին կորած չէ: Օրինակ, եթե ես երկար ժամանակ հոգնել եմ համակարգի կառավարման և DevOps խաղալիքներից, ապա ես դեռ սիրում եմ խաղալիքները, ես դեռ նոր եմ գնում: Բոլոր մարդիկ, այսպես թե այնպես, դեռ ուզում են ինչ-որ խաղալիքներ:
Պետք չէ խաղալ արտադրության հետ։ Ինչ էլ որ ես կտրականապես խորհուրդ եմ տալիս չանել և այն, ինչ հիմա զանգվածաբար տեսնում եմ. «Օ՜, նոր խաղալիք»: — նրանք վազեցին գնելու, գնեցին և. «Հիմա տանենք դպրոց և ցույց տանք մեր բոլոր ընկերներին»։ Մի արեք սա: Ներողություն եմ խնդրում, երեխաներս նոր են մեծանում, ես երեխաների մեջ անընդհատ ինչ-որ բան եմ տեսնում, իմ մեջ նկատում, հետո ընդհանրացնում մյուսներին։
Վերջնական պատասխանն է՝ ձեզ Kubernetes պետք չեն: Դուք պետք է լուծեք ձեր խնդիրները:
Ինչին կարող եք հասնել հետևյալն է.
- արդյունահանումը չի ընկնում;
- նույնիսկ եթե նա փորձի ընկնել, մենք դրա մասին նախապես գիտենք, և կարող ենք դրա մեջ ինչ-որ բան դնել;
- մենք կարող ենք փոխել այն արագությամբ, որով դա պահանջում է մեր բիզնեսը, և մենք կարող ենք դա անել հարմար կերպով, դա մեզ որևէ խնդիր չի առաջացնում:
Երկու իրական կարիք կա՝ հուսալիություն և դինամիկա/տարածման ճկունություն: Յուրաքանչյուր ոք, ով ներկայումս զբաղվում է ինչ-որ ՏՏ նախագծերով, անկախ նրանից, թե ինչպիսի բիզնեսում է, և ով հասկանում է դա, պետք է լուծի այդ կարիքները: Kubernetes-ը ճիշտ մոտեցմամբ, ճիշտ հասկացողությամբ և բավարար փորձով թույլ է տալիս լուծել դրանք։
Անսերվերի մասին
— Եթե մի փոքր ավելի հեռուն նայեք դեպի ապագան, ապա փորձեք լուծել գլխացավի բացակայության խնդիրը ենթակառուցվածքով, տեղադրման արագությամբ և հավելվածների փոփոխման արագությամբ, նոր լուծումներ են հայտնվում, օրինակ՝ առանց սերվերի։ Դուք որևէ ներուժ զգո՞ւմ եք այս ուղղությամբ և, ասենք, վտանգ Կուբերնետեսի և նմանատիպ լուծումների համար։
DmitryԱյստեղ պետք է նորից նկատողություն անենք, որ ես տեսանող չեմ, որ նայում եմ առաջ և ասում՝ այսպես կլինի։ Չնայած ես հենց նույն բանն արեցի։ Ես նայում եմ ոտքերիս ու տեսնում եմ այնտեղ մի շարք խնդիրներ, օրինակ՝ ինչպես են աշխատում տրանզիստորները համակարգչում։ Ծիծաղելի է, չէ՞: Մենք բախվում ենք պրոցեսորի որոշ սխալների:
Դարձրեք առանց սերվերի բավականին հուսալի, էժան, արդյունավետ և հարմար՝ լուծելով էկոհամակարգի բոլոր խնդիրները: Այստեղ ես համաձայն եմ Իլոն Մասկի հետ, որ մարդկության համար սխալ հանդուրժողականություն ստեղծելու համար անհրաժեշտ է երկրորդ մոլորակ: Չնայած ես չգիտեմ, թե ինչ է նա ասում, ես հասկանում եմ, որ ես ինքս պատրաստ չեմ Մարս թռչել, և դա վաղը չի լինի:
Առանց սերվերի դեպքում պարզ է, որ դա գաղափարապես ճիշտ բան է, ինչպես մարդկության հանդեպ սխալ հանդուրժողականությունը. երկու մոլորակ ունենալն ավելի լավ է, քան մեկը: Բայց ինչպե՞ս դա անել հիմա: Մեկ արշավախումբ ուղարկելը խնդիր չէ, եթե ձեր ուժերը կենտրոնացնեք դրա վրա: Մի քանի արշավախմբեր ուղարկելն ու այնտեղ մի քանի հազար մարդ բնակեցնելը, կարծում եմ, նույնպես իրատեսական է։ Բայց դա լիովին անսխալական դարձնել, որպեսզի մարդկության կեսն այնտեղ ապրի, ինձ հիմա անհնար է թվում՝ չդիտարկվելով։
Սերվերազուրկ մեկը մեկի վրա. բանը լավ է, բայց հեռու է 2019-ի խնդիրներից։ 2030-ին ավելի մոտ. եկեք ապրենք, որպեսզի տեսնենք այն: Չեմ կասկածում, որ կապրենք, անպայման կապրենք (կրկնում եմ քնելուց առաջ), բայց հիմա պետք է այլ խնդիրներ լուծել։ Դա նման է հավատալու հեքիաթային պոնի Rainbow-ին: Այո, մի երկու տոկոս գործերը լուծվում են, և դրանք հիանալի լուծվում են, բայց սուբյեկտիվորեն, առանց սերվերի ծիածանը... Ինձ համար այս թեման չափազանց հեռավոր է և չափազանց անհասկանալի։ Ես պատրաստ չեմ խոսելու։ 2019 թվականին դուք չեք կարող գրել մեկ հավելված առանց սերվերի։
Ինչպես կզարգանա Kubernetes-ը
— Մինչ մենք շարժվում ենք դեպի այս պոտենցիալ հրաշալի հեռավոր ապագան, ձեր կարծիքով ինչպե՞ս կզարգանան Kubernetes-ը և նրա շուրջը գտնվող էկոհամակարգը:
DmitryԵս շատ եմ մտածել այս մասին և ունեմ հստակ պատասխան. Առաջինը պետական է, ի վերջո քաղաքացիություն չունեցողն ավելի հեշտ է անել: Կուբերնետեսը սկզբում ավելի շատ ներդրումներ կատարեց դրա մեջ, ամեն ինչ սկսվեց դրանից: Քաղաքացիություն չունեցողն աշխատում է Kubernetes-ում գրեթե անթերի, պարզապես բողոքելու բան չկա: Դեռ շատ խնդիրներ կան, ավելի ճիշտ՝ նրբերանգներ։ Այնտեղ ամեն ինչ արդեն հիանալի է աշխատում մեզ մոտ, բայց դա մենք ենք: Առնվազն ևս մի քանի տարի կպահանջվի, որպեսզի դա աշխատի բոլորի համար: Սա հաշվարկված ցուցանիշ չէ, այլ իմ զգացողությունն իմ գլխից։
Մի խոսքով, պետականությունը պետք է և կզարգանա շատ ուժեղ, քանի որ մեր բոլոր հավելվածները պահում են կարգավիճակը, քաղաքացիություն չունեցող հավելվածներ չկան: Սա պատրանք է, ձեզ միշտ պետք է ինչ-որ տվյալների բազա և այլ բան: Statefull-ը վերաբերում է այն ամենին, ինչ հնարավոր է շտկելու, բոլոր սխալները շտկելու, ներկայումս բախվող բոլոր խնդիրների բարելավման մասին. եկեք դա անվանենք ընդունում:
Անհայտի մակարդակը, չլուծված խնդիրների մակարդակը, ինչ-որ բանի հետ հանդիպելու հավանականության մակարդակը զգալիորեն կիջնի։ Սա կարևոր պատմություն է։ Իսկ օպերատորներ՝ ամեն ինչ՝ կապված ադմինիստրացիայի տրամաբանության կոդավորման հետ, վերահսկման տրամաբանություն՝ հեշտ ծառայություն ստանալու համար. MySQL հեշտ ծառայություն, RabbitMQ հեշտ ծառայություն, Memcache հեշտ ծառայություն, ընդհանուր առմամբ, բոլոր այս բաղադրիչները, որոնք մենք պետք է երաշխավորված լինենք աշխատելու համար: տուփը։ Սա պարզապես լուծում է այն ցավը, որ մենք ցանկանում ենք տվյալների բազա, բայց մենք չենք ցանկանում կառավարել այն, կամ մենք ուզում ենք Kubernetes, բայց մենք չենք ցանկանում կառավարել այն:
Այս կամ այն ձևով օպերատորի զարգացման այս պատմությունը կարևոր կլինի առաջիկա մի քանի տարիներին:
Կարծում եմ, որ օգտագործման հեշտությունը պետք է մեծապես ավելանա. տուփը կդառնա ավելի ու ավելի սև, ավելի ու ավելի հուսալի, ավելի ու ավելի պարզ բռնակներով:
Ես մի անգամ YouTube-ում Saturday Night Live-ում լսեցի Իսահակ Ասիմովի հետ 80-ականների մի հին հարցազրույց՝ Urgant-ի նման հաղորդում, միայն հետաքրքիր: Նրան հարցրին համակարգիչների ապագայի մասին։ Նա ասաց, որ ապագան պարզության մեջ է, ինչպես ռադիոն։ Ռադիոընդունիչը ի սկզբանե բարդ բան էր: Ալիք բռնելու համար պետք էր 15 րոպե պտտել կոճակները, պտտել շամփուրները և ընդհանրապես իմանալ, թե ինչպես է ամեն ինչ աշխատում, հասկանալ ռադիոալիքների փոխանցման ֆիզիկան: Արդյունքում ռադիոյի մեջ մնաց ընդամենը մեկ կոճակ։
Հիմա 2019 թվականին ի՞նչ ռադիո: Մեքենայում ռադիոընդունիչը գտնում է բոլոր ալիքները և կայանների անվանումները: Գործընթացի ֆիզիկան չի փոխվել 100 տարվա ընթացքում, բայց օգտագործման հեշտությունը փոխվել է: Հիմա, և ոչ միայն հիմա, արդեն 1980 թվականին, երբ հարցազրույց կար Ազիմովի հետ, բոլորն օգտվում էին ռադիոյից և ոչ ոք չէր մտածում, թե ինչպես է այն աշխատում։ Դա միշտ աշխատել է, դա տրված է:
Ազիմովն այնուհետև ասաց, որ նույնը կլինի համակարգիչների դեպքում. կմեծանա օգտագործման հեշտությունը. Մինչդեռ 1980-ին դուք պետք է սովորեիք համակարգչի կոճակները սեղմելու համար, ապագայում դա այդպես չի լինի:
Ես այնպիսի զգացողություն ունեմ, որ Kubernetes-ի և ենթակառուցվածքի հետ կապված կլինի նաև օգտագործման հարմարավետության հսկայական աճ: Սա, իմ կարծիքով, ակնհայտ է. այն ընկած է մակերեսի վրա:
Ի՞նչ անել ինժեներների հետ:
— Այդ դեպքում ի՞նչ կլինի ինժեներների և համակարգի ադմինիստրատորների հետ, ովքեր աջակցում են Kubernetes-ին:
DmitryԻ՞նչ պատահեց հաշվապահին 1C-ի գալուստից հետո: Մոտավորապես նույնը։ Մինչ այս հաշվում էին թղթի վրա՝ հիմա ծրագրում։ Աշխատանքի արտադրողականությունը մեծացել է մեծության կարգերով, բայց աշխատուժն ինքնին չի անհետացել։ Եթե նախկինում լամպը պտտելու համար 10 ինժեներ էր պահանջվում, ապա այժմ մեկը բավական կլինի։
Ծրագրաշարի քանակն ու առաջադրանքների քանակը, ինձ թվում է, այժմ աճում է ավելի արագ տեմպերով, քան նոր DevOps-ներն են հայտնվում, և արդյունավետությունը մեծանում է: Շուկայում այս պահին կա կոնկրետ դեֆիցիտ, որը երկար կտևի։ Հետագայում ամեն ինչ կվերադառնա ինչ-որ նորմալության, որի դեպքում կբարձրանա աշխատանքի արդյունավետությունը, ավելի ու ավելի շատ կլինեն առանց սերվերների, Կուբերնետեսին կկցվի նեյրոն, որը կընտրի բոլոր ռեսուրսները ճիշտ ըստ անհրաժեշտության, և ընդհանրապես ամեն ինչ ինքն իրեն արեք, ինչպես որ պետք է. մարդը պարզապես հեռացեք և մի խառնվեք:
Բայց ինչ-որ մեկը դեռ պետք է որոշումներ կայացնի: Հասկանալի է, որ այս անձի որակավորման ու մասնագիտացման մակարդակն ավելի բարձր է։ Մեր օրերում հաշվապահությունում պետք չէ, որ 10 աշխատող գրքույկ պահեն, որ ձեռքերը չհոգնեն։ Դա պարզապես անհրաժեշտ չէ: Շատ փաստաթղթեր ավտոմատ կերպով սկանավորվում և ճանաչվում են էլեկտրոնային փաստաթղթերի կառավարման համակարգի կողմից: Բավական է մեկ խելացի գլխավոր հաշվապահ՝ արդեն շատ ավելի մեծ հմտություններով, լավ հասկացողությամբ։
Ընդհանրապես, բոլոր ոլորտներում այդպես է պետք գնալ։ Նույնն է մեքենաների դեպքում՝ նախկինում մեքենա էր գալիս մեխանիկով և երեք վարորդով։ Մեր օրերում մեքենա վարելը պարզ գործընթաց է, որին մենք բոլորս մասնակցում ենք ամեն օր։ Ոչ ոք չի կարծում, որ մեքենան ինչ-որ բարդ բան է։
DevOps-ը կամ համակարգերի ճարտարագիտությունը չի վերանա. բարձր մակարդակի աշխատանքն ու արդյունավետությունը կավելանան:
— Մի հետաքրքիր միտք էլ լսեցի, որ գործն իրականում կավելանա։
Dmitry- Իհարկե, հարյուր տոկոսով: Որովհետև մեր գրած ծրագրերի քանակը անընդհատ աճում է: Խնդիրների թիվը, որոնք մենք լուծում ենք ծրագրային ապահովման միջոցով, անընդհատ աճում է: Աշխատանքի ծավալն աճում է։ Այժմ DevOps շուկան ահավոր գերտաքացած է։ Դա երեւում է աշխատավարձի ակնկալիքներից: Լավ իմաստով, առանց մանրամասների մեջ մտնելու, պետք է լինեն կրտսերներ, ովքեր ցանկանում են X, միջինները, ովքեր ցանկանում են 1,5X, իսկ ավագները, ովքեր ցանկանում են 2X: Եվ հիմա, եթե նայեք Մոսկվայի DevOps-ի աշխատավարձի շուկան, կրտսերը ցանկանում է X-ից մինչև 3X, իսկ ավագը՝ X-ից մինչև 3X:
Ոչ ոք չգիտի, թե որքան արժե այն։ Աշխատավարձի մակարդակը չափվում է ձեր վստահությամբ՝ լրիվ գժանոց, ճիշտն ասած՝ ահավոր գերտաքացած շուկա։
Իհարկե, այս իրավիճակը շատ շուտով կփոխվի՝ որոշակի հագեցվածություն պետք է տեղի ունենա։ Դա այդպես չէ ծրագրային ապահովման մշակման դեպքում. չնայած այն հանգամանքին, որ բոլորը ծրագրավորողների կարիք ունեն, և բոլորին պետք են լավ ծրագրավորողներ, շուկան հասկանում է, թե ով ինչ արժե. ոլորտը տեղավորվել է: Այս օրերին DevOps-ի դեպքում այդպես չէ:
— Լսածիցս եզրակացրեցի, որ ներկայիս համակարգի ադմինիստրատորը չպետք է շատ անհանգստանա, այլ ժամանակն է բարելավելու իր հմտությունները և պատրաստվելու նրան, որ վաղը ավելի շատ աշխատանք է լինելու, բայց ավելի բարձր որակավորում ունեցող:
Dmitry: Հարյուր տոկոս. Ընդհանուր առմամբ, մենք ապրում ենք 2019 թվականին, և կյանքի կանոնը հետևյալն է. ցմահ ուսուցում - մենք սովորում ենք մեր ողջ կյանքի ընթացքում. Ինձ թվում է, որ այժմ բոլորն արդեն գիտեն և զգում են դա, բայց դա բավարար չէ իմանալը, դուք պետք է դա անեք: Ամեն օր մենք պետք է փոխվենք։ Եթե մենք դա չանենք, ապա վաղ թե ուշ մեզ կնվազեն մասնագիտության կողքին:
Պատրաստվեք կտրուկ 180 աստիճանի շրջադարձերի։ Չեմ բացառում մի իրավիճակ, երբ ինչ-որ բան արմատապես փոխվի, ինչ-որ նոր բան հորինվի, դա տեղի է ունենում: Հոփ - և մենք հիմա այլ կերպ ենք գործում: Կարևոր է պատրաստ լինել դրան և չանհանգստանալ։ Կարող է պատահել, որ վաղն այն ամենն, ինչ անում եմ, անհարկի դառնա՝ ոչինչ, ես ամբողջ կյանքս սովորել եմ և պատրաստ եմ այլ բան սովորել։ Դա խնդիր չէ։ Աշխատանքի անվտանգությունից վախենալ պետք չէ, բայց պետք է պատրաստ լինել անընդհատ նոր բան սովորելու։
Մաղթանքներ և մեկ րոպե գովազդ
-Ցանկություն ունե՞ք։
DmitryԱյո, ես մի քանի ցանկություն ունեմ։
Առաջին և առևտրային - բաժանորդագրվել . Հարգելի ընթերցողներ, այցելեք YouTube և բաժանորդագրվեք մեր ալիքին: Մոտ մեկ ամսից մենք կսկսենք ակտիվ ընդլայնել վիդեո ծառայությունը: Մենք կունենանք շատ կրթական բովանդակություն Kubernetes-ի մասին՝ բաց և բազմազան. սկզբունքների և օրինաչափությունների մակարդակ:
Երկրորդ մերկանտիլ ցանկությունը՝ գնալ դեպի և աստղեր դնել, քանի որ մենք սնվում ենք դրանցով: Եթե մեզ աստղեր չտաք, մենք ուտելու բան չենք ունենա։ Դա նման է մանայի համակարգչային խաղում: Մենք ինչ-որ բան անում ենք, անում ենք, փորձում ենք, մեկն ասում է, որ դրանք սարսափելի հեծանիվներ են, ինչ-որ մեկը, որ ամեն ինչ ամբողջովին սխալ է, բայց մենք շարունակում ենք և գործում բացարձակ ազնիվ։ Մենք խնդիր ենք տեսնում, լուծում և կիսվում ենք մեր փորձով։ Հետևաբար, մեզ աստղ տվեք, այն ձեզանից չի հեռանա, այլ կգա մեզ մոտ, որովհետև մենք սնվում ենք նրանցով:
Երրորդ, կարևոր և այլևս ոչ առևտրային ցանկությունը. դադարեք հավատալ հեքիաթներին. Դուք պրոֆեսիոնալներ եք։ DevOps-ը շատ լուրջ և պատասխանատու մասնագիտություն է։ Դադարեք խաղալ աշխատավայրում: Թող այն սեղմի ձեզ համար, և դուք դա կհասկանաք: Պատկերացրեք, որ դուք գալիս եք հիվանդանոց, և այնտեղ բժիշկը փորձարկում է ձեր վրա։ Ես հասկանում եմ, որ սա կարող է վիրավորական լինել ինչ-որ մեկի համար, բայց, ամենայն հավանականությամբ, դա քո մասին չէ, այլ ուրիշի: Ուրիշներին էլ ասա կանգ առնեն։ Սա իսկապես կործանում է բոլորիս կյանքը. շատերը սկսում են օպերացիաներին, ադմիններին և DevOps-ներին վերաբերվել որպես տղաների, ովքեր նորից ինչ-որ բան կոտրել են: Սա ամենից հաճախ «կոտրվում էր» այն պատճառով, որ մենք գնում էինք խաղալու, և սառը գիտակցությամբ չէինք նայում, որ այսպես է, և այդպես է։
Սա չի նշանակում, որ դուք չպետք է փորձեր կատարեք: Պետք է փորձարկել, մենք ինքներս ենք դա անում։ Անկեղծ ասած, մենք ինքներս երբեմն խաղեր ենք խաղում. սա, իհարկե, շատ վատ է, բայց մարդկային ոչինչ մեզ խորթ չէ։ Եկեք 2019 թվականը հայտարարենք լուրջ, մտածված փորձերի, այլ ոչ թե արտադրության խաղերի տարի։ Հավանաբար այդպես է։
- Շատ շնորհակալություն!
DmitryՇնորհակալություն, Վիտալի, և՛ ժամանակի, և՛ հարցազրույցի համար։ Հարգելի ընթերցողներ, շատ շնորհակալ եմ, եթե հանկարծ հասաք այս կետին: Հուսով եմ, որ մենք ձեզ գոնե մի երկու միտք ենք բերել։
Հարցազրույցում Դմիտրին անդրադարձել է վերֆի խնդրին։ Այժմ սա ունիվերսալ շվեյցարական դանակ է, որը լուծում է գրեթե բոլոր խնդիրները: Բայց միշտ չէ, որ այդպես է եղել։ Վրա փառատոնին Դմիտրի Ստոլյարովը ձեզ մանրամասն կպատմի այս գործիքի մասին։ հաշվետվության մեջ կլինեն ամեն ինչ՝ խնդիրներ և Kubernetes-ի թաքնված նրբերանգներ, այս դժվարությունների լուծման տարբերակները և մանրամասնորեն «werf»-ի ներկայիս իրականացումը: Միացե՛ք մեզ մայիսի 27-ին և 28-ին, մենք կստեղծենք կատարյալ գործիքներ։
Source: www.habr.com