Оваа приказна е за тоа како ги користиме контејнерите во производствена средина, конкретно Kubernetes. Статијата е посветена на собирање метрика и логови од контејнери, како и градење слики.

Ние сме од fintech компанијата Exness, која развива услуги за онлајн тргување и финтех производи за B2B и B2C. Нашето истражување и развој има многу различни тимови, одделот за развој има 100+ вработени.

Ние го претставуваме тимот кој е одговорен за платформата за нашите програмери да собираат и стартуваат код. Конкретно, ние сме одговорни за собирање, складирање и известување на метрика, дневници и настани од апликациите. Моментално работиме со приближно три илјади Docker контејнери во производствена средина, го одржуваме нашето складирање на големи податоци од 50 TB и обезбедуваме архитектонски решенија кои се изградени околу нашата инфраструктура: Kubernetes, Rancher и разни јавни даватели на облак. 

Нашата мотивација

Што гори? Никој не може да одговори. Каде е огништето? Тешко е да се разбере. Кога се запали? Можете да дознаете, но не веднаш. 

Зошто некои контејнери стојат додека други паднале? Кој сад беше виновен? На крајот на краиштата, надворешноста на контејнерите е иста, но внатре секој има свое Neo.

Нашите програмери се компетентни момци. Тие прават добри услуги кои носат профит за компанијата. Но, има неуспеси кога контејнерите со апликации одат на погрешен пат. Еден контејнер троши премногу процесор, друг ја троши мрежата, трет троши I/O операции, а четвртиот е целосно нејасно што прави со сокетите. Сето тоа паѓа и бродот тоне. 

Агенти

За да разбереме што се случува внатре, решивме да ставиме агенти директно во контејнери.

Овие средства се програми за ограничување кои ги држат контејнерите во таква состојба што не се кршат едни со други. Агентите се стандардизирани, а тоа овозможува стандардизиран пристап за сервисирање на контејнерите. 

Во нашиот случај, агентите мора да обезбедат дневници во стандарден формат, означени и пригушени. Тие, исто така, треба да ни обезбедат стандардизирани метрики што се проширливи од перспектива на деловна апликација.

Под агенти се подразбираат и алатки за работа и одржување кои можат да работат во различни системи за оркестрација кои поддржуваат различни слики (Debian, Alpine, Centos, итн.).

Конечно, агентите мора да поддржуваат едноставни CI/CD кои вклучуваат датотеки на Docker. Во спротивно, бродот ќе се распадне, бидејќи контејнерите ќе почнат да се испорачуваат по „криви“ шини.

Процес на градење и цел уред за слика

За да се задржи сè стандардизирано и управувано, треба да се следи некој вид стандарден процес на градење. Затоа, решивме да собираме контејнери по контејнери - ова е рекурзија.

Овде контејнерите се претставени со цврсти контури. Во исто време, тие одлучија да стават комплети за дистрибуција во нив за „животот да не изгледа како малини“. Зошто е направено ова, ќе објасниме подолу.
 
Резултатот е алатка за градење - контејнер специфичен за верзијата што упатува на специфични верзии на дистрибуција и специфични верзии на скрипти.

Како го користиме? Имаме Docker Hub кој содржи контејнер. Ние го пресликуваме во нашиот систем за да се ослободиме од надворешните зависности. Резултатот е контејнер означен со жолта боја. Ние создаваме шаблон за да ги инсталираме сите дистрибуции и скрипти што ни се потребни во контејнерот. После тоа, составуваме слика подготвена за употреба: програмерите ставаат код и некои од нивните посебни зависности во неа. 

Што е добро за овој пристап? 

• Прво, целосна контрола на верзијата на алатките за градење - изградба на контејнер, скрипта и верзии за дистрибуција. 
• Второ, постигнавме стандардизација: создаваме шаблони, средна и подготвена за употреба слика на ист начин. 
• Трето, контејнерите ни даваат преносливост. Денес користиме Gitlab, а утре ќе се префрлиме на TeamCity или Jenkins и ќе можеме да работиме со нашите контејнери на ист начин. 
• Четврто, минимизирање на зависностите. Не случајно ставивме комплети за дистрибуција во контејнерот, бидејќи тоа ни овозможува да избегнеме да ги преземаме од Интернет секој пат. 
• Петто, брзината на градење се зголеми - присуството на локални копии на слики ви овозможува да избегнете губење време при преземање, бидејќи има локална слика. 

Со други зборови, постигнавме контролиран и флексибилен процес на склопување. Ги користиме истите алатки за да изградиме какви било целосно верзии на контејнери. 

Како функционира нашата процедура за изградба

Склопот се стартува со една команда, процесот се извршува на сликата (означена со црвено). Програмерот има датотека Docker (означена со жолта боја), ја прикажуваме, заменувајќи ги променливите со вредности. И на патот додаваме заглавија и подножја - тоа се нашите агенти. 

Header додава дистрибуции од соодветните слики. И подножјето ги инсталира нашите услуги внатре, го конфигурира стартувањето на обемот на работа, евиденцијата и другите агенти, ја заменува влезната точка итн. 

Долго размислувавме дали да инсталираме супервизор. На крајот решивме дека ни е потребен. Избравме S6. Супервизорот обезбедува управување со контејнерот: ви овозможува да се поврзете со него ако главниот процес се урна и обезбедува рачно управување со контејнерот без повторно да го креирате. Дневниците и метриката се процеси што се извршуваат во контејнерот. И тие треба некако да се контролираат, а ние тоа го правиме со помош на претпоставен. Конечно, S6 се грижи за домаќинство, обработка на сигнали и други задачи.

Со оглед на тоа што користиме различни системи за оркестрација, по изградбата и трчањето, контејнерот мора да разбере во каква средина се наоѓа и да дејствува според ситуацијата. На пример:
Ова ни овозможува да изградиме една слика и да ја извршиме во различни системи за оркестрација, а таа ќе биде лансирана земајќи ги предвид спецификите на овој систем за оркестрација.

 

За истиот контејнер добиваме различни процесни дрвја во Docker и Kubernetes:

Товарот се извршува под надзор на S6. Обрнете внимание на собирачот и настаните - ова се нашите агенти одговорни за дневници и метрика. Кубернетис ги нема, но Докер ги има. Зошто? 

Ако ја погледнеме спецификацијата на „под“ (во натамошниот текст – Kubernetes pod), ќе видиме дека контејнерот за настани е извршен во подлога, која има посебен колекторски контејнер што ја врши функцијата на собирање метрики и логови. Можеме да ги користиме можностите на Kubernetes: пуштање контејнери во еден pod, во еден процес и/или мрежен простор. Всушност, запознајте ги вашите агенти и извршувајте некои функции. И ако истиот контејнер се лансира во Docker, тој ќе ги добие сите исти способности како излезот, односно ќе може да испорачува логови и метрика, бидејќи агентите ќе се лансираат внатрешно. 

Метрика и логови

Доставувањето метрика и логови е сложена задача. Има неколку аспекти на нејзината одлука.
Инфраструктурата е создадена за извршување на товарот, а не за масовна испорака на трупци. Тоа е, овој процес мора да се изврши со минимални барања за ресурси за контејнери. Ние се стремиме да им помогнеме на нашите програмери: „Земете контејнер Docker Hub, стартувајте го и можеме да ги испорачаме дневниците“. 

Вториот аспект е ограничување на обемот на дневниците. Ако се појави пораст на волуменот на дневниците во неколку контејнери (апликацијата емитува stack-trace во јамка), оптоварувањето на процесорот, каналите за комуникација и системот за обработка на дневници се зголемува, а тоа влијае на работата на домаќинот како цели и други контејнери на домаќинот, тогаш понекогаш тоа доведува до „пад“ на домаќинот. 

Третиот аспект е дека е неопходно да се поддржат што е можно повеќе методи за собирање метрика надвор од кутијата. Од читање датотеки и анкетирање на Prometheus-endpoint до користење на протоколи специфични за апликацијата.

И последниот аспект е да се минимизира потрошувачката на ресурси.

Избравме решение Go со отворен код наречен Телеграф. Ова е универзален конектор кој поддржува повеќе од 140 типови влезни канали (влезни приклучоци) и 30 типови излезни канали (излезни приклучоци). Го финализиравме и сега ќе ви кажеме како го користиме користејќи го Kubernetes како пример. 

Да речеме дека програмерот распоредува обем на работа и Kubernetes добива барање за создавање подлога. Во овој момент, контејнер наречен Колектор автоматски се креира за секоја подлога (ние користиме веб-кука за мутација). Колекторот е наш агент. На почетокот, овој контејнер се конфигурира да работи со Prometheus и системот за собирање дневници.

• За да го направите ова, користи прибелешки за подлоги и во зависност од неговата содржина, создава, да речеме, крајна точка на Прометеј; 
• Врз основа на спецификацијата на pod и специфичните поставки за контејнерот, тој одлучува како да се доставуваат дневниците.

Ние собираме дневници преку Docker API: програмерите треба само да ги стават во stdout или stderr, а Collector ќе го среди. Дневниците се собираат на парчиња со одредено задоцнување за да се спречи можното преоптоварување на домаќинот. 

Метриките се собираат низ случаите на обемот на работа (процеси) во контејнери. Сè е означено: именски простор, под и така натаму, а потоа се претвора во формат Прометеј - и станува достапно за собирање (освен за дневници). Исто така, испраќаме дневници, метрика и настани до Кафка и понатаму:

• Дневниците се достапни во Graylog (за визуелна анализа);
• Дневниците, метриката, настаните се испраќаат до Clickhouse за долгорочно складирање.

Сè работи потполно исто во AWS, само ние го заменуваме Graylog со Kafka со Cloudwatch. Ние ги испраќаме дневниците таму и сè излегува многу погодно: веднаш е јасно на кој кластер и контејнер припаѓаат. Истото важи и за Google Stackdriver. Односно, нашата шема работи и во просторија со Кафка и во облакот. 

Ако немаме Kubernetes со мешунки, шемата е малку посложена, но работи на истите принципи.

Истите процеси се извршуваат внатре во контејнерот, тие се оркестрирани со помош на S6. Сите исти процеси се извршуваат во истиот контејнер.

Како резултат на тоа,

Создадовме комплетно решение за градење и лансирање слики, со опции за собирање и доставување логови и метрика:

• Развивме стандардизиран пристап за составување слики и врз основа на него развивме CI шаблони;
• Агентите за собирање податоци се нашите екстензии на Телеграф. Добро ги тестиравме во производството;
• Ние користиме веб-кука за мутација за да имплементираме контејнери со агенти во мешунките; 
• Интегриран во екосистемот Kubernetes/Rancher;
• Можеме да ги извршиме истите контејнери во различни системи на оркестрација и да го добиеме резултатот што го очекуваме;
• Создаде целосно динамична конфигурација за управување со контејнери. 

Коавтор: Илја Прудников

Извор: www.habr.com