ProHoster > Blog > Administrimi > Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

NĂ« Çeljabinsk po zhvillohen takime pĂ«r administratorĂ«t e sistemeve Sysadminka, dhe nĂ« takimin e fundit pata njĂ« prezantim mbi zgjidhjen tonĂ« pĂ«r funksionimin e aplikacioneve nĂ« 1C-Bitrix nĂ« Kubernetes.

Bitrix, Kubernetes, Ceph — njĂ« pĂ«rzierje e shkĂ«lqyer?

Do të flas për mënyrën se si ne e përbëm një zgjidhje funksionale nga të gjitha këto.

Fillojmë!

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Takimi u zhvillua mĂ« 18 prill nĂ« Çeljabinsk. Mund tĂ« lexoni mbi takimet tona nĂ« Timepad dhe tĂ« shikoni nĂ« YouTube.

NĂ«se dĂ«shiron tĂ« vish me njĂ« prezantim ose si dĂ«gjues — je i mirĂ«pritur, shkruaj nĂ« vadim.isakanov@gmail.com dhe nĂ« Telegram t.me/vadimisakanov.

Prezntimi im

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Slajdet

Zgjidhja "Bitrix në Kubernetes, versioni Southbridge 1.0"

Do të flas për zgjidhjen tonë në formatin "për fillestarët në Kubernetes", siç ishte bërë në takimin. Por supozoj që fjalët Bitrix, Docker, Kubernetes, Ceph të jenë të njohura për ju të paktën në nivelin e artikujve në Wikipedia.

ÇfarĂ« ka nĂ« dispozicion pĂ«r Bitrix nĂ« Kubernetes?

Në të gjithë internetin ka shumë pak informacion rreth funksionimit të aplikacioneve në Bitrix në Kubernetes.
Kam gjetur vetëm këto materiale:

Prezntimi i Aleksandër Serbulit, 1C-Bitrix dhe Anton Tuzlukov nga Qsoft:

Luaj videon

E rekomandoj ta dëgjoni atë.

Zhvillimi i një zgjidhjeje të vetme nga përdoruesi serkyron në Habrë.
Kam gjetur gjithashtu një zgjidhje të tillë.

Dhe, në thelb, kjo është e gjitha.

Kujtoj se nuk e kemi verifikuar cilĂ«sinĂ« e zgjidhjeve sipas lidhjeve mĂ« sipĂ«r 🙂
Për më tepër, gjatë përgatitjes së zgjidhjes tonë kam biseduar me Aleksandër Serbulin, atëherë referati i tij ende nuk ishte në dispozicion, prandaj në prezentimet e mia ka një pikë «Bitrix nuk përdor Kubernetes».

Sidoqoftë, tashmë ka shumë imazhe Docker të gatshme për të punuar me Bitrix në Docker: https://hub.docker.com/search?q=bitrix&type=image

A është e mjaftueshme kjo për të krijuar një zgjidhje të plotë për Bitrix në Kubernetes?
Jo. Ekzistojnë shumë probleme që duhet të zgjidhen.

Cilat janë problemet me Bitrix në Kubernetes?

E para — imazhet e gatshme nga Dockerhub nuk janĂ« tĂ« pĂ«rshtatshme pĂ«r Kubernetes

NĂ«se duam tĂ« ndĂ«rtojmĂ« njĂ« arkitekturĂ« mikroshĂ«rbimesh (dhe zakonisht e duam kĂ«tĂ« nĂ« Kubernetes), aplikacioni nĂ« Kubernetes duhet tĂ« ndahet nĂ« kontejnerĂ« dhe tĂ« sigurohemi qĂ« çdo kontejner tĂ« kryejĂ« njĂ« funksion tĂ« vogĂ«l (dhe ta bĂ«jĂ« atĂ« mirĂ«). Pse vetĂ«m njĂ«? NĂ«se flasim shkurt — sa mĂ« e thjeshtĂ«, aq mĂ« e besueshme.
NĂ«se do tĂ« donit mĂ« shumĂ« informacion — ju lutem shikoni kĂ«tĂ« artikull dhe video: https://habr.com/ru/company/southbridge/blog/426637/

