Halo kabeh! Jenengku Pavel Agaletsky. Aku kerja minangka pimpinan tim ing tim sing ngembangake sistem pangiriman Lamoda. Ing 2018, aku ngomong ing konferensi HighLoad ++, lan dina iki aku arep menehi transkrip laporanku.

Topikku darmabakti kanggo pengalaman perusahaan kita ing deploying sistem lan layanan kanggo macem-macem lingkungan. Miwiti saka jaman prasejarah, nalika kita nyebarake kabeh sistem menyang server virtual biasa, dipungkasi kanthi transisi bertahap saka Nomad menyang penyebaran ing Kubernetes. Aku bakal ngandhani apa sebabe kita nindakake lan masalah apa sing ana ing proses kasebut.

Nyebarake aplikasi menyang VM

Ayo diwiwiti kanthi kasunyatan manawa 3 taun kepungkur kabeh sistem lan layanan perusahaan disebarake menyang server virtual biasa. Secara teknis, iki diatur kanthi cara supaya kabeh kode kanggo sistem kita disimpen lan dirakit nggunakake alat perakitan otomatis, nggunakake jenkins. Nggunakake Ansible, iki diluncurake saka sistem kontrol versi menyang server virtual. Kajaba iku, saben sistem sing diduweni perusahaan kita disebarake ing paling ora 2 server: siji ing sirah, sing kapindho ing buntut. Sistem loro iki pancen padha karo saben liyane ing kabeh setelan, daya, konfigurasi, lsp. Bentenipun mung ing antarane yaiku sirah sing nampa lalu lintas pangguna, dene buntut ora tau nampa lalu lintas pangguna.

Apa iku kanggo?

Nalika kita nyebarke rilis anyar saka aplikasi kita, kita wanted kanggo mesthekake rollout rapi, sing, tanpa jalaran ngelingke kanggo pangguna. Iki digayuh amarga kasunyatan manawa rilis kompilasi sabanjure nggunakake Ansible diluncurake menyang buntut. Ing kana, wong-wong sing melu penyebaran bisa mriksa lan mesthekake yen kabeh apik: kabeh metrik, bagean lan aplikasi bisa digunakake; skrip sing dibutuhake diluncurake. Mung sawise padha nggawe percoyo sing kabeh iku ok, lalu lintas diuripake. Iku wiwit pindhah menyang server sing sadurunge buntut. Lan sing sadurunge dadi kepala tetep tanpa lalu lintas pangguna, nalika isih duwe versi aplikasi sadurunge.

Dadi lancar kanggo pangguna. Amarga ngoper iku cepet, awit iku mung ngoper balancer. Sampeyan bisa gampang banget muter bali menyang versi sadurungé dening mung ngoper bali balancer. Kita uga bisa verifikasi manawa aplikasi kasebut bisa ngasilake sanajan sadurunge nampa lalu lintas pangguna, sing cukup trep.

Apa kaluwihan sing kita deleng ing kabeh iki?

1. Kaping pisanan, cukup iku mung bisa. Saben uwong ngerti carane skema panyebaran kasebut bisa digunakake, amarga umume wong wis dikirim menyang server virtual biasa.
2. Iki wis cukup andal, wiwit teknologi panyebaran iku prasaja, dites dening ewu perusahaan. Mayuta-yuta server disebarake kanthi cara iki. Iku angel kanggo break soko.
3. Lan pungkasane kita bisa entuk panyebaran atom. Panyebaran sing dumadi bebarengan kanggo pangguna, tanpa tataran ngelingke ngoper antarane versi lawas lan anyar.

Nanging kita uga weruh sawetara kekurangan ing kabeh iki:

