Jenengku Dmitry Sugrobov, aku dadi pangembang ing Leroy Merlin. Ing artikel iki aku bakal pitutur marang kowe apa Helm dibutuhake, carane nyederhanakake karya karo Kubernetes, apa wis diganti ing versi katelu, lan carane nggunakake aplikasi kanggo nganyari aplikasi ing produksi tanpa downtime.
Iki minangka ringkesan adhedhasar pidato ing konferensi by - yen sampeyan ora pengin maca, nonton video.
Apa kita nggunakake Kubernetes ing produksi
Leroy Merlin minangka pimpinan ing pasar ritel DIY ing Rusia lan Eropa. Perusahaan kita duwe luwih saka satus pangembang, 33 karyawan internal lan akeh wong sing ngunjungi hypermarket lan situs web. Kanggo nggawe kabeh seneng, kita mutusake kanggo ngetutake pendekatan standar industri. Ngembangake aplikasi anyar nggunakake arsitektur microservice; nggunakake wadhah kanggo ngisolasi lingkungan lan njamin pangiriman sing tepat; lan nggunakake Kubernetes kanggo orkestrasi. Rega kanggo nggunakake orkestra kanthi cepet dadi luwih murah: jumlah insinyur sing pinter babagan teknologi saya tambah akeh ing pasar, lan panyedhiya katon nawakake Kubernetes minangka layanan.
Kabeh sing ditindakake Kubernetes, mesthi, bisa ditindakake kanthi cara liya, contone, kanthi nutupi sawetara Jenkins lan docker-compose nganggo skrip, nanging kenapa urip rumit yen ana solusi sing wis siap lan dipercaya? Pramila kita teka ing Kubernetes lan wis digunakake ing produksi sajrone setaun saiki. Saiki kita duwe 24 klompok Kubernetes, sing paling tuwa umure luwih saka setahun, kanthi udakara rong atus polong.
Kutukan file YAML gedhe ing Kubernetes
Kanggo miwiti layanan mikro ing Kubernetes, kita bakal nggawe paling ora limang file YAML: kanggo Deployment, Service, Ingress, ConfigMap, Secrets - lan ngirim menyang kluster. Kanggo aplikasi sabanjure kita bakal nulis paket jambs sing padha, karo sing katelu kita bakal nulis liyane, lan sateruse. Yen kita tikelake jumlah dokumen kanthi jumlah lingkungan, kita bakal entuk atusan file, lan iki durung njupuk menyang akun lingkungan dinamis.
Adam Reese, pemelihara inti Helm, ngenalake konsep "", sing katon kaya iki:
- Nyalin YAML - nyalin file YAML.
- Tempel YAML - tempel.
- Ndandani Indents - Ndandani Indents.
- Baleni - baleni maneh.
Opsi kasebut bisa digunakake, nanging sampeyan kudu nyalin file YAML kaping pirang-pirang. Kanggo ngganti siklus iki, Helm diciptakake.
Apa iku Helm
Kaping pisanan, Helm- manajer paket, sing mbantu sampeyan nemokake lan nginstal program sing dibutuhake. Kanggo nginstal, contone, MongoDB, sampeyan ora perlu menyang situs web resmi lan ngundhuh binari, mung mbukak printah helm install stable/mongodb.
Kapindho, Helm- mesin Cithakan, mbantu kanggo parameterize file. Ayo bali menyang kahanan karo file YAML ing Kubernetes. Iku luwih gampang kanggo nulis file YAML padha, nambah sawetara placeholders menyang, menyang Helm bakal ngganti nilai. Yaiku, tinimbang scaffolds sing gedhe, bakal ana set template sing bakal diganti nilai sing dibutuhake ing wektu sing tepat.
Katelu, Helm- master penyebaran. Kanthi sampeyan bisa nginstal, muter maneh lan nganyari aplikasi. Ayo dadi ngerti carane nindakake iki.
Cara nggunakake Helm kanggo nyebarake aplikasi sampeyan dhewe
Ayo instal klien Helm ing komputer, tindakake resmi . Sabanjure, kita bakal nggawe set file YAML. Tinimbang nemtokake nilai tartamtu, kita bakal ninggalake placeholders, kang Helm bakal isi informasi ing mangsa. Sakumpulan file kasebut diarani bagan Helm. Bisa dikirim menyang klien konsol Helm kanthi telung cara:
- nuduhake folder karo cithakan;
- ngemas arsip menyang .tar lan arahake;
- sijine cithakan ing repositori remot lan nambah link menyang gudang ing klien Helm.
Sampeyan uga mbutuhake file kanthi nilai - values.yaml. Data saka ing kono bakal dilebokake ing cithakan. Ayo nggawe uga.
Versi kapindho Helm duwe aplikasi server tambahan - Tiller. Iki macet ing njaba Kubernetes lan ngenteni panjalukan saka klien Helm, lan nalika diarani, ngganti nilai sing dibutuhake menyang cithakan lan dikirim menyang Kubernetes.
Helm 3 luwih prasaja: tinimbang ngolah cithakan ing server, informasi saiki diproses kabeh ing sisih klien Helm lan dikirim langsung menyang API Kubernetes. Nyederhanakake iki nambah keamanan kluster lan nggampangake skema rollout.
Carane iku kabeh bisa
Mbukak printah helm install. Ayo nuduhake jeneng release aplikasi lan menehi path kanggo values.yaml. Ing pungkasan kita bakal nuduhake gudang ing ngendi grafik kasebut lan jeneng grafik kasebut. Ing conto, iki "lmru" lan "bestchart", mungguh.
helm install --name bestapp --values values.yaml lmru/bestchart
Printah kasebut bisa dieksekusi mung sapisan, nalika dieksekusi maneh install kudu nggunakake upgrade. Kanggo gamblang, tinimbang loro printah, sampeyan bisa mbukak printah upgrade karo tombol tambahan --install. Nalika dieksekusi pisanan, Helm bakal ngirim prentah kanggo nginstal release, lan bakal nganyari ing mangsa.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Pitfalls deploying versi anyar saka aplikasi karo Helm
Ing titik iki ing crita, Aku muter Who Wants to Be a Millionaire karo pirsawan, lan kita ngerti carane njaluk Helm kanggo nganyari versi app. .
Nalika aku sinau cara kerja Helm, aku kaget karo prilaku aneh nalika nyoba nganyari versi aplikasi sing mlaku. Aku nganyari kode aplikasi, upload gambar anyar kanggo pendaptaran Docker, dikirim printah penyebaran prajurit - lan boten kedaden. Ing ngisor iki sawetara cara sing ora sukses kanggo nganyari aplikasi. Kanthi sinau saben wong kanthi luwih rinci, sampeyan bakal mulai ngerti struktur internal instrumen lan alasan kanggo prilaku sing ora jelas iki.
Cara 1. Aja ngganti informasi wiwit diluncurake pungkasan
Minangka ngandika Helm, "Data Kubernetes bisa dadi gedhe lan rumit, mula Helm nyoba ora ndemek apa wae." Mulane, yen sampeyan nganyari versi paling anyar saka gambar aplikasi ing pendaptaran docker lan mbukak printah helm upgrade, banjur ora bakal kelakon. Helm bakal mikir yen ora ana sing diganti lan ora perlu ngirim perintah menyang Kubernetes kanggo nganyari aplikasi kasebut.
Ing kene lan ing ngisor iki, tag paling anyar ditampilake mung minangka conto. Nalika sampeyan nemtokake tag iki, Kubernetes bakal ngundhuh gambar saka pendaptaran docker saben wektu, preduli saka parameter imagePullPolicy. Nggunakake paling anyar ing produksi undesirable lan nimbulakΓ© efek sisih.
Cara 2. Nganyari LABEL ing gambar
Kaya sing ditulis ing padha , "Helm mung bakal nganyari aplikasi yen wis diganti wiwit rilis pungkasan." Opsi logis kanggo iki bakal katon nganyari LABEL ing gambar docker dhewe. Nanging, Helm ora ndeleng gambar aplikasi lan ora ngerti babagan owah-owahan. Patut, nalika nganyari label ing gambar, Helm ora bakal ngerti, lan printah nganyari aplikasi ora bakal dikirim menyang Kubernetes.
Cara 3: Gunakake tombol --force
Ayo pindhah menyang manual lan goleki kunci sing dibutuhake. Tombol ndadekake pangertèn paling --force. Senadyan jeneng cetha, prilaku beda saka samesthine. Tinimbang meksa nganyari aplikasi, tujuane sejatine yaiku mulihake rilis sing ana ing status GAGAL. Yen sampeyan ora nggunakake tombol iki, sampeyan kudu nglakokaké printah sequentially helm delete && helm install --replace. Disaranake nggunakake tombol tinimbang --force, sing ngotomatisasi eksekusi urutan perintah kasebut. Informasi liyane babagan iki . Kanggo ngandhani Helm supaya nganyari versi aplikasi, sayangé, tombol iki ora bisa digunakake.
Cara 4. Ganti label langsung ing Kubernetes
Nganyari label langsung ing kluster nggunakake printah kubectl edit - idea ala. Tumindak iki bakal nyebabake informasi sing ora konsisten ing antarane aplikasi sing mlaku lan sing asline dikirim kanggo penyebaran. Prilaku Helm sajrone panyebaran ing kasus iki beda karo versi: Helm 2 ora bakal nindakake apa-apa, lan Helm 3 bakal masang versi anyar saka aplikasi kasebut. Kanggo ngerti sebabe, sampeyan kudu ngerti cara kerja Helm.
Kepiye cara kerja Helm?
Kanggo nemtokake manawa aplikasi wis diganti wiwit rilis pungkasan, Helm bisa nggunakake:
- aplikasi mlaku ing Kubernetes;
- nilai anyar.yaml lan grafik saiki;
- Informasi release internal Helm.
Kanggo luwih penasaran: ngendi Helm nyimpen informasi internal babagan rilis?Kanthi nindakake prentah helm history, kita bakal entuk kabeh informasi babagan versi sing diinstal nggunakake Helm.
Ana uga informasi rinci babagan cithakan lan nilai sing dikirim. Kita bisa njaluk:
Ing versi kapindho Helm, informasi iki dumunung ing spasi jeneng sing padha ing ngendi Tiller mlaku (kube-sistem minangka standar), ing ConfigMap, ditandhani karo label "OWNER=TILLER":
Nalika versi katelu saka Helm muncul, informasi kasebut pindhah menyang rahasia, lan menyang papan jeneng sing padha ing ngendi aplikasi kasebut mlaku. Thanks kanggo iki, dadi bisa kanggo mbukak sawetara aplikasi bebarengan ing namespaces beda karo jeneng release padha. Ing versi kaloro, sirah serius nalika spasi jeneng diisolasi nanging bisa saling pengaruh.
Helm kapindho, nalika nyoba mangerteni apa perlu nganyari, mung nggunakake rong sumber informasi: apa sing diwenehake saiki, lan informasi internal babagan rilis, sing ana ing ConfigMap.
Helm katelu nggunakake strategi gabungan telung arah: saliyane kanggo informasi kasebut, uga njupuk akun aplikasi sing saiki mlaku ing Kubernetes.
Mulane, versi lawas saka Helm ora bakal nindakake apa-apa, awit iku ora njupuk menyang akun informasi aplikasi ing kluster, nanging Helm 3 bakal nampa owah-owahan lan ngirim aplikasi anyar kanggo penyebaran prajurit.
Cara 5. Gunakake saklar --recreate-pods
Kanthi kunci --recreate-pods sampeyan bisa entuk apa sing asline direncanakake kanthi kunci --force. Wadhah kasebut bakal diwiwiti maneh lan, miturut imagePullPolicy: Tansah kabijakan kanggo tag paling anyar (luwih lengkap babagan iki ing cathetan ing ndhuwur), Kubernetes bakal ndownload lan mbukak versi anyar gambar kasebut. Iki ora bakal ditindakake kanthi cara sing paling apik: tanpa nggatekake StrategyType saka penyebaran, bakal mateni kabeh instan aplikasi lawas lan miwiti ngluncurake sing anyar. Sajrone restart, sistem ora bisa digunakake, pangguna bakal nandhang sangsara.
Ing Kubernetes dhewe, masalah sing padha uga wis suwe. Lan saiki, 4 taun sawise bukaan , masalah wis didandani, lan wiwit karo versi 1.15 saka Kubernetes, kemampuan kanggo muter maneh pods katon.
Helm mung mateni kabeh aplikasi lan mbukak wadhah anyar ing cedhak. Sampeyan ora bisa nindakake iki ing produksi, supaya ora nyebabake downtime aplikasi. Iki mung dibutuhake kanggo kabutuhan pangembangan lan mung bisa ditindakake ing lingkungan panggung.
Carane nganyari versi aplikasi nggunakake Helm?
Kita bakal ngganti nilai sing dikirim menyang Helm. Biasane, iki minangka nilai sing diganti karo tag gambar. Ing kasus paling anyar, sing asring digunakake kanggo lingkungan sing ora produktif, informasi sing bisa diganti minangka anotasi, sing ora ana gunane kanggo Kubernetes dhewe, lan kanggo Helm bakal dadi sinyal yen perlu nganyari aplikasi kasebut. Pilihan kanggo ngisi nilai anotasi:
- Nilai acak nggunakake fungsi standar -
{{ randAlphaNum 6 }}.
Ana caveat: sawise saben panyebaran nggunakake grafik kanthi variabel kasebut, nilai anotasi bakal unik, lan Helm bakal nganggep yen ana owah-owahan. Pranyata kita bakal tansah miwiti maneh aplikasi, sanajan kita durung ngganti versi. Iki ora kritis, amarga ora bakal ana downtime, nanging isih ora nyenengake. - Tempel saiki tanggal lan wektu -
{{ .Release.Date }}.
Varian padha karo nilai acak kanthi variabel unik permanen. - Cara sing luwih bener yaiku nggunakake checksums. Iki minangka SHA gambar utawa SHA saka komit pungkasan ing git -
{{ .Values.sha }}.
Padha kudu diitung lan dikirim menyang klien Helm ing sisih telpon, contone ing Jenkins. Yen aplikasi wis diganti, checksum bakal diganti. Mulane, Helm mung bakal nganyari aplikasi yen perlu.
Ayo ngringkes upaya kita
- Helm nggawe owah-owahan kanthi cara sing paling ora invasif, saengga owah-owahan ing level gambar aplikasi ing Docker Registry ora bakal ngasilake nganyari: ora ana sing bakal kedadeyan sawise printah kasebut dieksekusi.
- Kunci
--forcedigunakake kanggo mulihake rilis masalah lan ora digandhengake karo nganyari dipeksa. - Kunci
--recreate-podsbakal nganyari aplikasi kanthi paksa, nanging bakal ditindakake kanthi cara vandal: bakal mateni kabeh kontaner kanthi cepet. Pangguna bakal nandhang sangsara saka iki; sampeyan ora kudu nindakake iki ing produksi. - Langsung gawe owah-owahan menyang kluster Kubernetes nggunakake printah
kubectl editaja: kita bakal break konsistensi, lan prilaku bakal beda-beda gumantung ing versi Helm. - Kanthi rilis versi Helm anyar, akeh nuansa sing katon. Masalah ing gudang Helm diterangake nganggo basa sing jelas, bakal mbantu sampeyan ngerti rincian kasebut.
- Nambahake anotasi sing bisa diowahi menyang grafik bakal nggawe luwih fleksibel. Iki bakal ngidini sampeyan muter aplikasi kanthi bener, tanpa downtime.
Pikiran "perdamaian donya" sing bisa digunakake ing kabeh bidang urip: maca pandhuan sadurunge digunakake, ora sawise. Mung kanthi informasi lengkap bakal bisa mbangun sistem sing dipercaya lan nggawe pangguna seneng.
Pranala liyane sing gegandhengan:
Laporan iki pisanan ditampilake ing dening Mail.ru Cloud Solutions. Delengen pagelaran liyane lan langganan pengumuman acara ing Telegram .
Source: www.habr.com