Pertemuan administrator sistem Sysadminka ditindakake ing Chelyabinsk, lan pungkasane aku menehi laporan babagan solusi kanggo aplikasi ing 1C-Bitrix ing Kubernetes.
Bitrix, Kubernetes, Ceph - campuran apik?
Aku bakal pitutur marang kowe carane kita ngumpulake solusi sing bisa digunakake saka kabeh iki.
Ayo ayo!
Pertemuan kasebut ditindakake tanggal 18 April ing Chelyabinsk. Sampeyan bisa maca babagan meetups kita ing lan katon ing .
Yen sampeyan pengin teka menyang kita karo laporan utawa minangka pamireng - welcome, nulis menyang [email dilindhungi] lan ing Telegram t.me/vadimisakanov.
Laporanku
Solusi "Bitrix ing Kubernetes, versi Southbridge 1.0"
Aku bakal ngomong babagan solusi kita ing format "kanggo dummies ing Kubernetes", kaya sing ditindakake ing rapat kasebut. Nanging aku nganggep sampeyan ngerti tembung Bitrix, Docker, Kubernetes, Ceph paling ora ing tingkat artikel ing Wikipedia.
Apa sing wis siap babagan Bitrix ing Kubernetes?
Ana sethithik banget informasi ing Internet babagan operasi aplikasi Bitrix ing Kubernetes.
Aku mung nemokake bahan kasebut:
Laporan dening Alexander Serbul, 1C-Bitrix, lan Anton Tuzlukov saka Qsoft:
Aku nyaranake ngrungokake.
Ngembangake solusi sampeyan dhewe saka pangguna .
ketemu liyane .
Aaand... bener, iku kabeh.
Aku ngelingake sampeyan, kita durung mriksa kualitas solusi ing tautan ing ndhuwur :)
Ngomong-ngomong, nalika nyiapake solusi, aku ngobrol karo Alexander Serbul, banjur laporan dheweke durung katon, mula ing slideku ana item "Bitrix ora nggunakake Kubernetes."
Nanging wis ana akeh gambar Docker sing wis siap kanggo mbukak Bitrix ing Docker:
Apa iki cukup kanggo nggawe solusi lengkap kanggo Bitrix ing Kubernetes?
Ora. Ana akeh masalah sing kudu dirampungake.
Apa masalah karo Bitrix ing Kubernetes?
Kaping pisanan, gambar sing wis digawe saka Dockerhub ora cocog kanggo Kubernetes
Yen kita pengin mbangun arsitektur microservices (lan ing Kubernetes biasane nindakake), kita kudu misahake aplikasi Kubernetes dadi wadhah lan saben wadhah nindakake fungsi cilik (lan nindakake kanthi apik). Kok mung siji? Ing cendhak, sing luwih prasaja luwih dipercaya.
Kanggo luwih spesifik, deleng artikel lan video iki, mangga:
Gambar Docker ing Dockerhub utamane dibangun ing prinsip kabeh-ing-siji, mula kita isih kudu nggawe sepeda dhewe lan malah nggawe gambar saka awal.
Kapindho - kode situs diowahi saka panel admin
Kita nggawe bagean anyar ing situs kasebut - kode kasebut dianyari (direktori kanthi jeneng bagean anyar ditambahake).
Yen sampeyan ngganti sifat komponen saka panel admin, kode kasebut diganti.
Kubernetes "kanthi standar" ora bisa digunakake; kontaner kudu tanpa negara.
Alesan: Saben wadhah (pod) ing kluster proses mung bagean saka lalu lintas. Yen sampeyan ngganti kode ing mung siji wadhah (pod), banjur kode bakal beda ing pods beda, situs bakal bisa beda, lan versi beda saka situs bakal ditampilake kanggo pangguna beda. Sampeyan ora bisa urip kaya ngono.
Katelu - sampeyan kudu ngatasi masalah karo penyebaran
Yen kita duwe monolit lan siji "klasik" server, kabeh iku cukup prasaja: kita masang basis kode anyar, migrasi database, ngalih lalu lintas menyang versi anyar saka kode. Ngalih dumadi langsung.
Yen kita duwe situs ing Kubernetes, Cut menyang microservices, ana akeh kontaner karo kode - oh. Sampeyan kudu ngumpulake kontaner kanthi versi kode anyar, gulung metu tinimbang sing lawas, migrasi database kanthi bener, lan saenipun nindakake iki tanpa diweruhi dening pengunjung. Untunge, Kubernetes mbantu kita babagan iki, ndhukung macem-macem jinis penyebaran.
Papat - sampeyan kudu ngatasi masalah nyimpen statis
Yen situs sampeyan "mung" 10 gigabyte lan sampeyan nyebarake kabeh ing kontaner, sampeyan bakal entuk 10 kontaner gigabyte sing bakal digunakake ing salawas-lawase.
Sampeyan kudu nyimpen bagean "paling abot" ing situs ing njaba wadhah, lan ana pitakonan babagan carane nindakake iki kanthi bener
Apa sing ilang saka solusi kita?
Kabeh kode Bitrix ora dipérang dadi microfunctions / microservices (supaya registrasi kapisah, modul toko online kapisah, etc.). Kita nyimpen kabeh basis kode ing saben wadhah.
Kita uga ora nyimpen database ing Kubernetes (Aku isih ngleksanakake solusi karo database ing Kubernetes kanggo lingkungan pembangunan, nanging ora kanggo produksi).
Iku isih bakal katon kanggo administrator situs sing situs mlaku ing Kubernetes. Fungsi "pemeriksaan sistem" ora bisa digunakake kanthi bener; kanggo ngowahi kode situs saka panel admin, sampeyan kudu ngeklik tombol "Aku pengin ngowahi kode".
Masalah wis diidentifikasi, kabutuhan kanggo ngleksanakake layanan mikro wis ditemtokake, tujuane jelas - kanggo entuk sistem sing bisa digunakake kanggo aplikasi ing Bitrix ing Kubernetes, njaga kemampuan Bitrix lan kaluwihan Kubernetes. Ayo miwiti implementasine.
arsitektur
Ana akeh pods "makarya" karo server web (buruh).
Siji ing ngisor karo tugas cron (mung siji sing dibutuhake).
Siji upgrade kanggo nyunting kode situs saka panel admin (uga mung siji sing dibutuhake).
Kita ngrampungake pitakonan:
- Where kanggo nyimpen sesi?
- Where kanggo nyimpen cache?
- Where kanggo nyimpen statics, ora kanggo nyeleh gigabyte statis ing Bunch saka kontaner?
- Kepiye database bisa digunakake?
Gambar Docker
Kita miwiti kanthi mbangun gambar Docker.
Pilihan sing cocog yaiku kita duwe gambar universal, kanthi basis kita entuk pod pekerja, polong karo Crontasks, lan polong upgrade.
.
Iki kalebu nginx, apache/php-fpm (bisa dipilih sajrone mbangun), msmtp kanggo ngirim email, lan cron.
Nalika ngumpulake gambar, kabeh basis kode situs kasebut disalin menyang direktori / app (kajaba bagean kasebut sing bakal dipindhah menyang panyimpenan bareng sing kapisah).
Layanan mikro, layanan
podho buruh:
- Wadah nganggo nginx + wadhah apache / php-fpm + msmtp
- Ora bisa mindhah msmtp menyang layanan mikro sing kapisah, Bitrix wiwit nesu amarga ora bisa ngirim email langsung
- Saben wadhah duwe basis kode lengkap.
- Larangan kanggo ngganti kode ing kontaner.
cron ing:
- wadhah karo apache, php, cron
- basis kode lengkap klebu
- larangan ngganti kode ing kontaner
upgrade miturut:
- wadhah nginx + wadhah apache / php-fpm + msmtp
- Ora ana larangan kanggo ngganti kode ing kontaner
panyimpenan sesi
Panyimpenan cache Bitrix
Liyane bab penting: kita nyimpen sandhi kanggo nyambungake menyang kabeh, saka database kanggo mail, ing rahasia kubernetes. Kita entuk bonus: sandhi mung katon kanggo wong-wong sing menehi akses menyang rahasia, lan ora kanggo kabeh wong sing duwe akses menyang basis kode proyek.
Panyimpenan kanggo statis
Sampeyan bisa nggunakake apa wae: ceph, nfs (nanging kita ora nyaranake nfs kanggo produksi), panyimpenan jaringan saka panyedhiya maya, lsp.
Panyimpenan kudu disambungake ing wadhah menyang direktori / upload / situs lan direktori liyane kanthi konten statis.
Database
Kanggo gamblang, disaranake mindhah database ing njaba Kubernetes. Basis ing Kubernetes minangka tugas rumit sing kapisah; bakal nggawe skema supaya luwih rumit.
Panyimpenan sesi
Kita nggunakake memcached :)
Nangani panyimpenan sesi kanthi apik, dikelompokake, lan didhukung "natively" minangka session.save_path ing php. Sistem kasebut wis dites kaping pirang-pirang ing arsitektur monolitik klasik, nalika kita mbangun kluster kanthi akeh server web. Kanggo penyebaran kita nggunakake helm.
$ helm install stable/memcached --name sessionphp.ini - ing kene gambar ngemot setelan kanggo nyimpen sesi ing memcached
Kita nggunakake Variabel Lingkungan kanggo ngirim data babagan host kanthi memcached .
Iki ngidini sampeyan nggunakake kode sing padha ing lingkungan dev, tataran, test, prod (jeneng host memcached ing wong-wong mau bakal beda-beda, supaya kita kudu pass jeneng host unik kanggo sesi kanggo saben lingkungan).
Panyimpenan cache Bitrix
We kudu panyimpenan fault-tolerant sing kabeh pods bisa nulis lan maca saka.
Kita uga nggunakake memcached.
Solusi iki dianjurake dening Bitrix dhewe.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - kene ing Bitrix ditemtokake ngendi cache disimpen
Kita uga nggunakake Variabel Lingkungan.
Krontaski
Ana macem-macem pendekatan kanggo mbukak Crontasks ing Kubernetes.
- penyebaran kapisah karo pod kanggo mlaku Crontasks
- cronjob kanggo nglakokake crontasks (yen iki aplikasi web - nganggo wget , utawa kubectl exec ing salah sawijining pod pekerja, lsp.)
- etc.
Sampeyan bisa mbantah babagan sing paling bener, nanging ing kasus iki kita milih pilihan "penyebaran kapisah karo pods kanggo Crontasks"
Carane iku rampung:
- nambah tugas cron liwat ConfigMap utawa liwat file config / addcron
- ing salah sawijining conto, kita mbukak wadhah sing padha karo pod pekerja + ngidini eksekusi tugas mahkota ing njero
- basa kode padha digunakake, thanks kanggo manunggalaken, Déwan wadhah punika prasaja
Apa gunane:
- kita wis nggarap Crontasks ing lingkungan sing padha karo lingkungan pangembang (docker)
- Crontasks ora perlu "ditulis maneh" kanggo Kubernetes, padha bisa digunakake ing wangun sing padha lan ing basis kode padha sadurunge.
- tugas cron bisa ditambahake dening kabeh anggota tim kanthi hak komitmen kanggo cabang produksi, ora mung admin
Southbridge K8SDeploy modul lan kode editing saka panel admin
Kita padha ngomong bab upgrade ing?
Kepiye carane ngarahake lalu lintas ing kana?
Hurray, kita nulis modul iki ing PHP :) Iki modul klasik cilik kanggo Bitrix. Iku durung kasedhiya kanggo umum, nanging kita rencana kanggo mbukak.
Modul kasebut diinstal kaya modul biasa ing Bitrix:
Lan katon kaya iki:
Ngidini sampeyan nyetel cookie sing ngenali administrator situs lan ngidini Kubernetes ngirim lalu lintas menyang pod upgrade.
Nalika owah-owahan wis rampung, sampeyan kudu ngeklik git push, owah-owahan kode bakal dikirim menyang git, banjur sistem bakal mbangun gambar karo versi anyar saka kode lan "muter metu" ing kluster, ngganti pods lawas. .
Ya, iku rada crutch, nanging ing wektu sing padha kita njaga arsitektur microservice lan ora njupuk saka pangguna Bitrix kesempatan favorit kanggo mbenerake kode saka panel admin. Pungkasane, iki minangka pilihan; sampeyan bisa ngatasi masalah nyunting kode kanthi cara sing beda.
Bagan helm
Kanggo mbangun aplikasi ing Kubernetes, biasane nggunakake manajer paket Helm.
Kanggo solusi Bitrix ing Kubernetes, Sergey Bondarev, administrator sistem utama, nulis grafik Helm khusus.
Iku mbangun worker, ugrade, cron pods, configures ingresses, layanan, lan transfer variabel saka rahasia Kubernetes menyang pods.
Kita nyimpen kode ing Gitlab, lan kita uga mbukak Helm mbangun saka Gitlab.
Ing cendhak, katon kaya iki
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm uga ngijini sampeyan kanggo nindakake "mulus" rollback yen dumadakan ana salah sak penyebaran. Iku apik yen sampeyan ora gupuh "ndandani kode liwat ftp amarga prod tiba," nanging Kubernetes nindakaken kanthi otomatis, lan tanpa downtime.
nyebarake
Ya, kita penggemar Gitlab & Gitlab CI, kita nggunakake :)
Nalika nindakake ing Gitlab menyang repositori proyek, Gitlab ngluncurake pipa sing nyebarake versi lingkungan anyar.
Tahap:
- mbangun (mbangun gambar Docker anyar)
- tes (testing)
- ngresiki (mbusak lingkungan test)
- push (kita ngirim menyang registri Docker)
- deploy (kita masang aplikasi menyang Kubernetes liwat Helm).
Hore, wis siyap, ayo dileksanakake!
Inggih, utawa takon pitakonan yen ana.
Dadi apa sing kita lakoni
Saka sudut pandang teknis:
- Dockerized Bitrix;
- "Cut" Bitrix menyang kontaner, saben-saben nindakake fungsi minimal;
- ngrambah negara stateless saka kontaner;
- ngatasi masalah karo nganyari Bitrix ing Kubernetes;
- kabeh fungsi Bitrix terus bisa (meh kabeh);
- Kita nggarap penyebaran menyang Kubernetes lan muter maneh ing antarane versi.
Saka sudut pandang bisnis:
- toleransi kesalahan;
- Alat Kubernetes (integrasi gampang karo Gitlab CI, panyebaran lancar, lsp);
- sandhi rahasia (mung bisa dideleng kanggo wong sing langsung diwenehi akses menyang sandhi);
- Iku trep kanggo nggawe lingkungan tambahan (kanggo pembangunan, tes, etc.) ing infrastruktur siji.
Source: www.habr.com