See lugu räägib sellest, kuidas me kasutame konteinereid tootmiskeskkonnas, täpsemalt Kubernetes. Artikkel on pühendatud konteineritest mõõdikute ja logide kogumisele, samuti piltide loomisele.

Oleme fintech-ettevõttest Exness, mis arendab teenuseid online-kauplemiseks ning fintech-tooteid B2B ja B2C jaoks. Meie teadus- ja arendustegevuses on palju erinevaid meeskondi, arendusosakonnas on üle 100 töötaja.

Me esindame meeskonda, kes vastutab platvormi eest, et meie arendajad saaksid koodi koguda ja käitada. Eelkõige vastutame rakenduste mõõdikute, logide ja sündmuste kogumise, salvestamise ja aruandluse eest. Praegu kasutame tootmiskeskkonnas ligikaudu kolme tuhat Dockeri konteinerit, hooldame oma 50 TB suurandmesalvestust ja pakume arhitektuurseid lahendusi, mis on üles ehitatud meie infrastruktuurile: Kubernetes, Rancher ja erinevad avalikud pilveteenuse pakkujad. 

Meie motivatsioon

Mis põleb? Keegi ei oska vastata. Kus on kolle? Seda on raske mõista. Millal see põlema läks? Saate teada, kuid mitte kohe. 

Miks mõned konteinerid seisavad, teised aga alla kukkunud? Milline konteiner oli süüdi? Konteinerid on ju väljast ühesugused, aga sees on igaühel oma Neo.

Meie arendajad on pädevad poisid. Nad pakuvad häid teenuseid, mis toovad ettevõttele kasumit. Kuid on tõrkeid, kui rakendustega konteinerid eksivad. Üks konteiner tarbib liiga palju CPU-d, teine ​​võrku, kolmas sisend-väljundoperatsioone ja neljas on täiesti ebaselge, mida ta pistikupesadega teeb. See kõik kukub ja laev upub. 

Esindajad

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

Need ained on ohjeldusprogrammid, mis hoiavad konteinereid sellises olekus, et need üksteist ei lõhuks. Agendid on standardiseeritud ja see võimaldab standardiseeritud lähenemist konteinerite teenindamisele. 

Meie puhul peavad agendid esitama logid standardvormingus, sildistatud ja piiratud. Samuti peaksid nad pakkuma meile standardiseeritud mõõdikuid, mis on ärirakenduste vaatenurgast laiendatavad.

Agendid tähendavad ka käitamise ja hoolduse utiliite, mis võivad töötada erinevates orkestreerimissüsteemides, mis toetavad erinevaid pilte (Debian, Alpine, Centos jne).

Lõpuks peavad agendid toetama lihtsat CI/CD-d, mis sisaldavad Dockeri faile. Vastasel juhul laguneb laev laiali, sest konteinereid hakatakse toimetama mööda “kõveraid” rööpaid.

Ehitage protsess ja sihtige pildiseade

Et kõik oleks standardiseeritud ja hallatav, tuleb järgida mingit standardset koostamisprotsessi. Seetõttu otsustasime koguda konteinereid konteinerite kaupa – see on rekursioon.

Siin on konteinerid kujutatud kindlate piirjoontega. Samal ajal otsustasid nad panna neisse jaotuskomplektid, et "elu ei tunduks vaarikad". Miks seda tehti, selgitame allpool.
 
Tulemuseks on koostamistööriist – versioonispetsiifiline konteiner, mis viitab konkreetsetele levitamisversioonidele ja konkreetsetele skriptiversioonidele.

Kuidas me seda kasutame? Meil on Dockeri jaotur, mis sisaldab konteinerit. Me peegeldame seda oma süsteemi sees, et vabaneda välistest sõltuvustest. Tulemuseks on kollase märgistusega anum. Loome malli kõigi vajalike distributsioonide ja skriptide installimiseks konteinerisse. Pärast seda paneme kokku kasutusvalmis pildi: arendajad panevad sellesse koodi ja mõned oma erisõltuvused. 

Mis on selles lähenemisviisis head? 

• Esiteks, ehitustööriistade täielik versioonikontroll – ehituskonteiner, skript ja levitamise versioonid. 
• Teiseks oleme saavutanud standardimise: loome ühtmoodi malle, vahe- ja kasutusvalmis pilti. 
• Kolmandaks annavad konteinerid meile kaasaskantavuse. Täna kasutame Gitlabi ja homme läheme TeamCityle või Jenkinsile ning saame samamoodi oma konteinereid käitada. 
• Neljandaks, sõltuvuste minimeerimine. Ei olnud juhus, et panime konteinerisse jaotuskomplektid, sest see võimaldab vältida nende iga kord Internetist allalaadimist. 
• Viiendaks on ehituskiirus suurenenud - piltide kohalike koopiate olemasolu võimaldab vältida allalaadimisele aja raiskamist, kuna seal on kohalik pilt. 

Teisisõnu, oleme saavutanud kontrollitud ja paindliku montaažiprotsessi. Kasutame samu tööriistu mis tahes täisversiooniga konteinerite koostamiseks. 

Kuidas meie ehitusprotseduur töötab

Koost käivitatakse ühe käsuga, protsess käivitatakse pildil (punasega esile tõstetud). Arendajal on Dockeri fail (kollasega esile tõstetud), me renderdame selle, asendades muutujad väärtustega. Ja tee peale lisame päiseid ja jaluseid – need on meie agendid. 

Päis lisab vastavate piltide distributsioonid. Jalus installib meie teenused sisse, konfigureerib töökoormuse, logimise ja muude agentide käivitamise, asendab sisenemispunkti jne. 

Mõtlesime kaua, kas paigaldada järelevaataja. Lõpuks otsustasime, et vajame teda. Valisime S6. Juhendaja pakub konteinerihaldust: võimaldab teil sellega ühenduse luua, kui põhiprotsess jookseb kokku ja võimaldab konteinerit käsitsi hallata ilma seda uuesti loomata. Logid ja mõõdikud on konteineris töötavad protsessid. Neid tuleb ka kuidagi kontrollida ja me teeme seda juhendaja abiga. Lõpuks hoolitseb S6 majapidamise, signaalitöötluse ja muude ülesannete eest.

Kuna kasutame erinevaid orkestreerimissüsteeme, peab konteiner pärast ehitamist ja käivitamist aru saama, millises keskkonnas ta on, ning tegutsema vastavalt olukorrale. Näiteks:
See võimaldab meil ehitada ühe pildi ja käivitada seda erinevates orkestreerimissüsteemides ning see käivitatakse selle orkestreerimissüsteemi eripärasid arvestades.

 

Sama konteineri jaoks saame Dockeris ja Kubernetesis erinevad protsessipuud:

Kasulik koormus täidetakse S6 järelevalve all. Pöörake tähelepanu kogujale ja sündmustele – need on meie agendid, kes vastutavad logide ja mõõdikute eest. Kubernetesel neid pole, aga Dockeril on. Miks? 

Kui vaatame “podi” (edaspidi – Kubernetes pod) spetsifikatsiooni, siis näeme, et sündmuste konteiner täidetakse podis, millel on eraldiseisev kollektori konteiner, mis täidab mõõdikute ja logide kogumise funktsiooni. Saame kasutada Kubernetese võimalusi: konteinerite käitamine ühes podis, ühes protsessis ja/või võrguruumis. Tegelikult tutvustage oma agente ja täitke mõnda funktsiooni. Ja kui sama konteiner käivitatakse Dockeris, saab see kõik samad võimalused kui väljund, see tähendab, et see suudab edastada logisid ja mõõdikuid, kuna agendid käivitatakse sisemiselt. 

Mõõdikud ja logid

Mõõdikute ja logide edastamine on keeruline ülesanne. Tema otsusel on mitu aspekti.
Taristu on loodud kasuliku koormuse täitmiseks, mitte palkide massiliseks kohaletoimetamiseks. See tähendab, et see protsess tuleb läbi viia minimaalse konteineri ressursivajadusega. Püüame oma arendajaid aidata: "Hankige Docker Hubi konteiner, käivitage see ja me saame logid kohale toimetada." 

