Papanggihan administrator sistem Sysadminka lumangsung di Chelyabinsk, sareng anu terakhir kuring masihan laporan ngeunaan solusi kami pikeun ngajalankeun aplikasi dina 1C-Bitrix di Kubernetes.
Bitrix, Kubernetes, Ceph - campuran hébat?
Kuring bakal ngabejaan ka maneh kumaha urang nunda babarengan solusi gawé tina sagala ieu.
Hayu urang balik!
Papanggihan lumangsung dina 18 April di Chelyabinsk. Anjeun tiasa maca ngeunaan meetup urang di jeung kasampak di .
Upami anjeun hoyong sumping ka kami kalayan laporan atanapi salaku pangdéngé - wilujeng sumping, nyerat ka [email dijaga] sareng dina Telegram t.me/vadimisakanov.
laporan kuring
Solusi "Bitrix di Kubernetes, versi Southbridge 1.0"
Kuring bakal ngobrol ngeunaan solusi urang dina format "kanggo dummies di Kubernetes", sakumaha anu dipigawé dina meetup. Tapi kuring nganggap yén anjeun terang kecap Bitrix, Docker, Kubernetes, Ceph sahenteuna dina tingkat tulisan dina Wikipedia.
Naon anu siap-siap ngeunaan Bitrix di Kubernetes?
Aya saeutik pisan inpormasi dina sakabéh Internét ngeunaan operasi aplikasi Bitrix di Kubernetes.
Kuring ngan manggihan bahan ieu:
Laporan ku Alexander Serbul, 1C-Bitrix, sareng Anton Tuzlukov ti Qsoft:
Abdi nyarankeun ngadangukeunana.
Ngembangkeun solusi anjeun nyalira ti pangguna .
Kapanggih deui .
Aaand... sabenerna, éta sakabéh.
Kuring ngingetkeun anjeun, kami henteu acan pariksa kualitas solusi dina tautan di luhur :)
Ngomong-ngomong, nalika nyiapkeun solusi kami, kuring ngobrol sareng Alexander Serbul, teras laporanna henteu acan muncul, janten dina slide kuring aya item "Bitrix henteu nganggo Kubernetes."
Tapi parantos aya seueur gambar Docker anu siap-siap pikeun ngajalankeun Bitrix di Docker:
Naha ieu cekap pikeun nyiptakeun solusi lengkep pikeun Bitrix di Kubernetes?
No. Aya sajumlah ageung masalah anu kedah direngsekeun.
Naon masalah sareng Bitrix di Kubernetes?
Kahiji, gambar siap-dijieun tina Dockerhub henteu cocog pikeun Kubernetes
Upami urang hoyong ngawangun arsitéktur microservices (sareng di Kubernetes biasana urang ngalakukeun), urang kedah misahkeun aplikasi Kubernetes kana wadahna sareng masing-masing wadahna ngalaksanakeun hiji fungsi anu alit (sareng ngalaksanakeunna saé). Naha ngan hiji? Pondokna, nu basajan leuwih dipercaya.
Pikeun langkung spésifik, tingali artikel sareng pidéo ieu, mangga:
Gambar Docker di Dockerhub utamana diwangun dina prinsip sadaya-dina-hiji, ku kituna urang masih kedah ngadamel sapédah sorangan komo nyieun gambar ti scratch.
Kadua - kode situs diédit tina panel admin
Kami nyiptakeun bagian énggal dina situs éta - kodeu parantos diropéa (diréktori kalayan nami bagian énggal parantos ditambah).
Upami anjeun ngarobih sipat komponén tina panel admin, kodeu dirobih.
Kubernetes "sacara standar" teu tiasa dianggo sareng ieu; wadahna kedah stateless.
Alesan: Unggal wadahna (pod) dina klaster prosés ngan nyangkokkeun sabagian lalulintas. Upami anjeun ngarobih kode dina ngan ukur hiji wadah (pod), maka kodeu bakal béda dina pods anu béda, situsna bakal tiasa dianggo béda, sareng versi anu béda tina situs bakal ditingalikeun ka pangguna anu béda. Anjeun moal tiasa hirup sapertos kitu.
Katilu - anjeun kedah ngabéréskeun masalah kalayan panyebaran
Upami urang gaduh monolith sareng salah sahiji server "klasik", sadayana saderhana: urang nyebarkeun dasar kode énggal, migrasi pangkalan data, pindahkeun lalu lintas kana versi kode anyar. Ngalihkeun lumangsung langsung.
Lamun urang boga situs di Kubernetes, potong microservices, aya loba peti jeung kode - oh. Anjeun kedah ngumpulkeun peti kalayan versi anyar kode, gulung aranjeunna kaluar tinimbang nu heubeul, leres migrasi database, sarta ideally ngalakukeun ieu unnoticed ku datang. Untungna, Kubernetes ngabantosan kami dina ieu, ngadukung sakumpulan jinis panyebaran anu béda.
Kaopat - anjeun kedah ngabéréskeun masalah nyimpen statik
Lamun situs anjeun "ngan" 10 gigabytes jeung anjeun nyebarkeun eta sagemblengna dina peti, anjeun bakal mungkas nepi ka 10 peti gigabyte nu nyandak salamina nyebarkeun.
Anjeun kedah nyimpen bagian "paling beurat" dina situs di luar wadahna, sareng patarosan timbul kumaha ngalakukeun ieu leres.
Naon anu leungit tina solusi kami?
Sakabéh kode Bitrix henteu dibagi kana microfunctions / microservices (supaya pendaptaran misah, modul toko online misah, jsb). Urang nyimpen sakabéh basa kode dina unggal wadahna.
Urang ogé henteu nyimpen databés dina Kubernetes (Kuring masih ngalaksanakeun solusi sareng database di Kubernetes pikeun lingkungan pangwangunan, tapi henteu pikeun produksi).
Masih bakal katingali ku pangurus situs yén situs éta dijalankeun dina Kubernetes. Fungsi "pariksa sistem" henteu jalan leres; pikeun ngédit kode situs tina panel admin, anjeun kedah pencét heula tombol "Kuring hoyong ngédit kodeu".
Masalahna parantos diidentifikasi, kabutuhan pikeun nerapkeun jasa mikro parantos ditangtukeun, tujuanana jelas - pikeun kéngingkeun sistem anu tiasa dianggo pikeun ngajalankeun aplikasi dina Bitrix di Kubernetes, ngajaga kamampuan Bitrix sareng kaunggulan Kubernetes. Hayu urang mimitian palaksanaan.
gawena undagi
Aya seueur pods "garap" sareng server wéb (pagawe).
Hiji handapeun kalawan tugas cron (ngan hiji diperlukeun).
Hiji pamutahiran pikeun ngédit kode situs ti panel admin (ogé ngan hiji diperlukeun).
Urang ngajawab patarosan:
- Dimana nyimpen sesi?
- Dimana nyimpen cache?
- Dimana nyimpen statics, teu nempatkeun gigabytes of statics dina kebat peti?
- Kumaha database bakal dianggo?
Gambar Docker
Urang mimitian ku ngawangun gambar Docker.
Pilihan idéal nyaéta yén urang gaduh hiji gambar universal, dumasar kana dasarna, urang nampi pods worker, pods sareng Crontasks, sareng ningkatkeun pods.
.
Éta kalebet nginx, apache/php-fpm (tiasa dipilih nalika ngawangun), msmtp pikeun ngirim surat, sareng cron.
Nalika assembling gambar, sakabéh basa kode situs ieu disalin kana / diréktori aplikasi (iwal eta bagian nu urang bakal mindahkeun ka gudang dibagikeun misah).
Microservices, jasa
pagawe pod:
- Wadahna nganggo nginx + wadahna Apache / php-fpm + msmtp
- Teu hasil pikeun mindahkeun msmtp kana microservice anu misah, Bitrix mimiti ngambek yén éta henteu tiasa ngirim surat langsung.
- Unggal wadahna gaduh basis kode anu lengkep.
- Larangan pikeun ngarobah kodeu dina peti.
cron handapeun:
- wadahna kalawan Apache, php, cron
- base kode lengkep kaasup
- larangan dina ngarobah kode dina peti
ningkatkeun dina:
- wadahna nginx + wadahna Apache / php-fpm + msmtp
- Henteu aya larangan pikeun ngarobih kode dina peti
neundeun sési
Panyimpenan cache Bitrix
Hal penting séjén: urang nyimpen kecap akses pikeun nyambung ka sagalana, ti database ka mail, dina Rahasia kubernetes. Kami nampi bonus: kecap akses ngan ukur katingali ku jalma anu kami masihan aksés kana rusiah, sareng henteu ka sadayana anu ngagaduhan aksés kana dasar kode proyék.
Panyimpenan pikeun statik
Anjeun tiasa nganggo naon waé: ceph, nfs (tapi kami henteu nyarankeun nfs pikeun produksi), neundeun jaringan tina panyadia awan, jsb.
Panyimpenan kedah dihubungkeun dina wadah ka diréktori / unggah / situs sareng diréktori sanés anu eusina statik.
Basis data
Pikeun kesederhanaan, kami nyarankeun mindahkeun pangkalan data di luar Kubernetes. Dasar di Kubernetes mangrupikeun tugas kompleks anu misah; éta bakal ngajantenkeun skéma langkung ageung langkung kompleks.
neundeun sési
Kami nganggo memcached :)
Ieu handles gudang sési ogé, ieu clustered, sarta dirojong "asli" salaku session.save_path di php. Sistim saperti geus diuji sababaraha kali dina arsitektur monolithic klasik, nalika urang ngawangun klaster kalawan angka nu gede ngarupakeun web server. Pikeun deployment kami nganggo Helm.
$ helm install stable/memcached --name sessionphp.ini - di dieu gambar ngandung setélan pikeun nyimpen sesi di memcached
Kami nganggo Variabel Lingkungan pikeun ngalirkeun data ngeunaan host kalayan memcached .
Hal ieu ngamungkinkeun anjeun ngagunakeun kodeu sarua dina dev, panggung, test, lingkungan prod (ngaran host memcached di antarana bakal béda, jadi urang kudu lulus ngaran host unik pikeun sesi ka unggal lingkungan).
Panyimpenan cache Bitrix
Urang peryogi panyimpen anu toleran lepat anu sadayana pod tiasa nyerat sareng maca.
Urang ogé ngagunakeun memcached.
Solusi ieu disarankeun ku Bitrix sorangan.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - didieu di Bitrix dieusian dimana cache disimpen
Urang ogé ngagunakeun Variabel Lingkungan.
Krontaski
Aya sababaraha pendekatan pikeun ngajalankeun Crontasks di Kubernetes.
- deployment misah jeung pod pikeun ngajalankeun Crontasks
- cronjob pikeun ngaéksekusi crontasks (upami ieu mangrupikeun aplikasi wéb - nganggo wget , atanapi kubectl exec di jero salah sahiji polong pagawe, jsb.)
- jsb
Anjeun tiasa ngajawab ngeunaan anu paling leres, tapi dina hal ieu kami milih pilihan "penyebaran misah sareng pods pikeun Crontasks"
Kumaha éta dilakukeun:
- tambahkeun tugas cron via ConfigMap atanapi via file config / addcron
- dina hiji conto urang ngajalankeun wadahna idéntik jeung worker pod + ngidinan palaksanaan tugas makuta di dinya
- basa kode sarua dipaké, hatur nuhun kana ngahiji, assembly wadahna basajan
Naon alusna urang meunang:
- kami parantos damel Crontasks di lingkungan anu sami sareng lingkungan pamekar (docker)
- Crontasks henteu kedah "ditulis ulang" kanggo Kubernetes, aranjeunna tiasa dianggo dina bentuk anu sami sareng dina dasar kode anu sami sareng sateuacana.
- tugas cron bisa ditambahkeun ku sakabeh anggota tim kalawan hak komitmen kana cabang produksi, teu ngan admins
Southbridge K8SDeploy modul jeung ngedit kode ti panel admin
Urang ngobrol ngeunaan pamutahiran sahandapeun?
Kumaha ngarahkeun lalu lintas di dinya?
Hurray, urang nulis modul pikeun ieu dina PHP :) Ieu modul Palasik leutik pikeun Bitrix. Éta henteu acan sayogi pikeun umum, tapi kami badé mukakeunana.
Modul dipasang sapertos modul biasa dina Bitrix:
Sareng sapertos kieu:
Éta ngamungkinkeun anjeun nyetél cookie anu ngidentipikasi administrator situs sareng ngamungkinkeun Kubernetes ngirim lalu lintas kana pod pamutahiran.
Nalika parobihan parantos réngsé, anjeun kedah klik git push, parobihan kode bakal dikirim ka git, teras sistem bakal ngawangun gambar nganggo versi kode anu énggal sareng "gulung kaluar" dina kluster, ngagentos pods lami. .
Leres, éta sakedik kruk, tapi dina waktos anu sami urang ngajaga arsitéktur microservice sareng henteu nyandak pangguna Bitrix kasempetan karesepna pikeun ngabenerkeun kode tina panel admin. Tungtungna, ieu mangrupikeun pilihan; anjeun tiasa ngabéréskeun masalah ngédit kode ku cara anu béda.
Bagan helm
Pikeun ngawangun aplikasi dina Kubernetes, urang biasana nganggo manajer pakét Helm.
Pikeun solusi Bitrix kami di Kubernetes, Sergey Bondarev, administrator sistem utama kami, nyerat bagan Helm khusus.
Éta ngawangun pagawé, ugrade, cron pods, ngonpigurasikeun asupan, jasa, sareng nransferkeun variabel tina Rahasia Kubernetes ka pods.
Urang nyimpen kodeu di Gitlab, sarta kami ogé ngajalankeun Helm ngawangun ti Gitlab.
Pondokna, sigana kieu
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm ogé ngidinan Anjeun pikeun ngalakukeun hiji "seamless" rollback lamun ujug-ujug aya nu salah salila deployment. Ieu nice lamun anjeun teu panik "ngalereskeun kode via ftp sabab prod nu murag," tapi Kubernetes ngalakukeun eta otomatis, sarta tanpa downtime.
Nyebarkeun
Leres, kami fans Gitlab & Gitlab CI, kami nganggo éta :)
Nalika komitmen di Gitlab ka gudang proyék, Gitlab ngaluncurkeun pipa anu nyebarkeun versi lingkungan anyar.
hambalan:
- ngawangun (ngawangun gambar Docker anyar)
- uji (uji)
- ngabersihkeun (ngahapus lingkungan tés)
- push (urang kirimkeun ka pendaptaran Docker)
- nyebarkeun (urang nyebarkeun aplikasi pikeun Kubernetes via Helm).
Hore, geus siap, hayu urang laksanakeun!
Nya, atanapi naroskeun patarosan upami aya.
Janten naon anu urang laksanakeun
Ti sudut pandang teknis:
- dockerized Bitrix;
- "motong" Bitrix kana wadahna, anu masing-masing ngalaksanakeun fungsi minimum;
- kahontal kaayaan stateless tina wadahna;
- ngarengsekeun masalah sareng ngamutahirkeun Bitrix di Kubernetes;
- sadaya fungsi Bitrix terus jalan (ampir kabéh);
- Urang digawé dina deployment ka Kubernetes jeung rollback antara versi.
Tina sudut pandang bisnis:
- kasabaran kasalahan;
- Alat Kubernetes (integrasi gampang sareng Gitlab CI, panyebaran lancar, jsb);
- kecap akses rusiah (ngan katingali ku jalma anu langsung dibéré aksés kana kecap akses);
- Éta merenah pikeun nyieun lingkungan tambahan (pikeun pangwangunan, tés, jeung sajabana) dina hiji infrastruktur tunggal.
sumber: www.habr.com