Crita iki babagan carane nggunakake wadhah ing lingkungan produksi, khususe Kubernetes. Artikel kasebut dikhususake kanggo ngumpulake metrik lan log saka wadhah, uga nggawe gambar.

Kita saka perusahaan fintech Exness, sing ngembangake layanan kanggo dagang online lan produk fintech kanggo B2B lan B2C. R&D kita duwe macem-macem tim, departemen pangembangan duwe 100+ karyawan.

Kita makili tim sing tanggung jawab kanggo platform kanggo pangembang kanggo ngumpulake lan mbukak kode. Utamane, kita tanggung jawab kanggo ngumpulake, nyimpen lan nglaporake metrik, log, lan acara saka aplikasi. Saiki kita ngoperasikake kira-kira telung ewu kontainer Docker ing lingkungan produksi, njaga panyimpenan data gedhe 50 TB, lan nyedhiyakake solusi arsitektur sing dibangun ing sekitar infrastruktur kita: Kubernetes, Rancher, lan macem-macem panyedhiya awan umum. 

Motivasi kita

Apa sing kobong? Ora ana sing bisa mangsuli. Endi perapian? Iku angel dimangerteni. Nalika iku murub? Sampeyan bisa ngerteni, nanging ora langsung. 

Yagene sawetara wadhah ngadeg nalika liyane tiba? Wadhah endi sing kudu disalahake? Sawise kabeh, ing njaba wadhah padha, nanging ing njero saben duwe Neo dhewe.

Pangembang kita wong lanang sing kompeten. Dheweke nggawe layanan apik sing nggawa bathi kanggo perusahaan. Nanging ana kegagalan nalika kontaner kanthi aplikasi kesasar. Siji wadhah nganggo CPU akeh banget, liyane nganggo jaringan, katelu nganggo operasi I / O, lan kaping papat ora jelas apa sing ditindakake karo soket. Iku kabeh tiba lan kapal klelep. 

Agen

Kanggo ngerti apa sing kedadeyan ing njero, kita mutusake kanggo nyelehake agen langsung ing wadhah.

Agen-agen kasebut ngalang-alangi program sing njaga kontaner ing kahanan kaya ngono supaya ora pecah. Agen wis standar, lan iki ngidini kanggo pendekatan standar kanggo layanan kontaner. 

Ing kasus kita, agen kudu nyedhiyani log ing format standar, diwenehi tag lan throttled. Dheweke uga kudu menehi kita metrik standar sing bisa diperluas saka perspektif aplikasi bisnis.

Agen uga tegese utilitas kanggo operasi lan pangopènan sing bisa digunakake ing sistem orkestrasi sing beda-beda sing ndhukung gambar sing beda (Debian, Alpine, Centos, lsp.).

Pungkasan, agen kudu ndhukung CI / CD prasaja sing kalebu file Docker. Yen ora, kapal bakal ambruk, amarga kontainer bakal diwiwiti ing rel "bengkong".

Proses mbangun lan piranti gambar target

Kanggo njaga kabeh standar lan bisa diatur, sawetara proses mbangun standar kudu ditindakake. Mulane, kita mutusake kanggo ngumpulake wadhah kanthi wadhah - iki minangka rekursi.

Ing kene wadhah kasebut diwakili kanthi garis-garis padhet. Ing wektu sing padha, dheweke mutusake kanggo nyelehake kit distribusi supaya "urip ora katon kaya raspberry." Apa iki rampung, kita bakal nerangake ing ngisor iki.
 
Asil kasebut minangka alat mbangun-wadhah khusus versi sing ngrujuk versi distribusi tartamtu lan versi skrip tartamtu.

Kepiye carane nggunakake? Kita duwe Docker Hub sing ngemot wadhah. Kita kaca ing njero sistem kita kanggo nyingkirake dependensi eksternal. Asilé wadhah sing ditandhani warna kuning. Kita nggawe cithakan kanggo nginstal kabeh distribusi lan skrip sing dibutuhake ing wadhah kasebut. Sawise iku, kita ngumpulake gambar sing siap digunakake: pangembang sijine kode lan sawetara dependensi khusus dhewe menyang. 