1. Saliyane lingkungan produksi, lingkungan pangembangan, ana lingkungan liyane. Contone, qa lan praproduksi. Ing wektu iku, kita duwe akeh server lan udakara 60 layanan. Mulane iku perlu kanggo saben layanan, njaga versi paling anyar kanggo mesin virtual. Kajaba iku, yen sampeyan pengin nganyari perpustakaan utawa nginstal dependensi anyar, sampeyan kudu nindakake iki ing kabeh lingkungan. Sampeyan uga kudu nyinkronake wektu nalika sampeyan arep masang versi anyar aplikasi sampeyan karo wektu nalika devops nindakake setelan lingkungan sing dibutuhake. Ing kasus iki, iku gampang kanggo njaluk menyang kahanan sing lingkungan kita bakal rada beda ing kabeh lingkungan bebarengan. Contone, ing lingkungan QA bakal ana sawetara versi perpustakaan, lan ing lingkungan produksi bakal ana sing beda-beda, sing bakal nyebabake masalah.
2. Kesulitan nganyari dependensi aplikasi sampeyan. Iku ora gumantung ing sampeyan, nanging ing tim liyane. Yaiku, saka tim devops sing njaga server. Sampeyan kudu menehi tugas sing cocog lan katrangan babagan apa sing arep ditindakake.
3. Ing wektu iku, kita uga pengin dibagi monoliths gedhe gedhe kita wis dadi layanan cilik kapisah, awit kita mangertos sing bakal ana liyane lan liyane. Ing wektu kasebut, kita wis duwe luwih saka 100. Kanggo saben layanan anyar, perlu nggawe mesin virtual anyar sing kapisah, sing uga kudu dijaga lan disebarake. Kajaba iku, sampeyan kudu ora siji mobil, nanging paling ora loro. Ditambahake kabeh iki yaiku lingkungan QA. Iki nyebabake masalah lan nggawe luwih angel kanggo sampeyan mbangun lan mbukak sistem anyar. proses rumit, larang lan dawa.

Mula, kita mutusake manawa bakal luwih trep kanggo pindhah saka nggunakake mesin virtual biasa menyang nyebarake aplikasi ing wadhah docker. Yen sampeyan duwe docker, sampeyan kudu sistem sing bisa mbukak aplikasi ing kluster, amarga sampeyan ora bisa mung mundhakaken wadhah. Biasane sampeyan pengin nglacak jumlah kontaner sing diangkat supaya bisa diangkat kanthi otomatis. Kanggo alasan iki, kita kudu milih sistem kontrol.

We mikir kanggo dangu bab kang siji kita bisa njupuk. Kasunyatane, ing wektu kasebut tumpukan penyebaran ing server virtual reguler rada ketinggalan jaman, amarga padha ora duwe versi paling anyar saka sistem operasi. Ing sawetara titik, malah ana FreeBSD, sing ora trep banget kanggo ndhukung. Kita ngerti yen kita kudu pindhah menyang docker kanthi cepet. Devops kita ndeleng pengalaman sing ana karo solusi sing beda-beda lan milih sistem kaya Nomad.

Ngalih menyang Nomad

Nomad minangka produk saka HashiCorp. Dheweke uga dikenal kanggo solusi liyane:

"Konsul" minangka alat kanggo nemokake layanan.

"Terraform" - sistem kanggo ngatur server sing ngijini sampeyan kanggo ngatur liwat konfigurasi, supaya-disebut infrastruktur-minangka-a-kode.

"Galang" ngidini sampeyan masang mesin virtual sacara lokal utawa ing awan liwat file konfigurasi tartamtu.

Nomad ing wektu iku katon kaya solusi sing cukup prasaja sing bisa diowahi kanthi cepet tanpa ngganti kabeh infrastruktur. Kajaba iku, iku cukup gampang kanggo sinau. Pramila kita milih minangka sistem filtrasi kanggo wadhah kita.

Apa sing sampeyan butuhake kanggo nyebarake sistem menyang Nomad?

1. Pisanan sampeyan kudu gambar docker aplikasi sampeyan. Sampeyan kudu mbangun lan nyelehake ing gudang gambar docker. Ing kasus kita, iki minangka artifactory - sistem sing ngidini sampeyan nyurung macem-macem artefak saka macem-macem jinis menyang. Bisa nyimpen arsip, gambar docker, paket PHP komposer, paket NPM, lan liya-liyane.
2. Uga dibutuhake file konfigurasi, sing bakal ngandhani Nomad apa, ing ngendi lan ing jumlah apa sing pengin disebarake.

Nalika kita ngomong babagan Nomad, nggunakake basa HCL minangka format file informasi, sing tegese Basa Konfigurasi HashiCorp. Iki minangka superset saka Yaml sing ngidini sampeyan njlèntrèhaké layanan ing istilah Nomad.

Iku ngijini sampeyan kanggo ngomong carane akeh kontaner pengin disebaraké, saka kang gambar kanggo pass macem-macem paramèter kanggo wong-wong mau sak penyebaran. Mangkono, sampeyan feed file iki kanggo Nomad, lan mbukak kontaner menyang produksi miturut iku.

Ing kasus kita, kita nyadari yen mung nulis file HCL sing padha kanggo saben layanan ora bakal trep banget, amarga ana akeh layanan lan kadhangkala sampeyan pengin nganyari. Iku kedadeyan yen siji layanan disebarake ora ing siji conto, nanging ing macem-macem sing beda. Contone, salah sawijining sistem sing ana ing produksi duwe luwih saka 100 conto ing produksi. Padha mbukak saka gambar sing padha, nanging beda-beda ing setelan konfigurasi lan file konfigurasi.

Mula, kita mutusake manawa luwih trep kanggo nyimpen kabeh file konfigurasi kanggo disebarake ing siji gudang umum. Kanthi cara iki, padha katon: padha gampang kanggo njaga lan kita bisa ndeleng apa sistem kita duwe. Yen perlu, iku uga gampang kanggo nganyari utawa ngganti soko. Nambahake sistem anyar uga ora angel - sampeyan mung kudu nggawe file konfigurasi ing direktori anyar. Ing njero ana file ing ngisor iki: service.hcl, sing ngemot katrangan babagan layanan kita, lan sawetara file env sing ngidini layanan iki, disebarake ing produksi, dikonfigurasi.

Nanging, sawetara sistem kita disebarake ing produksi ora ing siji salinan, nanging ing sawetara bebarengan. Mulane, kita mutusaké sing bakal trep kanggo nyimpen ora configs ing wangun murni, nanging wangun templated. Lan kita milih jinja 2. Ing format iki, kita nyimpen loro configs layanan dhewe lan file env needed kanggo iku.

Kajaba iku, kita wis diselehake ing gudang skrip penyebaran umum kanggo kabeh proyek, sing ngijini sampeyan kanggo miwiti lan masang layanan menyang produksi, menyang lingkungan sing dikarepake, menyang target sing dikarepake. Ing kasus nalika kita nguripake config HCL menyang cithakan, banjur file HCL, kang sadurunge config Nomad biasa, ing kasus iki wiwit katon beda sethitik.

Yaiku, kita ngganti sawetara variabel lokasi config karo variabel sing dilebokake sing dijupuk saka file env utawa sumber liyane. Kajaba iku, kita entuk kesempatan kanggo ngumpulake file HCL kanthi dinamis, yaiku, kita bisa nggunakake ora mung sisipan variabel biasa. Wiwit jinja ndhukung puteran lan kahanan, sampeyan uga bisa nggawe file konfigurasi ing kana, sing diganti gumantung ing ngendi sampeyan nggunakake aplikasi sampeyan.

Contone, sampeyan pengin nyebarake layanan menyang pra-produksi lan produksi. Ayo ngomong yen ing pra-produksi sampeyan ora pengin mbukak skrip cron, nanging mung pengin ndeleng layanan ing domain sing kapisah kanggo mesthekake yen bisa digunakake. Kanggo sapa wae sing nyebarake layanan kasebut, proses kasebut katon prasaja lan transparan. Sampeyan mung kudu nglakokake file deploy.sh, nemtokake layanan sing pengin sampeyan gunakake lan target sing endi. Contone, sampeyan pengin masang sistem tartamtu menyang Rusia, Belarus utawa Kazakhstan. Kanggo nindakake iki, mung ngganti salah sawijining paramèter, lan sampeyan bakal duwe file konfigurasi sing bener.

