Carita ieu ngeunaan kumaha urang ngagunakeun peti dina lingkungan produksi, khususna Kubernetes. Artikel ieu dikhususkeun pikeun ngumpulkeun métrik sareng log tina wadah, ogé ngawangun gambar.

Kami ti perusahaan fintech Exness, anu ngembangkeun jasa pikeun dagang online sareng produk fintech pikeun B2B sareng B2C. Urang R&D boga loba tim béda, departemén ngembangkeun boga 100+ pagawé.

Kami ngawakilan tim anu tanggung jawab pikeun platform pikeun pamekar kami pikeun ngumpulkeun sareng ngajalankeun kode. Khususna, kami tanggung jawab pikeun ngumpulkeun, nyimpen sareng ngalaporkeun métrik, log, sareng acara tina aplikasi. Kami ayeuna ngajalankeun kira-kira tilu rébu wadah Docker di lingkungan produksi, ngajaga panyimpen data ageung 50 TB kami, sareng nyayogikeun solusi arsitéktur anu diwangun dina infrastruktur kami: Kubernetes, Rancher, sareng sagala rupa panyadia awan umum. 

Motivasi urang

Naon nu ngaduruk? Taya nu bisa ngajawab. Dimana hearth? Hésé kaharti. Iraha éta seuneu? Anjeun tiasa manggihan, tapi teu langsung. 

Naha sababaraha wadahna nangtung sedengkeun anu sanésna murag? Wadah mana anu disalahkeun? Barina ogé, luar wadahna sami, tapi di jero masing-masing gaduh Neo sorangan.

Pamekar kami mangrupikeun jalma anu kompeten. Aranjeunna ngadamel jasa anu saé anu mawa kauntungan pikeun perusahaan. Tapi aya kagagalan nalika wadah sareng aplikasi sesat. Hiji wadah meakeun teuing CPU, sejen meakeun jaringan, sapertilu meakeun operasi I / O, jeung kaopat sagemblengna can écés naon eta teu kalawan sockets. Éta kabéh ragrag jeung kapal tilelep. 

Agén

Pikeun ngartos naon anu lumangsung di jero, kami mutuskeun pikeun nempatkeun agén langsung dina wadahna.

Agén-agén ieu ngahalangan program anu ngajaga wadahna dina kaayaan anu henteu silih pegat. Agén distandarisasi, sareng ieu ngamungkinkeun pendekatan standar pikeun ngalayanan wadahna. 

Dina kasus urang, agén kedah nyayogikeun log dina format standar, ditandaan sareng di-throttled. Éta ogé kedah nyayogikeun kami métrik standar anu tiasa diperpanjang tina sudut pandang aplikasi bisnis.

Agén ogé hartosna utilitas pikeun operasi sareng pangropéa anu tiasa dianggo dina sistem orkestrasi anu béda anu ngadukung gambar anu béda (Debian, Alpine, Centos, jsb.).

Tungtungna, agén kedah ngadukung CI / CD saderhana anu kalebet file Docker. Upami teu kitu, kapal bakal murag, sabab peti bakal mimiti dikirimkeun sapanjang rel "bengkung".

Proses ngawangun sareng alat gambar target

Pikeun ngajaga sadayana standar sareng tiasa diurus, sababaraha jinis prosés ngawangun standar kedah dituturkeun. Ku alatan éta, urang mutuskeun pikeun ngumpulkeun peti ku peti - ieu recursion.

Di dieu wadahna digambarkeun ku outlines padet. Dina waktos anu sami, aranjeunna mutuskeun pikeun nempatkeun kit distribusi di aranjeunna supados "hirup henteu siga buah prambus." Naha ieu dipigawé, urang bakal ngajelaskeun handap.
 
Hasilna mangrupikeun alat ngawangun-wadah khusus versi anu ngarujuk versi distribusi khusus sareng versi naskah khusus.

Kumaha urang ngagunakeunana? Kami gaduh Docker Hub anu ngandung wadahna. Urang eunteung di jero sistem urang pikeun ngaleungitkeun kagumantungan éksternal. hasilna mangrupakeun wadah ditandaan konéng. Urang nyieun template pikeun masang sagala sebaran jeung Aksara urang kudu kana wadahna. Saatos éta, urang ngumpul gambar anu siap dianggo: pamekar nempatkeun kode sareng sababaraha katergantungan khususna. 

Naon anu hadé ngeunaan pendekatan ieu? 

