Þessi saga fjallar um hvernig við notum ílát í framleiðsluumhverfi, nánar tiltekið Kubernetes. Greinin er helguð söfnun mæligilda og annála úr gámum, auk þess að byggja myndir.

Við erum frá fintech fyrirtækinu Exness sem þróar þjónustu fyrir netviðskipti og fintech vörur fyrir B2B og B2C. R&D okkar hefur mörg mismunandi teymi, þróunardeildin hefur 100+ starfsmenn.

Við erum fulltrúar liðsins sem ber ábyrgð á vettvangi fyrir þróunaraðila okkar til að safna og keyra kóða. Sérstaklega erum við ábyrg fyrir því að safna, geyma og tilkynna mælikvarða, annála og atburði úr forritum. Við starfrækjum nú um það bil þrjú þúsund Docker gáma í framleiðsluumhverfi, viðhaldum 50 TB stórgagnageymslunni okkar og bjóðum upp á byggingarlausnir sem eru byggðar í kringum innviði okkar: Kubernetes, Rancher og ýmsar opinberar skýjaveitur. 

Hvatning okkar

Hvað brennur? Enginn getur svarað. Hvar er aflinn? Það er erfitt að skilja. Hvenær kviknaði í því? Þú getur komist að því, en ekki strax. 

Af hverju standa sumir gámar á meðan aðrir hafa fallið? Hvaða gámum var um að kenna? Þegar öllu er á botninn hvolft eru ílátin eins að utan, en að innan hefur hver og einn sinn Neo.

Hönnuðir okkar eru hæfir krakkar. Þeir gera góða þjónustu sem skilar hagnaði til fyrirtækisins. En það eru bilanir þegar gámar með forritum fara afvega. Einn gámur eyðir of miklum örgjörva, annar eyðir netinu, sá þriðji eyðir I/O aðgerðum og sá fjórði er algjörlega óljóst hvað hann gerir við innstungur. Það fellur allt og skipið sekkur. 

Umboðsmenn

Til að skilja hvað er að gerast inni ákváðum við að setja umboðsmenn beint í gáma.

Þessir aðilar eru aðhaldsáætlanir sem halda ílátunum í því ástandi að þeir brjóta ekki hvert annað. Umboðsaðilar eru staðlaðir og það gerir ráð fyrir staðlaðri nálgun við að þjónusta gáma. 

Í okkar tilviki verða umboðsmenn að útvega annála á stöðluðu sniði, merkt og innifalið. Þeir ættu einnig að veita okkur staðlaðar mælingar sem eru stækkanlegar frá sjónarhóli viðskiptaumsóknar.

Umboðsmenn meina einnig tól fyrir rekstur og viðhald sem geta virkað í mismunandi hljómsveitarkerfum sem styðja mismunandi myndir (Debian, Alpine, Centos o.s.frv.).

Að lokum verða umboðsmenn að styðja einfalda CI/CD sem inniheldur Docker skrár. Annars mun skipið falla í sundur, vegna þess að byrjað er að afhenda gáma eftir „skökkum“ teinum.

Byggja ferli og miða mynd tæki

Til að halda öllu stöðluðu og viðráðanlegu þarf að fylgja einhvers konar stöðluðu byggingarferli. Þess vegna ákváðum við að safna gámum eftir gámum - þetta er endurkoma.

Hér eru ílátin táknuð með traustum útlínum. Á sama tíma ákváðu þeir að setja dreifingarsett í þá þannig að „lífið virðist ekki eins og hindber“. Hvers vegna þetta var gert, munum við útskýra hér að neðan.
 
Niðurstaðan er smíðaverkfæri — útgáfusértækur gámur sem vísar til tiltekinna dreifingarútgáfu og tiltekinna handritaútgáfu.

Hvernig notum við það? Við erum með Docker Hub sem inniheldur ílát. Við speglum það inni í kerfinu okkar til að losna við ytri ósjálfstæði. Útkoman er ílát merkt með gulu. Við búum til sniðmát til að setja upp allar dreifingar og forskriftir sem við þurfum í ílátið. Eftir það setjum við saman mynd sem er tilbúin til notkunar: forritarar setja kóða og eitthvað af eigin sérstökum ósjálfstæði í það. 

Hvað er gott við þessa nálgun? 