Nalika layanan Nomad wis disebarake menyang kluster sampeyan, katon kaya iki.

Pisanan, sampeyan butuh sawetara jinis balancer ing njaba, sing bakal nampa kabeh lalu lintas pangguna. Bakal bisa kerja bareng karo Konsul lan ngerteni saka ngendi, ing simpul apa, ing alamat IP apa layanan tartamtu dumunung sing cocog karo jeneng domain tartamtu. Layanan ing Konsul teka saka Nomad dhewe. Amarga iki minangka produk saka perusahaan sing padha, mula ana hubungane karo siji liyane. Kita bisa ngomong sing Nomad metu saka kothak bisa ndhaftar kabeh layanan dibukak ing Konsul.

Sawise load balancer ngarep sampeyan ngerti layanan sing arep dikirim lalu lintas, banjur diterusake menyang wadhah sing cocog utawa macem-macem wadhah sing cocog karo aplikasi sampeyan. Alami, sampeyan uga kudu mikir babagan safety. Sanajan kabeh layanan mbukak ing mesin virtual sing padha ing wadhah, iki biasane mbutuhake nyegah akses gratis saka layanan apa wae menyang liyane. Kita entuk iki liwat segmentasi. Saben layanan diluncurake ing jaringan virtual dhewe, ing ngendi aturan rute lan aturan kanggo ngidini / nolak akses menyang sistem lan layanan liyane diwenehake. Bisa ditemokake ing njero kluster iki lan ing njaba. Contone, yen sampeyan pengin nyegah layanan kanggo nyambung menyang database tartamtu, iki bisa ditindakake liwat segmentasi tingkat jaringan. Yaiku, sanajan kanthi salah, sampeyan ora bisa ora sengaja nyambungake saka lingkungan tes menyang database produksi sampeyan.

Pira biaya transisi babagan sumber daya manungsa?

Transisi kabeh perusahaan menyang Nomad njupuk kira-kira 5-6 sasi. We dipindhah ing basis layanan-by-layanan, nanging ing jangkah nyedhaki cepet. Saben tim kudu nggawe wadhah dhewe kanggo layanan kasebut.

Kita wis ngetrapake pendekatan kasebut supaya saben tim tanggung jawab kanggo gambar docker sistem kasebut kanthi mandiri. DevOps nyedhiyakake infrastruktur umum sing perlu kanggo panyebaran, yaiku, dhukungan kanggo kluster kasebut, dhukungan kanggo sistem CI, lan liya-liyane. Lan ing wektu kasebut, luwih saka 60 sistem dipindhah menyang Nomad, sing kira-kira 2 ewu kontainer.

Devops tanggung jawab kanggo infrastruktur umum kabeh sing ana gandhengane karo penyebaran lan server. Lan saben tim pangembangan, siji, tanggung jawab kanggo ngleksanakake kontaner kanggo sistem tartamtu, amarga iku tim sing ngerti apa sing umume perlu ing wadhah tartamtu.

Alasan kanggo ninggalake Nomad

Apa kaluwihan sing kita entuk kanthi ngalih menyang penyebaran nggunakake Nomad lan docker, antara liya?

