Bu hikoya ishlab chiqarish muhitida, xususan Kubernetesda konteynerlardan qanday foydalanishimiz haqida. Maqola konteynerlardan o'lchovlar va jurnallarni yig'ish, shuningdek, tasvirlarni yaratishga bag'ishlangan.

Biz B2B va B2C uchun onlayn savdo va fintech mahsulotlari uchun xizmatlarni ishlab chiqadigan Exness fintech kompaniyasidanmiz. Bizning ilmiy-tadqiqot ishlarimiz juda ko'p turli guruhlarga ega, rivojlanish bo'limida 100 dan ortiq xodimlar mavjud.

Biz dasturchilarimiz kodni to'plash va ishga tushirish uchun platforma uchun mas'ul bo'lgan jamoani vakilimiz. Xususan, biz ilovalardan o'lchovlar, jurnallar va hodisalarni yig'ish, saqlash va hisobot berish uchun javobgarmiz. Biz hozirda taxminan uch ming Docker konteynerini ishlab chiqarish muhitida ishlatamiz, 50 TB hajmdagi katta maʼlumotlar saqlashimizni taʼminlaymiz va infratuzilmamiz atrofida qurilgan meʼmoriy yechimlarni taqdim etamiz: Kubernetes, Rancher va turli ommaviy bulut provayderlari. 

Bizning motivatsiyamiz

Nima yonmoqda? Hech kim javob bera olmaydi. O'choq qayerda? Buni tushunish qiyin. Qachon yonib ketdi? Siz bilib olishingiz mumkin, lekin darhol emas. 

Nima uchun ba'zi konteynerlar turibdi, boshqalari tushib ketgan? Qaysi konteyner aybdor edi? Axir, idishlarning tashqi tomoni bir xil, lekin har birining ichida o'z Neo mavjud.

Ishlab chiquvchilarimiz malakali yigitlardir. Ular kompaniyaga foyda keltiradigan yaxshi xizmatlarni ko'rsatadilar. Ammo ilovalar bilan konteynerlar noto'g'ri ketganda muvaffaqiyatsizliklar mavjud. Bitta konteyner juda ko'p CPU iste'mol qiladi, ikkinchisi tarmoqni iste'mol qiladi, uchinchisi kiritish-chiqarish operatsiyalarini iste'mol qiladi, to'rtinchisi esa rozetkalar bilan nima qilishini mutlaqo tushunarsiz. Hammasi qulab tushadi va kema cho'kadi. 

Agentliklar

Ichkarida nima bo'layotganini tushunish uchun biz agentlarni to'g'ridan-to'g'ri konteynerlarga joylashtirishga qaror qildik.

Ushbu agentlar konteynerlarni bir-birini buzmaydigan holatda saqlaydigan cheklovchi dasturlardir. Agentlar standartlashtirilgan va bu konteynerlarga xizmat ko'rsatishda standartlashtirilgan yondashuvga imkon beradi. 

Bizning holatda, agentlar jurnallarni standart formatda, teglangan va qisqartirilgan holda taqdim etishlari kerak. Shuningdek, ular bizga biznes dasturlari nuqtai nazaridan kengaytirilishi mumkin bo'lgan standartlashtirilgan ko'rsatkichlarni taqdim etishlari kerak.

Agentlar, shuningdek, turli xil tasvirlarni (Debian, Alpine, Centos va boshqalar) qo'llab-quvvatlaydigan turli orkestr tizimlarida ishlashi mumkin bo'lgan foydalanish va texnik xizmat ko'rsatish uchun yordamchi dasturlarni anglatadi.

Va nihoyat, agentlar Docker fayllarini o'z ichiga olgan oddiy CI/CD-ni qo'llab-quvvatlashlari kerak. Aks holda, kema parchalanadi, chunki konteynerlar "qiyshiq" relslar bo'ylab etkazib berila boshlaydi.

Qurilish jarayoni va maqsadli tasvir qurilmasi

