Halo sadayana! Nami abdi Pavel Agaletsky. Abdi damel salaku pimpinan tim dina tim anu ngembangkeun sistem pangiriman Lamoda. Taun 2018, kuring nyarios dina konperénsi HighLoad ++, sareng ayeuna kuring badé nampilkeun transkrip laporan kuring.

Topik kuring dikhususkeun pikeun pangalaman perusahaan urang dina nyebarkeun sistem sareng jasa ka lingkungan anu béda. Mimitian ti jaman prasejarah urang, nalika urang deployed sakabéh sistem kana server maya biasa, ditungtungan make transisi bertahap ti Nomad kana deployment di Kubernetes. Kuring bakal nyarioskeun ka anjeun naha urang ngalakukeun éta sareng naon masalah anu urang ngalaman dina prosés éta.

Deploying aplikasi pikeun VM

Hayu urang mimitian ku kanyataan yén 3 sababaraha taun ka pengker sadaya sistem sareng jasa perusahaan dipasang kana server virtual biasa. Téhnisna, éta dikelompokeun ku cara anu sadayana kode pikeun sistem kami disimpen sareng dirakit nganggo alat assembly otomatis, nganggo jenkins. Nganggo Ansible, éta digulung tina sistem kontrol versi kami ka server virtual. Leuwih ti éta, unggal sistem nu parusahaan urang tadi ieu deployed ka sahenteuna 2 server: salah sahijina dina sirah, kadua dina buntut. Dua sistem ieu leres-leres idéntik dina sadaya setélan, kakuatan, konfigurasi, jsb. Hijina bédana antara aranjeunna éta sirah narima lalulintas pamaké, bari buntut pernah narima lalulintas pamaké.

Naha ieu dilakukeun?

Nalika kami nyebarkeun sékrési énggal tina aplikasi kami, kami hoyong mastikeun peluncuran anu lancar, nyaéta, tanpa akibat anu nyata pikeun pangguna. Ieu kahontal kusabab kanyataan yén sékrési kompilasi salajengna nganggo Ansible digulung ka buntut. Aya, jalma anu aub dina deployment nu bisa pariksa jeung mastikeun yén sagalana éta rupa: kabéh metrics, bagian sarta aplikasi anu jalan; naskah perlu dibuka. Ngan sanggeus maranéhanana yakin yén sagalana éta ok, lalulintas ieu switched. Ieu dimimitian bade server anu saméméhna buntut. Sareng anu saacanna janten sirah tetep tanpa lalu lintas pangguna, bari tetep gaduh versi sateuacana tina aplikasi kami.

Janten éta mulus pikeun pangguna. Kusabab switching téh sakedapan, saprak éta ngan saukur ngaganti balancer nu. Anjeun tiasa pisan gampang gulung deui ka versi saméméhna ku ngan saukur ngaganti balancer deui. Urang ogé tiasa pariksa yén aplikasi éta sanggup ngahasilkeun bahkan sateuacan nampi lalu lintas pangguna, anu lumayan merenah.

Naon kaunggulan anu urang tingali dina sagala ieu?

1. Kahiji, éta cukup eta ngan dianggo. Sarerea ngartos kumaha skéma panyebaran sapertos kitu, sabab seueur jalma anu kantos nyebarkeun ka server virtual biasa.
2. Ieu cukup dipercaya, saprak téhnologi deployment basajan, diuji ku rébuan pausahaan. Jutaan server disebarkeun ku cara ieu. Hésé megatkeun hiji hal.
3. Sarta pamustunganana urang bisa meunang deployments atom. Deployments anu lumangsung sakaligus pikeun pamaké, tanpa tahap noticeable of pindah antara versi heubeul jeung nu anyar.

Tapi urang ogé nempo sababaraha shortcomings dina sakabéh ieu:

1. Salian lingkungan produksi, lingkungan pangwangunan, aya lingkungan anu sanés. Contona, qa jeung praproduksi. Waktu éta kami ngagaduhan seueur server sareng sakitar 60 jasa. Ku sabab kitu ieu diperlukeun pikeun tiap jasa, ngajaga versi panganyarna pikeun eta mesin virtual. Sumawona, upami anjeun hoyong ngapdet perpustakaan atanapi masang katergantungan énggal, anjeun kedah ngalakukeun ieu dina sadaya lingkungan. Anjeun ogé kedah nyinkronkeun waktos nalika anjeun badé nyebarkeun versi anyar aplikasi anjeun sareng waktos nalika devops ngalaksanakeun setélan lingkungan anu diperyogikeun. Dina hal ieu, gampang pikeun asup kana kaayaan dimana lingkungan urang bakal rada béda dina sadaya lingkungan sakaligus. Salaku conto, dina lingkungan QA bakal aya sababaraha versi perpustakaan, sareng dina lingkungan produksi bakal aya anu béda, anu bakal nyababkeun masalah.
2. Kasesahan ngamutahirkeun kagumantungan aplikasi Anjeun. Teu gumantung ka anjeun, tapi dina tim séjén. Nyaéta, ti tim devops anu ngajaga server. Anjeun kedah masihan aranjeunna tugas anu pas sareng pedaran ngeunaan naon anu anjeun hoyong laksanakeun.
3. Waktu éta, urang ogé hayang ngabagi monoliths badag badag urang tadi kana jasa leutik misah, saprak urang ngartos yen bakal aya beuki loba. Dina waktos éta, urang parantos ngagaduhan langkung ti 100. Pikeun unggal jasa énggal kedah nyiptakeun mesin virtual énggal anu misah, anu ogé kedah dijaga sareng disebarkeun. Sajaba ti éta, anjeun teu kudu hiji mobil, tapi sahenteuna dua. Ditambahkeun kana sadaya ieu lingkungan QA. Ieu nyababkeun masalah sareng ngajantenkeun anjeun langkung hese pikeun ngawangun sareng ngajalankeun sistem énggal. prosés rumit, mahal jeung panjang.

Kituna, urang mutuskeun yén éta bakal leuwih merenah pikeun mindahkeun tina deploying mesin virtual biasa mun deploying aplikasi urang dina wadah docker. Upami Anjeun gaduh docker, anjeun peryogi sistem nu bisa ngajalankeun aplikasi dina klaster a, saprak anjeun teu bisa ngan ngangkat wadahna. Biasana anjeun hoyong ngalacak sabaraha wadah anu diangkat supados otomatis angkat. Kusabab ieu, urang kedah milih sistem kontrol.

Urang mikir pikeun lila ngeunaan mana nu bisa nyandak. Nyatana yén dina waktos éta tumpukan panyebaran ieu dina server maya biasa rada katinggaleun jaman, sabab henteu ngagaduhan versi sistem operasi panganyarna. Di sawatara titik, malah aya FreeBSD, nu teu pisan merenah pikeun ngarojong. Kami ngartos yén urang kedah migrasi ka docker gancang-gancang. Devops kami ningali pangalaman anu aya sareng solusi anu béda sareng milih sistem sapertos Nomad.

Pindah ka Nomad

Nomad mangrupikeun produk HashiCorp. Éta ogé dipikanyaho pikeun solusi anu sanés:

"Konsul" mangrupa alat pikeun manggihan jasa.

"Terraform" - sistem pikeun ngatur server anu ngamungkinkeun anjeun pikeun ngonpigurasikeunana ngaliwatan konfigurasi, anu disebut infrastruktur-as-a-code.

"Geulis" ngidinan Anjeun pikeun nyebarkeun mesin virtual lokal atawa dina awan ngaliwatan file konfigurasi husus.

Nomad dina waktos éta sigana sapertos solusi anu saderhana anu tiasa gancang-gancang dialihkeun tanpa ngarobih sadayana infrastruktur. Sajaba ti éta, éta rada gampang pikeun neuleuman. Éta sababna kami milih éta salaku sistem filtrasi pikeun wadahna.

Naon anu anjeun peryogikeun pikeun nyebarkeun sistem anjeun ka Nomad?

1. Munggaran sadaya nu peryogi gambar docker aplikasi Anjeun. Anjeun kedah ngawangun sareng nempatkeun éta dina gudang gambar docker. Dina hal urang, ieu mangrupa artifactory - sistem nu ngidinan Anjeun pikeun nyorong rupa artefak tina tipena béda. Éta tiasa nyimpen arsip, gambar docker, bungkusan PHP komposer, bungkusan NPM, sareng sajabana.
2. Ogé diperlukeun file konfigurasi, nu bakal ngabejaan Nomad naon, dimana jeung dina kuantitas naon rék nyebarkeun.