1. Kita kasedhiya kahanan sing padha kanggo kabeh lingkungan. Ing pangembangan, lingkungan QA, pra-produksi, produksi, gambar wadhah sing padha digunakake, kanthi dependensi sing padha. Patut, sampeyan meh ora duwe kesempatan manawa apa sing bakal ditindakake ing produksi dudu sing sadurunge dites sacara lokal utawa ing lingkungan tes sampeyan.
2. Kita uga nemokake yen cukup gampang kanggo nambah layanan anyar. Saka sudut pandang penyebaran, sistem anyar apa wae diluncurake kanthi gampang. Cukup menyang repositori sing nyimpen konfigurasi, nambah konfigurasi liyane kanggo sistem sampeyan ana, lan sampeyan wis siap. Sampeyan bisa masang sistem menyang produksi tanpa gaweyan tambahan saka devops.
3. Kabeh file konfigurasi ing siji gudang umum pranyata ing review. Nalika kita nyebarake sistem nggunakake server virtual, kita nggunakake Ansible, ing ngendi konfigurasi ana ing gudang sing padha. Nanging, kanggo umume pangembang iki rada angel digarap. Ing kene volume konfigurasi lan kode sing kudu ditambahake kanggo nyebarake layanan kasebut dadi luwih cilik. Kajaba iku, gampang banget kanggo devops ndandani utawa ngganti. Ing cilik saka transisi, contone, kanggo versi anyar saka Nomad, padha bisa njupuk lan akeh nganyari kabeh file operasi dumunung ing panggonan sing padha.

Nanging kita uga nemoni sawetara kekurangan:

Ternyata kita ora bisa entuk penyebaran lancar ing kasus Nomad. Nalika nggulung kontaner ing kahanan sing beda-beda, bisa uga mlaku, lan Nomad nganggep minangka wadhah sing siap nampa lalu lintas. Iki kedadeyan sadurunge aplikasi ing njero malah duwe kesempatan kanggo diluncurake. Mulane, sistem wiwit ngasilake 500 kesalahan kanggo wektu sing cendhak, amarga lalu lintas wiwit menyang wadhah sing durung siap nampa.

Kita ketemu sawetara kewan omo. Bug sing paling penting yaiku Nomad ora nangani kluster gedhe yen sampeyan duwe akeh sistem lan wadhah. Nalika sampeyan pengin njupuk metu siji saka server sing klebu ing kluster Nomad kanggo pangopènan, ana kemungkinan cukup dhuwur sing kluster ora aran apik banget lan bakal tiba loro. Sawetara kontaner bisa uga, umpamane, tiba lan ora munggah - iki bakal larang banget yen kabeh sistem produksi sampeyan ana ing kluster sing dikelola dening Nomad.

Mula, kita mutusaké kanggo mikir bab ngendi kita kudu pindhah sabanjuré. Ing wektu kasebut, kita dadi luwih ngerti apa sing dikarepake. Yaiku: kita pengin linuwih, fungsi sing luwih cilik tinimbang sing diwenehake Nomad, lan sistem sing luwih diwasa lan luwih stabil.

Ing babagan iki, pilihan kita ana ing Kubernetes minangka platform sing paling populer kanggo ngluncurake kluster. Utamane yen ukuran lan jumlah wadhah kita cukup gedhe. Kanggo tujuan kasebut, Kubernetes katon minangka sistem sing paling cocog sing bisa dideleng.

Transisi menyang Kubernetes

Aku bakal ngandhani sampeyan babagan konsep dhasar Kubernetes lan kepiye bedane karo Nomad.

Kaping pisanan, konsep paling dhasar ing Kubernetes yaiku konsep pod. pod yaiku klompok siji utawa luwih wadhah sing tansah lumaku bebarengan. Lan padha tansah bisa kaya strictly ing siji mesin virtual. Padha bisa diakses kanggo saben liyane liwat IP 127.0.0.1 ing port beda.

Ayo nganggep yen sampeyan duwe aplikasi PHP sing kasusun saka nginx lan php-fpm - skema klasik. Paling kamungkinan, sampeyan bakal pengin tetep loro nginx lan php-fpm wadhah bebarengan ing kabeh wektu. Kubernetes ngidini sampeyan entuk iki kanthi njlèntrèhaké minangka pod umum. Iki persis sing ora bisa ditampa karo Nomad.

