Questa storia hè di cumu usemu cuntenituri in un ambiente di produzzione, in particulare Kubernetes. L'articulu hè dedicatu à a cullizzioni di metriche è logs da cuntenituri, è ancu di custruisce l'imaghjini.

Semu da a cumpagnia fintech Exness, chì sviluppa servizii per u cummerciu in linea è prudutti fintech per B2B è B2C. A nostra R&D hà parechje squadre diverse, u dipartimentu di sviluppu hà più di 100 impiegati.

Rappresentemu a squadra chì hè rispunsevule per a piattaforma per i nostri sviluppatori per cullà è eseguisce codice. In particulare, simu rispunsevuli di cullà, almacenà è rappurtate metriche, logs, è avvenimenti da l'applicazioni. Attualmente operemu circa trè mila cuntenituri Docker in un ambiente di produzzione, mantenemu u nostru almacenamentu di big data 50 TB, è furnisce soluzioni architettoniche chì sò custruite intornu à a nostra infrastruttura: Kubernetes, Rancher, è diversi fornitori di nuvola publica. 

A nostra mutivazione

Chì brusgia ? Nimu pò risponde. Induve hè u focu ? Hè difficiuli à capisce. Quandu hà pigliatu u focu ? Pudete scopre, ma micca subitu. 

Perchè certi cuntenituri sò stati mentre altri sò cascati ? Quale cuntainer era à culpa ? Dopu tuttu, l'esternu di i cuntenituri sò listessi, ma à l'internu ognunu hà u so propiu Neo.

I nostri sviluppatori sò ragazzi competenti. Facenu boni servizii chì portanu prufittu à a cumpagnia. Ma ci sò fallimenti quandu i cuntenituri cù l'applicazioni si svianu. Un cuntainer cunsuma troppu CPU, un altru cunsuma a reta, un terzu cunsuma l'operazioni I / O, è u quartu ùn hè micca chjaru ciò chì faci cù sockets. Tuttu casca è a nave s'affonda. 

Agenti

Per capisce ciò chì succede in l'internu, avemu decisu di mette l'agenti direttamente in cuntenituri.

Questi agenti sò prugrammi di restrizzioni chì mantenenu i cuntenituri in un statu tali chì ùn si rompenu micca. L'agenti sò standardizati, è questu permette un approcciu standardizatu à i cuntenituri di serviziu. 

In u nostru casu, l'agenti devenu furnisce logs in un formatu standard, tagged and throttled. Ci anu da furnisce ancu metriche standardizzate chì sò estensibile da una perspettiva di l'applicazione cummerciale.

L'agenti significanu ancu utilità per u funziunamentu è u mantenimentu chì ponu travaglià in diversi sistemi di orchestrazione chì supportanu diverse imagine (Debian, Alpine, Centos, etc.).

Infine, l'agenti devenu supportà CI / CD simplici chì includenu i schedari Docker. Altrimenti, a nave caderà in pezzi, perchè i cuntenituri cumincianu à esse spediti longu i rails "storti".

Custruisce u prucessu è u dispositivu di l'imaghjini di destinazione

Per mantene tuttu standardizatu è gestibile, un tipu di prucessu di custruzzione standard deve esse seguitu. Per quessa, avemu decisu di cullà i cuntenituri per cuntenituri - questu hè recursione.

Quì i cuntenituri sò rapprisintati da contorni solidi. À u listessu tempu, anu decisu di mette kit di distribuzione in elli per chì "a vita ùn pare micca lamponi". Perchè questu hè statu fattu, spiegheremu quì sottu.
 
U risultatu hè un strumentu di creazione - un containeru specificu di versione chì riferisce versioni di distribuzione specifiche è versioni di script specifichi.

Cumu usemu? Avemu un Docker Hub chì cuntene un containeru. L'avemu specchiatu in u nostru sistema per sbarazzarsi di dipendenze esterne. U risultatu hè un cuntinuu marcatu in giallu. Creemu un mudellu per installà tutte e distribuzioni è script chì avemu bisognu in u cuntinuu. Dopu quì, assemblemu una maghjina pronta per l'usu: i sviluppatori mettenu u codice è alcune di e so dipendenze speciali. 

Chì ci hè di bonu in questu approcciu? 