• Í fyrsta lagi fulla útgáfustýringu á byggingarverkfærum - smíða gáma, skriftu og dreifingarútgáfur. 
• Í öðru lagi höfum við náð stöðlun: við búum til sniðmát, millimyndir og tilbúnar til notkunar á sama hátt. 
• Í þriðja lagi gefa gámar okkur færanleika. Í dag notum við Gitlab og á morgun munum við skipta yfir í TeamCity eða Jenkins og við munum geta keyrt gámana okkar á sama hátt. 
• Í fjórða lagi, lágmarka ósjálfstæði. Það var engin tilviljun að við settum dreifingarsett í gáminn því þetta gerir okkur kleift að forðast að hala þeim niður af netinu í hvert skipti. 
• Í fimmta lagi hefur byggingarhraði aukist - tilvist staðbundinna afrita af myndum gerir þér kleift að forðast að eyða tíma í niðurhal, þar sem það er staðbundin mynd. 

Með öðrum orðum, við höfum náð stýrðu og sveigjanlegu samsetningarferli. Við notum sömu verkfæri til að smíða hvaða ílát sem er í fullri útgáfu. 

Hvernig byggingarferlið okkar virkar

Samkoman er sett af stað með einni skipun, ferlið er keyrt á myndinni (auðkennt með rauðu). Framkvæmdaraðilinn er með Docker skrá (auðkennt með gulu), við gerum hana og skiptum út breytum fyrir gildi. Og á leiðinni bætum við við hausum og fótum - þetta eru umboðsmenn okkar. 

Header bætir við dreifingu úr samsvarandi myndum. Og fótur setur upp þjónustu okkar inni, stillir upphaf vinnuálags, skógarhögg og aðra umboðsmenn, kemur í stað inngangspunkts osfrv. 

Við hugsuðum lengi hvort setja ætti upp umsjónarmann. Á endanum ákváðum við að við þyrftum á honum að halda. Við völdum S6. Umsjónarmaður veitir gámastjórnun: gerir þér kleift að tengjast því ef aðalferlið hrynur og veitir handvirka stjórnun á gámnum án þess að endurskapa það. Logs og mæligildi eru ferli sem keyra inni í gámnum. Það þarf líka að stjórna þeim einhvern veginn og það gerum við með aðstoð yfirmanns. Loks sér S6 um heimilishald, merkjavinnslu og önnur verkefni.

Þar sem við notum mismunandi hljómsveitarkerfi, eftir að búið er að byggja og keyra, verður gámurinn að skilja í hvaða umhverfi hann er og starfa í samræmi við aðstæður. Til dæmis:
Þetta gerir okkur kleift að byggja eina mynd og keyra hana í mismunandi hljómsveitarkerfi og hún verður sett í gang með hliðsjón af sérkennum þessa hljómsveitarkerfis.

 

Fyrir sama ílát fáum við mismunandi vinnslutré í Docker og Kubernetes:

Burðargetan er framkvæmt undir eftirliti S6. Gefðu gaum að safnara og viðburðum - þetta eru umboðsmenn okkar sem bera ábyrgð á annálum og mælingum. Kubernetes er ekki með þá, en Docker gerir það. Hvers vegna? 

Ef við skoðum forskriftina fyrir „belg“ (hér eftir – Kubernetes fræbelgur), munum við sjá að atburðagámurinn er keyrður í belg, sem hefur aðskilið söfnunarílát sem sinnir því hlutverki að safna mælingum og annálum. Við getum notað möguleika Kubernetes: keyra gáma í einum belg, í einu ferli og/eða netrými. Kynntu í raun umboðsmenn þína og framkvæma nokkrar aðgerðir. Og ef sami gámur er hleypt af stokkunum í Docker mun hann fá alla sömu möguleika og framleiðsla, það er að segja að hann geti skilað annálum og mælingum, þar sem umboðsmennirnir verða ræstir innbyrðis. 

Mælingar og logs

Það er flókið verkefni að skila mælingum og annálum. Það eru nokkrir þættir í ákvörðun hennar.
Uppbyggingin er búin til fyrir framkvæmd farmsins, en ekki til fjöldaafhendingar á logum. Það er, þetta ferli verður að fara fram með lágmarkskröfum um gámaauðlind. Við leitumst við að hjálpa þróunaraðilum okkar: "Fáðu Docker Hub gám, keyrðu hann og við getum afhent annálana." 