Lamun urang ngobrol ngeunaan Nomad, éta ngagunakeun basa HCL salaku format file informasi na, nu nangtung pikeun Basa Konfigurasi HashiCorp. Ieu mangrupikeun superset Yaml anu ngamungkinkeun anjeun ngajelaskeun jasa anjeun dina istilah Nomad.

Eta ngidinan Anjeun pikeun nyebutkeun sabaraha peti rék nyebarkeun, ti mana gambar ngalirkeun rupa parameter ka aranjeunna salila deployment. Ku kituna, anjeun eupan file ieu ka Nomad, sarta eta ngajalankeun wadahna kana produksi nurutkeun eta.

Dina kasus urang, urang sadar yén ngan saukur nulis file HCL idéntik pikeun tiap jasa moal jadi pohara merenah, sabab aya loba layanan sarta kadangkala rék ngapdet aranjeunna. Éta kajadian yén hiji layanan disebarkeun henteu dina hiji conto, tapi dina sababaraha rupa anu béda. Salaku conto, salah sahiji sistem anu urang gaduh dina produksi gaduh langkung ti 100 instansi dina produksi. Aranjeunna ngajalankeun tina gambar anu sami, tapi béda dina setélan konfigurasi sareng file konfigurasi.

Ku alatan éta, urang mutuskeun yén éta bakal merenah pikeun urang nyimpen sakabéh file konfigurasi urang pikeun deployment dina hiji gudang umum. Ku cara ieu aranjeunna katingali: aranjeunna gampang dijaga sareng urang tiasa ningali sistem naon anu urang gaduh. Upami diperlukeun, éta ogé gampang pikeun ngapdet atawa ngarobah hiji hal. Nambahkeun sistem anyar ogé henteu sesah - anjeun ngan ukur kedah nyiptakeun file konfigurasi dina diréktori énggal. Di jerona aya file-file di handap ieu: service.hcl, anu ngandung pedaran ngeunaan jasa kami, sareng sababaraha file env anu ngamungkinkeun jasa ieu, didamel dina produksi, dikonpigurasi.

Nanging, sababaraha sistem kami disebarkeun dina produksi sanés dina hiji salinan, tapi dina sababaraha sakaligus. Kituna, urang mutuskeun yén éta bakal merenah pikeun urang nyimpen teu configs dina formulir murni maranéhanana, tapi formulir templated maranéhna. Sarta kami milih jinja 2. Dina format ieu, urang nyimpen duanana configs sahiji layanan sorangan jeung file env diperlukeun pikeun eta.

Sajaba ti éta, kami geus nempatkeun dina Repository a Aksara deployment umum pikeun sakabéh proyék, nu ngidinan Anjeun pikeun ngajalankeun sarta nyebarkeun jasa anjeun kana produksi, kana lingkungan nu dipikahoyong, kana udagan nu dipikahoyong. Dina kasus nalika urang ngancik config HCL urang kana citakan, lajeng file HCL, nu saméméhna éta config Nomad biasa, dina hal ieu mimiti kasampak saeutik béda.

Hartina, urang ngaganti sababaraha variabel lokasi config ku variabel diselapkeun nu dicokot tina file env atawa sumber séjén. Salaku tambahan, urang ngagaduhan kasempetan pikeun ngumpulkeun file HCL sacara dinamis, nyaéta, urang tiasa nganggo henteu ngan ukur sisipan variabel biasa. Kusabab jinja ngadukung loop sareng kaayaan, anjeun ogé tiasa nyiptakeun file konfigurasi di dinya, anu robih gumantung kana dimana persis anjeun nyebarkeun aplikasi anjeun.

Salaku conto, anjeun hoyong nyebarkeun jasa anjeun ka pra-produksi sareng produksi. Hayu urang nyarios yén dina pra-produksi anjeun henteu hoyong ngajalankeun skrip cron, tapi ngan ukur hoyong ningali jasa dina domain anu misah pikeun mastikeun éta jalan. Pikeun saha waé anu nyebarkeun jasa éta, prosésna katingali saderhana sareng transparan. Sadaya anu anjeun kedah laksanakeun nyaéta ngaéksekusi file deploy.sh, sebutkeun jasa mana anu anjeun hoyong pasang sareng target mana. Salaku conto, anjeun hoyong nyebarkeun sistem anu tangtu ka Rusia, Bélarus atanapi Kazakhstan. Jang ngalampahkeun ieu, ngan saukur ngarobah salah sahiji parameter, tur Anjeun bakal boga file konfigurasi bener.

