Ši istorija yra apie tai, kaip mes naudojame konteinerius gamybos aplinkoje, ypač Kubernetes. Straipsnis skirtas metrikų ir žurnalų rinkimui iš konteinerių, taip pat pastato vaizdams.

Esame iš fintech įmonės Exness, kuri kuria internetinės prekybos paslaugas ir fintech produktus B2B ir B2C. Mūsų MTEP turi daug skirtingų komandų, plėtros skyriuje dirba daugiau nei 100 darbuotojų.

Atstovaujame komandai, atsakingai už platformą, skirtą mūsų kūrėjams rinkti ir paleisti kodą. Visų pirma esame atsakingi už programų metrikos, žurnalų ir įvykių rinkimą, saugojimą ir ataskaitų teikimą. Šiuo metu gamybinėje aplinkoje eksploatuojame apie tris tūkstančius „Docker“ konteinerių, prižiūrime 50 TB didelių duomenų saugyklą ir teikiame architektūrinius sprendimus, sukurtus pagal mūsų infrastruktūrą: „Kubernetes“, „Rancher“ ir įvairius viešųjų debesų paslaugų teikėjus. 

Mūsų motyvacija

Kas dega? Niekas negali atsakyti. Kur yra židinys? Sunku suprasti. Kada užsidegė? Galite sužinoti, bet ne iš karto. 

Kodėl vieni konteineriai stovi, o kiti nukrito? Kuris konteineris buvo kaltas? Juk konteinerių išorė vienoda, bet viduje kiekvienas turi savo Neo.

Mūsų kūrėjai yra kompetentingi vaikinai. Jie teikia geras paslaugas, kurios neša įmonei pelną. Tačiau pasitaiko gedimų, kai konteineriai su programomis suklysta. Vienas konteineris sunaudoja per daug procesoriaus, kitas – tinklą, trečias – įvesties/išvesties operacijas, o ketvirtas visiškai neaišku, ką daro su lizdais. Viskas krenta ir laivas nuskęsta. 

Agentai

Norėdami suprasti, kas vyksta viduje, nusprendėme agentus sudėti tiesiai į konteinerius.

Šios priemonės yra suvaržymo programos, kurios išlaiko konteinerius tokioje būsenoje, kad vienas kito nesulaužytų. Agentai yra standartizuoti, o tai leidžia taikyti standartizuotą požiūrį į konteinerių aptarnavimą. 

Mūsų atveju agentai turi pateikti žurnalus standartiniu formatu, pažymėti ir užblokuoti. Jie taip pat turėtų pateikti mums standartizuotą metriką, kurią galima išplėsti verslo taikomųjų programų požiūriu.

Agentai taip pat reiškia valdymo ir priežiūros paslaugas, kurios gali veikti skirtingose ​​orkestravimo sistemose, palaikančiose skirtingus vaizdus („Debian“, „Alpine“, „Centos“ ir kt.).

Galiausiai agentai turi palaikyti paprastą CI / CD, kuriame yra Docker failai. Priešingu atveju laivas subyrės, nes konteineriai bus pradėti gabenti išilgai „kreivų“ bėgių.

Sukurkite procesą ir nukreipkite vaizdo įrenginį

Kad viskas būtų standartizuota ir valdoma, reikia laikytis tam tikro standartinio kūrimo proceso. Todėl nusprendėme rinkti konteinerius konteineriais – tai rekursija.

Čia konteineriai pavaizduoti vientisais kontūrais. Tuo pat metu jie nusprendė į juos įdėti platinimo rinkinius, kad „gyvenimas neatrodytų kaip avietės“. Kodėl tai buvo padaryta, paaiškinsime toliau.
 
Rezultatas yra kūrimo įrankis – konkrečiai versijai skirtas konteineris, nurodantis konkrečias platinimo versijas ir konkrečias scenarijaus versijas.

Kaip mes jį naudojame? Turime Docker Hub, kuriame yra konteineris. Mes atspindime jį savo sistemoje, kad atsikratytume išorinių priklausomybių. Rezultatas – geltonai pažymėtas konteineris. Sukuriame šabloną, kad į konteinerį įdiegtume visus reikalingus paskirstymus ir scenarijus. Po to surenkame paruoštą naudoti vaizdą: kūrėjai į jį įdeda kodą ir kai kurias savo specialias priklausomybes. 

Kuo šis požiūris yra geras? 