Konsep kapindho yaiku penyebaran. Kasunyatane yaiku polong kasebut minangka barang sing ora pati penting; diwiwiti lan ilang. Apa sampeyan pengin mateni kabeh kontaner sadurunge, banjur miwiti versi anyar bebarengan, utawa sampeyan pengin muter kanthi bertahap? Iki minangka proses sing tanggung jawab konsep penyebaran. Iki nerangake carane sampeyan masang pods, ing jumlah apa lan carane nganyari.

Konsep katelu yaiku layanan. Layanan sampeyan sejatine sistem sampeyan, sing nampa sawetara lalu lintas banjur diterusake menyang siji utawa luwih pod sing cocog karo layanan sampeyan. Yaiku, ngidini sampeyan ujar manawa kabeh lalu lintas mlebu menyang layanan kasebut kanthi jeneng kasebut kudu dikirim menyang pods tartamtu iki. Lan ing wektu sing padha nyedhiyakake keseimbangan lalu lintas. Yaiku, sampeyan bisa miwiti rong pod aplikasi sampeyan, lan kabeh lalu lintas sing mlebu bakal seimbang ing antarane pod sing ana gandhengane karo layanan iki.

Lan konsep dhasar papat yaiku Ingress. Iki minangka layanan sing mlaku ing kluster Kubernetes. Tumindak minangka imbangan beban eksternal sing njupuk kabeh panjaluk. Nggunakake API Kubernetes, Ingress bisa nemtokake ngendi panjalukan kasebut kudu dikirim. Kajaba iku, dheweke nindakake iki kanthi fleksibel. Sampeyan bisa ujar manawa kabeh panjaluk menyang host iki lan URL kasebut dikirim menyang layanan iki. Lan panjaluk kasebut teka menyang host iki lan menyang URL liyane dikirim menyang layanan liyane.

Sing paling keren saka sudut pandang wong sing ngembangake aplikasi yaiku sampeyan bisa ngatur kabeh dhewe. Kanthi nyetel konfigurasi Ingress, sampeyan bisa ngirim kabeh lalu lintas menyang API kasebut kanggo misahake wadhah sing ditulis, contone, ing Go. Nanging lalu lintas iki, teka menyang domain sing padha, nanging menyang URL sing beda, kudu dikirim menyang wadhah sing ditulis ing PHP, ing ngendi ana akeh logika, nanging ora cepet banget.

Yen kita mbandhingake kabeh konsep iki karo Nomad, kita bisa ngomong sing telung konsep pisanan kabeh bebarengan Service. Lan konsep pungkasan ora ana ing Nomad dhewe. Kita nggunakake balancer eksternal minangka: bisa dadi haproxy, nginx, nginx +, lan liya-liyane. Ing kasus kubus, sampeyan ora perlu ngenalake konsep tambahan iki kanthi kapisah. Nanging, yen katon ing Ingress internal, iku salah siji nginx, haproxy, utawa traefik, nanging Urut dibangun menyang Kubernetes.

Kabeh konsep sing dakgambarake, nyatane, sumber daya sing ana ing kluster Kubernetes. Kanggo njlèntrèhaké ing kubus, format yaml digunakake, sing luwih bisa diwaca lan akrab tinimbang file HCL ing kasus Nomad. Nanging struktural padha njlèntrèhaké bab sing padha ing kasus, contone, pod. Dheweke ujar - Aku pengin nyebarake polong kasebut ing kana, kanthi gambar kasebut lan kaya ngono, kanthi jumlah kasebut.

Kajaba iku, kita nyadari yen kita ora pengin nggawe saben sumber daya kanthi tangan: penyebaran, layanan, Ingress, lsp. Nanging, kita pengin njlèntrèhaké saben sistem kita ing syarat-syarat Kubernetes sajrone panyebaran, supaya kita ora kudu nggawé ulang kabeh dependensi sumber daya sing perlu kanthi manual ing urutan sing bener. Helm dipilih minangka sistem sing ngidini kita nindakake iki.

Konsep dhasar ing Helm