Nalika jasa Nomad parantos disebarkeun ka kluster anjeun, sigana sapertos kieu.

Mimiti, anjeun peryogi sababaraha jinis pangimbang di luar, anu bakal nampi sadaya lalu lintas pangguna. Bakal gawé bareng jeung Konsul jeung manggihan ti mana, dina titik naon, dina naon alamat IP hiji layanan husus lokasina nu pakait jeung ngaran domain nu tangtu. Jasa di Konsul asalna ti Nomad sorangan. Kusabab ieu mangrupikeun produk ti perusahaan anu sami, aranjeunna rada aya hubunganana. Urang tiasa nyarios yén Nomad out of the box tiasa ngadaptarkeun sadaya jasa anu diluncurkeun di jero Konsul.

Sakali pangimbang beban hareup-tungtung anjeun terang jasa mana anu ngirimkeun lalu lintas, éta teraskeun kana wadah anu cocog atanapi sababaraha wadah anu cocog sareng aplikasi anjeun. Alami, éta ogé perlu mikir ngeunaan kaamanan. Sanaos sadaya jasa dijalankeun dina mesin virtual anu sami dina wadah, ieu biasana ngabutuhkeun nyegah aksés gratis tina jasa naon waé ka anu sanés. Urang ngahontal ieu ngaliwatan segmentation. Masing-masing jasa diluncurkeun dina jaringan virtual sorangan, dimana aturan routing sareng aturan pikeun ngawenangkeun / nolak aksés kana sistem sareng jasa anu sanés ditunjuk. Éta tiasa ayana di jero klaster ieu sareng di luar éta. Contona, upami anjeun hoyong nyegah layanan tina nyambungkeun ka database husus, ieu bisa dipigawé ngaliwatan segmentation tingkat jaringan. Hartina, sanajan ku kasalahan, anjeun teu bisa ngahaja nyambungkeun ti lingkungan test ka database produksi Anjeun.

Sabaraha biaya transisi urang dina hal SDM?

Transisi sakabéh perusahaan ka Nomad nyandak kirang langkung 5-6 bulan. Urang pindah dina dasar jasa-demi-jasa, tapi dina Pace cukup gancang. Masing-masing tim kedah nyiptakeun wadahna sorangan pikeun jasa éta.

Kami parantos ngadopsi pendekatan sapertos unggal tim nanggung jawab pikeun gambar docker tina sistemna sacara mandiri. DevOps nyadiakeun infrastruktur umum dipikabutuh pikeun deployment, nyaeta, rojongan pikeun klaster sorangan, rojongan pikeun sistem CI, jeung saterusna. Sareng dina waktos éta, langkung ti 60 sistem dipindahkeun ka Nomad, anu jumlahna sakitar 2 rébu wadah.

Devops tanggung jawab pikeun infrastruktur umum sadaya anu aya hubunganana sareng panyebaran sareng server. Sareng masing-masing tim pamekaran, kahareupna tanggung jawab pikeun ngalaksanakeun wadah pikeun sistem khususna, sabab éta tim anu terang naon anu diperyogikeun dina wadah khusus.

Alesan pikeun abandoning Nomad

Naon kaunggulan anu urang kéngingkeun ku ngalih kana panyebaran nganggo Nomad sareng docker, antara anu sanésna?