• Pirma, pilnas kūrimo įrankių versijos valdymas – kūrimo konteineris, scenarijus ir platinimo versijos. 
• Antra, pasiekėme standartizavimo: vienodai kuriame šablonus, tarpinį ir paruoštą naudoti vaizdą. 
• Trečia, konteineriai suteikia mums nešiojamumo. Šiandien mes naudojame „Gitlab“, o rytoj pereisime prie „TeamCity“ arba „Jenkins“ ir savo konteinerius galėsime valdyti taip pat. 
• Ketvirta, priklausomybių mažinimas. Neatsitiktinai į konteinerį įdėjome platinimo rinkinius, nes tai leidžia išvengti jų kaskart parsisiuntimo iš interneto. 
• Penkta, kūrimo greitis padidėjo - vietinių vaizdų kopijų buvimas leidžia neeikvoti laiko atsisiuntimui, nes yra vietinis vaizdas. 

Kitaip tariant, mes pasiekėme kontroliuojamą ir lankstų surinkimo procesą. Naudojame tuos pačius įrankius, kad sukurtume bet kokius visiškai sutvarkytus konteinerius. 

Kaip veikia mūsų kūrimo procedūra

Surinkimas paleidžiamas viena komanda, procesas vykdomas paveikslėlyje (paryškintas raudonai). Kūrėjas turi Docker failą (paryškintas geltonai), mes jį pateikiame, pakeisdami kintamuosius reikšmėmis. Pakeliui pridedame antraštes ir poraštes – tai mūsų agentai. 

Antraštė prideda paskirstymus iš atitinkamų vaizdų. O poraštė įdiegia mūsų paslaugas viduje, sukonfigūruoja darbo krūvio, registravimo ir kitų agentų paleidimą, pakeičia įėjimo tašką ir pan. 

Ilgai galvojome, ar įrengti prižiūrėtoją. Galiausiai nusprendėme, kad mums jo reikia. Mes pasirinkome S6. Prižiūrėtojas teikia konteinerio valdymą: leidžia prisijungti prie jo, jei pagrindinis procesas sugenda, ir rankiniu būdu valdo konteinerį jo nesukūrus iš naujo. Žurnalai ir metrika yra procesai, vykdomi konteinerio viduje. Juos irgi reikia kažkaip kontroliuoti, o tai darome su prižiūrėtojo pagalba. Galiausiai S6 rūpinasi namų tvarkymu, signalų apdorojimu ir kitomis užduotimis.

Kadangi naudojame skirtingas orkestravimo sistemas, sukonstravus ir paleistas konteineris turi suprasti, kokioje aplinkoje jis yra ir veikti pagal situaciją. Pavyzdžiui:
Tai leidžia mums sukurti vieną vaizdą ir paleisti jį skirtingose ​​orkestravimo sistemose, o jis bus paleistas atsižvelgiant į šios orkestravimo sistemos specifiką.

 

Tam pačiam konteineriui „Docker“ ir „Kubernetes“ gauname skirtingus proceso medžius:

Naudingasis krovinys vykdomas prižiūrint S6. Atkreipkite dėmesį į kolekcionierių ir įvykius – tai mūsų agentai, atsakingi už žurnalus ir metrikas. „Kubernetes“ jų neturi, bet „Docker“ turi. Kodėl? 

Jei pažiūrėtume į “pod” (toliau – Kubernetes pod) specifikaciją, pamatytume, kad įvykių konteineris yra vykdomas podyje, kuris turi atskirą kolektoriaus konteinerį, kuris atlieka metrikų ir žurnalų rinkimo funkciją. Galime pasinaudoti Kubernetes galimybėmis: paleisti konteinerius viename bloke, viename procese ir (arba) tinklo erdvėje. Iš tikrųjų pristatykite savo agentus ir atlikite kai kurias funkcijas. Ir jei tas pats konteineris bus paleistas „Docker“, jis gaus visas tas pačias galimybes kaip ir išvestis, tai yra, galės pateikti žurnalus ir metrikas, nes agentai bus paleisti viduje. 

Metrika ir žurnalai

Metrikų ir žurnalų pateikimas yra sudėtinga užduotis. Jos sprendimas turi keletą aspektų.
Infrastruktūra sukurta naudingo krovinio vykdymui, o ne masiniam rąstų pristatymui. Tai reiškia, kad šis procesas turi būti atliekamas su minimaliais konteinerio išteklių reikalavimais. Stengiamės padėti savo kūrėjams: „Įsigykite „Docker Hub“ konteinerį, paleiskite jį ir galėsime pristatyti žurnalus. 

