Ова прича говори о томе како користимо контејнере у производном окружењу, посебно Кубернетес. Чланак је посвећен прикупљању метрика и дневника из контејнера, као и изградњи слика.

Ми смо из финтецх компаније Екнесс, која развија услуге за онлајн трговину и финтецх производе за Б2Б и Б2Ц. Наше истраживање и развој има много различитих тимова, одељење за развој има 100+ запослених.

Представљамо тим који је одговоран за платформу на којој наши програмери прикупљају и покрећу код. Посебно смо одговорни за прикупљање, чување и извештавање о метрикама, евиденцијама и догађајима из апликација. Тренутно управљамо са око три хиљаде Доцкер контејнера у производном окружењу, одржавамо наше складиште великих података од 50 ТБ и пружамо архитектонска решења која су изграђена око наше инфраструктуре: Кубернетес, Ранцхер и разних добављача јавних облака. 

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

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

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

Наши програмери су компетентни момци. Они праве добре услуге које доносе профит компанији. Али има грешака када контејнери са апликацијама залутају. Један контејнер троши превише ЦПУ-а, други троши мрежу, трећи И/О операције, а четврти је потпуно нејасно шта ради са утичницама. Све то пада и брод тоне. 

Агенти

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

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

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

Агенти такође означавају услужне програме за рад и одржавање који могу да раде у различитим системима оркестрације који подржавају различите слике (Дебиан, Алпине, Центос, итд.).

Коначно, агенти морају подржавати једноставан ЦИ/ЦД који укључује Доцкер датотеке. У супротном, брод ће се распасти, јер ће контејнери почети да се испоручују по „кривим“ шинама.

Изградите процес и одредите уређај за слику

Да би све остало стандардизовано и којим се може управљати, потребно је пратити неку врсту стандардног процеса изградње. Стога смо одлучили да сакупљамо контејнере по контејнерима - ово је рекурзија.

Овде су контејнери представљени чврстим обрисима. Истовремено, одлучили су да у њих ставе дистрибутивне комплете како „живот не би личио на малине“. Зашто је то учињено, објаснићемо у наставку.
 
Резултат је алатка за прављење—контејнер специфичан за верзију који упућује на специфичне верзије дистрибуције и специфичне верзије скрипте.

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

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

• Прво, пуна контрола верзија алата за прављење - верзије контејнера за прављење, скрипте и дистрибуције. 
• Друго, постигли смо стандардизацију: на исти начин креирамо шаблоне, средњу и слику спремну за употребу. 
• Треће, контејнери нам дају преносивост. Данас користимо Гитлаб, а сутра прелазимо на ТеамЦити или Јенкинс и моћи ћемо да покрећемо наше контејнере на исти начин. 
• Четврто, минимизирање зависности. Није било случајно што смо дистрибутивне комплете ставили у контејнер, јер нам то омогућава да избегнемо сваки пут да их преузимамо са интернета. 
• Пето, брзина израде је повећана - присуство локалних копија слика омогућава вам да избегнете губљење времена на преузимање, јер постоји локална слика. 

Другим речима, постигли смо контролисан и флексибилан процес монтаже. Користимо исте алате за прављење контејнера са потпуним верзијама. 

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

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

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

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

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

 

За исти контејнер добијамо различита стабла процеса у Доцкер-у и Кубернетес-у:

Корисно оптерећење се извршава под надзором С6. Обратите пажњу на сакупљаче и догађаје - то су наши агенти одговорни за евиденцију и метрику. Кубернетес их нема, али Доцкер има. Зашто? 

Ако погледамо спецификацију “под” (у даљем тексту – Кубернетес под), видећемо да се контејнер догађаја извршава у под-у који има посебан колекторски контејнер који обавља функцију прикупљања метрика и логова. Можемо да користимо могућности Кубернетеса: покретање контејнера у једном модулу, у једном процесу и/или мрежном простору. У ствари, представите своје агенте и извршите неке функције. А ако се исти контејнер покрене у Доцкер-у, он ће добити све исте могућности као и излаз, односно моћи ће да испоручује евиденције и метрике, пошто ће агенти бити покренути интерно. 

Метрике и евиденције

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

Други аспект је ограничавање запремине трупаца. Ако дође до пораста обима евиденције у неколико контејнера (апликација емитује стацк-траце у петљи), повећава се оптерећење ЦПУ-а, комуникационих канала и система за обраду дневника, а то утиче на рад хоста као целих и других контејнера на хосту, онда то понекад доводи до "пада" хоста. 

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

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

Изабрали смо Го решење отвореног кода под називом Телеграф. Ово је универзални конектор који подржава више од 140 типова улазних канала (улазних додатака) и 30 типова излазних канала (излазних додатака). Завршили смо га и сада ћемо вам рећи како га користимо користећи Кубернетес као пример. 

Рецимо да програмер распоређује радно оптерећење и Кубернетес добије захтев за креирање под. У овом тренутку, контејнер под називом Цоллецтор се аутоматски креира за сваки под (користимо мутациони вебхоок). Колекционар је наш агент. На почетку, овај контејнер се конфигурише да ради са Прометхеусом и системом прикупљања дневника.

• Да би то урадио, користи под напомене, и у зависности од свог садржаја, креира, рецимо, Прометхеус крајњу тачку; 
• На основу спецификације под и специфичних поставки контејнера, одлучује како да испоручи евиденцију.

Прикупљамо евиденције преко Доцкер АПИ-ја: програмери само треба да их ставе у стдоут или стдерр, а Цоллецтор ће то средити. Дневници се прикупљају у деловима са извесним закашњењем како би се спречило могуће преоптерећење хоста. 

Метрике се прикупљају кроз инстанце радног оптерећења (процесе) у контејнерима. Све је означено: именски простор, испод и тако даље, а затим се конвертује у Прометхеус формат - и постаје доступно за прикупљање (осим за дневнике). Такође шаљемо евиденције, метрике и догађаје Кафки и даље:

• Дневници су доступни у Граилог-у (за визуелну анализу);
• Дневници, метрика, догађаји се шаљу у Цлицкхоусе за дуготрајно складиштење.

Све функционише потпуно исто у АВС-у, само што Грејлог замењујемо Кафком са Цлоудватцх-ом. Тамо шаљемо дневнике и све се испоставља веома згодно: одмах је јасно ком кластеру и контејнеру припадају. Исто важи и за Гоогле Стацкдривер. Односно, наша шема ради и локално са Кафком и у облаку. 

Ако немамо Кубернетес са подовима, шема је мало компликованија, али ради на истим принципима.

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

Као резултат тога,

Направили смо комплетно решење за прављење и покретање слика, са опцијама за прикупљање и испоруку евиденције и метрике:

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

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

Извор: ввв.хабр.цом