1. urang disadiakeun kaayaan sarua pikeun sakabéh lingkungan. Dina pamekaran, lingkungan QA, pra-produksi, produksi, gambar wadah anu sami dianggo, sareng kagumantungan anu sami. Sasuai, anjeun ampir teu aya kasempetan yén naon anu bakal aya dina produksi sanés naon anu anjeun uji sacara lokal atanapi di lingkungan tés anjeun.
2. Urang ogé manggihan yén éta téh cukup gampang pikeun nambahkeun layanan anyar. Ti sudut pandang deployment, sagala sistem anyar diluncurkeun pisan basajan. Ngan buka Repository nu nyimpen configs, tambahkeun config sejen pikeun sistem anjeun aya, tur anjeun geus siap. Anjeun tiasa nyebarkeun sistem anjeun ka produksi tanpa usaha tambahan ti devops.
3. sadaya file konfigurasi dina hiji gudang umum tétéla dina review. Dina waktos urang nyebarkeun sistem kami nganggo server virtual, kami nganggo Ansible, dimana konfigurasina aya dina gudang anu sami. Nanging, pikeun sabagéan ageung pamekar, ieu rada sesah dianggo. Di dieu volume configs sareng kode anu anjeun kedah tambahkeun pikeun nyebarkeun jasa parantos langkung alit. Tambih Deui, éta gampang pisan pikeun devops ngalereskeun atanapi ngarobih. Dina hal transisi, contona, kana versi anyar Nomad, aranjeunna tiasa nyandak sareng ngamutahirkeun massal sadaya file operasi anu aya di tempat anu sami.

Tapi kami ogé mendakan sababaraha kalemahan:

Tétéla urang teu bisa ngahontal deployments seamless dina kasus Nomad. Nalika ngagulung wadahna dina kaayaan anu béda, éta tiasa dijalankeun, sareng Nomad nganggap éta salaku wadah anu siap nampi lalu lintas. Ieu kajantenan sateuacan aplikasi di jerona ngagaduhan kasempetan pikeun diluncurkeun. Ku sabab kitu, sistem mimiti ngahasilkeun 500 kasalahan dina jangka waktu anu singget, sabab lalulintas mimiti buka wadahna nu teu acan siap pikeun nampa eta.

Urang encountered sababaraha bug. Bug anu paling penting nyaéta Nomad henteu nanganan klaster ageung upami anjeun gaduh seueur sistem sareng wadah. Nalika anjeun badé nyandak salah sahiji server anu kalebet dina kluster Nomad pikeun pangropéa, aya kamungkinan anu cukup luhur yén kluster moal karasa saé sareng bakal ngancurkeun. Sababaraha wadah tiasa, contona, turun sareng henteu naék - ieu bakal ngarugikeun anjeun engké upami sadaya sistem produksi anjeun aya dina klaster anu dikelola ku Nomad.

Ku kituna urang mutuskeun pikeun mikir ngeunaan dimana urang kudu indit salajengna. Dina titik éta, urang jadi leuwih sadar naon urang hayang ngahontal. Nyaéta: urang hoyong reliabilitas, langkung seueur fungsi ti Nomad nyayogikeun, sareng sistem anu langkung dewasa, langkung stabil.

Dina hal ieu, pilihan urang murag kana Kubernetes salaku platform anu paling populér pikeun ngaluncurkeun klaster. Utamana nunjukkeun yén ukuran sareng jumlah wadah kami cukup ageung. Pikeun tujuan sapertos kitu, Kubernetes sigana mangrupikeun sistem anu paling cocog anu urang tingali.

Transisi kana Kubernetes

Kuring gé ngabejaan Anjeun saeutik ngeunaan konsép dasar Kubernetes na kumaha aranjeunna béda ti Nomad.

Anu mimiti, konsép anu paling dasar dina Kubernetes nyaéta konsép pod. pod nyaéta kumpulan hiji atawa leuwih wadah anu salawasna ngajalankeun babarengan. Jeung maranéhna salawasna dianggo saolah-olah mastikeun dina hiji mesin virtual. Aranjeunna diaksés ka silih via IP 127.0.0.1 on palabuhan béda.

Hayu urang nganggap yén anjeun gaduh aplikasi PHP anu diwangun ku nginx sareng php-fpm - skéma klasik. Paling dipikaresep, anjeun bakal hoyong tetep duanana nginx na php-fpm wadahna babarengan sepanjang waktos. Kubernetes ngidinan Anjeun pikeun ngahontal ieu ku ngajéntrékeun aranjeunna salaku hiji pod umum. Ieu persis naon urang teu bisa meunang kalawan Nomad.

Konsep kadua nyaéta deployment. Kanyataan yén pod sorangan mangrupikeun hal anu ephemeral; dimimitian sareng ngaleungit. Naha anjeun badé maéhan sadaya wadah sateuacana heula, teras ngaluncurkeun vérsi énggal sakaligus, atanapi anjeun badé ngagulungna laun-laun? Ieu mangrupikeun prosés anu tanggung jawab konsép panyebaran. Ieu ngajelaskeun kumaha anjeun nyebarkeun pods anjeun, dina sabaraha kuantitas sareng kumaha ngapdetna.

