Takimet e administratorëve të sistemit Sysadminka po zhvillohen në Chelyabinsk, dhe në të fundit unë dhashë një raport mbi zgjidhjen tonë për ekzekutimin e aplikacioneve në 1C-Bitrix në Kubernetes.
Bitrix, Kubernetes, Ceph - një përzierje e shkëlqyer?
Unë do t'ju tregoj se si kemi bashkuar një zgjidhje funksionale nga e gjithë kjo.
Le të shkojë!
Takimi u zhvillua më 18 prill në Chelyabinsk. Ju mund të lexoni për takimet tona në dhe shiko .
Nëse dëshironi të vini tek ne me një raport ose si dëgjues - mirë se vini, shkruani tek ne [email mbrojtur] dhe në Telegram t.me/vadimisakanov.
Raporti im
Zgjidhja "Bitrix në Kubernetes, versioni Southbridge 1.0"
Unë do të flas për zgjidhjen tonë në formatin "për dummies në Kubernetes", siç u bë në takim. Por supozoj se ju i dini fjalët Bitrix, Docker, Kubernetes, Ceph të paktën në nivelin e artikujve në Wikipedia.
Çfarë është gati për Bitrix në Kubernetes?
Ka shumë pak informacion në të gjithë internetin në lidhje me funksionimin e aplikacioneve në Bitrix në Kubernetes.
Kam gjetur vetëm këto materiale:
Raport nga Alexander Serbul, 1C-Bitrix dhe Anton Tuzlukov nga Qsoft:
Unë rekomandoj ta dëgjoni.
Zhvillimi i zgjidhjes tuaj nga përdoruesi .
Gjeti më shumë .
Aadhe... në fakt, kjo është e gjitha.
Ju paralajmëroj, ne nuk kemi kontrolluar cilësinë e zgjidhjeve në lidhjet e mësipërme :)
Nga rruga, kur përgatitja zgjidhjen tonë, bisedova me Alexander Serbul, atëherë raporti i tij nuk ishte shfaqur ende, kështu që në rrëshqitjet e mia ka një artikull "Bitrix nuk përdor Kubernetes".
Por tashmë ka shumë imazhe të gatshme Docker për ekzekutimin e Bitrix në Docker:
A mjafton kjo për të krijuar një zgjidhje të plotë për Bitrix në Kubernetes?
Nr. Ka një numër të madh problemesh që duhen zgjidhur.
Cilat janë problemet me Bitrix në Kubernetes?
Së pari, imazhet e gatshme nga Dockerhub nuk janë të përshtatshme për Kubernetes
Nëse duam të ndërtojmë një arkitekturë mikroshërbimesh (dhe në Kubernetes ne zakonisht e bëjmë), ne duhet të ndajmë aplikacionin tonë Kubernetes në kontejnerë dhe që secili kontejner të kryejë një funksion të vogël (dhe ta bëjë mirë). Pse vetëm një? Me pak fjalë, sa më e thjeshtë aq më e besueshme.
Për të qenë më specifik, shikoni këtë artikull dhe video, ju lutemi:
Imazhet e Docker në Dockerhub janë ndërtuar kryesisht mbi parimin "gjithë-në-një", kështu që ne ende duhej të bënim biçikletën tonë dhe madje të krijonim imazhe nga e para.
Së dyti - kodi i faqes redaktohet nga paneli i administratorit
Ne krijuam një seksion të ri në sit - kodi u përditësua (u shtua një drejtori me emrin e seksionit të ri).
Nëse keni ndryshuar vetitë e një komponenti nga paneli i administratorit, kodi ndryshon.
Kubernetes "si parazgjedhje" nuk mund të funksionojë me këtë; kontejnerët duhet të jenë pa shtetësi.
Arsyeja: Çdo kontejner (pod) në grup përpunon vetëm një pjesë të trafikut. Nëse e ndryshoni kodin vetëm në një enë (pod), atëherë kodi do të jetë i ndryshëm në pods të ndryshëm, faqja do të funksionojë ndryshe dhe versione të ndryshme të sajtit do t'u shfaqen përdoruesve të ndryshëm. Nuk mund të jetosh kështu.
Së treti - ju duhet ta zgjidhni çështjen me vendosjen
Nëse kemi një server monolit dhe një server "klasik", gjithçka është mjaft e thjeshtë: vendosim një bazë të re kodi, migrojmë bazën e të dhënave, kalojmë trafikun në versionin e ri të kodit. Ndërrimi ndodh menjëherë.
Nëse kemi një faqe në Kubernetes, të prerë në mikroshërbime, ka shumë kontejnerë me kod - oh. Ju duhet të grumbulloni kontejnerë me një version të ri të kodit, t'i hapni ato në vend të atyre të vjetrit, të migroni saktë bazën e të dhënave dhe në mënyrë ideale ta bëni këtë pa u vënë re nga vizitorët. Për fat të mirë, Kubernetes na ndihmon me këtë, duke mbështetur një grup të tërë llojesh të ndryshme vendosjesh.
Së katërti - ju duhet të zgjidhni çështjen e ruajtjes së statikës
Nëse faqja juaj është "vetëm" 10 gigabajt dhe e vendosni atë tërësisht në kontejnerë, do të përfundoni me kontejnerë 10 gigabajt që vendosen përgjithmonë.
Ju duhet të ruani pjesët "më të rënda" të faqes jashtë kontejnerëve dhe lind pyetja se si ta bëni këtë saktë
Çfarë i mungon zgjidhjes sonë?
I gjithë kodi Bitrix nuk është i ndarë në mikrofunksione/mikroshërbime (në mënyrë që regjistrimi të jetë i veçantë, moduli i dyqanit online të jetë i veçantë, etj.). Ne ruajmë të gjithë bazën e kodit në çdo enë.
Ne gjithashtu nuk e ruajmë bazën e të dhënave në Kubernetes (Unë ende zbatova zgjidhje me një bazë të dhënash në Kubernetes për mjediset e zhvillimit, por jo për prodhimin).
Do të jetë ende e dukshme për administratorët e faqes që faqja funksionon në Kubernetes. Funksioni "kontrolli i sistemit" nuk funksionon siç duhet; për të modifikuar kodin e faqes nga paneli i administratorit, së pari duhet të klikoni butonin "Dua të modifikoj kodin".
Problemet janë identifikuar, nevoja për të zbatuar mikroshërbime është përcaktuar, qëllimi është i qartë - të merret një sistem pune për ekzekutimin e aplikacioneve në Bitrix në Kubernetes, duke ruajtur si aftësitë e Bitrix ashtu edhe avantazhet e Kubernetes. Le të fillojmë zbatimin.
Arkitekturë
Ka shumë pods "punues" me një server në internet (punëtorë).
Një nën me detyra cron (kërkohet vetëm një).
Një përmirësim për modifikimin e kodit të faqes nga paneli i administratorit (gjithashtu kërkohet vetëm një).
Ne zgjidhim pyetjet:
- Ku të ruhen seancat?
- Ku të ruhet cache?
- Ku të ruani statikën, të mos vendosni gigabajt statikë në një tufë kontejnerësh?
- Si do të funksionojë baza e të dhënave?
Imazhi i dokerit
Ne fillojmë duke ndërtuar një imazh Docker.
Opsioni ideal është që ne të kemi një imazh universal, mbi bazën e tij marrim pods punëtor, pods me Crontasks dhe azhurnime.
.
Ai përfshin nginx, apache/php-fpm (mund të zgjidhet gjatë ndërtimit), msmtp për dërgimin e postës dhe cron.
Kur montoni imazhin, e gjithë baza e kodit të faqes kopjohet në direktorinë /app (me përjashtim të atyre pjesëve që do t'i zhvendosim në një ruajtje të veçantë të përbashkët).
Mikroshërbime, shërbime
bishtajat e punëtorëve:
- Kontejner me nginx + kontejner apache/php-fpm + msmtp
- Nuk funksionoi për të zhvendosur msmtp në një mikroshërbim të veçantë, Bitrix po fillon të indinjohet që nuk mund të dërgojë postë direkt
- Çdo kontejner ka një bazë të plotë kodesh.
- Ndalimi i ndryshimit të kodit në kontejnerë.
cron nën:
- enë me apache, php, cron
- e përfshirë bazën e plotë të kodit
- ndalimi i ndryshimit të kodit në kontejnerë
përmirësimi sipas:
- kontejner nginx + kontejner apache/php-fpm + msmtp
- Nuk ka asnjë ndalim për ndryshimin e kodit në kontejnerë
ruajtja e sesioneve
Ruajtja e memories Bitrix
Një tjetër gjë e rëndësishme: ne ruajmë fjalëkalime për t'u lidhur me gjithçka, nga baza e të dhënave te posta, në sekretet kubernetes. Ne marrim një bonus: fjalëkalimet janë të dukshme vetëm për ata të cilëve u japim akses në sekretet, dhe jo për të gjithë ata që kanë akses në bazën e kodit të projektit.
Magazinimi për statikën
Ju mund të përdorni çdo gjë: ceph, nfs (por ne nuk rekomandojmë nfs për prodhim), ruajtjen e rrjetit nga ofruesit e cloud, etj.
Hapësira ruajtëse do të duhet të lidhet në kontejnerë me drejtorinë /upload/ të sajtit dhe drejtoritë e tjera me përmbajtje statike.
bazës së të dhënave
Për thjeshtësi, ne rekomandojmë zhvendosjen e bazës së të dhënave jashtë Kubernetes. Baza në Kubernetes është një detyrë më vete komplekse; do ta bëjë skemën një renditje të madhësisë më komplekse.
Ruajtja e sesionit
Ne përdorim memcached :)
Ai trajton mirë ruajtjen e sesioneve, është i grupuar dhe mbështetet "në bazë" si session.save_path në php. Një sistem i tillë është testuar shumë herë në arkitekturën klasike monolitike, kur kemi ndërtuar grupe me një numër të madh të serverëve në internet. Për vendosjen ne përdorim timonin.
$ helm install stable/memcached --name sessionphp.ini - këtu imazhi përmban cilësimet për ruajtjen e seancave në memcached
Ne përdorëm variablat e mjedisit për të kaluar të dhëna për hostet me memcached .
Kjo ju lejon të përdorni të njëjtin kod në mjediset e dev, fazë, test, prod (emrat e hosteve të memcached në to do të jenë të ndryshëm, kështu që ne duhet të kalojmë një emër unik pritës për seancat në çdo mjedis).
Ruajtja e memories Bitrix
Ne kemi nevojë për ruajtje tolerante ndaj gabimeve në të cilën të gjitha podet mund të shkruajnë dhe të lexojnë.
Ne përdorim gjithashtu memcached.
Kjo zgjidhje rekomandohet nga vetë Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - këtu në Bitrix specifikohet se ku ruhet cache
Ne përdorim gjithashtu variablat e mjedisit.
Krontaski
Ka qasje të ndryshme për ekzekutimin e Crontasks në Kubernetes.
- vendosje e veçantë me një pod për ekzekutimin e Crontasks
- cronjob për ekzekutimin e crontasks (nëse ky është një aplikacion në internet - me wget , ose kubectl exec brenda një prej podeve të punëtorëve, etj.)
- etj.
Ju mund të debatoni për atë më të saktën, por në këtë rast ne zgjodhëm opsionin "vendosja e veçantë me pods për Crontasks"
Si bëhet:
- shtoni detyrat cron nëpërmjet ConfigMap ose nëpërmjet skedarit config/addcron
- në një rast lëshojmë një kontejner identik me podin e punëtorit + lejojmë ekzekutimin e detyrave të kurorës në të
- përdoret e njëjta bazë kodi, falë unifikimit, montimi i kontejnerit është i thjeshtë
Çfarë të mirë kemi:
- ne kemi Crontasks pune në një mjedis identik me mjedisin e zhvilluesve (docker)
- Crontasks nuk kanë nevojë të "rishkruhen" për Kubernetes, ato punojnë në të njëjtën formë dhe në të njëjtën bazë kodi si më parë
- detyrat cron mund të shtohen nga të gjithë anëtarët e ekipit me të drejta të angazhimit në degën e prodhimit, jo vetëm nga administratorët
Southbridge K8SDeploy modulin dhe modifikimin e kodit nga paneli i administratorit
Ne po flisnim për përmirësimin nën?
Si të drejtoni trafikun atje?
Hurra, ne kemi shkruar një modul për këtë në PHP :) Ky është një modul i vogël klasik për Bitrix. Nuk është ende në dispozicion për publikun, por ne planifikojmë ta hapim atë.
Moduli është i instaluar si një modul i rregullt në Bitrix:
Dhe duket kështu:
Kjo ju lejon të vendosni një cookie që identifikon administratorin e faqes dhe lejon Kubernetes të dërgojë trafik në podin e përmirësimit.
Kur të përfundojnë ndryshimet, duhet të klikoni git push, ndryshimet e kodit do të dërgohen në git, më pas sistemi do të ndërtojë një imazh me një version të ri të kodit dhe do ta "shpërndajë" atë nëpër grup, duke zëvendësuar podet e vjetra. .
Po, është pak paterica, por në të njëjtën kohë ne ruajmë arkitekturën e mikroshërbimit dhe nuk u heqim përdoruesve të Bitrix mundësinë e tyre të preferuar për të korrigjuar kodin nga paneli i administratorit. Në fund, ky është një opsion; ju mund ta zgjidhni problemin e redaktimit të kodit në një mënyrë tjetër.
Grafiku i timonit
Për të ndërtuar aplikacione në Kubernetes, ne zakonisht përdorim menaxherin e paketave Helm.
Për zgjidhjen tonë Bitrix në Kubernetes, Sergey Bondarev, administratori ynë kryesor i sistemit, shkroi një tabelë të veçantë Helm.
Ai ndërton worker, ugrade, cron pods, konfiguron hyrjet, shërbimet dhe transferon variabla nga sekretet e Kubernetes në pods.
Ne e ruajmë kodin në Gitlab, dhe gjithashtu ekzekutojmë ndërtimin e Helm nga Gitlab.
Me pak fjalë, duket kështu
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm gjithashtu ju lejon të bëni një rikthim "të qetë" nëse papritur diçka shkon keq gjatë vendosjes. Është mirë kur nuk jeni në panik "rregulloni kodin përmes ftp sepse prod-i ra", por Kubernetes e bën atë automatikisht dhe pa ndërprerje.
Vendosni
Po, ne jemi adhurues të Gitlab & Gitlab CI, ne e përdorim atë :)
Kur angazhohet në Gitlab në depon e projektit, Gitlab lëshon një tubacion që vendos një version të ri të mjedisit.
faza:
- build (ndërtimi i një imazhi të ri Docker)
- provë (testim)
- pastroj (duke hequr mjedisin e testimit)
- shtytje (ne e dërgojmë atë në regjistrin Docker)
- vendosim (ne e vendosim aplikacionin në Kubernetes nëpërmjet Helm).
Hurra, është gati, le ta zbatojmë!
Epo, ose bëni pyetje nëse ka.
Pra, çfarë bëmë
Nga pikëpamja teknike:
- Bitrix i dokerizuar;
- "Preni" Bitrix në kontejnerë, secila prej të cilave kryen një minimum funksionesh;
- ka arritur gjendje pa shtetësi të kontejnerëve;
- zgjidhi problemin me përditësimin e Bitrix në Kubernetes;
- të gjitha funksionet Bitrix vazhduan të funksionojnë (pothuajse të gjitha);
- Ne kemi punuar për vendosjen në Kubernetes dhe rikthimin midis versioneve.
Nga pikëpamja e biznesit:
- toleranca ndaj gabimeve;
- Mjetet Kubernetes (integrim i lehtë me Gitlab CI, vendosje pa probleme, etj);
- fjalëkalime sekrete (të dukshme vetëm për ata të cilëve u është dhënë drejtpërdrejt akses në fjalëkalime);
- Është i përshtatshëm për të krijuar mjedise shtesë (për zhvillim, teste, etj.) brenda një infrastrukture të vetme.
Burimi: www.habr.com