See lugu räägib sellest, kuidas kasutame konteinerite rakendusi tootmisümbritsuse, eriti Kubernetes'i all. Artikkel on pühendatud mõõdikute ja logide kogumisele konteineritest ning piltide koostamisele.

Me oleme finansitehnoloogia ettevõte Exness, mis loob teenuseid veebikaubanduse ja finantsteaduste saavutamiseks B2B ja B2C valdkondades. Meie teadus- ja arendustegevuses on palju erinevaid meeskondi, arendusosakonnas üle 100 töötaja.

Esindame meeskonda, kes vastutab meie arendajate koodi kogumise ja käitamise platvormi eest. Täpsemalt vastutame mõõdikute, logide ja rakendustest pärinevate sündmuste kogumise, salvestamise ja esitamise eest. Praegu opereerime umbes kolme tuhande Docker-konteineriga tootmisümbritsuses, toetame 50 TB suurust big data ladustamist ning pakume arhitektuurilisi lahendusi, mis põhinevad meie infrastruktuuril: Kubernetes, Rancher ja erinevad avalikud pilveteenuse pakkujad. 

Meie motivatsioon

Mis põleb? Keegi ei oska vastata. Kus on tulekold? Seda on raske aru saada. Millal see süttis? Selle väljaselgitamine on võimalik, kuid mitte kohe. 

Miks mõned konteinerid tõusevad, samas kui teised langevad? Milline konteiner on selle põhjuseks? Kuigi konteinerite välimus on sama, on igaühes sees oma Neo.

Meie arendajad on targa mõtlemisega. Nad loovad häid teenuseid, mis toovad ettevõttele kasumit. Kuid juhtuvad ka ebaõnnestumised, kui rakenduste konteinerid lähevad sassi. Üks konteiner tarbib liiga palju CPU-d, teine - võrku, kolmas - sisendi ja väljundi operatsioone, neljas ei selgu üldse, mis ta pistikute külge teeb. Kõik see kukub kokku ja alus põhjavette. 

Agenid

Kuna tahame aru saada, mis toimub sees, otsustasime paigutada agendid otse konteineritesse.

Need agendid on piiravad programmid, mis hoiavad konteinerid olukorras, kus nad üksteist ei rikuks. Agendid on standardiseeritud, mis võimaldab standardiseerida lähenemisviisi konteinerite hooldamisele. 

Meie puhul peavad agendid esitama logisid standardses vormingus, märgistatuna ja trottlinguga. Samuti peavad nad esitama meile standardiseeritud mõõdikud, mis on ärirakenduste jaoks laiendatavad.

Agente tähendab ka utiliite, mis on mõeldud ekspluateerimiseks ja hooldamiseks ning suudavad töötada erinevates orkestreerimissüsteemides, toetades erinevaid images (Debian, Alpine, Centos jne).

Lõpuks peavad agendid toetama lihtsat CI/CD-d, mis hõlmab Docker-failide kasutamist. Vastasel juhul laev laguneb, kuna konteinerid hakatakse tarnima "kõveratel" rööbastel.

Kogumisprotsess ja siht-image struktuur

Kuna kõik peab olema standardiseeritud ja hallatav, on vajalik järgida mõnda standardset kogumisprotsessi. Seetõttu otsustasime koguda konteinerid konteinerite abil — selline rekursioon.

Siin on konteinerid esitatud ühtsete kontuuride kujul. Samuti otsustasime lisada neisse distributsioonid, et "elu ei tunduks liiga magus". Miks see tehti, selgitame allpool.
 
Tulemusena saime tööriista kogumiseks — kindla versiooniga konteineri, mis viitab kindlatele distrubutsiooniversioonidele ja kindlatele skriptiversioonidele.

Kuidas me seda rakendame? Meil on Docker Hub, kus on konteiner. Me peegeldame selle oma süsteemi, et vältida väliseid sõltuvusi. Tulemusena saame kollaseks märgistatud konteineri. Loome šablooni, et paigaldada konteinerisse kõik vajalikud distributsioonid ja skriptid. Pärast seda kogume valmis kasutamiseks mõeldud pildi: arendajad panevad sinna oma koodi ja erilised sõltuvused. 