Imazhet Docker në Dockerhub kryesisht janë ndërtuar sipas parimit «gjithçka në një», prandaj duhej të krijonim një rast të ri dhe madje të bënim imazhet nga fillimi.

E dyta — kodi i faqes rregullohet nga paneli i administratorit

Kemi krijuar një seksion të ri në faqen e internetit - është përmirësuar kodi (është shtuar një dosje me emrin e seksionit të ri).

Kemi ndryshuar cilësitë e komponentit nga paneli administrativ - kodi është ndryshuar.

Kubernetes «default» nuk di të punojë me këtë, kontejnerët duhet të jenë të papërmbajtur (Stateless).

Arsyeja: çdo kontejner (pod) në klaster trajton vetëm një pjesë të trafikut. Nëse ndryshoni kodin vetëm në një kontejner (pod), atëherë në pod-e të ndryshme kodi do të jetë ndryshe, faqja do të funksionojë ndryshe, përdoruesve të ndryshëm do t'u tregohen versione të ndryshme të faqes. Një jetë të tillë nuk e duam.

E treta - duhet të zgjidhim çështjen e shpërndarjes.

Nëse kemi një monolit dhe një server «klasik», gjithçka është shumë e thjeshtë: shpalosim një bazë të re kodi, kryejmë migrimin e DB, kalojmë trafikun në versionin e ri të kodit. Kalimi ndodh menjëherë.
Nëse kemi një faqe në Kubernetes, të ndarë në mikroshërbime, shumë kontejnerë me kod - oj. Duhet të ndërtojmë kontejnerë me versionin e ri të kodit, t'i lançojmë ato në vend të të vjetrave, të kryejmë migrimin e DB në mënyrë të duhur, dhe idealisht ta bëjmë këtë pa u vënë re nga vizitorët. Fatmirësisht, Kubernetes na ndihmon në këtë, duke mbështetur një mori të ndryshme llojesh shpërndarjeje.

E katĂ«rta — duhet tĂ« zgjidhni çështjen e ruajtjes sĂ« statikĂ«s

Nëse faqja juaj peshon "vetëm" 10 gigabajt dhe ju e vendosni atë tërësisht në konteinerë, do të merrni konteinerë me peshë 10 gigabajt, të cilët do të implementohen përjetësisht.
Duhet të ruani pjesët "më të rënda" të faqes jashtë konteinerëve, dhe lind pyetja se si ta bëni këtë siç duhet

ÇfarĂ« nuk ka nĂ« zgjidhjen tonĂ«

Të gjithë kodi i Bitrix nuk është ndarë në mikrofunksione/mikroshërbime (p.sh., regjistrimi veçmas, moduli i dyqanit online veçmas, etj.). E gjithë baza e kodit ruhet në çdo konteiner në tërësi.

Baza në Kubernetes gjithashtu nuk ruhen (unë megjithatë kam realizuar zgjidhje me bazën në Kubernetes për mjediset e zhvilluesve, por jo për prodhim).

Administratorëve të faqes do t'u bëhet e dukshme se faqja funksionon në Kubernetes. Funksioni "kontrolli i sistemit" nuk funksionon saktë, për të redaktuar kodin e faqes nga paneli i administratorit, së pari duhet të klikoni në butonin "dua të redaktoj kodin".

Problemet u zgjidhĂ«n, e pĂ«rcaktuam nevojĂ«n pĂ«r implementimin e mikrosĂ«rvices, qĂ«llimi Ă«shtĂ« i qartĂ« — tĂ« krijojmĂ« njĂ« sistem funksional pĂ«r aplikacionet nĂ« Bitrix nĂ« Kubernetes, duke ruajtur mundĂ«sitĂ« e Bitrix dhe pĂ«rfitimet e Kubernetes. TĂ« fillojmĂ« realizimin.

