Այս պատմությունն այն մասին է, թե ինչպես ենք մենք օգտագործում կոնտեյներներ արտադրական միջավայրում, մասնավորապես Kubernetes-ում: Հոդվածը նվիրված է բեռնարկղերից չափումների և տեղեկամատյանների հավաքագրմանը, ինչպես նաև պատկերների կառուցմանը:

Մենք Exness ֆինտեխ ընկերությունից ենք, որը մշակում է առցանց առևտրի ծառայություններ և ֆինտեխ ապրանքներ B2B և B2C համար: Մեր R&D-ն ունի բազմաթիվ տարբեր թիմեր, զարգացման բաժինն ունի 100+ աշխատակից:

Մենք ներկայացնում ենք այն թիմը, որը պատասխանատու է մեր մշակողների համար կոդ հավաքելու և գործարկելու հարթակի համար: Մասնավորապես, մենք պատասխանատու ենք հավելվածներից չափանիշների, տեղեկամատյանների և իրադարձությունների հավաքագրման, պահպանման և հաշվետվությունների համար: Ներկայումս մենք աշխատում ենք մոտավորապես երեք հազար Docker կոնտեյներներ արտադրական միջավայրում, պահպանում ենք մեր 50 TB մեծ տվյալների պահեստը և տրամադրում ենք ճարտարապետական ​​լուծումներ, որոնք կառուցված են մեր ենթակառուցվածքի շուրջ՝ Kubernetes, Rancher և տարբեր հանրային ամպային մատակարարներ: 

Մեր մոտիվացիան

Ի՞նչ է այրվում: Ոչ ոք չի կարող պատասխանել։ Որտեղ է օջախը: Դժվար է հասկանալ: Ե՞րբ է այն բռնկվել: Դուք կարող եք պարզել, բայց ոչ անմիջապես: 

Ինչո՞ւ են որոշ բեռնարկղեր կանգնած, իսկ մյուսներն ընկել են: Ո՞ր տարան էր մեղավոր։ Ի վերջո, տարաների արտաքին կողմը նույնն է, բայց ներսում յուրաքանչյուրն ունի իր Neo-ն:

Մեր մշակողները կոմպետենտ տղաներ են։ Նրանք լավ ծառայություններ են մատուցում, որոնք շահույթ են բերում ընկերությանը: Բայց կան ձախողումներ, երբ հավելվածներով տարաները մոլորվում են: Մի կոնտեյներ սպառում է չափազանց շատ պրոցեսոր, մյուսը սպառում է ցանցը, երրորդը սպառում է I/O գործառնությունները, իսկ չորրորդը լիովին անհասկանալի է, թե ինչ է անում վարդակների հետ: Ամեն ինչ ընկնում է, և նավը խորտակվում է: 

Գործակալներ

Հասկանալու համար, թե ինչ է կատարվում ներսում, մենք որոշեցինք գործակալները տեղադրել անմիջապես տարաների մեջ:

Այս գործակալները զսպող ծրագրեր են, որոնք կոնտեյներները պահում են այնպիսի վիճակում, որ նրանք միմյանց չկոտրեն։ Գործակալները ստանդարտացված են, և դա թույլ է տալիս ստանդարտացված մոտեցում ցուցաբերել բեռնարկղերի սպասարկմանը: 

Մեր դեպքում, գործակալները պետք է տրամադրեն տեղեկամատյանները ստանդարտ ձևաչափով, պիտակավորված և խափանված: Նրանք նաև պետք է մեզ տրամադրեն ստանդարտացված չափումներ, որոնք ընդարձակելի են բիզնեսի կիրառման տեսանկյունից:

Գործակալները նշանակում են նաև կոմունալ ծառայություններ շահագործման և պահպանման համար, որոնք կարող են աշխատել տարբեր նվագախմբային համակարգերում, որոնք աջակցում են տարբեր պատկերներ (Debian, Alpine, Centos և այլն):

Վերջապես, գործակալները պետք է աջակցեն պարզ CI/CD-ին, որը ներառում է Docker ֆայլերը: Հակառակ դեպքում նավը կքանդվի, քանի որ բեռնարկղերը կսկսեն առաքվել «ծուռ» ռելսերի երկայնքով։

Կառուցեք գործընթացի և թիրախային պատկերի սարքը