Hamma narsani standartlashtirilgan va boshqarish mumkin bo'lishi uchun qandaydir standart qurish jarayoniga rioya qilish kerak. Shuning uchun biz konteynerlarni konteynerlar bilan yig'ishga qaror qildik - bu rekursiya.

Bu erda konteynerlar qattiq konturlar bilan ifodalanadi. Shu bilan birga, ular "hayot malina kabi ko'rinmasligi" uchun ularga tarqatish to'plamlarini qo'yishga qaror qilishdi. Nima uchun bu amalga oshirildi, biz quyida tushuntiramiz.
 
Natijada yaratish vositasi - ma'lum tarqatish versiyalari va maxsus skript versiyalariga havola qiluvchi versiyaga xos konteyner.

Biz undan qanday foydalanamiz? Bizda konteynerni o'z ichiga olgan Docker Hub mavjud. Biz tashqi qaramlikdan xalos bo'lish uchun uni tizimimizda aks ettiramiz. Natijada sariq rang bilan belgilangan idish paydo bo'ladi. Biz konteynerga kerak bo'lgan barcha tarqatish va skriptlarni o'rnatish uchun shablon yaratamiz. Shundan so'ng biz foydalanishga tayyor tasvirni yig'amiz: ishlab chiquvchilar unga kod va o'zlarining maxsus bog'liqliklarini qo'yishadi. 

Bu yondashuvning nimasi yaxshi? 

• Birinchidan, qurish vositalarining to'liq versiyasini boshqarish - qurish konteyneri, skript va tarqatish versiyalari. 
• Ikkinchidan, biz standartlashtirishga erishdik: shablonlarni, oraliq va foydalanishga tayyor tasvirni xuddi shu tarzda yaratamiz. 
• Uchinchidan, konteynerlar bizga portativlikni beradi. Bugun biz Gitlab-dan foydalanamiz, ertaga esa TeamCity yoki Jenkins-ga o'tamiz va konteynerlarimizni xuddi shu tarzda boshqara olamiz. 
• To'rtinchidan, qaramlikni minimallashtirish. Biz tarqatish to'plamlarini konteynerga joylashtirganimiz tasodif emas edi, chunki bu har safar ularni Internetdan yuklab olishdan qochish imkonini beradi. 
• Beshinchidan, qurish tezligi oshdi - rasmlarning mahalliy nusxalarining mavjudligi yuklab olish uchun vaqtni behuda sarflamaslik imkonini beradi, chunki mahalliy tasvir mavjud. 

Boshqacha qilib aytganda, biz boshqariladigan va moslashuvchan yig'ish jarayoniga erishdik. Biz har qanday to'liq versiyali konteynerlarni qurish uchun bir xil vositalardan foydalanamiz. 

Bizning qurilish protseduramiz qanday ishlaydi

Yig'ish bitta buyruq bilan ishga tushiriladi, jarayon rasmda bajariladi (qizil rang bilan ta'kidlangan). Ishlab chiquvchida Docker fayli mavjud (sariq rang bilan ajratilgan), biz uni o'zgaruvchilarni qiymatlar bilan almashtiramiz. Va yo'lda biz sarlavhalar va altbilgilarni qo'shamiz - bu bizning agentlarimiz. 

Sarlavha tegishli rasmlardan taqsimotlarni qo'shadi. Va altbilgi bizning xizmatlarimizni ichkariga o'rnatadi, ish yukini, jurnalni va boshqa agentlarni ishga tushirishni sozlaydi, kirish nuqtasini almashtiradi va hokazo. 

Biz uzoq vaqt davomida nazoratchi o'rnatishni o'yladik. Oxir-oqibat, biz u bizga kerak deb qaror qildik. Biz S6 ni tanladik. Nazoratchi konteyner boshqaruvini ta'minlaydi: agar asosiy jarayon ishlamay qolsa, unga ulanish imkonini beradi va konteynerni qayta yaratmasdan qo'lda boshqarishni ta'minlaydi. Jurnallar va ko'rsatkichlar konteyner ichida ishlaydigan jarayonlardir. Ular ham qandaydir tarzda nazorat qilinishi kerak va biz buni nazoratchi yordamida qilamiz. Nihoyat, S6 uy ishlari, signallarni qayta ishlash va boshqa vazifalarni bajaradi.

