See lugu räägib, kuidas me kasutame konteinerite toote keskkonnas, eriti Kubernetes'i all. Artikkel käsitleb konteinerite mõõtmete ja logide kogumist ning piltide ehitamist.

Meie oleme finantstehnoloogia ettevõte Exness, mis arendab teenuseid online-kaubanduse ja finantstehnoloogiate toodete jaoks B2B ja B2C. Meie R&D-s on palju erinevaid meeskondi, arendusosakonnas üle 100 töötaja.

Esindame meeskonda, mis vastutab meie arendajate koodi kogumise ja käivitamise platvormi eest. Konkreetsemalt vastutame mõõtmete, logide ja sündmuste kogumise, salvestamise ja jagamise eest rakendustest. Praegu opereerime umbes kolme tuhande Docker-konteineriga toote keskkonnas, toetame meie 50 TB suurust big data hoidlat ning pakume arhitektuurilahendusi, mis on üles ehitatud meie infrastruktuuri ümber: Kubernetes, Rancher ja erinevad avalikud pilveteenuse pakkujad. 

Meie motivatsioon

Mis põleb? Keegi ei oska vastata. Kus on epitsenter? Selle mõistmine on keeruline. Millal see süttis? Seda saab täpsustada, aga mitte kohe. 

Miks mõned konteinerid seisavad, aga teised kukuvad? Milline konteiner on süüdi? Väljastpoolt näevad konteinerid välja identsed, kuid igaühe sees on oma Neo.

Meie arendajad on osavad kutid. Nad loovad häid teenuseid, mis toovad firmale kasumit. Kuid juhtub ka komplikatsioone, kui rakendustega konteinerid lähevad segamini. Üks konteiner tarbib liiga palju CPU-d, teine — võrku, kolmas — sisend-väljundoperatsioone, neljas pole üldse selge, mida teeb socketitega. Kõik see kukub ja laev uputab. 

Agendid

Selleks, et mõista, mis toimub sees, otsustasime paigutada agendid otse konteineritesse.

Need agendid on pidurprogrammid, mis hoiavad konteinerid sellises seisundis, et nad ei rikuks üksteist. Agendid on standardiseeritud, mis võimaldab standardiseerida lähenemist konteinerite hooldusele. 

Meie puhul peavad agendid andma logisid standardformaadis, märgitud ja throttle'itud. Samuti peavad nad andma meile standardiseeritud mõõtmeid, mis on ärirakenduste seisukohalt laiendatavad.

Agentide alla kuuluvad ka utiliidid ekspluateerimiseks ja hoolduseks, mis oskavad töötada erinevates orkestreerimissüsteemides, toetades erinevaid pilte (Debian, Alpine, Centos jne).

Lõpuks peavad agendid toetama lihtsat CI/CD-d, sealhulgas Docker-faile. Vastasel juhul laguneb laev, kuna konteinerid hakkavad tulema "kõveratel" rööbastel.

Kogumise protsess ja sihtpildi seadmed

Et kõik oleks standardiseeritud ja hallatav, on oluline järgida mingit standardset kogumisprotsessi. Seetõttu otsustasime koguda konteineritest konteinerid – selline rekursioon.

Siin on konteinerid esitatud pidevate kontuuridena. Samuti otsustasime panna neisse distributsioonid, et "elu ei näiks nii lihtne". Miks see tehtud sai, selgitame allpool.
 
Tulemuseks sai kogumise tööriist – kindla versiooniga konteiner, mis viitab teatud versioonidele distributsioonidest ja teatud versioonidele skriptidest.

Kuidas me seda rakendame? Meil on Docker Hub, kus konteiner asub. Kopeerime selle oma süsteemi, et vabaneda välistest sõltuvustest. Meil on konteiner, mis on tähistatud kollase värviga. Loome mall, et installida konteinerisse kõik vajalikud distributsioonid ja skriptid. Pärast seda kogume kasutamiseks valmis pildi: arendajad panevad sinna koodi ja mingid oma erilised sõltuvused. 