Annar þátturinn er að takmarka magn af annálum. Ef aukning á magni annála á sér stað í nokkrum gámum (forritið gefur frá sér staflaspor í lykkju), eykst álagið á örgjörva, samskiptarásir og annálavinnslukerfi og það hefur áhrif á rekstur hýsilsins sem heilum og öðrum ílátum á hýsilinn, þá leiðir þetta stundum til "falls" hýsilsins. 

Þriðji þátturinn er sá að nauðsynlegt er að styðja við eins margar aðferðir við söfnun mæligilda og mögulegt er. Allt frá því að lesa skrár og skoða Prometheus-endapunkt til að nota sértækar samskiptareglur fyrir forrit.

Og síðasti þátturinn er að lágmarka auðlindanotkun.

Við völdum opinn Go lausn sem heitir Telegraf. Þetta er alhliða tengi sem styður meira en 140 gerðir af inntaksrásum (inntaksviðbætur) og 30 tegundir af úttaksrásum (úttaksviðbætur). Við höfum gengið frá því og nú munum við segja þér hvernig við notum það með Kubernetes sem dæmi. 

Segjum að verktaki sendi inn vinnuálag og Kubernetes fái beiðni um að búa til fræbelg. Á þessum tímapunkti er gámur sem heitir Collector sjálfkrafa búinn til fyrir hvern belg (við notum stökkbreytingar vefhook). Safnari er umboðsmaður okkar. Í upphafi stillir þessi gámur sig til að vinna með Prometheus og annálasöfnunarkerfinu.

• Til að gera þetta notar það belgskýringar og skapar, til dæmis, Prometheus endapunkt, allt eftir innihaldi þess; 
• Byggt á belgforskriftinni og sérstökum gámastillingum ákveður það hvernig á að afhenda annála.

Við söfnum annálum í gegnum Docker API: forritarar þurfa bara að setja þá í stdout eða stderr, og Collector mun redda því. Logum er safnað í klumpur með nokkurri töf til að koma í veg fyrir mögulega ofhleðslu hýsils. 

Mælingum er safnað yfir vinnuálagstilvik (ferla) í gámum. Allt er merkt: nafnrými, undir, og svo framvegis, og síðan breytt í Prometheus snið - og verður aðgengilegt fyrir söfnun (nema logs). Við sendum einnig annála, mælikvarða og atburði til Kafka og fleira:

• Logs eru fáanlegir í Graylog (fyrir sjónræna greiningu);
• Logs, mælikvarðar, atburðir eru sendir til Clickhouse til langtímageymslu.

Allt virkar nákvæmlega eins í AWS, aðeins við skiptum Graylog út fyrir Kafka fyrir Cloudwatch. Við sendum annálana þangað og allt reynist mjög þægilegt: það er strax ljóst hvaða þyrping og ílát þeir tilheyra. Sama á við um Google Stackdriver. Það er, kerfið okkar virkar bæði á staðnum með Kafka og í skýinu. 

Ef við erum ekki með Kubernetes með fræbelg er kerfið aðeins flóknara, en það virkar á sömu meginreglum.

Sömu ferli eru framkvæmd inni í gámnum, þau eru skipulögð með S6. Öll sömu ferlarnir eru í gangi í sama ílátinu.

Þar af leiðandi,

Við höfum búið til heildarlausn til að byggja og opna myndir, með valkostum til að safna og afhenda annálum og mæligildum:

• Við þróuðum staðlaða nálgun við að setja saman myndir og út frá henni þróuðum við CI sniðmát;
• Gagnasöfnunaraðilar eru Telegraf viðbætur okkar. Við prófuðum þá vel í framleiðslu;
• Við notum stökkbreytingar vefhook til að útfæra ílát með efni í belg; 
• Innbyggt í Kubernetes/Rancher vistkerfið;
• Við getum framkvæmt sömu gámana í mismunandi hljómsveitarkerfi og fengið þá niðurstöðu sem við búumst við;
• Búið til algjörlega kraftmikla gámastjórnunarstillingu. 

Meðhöfundur: Ilya Prudnikov

Heimild: www.habr.com