• Kahiji, kadali vérsi pinuh ku alat ngawangun - ngawangun wadah, naskah sareng versi distribusi. 
• Bréh, urang geus ngahontal standarisasi: urang nyieun témplat, gambar panengah jeung siap pake dina cara nu sarua. 
• Katilu, wadah masihan kami portability. Dinten ieu kami nganggo Gitlab, sareng énjing kami bakal ngalih ka TeamCity atanapi Jenkins sareng kami bakal tiasa ngajalankeun wadahna ku cara anu sami. 
• Kaopat, ngaminimalkeun kagumantungan. Henteu kabeneran yén kami nempatkeun kit distribusi dina wadahna, sabab ieu ngamungkinkeun urang pikeun ngahindarkeun ngaunduhana tina Internét unggal waktos. 
• Kalima, laju ngawangun parantos ningkat - ayana salinan gambar lokal ngamungkinkeun anjeun pikeun ngahindarkeun waktos ngaunduh, sabab aya gambar lokal. 

Dina basa sejen, kami geus kahontal prosés assembly dikawasa sarta fléksibel. Kami nganggo alat anu sami pikeun ngawangun wadah anu pinuh versi. 

Kumaha prosedur ngawangun urang jalan

Majelis diluncurkeun ku hiji paréntah, prosésna dieksekusi dina gambar (disorot beureum). Pamekar ngagaduhan file Docker (disorot dina warna konéng), kami render, ngagentos variabel sareng nilai. Sareng sapanjang jalan kami nambihan header sareng footer - ieu mangrupikeun agén kami. 

Header nambihan distribusi tina gambar anu cocog. Sareng footer masang jasa kami di jero, ngonpigurasikeun peluncuran beban kerja, logging sareng agén sanésna, ngagentos titik entri, jsb. 

Urang mikir pikeun lila naha install supervisor a. Tungtungna, urang mutuskeun yén urang peryogi anjeunna. Urang milih S6. Pengawas nyayogikeun manajemén wadahna: ngamungkinkeun anjeun nyambung ka éta upami prosés utama nabrak sareng nyayogikeun manajemén manual wadahna tanpa nyiptakeun deui. Log sareng métrik mangrupikeun prosés anu dijalankeun di jero wadahna. Éta ogé kudu dikawasa kumaha bae, sarta kami ngalakukeun ieu kalayan bantuan pengawas a. Tungtungna, S6 ngurus housekeeping, processing sinyal jeung tugas séjén.

Kusabab kami nganggo sistem orkestrasi anu béda-béda, saatos ngawangun sareng ngajalankeun, wadahna kedah ngartos naon lingkunganana sareng ngalaksanakeun dumasar kana kaayaan. Salaku conto:
Hal ieu ngamungkinkeun urang pikeun ngawangun hiji gambar tur ngajalankeun eta dina sistem orkestrasi béda, sarta eta bakal dibuka nyokot kana akun spésifik tina sistem orkestrasi ieu.

 

Pikeun wadah anu sami kami kéngingkeun tangkal prosés anu béda dina Docker sareng Kubernetes:

Payload dieksekusi dina pangawasan S6. Nengetan kolektor sareng acara - ieu agén kami anu tanggung jawab pikeun log sareng métrik. Kubernetes teu gaduh aranjeunna, tapi Docker gaduh. Naha? 

Lamun urang tingali dina spésifikasi tina "pod" (hereinafter - Kubernetes pod), urang bakal nempo yén wadahna acara dieksekusi dina pod a, nu boga wadah collector misah nu ngalakukeun fungsi ngumpulkeun metrics jeung log. Urang tiasa nganggo kamampuan Kubernetes: ngajalankeun wadah dina hiji pod, dina prosés tunggal sareng/atanapi rohangan jaringan. Sabenerna ngenalkeun agén anjeun sareng ngalaksanakeun sababaraha fungsi. Sareng upami wadah anu sami diluncurkeun di Docker, éta bakal nampi sadaya kamampuan anu sami sareng kaluaran, nyaéta, éta bakal tiasa nganteurkeun log sareng métrik, sabab agén bakal diluncurkeun sacara internal. 

Métrik jeung log

Ngirimkeun métrik sareng log mangrupikeun tugas anu rumit. Aya sababaraha aspék kaputusan dirina.
Infrastruktur didamel pikeun palaksanaan muatan, sareng sanés pikeun pangiriman massal log. Hartina, prosés ieu kudu dilaksanakeun kalawan syarat sumberdaya wadahna minimal. Kami narékahan pikeun ngabantosan pamekar kami: "Kéngingkeun wadah Docker Hub, jalankeun, sareng kami tiasa nganteurkeun log." 