Konsep katilu nyaeta palayanan. Ladenan anjeun saleresna mangrupikeun sistem anjeun, anu nampi sababaraha lalu lintas teras diteruskeun ka hiji atanapi langkung pods anu cocog sareng jasa anjeun. Nyaéta, éta ngamungkinkeun anjeun nyarios yén sadaya lalu lintas asup kana jasa sapertos kitu sareng nami sapertos kitu kedah dikirim ka pods khusus ieu. Sareng dina waktos anu sami nyayogikeun anjeun balancing lalu lintas. Nyaéta, anjeun tiasa ngaluncurkeun dua pod aplikasi anjeun, sareng sadaya lalu lintas anu asup bakal saimbang rata antara pods anu aya hubunganana sareng jasa ieu.

Jeung konsép dasar kaopat nyaéta Ingress. Ieu mangrupikeun jasa anu dijalankeun dina klaster Kubernetes. Éta tindakan minangka pangimbang beban éksternal anu nyandak alih sadaya pamundut. Ngagunakeun Kubernetes API, Ingress bisa nangtukeun mana requests ieu kudu dikirim. Leuwih ti éta, anjeunna ngalakukeun ieu pisan flexibly. Anjeun tiasa nyarios yén sadaya pamundut ka host ieu sareng URL sapertos kitu dikirim ka jasa ieu. Jeung requests ieu datang ka host ieu sareng ka URL sejen dikirim ka layanan sejen.

Hal anu paling keren tina sudut pandang jalma anu ngembangkeun aplikasi nyaéta anjeun tiasa ngatur éta sadayana nyalira. Ku netepkeun config Ingress, Anjeun bisa ngirim sakabeh lalulintas datang ka API misalna hiji pikeun misahkeun peti ditulis, contona, dina Go. Tapi lalulintas ieu, datang ka domain sarua, tapi ka URL béda, kudu dikirim ka peti ditulis dina PHP, dimana aya loba logika, tapi maranéhna teu pisan gancang.

Upami urang ngabandingkeun sadayana konsép ieu sareng Nomad, urang tiasa nyebatkeun yén tilu konsép anu munggaran sadayana babarengan Service. Sareng konsép anu terakhir henteu aya dina Nomad sorangan. Kami nganggo pangimbang éksternal sapertos: éta tiasa haproxy, nginx, nginx +, sareng saterasna. Dina kasus kubus, anjeun teu kedah ngenalkeun konsep tambahan ieu nyalira. Sanajan kitu, lamun nempo Ingress internal, éta boh nginx, haproxy, atawa traefik, tapi nurun diwangun kana Kubernetes.

Sadaya konsép anu kuring dijelaskeun nyaéta, kanyataanna, sumber daya anu aya dina klaster Kubernetes. Pikeun ngajelaskeun aranjeunna dina kubus, format yaml dianggo, anu langkung gampang dibaca sareng akrab tibatan file HCL dina kasus Nomad. Tapi Sacara stuktur aranjeunna ngajelaskeun hal anu sarua dina kasus, contona, pod. Aranjeunna nyarios - Abdi hoyong nyebarkeun polong sapertos kitu di dinya, kalayan gambar sapertos kitu, dina jumlah sapertos kitu.

Sajaba ti éta, urang sadar yen urang teu hayang nyieun unggal sumberdaya individu ku leungeun: deployment, jasa, Ingress, jsb. Sabalikna, kami hoyong ngajelaskeun unggal sistem kami dina hal Kubernetes salami panyebaran, ku kituna kami henteu kedah nyiptakeun deui sacara manual sadaya katergantungan sumberdaya anu diperyogikeun dina urutan anu leres. Helm dipilih salaku sistem anu ngamungkinkeun urang ngalakukeun ieu.

Konsep dasar dina Helm