Apa sing apik babagan pendekatan iki? 

• Pisanan, kontrol versi lengkap alat mbangun - mbangun versi wadhah, skrip lan distribusi. 
• Kapindho, kita wis entuk standarisasi: kita nggawe cithakan, gambar penengah lan siap digunakake kanthi cara sing padha. 
• Katelu, kontaner menehi portabilitas. Dina iki kita nggunakake Gitlab, lan sesuk kita bakal pindhah menyang TeamCity utawa Jenkins lan kita bakal bisa mbukak kontaner kanthi cara sing padha. 
• Papat, minimalake dependensi. Ora ana kebetulan yen kita sijine kit distribusi ing wadhah, amarga iki ngidini kita supaya ora ndownload saka Internet saben wektu. 
• Kalima, kacepetan mbangun saya tambah - anané salinan gambar lokal ngidini sampeyan ora mbuwang wektu kanggo ndownload, amarga ana gambar lokal. 

Ing tembung liyane, kita wis entuk proses perakitan sing dikontrol lan fleksibel. Kita nggunakake alat sing padha kanggo mbangun kontaner kanthi versi lengkap. 

Carane kita mbangun prosedur

Déwan diluncurake kanthi siji prentah, proses kasebut dieksekusi ing gambar (disorot nganggo warna abang). Pangembang duwe file Docker (disorot kuning), kita render, ngganti variabel kanthi nilai. Lan ing dalan kita nambah header lan footer - iki agen kita. 

Header nambahake distribusi saka gambar sing cocog. Lan footer nginstal layanan kita ing njero, ngatur peluncuran beban kerja, logging lan agen liyane, ngganti titik mlebu, lsp. 

Kita mikir kanggo dangu apa kanggo nginstal supervisor. Ing pungkasan, kita mutusake yen kita butuh dheweke. Kita milih S6. Pengawas nyedhiyakake manajemen wadhah: ngidini sampeyan nyambungake yen proses utama kacilakan lan menehi manajemen wadhah manual tanpa nggawe maneh. Log lan metrik minangka proses sing mlaku ing wadhah. Padha uga kudu kontrol piye wae, lan kita nindakake iki karo bantuan saka supervisor. Pungkasan, S6 ngurus omah, pangolahan sinyal lan tugas liyane.

Amarga kita nggunakake sistem orkestrasi sing beda-beda, sawise mbangun lan mlaku, wadhah kasebut kudu ngerti apa lingkungan kasebut lan tumindak miturut kahanan kasebut. Tuladhane:
Iki ngidini kita mbangun siji gambar lan mbukak ing sistem orkestrasi sing beda-beda, lan bakal diluncurake kanthi nganggep spesifik sistem orkestrasi iki.

 

Kanggo wadhah sing padha, kita entuk wit proses sing beda ing Docker lan Kubernetes:

Muatan kasebut ditindakake ing sangisore pengawasan S6. Priksa manawa kolektor lan acara - iki minangka agen sing tanggung jawab kanggo log lan metrik. Kubernetes ora duwe, nanging Docker duwe. Kenging punapa? 

Yen kita katon ing specification saka "pod" (sabanjuré - Kubernetes pod), kita bakal weruh sing kontaner acara wis kaleksanan ing pod, kang wis wadhah Penagih kapisah sing nindakake fungsi ngempalaken metrik lan log. Kita bisa nggunakake kemampuan Kubernetes: mbukak wadhah ing siji pod, ing siji proses lan/utawa papan jaringan. Bener ngenalake agen sampeyan lan nindakake sawetara fungsi. Lan yen wadhah sing padha diluncurake ing Docker, bakal nampa kabeh kemampuan sing padha karo output, yaiku, bakal bisa ngirim log lan metrik, amarga agen kasebut bakal diluncurake sacara internal. 

Metrik lan log

Ngirim metrik lan log minangka tugas sing rumit. Ana sawetara aspek kanggo keputusane.
Infrastruktur digawe kanggo eksekusi muatan, lan dudu kanggo pangiriman massal. Tegese, proses iki kudu ditindakake kanthi syarat sumber daya wadhah minimal. Kita usaha kanggo mbantu pangembang: "Entuk wadhah Docker Hub, jalanake, lan kita bisa ngirim log." 