Ամեն ինչ ստանդարտացված և կառավարելի պահելու համար հարկավոր է հետևել որոշակի ստանդարտ կառուցման գործընթացին: Հետևաբար, մենք որոշեցինք բեռնարկղերը հավաքել տարաներով. սա ռեկուրսիա է:

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

Ինչպե՞ս ենք մենք օգտագործում այն: Մենք ունենք Docker Hub, որը պարունակում է կոնտեյներ: Մենք այն արտացոլում ենք մեր համակարգի ներսում՝ ազատվելու արտաքին կախվածություններից: Արդյունքը դեղինով նշված կոնտեյներ է: Մենք ստեղծում ենք ձևանմուշ՝ մեզ անհրաժեշտ բոլոր բաշխումները և սցենարները կոնտեյների մեջ տեղադրելու համար: Դրանից հետո մենք հավաքում ենք օգտագործման համար պատրաստ պատկեր. մշակողները դրանում տեղադրում են ծածկագիր և իրենց որոշ հատուկ կախվածություններ: 

Ի՞նչն է լավ այս մոտեցման մեջ: 

• Նախ, կառուցման գործիքների ամբողջական տարբերակի վերահսկում - կառուցեք կոնտեյներ, սցենար և բաշխման տարբերակներ: 
• Երկրորդ, մենք հասել ենք ստանդարտացման. նույն ձևով ստեղծում ենք կաղապարներ, միջանկյալ և պատրաստի պատկեր: 
• Երրորդ, բեռնարկղերը մեզ տալիս են շարժունակություն: Այսօր մենք օգտագործում ենք Gitlab-ը, իսկ վաղը մենք կանցնենք TeamCity-ին կամ Jenkins-ին և կկարողանանք նույն կերպ աշխատեցնել մեր կոնտեյներները: 
• Չորրորդ՝ նվազագույնի հասցնելով կախվածությունները: Պատահական չէր, որ մենք տարայի մեջ տեղադրեցինք բաշխիչ փաթեթներ, քանի որ դա թույլ է տալիս ամեն անգամ խուսափել դրանք ինտերնետից ներբեռնելուց։ 
• Հինգերորդ, կառուցման արագությունը մեծացել է. պատկերների տեղական պատճենների առկայությունը թույլ է տալիս խուսափել ներբեռնման վրա ժամանակ վատնելուց, քանի որ կա տեղական պատկեր: 

Այսինքն՝ մենք հասել ենք վերահսկվող և ճկուն հավաքման գործընթացի։ Մենք օգտագործում ենք նույն գործիքները, որպեսզի կառուցենք ցանկացած ամբողջական տարբերակված կոնտեյներ: 

Ինչպես է աշխատում մեր կառուցման ընթացակարգը

Ժողովը գործարկվում է մեկ հրամանով, գործընթացը կատարվում է պատկերում (կարմիրով ընդգծված): Մշակողը ունի Docker ֆայլ (դեղինով ընդգծված), մենք այն մատուցում ենք՝ փոփոխականները փոխարինելով արժեքներով։ Եվ ճանապարհին մենք ավելացնում ենք վերնագրեր և էջատակներ. սրանք մեր գործակալներն են: 

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

Երկար մտածում էինք՝ վերահսկիչ տեղադրե՞լ։ Ի վերջո, մենք որոշեցինք, որ նա մեզ պետք է։ Մենք ընտրեցինք S6-ը։ Վերահսկիչն ապահովում է կոնտեյների կառավարում. թույլ է տալիս միանալ դրան, եթե հիմնական պրոցեսը խափանվում է և ապահովում է կոնտեյների ձեռքով կառավարում՝ առանց այն վերստեղծելու: Տեղեկամատյանները և չափումները կոնտեյների ներսում գործող գործընթացներ են: Նրանք նույնպես պետք է ինչ-որ կերպ վերահսկվեն, և մենք դա անում ենք վերահսկողի օգնությամբ: Վերջապես, S6-ը հոգում է տնային տնտեսության, ազդանշանի մշակման և այլ խնդիրների մասին:

Քանի որ մենք օգտագործում ենք տարբեր նվագախմբային համակարգեր, կառուցելուց և գործարկելուց հետո կոնտեյները պետք է հասկանա, թե ինչ միջավայրում է գտնվում և գործի ըստ իրավիճակի։ Օրինակ:
Սա մեզ թույլ է տալիս կառուցել մեկ պատկեր և գործարկել այն տարբեր նվագախմբային համակարգերում, և այն կգործարկվի՝ հաշվի առնելով այս նվագախմբային համակարգի առանձնահատկությունները:

 