Teine aspekt on palkide mahu piiramine. Kui logide mahu suurenemine toimub mitmes konteineris (rakendus väljastab ahelas virnajälje), suureneb protsessori, sidekanalite ja logitöötlussüsteemi koormus ning see mõjutab hosti tööd terveid ja muid hosti konteinereid, siis mõnikord viib see hosti "kukkumiseni". 

Kolmas aspekt on see, et on vaja toetada võimalikult paljusid mõõdikute kogumise meetodeid. Alates failide lugemisest ja Prometheuse lõpp-punkti küsitlemisest kuni rakendusspetsiifiliste protokollide kasutamiseni.

Ja viimane aspekt on ressursside tarbimise minimeerimine.

Valisime avatud lähtekoodiga Go lahenduse nimega Telegraf. See on universaalne pistik, mis toetab enam kui 140 tüüpi sisendkanaleid (sisendpluginaid) ja 30 tüüpi väljundkanaleid (väljundpluginaid). Oleme selle lõpule viinud ja nüüd räägime teile, kuidas me seda kasutame, kasutades näitena Kubernetes. 

Oletame, et arendaja juurutab töökoormuse ja Kubernetes saab taotluse podi loomiseks. Siinkohal luuakse iga kausta jaoks automaatselt konteiner nimega Collector (kasutame mutatsiooni veebihaagi). Koguja on meie agent. Alguses konfigureerib see konteiner end töötama Prometheuse ja logide kogumise süsteemiga.

• Selleks kasutab ta pod annotatsioone ja loob olenevalt selle sisust näiteks Prometheuse lõpp-punkti; 
• Tuginedes podi spetsifikatsioonile ja konkreetsetele konteineri sätetele, otsustab see, kuidas logid edastada.

Kogume logisid Dockeri API kaudu: arendajatel tuleb need lihtsalt panna stdout või stderr ja Collector sorteerib need välja. Logid kogutakse tükkidena teatud viivitusega, et vältida hosti võimalikku ülekoormust. 

Mõõdikud kogutakse töökoormuse eksemplaride (protsesside) lõikes konteineritesse. Kõik on märgistatud: nimeruum, all ja nii edasi ning seejärel teisendatakse Prometheuse vormingusse – ja see muutub kogumiseks kättesaadavaks (välja arvatud logid). Samuti saadame logisid, mõõdikuid ja sündmusi Kafkale ja mujale:

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

AWS-is töötab kõik täpselt samamoodi, ainult et Graylogi asendame Kafkaga Cloudwatchiga. Saadame logid sinna ja kõik osutub väga mugavaks: kohe on selge, millisesse kobarasse ja konteinerisse need kuuluvad. Sama kehtib ka Google Stackdriveri kohta. See tähendab, et meie skeem töötab nii Kafkaga kohapeal kui ka pilves. 

Kui meil kaunadega Kubernetes pole, on skeem veidi keerulisem, kuid töötab samadel põhimõtetel.

Samad protsessid teostatakse konteineris, need on orkestreeritud S6 abil. Kõik samad protsessid töötavad samas konteineris.

Selle tulemusena

Oleme loonud tervikliku lahenduse piltide koostamiseks ja käivitamiseks, mis sisaldab võimalusi logide ja mõõdikute kogumiseks ja edastamiseks:

• Töötasime välja standardiseeritud lähenemise piltide kokkupanemisele ja selle põhjal töötasime välja CI mallid;
• Andmekogumisagendid on meie Telegrafi laiendused. Testisime neid tootmises hästi;
• Kasutame mutatsiooniveebihaaki, et juurutada kaunades olevaid agente sisaldavaid konteinereid; 
• Integreeritud Kubernetes/Rancheri ökosüsteemi;
• Saame teostada samu konteinereid erinevates orkestreerimissüsteemides ja saada oodatud tulemuse;
• Loodud täiesti dünaamiline konteinerihalduse konfiguratsioon. 

Kaasautor: Ilja Prudnikov

Allikas: www.habr.com