Miks on selline lähenemine hea? 

• Esiteks, täielik versioonihaldus kogumise tööriistadele – kogumise konteiner, skriptide ja distributsioonide versioonid. 
• Teiseks oleme saavutanud standardiseerimise: loome malli, vahepealseid ja kasutamiseks valmis pilte ühtsel viisil. 
• Kolmandaks, konteinerid tagavad meile portatiivsuse. Täna kasutame Gitlabi, aga homme saame üle TeamCity-le või Jenkinsile ja saame samamoodi käivitada meie konteinerid. 
• Neljandaks, sõltuvuste vähendamine. Me ei pannud juhuslikult konteinerisse distributsioonide, sest see võimaldab neid iga kord internetist alla laadida mitte. 
• Viies, kogumise kiirus on tõusnud – kohalike piltide olemasolu võimaldab mitte raisata aega allalaadimisele, kuna kohalikke pilte on olemas. 

Teisisõnu oleme saavutanud kontrollitava ja paindliku kogumisprotsessi. Kasutame kõigi konteinerite kogumiseks samu tööriistu, millel on täielik versioonihaldus. 

Kuidas meie kogumise protseduur töötab

Kogumine käivitub ühe käsuga, protsess toimub pildis (märgitud punasega). Arendajal on Docker-fail (märgitud kollasega), me renderdame selle, asendades muutujad väärtustega. Ja samal ajal lisame header’id ja footer’id – need on meie agendid. 

Header lisab distributsioonid vastavatest piltidest. Footer paigutab meie teenused, seadistab töökoormuse, logimise ja muud agenid, asendab entrypoint'i jne. 

Oleme kaua mõelnud, kas paigaldada superviisor. Lõpuks otsustasime, et see on vajalik. Valisime S6. Superviisor tagab konteineri halduse: võimaldab sellele juurde pääseda, kui põhiprotsess kukub, ja võimaldab käsitsi konteineri haldamist ilma seda uuesti loomata. Logid ja näidud on protsessid, mis kestavad konteineris. Need tuleb ka mingil viisil kontrollida, ja me teeme seda superviisori abiga. Lõpuks, S6 teeb koristustöid, signaalide töötlemist ja muid ülesandeid.

Kuna kasutame erinevaid orkestreerimissüsteeme, peab konteiner pärast kokkupanemist ja käivitamist aru saama, millises keskkonnas ta asub, ja toimima vastavalt olukorrale. Näiteks:
See võimaldab meil koguda ühe pildi ja käivitada selle erinevates orkestreerimissüsteemides, arvestades selle süsteemi eripära.

 

Sama konteineri jaoks saame erinevad protsessipuid Dockeris ja Kuberneteses:

Käitlemine toimub superviisori S6 all. Pange tähele, et collector ja events – need on meie agendid, kes vastutavad logide ja näitude eest. Kuberneteses pole neid, aga Dockeris on. Miks? 

Kui vaadata 'podi' spetsifikatsiooni (edaspidi – Kubernetes pod), näeme, et konteiner events käitub podis, kus on eraldi konteiner collector, mis täidab mõõtmete ja logide kogumise funktsiooni. Saame kasutada Kubernetes'e võimalusi: konteinerite käivitamine ühes podis, ühes protsessis ja/või võrgu ruumis. Tegelikult saame integreerida oma agendid ja täita erinevaid funktsioone. Ja kui sama konteiner käivitub Dockeris, saab ta kõik need samad võimalused, st saab edastada logisid ja näidiseid, kuna agendid käivitatakse sees. 

Näidud ja logid

Näidude ja logide edastamine on keeruline ülesanne. Selle lahendamisel on seotud mitmed aspektid.
Infrastruktuur luuakse kasuliku koormuse täitmiseks, mitte logide massiliseks edastamiseks. See tähendab, et see protsess peaks toimuma minimaalsete nõudmistega konteinerite ressurssidele. Meie eesmärk on aidata meie arendajatel: "Võtke Docker Hubi konteiner, käivitage see ja me saame logid edastada." 

Teine aspekt on logide mahu piiramine. Kui mitmes konteineris tekib logide mahu plahvatus (rakendus prindib pidevalt stack-trace'i), suureneb koormus CPU-le, sidekanalitele, logide töötlemise süsteemile, ja see mõjutab hosti üldist tööd ning muid konteinerid hostis, mis mõnikord viib hosti "kukkumiseni". 

Kolmas aspekt on see, et võimalikult palju metoodikaid mõõdikute kogumiseks tuleb tooteid välja pakkuda. Alates failide lugemisest ja Prometheuse lõpp-punkti küsitlusest kuni rakenduste spetsiifiliste protokollide kasutamiseni.

Ja viimane aspekt on ressursikasutuse minimeerimine.

Oleme valinud open-source lahenduse Go keeles nimega Telegraf. See on universaalne konnektor, mis toetab üle 140 erineva sisenemiskanali (input plugins) ja 30 väljundkanali (output plugins) tüübid. Oleme selle edasi arendanud ja nüüd räägime, kuidas seda meie Kuberneteses kasutada. 

Oletame, et arendaja käivitab koormuse ja Kubernetes saab taotluse podi loomiseks. Sel hetkel luuakse iga podi jaoks automaatselt konteiner nimega Collector (kasutame mutation webhooki). Collector on meie agent. Käivitamisel seadistab see konteiner end tööks Prometheuse ja logide kogumise süsteemiga.

• K selleks kasutab ta podi annotatsioone ning sõltuvalt nende sisust loob näiteks Prometheuse lõpp-punkti; 
• Pod'i spetsifikatsiooni ja konteinerite spetsiifiliste seadistuste põhjal otsustab, kuidas loge edastada.

Kogume logisid läbi Docker API: arendajatele piisab, kui nad panevad need stdout või stderr, ja edasi tegeleb Collector sellega. Logid kogutakse chunk'ides teatud viivitusega, et vältida võimaliku hosti ülekoormust. 

Mõõdikud kogutakse töökoormuste (protsesside) kaupa konteinerites. Kõik märgistatakse siltidega: namespace, pod jne., ja seejärel konverteeritakse Prometheuse vormingusse – ning muutub kogumiseks kättesaadavaks (välja arvatud logid). Samuti saadame logisid, mõõdikuid ja sündmusi Kafka'sse ja edasi:

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

Sama süsteem töötab ka AWS-is, lihtsalt asendame Graylogi Kafka ja Cloudwatchiga. Saadame sinna logid, mille tagajärjel on kõik väga mugav: kohe on selge, millisele klastrile ja konteinerile need kuuluvad. Sama kehtib ka Google Stackdriveri kohta. Meie skeem töötab nii on-premise lahenduses Kafka'ga kui ka pilves. 

Kui meil pole Kubernetes'e pod'e, on skeem pisut keerulisem, kuid toimib samade põhimõtete alusel.

Konteineri sees käivad samad protsessid, mida orkestreeritakse S6 abil. Kõik need protsessid on käivitatud ühes konteineris.

Kokkuvõttes

Oleme loonud tervikliku lahenduse piltide koostamiseks ja kasutusele võtmiseks, logide ja mõõdikute kogumise ja edastamise võimalustega:

• Oleme välja töötanud standardiseeritud lähenemise piltide koostamiseks ja selle alusel loonud CI-malle;
• Andmete kogumise agendid on meie Telegrafi laiendused. Oleme neid hästi testinud tootmises;
• Kasutame mutation webhook'i agendiga konteinerite sisestamiseks pod'desse; 
• Oleme integreerunud Kubernetes’e/Rancheri ökosüsteemi;
• Saame käitada samu konteinereid erinevates orkestreerimissüsteemides ja saavutada oodatud tulemuse;
• Oleme loonud täiesti dünaamilise konteinerihalduskonfiguratsiooni. 

Kaastoimetaja: Ilya Prudnikov

Allikas: habr.com