Helm iku manajer paket kanggo Kubernetes. Iku meh padha karo cara manajer paket ing basa pemrograman. Dheweke ngidini sampeyan nyimpen layanan sing kalebu, contone, penyebaran nginx, penyebaran php-fpm, config kanggo Ingress, configmaps (iki minangka entitas sing ngidini sampeyan nyetel env lan paramèter liyane kanggo sistem sampeyan) ing wangun so- disebut grafik. Ing wektu sing padha Helm mlaku ing ndhuwur Kubernetes. Tegese, iki dudu sawetara sistem sing mandheg, nanging mung layanan liyane sing diluncurake ing jero kubus. Sampeyan sesambungan karo liwat API liwat printah console. Penak lan kaendahane yaiku sanajan setir rusak utawa dicopot saka kluster, layanan sampeyan ora bakal ilang, amarga setir mung bisa digunakake kanggo miwiti sistem. Kubernetes dhewe banjur tanggung jawab kanggo kinerja lan kahanan layanan.

Kita uga nyadari yen templateization, sing sadurunge dipeksa nindakake dhewe kanthi ngenalake jinja menyang konfigurasi kita, minangka salah sawijining fitur utama helm. Kabeh konfigurasi sing digawe kanggo sistem sampeyan disimpen ing setir ing wangun cithakan, sethitik padha karo jinja, nanging nyatane, nggunakake templating saka basa Go, kang helm ditulis, kaya Kubernetes.

Helm nambah sawetara konsep liyane kanggo kita.

Chart - iki minangka katrangan babagan layanan sampeyan. Ing manajer paket liyane bakal diarani paket, bundel utawa sing padha. Ing kene diarani grafik.

Nilai yaiku variabel sing pengin digunakake kanggo mbangun konfigurasi saka template.

release. Saben layanan sing disebarake nggunakake setir nampa versi tambahan saka release. Helm ngelingi apa konfigurasi layanan ing rilis sadurunge, rilis sadurunge, lan liya-liyane. Mulane, yen sampeyan kudu muter maneh, mung mbukak printah callback helm, ngarahake menyang versi release sadurungé. Sanajan konfigurasi sing cocog ing repositori sampeyan ora kasedhiya nalika muter maneh, setir bakal tetep ngelingi apa iku lan bakal mbalek maneh sistem sampeyan menyang negara sing ana ing release sadurunge.

Ing kasus nalika nggunakake helm, konfigurasi biasa kanggo Kubernetes uga dadi cithakan sing bisa nggunakake variabel, fungsi, lan ngetrapake pernyataan kondisional. Kanthi cara iki sampeyan bisa ngumpulake konfigurasi layanan gumantung saka lingkungan.

Ing laku, kita mutusaké kanggo nindakake iku sethitik beda saka kita karo Nomad. Yen ing Nomad loro konfigurasi penyebaran lan n-variabel sing dibutuhake kanggo nyebarake layanan kita disimpen ing siji repositori, ing kene kita mutusake kanggo dibagi dadi rong repositori sing kapisah. Repositori "nyebar" mung nyimpen n-variabel sing dibutuhake kanggo penyebaran, lan repositori "helm" nyimpen konfigurasi utawa grafik.

Apa iki menehi kita?

Senadyan kasunyatan manawa kita ora nyimpen data sing sensitif banget ing file konfigurasi kasebut. Contone, sandhi kanggo database. Iki disimpen minangka rahasia ing Kubernetes, nanging isih ana sawetara perkara sing ora pengin dilebokake kanggo kabeh wong. Mulane, akses menyang repositori "nyebar" luwih winates, lan repositori "helm" mung ngemot katrangan babagan layanan kasebut. Mulane, bisa diakses kanthi aman dening wong sing luwih akeh.

Amarga kita duwe ora mung produksi, nanging uga lingkungan liyane, thanks kanggo pamisahan iki kita bisa nggunakake maneh denah setir kanggo nyebarke layanan ora mung kanggo produksi, nanging uga, contone, kanggo lingkungan QA. Malah kanggo masang mau lokal nggunakake Minikube - iki bab kanggo mbukak Kubernetes lokal.