Arkitektura

Shumë pod të 'punës' me server web (punëtorë).
Një pod me detyrat e kront (domosdoshmërisht vetëm një).
Një upgrade pod për redaktimin e kodit të faqes nga paneli i administrimit (po ashtu domosdoshmërisht vetëm një).

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Po zgjidhim çështjet:

  • Ku do tĂ« ruhen sesionet?
  • Ku do tĂ« ruhet cache?
  • Ku do tĂ« ruhet statika, nuk mund tĂ« vendosim gigabajt statike nĂ« njĂ« grumbull kontejnerĂ«sh?
  • Si do tĂ« funksionojĂ« baza e tĂ« dhĂ«nave?

Docker image

Fillojmë me ndërtimin e Docker image-it.

Varianti ideal — kemi njĂ« imazh universale, mbi tĂ« cilin krijojmĂ« dhe pod punĂ«torĂ«sh, dhe pod me detyrat e kront, dhe pod upgrade.

Ne bëjmë një imazh të tillë..

Ai përfshin nginx, apache/php-fpm (mund të zgjidhet gjatë ndërtimit), msmtp për dërgimin e postës, dhe cron.

Gjatë ndërtimit të imazhit, baza e plotë e kodit të faqes kopjohet në direktorinë /app (përveç atyre pjesëve që do t'i nxjerrim në një ruajtje të veçantë të përbashkët).

Mikrosërvices, shërbime

pod punëtorësh:

  • Kontejner me nginx + konteiner apache/php-fpm + msmtp
  • Nuk arritĂ«m ta nxjerrim msmtp si njĂ« mikroshĂ«rbim tĂ« veçantĂ«, Bitrix fillon tĂ« protestojĂ« qĂ« nuk mund tĂ« dĂ«rgojĂ« email direkt.
  • NĂ« çdo enĂ« Ă«shtĂ« baza e plotĂ« e kodit.
  • Ndalohet ndryshimi i kodit nĂ« enĂ«t.

cron nën:

  • enĂ« me apache, php, cron
  • vjen me bazĂ«n e plotĂ« tĂ« kodit
  • ndalohet ndryshimi i kodit nĂ« enĂ«t

upgrade nën:

  • enĂ« me nginx + enĂ« apache/php-fpm + msmtp
  • nuk ka ndalim pĂ«r ndryshimin e kodit nĂ« enĂ«t

depozita e sesioneve

depozita e caches për Bitrix

E rëndësishme gjithashtu: fjalëkalimet për lidhje me gjithçka, nga databaza deri te emaili, i ruajmë në sekrete të kubernetes. Marrim një përfitim, fjalëkalimet duken vetëm për ata që i japim qasje sekreteve, e jo për të gjithë ata që kanë qasje në bazën e kodit të projektit.

depozita për statikën

Mund të përdorni çfarëdo: ceph, nfs (por nuk e rekomandojmë për prodhim), ruajtje në rrjet nga ofruesit "cloud", etj.

Depozita duhet të lidhet në enët në direktorinë /upload/ të faqes dhe drejtoritë e tjera me statikën.

Baza e të dhënave

Për thjeshtësi, rekomandojmë të nxjerrim databazën jashtë Kubernetes. Databaza në Kubernetes është një detyrë komplekse, ajo do ta bëjë skemën shumë më të komplikuar.

depozita e sesioneve

PĂ«rdorim memcached 🙂

Ai menaxhon mirë ruajtjen e seancave, është e grumbulluar, mbështetet "nativisht" si session.save_path në php. Ky sistem është testuar shumë herë edhe në arkitekturën klasike monolite, kur ndërtuam klastere me numër të madh serverash web. Ne përdorim helm për shpërndarje.

$ helm install stable/memcached --name session

php.ini — kĂ«tu nĂ« imazh janĂ« vendosur cilĂ«simet pĂ«r ruajtjen e seancave nĂ« memcached

Ne kemi përdorur Environment Variables për të kaluar të dhënat mbi hostet me memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Kjo lejon përdorimin e të njëjtit kod në ambientet dev, stage, test, prod (emrat e hosteve memcached në to do të ndryshojnë, prandaj në çdo ambient ne duhet të kalojmë emra unikë hostesh për seancat).
Ruajtja e caches Bitrix

Na nevojitet një ruajtje rezistente ndaj gabimeve, në të cilën të gjithë pods të mund të shkrijnë dhe të lexojnë.

Po ashtu përdorim memcached.
Ky zgjidhje rekomandohet nga vetë Bitrix.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php — kĂ«tu nĂ« Bitrix pĂ«rcaktohet se ku ruhet cache

Po ashtu përdorim Environment Variables.

Kron Tasks

Ka qasje të ndryshme për ekzekutimin e krontaskave në Kubernetes.

  • ndarĂ« deployment me pod pĂ«r ekzekutimin e krontaskave
  • cronjob pĂ«r tĂ« ekzekutuar krontaskat (nĂ«se kjo Ă«shtĂ« njĂ« aplikacion web — me wget https://$host$cronjobname, ose kubectl exec brenda njĂ«rit nga pod-et punues, etj.)
  • etc.

Mund të diskutohet për më të saktin, por në këtë rast ne zgjodhëm variantin "deploy i veçantë me pod-e për krontaskat"

Si është bërë kjo:

  • krontaskat i shtojmĂ« pĂ«rmes ConfigMap ose pĂ«rmes skedarit config/addcron
  • nĂ« njĂ« ekzemplar ekzekutojmĂ« kontejnerin, identik me pod-in punues + lejojmĂ« ekzekutimin e krontaskave nĂ« tĂ«
  • pĂ«rdoret e njĂ«jta bazĂ« kodi, falĂ« unifikimit ndĂ«rtimi i kontejnerit Ă«shtĂ« i thjeshtĂ«

ÇfarĂ« mirĂ«sie marrim:

  • kemi krontaska funksionale nĂ« njĂ« ambient, identik me ambientin e zhvilluesve (docker)
  • krontaskat nuk kanĂ« nevojĂ« tĂ« "rishkruhen" pĂ«r Kubernetes, ato funksionojnĂ« nĂ« tĂ« njĂ«jtĂ«n formĂ« dhe me tĂ« njĂ«jtin bazĂ« kodi, si mĂ« parĂ«
  • krontaskat mund t’i shtojnĂ« tĂ« gjithĂ« anĂ«tarĂ«t e ekipit me tĂ« drejta commit nĂ« degĂ«n production, dhe jo vetĂ«m administratorĂ«t

Moduli Southbridge K8SDeploy dhe redaktimi i kodit nga paneli i administratës

Sepse ne folëm për upgrade-in e pod-it?
Si ta drejtojmë aty trafikun?
Hurra, ne shkruam njĂ« modul pĂ«r kĂ«tĂ« nĂ« php 🙂 Kjo Ă«shtĂ« njĂ« modul klasik i vogĂ«l pĂ«r Bitrix. Nuk Ă«shtĂ« ende nĂ« akses tĂ« hapur, por ne planifikojmĂ« ta hapim.
Moduli instalohet si një modul standard në Bitrix:

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Dhe duket kështu:

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Ai lejon të vendoset një cookie, e cila identifikon administratorin e faqes dhe lejon Kubernetes të dërgojë trafik në upgrade pod.

Pasi të përfundojnë ndryshimet, duhet të klikoni git push, ndryshimet në kod do të dërgohen në git, pastaj sistemi do të ndërtojë një imazh me versionin e ri të kodit dhe do ta "shpërndajë" atë në klaster, duke zëvendësuar pod-et e vjetra.

Po, disi me pengesa, por me këtë ne ruajmë arkitekturën mikroshërbimi dhe nuk e heqim nga përdoruesit e Bitrix mundësinë e preferuar për të modifikuar kodin nga admin paneli. Fundja, kjo është një mundësi, mund ta zgjidhni detyrën e modifikimit të kodit ndryshe.

Helm chart

Për ndërtimin e aplikacioneve në Kubernetes, zakonisht përdorim menaxherin e paketave Helm.
Për zgjidhjen tonë Bitrix në Kubernetes, Sergey Bondarev, administratori ynë kryesor i sistemeve, shkroi një Helm chart të veçantë.

Ai ndihmon në ndërtimin e pod-eve worker, upgrade, cron, konfigurimin e ingress-ëve, shërbimeve, dhe kalon variabla nga Kubernetes secrets në pod-e.

Kodet i ruajmë në Gitlab, dhe ndërtimin e Helm gjithashtu e nisim nga Gitlab.

Nëse e shikoni shkurt, duket kështu

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

Helm gjithashtu lejon rikthim «pa ndihmĂ«s» nĂ«se ndodhi ndonjĂ« problem gjatĂ« shpĂ«rndarjes. ËshtĂ« e kĂ«ndshme kur nuk jeni nĂ« panic duke «korrigjuar kodin pĂ«rmes FTP-sĂ« qĂ« prodhimi Ă«shtĂ« ndalur», ndĂ«rsa Kubernetes e bĂ«n kĂ«tĂ« automatikisht, pa ndonjĂ« ndalim.

DĂ«rgo

Po, ne jemi fanatikĂ« tĂ« Gitlab & Gitlab CI, e pĂ«rdorim 🙂
Kur bëni një commit në Gitlab, depozitimi i projektit aktivizon një pipeline në Gitlab që realizon shpërndarjen e versionit të ri të mjedisit.

Hapat:

  • build (krijojmĂ« imazhin e ri Docker)
  • test (testojmĂ«)
  • clean up (heqim mjedisin e testimit)
  • push (e dĂ«rgojmĂ« nĂ« Docker registry)
  • deploy (shpĂ«rndajmĂ« aplikacionin nĂ« Kubernetes pĂ«rmes Helm).

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Hurrah, e gatshme, e implementojmë!
Ose bëjmë pyetje, nëse ka.

Pra, çfarë kemi bërë

Nga një pikëpamje teknike:

  • dockerizuam Bitrix;
  • «prishĂ«m» Bitrix nĂ« konteinerĂ«, secili nga tĂ« cilĂ«t kryen funksione minimale;
  • arritĂ«m njĂ« gjendje stateless pĂ«r konteinerĂ«t;
  • zgjidhĂ«m problemin e pĂ«rditĂ«simit tĂ« Bitrix nĂ« Kubernetes;
  • tĂ« gjitha funksionet e Bitrix vazhduan tĂ« punojnĂ« (pothuajse tĂ« gjitha);
  • punuam shpĂ«rndarjen nĂ« Kubernetes dhe rikthimin midis versioneve.

Nga një pikëpamje biznesi:

  • qĂ«ndrueshmĂ«ri;
  • instrumentat Kubernetes (integrim i thjeshtĂ« me Gitlab CI, shpĂ«rndarje pa ndĂ«rlikime, etj);
  • fjalĂ«kalimet nĂ« sekretet (shihen vetĂ«m nga ata qĂ« janĂ« drejtpĂ«rdrejt tĂ« autorizuar pĂ«r fjalĂ«kalimet);
  • Ă«shtĂ« lehtĂ« tĂ« bĂ«sh ambiente shtesĂ« (pĂ«r zhvillim, teste dhe tĂ« tjera) brenda infrastrukturĂ«s sĂ« vetme.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster