Ez a történet arról szól, hogyan használunk konténereket éles környezetben, különösen a Kubernetesben. A cikk a mérőszámok és naplók konténerekből való gyűjtésével, valamint az épületképekkel foglalkozik.

Az Exness fintech cégtől származunk, amely online kereskedési szolgáltatásokat és fintech termékeket fejleszt B2B és B2C számára. A K+F-nknek sokféle csapata van, a fejlesztési részleg több mint 100 alkalmazottat foglalkoztat.

Azt a csapatot képviseljük, amely felelős a fejlesztőink számára a kódgyűjtés és futtatás platformjáért. Különösen az alkalmazásokból származó mutatók, naplók és események összegyűjtéséért, tárolásáért és jelentéséért vagyunk felelősek. Jelenleg mintegy háromezer Docker konténert üzemeltetünk termelési környezetben, karbantartjuk 50 TB-os big data tárolónkat, és olyan építészeti megoldásokat biztosítunk, amelyek az infrastruktúránk köré épülnek: Kubernetes, Rancher és különböző nyilvános felhőszolgáltatók. 

A mi motivációnk

Mi ég? Senki nem tud válaszolni. Hol van a kandalló? Nehéz megérteni. Mikor gyulladt ki? Megtudhatod, de nem azonnal. 

Miért állnak egyes konténerek, míg mások leestek? Melyik konténer volt a hibás? Végül is a konténerek külseje ugyanaz, de belül mindegyiknek megvan a saját Neo.

A fejlesztőink hozzáértő srácok. Jó szolgáltatásokat nyújtanak, amelyek nyereséget hoznak a vállalat számára. De vannak hibák, amikor az alkalmazásokat tartalmazó tárolók félrecsúsznak. Az egyik konténer túl sok CPU-t fogyaszt, a másik a hálózatot, a harmadik az I/O műveleteket, a negyedik pedig teljesen homályos, hogy mit csinál a socketekkel. Minden leesik, és a hajó elsüllyed. 

Ügynökök

Hogy megértsük, mi történik odabent, úgy döntöttünk, hogy az ügynököket közvetlenül konténerekbe helyezzük.

Ezek az ágensek olyan visszatartó programok, amelyek a konténereket olyan állapotban tartják, hogy ne törjék szét egymást. Az ügynökök szabványosítottak, és ez szabványosított megközelítést tesz lehetővé a konténerek kiszolgálásában. 

Esetünkben az ügynököknek szabványos formátumban kell biztosítaniuk a naplókat, címkézve és korlátozva. Ezenkívül szabványosított mérőszámokat kell biztosítaniuk számunkra, amelyek üzleti alkalmazások szempontjából bővíthetők.

Az ügynökök olyan üzemeltetési és karbantartási segédprogramokat is jelentenek, amelyek különböző lemezképeket támogató különböző hangszerelési rendszerekben működhetnek (Debian, Alpine, Centos stb.).

Végül az ügynököknek támogatniuk kell az egyszerű CI-t/CD-t, amely Docker-fájlokat tartalmaz. Ellenkező esetben a hajó szétesik, mert a konténereket „görbe” sínek mentén kezdik szállítani.

Építsen folyamatot és célképes eszközt

Ahhoz, hogy minden szabványos és kezelhető legyen, valamilyen szabványos összeállítási folyamatot kell követni. Ezért úgy döntöttünk, hogy a konténereket konténerenként gyűjtjük – ez rekurzió.

Itt a konténereket tömör körvonalak ábrázolják. Ugyanakkor úgy döntöttek, hogy elosztókészleteket helyeznek el bennük, hogy „az élet ne málnának tűnjön”. Hogy miért történt ez, az alábbiakban elmagyarázzuk.
 
Az eredmény egy összeállítási eszköz – egy verzióspecifikus tároló, amely meghatározott terjesztési verziókra és adott szkriptverziókra hivatkozik.

Hogyan használjuk? Van egy Docker Hubunk, amely egy konténert tartalmaz. A rendszerünkben tükrözzük, hogy megszabaduljunk a külső függőségektől. Az eredmény egy sárgával jelölt tartály. Létrehozunk egy sablont az összes szükséges disztribúció és szkript telepítéséhez a tárolóba. Ezt követően összeállítunk egy használatra kész képet: a fejlesztők kódot és néhány saját speciális függőséget tesznek bele. 

Mi a jó ebben a megközelítésben? 

• Először is, az összeállítási eszközök teljes verziójának ellenőrzése – tároló-, szkript- és terjesztési verziók. 
• Másodszor, elértük a szabványosítást: ugyanúgy készítünk sablonokat, köztes és használatra kész képet. 
• Harmadszor, a konténerek hordozhatóságot biztosítanak számunkra. Ma Gitlabot használunk, holnap pedig TeamCityre vagy Jenkinsre váltunk, és ugyanúgy futtathatjuk majd a konténereinket. 
• Negyedszer, a függőségek minimalizálása. Nem véletlenül tettünk elosztó készleteket a konténerbe, mert így elkerülhetjük, hogy minden alkalommal letöltsük őket az internetről. 
• Ötödször, az építési sebesség nőtt - a képek helyi másolatainak jelenléte lehetővé teszi, hogy elkerülje a letöltésre való időveszteséget, mivel van helyi kép. 

Vagyis kontrollált és rugalmas összeszerelési folyamatot értünk el. Ugyanazokat az eszközöket használjuk a teljes verziójú konténerek elkészítéséhez. 

Hogyan működik az építési eljárásunk

Az összeállítás egy paranccsal indul, a folyamat a képen (pirossal kiemelve) lefut. A fejlesztőnek van egy Docker fájlja (sárgával kiemelve), ezt rendereljük, a változókat értékekkel helyettesítjük. És közben fejléceket és lábléceket adunk hozzá – ezek a mi ügynökeink. 

A fejléc disztribúciókat ad hozzá a megfelelő képekből. A lábléc pedig telepíti a szolgáltatásainkat, konfigurálja a munkaterhelés, naplózás és egyéb ügynökök indítását, lecseréli a belépési pontot stb. 

Sokáig gondolkodtunk, telepítsünk-e felügyelőt. Végül úgy döntöttünk, hogy szükségünk van rá. Mi az S6-ot választottuk. A felügyelő biztosítja a tárolókezelést: lehetővé teszi a csatlakozást, ha a fő folyamat összeomlik, és manuálisan kezeli a tárolót anélkül, hogy újra létrehozná. A naplók és a metrikák a tárolón belül futó folyamatok. Ezeket is ellenőrizni kell valahogy, és ezt egy felügyelő segítségével tesszük. Végül az S6 gondoskodik a háztartásról, a jelfeldolgozásról és egyéb feladatokról.

Mivel különböző hangszerelési rendszereket használunk, felépítés és futtatás után a konténernek meg kell értenie, hogy milyen környezetben van, és a helyzetnek megfelelően kell cselekednie. Például:
Ez lehetővé teszi, hogy egyetlen képet építsünk fel és futtassunk különböző hangszerelési rendszerekben, és ennek a hangszerelési rendszernek a sajátosságait figyelembe véve kerül forgalomba.

 

Ugyanahhoz a tárolóhoz különböző folyamatfákat kapunk a Dockerben és a Kubernetesben:

A hasznos teher végrehajtása az S6 felügyelete alatt történik. Ügyeljen a gyűjtőre és az eseményekre – ezek a naplókért és mérőszámokért felelős ügynökeink. A Kubernetes nem rendelkezik velük, a Docker viszont igen. Miért? 

Ha megnézzük a „pod” (továbbiakban – Kubernetes pod) specifikációját, azt látjuk, hogy az eseménykonténer egy podban van végrehajtva, amelynek külön gyűjtőtárolója van, amely a metrikák és naplók gyűjtését látja el. Használhatjuk a Kubernetes képességeit: konténerek futtatása egy podban, egyetlen folyamatban és/vagy hálózati térben. Valójában mutassa be ügynökeit, és hajtson végre néhány funkciót. És ha ugyanaz a konténer indul a Dockerben, akkor ugyanazokat a képességeket kapja, mint a kimenet, azaz képes lesz naplókat és mérőszámokat szállítani, mivel az ügynökök belső indítására kerülnek. 

Mérések és naplók

A mérőszámok és naplók megjelenítése összetett feladat. Döntésének több szempontja is van.
Az infrastruktúra a hasznos teher végrehajtására készült, nem pedig a naplók tömeges szállítására. Vagyis ezt a folyamatot minimális konténer-erőforrásigény mellett kell végrehajtani. Arra törekszünk, hogy segítsünk fejlesztőinknek: „Szerezzen egy Docker Hub tárolót, futtassa, és mi szállítjuk a naplókat.” 