Aspék kadua nyaéta ngawatesan volume log. Upami lonjakan volume log lumangsung dina sababaraha wadah (aplikasi ngahasilkeun jejak tumpukan dina loop), beban dina CPU, saluran komunikasi, sareng sistem pamrosésan log naek, sareng ieu mangaruhan operasi host salaku a sakabeh na wadah sejenna dina host, lajeng kadang ieu ngakibatkeun "ragrag" host teh. 

Aspék katilu nyaéta yén anjeun kedah ngadukung saloba metode pangumpulan métrik anu mungkin kaluar tina kotak. Tina maca file sareng polling Prometheus-endpoint pikeun ngagunakeun protokol khusus aplikasi.

Jeung aspék panungtungan nyaéta pikeun ngaleutikan konsumsi sumberdaya.

Kami milih solusi Go open source anu disebut Telegraf. Ieu mangrupikeun konektor universal anu ngadukung langkung ti 140 jinis saluran input (plugin input) sareng 30 jinis saluran kaluaran (plugin output). Kami parantos ngabéréskeun éta sareng ayeuna kami bakal nyarioskeun ka anjeun kumaha kami nganggo éta nganggo Kubernetes salaku conto. 

Sebutkeun pamekar nyebarkeun beban kerja sareng Kubernetes nampi pamundut pikeun ngadamel pod. Dina titik ieu, wadah disebut Kolektor otomatis dijieun pikeun tiap pod (urang make mutasi webhook). Kolektor mangrupikeun agén kami. Dina awalna, wadahna ieu ngonpigurasikeun diri pikeun damel sareng Prometheus sareng sistem koleksi log.

• Jang ngalampahkeun ieu, ngagunakeun annotations pod, sarta gumantung kana eusina, nyiptakeun, sebutkeun, titik tungtung Prometheus; 
• Dumasar kana spésifikasi pod sareng setélan wadahna khusus, éta mutuskeun kumaha ngirim log.

Kami ngumpulkeun log via Docker API: pamekar ngan kedah nempatkeun aranjeunna dina stdout atanapi stderr, sareng Kolektor bakal nyortir. Log dikumpulkeun dina sakumpulan jeung sababaraha reureuh pikeun nyegah kamungkinan overload host. 

Métrik dikumpulkeun dina sadaya instansi beban kerja (prosés) dina wadah. Sagalana ditandaan: spasi ngaran, handapeun, jeung saterusna, lajeng dirobah jadi format Prometheus - sarta sadia pikeun ngumpulkeun (iwal log). Kami ogé ngirim log, métrik sareng acara ka Kafka sareng salajengna:

• Log sadia dina Graylog (pikeun analisis visual);
• Log, métrik, acara dikirim ka Clickhouse pikeun neundeun jangka panjang.

Sagalana jalan persis sarua dina AWS, ngan urang ngaganti Graylog kalawan Kafka kalawan Cloudwatch. Urang ngirim log ka dinya, sarta sagalana tétéla pohara merenah: éta geuwat jelas nu klaster jeung wadahna aranjeunna milik. Sami bener keur Google Stackdriver. Nyaéta, skéma kami tiasa dianggo dina premis sareng Kafka sareng dina méga. 

Lamun urang teu boga Kubernetes kalawan pods, skéma téh saeutik leuwih pajeulit, tapi jalan dina prinsip anu sarua.

Prosés anu sami dilaksanakeun di jero wadahna, aranjeunna diatur nganggo S6. Sadaya prosés anu sami dijalankeun dina wadah anu sami.

Dina ahir

Kami parantos nyiptakeun solusi lengkep pikeun ngawangun sareng ngaluncurkeun gambar, kalayan pilihan pikeun ngumpulkeun sareng nganteurkeun log sareng métrik:

• Kami ngembangkeun pendekatan standar pikeun ngarakit gambar, sareng dumasar kana éta kami ngembangkeun template CI;
• Agén pangumpulan data mangrupikeun ekstensi Telegraf kami. Urang diuji aranjeunna ogé dina produksi;
• Urang make mutasi webhook pikeun nerapkeun peti jeung agén dina pods; 
• Terintegrasi kana ekosistem Kubernetes/Rancher;
• Urang tiasa ngaéksekusi wadah anu sami dina sistem orkestrasi anu béda sareng kéngingkeun hasil anu kami ngarepkeun;
• Dijieun konfigurasi manajemén wadahna lengkep dinamis. 

Pangarang babarengan: Ilya Prudnikov

sumber: www.habr.com