Тази история е за това как използваме контейнери в производствена среда, особено под Kubernetes. Статията е посветена на събирането на метрики и регистрационни файлове от контейнери, както и на изграждането на изображения.

Ние сме от финтех компанията Exness, която разработва услуги за онлайн търговия и финтех продукти за B2B и B2C. Има много различни екипи в нашата научноизследователска и развойна дейност, над 100 служители в отдела за развитие.

Ние представляваме екипа, който отговаря за платформата за събиране и изпълнение на код от нашите разработчици. По-специално, ние сме отговорни за събирането, съхраняването и предоставянето на показатели, регистрационни файлове и събития от приложения. В момента управляваме приблизително 50 Docker контейнера в производство, поддържаме нашето XNUMXTB голямо хранилище за данни и предоставяме архитектурни решения, които са изградени около нашата инфраструктура: Kubernetes, Rancher и различни доставчици на публичен облак. 

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

Какво гори? Никой не може да отговори. Къде е огнището? Трудно е за разбиране. Кога запали? Можете да разберете, но не веднага. 

Защо някои контейнери стоят, докато други падат? Кой контейнер беше виновникът? В края на краищата, отвън контейнерите са еднакви, но вътре всеки има свой Neo.

Нашите разработчици са умни момчета. Те правят добри услуги, които носят печалба на компанията. Но има грешки, когато контейнерите с приложения се развалят. Един контейнер консумира твърде много CPU, другият - мрежата, третият - I / O операции, четвъртият като цяло не е ясно какво прави със сокети. Всичко това пада и корабът потъва. 

Агенти

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

Тези агенти са ограничаващи програми, които поддържат контейнерите в такова състояние, че да не се счупят един друг. Агентите са стандартизирани и това ви позволява да стандартизирате подхода към сервирането на контейнери. 

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

Агентите също означават помощни програми за работа и поддръжка, които могат да работят в различни системи за оркестрация, които поддържат различни изображения (Debian, Alpine, Centos и др.).

И накрая, агентите трябва да поддържат прост CI/CD, включително Dockerfiles. В противен случай корабът ще се разпадне, тъй като контейнерите ще бъдат доставени по "кривите" релси.

Процес на изграждане и устройство за целево изображение

За да бъде всичко стандартизирано и управляемо, трябва да се следва някакъв стандартен процес на изграждане. Затова решихме да събираме контейнери по контейнери - такава е рекурсията.

Тук контейнерите са представени с плътни контури. В същото време решихме да поставим дистрибуции в тях, така че „животът да не изглежда като малина“. Защо беше направено това, ще опишем по-долу.
 
Резултатът е инструмент за изграждане, специфичен за версията контейнер, който препраща към конкретни версии на разпространение и версии на скриптове.

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

Защо този подход е добър? 

• Първо, пълен контрол на версиите на инструментите за изграждане - контейнер за изграждане, скрипт и версии за разпространение. 
• Второ, постигнахме стандартизация: създаваме шаблони по същия начин, междинни и готови за използване изображения. 
• Трето, контейнерите ни осигуряват преносимост. Днес използваме Gitlab, а утре ще преминем към TeamCity или Jenkins и ще можем да управляваме нашите контейнери по същия начин. 
• Четвърто, минимизиране на зависимостите. Неслучайно поставяме дистрибуции в контейнера, защото това ни позволява да не ги изтегляме всеки път от интернет. 
• Пето, скоростта на сглобяване се е увеличила - наличието на локални копия на изображения ви позволява да не губите време за изтегляне, тъй като има локално изображение. 

С други думи, постигнахме контролиран и гъвкав процес на сглобяване. Ние използваме едни и същи инструменти, за да изградим всякакви контейнери с пълна версия. 

Как работи нашата процедура за сглобяване

Сглобяването се стартира с една команда, процесът се изпълнява в изображението (маркирано в червено). Разработчикът има Docker файл (маркиран в жълто), ние го изобразяваме, като заменяме променливите със стойности. И по пътя добавяме горни и долни колонтитули - това са нашите агенти. 

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

Дълго мислихме дали да инсталираме супервайзор. В крайна сметка решихме, че ни трябва. Изберете S6. Надзорникът осигурява управление на контейнера: той ви позволява да се свържете с него, ако основният процес се срине и осигурява ръчно управление на контейнера, без да го създавате отново. Дневниците и показателите са процеси, които се изпълняват вътре в контейнер. Те също трябва да бъдат контролирани по някакъв начин и ние го правим с помощта на супервайзор. И накрая, S6 се грижи за домакинството, обработката на сигнала и други задачи.

Тъй като използваме различни системи за оркестрация, след сглобяване и стартиране контейнерът трябва да разбере в каква среда се намира и да действа според ситуацията. Например:
Това ни позволява да изградим едно изображение и да го стартираме в различни системи за оркестрация, като то ще бъде стартирано, като се вземат предвид спецификите на тази система за оркестрация.

 

За един и същ контейнер получаваме различни дървета на процеси в Docker и Kubernetes:

Полезният товар се изпълнява под супервайзора S6. Обърнете внимание на събирача и събитията - това са нашите агенти, отговорни за регистрационните файлове и показателите. Kubernetes ги няма, но Docker ги има. Защо? 

Ако погледнете спецификацията на „pod“ (по-нататък - Kubernetes pod), тогава ще видим, че контейнерът за събития се изпълнява в pod, който има отделен контейнер за събиране, който изпълнява функцията за събиране на показатели и регистрационни файлове. Можем да използваме функциите на Kubernetes: работещи контейнери в един под, в един процес и/или мрежово пространство. Всъщност внедряват техните агенти и изпълняват някои функции. И ако същият контейнер се стартира в Docker, той ще получи всички същите функции като изхода, тоест ще може да доставя регистрационни файлове и показатели, тъй като агентите ще бъдат стартирани вътре. 

Метрики и регистрационни файлове

Предоставянето на показатели и регистрационни файлове е трудна задача. Има няколко аспекта на неговото решение.
Инфраструктурата е създадена за изпълнение на полезния товар, а не за масова доставка на трупи. Това означава, че този процес трябва да работи с минимални изисквания за ресурси на контейнера. Ние се стремим да помогнем на нашите разработчици: „Вземете контейнер на Docker Hub, стартирайте го и ние можем да доставим регистрационните файлове.“ 

Вторият аспект е ограничаване на обема на трупите. Ако възникне ситуация на скок в обема на регистрационните файлове в няколко контейнера (приложението извежда проследяване на стека в цикъл), натоварването на процесора, комуникационните канали, системата за обработка на регистрационни файлове се увеличава и това се отразява на работата на хост като цяло и други контейнери на хоста, тогава понякога това води до "падане" на хоста. 

Третият аспект е, че трябва да поддържате възможно най-много методи за събиране на показатели от кутията. От четене на файлове и запитване на крайната точка на Prometheus до използване на специфични протоколи за приложения.

И последният аспект - необходимо е да се сведе до минимум потреблението на ресурси.

Избрахме Go решение с отворен код, наречено Telegraf. Това е универсален конектор, който поддържа повече от 140 вида входни канали (входни плъгини) и 30 вида изходни канали (изходни плъгини). Ние го финализирахме и сега ще ви кажем как го използваме, като използваме Kubernetes като пример. 

Да приемем, че разработчик внедри товар и Kubernetes получи заявка за създаване на pod. В този момент автоматично се създава контейнер, наречен Collector за всеки Pod (използваме webhook за мутация). Collector е наш агент. В началото този контейнер се настройва да работи с Prometheus и системата за регистриране.

• За да направи това, той използва анотации на Pod и в зависимост от съдържанието си създава, да речем, крайна точка Prometheus; 
• Въз основа на спецификацията на групата и конкретните настройки на контейнера, решава как да достави регистрационните файлове.

Ние събираме регистрационни файлове чрез Docker API: разработчиците просто трябва да ги поставят в stdout или stderr и след това Collector ще разбере. Регистрационните файлове се събират на части с известно забавяне, за да се предотврати възможно претоварване на хоста. 

Метриките се събират от екземпляри на работно натоварване (процеси) в контейнери. Всичко се маркира с тагове: пространство от имена, pod и т.н., след което се преобразува във формата на Prometheus - и става достъпно за събиране (с изключение на регистрационни файлове). Също така изпращаме регистрационни файлове, показатели и събития на Kafka и по-нататък:

• Дневниците са налични в Graylog (за визуален анализ);
• Регистри, показатели, събития се изпращат на Clickhouse за дългосрочно съхранение.

Всичко работи абсолютно същото в AWS, само че заменяме Graylog от Kafka с Cloudwatch. Изпращаме регистрационни файлове там и всичко се оказва много удобно: веднага става ясно към кой клъстер и контейнер принадлежат. Същото важи и за Google Stackdriver. Тоест нашата схема работи както на място с Kafka, така и в облака. 

Ако нямаме Kubernetes с pods, схемата е малко по-сложна, но работи на същите принципи.

Вътре в контейнера се изпълняват същите процеси, те се управляват с помощта на S6. Всички същите процеси се изпълняват в един и същи контейнер.

В резултат на това

Създадохме цялостно решение за изграждане и стартиране на изображения в експлоатация, с опции за събиране и доставяне на регистрационни файлове и показатели:

• Разработихме стандартизиран подход за изграждане на изображения, въз основа на който разработихме CI шаблони;
• Агентите за събиране на данни са нашите разширения на Telegraf. Тествахме ги добре в производството;
• Използваме webhook за мутация, за да инжектираме контейнери с агенти в контейнери; 
• Интегриран в екосистемата Kubernetes/Rancher;
• Можем да изпълним едни и същи контейнери в различни системи за оркестрация и да получим резултата, който очакваме;
• Създадена напълно динамична конфигурация за управление на контейнери. 

Съавтор: Иля Прудников

Източник: www.habr.com