Aspek kapindho yaiku mbatesi volume log. Yen mundhak ing volume log ana ing sawetara kontaner (aplikasi ngasilake tumpukan-tilak ing daur ulang), beban ing CPU, saluran komunikasi, lan sistem pangolahan log mundhak, lan iki mengaruhi operasi saka host minangka a kabèh lan wadhah liyane ing inang, banjur kadhangkala iki ndadékaké kanggo "tiba" saka inang. 

Aspek katelu iku perlu kanggo ndhukung minangka akeh metrik cara koleksi sabisa metu saka kothak. Saka maca file lan polling Prometheus-endpoint kanggo nggunakake protokol tartamtu aplikasi.

Lan aspek pungkasan yaiku nyuda konsumsi sumber daya.

Kita milih solusi Go open-source sing diarani Telegraf. Iki minangka konektor universal sing ndhukung luwih saka 140 jinis saluran input (plugin input) lan 30 jinis saluran output (plugin output). Kita wis ngrampungake lan saiki bakal menehi pitutur marang kowe carane nggunakake Kubernetes minangka conto. 

Contone, pangembang nyebarake beban kerja lan Kubernetes nampa panjaluk kanggo nggawe pod. Ing wektu iki, wadhah sing diarani Collector digawe kanthi otomatis kanggo saben pod (kita nggunakake webhook mutasi). Kolektor minangka agen kita. Ing wiwitan, wadhah iki ngatur dhewe kanggo nggarap Prometheus lan sistem koleksi log.

• Kanggo nindakake iki, nggunakake anotasi pod, lan gumantung ing isi, nggawe, ngomong, titik pungkasan Prometheus; 
• Adhedhasar spesifikasi pod lan setelan wadhah tartamtu, mutusake carane ngirim log.

Kita ngumpulake log liwat Docker API: pangembang mung kudu sijine ing stdout utawa stderr, lan Collector bakal ngurutake. Log diklumpukake ing potongan kanthi sawetara wektu tundha kanggo nyegah kakehan host. 

Metrik diklumpukake ing kasus (proses) beban kerja ing wadhah. Kabeh diwenehi tag: namespace, under, lan liya-liyane, banjur diowahi dadi format Prometheus - lan kasedhiya kanggo koleksi (kajaba log). Kita uga ngirim log, metrik lan acara menyang Kafka lan luwih:

• Log kasedhiya ing Graylog (kanggo analisis visual);
• Log, metrik, acara dikirim menyang Clickhouse kanggo panyimpenan jangka panjang.

Kabèh dianggo persis padha ing AWS, mung kita ngganti Graylog karo Kafka karo Cloudwatch. Kita ngirim log ana, lan kabeh dadi trep banget: langsung jelas klompok lan wadhah sing ana. Padha bener kanggo Google Stackdriver. Yaiku, skema kita bisa digunakake ing premis karo Kafka lan ing awan. 

Yen kita ora duwe Kubernetes karo polong, skema kasebut rada rumit, nanging bisa digunakake kanthi prinsip sing padha.

Proses sing padha ditindakake ing njero wadhah, diatur kanthi nggunakake S6. Kabeh proses sing padha mlaku ing wadhah sing padha.

Ing pungkasan

Kita wis nggawe solusi lengkap kanggo mbangun lan ngluncurake gambar, kanthi pilihan kanggo ngumpulake lan ngirim log lan metrik:

• We dikembangaké pendekatan standar kanggo assembling gambar, lan adhedhasar iku kita dikembangaké cithakan CI;
• Agen pangumpulan data minangka ekstensi Telegraf kita. Kita nguji kanthi apik ing produksi;
• Kita nggunakake webhook mutasi kanggo ngleksanakake kontaner karo agen ing pods; 
• Integrasi menyang ekosistem Kubernetes/Rancher;
• Kita bisa nindakake wadhah sing padha ing sistem orkestrasi sing beda-beda lan entuk asil sing dikarepake;
• Nggawe konfigurasi manajemen wadhah sing dinamis. 

Co-penulis: Ilya Prudnikov

Source: www.habr.com