Ing saben repositori, kita ninggalake divisi menyang direktori sing kapisah kanggo saben layanan. Tegese, ing saben direktori ana cithakan sing ana gandhengane karo grafik sing cocog lan nggambarake sumber daya sing kudu disebarake kanggo mbukak sistem kita. Kita mung ninggalake envs ing repositori "nyebar". Ing kasus iki, kita ora nggunakake template nggunakake jinja, amarga helm dhewe nyedhiyakake template out of the box - iki minangka salah sawijining fungsi utama.

Kita ninggalake skrip penyebaran - deploy.sh, sing nyederhanakake lan nggawe standarisasi peluncuran kanggo penyebaran nggunakake setir. Dadi, kanggo sapa wae sing pengin nyebarake, antarmuka panyebaran katon padha karo nalika nyebarake liwat Nomad. deploy.sh padha, jeneng layanan sampeyan, lan ing ngendi sampeyan pengin masang. Iki nyebabake setir kanggo miwiti internal. Banjur, ngumpulake konfigurasi saka template, nglebokake file nilai sing dibutuhake, banjur disebarake, diluncurake menyang Kubernetes.

temonan

Layanan Kubernetes katon luwih rumit tinimbang Nomad.

Ing kene lalu lintas metu menyang Ingress. Iki mung pengontrol ngarep, sing njupuk kabeh panjalukan lan banjur dikirim menyang layanan sing cocog karo data panyuwunan. Nemtokake adhedhasar konfigurasi sing minangka bagean saka katrangan aplikasi sampeyan lan pangembang sing disetel dhewe. Layanan ngirim panjalukan menyang pods, yaiku, wadhah khusus, ngimbangi lalu lintas mlebu ing antarane kabeh wadhah sing kalebu layanan iki. Lan, mesthi, kita ora kudu lali yen kita ora kudu pindhah menyang ngendi wae saka keamanan ing tingkat jaringan. Mula, segmentasi bisa digunakake ing kluster Kubernetes, sing adhedhasar menehi tag. Kabeh layanan duwe tag tartamtu sing nduweni hak akses layanan menyang sumber eksternal / internal tartamtu ing njero utawa njaba kluster.

Nalika kita nggawe transisi, kita weruh yen Kubernetes duwe kabeh kemampuan Nomad, sing sadurunge wis digunakake, lan uga nambahake akeh perkara anyar. Bisa ditambahi liwat plugin, lan nyatane liwat jinis sumber daya khusus. Sing, sampeyan duwe kesempatan ora mung kanggo nggunakake soko sing teka karo Kubernetes metu saka kothak, nanging kanggo nggawe sumber daya dhewe lan layanan sing bakal maca sumber. Iki menehi opsi tambahan kanggo nggedhekake sistem tanpa kudu nginstal maneh Kubernetes lan tanpa mbutuhake modifikasi.

Conto panggunaan kasebut yaiku Prometheus, sing ana ing kluster Kubernetes. Supaya bisa miwiti ngumpulake metrik saka layanan tartamtu, kita kudu nambah jinis sumber daya tambahan, sing disebut monitor layanan, menyang katrangan layanan. Prometheus, amarga kasunyatane bisa maca jinis sumber daya khusus nalika diluncurake ing Kubernetes, kanthi otomatis wiwit ngumpulake metrik saka sistem anyar. Iku cukup trep.

Penyebaran pisanan sing ditindakake ing Kubernetes yaiku ing Maret 2018. Lan sajrone wektu iki, kita ora nate nemoni masalah. Kerjane cukup stabil tanpa kewan omo sing signifikan. Kajaba iku, kita bisa nggedhekake luwih. Dina iki kita duwe kabisan sing cukup, lan kita seneng banget karo kecepatan pangembangan Kubernetes. Saiki, luwih saka 3000 kontainer ana ing Kubernetes. Kluster kasebut manggoni sawetara Node. Ing wektu sing padha, bisa dilayani, stabil lan bisa dikontrol.

Source: www.habr.com