A második szempont a rönkök mennyiségének korlátozása. Ha több tárolóban megugrik a naplók mennyisége (az alkalmazás egy hurokban ad ki egy verem-nyomkövetést), megnő a CPU, a kommunikációs csatornák és a naplófeldolgozó rendszer terhelése, és ez befolyásolja a gazdagép működését. egész és egyéb konténerek a gazdagépen, akkor ez néha a gazdagép "leeséséhez" vezet. 

A harmadik szempont az, hogy a lehető legtöbb mérőszám-gyűjtési módszert azonnal támogatni kell. A fájlok beolvasásától és a Prometheus-végpont lekérdezésétől az alkalmazásspecifikus protokollok használatáig.

Az utolsó szempont pedig az erőforrás-felhasználás minimalizálása.

A Telegraf nevű nyílt forráskódú Go megoldást választottuk. Ez egy univerzális csatlakozó, amely több mint 140 típusú bemeneti csatornát (bemeneti bővítményt) és 30 típusú kimeneti csatornát (kimeneti bővítményt) támogat. Véglegesítettük, és most a Kubernetes példáján elmondjuk, hogyan használjuk. 

Tegyük fel, hogy egy fejlesztő üzembe helyez egy munkaterhelést, és a Kubernetes kérést kap egy pod létrehozására. Ekkor minden egyes podhoz automatikusan létrejön egy Collector nevű tároló (mutációs webhookot használunk). A gyűjtő az ügynökünk. Kezdetben ez a tároló úgy konfigurálja magát, hogy működjön együtt a Prometheusszal és a naplógyűjtő rendszerrel.

• Ehhez pod annotációkat használ, és annak tartalmától függően létrehoz, mondjuk, egy Prometheus végpontot; 
• A pod-specifikáció és az adott tárolóbeállítások alapján dönti el, hogyan kell kézbesíteni a naplókat.

A naplókat a Docker API-n keresztül gyűjtjük: a fejlesztőknek csak az stdout-ba vagy az stderr-be kell helyezniük, és a Collector rendezi. A naplók összegyűjtése bizonyos késleltetéssel darabokban történik, hogy megakadályozzák a gazdagép esetleges túlterhelését. 

A mérőszámokat a munkaterhelés-példányok (folyamatok) között gyűjtik tárolókban. Minden meg van címkézve: névtér, alatt és így tovább, majd Prometheus formátumba konvertálva – és gyűjthetővé válik (kivéve a naplókat). Naplókat, mérőszámokat és eseményeket is küldünk Kafkának és a többieknek:

• A naplók Graylogban érhetők el (vizuális elemzéshez);
• A naplókat, mérőszámokat, eseményeket elküldik a Clickhouse-nak hosszú távú tárolás céljából.

Az AWS-ben minden pontosan ugyanúgy működik, csak a Graylogot Kafkára cseréljük a Cloudwatch-al. Oda küldjük a naplókat, és minden nagyon kényelmesnek bizonyul: azonnal kiderül, melyik klaszterhez és konténerhez tartoznak. Ugyanez igaz a Google Stackdriverre is. Vagyis a rendszerünk a helyszínen és a felhőben is működik a Kafkával. 

Ha nincs Kubernetesünk hüvelyekkel, akkor a séma kicsit bonyolultabb, de ugyanazon az elven működik.

Ugyanezek a folyamatok a konténeren belül is végrehajtódnak, S6-tal hangszerelve. Ugyanabban a tárolóban ugyanazok a folyamatok futnak.

Ennek eredményeképpen,

Komplett megoldást hoztunk létre a képek készítéséhez és elindításához, a naplók és mutatók összegyűjtésének és szállításának lehetőségeivel:

• Kidolgoztunk egy szabványosított megközelítést a képek összeállításához, és ennek alapján CI-sablonokat dolgoztunk ki;
• Az adatgyűjtő ügynökök a Telegraf bővítményeink. Jól teszteltük őket a gyártás során;
• Mutációs webhookot használunk az ügynököket tartalmazó konténerek elhelyezésére a hüvelyekben; 
• Integrált a Kubernetes/Rancher ökoszisztémába;
• Ugyanazokat a konténereket végrehajthatjuk különböző hangszerelési rendszerekben, és megkapjuk a várt eredményt;
• Teljesen dinamikus tárolókezelési konfigurációt hozott létre. 

Társszerző: Ilja Prudnyikov

Forrás: will.com