Helm téh manajer pakét pikeun Kubernetes. Sarupa pisan sareng kumaha manajer pakét dina basa pamrograman jalan. Aranjeunna ngidinan Anjeun pikeun nyimpen layanan nu diwangun ku, contona, deployment nginx, deployment php-fpm, config pikeun Ingress, configmaps (ieu mangrupa éntitas nu ngidinan Anjeun pikeun nyetel env sarta parameter séjén pikeun sistem Anjeun) dina bentuk jadi- disebut grafik. Dina waktu nu sarua Helm dijalankeun dina luhureun Kubernetes. Nyaéta, ieu sanés sababaraha sistem anu nangtung, tapi ngan ukur jasa anu sanés diluncurkeun di jero kubus. Anjeun berinteraksi sareng eta via API na via paréntah konsol. Kaseueuran sareng kaéndahanna nyaéta sanaos helm rusak atanapi anjeun ngahapus tina kluster, jasa anjeun moal ngaleungit, sabab helm dasarna ngan ukur dianggo pikeun ngamimitian sistem. Kubernetes sorangan teras tanggung jawab kana kinerja sareng kaayaan jasa.

Urang ogé sadar éta templateization, nu urang saméméhna kapaksa ngalakukeun sorangan ku ngawanohkeun jinja kana configs urang, mangrupa salah sahiji fitur utama Helm. Sadaya configs nu Anjeun jieun pikeun sistem Anjeun disimpen dina Helm dina bentuk template, saeutik sarupa jinja, tapi, dina kanyataanana, ngagunakeun templating tina basa Go, nu Helm ditulis, kawas Kubernetes.

Helm nambihan sababaraha deui konsép pikeun urang.

grapik - ieu pedaran jasa anjeun. Dina manajer pakét séjén éta bakal disebut pakét, kebat atanapi anu sami. Di dieu éta disebut bagan.

nilai nyaeta variabel nu Anjeun hoyong pake pikeun ngawangun configs anjeun ti template.

ngabebaskeun. Unggal waktos jasa anu disebarkeun nganggo Helm nampi pérsi tambahan tina sékrési éta. Helm émut naon konfigurasi jasa dina sékrési saméméhna, sékrési sateuacan éta, sareng saterasna. Ku alatan éta, lamun kudu rollback, ngan ngajalankeun paréntah callback Helm, ngarah ka versi release saméméhna. Sanaos konfigurasi anu saluyu dina gudang anjeun henteu sayogi dina waktos rollback, Helm bakal tetep émut naon éta sareng bakal ngabalikan deui sistem anjeun ka kaayaan anu aya dina sékrési saméméhna.

Dina kasus nalika urang make Helm, configs biasa pikeun Kubernetes ogé robah jadi template nu kasebut nyaéta dimungkinkeun pikeun ngagunakeun variabel, fungsi, jeung nerapkeun pernyataan kondisional. Ku cara ieu anjeun tiasa ngumpulkeun konfigurasi jasa anjeun gumantung kana lingkunganana.

Dina prakna, urang mutuskeun pikeun ngalakukeun hal saeutik béda ti urang ngalakukeun kalawan Nomad. Lamun di Nomad duanana configs deployment sarta n-variabel anu diperlukeun pikeun nyebarkeun jasa kami disimpen dina hiji gudang, didieu urang mutuskeun pikeun ngabagi kana dua repositories misah. Repositori "nyebarkeun" ngan ukur n-variabel anu dipikabutuh pikeun panyebaran, sareng gudang "helm" nyimpen konfigurasi atanapi grafik.

Naon ieu masihan kami?

Sanaos kanyataan yén kami henteu nyimpen data anu sénsitip dina file konfigurasi sorangan. Contona, kecap akses kana database. Éta disimpen salaku rusiah dina Kubernetes, tapi masih aya hal-hal anu tangtu anu urang henteu hoyong masihan aksés ka sadayana. Ku alatan éta, aksés ka gudang "nyebarkeun" leuwih kawates, sarta gudang "helm" saukur ngandung pedaran jasa. Ku sabab kitu, éta tiasa diaksés sacara aman ku sajumlah jalma anu langkung lega.

Kusabab urang henteu ngan ukur produksi, tapi ogé lingkungan anu sanés, hatur nuhun kana pamisahan ieu kami tiasa nganggo deui bagan Helm pikeun nyebarkeun jasa henteu ngan ukur pikeun produksi, tapi ogé, contona, ka lingkungan QA. Malah pikeun nyebarkeun aranjeunna sacara lokal ngagunakeun Minikube - ieu hal pikeun ngajalankeun Kubernetes lokal.