• Prima, u cuntrollu tutale di a versione di l'arnesi di creazione - custruite versioni di container, script è distribuzione. 
• Siconda, avemu ottinutu a standardizazione: creamu mudelli, l'imaghjini intermedi è pronti à aduprà in u listessu modu. 
• Terzu, i cuntenituri ci danu a portabilità. Oghje usemu Gitlab, è dumani cambieremu à TeamCity o Jenkins è puderemu eseguisce i nostri cuntenituri in u listessu modu. 
• Quartu, minimizzà e dipendenze. Ùn era micca una coincidenza chì avemu messu i kit di distribuzione in u cuntinuu, perchè questu ci permette di evità di scaricallu da Internet ogni volta. 
• Quintu, a velocità di custruzzione hè aumentata - a presenza di copie lucali di l'imaghjini permette di evità di perde u tempu di scaricamentu, postu chì ci hè una maghjina lucale. 

In altre parolle, avemu ottinutu un prucessu di assemblea cuntrullatu è flexible. Utilizemu i stessi strumenti per custruisce qualsiasi cuntainer cumpletamente versioned. 

Cumu funziona a nostra prucedura di custruzzione

L'assemblea hè lanciata cù un cumandamentu, u prucessu hè eseguitu in l'imaghjini (saltatu in rossu). U sviluppatore hà un schedariu Docker (evidenziatu in giallu), u rendemu, rimpiazzà e variàbili cù valori. È in u caminu aghjunghjemu headers è footers - questi sò i nostri agenti. 

Header aghjusta distribuzioni da l'imaghjini currispundenti. È footer installà i nostri servizii in l'internu, cunfigura u lanciamentu di a carica di travagliu, logging è altri agenti, rimpiazza l'entrypoint, etc. 

Avemu pensatu per un bellu pezzu se installà un supervisore. À a fine, avemu decisu chì avemu bisognu di ellu. Avemu sceltu S6. U supervisore furnisce a gestione di u cuntainer: permette di cunnetta cù questu se u prucessu principalu crash è furnisce a gestione manuale di u cuntinuu senza ricreà. I logs è e metriche sò prucessi in esecuzione in u containeru. Ancu anu da esse cuntrullati in qualchì manera, è facemu questu cù l'aiutu di un supervisore. Infine, u S6 si occupa di a pulizia di a casa, di trasfurmazioni di signali è altre attività.

Siccomu usemu diversi sistemi d'orchestrazione, dopu à custruisce è in esecuzione, u cuntinuu deve capisce in quale ambiente si trova è agisce secondu a situazione. Per esempiu:
Questu ci permette di custruisce una maghjina è eseguisce in diversi sistemi d'orchestrazione, è serà lanciata in cunsiderà i specifichi di stu sistema d'orchestrazione.

 

Per u listessu cuntainer, uttene diverse arburi di prucessu in Docker è Kubernetes:

U payload hè eseguitu sottu a tutela di S6. Prestate attenzione à u cullettore è l'avvenimenti - questi sò i nostri agenti rispunsevuli di logs è metriche. Kubernetes ùn li hà micca, ma Docker hà. Perchè? 

Se guardemu à l'specificazione di u "pod" (in seguitu - Kubernetes pod), vedemu chì u cuntinuu di l'avvenimenti hè eseguitu in un pod, chì hà un containeru di cullezzione separatu chì eseguisce a funzione di cullizzioni di metriche è logs. Pudemu aduprà e capacità di Kubernetes: eseguisce cuntenituri in un pod, in un unicu prucessu è / o spaziu di rete. In realtà presentate i vostri agenti è eseguite alcune funzioni. È se u stessu containeru hè lanciatu in Docker, riceverà tutte e listesse capacità cum'è l'output, vale à dì, puderà furnisce logs è metriche, postu chì l'agenti seranu lanciati internamente. 

Metriche è logs

A consegna di metriche è logs hè un compitu cumplessu. Ci sò parechji aspetti di a so decisione.
L'infrastruttura hè creata per l'esekzione di u payload, è micca per a spedizione massiva di logs. Vale à dì, stu prucessu deve esse realizatu cù esigenze minimi di risorse di container. Ci sforzemu d'aiutà i nostri sviluppatori: "Ottene un containeru Docker Hub, eseguite, è pudemu furnisce i log". 