Նույն կոնտեյների համար մենք Docker-ում և Kubernetes-ում ստանում ենք տարբեր պրոցեսի ծառեր.

Օգտակար բեռը կատարվում է S6-ի հսկողության ներքո: Ուշադրություն դարձրեք հավաքողին և իրադարձություններին. սրանք մեր գործակալներն են, որոնք պատասխանատու են տեղեկամատյանների և չափումների համար: Kubernetes-ը դրանք չունի, բայց Docker-ն ունի: Ինչո՞ւ։ 

Եթե ​​նայենք «pod»-ի ճշգրտմանը (այսուհետ՝ Kubernetes pod), ապա կտեսնենք, որ իրադարձությունների կոնտեյները կատարվում է պատիճով, որն ունի առանձին կոլեկտորային կոնտեյներ, որը կատարում է չափումների և լոգերի հավաքման գործառույթը։ Մենք կարող ենք օգտագործել Kubernetes-ի հնարավորությունները. կոնտեյներներ գործարկել մեկ պատիճում, մեկ գործընթացում և/կամ ցանցային տարածքում: Փաստորեն ներկայացրեք ձեր գործակալներին և կատարեք որոշ գործառույթներ: Եվ եթե նույն կոնտեյները գործարկվի Docker-ում, ապա այն կստանա նույն բոլոր հնարավորությունները, ինչ ելքը, այսինքն՝ կկարողանա առաքել տեղեկամատյանները և չափումները, քանի որ գործակալները կգործարկվեն ներսում: 

Չափումներ և տեղեկամատյաններ

Չափումների և տեղեկամատյանների տրամադրումը բարդ խնդիր է: Նրա որոշման մեջ կան մի քանի ասպեկտներ.
Ենթակառուցվածքը ստեղծված է ծանրաբեռնվածության կատարման, այլ ոչ թե գերանների զանգվածային առաքման համար։ Այսինքն՝ այս գործընթացը պետք է իրականացվի կոնտեյներային ռեսուրսների նվազագույն պահանջներով։ Մենք ձգտում ենք օգնել մեր մշակողներին. «Ստացեք Docker Hub կոնտեյներ, գործարկեք այն, և մենք կարող ենք առաքել տեղեկամատյանները»: 

Երկրորդ ասպեկտը տեղեկամատյանների ծավալի սահմանափակումն է: Եթե ​​տեղեկամատյանների ծավալի մեծացում է տեղի ունենում մի քանի կոնտեյներով (հավելվածը թողարկում է ստաք-հետք հանգույցով), պրոցեսորի, կապի ալիքների և տեղեկամատյանների մշակման համակարգի բեռը մեծանում է, և դա ազդում է հոսթի աշխատանքի վրա՝ որպես ամբողջ և այլ տարաներ հյուրընկալողի վրա, ապա երբեմն դա հանգեցնում է տանտիրոջ «անկմանը»: 

Երրորդ ասպեկտն այն է, որ անհրաժեշտ է աջակցել չափումների հավաքագրման հնարավորինս շատ մեթոդներին: Ֆայլեր կարդալուց և Prometheus-endpoint-ի հարցումներից մինչև հավելվածի հատուկ արձանագրություններ օգտագործելը:

Եվ վերջին ասպեկտը ռեսուրսների սպառումը նվազագույնի հասցնելն է:

Մենք ընտրեցինք բաց կոդով Go լուծում, որը կոչվում է Telegraf: Սա ունիվերսալ միակցիչ է, որն աջակցում է ավելի քան 140 տեսակի մուտքային ալիքներ (մուտքագրման պլագիններ) և 30 տեսակի ելքային ալիքներ (ելքային պլագիններ): Մենք վերջնական տեսքի ենք բերել այն, և այժմ մենք ձեզ կասենք, թե ինչպես ենք այն օգտագործում Kubernetes-ի օրինակով: 