Di jero unggal gudang, urang ninggalkeun division kana directories misah pikeun tiap jasa. Nyaéta, di jero unggal diréktori aya témplat anu aya hubunganana sareng bagan anu saluyu sareng ngajelaskeun sumber daya anu kedah disebarkeun pikeun ngajalankeun sistem kami. Urang ngan ukur tinggalkeun envs dina gudang "nyebarkeun". Dina hal ieu, kami henteu nganggo templating nganggo jinja, sabab Helm sorangan nyayogikeun template out of the box - ieu mangrupikeun salah sahiji fungsi utami.

Kami tinggalkeun naskah panyebaran - deploy.sh, anu nyederhanakeun sareng ngabakukeun peluncuran pikeun penyebaran nganggo Helm. Janten, pikeun saha waé anu hoyong nyebarkeun, antarbeungeut panyebaran katingalina sami sareng nalika nyebarkeun ngaliwatan Nomad. deploy.sh sami, nami jasa anjeun, sareng dimana anjeun badé nyebarkeunana. Hal ieu nyababkeun Helm ngamimitian sacara internal. Éta, kahareupna ngumpulkeun konfigurasi tina témplat, nyelapkeun file nilai anu diperyogikeun kana éta, teras nyebarkeunana, ngaluncurkeun kana Kubernetes.

papanggihan

Ladenan Kubernetes sigana langkung kompleks tibatan Nomad.

Di dieu lalulintas kaluar datang ka Ingress. Ieu ngan controller hareup, nu nyokot alih sagala requests sarta salajengna ngirimkeunana ka layanan pakait jeung data pamundut. Eta nangtukeun aranjeunna dumasar kana configs anu mangrupa bagian tina pedaran aplikasi anjeun dina Helm na nu pamekar diatur sorangan. Ladenan ngirimkeun pamenta ka polongna, nyaéta, wadah khusus, nyaimbangkeun lalu lintas anu asup antara sadaya wadah anu kalebet kana jasa ieu. Sareng, tangtosna, urang henteu kedah hilap yén urang henteu kedah angkat ka mana waé tina kaamanan dina tingkat jaringan. Ku alatan éta, segmentasi jalan dina klaster Kubernetes, nu dumasar kana méré tag. Sadaya jasa gaduh tag anu tangtu dimana hak aksés jasa kana sumber éksternal / internal anu tangtu di jero atanapi di luar klaster pakait.

Nalika urang ngadamel transisi, urang ningali yén Kubernetes ngagaduhan sadaya kamampuan Nomad, anu kami kantos dianggo, sareng ogé nambihan seueur hal énggal. Ieu bisa dimekarkeun ngaliwatan plugins, sarta dina kanyataanana ngaliwatan tipe sumberdaya custom. Hartina, anjeun boga kasempetan teu ngan ngagunakeun hal anu hadir kalawan Kubernetes out of the box, tapi pikeun nyieun sumberdaya sorangan sarta jasa anu bakal maca sumberdaya Anjeun. Ieu masihan anjeun pilihan tambahan pikeun ngalegaan sistem anjeun tanpa kedah masang deui Kubernetes sareng henteu peryogi modifikasi.

Conto pamakean sapertos kitu nyaéta Prometheus, anu aya di jero klaster Kubernetes kami. Pikeun ngamimitian ngumpulkeun métrik tina jasa khusus, urang kedah nambihan jinis sumber tambahan, anu disebut monitor jasa, kana katerangan jasa. Prometheus, kusabab kanyataan yén éta tiasa maca jinis sumberdaya khusus nalika diluncurkeun dina Kubernetes, otomatis mimiti ngumpulkeun métrik tina sistem énggal. Ieu rada merenah.

Panyebaran munggaran anu kami lakukeun ka Kubernetes nyaéta dina Maret 2018. Sareng salami ieu kami henteu kantos ngalaman masalah sareng éta. Gawéna cukup stabil tanpa bug signifikan. Salaku tambahan, urang tiasa ngalegaan deui. Dinten ieu kami boga cukup kamampuhan eta, sarta kami resep pisan laju ngembangkeun Kubernetes. Ayeuna, langkung ti 3000 wadahna aya di Kubernetes. Kluster nempatan sababaraha Node. Dina waktos anu sami, éta tiasa dilayanan, stabil sareng tiasa dikontrol.

sumber: www.habr.com