Biz turli xil orkestratsiya tizimlaridan foydalanganimiz sababli, qurish va ishga tushirishdan keyin konteyner qanday muhitda ekanligini tushunishi va vaziyatga qarab harakat qilishi kerak. Masalan:
Bu bizga bitta tasvirni yaratish va uni turli orkestrlash tizimlarida ishga tushirish imkonini beradi va u ushbu orkestrlash tizimining o'ziga xos xususiyatlarini hisobga olgan holda ishga tushiriladi.

 

Xuddi shu konteyner uchun biz Docker va Kubernetes-da turli xil texnologik daraxtlarni olamiz:

Foydali yuk S6 nazorati ostida amalga oshiriladi. Kollektor va voqealarga e'tibor bering - bu bizning agentlarimiz jurnallar va ko'rsatkichlar uchun javobgardir. Kubernetesda ular yo'q, lekin Docker bor. Nega? 

Agar biz "pod" (keyingi o'rinlarda - Kubernetes pod) spetsifikatsiyasini ko'rib chiqsak, hodisalar konteyneri ko'rsatkichlar va jurnallarni yig'ish funktsiyasini bajaradigan alohida kollektor konteyneriga ega bo'lgan podda bajarilganligini ko'ramiz. Biz Kubernetes imkoniyatlaridan foydalanishimiz mumkin: konteynerlarni bir podda, bitta jarayonda va/yoki tarmoq maydonida ishga tushirish. Aslida agentlaringizni tanishtiring va ba'zi funktsiyalarni bajaring. Va agar xuddi shu konteyner Docker-da ishga tushirilsa, u chiqish bilan bir xil imkoniyatlarga ega bo'ladi, ya'ni u jurnallar va ko'rsatkichlarni etkazib bera oladi, chunki agentlar ichki ishga tushiriladi. 

Ko'rsatkichlar va jurnallar

Ko'rsatkichlar va jurnallarni etkazib berish murakkab vazifadir. Uning qarorida bir nechta jihatlar bor.
Infratuzilma jurnallarni ommaviy yetkazib berish uchun emas, balki foydali yukni bajarish uchun yaratilgan. Ya'ni, bu jarayon minimal konteyner resurslari talablari bilan amalga oshirilishi kerak. Biz ishlab chiquvchilarimizga yordam berishga intilamiz: "Docker Hub konteynerini oling, uni ishga tushiring va biz jurnallarni yetkazib bera olamiz." 

Ikkinchi jihat - jurnallar hajmini cheklash. Agar jurnallar hajmining ko'tarilishi bir nechta konteynerlarda sodir bo'lsa (ilova tsiklda stek-izni chiqaradi), protsessorga, aloqa kanallariga va jurnalni qayta ishlash tizimiga yuk ortadi va bu xostning ishlashiga ta'sir qiladi. uy egasida butun va boshqa idishlar, keyin ba'zan bu uy egasining "tushilishiga" olib keladi. 

Uchinchi jihat shundaki, qutidan tashqarida imkon qadar ko'proq o'lchovlarni yig'ish usullarini qo'llab-quvvatlash kerak. Fayllarni o'qish va Prometey so'nggi nuqtasini so'rashdan tortib, ilovaga maxsus protokollardan foydalanishgacha.

Va oxirgi jihat - resurslarni iste'mol qilishni minimallashtirish.

Biz Telegraf deb nomlangan ochiq manbali Go yechimini tanladik. Bu 140 dan ortiq turdagi kirish kanallarini (kirish plaginlari) va 30 turdagi chiqish kanallarini (chiqish plaginlari) qo'llab-quvvatlaydigan universal ulagichdir. Biz buni yakunladik va endi biz buni Kubernetes misolida qanday ishlatishimizni aytib beramiz. 

Aytaylik, ishlab chiquvchi ish yukini joylashtiradi va Kubernetes pod yaratish so'rovini oladi. Ushbu nuqtada har bir pod uchun Kollektor deb nomlangan konteyner avtomatik ravishda yaratiladi (biz mutatsiya webhookidan foydalanamiz). Kollektor bizning agentimiz. Dastlab, bu konteyner o'zini Prometey va jurnallarni yig'ish tizimi bilan ishlash uchun sozlaydi.

• Buning uchun u pod annotatsiyalaridan foydalanadi va uning mazmuniga qarab, aytaylik, Prometey so'nggi nuqtasini yaratadi; 
• Pod spetsifikatsiyasi va maxsus konteyner sozlamalariga asoslanib, u jurnallarni qanday etkazib berishni hal qiladi.

Biz jurnallarni Docker API orqali to'playmiz: ishlab chiquvchilar ularni stdout yoki stderr-ga qo'yishlari kerak va Kollektor uni tartibga soladi. Xostning ortiqcha yuklanishining oldini olish uchun jurnallar biroz kechikish bilan qismlarga yig'iladi. 

Ko'rsatkichlar konteynerlardagi ish yuki misollari (jarayonlar) bo'ylab to'planadi. Hammasi teglangan: nom maydoni, ostida va hokazo, keyin Prometey formatiga o'zgartiriladi - va yig'ish uchun mavjud bo'ladi (jurnallardan tashqari). Shuningdek, biz jurnallar, o'lchovlar va voqealarni Kafkaga yuboramiz va yana:

• Jurnallar Graylogda mavjud (vizual tahlil qilish uchun);
• Jurnallar, o'lchovlar, voqealar uzoq muddatli saqlash uchun Clickhouse-ga yuboriladi.

AWS da hamma narsa xuddi shunday ishlaydi, faqat biz Graylogni Kafka bilan Cloudwatch bilan almashtiramiz. Biz u erga jurnallarni yuboramiz va hamma narsa juda qulay bo'lib chiqadi: ular qaysi klaster va konteynerga tegishli ekanligi darhol aniq bo'ladi. Xuddi shu narsa Google Stackdriver uchun ham amal qiladi. Ya'ni, bizning sxemamiz Kafka bilan ham, bulutda ham ishlaydi. 

Agar bizda podalar bilan Kubernetlar bo'lmasa, sxema biroz murakkabroq, lekin u xuddi shu printsiplarda ishlaydi.

Xuddi shu jarayonlar konteyner ichida amalga oshiriladi, ular S6 yordamida tartibga solinadi. Barcha jarayonlar bir xil konteyner ichida ishlaydi.

Natijada

Biz jurnallar va koʻrsatkichlarni yigʻish va yetkazib berish imkoniyatlari bilan tasvirlarni yaratish va ishga tushirish uchun toʻliq yechim yaratdik:

• Biz tasvirlarni yig'ish uchun standartlashtirilgan yondashuvni ishlab chiqdik va uning asosida CI shablonlarini ishlab chiqdik;
• Ma'lumot yig'ish agentlari bizning Telegraf kengaytmalarimizdir. Biz ularni ishlab chiqarishda yaxshi sinovdan o'tkazdik;
• Biz mutatsion vebhukdan foydalanamiz va podlarda agentlari bo'lgan konteynerlarni amalga oshiramiz; 
• Kubernetes/Rancher ekotizimiga integratsiyalashgan;
• Biz bir xil konteynerlarni turli orkestrlash tizimlarida bajarishimiz va biz kutgan natijani olishimiz mumkin;
• To'liq dinamik konteyner boshqaruvi konfiguratsiyasi yaratildi. 

Hammuallif: Ilya Prudnikov

Manba: www.habr.com