Ենթադրենք, մշակողը տեղակայում է աշխատանքային ծանրաբեռնվածություն, և Kubernetes-ը ստանում է փոդ ստեղծելու հարցում: Այս պահին յուրաքանչյուր pod-ի համար ավտոմատ կերպով ստեղծվում է մի կոնտեյներ, որը կոչվում է Կոլեկցիոներ (մենք օգտագործում ենք մուտացիոն վեբ-կեռիկ): Կոլեկցիոները մեր գործակալն է: Սկզբում այս բեռնարկղը կարգավորվում է Պրոմեթևսի և լոգերի հավաքման համակարգի հետ աշխատելու համար:

• Դա անելու համար այն օգտագործում է pod ծանոթագրություններ, և կախված իր բովանդակությունից՝ ստեղծում է, ասենք, Պրոմեթևսի վերջնակետ; 
• Ելնելով պատյանների ճշգրտումից և կոնտեյների հատուկ կարգավորումներից՝ այն որոշում է, թե ինչպես մատուցել տեղեկամատյանները:

Մենք հավաքում ենք տեղեկամատյանները Docker API-ի միջոցով. մշակողները պարզապես պետք է տեղադրեն դրանք stdout կամ stderr-ում, և Collector-ը կկարգավորի այն: Տեղեկամատյանները հավաքվում են կտորներով՝ որոշակի ուշացումով, որպեսզի կանխեն հյուրընկալողի հնարավոր գերծանրաբեռնվածությունը: 

Չափիչները հավաքվում են բեռնարկղերում աշխատանքային ծանրաբեռնվածության դեպքերի (գործընթացների) վրա: Ամեն ինչ պիտակված է՝ անվանատարածք, տակ և այլն, այնուհետև փոխարկվում է Պրոմեթևսի ձևաչափի և հասանելի է դառնում հավաքագրման համար (բացառությամբ տեղեկամատյանների): Մենք նաև տեղեկամատյաններ, չափումներ և իրադարձություններ ենք ուղարկում Կաֆկային և հետագա՝

• Գրանցամատյանները հասանելի են Graylog-ում (տեսողական վերլուծության համար);
• Տեղեկամատյանները, չափումները, իրադարձությունները ուղարկվում են Clickhouse՝ երկարաժամկետ պահպանման համար:

AWS-ում ամեն ինչ նույնն է աշխատում, միայն մենք փոխարինում ենք Graylog-ը Kafka-ով Cloudwatch-ով: Մենք տեղեկամատյաններն ուղարկում ենք այնտեղ, և ամեն ինչ շատ հարմար է ստացվում. անմիջապես պարզ է, թե որ կլաստերին և կոնտեյներին են դրանք պատկանում: Նույնը վերաբերում է Google Stackdriver-ին: Այսինքն, մեր սխեման աշխատում է ինչպես Կաֆկայի հետ, այնպես էլ ամպի մեջ: 

Եթե ​​մենք չունենք Kubernetes հետ pods, սխեման մի փոքր ավելի բարդ է, բայց այն աշխատում է նույն սկզբունքներով:

Նույն գործընթացներն իրականացվում են կոնտեյների ներսում, դրանք կազմակերպվում են S6-ի միջոցով: Բոլոր նույն գործընթացներն ընթանում են նույն կոնտեյների ներսում:

Որպես հետեւանք,

Մենք ստեղծել ենք ամբողջական լուծում պատկերներ ստեղծելու և գործարկելու համար՝ տեղեկամատյանների և չափումների հավաքման և առաքման տարբերակներով.

• Մենք մշակեցինք պատկերների հավաքման ստանդարտացված մոտեցում, և դրա հիման վրա մշակեցինք CI ձևանմուշներ;
• Տվյալների հավաքագրման գործակալները մեր Telegraf-ի ընդլայնումն են: Մենք դրանք լավ փորձարկեցինք արտադրության մեջ.
• Մենք օգտագործում ենք մուտացիոն վեբ-կեռիկ՝ պատիճներում գործակալներով կոնտեյներներ տեղադրելու համար; 
• Ինտեգրված Kubernetes/Rancher էկոհամակարգում;
• Մենք կարող ենք կատարել նույն կոնտեյներները տարբեր նվագախմբային համակարգերում և ստանալ այն արդյունքը, որը մենք ակնկալում ենք.
• Ստեղծվել է կոնտեյների կառավարման ամբողջովին դինամիկ կոնֆիգուրացիա: 

Համահեղինակ. Իլյա Պրուդնիկով

Source: www.habr.com