U sicondu aspettu hè limità u voluminu di logs. Se un surge in u voluminu di logs si trova in parechji cuntenituri (l'applicazione produce una stack-trace in un loop), a carica nantu à u CPU, i canali di cumunicazione è u sistema di processazione di log aumenta, è questu affetta u funziunamentu di l'ospite cum'è un cuntenituri sanu è altri nantu à l'ospitu, allora qualchì volta questu porta à "caduta" di l'ospite. 

U terzu aspettu hè chì hè necessariu di sustene quant'è metudi di cullizzioni di metrica pussibule fora di a scatula. Da leghje i fugliali è polling Prometheus-endpoint à aduprà protokolli specifichi di l'applicazione.

È l'ultimu aspettu hè di minimizzà u cunsumu di risorse.

Avemu sceltu una soluzione Go open-source chjamata Telegraf. Questu hè un connettore universale chì sustene più di 140 tipi di canali di input (plugins di input) è 30 tipi di canali di output (plugins di output). L'avemu finalizatu è avà vi diceremu cumu l'utilicemu usendu Kubernetes cum'è un esempiu. 

Diciamu chì un sviluppatore implementa una carica di travagliu è Kubernetes riceve una dumanda per creà un pod. À questu puntu, un cuntinuu chjamatu Collector hè creatu automaticamente per ogni pod (utilicemu mutazione webhook). U cullettore hè u nostru agente. À u principiu, stu cuntinuu si cunfigura per travaglià cù Prometheus è u sistema di raccolta di log.

• Per fà questu, usa annotazioni pod, è sicondu u so cuntenutu, crea, per dì, un puntu finale di Prometheus; 
• Basatu nantu à a specificazione di pod è paràmetri specifichi di u containeru, decide cumu furnisce i logs.

Raccogliamu logs via l'API Docker: i sviluppatori solu bisognu di mette in stdout o stderr, è u Collector l'arrangerà. I logs sò cullati in pezzi cù qualchì ritardu per prevene una eventuale sovraccarico di host. 

I metrici sò raccolti in istanze di carichi di travagliu (processi) in cuntenituri. Tuttu hè tagged: namespace, under, and so on, and then converted to Prometheus format - è diventa dispunibule per a cullizzioni (eccettu i logs). Mandemu ancu logs, metriche è avvenimenti à Kafka è ancu più:

• I logs sò dispunibili in Graylog (per l'analisi visuale);
• Logs, metriche, avvenimenti sò mandati à Clickhouse per un almacenamentu longu.

Tuttu funziona esattamente u listessu in AWS, solu noi rimpiazzà Graylog cù Kafka cù Cloudwatch. Mandemu i logs quì, è tuttu diventa assai cunvene: hè subitu chjaru à quale cluster è cuntainer appartenenu. U stessu hè veru per Google Stackdriver. Vale à dì, u nostru schema funziona sia in premisa cù Kafka sia in u nuvulu. 

Se ùn avemu micca Kubernetes cù pods, u schema hè un pocu più cumplicatu, ma travaglia nantu à i stessi principii.

I stessi prucessi sò eseguiti in u cuntinuu, sò orchestrati cù S6. Tutti i stessi prucessi sò in esecuzione in u stessu containeru.

Par via di cunsiquenza,

Avemu creatu una suluzione cumpleta per custruisce è lanciari l'imaghjini, cù opzioni per cullà è furnisce logs è metriche:

• Avemu sviluppatu un approcciu standardizatu per assemblà l'imaghjini, è basatu annantu à questu avemu sviluppatu mudelli CI;
• L'agenti di raccolta di dati sò e nostre estensioni Telegraf. Avemu pruvatu bè in a produzzione;
• Utilizemu mutazione webhook per implementà cuntenituri cù agenti in pods; 
• Integratu in l'ecosistema Kubernetes / Rancher;
• Pudemu eseguisce i stessi cuntenituri in diversi sistemi di orchestrazione è uttene u risultatu chì aspittemu;
• Criatu una cunfigurazione di gestione di container cumplettamente dinamica. 

Co-autore: Ilya Prudnikov

Source: www.habr.com