Miks on see lähenemine hea? 

• Esiteks, täielik versioonikontroll ehitusvahendite üle – ehituskonteiner, skriptide ja distributsioonide versioonid. 
• Teiseks, oleme saavutanud standardiseerimise: loome šabloone, vahepealseid ja valmis kasutamiseks mõeldud pilte ühtselt. 
• Kolmandaks, konteinerid tagavad meile kaasaskantavuse. Täna kasutame Gitlab'i, aga homme võime üle minna TeamCity'le või Jenkins'ile ning saame oma konteinerid sealgi käivitada. 
• Neljandaks, sõltuvuste minimeerimine. Me ei pannud konteinerisse distributsioone juhuslikult, kuna see võimaldab meil neid iga kord internetist alla laadida. 
• Viies, ehitamise kiirus on suurenenud – kohalike piltide olemasolu võimaldab mitte kulutada aega allalaadimisele, kuna kohaliku pildi olemasolu. 

Teisisõnu, oleme saavutanud kontrollitava ja paindliku ehitusprotsessi. Kasutame kõigi konteinerite ehitamiseks samu vahendeid koos täieliku versioonihaldusega. 

Kuidas meie ehitusprotseduur töötab

Ehitamine käivitub ühe käsklusega, protsess viiakse läbi pildis (märgitud punasega). Arendajal on Docker-fail (märgitud kollasega), me renderdame selle, asendades muutuja väärtustega. Samal ajal lisame päise ja jaluse – need on meie agentid. 

Päis lisab jaotised vastavatest piltidest. Jalus seadistab meie teenused, konfigureerib töökoormuse, logimise ja teiste agentide käivitamise, asendab sisenemispunkti jne. 

Me mõtlesime kaua, kas võtta superviisor või mitte. Lõpuks otsustasime, et see on vajalik. Valisime S6. Superviisor haldab konteinerit: see võimaldab pääseda sellele juurde, kui põhiprotsess kukub ning tagab käsitsi haldamise konteinerit uuesti loomata. Logid ja metrika on protsessid, mis töötavad konteineri sees. Neid tuleb samuti kontrollida, ja me teeme seda superviisori abil. Lõpuks võtab S6 enda alla koristustööd, signaalide töötlemise ja muud ülesanded.

Kuna kasutame erinevaid orkestreerimissüsteeme, peab konteiner pärast ehitamist ja käivitamist mõistma, milles keskkonnas ta asub ja tegutsema vastavalt sellele. Näiteks:
See võimaldab meil luua ühe pildi ja käivitada selle erinevates orkestreerimissüsteemides, kusjuures käivitamine toimub selle süsteemi spetsiifikat arvesse võttes.

 

Ühe ja sama konteineri jaoks saame Dockeris ja Kuberneteses erinevad protsessipuu.

Kasulik koormus töötab superviisor S6 all. Pange tähele collectorit ja events'i — need on meie agendid, mis vastutavad logide ja metrika eest. Kuberneteses neid pole, kuid Dockeris on. Miks? 

Kubernetesi podi spetsifikatsiooni vaatamisel märkame, et konteiner events käivitatakse podis, kus on eraldi konteiner collector, mis täidab meetrikate ja logide kogumise funktsiooni. Saame kasutada Kubernetes'e võimalusi: konteinerite käivitamine ühes podis, ühes protsessi- ja/või võrgu ruumis. Tegelikult saame oma agente juurutada ja teatud funktsioone täita. Ja kui sama konteiner käivitatakse Dockeri keskkonnas, saab ta kõik need samad võimed, st suudab logisid ja meetrikate edastada, kuna agendid on käivitatud siseselt. 

Metrikad ja logid

Metrikate ja logide edastamine on keeruline ülesanne. Selle lahendamisega on seotud mitmeid aspekte.
Infrastruktuur luuakse kasuliku koormuse täitmiseks, mitte logide massiliseks edastamiseks. Seega peaks see protsess toimuma minimaalsete nõudmistega konteinerite ressursside osas. Püüame aidata meie arendajatel: 'Võtke Docker Hub'i konteiner, käivitage see, ja me suudame logid edastada.' 

Teine aspekt on logide mahtude piiramine. Kui mitmes konteineris tekib logide mahu tõus (rakendus tsüklis väljastab stack-trace), suureneb koormus CPU-le, sideteedele ja logide töötlemise süsteemile, mis mõjutab kõigi hostitud konteinerite töökindlust, ning see võib põhjustada hosti "kukkumise". 

Kolmas aspekt on vajadus pakkuda võimalikult palju meetodeid mõõdikute kogumiseks juba vaikimisi. See hõlmab failide lugemist ja Prometheuse lõpp-punktide küsitlemist kuni rakendustele spetsiifiliste protokollide kasutamiseni.

Ja viimane aspekt on kohustust vähendada ressursikulu.

Oleme valinud avatud lähtekoodiga lahenduse Go-s nimega Telegraf. See on universaalne konnektor, mis toetab üle 140 erinevat sisendkanalit (input plugins) ja 30 erinevat väljundit (output plugins). Oleme teinud sellele täiendusi ja nüüd räägime, kuidas seda Kuberneteses kasutada. 

Kujutage ette, et arendaja juurutab koormust ja Kubernetes saab päringu podi loomise jaoks. Sel hetkel luuakse automaatselt iga podi jaoks konteiner nimega Collector (kasutame mutation webhook'i). Collector on meie agent. Käivitamisel seadistab see konteiner end töötama koos Prometheuse ja logide kogumise süsteemiga.

• Selle jaoks kasutab ta podi annotatsioone ning olenevalt nende sisust loob näiteks Prometheuse lõpppunkti (end-point); 
• Podi spetsifikatsiooni ja konteinerit eristavate seadete põhjal otsustab ta, kuidas logisid edastada.

Logisid kogume Docker API kaudu: arendajad peavad need lihtsalt stdout või stderr panema, ja edasi tegeleb Collector. Logid kogutakse chunk'idena teatud viivitusega, et vältida võimalikke hosti ülekoormusi. 

Metoodikat kogutakse töökoormuse (protsesside) eksemplaride järgi konteinerites. Kõik märgistatakse siltidega: namespace, pod jms, ja seejärel konverteeritakse Prometheuse vormingusse – ja muutub kergesti kogutavaks (logide puhul välja arvatud). Samuti saadame logid, mõõdikud ja sündmused Kafka kaudu edasi:

• Logid on saadaval Graylogis (visuaalse analüüsi jaoks);
• Logid, mõõdikud ja sündmused saadetakse Clickhouse'i pikaajaliseks säilitamiseks.

Sama töötab ka AWS-is, lihtsalt me asendame Graylogi Kafka ja Cloudwatchiga. Saadetakse logid sinna ja kõik muutub väga mugavaks: kohe on arusaadav, kelle klastriga ja konteineriga need seotud on. Sama kehtib ka Google Stackdriveri kohta. Seega meie skeem töötab nii on-premise'i Kafka kui ka pilves. 

Kui meil pole Kubernetes't koos podidega, siis skeem muutub veidi keerulisemaks, kuid töötab samade põhimõtete järgi.

Konteineri sees käivitatakse samad protsessid, neid orkestreeritakse S6 abil. Kõik samad protsessid on käivitatud ühes konteineris.

In conclusion,

Oleme loonud tervikliku lahenduse piltide koostamiseks ja tootmisse käivitamiseks, koos logide ja mõõdikute kogumise ja edastamise valikutega:

• Oleme välja töötanud standardiseeritud lähenemise piltide koostamiseks, mille alusel oleme loonud CI-malle;
• Andmete kogumise agentideks on meie Telegrafi laiendused. Oleme neid hästi testinud tootmises;
• Kasutame mutation webhook'i, et sisestada agente podidesse; 
• Oleme integreerunud Kubernetes/Rancheri ökosüsteemi;
• Saame käivitada samu konteinerite erinevates orkestreerimissüsteemides ja saavutada oodatud tulemuse;
• Loodi täielikult dünaamiline konteinerite haldamise konfiguratsioon. 

Kaastööline: Ilja Prudnikov

Allikas: habr.com