Antras aspektas – rąstų apimties ribojimas. Jei keliuose konteineriuose įvyksta žurnalų apimties padidėjimas (programa kilpoje išveda kamino pėdsaką), padidėja procesoriaus, ryšio kanalų ir žurnalų apdorojimo sistemos apkrova, o tai turi įtakos pagrindinio kompiuterio veikimui. visos ir kitos talpyklos ant pagrindinio kompiuterio, tada kartais tai lemia pagrindinio kompiuterio „nukritimą“. 

Trečias aspektas – būtina palaikyti kuo daugiau metrikų rinkimo metodų. Nuo failų skaitymo ir Prometheus galutinio taško apklausos iki specifinių taikomųjų protokolų naudojimo.

Ir paskutinis aspektas – iki minimumo sumažinti išteklių suvartojimą.

Pasirinkome atvirojo kodo „Go“ sprendimą, pavadintą „Telegraf“. Tai universali jungtis, palaikanti daugiau nei 140 tipų įvesties kanalų (įvesties įskiepių) ir 30 tipų išvesties kanalų (išvesties papildinius). Mes jį užbaigėme ir dabar mes jums pasakysime, kaip mes jį naudojame, naudodami „Kubernetes“ pavyzdį. 

Tarkime, kūrėjas diegia darbo krūvį ir „Kubernetes“ gauna užklausą sukurti bloką. Šiuo metu kiekvienam podeliui automatiškai sukuriamas konteineris pavadinimu Collector (naudojame mutacijos žiniatinklio kabliuką). Kolekcionierius yra mūsų agentas. Iš pradžių šis konteineris sukonfigūruojamas dirbti su Prometheus ir žurnalų rinkimo sistema.

• Norėdami tai padaryti, jis naudoja anotacijas ir, priklausomai nuo turinio, sukuria, tarkime, Prometheus galutinį tašką; 
• Remdamasi rinkinio specifikacija ir konkrečiais konteinerio nustatymais, ji nusprendžia, kaip pristatyti žurnalus.

Žurnalus renkame per Docker API: kūrėjams tereikia juos įdėti į stdout arba stderr, o Collector tai sutvarkys. Žurnalai renkami dalimis su tam tikru vėlavimu, kad būtų išvengta galimos pagrindinio kompiuterio perkrovos. 

Metrika renkama iš visų darbo krūvio atvejų (procesų) konteineriuose. Viskas yra pažymėta: vardų erdvė, pagal ir tt, o tada konvertuojama į Prometheus formatą – ir tampa prieinama rinkimui (išskyrus žurnalus). Taip pat siunčiame žurnalus, metrikas ir įvykius Kafka ir toliau:

• Žurnalai yra prieinami Graylog (vizualinei analizei);
• Žurnalai, metrika, įvykiai siunčiami į Clickhouse ilgalaikiam saugojimui.

AWS viskas veikia lygiai taip pat, tik „Graylog“ pakeičiame „Kafka“ su „Cloudwatch“. Mes siunčiame rąstus ten, ir viskas pasirodo labai patogu: iš karto aišku, kokiam klasteriui ir konteineriui jie priklauso. Tas pats pasakytina apie „Google Stackdriver“. Tai reiškia, kad mūsų schema veikia ir vietoje su Kafka, ir debesyje. 

Jei neturime Kubernetes su ankštimis, schema yra šiek tiek sudėtingesnė, tačiau ji veikia tais pačiais principais.

Tie patys procesai vykdomi konteinerio viduje, jie suorganizuoti naudojant S6. Visi tie patys procesai vyksta tame pačiame konteineryje.

Kaip rezultatas,

Sukūrėme išsamų vaizdų kūrimo ir paleidimo sprendimą su žurnalų ir metrikos rinkimo ir pristatymo galimybėmis:

• Sukūrėme standartizuotą vaizdų rinkimo metodą ir pagal jį sukūrėme CI šablonus;
• Duomenų rinkimo agentai yra mūsų „Telegraf“ plėtiniai. Mes juos gerai išbandėme gamyboje;
• Mes naudojame mutacijos žiniatinklio kabliuką, kad įdiegtume konteinerius su agentais ankštyse; 
• Integruota į Kubernetes/Rancher ekosistemą;
• Galime atlikti tuos pačius konteinerius skirtingose ​​orkestravimo sistemose ir gauti rezultatą, kurio tikimės;
• Sukurta visiškai dinamiška konteinerio valdymo konfigūracija. 

Bendraautorius: Ilja Prudnikovas

Šaltinis: www.habr.com