Bu hekayə istehsal mühitində, xüsusən Kubernetesdə konteynerlərdən necə istifadə etdiyimizdən bəhs edir. Məqalə konteynerlərdən ölçü və jurnalların toplanmasına, eləcə də şəkillərin qurulmasına həsr edilmişdir.

Biz B2B və B2C üçün onlayn ticarət və fintech məhsulları üçün xidmətlər hazırlayan Exness fintech şirkətindənik. Ar-Ge bölməmizdə bir çox fərqli komanda var, inkişaf departamentində 100+ işçi var.

Biz tərtibatçılarımızın kod toplaması və işlətməsi üçün platformaya cavabdeh olan komandanı təmsil edirik. Xüsusilə, biz tətbiqlərdən ölçüləri, qeydləri və hadisələri toplamaq, saxlamaq və hesabat vermək üçün məsuliyyət daşıyırıq. Hazırda biz istehsal mühitində təxminən üç min Docker konteynerini işlədirik, 50 TB böyük məlumat yaddaşımızı saxlayırıq və infrastrukturumuzun ətrafında qurulmuş memarlıq həlləri təqdim edirik: Kubernetes, Rancher və müxtəlif ictimai bulud provayderləri. 

Bizim motivasiyamız

Nə yanır? Heç kim cavab verə bilməz. Ocaq haradadır? Bunu başa düşmək çətindir. Nə vaxt yandı? Siz öyrənə bilərsiniz, amma dərhal deyil. 

Niyə bəzi konteynerlər dayanıb, digərləri isə yıxılıb? Hansı konteyner günahkar idi? Axı qabların çölü eynidir, amma hər birinin içində öz Neo var.

Tərtibatçılarımız bacarıqlı uşaqlardır. Şirkətə qazanc gətirən yaxşı xidmətlər göstərirlər. Ancaq tətbiqləri olan konteynerlər yoldan çıxdıqda uğursuzluqlar olur. Bir konteyner çox CPU istehlak edir, digəri şəbəkəni istehlak edir, üçüncüsü I/O əməliyyatlarını istehlak edir, dördüncüsü isə rozetkalarla nə etdiyi tamamilə aydın deyil. Hamısı düşür və gəmi batır. 

Agentlər

İçəridə nə baş verdiyini anlamaq üçün agentləri birbaşa konteynerlərə yerləşdirməyə qərar verdik.

Bu agentlər konteynerləri bir-birini sındırmayan vəziyyətdə saxlayan məhdudlaşdırıcı proqramlardır. Agentlər standartlaşdırılıb və bu, konteynerlərə xidmət göstərmək üçün standart yanaşmaya imkan verir. 

Bizim vəziyyətimizdə agentlər standart formatda, etiketlənmiş və sıxılmış logları təqdim etməlidirlər. Onlar həmçinin bizə biznes tətbiqi baxımından genişləndirilə bilən standartlaşdırılmış ölçüləri təqdim etməlidirlər.

Agentlər həmçinin müxtəlif təsvirləri (Debian, Alpine, Centos və s.) dəstəkləyən müxtəlif orkestr sistemlərində işləyə bilən əməliyyat və texniki xidmət üçün kommunalları nəzərdə tutur.

Nəhayət, agentlər Docker fayllarını ehtiva edən sadə CI/CD-ni dəstəkləməlidirlər. Əks təqdirdə, gəmi dağılacaq, çünki konteynerlər "əyri" relslər boyunca çatdırılmağa başlayacaq.

Proses və hədəf görüntü cihazı qurun

Hər şeyi standart və idarə edilə bilən saxlamaq üçün bir növ standart qurma prosesinə riayət etmək lazımdır. Buna görə konteynerləri konteynerlərlə toplamaq qərarına gəldik - bu, rekursiyadır.

Burada qablar möhkəm konturlarla təmsil olunur. Eyni zamanda, "həyat moruq kimi görünməməsi" üçün onlara paylama dəstləri qoymağa qərar verdilər. Bunun niyə edildiyini aşağıda izah edəcəyik.
 
Nəticə bir qurma alətidir - xüsusi paylama versiyalarına və xüsusi skript versiyalarına istinad edən versiyaya xüsusi konteyner.

Biz ondan necə istifadə edirik? Bizdə konteyner olan Docker Hub var. Xarici asılılıqlardan qurtulmaq üçün onu sistemimizin daxilində əks etdiririk. Nəticə sarı ilə işarələnmiş bir qabdır. Konteynerə lazım olan bütün paylamaları və skriptləri quraşdırmaq üçün şablon yaradırıq. Bundan sonra biz istifadəyə hazır təsviri yığırıq: tərtibatçılar ona kod və bəzi xüsusi asılılıqlarını qoyurlar. 

Bu yanaşmada nə yaxşıdır? 

• Birincisi, qurma alətlərinin tam versiyasına nəzarət - konteyner, skript və paylama versiyalarını qurmaq. 
• İkincisi, biz standartlaşmaya nail olduq: şablonları, aralıq və istifadəyə hazır təsvirləri eyni şəkildə yaradırıq. 
• Üçüncüsü, konteynerlər bizə daşınma qabiliyyəti verir. Bu gün biz Gitlab-dan istifadə edirik, sabah isə TeamCity və ya Jenkins-ə keçəcəyik və konteynerlərimizi eyni şəkildə işlədə biləcəyik. 
• Dördüncüsü, asılılıqların minimuma endirilməsi. Konteynerə paylama dəstləri qoymağımız təsadüfi deyildi, çünki bu, hər dəfə onları İnternetdən yükləməkdən qaçmağa imkan verir. 
• Beşincisi, qurma sürəti artdı - şəkillərin yerli nüsxələrinin olması yerli görüntü olduğundan yükləməyə vaxt itirməməyə imkan verir. 

Başqa sözlə, biz idarə olunan və çevik montaj prosesinə nail olduq. İstənilən tam versiyalı konteynerlər yaratmaq üçün eyni alətlərdən istifadə edirik. 

Quraşdırma prosedurumuz necə işləyir

Montaj bir komanda ilə işə salınır, proses şəkildə həyata keçirilir (qırmızı rənglə vurğulanır). Tərtibatçının Docker faylı var (sarı ilə vurğulanmışdır), biz dəyişənləri dəyərlərlə əvəz edərək onu təqdim edirik. Və yol boyu biz başlıqlar və altbilgilər əlavə edirik - bunlar bizim agentlərimizdir. 

Başlıq müvafiq şəkillərdən paylamalar əlavə edir. Və altbilgi xidmətlərimizi içəridə quraşdırır, iş yükünün işə salınmasını, giriş və digər agentləri konfiqurasiya edir, giriş nöqtəsini əvəz edir və s. 

Uzun müddət düşündük ki, nəzarətçi quraşdıraqmı. Sonda qərara gəldik ki, ona ehtiyacımız var. S6 seçdik. Nəzarətçi konteynerin idarə edilməsini təmin edir: əsas proses qəzaya uğradıqda ona qoşulmağa imkan verir və konteyneri yenidən yaratmadan əl ilə idarə olunmasını təmin edir. Qeydlər və ölçülər konteynerin içərisində işləyən proseslərdir. Onlara da bir şəkildə nəzarət etmək lazımdır və biz bunu nəzarətçinin köməyi ilə edirik. Nəhayət, S6 ev işləri, siqnalların işlənməsi və digər tapşırıqları yerinə yetirir.

Fərqli orkestrasiya sistemlərindən istifadə etdiyimiz üçün, tikinti və işə salındıqdan sonra konteyner hansı mühitdə olduğunu anlamalı və vəziyyətə uyğun hərəkət etməlidir. Misal üçün:
Bu, bizə bir görüntü yaratmağa və onu müxtəlif orkestrləşdirmə sistemlərində işlətməyə imkan verir və o, bu orkestrləşdirmə sisteminin xüsusiyyətləri nəzərə alınmaqla işə salınacaq.

 

Eyni konteyner üçün Docker və Kubernetes-də fərqli proses ağacları alırıq:

Faydalı yük S6 nəzarəti altında həyata keçirilir. Kollektor və hadisələrə diqqət yetirin - bunlar qeydlər və ölçülərə cavabdeh olan agentlərimizdir. Kubernetesdə bunlar yoxdur, lakin Docker var. Niyə? 

“Pod”un (bundan sonra – Kubernetes pod) spesifikasiyasına baxsaq, hadisələr konteynerinin ölçülər və qeydlərin toplanması funksiyasını yerinə yetirən ayrıca kollektor konteyneri olan podda icra olunduğunu görərik. Biz Kubernetes-in imkanlarından istifadə edə bilərik: konteynerləri bir podda, tək prosesdə və/və ya şəbəkə məkanında işlədirik. Əslində agentlərinizi təqdim edin və bəzi funksiyaları yerinə yetirin. Eyni konteyner Docker-də işə salınarsa, o, çıxış kimi bütün eyni imkanları alacaq, yəni agentlər daxildə işə salınacağı üçün qeydləri və ölçüləri çatdıra biləcək. 

Metriklər və qeydlər

Ölçüləri və qeydləri çatdırmaq mürəkkəb bir işdir. Onun qərarının bir neçə aspekti var.
İnfrastruktur logların kütləvi çatdırılması üçün deyil, faydalı yükün icrası üçün yaradılmışdır. Yəni, bu proses minimum konteyner resursu tələbləri ilə həyata keçirilməlidir. Biz tərtibatçılarımıza kömək etməyə çalışırıq: "Docker Hub konteyneri alın, onu işə salın və biz qeydləri çatdıra bilərik." 

İkinci aspekt logların həcmini məhdudlaşdırmaqdır. Əgər logların həcmində artım bir neçə konteynerdə baş verərsə (tətbiq bir döngədə stack-trace çıxarır), CPU-ya, rabitə kanallarına və log emalı sisteminə yük artır və bu, hostun işinə təsir göstərir. bütövlükdə və ev sahibinin digər qabları, sonra bəzən bu ev sahibinin "düşməsinə" səbəb olur. 

Üçüncü cəhət ondan ibarətdir ki, qutudan mümkün qədər çox ölçü toplama metodunu dəstəkləmək lazımdır. Faylları oxumaqdan və Prometheus-endpoint-in sorğusundan tutmuş proqrama xüsusi protokolların istifadəsinə qədər.

Və sonuncu aspekt resurs istehlakını minimuma endirməkdir.

Teleqraf adlı açıq mənbəli Go həllini seçdik. Bu, 140-dan çox giriş kanalını (giriş plaginləri) və 30 növ çıxış kanalını (çıxış plaginləri) dəstəkləyən universal bağlayıcıdır. Biz onu yekunlaşdırdıq və indi Kubernetes-dən nümunə olaraq necə istifadə etdiyimizi sizə xəbər verəcəyik. 

Deyək ki, tərtibatçı iş yükünü yerləşdirir və Kubernetes pod yaratmaq üçün sorğu alır. Bu nöqtədə, hər bir pod üçün Kollektor adlı konteyner avtomatik olaraq yaradılır (biz mutasiya webhook istifadə edirik). Kollektor bizim agentimizdir. Başlanğıcda bu konteyner özünü Prometey və log toplama sistemi ilə işləmək üçün konfiqurasiya edir.

• Bunun üçün o, pod annotasiyalarından istifadə edir və məzmunundan asılı olaraq, deyək ki, Prometey son nöqtəsini yaradır; 
• Pod spesifikasiyasına və xüsusi konteyner parametrlərinə əsaslanaraq, jurnalların necə çatdırılacağına qərar verir.

Biz jurnalları Docker API vasitəsilə toplayırıq: tərtibatçılar sadəcə onları stdout və ya stderr-ə yerləşdirməlidirlər və Kollektor onu sıralayacaq. Mümkün host yüklənməsinin qarşısını almaq üçün qeydlər bir qədər gecikmə ilə parçalara yığılır. 

Metriklər konteynerlərdəki iş yükü nümunələri (prosesləri) üzrə toplanır. Hər şey etiketlənir: ad sahəsi, altında və s., sonra Prometheus formatına çevrilir - və kolleksiya üçün əlçatan olur (loglardan başqa). Biz həmçinin qeydləri, ölçüləri və hadisələri Kafkaya və daha çox göndəririk:

• Qeydlər Graylog-da mövcuddur (vizual analiz üçün);
• Qeydlər, ölçülər, hadisələr uzunmüddətli saxlama üçün Clickhouse-a göndərilir.

AWS-də hər şey tam olaraq eyni işləyir, yalnız biz Graylogu Kafka ilə Cloudwatch ilə əvəz edirik. Günlükləri ora göndəririk və hər şey çox əlverişlidir: onların hansı klasterə və konteynerə aid olduğu dərhal aydın olur. Eyni şey Google Stackdriver üçün də keçərlidir. Yəni bizim sxemimiz həm Kafka ilə həm yerli, həm də buludda işləyir. 

Podları olan Kubernetlərimiz yoxdursa, sxem bir az daha mürəkkəbdir, lakin eyni prinsiplər üzərində işləyir.

Eyni proseslər konteynerin içərisində həyata keçirilir, onlar S6 istifadə edərək təşkil edilir. Bütün eyni proseslər eyni konteynerdə aparılır.

Nəticədə,

Biz qeydlərin və ölçülərin toplanması və çatdırılması variantları ilə şəkillərin yaradılması və işə salınması üçün tam bir həll yaratdıq:

• Biz şəkillərin yığılması üçün standartlaşdırılmış yanaşma işləyib hazırladıq və bunun əsasında CI şablonlarını hazırladıq;
• Məlumat toplama agentləri bizim Teleqraf əlavələrimizdir. Biz onları istehsalda yaxşı sınaqdan keçirdik;
• Biz podlarda agentləri olan konteynerləri həyata keçirmək üçün mutasiya webhook istifadə edirik; 
• Kubernetes/Rancher ekosisteminə inteqrasiya olunub;
• Eyni konteynerləri müxtəlif orkestrləşdirmə sistemlərində icra edə və gözlədiyimiz nəticəni əldə edə bilərik;
• Tamamilə dinamik konteyner idarəetmə konfiqurasiyası yaradıldı. 

Həmmüəllif: İlya Prudnikov

Mənbə: www.habr.com