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

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Në Chelyabinsk po mbahet takimi i administratorëve të sistemeve Sysadminka, dhe në takimin e fundit unë mbajta një ligjëratë rreth zgjidhjes sonë për funksionimin e aplikacioneve në 1C-Bitrix në Kubernetes.

Bitrix, Kubernetes, Ceph — njĂ« kombinim i shkĂ«lqyer?

Do t'ju tregoj se si ne e ndërtuam një zgjidhje funksionale nga e gjithë kjo.

Le të shkojmë!

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Takimi u mbajt më 18 prill në Chelyabinsk. Mund të lexoni për takimet tona në Timepad dhe t'i shihni ato në YouTube.

NĂ«se dĂ«shirani tĂ« vini me njĂ« ligjĂ«ratĂ« ose si dĂ«gjues — jeni tĂ« mirĂ«pritur, shkruani nĂ« vadim.isakanov@gmail.com dhe nĂ« Telegram t.me/vadimisakanov.

Ligjërata ime

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Slida

Zgjidhja «Bitrix në Kubernetes, versioni Southbridge 1.0»

Do flas për zgjidhjen tonë në formatin «për fillestarët në Kubernetes», si është bërë në takim. Por supozitë se fjalët Bitrix, Docker, Kubernetes, Ceph janë të njohura për ju të paktën në nivelin e artikujve në Wikipedia.

ÇfarĂ« informacioni ekziston rreth Bitrix nĂ« Kubernetes?

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

Ligjërata e Aleksandrit Serbul dhe Anton Tuzlukov nga Qsoft:

Luaj videon

E rekomandoj të dëgjoni atë.

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

Dhe
 nĂ« thelb, kjo Ă«shtĂ« gjithçka.

Ju paralajmĂ«roj, nuk e kemi verifikuar cilĂ«sinĂ« e zgjidhjeve nĂ« lidhjet e mĂ«sipĂ«rme 🙂
Për më tepër, gjatë përgatitjes së zgjidhjes sonë kam komunikuar me Aleksandrin Serbul, ligjërata e tij nuk ishte ende publikuar, kështu që në slajdet e mia ka një pikë «Bitrix nuk përdor Kubernetes».

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

A është e mjaftueshme kjo për të ndërtuar një zgjidhje të plotë për Bitrix në Kubernetes?
Jo. Ka një numër të madh problemesh që duhet të zgjidhen.

Cilat janë problemet me Bitrix në Kubernetes?

E para — imazhet e gatshme nga Dockerhub nuk i pĂ«rshtaten Kubernetes

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

Imazhet e Docker në Dockerhub në përgjithësi janë ndërtuar sipas parimit «të gjitha në një», prandaj na duhej të bënim një biçikletë tonë dhe madje të krijonim imazhe nga e para.

E dyta — kodi i sitit rregullohet nga paneli i adminit

Krijuam një seksion të ri në sajt - kodi është përditësuar (u shtua një direktor i quajtur si seksioni i ri).

Ndryshuam pronësitë e komponentit nga paneli i administratës - kodi është ndryshuar.

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

Arsyetimi: secili kontejner (pod) në klaster përpunon vetëm një pjesë të trafikut. Nëse ndryshoni kodin vetëm në një kontejner (pod), atëherë kode të ndryshme do të jenë në pod-e të ndryshëm, sajt do të funksionojë ndryshe, përdorues të ndryshëm do t'u shfaqen versione të ndryshme të sajtit. Kështu nuk është e mundur të vazhdohet.

E treta - nevojitet të zgjidhet çështja e deploy-it.

Nëse kemi një monolit dhe një server «klasik», gjithçka është shumë e thjeshtë: zbatojmë një bazë të re kodi, kryejmë migrimin e DB, drejtojmë trafikun në versionin e ri të kodit. Kalimi ndodh menjëherë.
Nëse kemi një sajt në Kubernetes, të shpërndarë në mikroshërbime, ka shumë kontejnerë me kod - oj. Duhet të mbledhim kontejnerët me versionin e ri të kodit, ti zëvendësojmë ata me të vjetrët, të kryejmë migrimin e DB saktë, dhe idealisht ta bëjmë këtë pa i vënë re vizitorëve. Fatmirësisht, Kubernetes na ndihmon me këtë, duke mbështetur një sërë llojshmërish të ndryshme të deploy-it.

E katërta - duhet të zgjidhet çështja e ruajtjes së statikës.

Nëse saiti juaj peshon «vetëm» 10 gigabajt dhe ju e implementoni atë krejtësisht në kontejnerë, do të merrni kontejnerë pesha 10 gigabajt, të cilët do të implementohen për një kohë të gjatë.
Duhet të ruajmë pjesët më «të mëdha» të sajtit jashtë kontejnerëve, dhe lind pyetja, si të bëjmë këtë saktësisht.

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

Të gjithë kodi Bitrix nuk është prerë në mikrofunksione/mikroshërbime (në mënyrë që regjistrimi të jetë veçmas, moduli i dyqanit të internetit veçmas, etj.). Ne ruajmë tërë bazën e kodit në çdo kontejner në mënyrë të plotë.

Ne gjithashtu nuk ruajmë bazën e të dhënave në Kubernetes (kalim, unë gjithmonë kam implementuar zgjidhje me bazën e të dhënave në Kubernetes për mjediset e zhvilluesve, por jo për prodhim).

Administratorët e sajtit gjithsesi do ta ndjejnë se saiti funksionon në Kubernetes. Funksioni «kontrolli i sistemit» punon në mënyrë të parregullt, për të redaktuar kodin e saj do të duhet së pari të shtypni butonin «dua të redaktoj kodin».

Kemi pĂ«rballur me problemet, kemi rĂ«nĂ« dakord pĂ«r nevojĂ«n pĂ«r implementimin e mikroshĂ«rbimeve, dhe qĂ«llimi Ă«shtĂ« i qartĂ« — tĂ« kemi njĂ« sistem funksional pĂ«r punĂ«n e aplikacioneve nĂ« Bitrix nĂ« Kubernetes, duke ruajtur mundĂ«sitĂ« e Bitrix dhe avantazhet e Kubernetes. FillojmĂ« implementimin.

Arkitektura

Shumë pod'esh 'punues' me serverin web (punëtorë).
Një pod me detyra cron (absolutisht vetëm një).
Një pod upgrade për redaktimin e kodit të faqes nga paneli administrativ (po ashtu, absolutisht vetëm një).

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Po zgjidhim pyetje:

  • Ku tĂ« ruhen sesionet?
  • Ku tĂ« ruhet cache?
  • Ku tĂ« ruhet statika, a nuk Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« vendosim gigabajtĂ« e statikĂ«s nĂ« shumĂ« kontejnerĂ«?
  • Si do tĂ« funksionojĂ« baza e tĂ« dhĂ«nave?

Docker image

Fillojmë me ndërtimin e imazhit Docker.

Zgjedhja ideale — kemi njĂ« imazh universale, mbi tĂ« cilin marrim pod'esh punues, pod'esh me detyra cron dhe pod'esh upgrade.

Ne bëmë 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.

NĂ« ndĂ«rtimin e imazhit, e gjithĂ« baza e kodit tĂ« faqes kopjohet nĂ« direktorinĂ« /app (pĂ«rveç atyre pjesĂ«ve qĂ« ne do t’i nxjerrim nĂ« njĂ« depo tĂ« ndarĂ«).

Mikroshërbim, shërbime

pod'esh punues:

  • Kontejner me nginx + kontejner apache/php-fpm + msmtp
  • Nuk arritĂ«m ta nxjerrim msmtp nĂ« njĂ« mikroshĂ«rbim tĂ« veçantĂ«, Bitrix fillon tĂ« ankohen qĂ« nuk mund tĂ« dĂ«rgojĂ« postĂ« direkt.
  • NĂ« secilin konteiner Ă«shtĂ« e gjithĂ« baza e kodit.
  • Ndalim pĂ«r ndryshimin e kodit nĂ« kontejnerĂ«.

pod cron:

  • kontejner me apache, php, cron
  • nĂ« paketĂ« Ă«shtĂ« e gjithĂ« baza e kodit
  • ndalim pĂ«r ndryshimin e kodit nĂ« kontejnerĂ«

pod upgrade:

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

depo sesionesh

depo cache i Bitrix

Gjithashtu është e rëndësishme: fjalëkalimet për t'u lidhur me gjithçka, nga baza e të dhënave deri te posta, i ruajmë në sekrete kubernetes. Marrim një bonus, fjalëkalimet janë të dukshme vetëm për ata që u japim qasje sekreteve, dhe jo për të gjithë ata që kanë qasje në bazën e kodit të projektit.

depo për statikën

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

Depoja duhet të lidhet në kontejnerë në direktorinë /upload/ të faqes dhe drejtime të tjera me statikën.

Baza e të dhënave

PĂ«r thjeshtĂ«si, ne rekomandojmĂ« qĂ« baza tĂ« nxirret jashtĂ« Kubernetes. Baza nĂ« Kubernetes — njĂ« detyrĂ« e ndĂ«rlikuar e veçantĂ«, do ta bĂ«jĂ« skemĂ«n ndjeshĂ«m mĂ« tĂ« komplikuar.

depo sesionesh

PĂ«rdorim memcached 🙂

Ai merr një menaxhim të mirë për ruajtjen e sesioneve, është i klasterizuar dhe mbështetet "natyrshëm" si session.save_path në php. Ky sistem është testuar shumë herë në arkitekturën klasike monolitike, kur ne krijonim klastere me numër të madh serverash web. Ne përdorim helm për aktivizimin.

$ helm install stable/memcached --name session

php.ini — kĂ«tu nĂ« imazhin janĂ« vendosur konfigurimet pĂ«r ruajtjen e sesioneve nĂ« memcached

Ne përdorëm Environment Variables për të kaluar të dhëna 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ë jenë të ndryshëm, kështu që për çdo ambient ne duhet të kalojmë emra unikë hostesh për sesionet).
Kostak i cache Bitrix

Na nevojitet një ruajtje e qëndrueshme, në të cilën të gjithë podet mund të shkruajnë dhe të lexojnë.

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

$ helm install stable/memcached --name cache

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

Po ashtu përdorim Environment Variables.

Kron-taske

Ka qasje të ndryshme për ekzekutimin e kron-taskëve në Kubernetes.

  • njĂ« aktivizim tĂ« veçantĂ« me pod pĂ«r ekzekutimin e kron-taskĂ«ve
  • cronjob pĂ«r ekzekutimin e kron-taskĂ«ve (nĂ«se Ă«shtĂ« web app — me wget https://$host$cronjobname, ose kubectl exec brenda njĂ« prej podĂ«ve punĂ«torĂ«, etj.)
  • et cetera

Mund të diskutohet për opsionin më të saktë, por në këtë rast ne zgjodhëm variantin "aktivizim të veçantë me pod për kron-taskët"

Si është bërë:

  • kron-taskĂ«t i shtojmĂ« pĂ«rmes ConfigMap ose pĂ«rmes skedarit config/addcron
  • nĂ« njĂ« kopje ekzekutojmĂ« kontejnerin, tĂ« njĂ«jtĂ« me podin punĂ«tor + lejojmĂ« ekzekutimin e kron-taskĂ«ve nĂ« tĂ«
  • pĂ«rdoret e njĂ«jta bazĂ« kodimi, falĂ« unifikimit ndĂ«rtimi i kontejnerit Ă«shtĂ« i thjeshtĂ«

ÇfarĂ« pĂ«rfitimi kemi:

  • kemi kron-taskĂ« tĂ« punuara nĂ« njĂ« ambient, tĂ« njĂ«jtĂ« me ambientin e zhvilluesve (docker)
  • kron-taskĂ«t nuk kanĂ« nevojĂ« tĂ« "rishkruhen" pĂ«r Kubernetes, ato punojnĂ« nĂ« tĂ« njĂ«jtin format dhe nĂ« tĂ« njĂ«jtĂ«n bazĂ« kodi si mĂ« parĂ«
  • kron-taskĂ«t mund tĂ« shtohen nga tĂ« gjithĂ« anĂ«tarĂ«t e ekipit me tĂ« drejta commit nĂ« degĂ«n prodhuese, jo vetĂ«m nga administratorĂ«t

Moduli Southbridge K8SDeploy dhe redaktimi i kodit nga paneli administrativ

Po folëm për përmirësimin e pod?
Si ta drejtojmë trafikun atje?
Ura, ne shkruam njĂ« modul pĂ«r kĂ«tĂ« nĂ« php 🙂 Ky Ă«shtĂ« njĂ« modul klasik pĂ«r Bitrix. Ai ende nuk Ă«shtĂ« nĂ« dispozitĂ« publike, por ne planifikojmĂ« ta hapim.
Moduli instalohet si një modul i zakonshëm në Bitrix:

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Dhe duket kështu:

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

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

Kur ndryshimet të përfundojnë, duhet të shtypni git push, ndryshimet e kodit do të dërgohen në git, pastaj sistemi do të ndërtojnë një imazh me versionin e ri të kodit dhe do ta shpërndajë atë në klaster, duke zëvendësuar pod-at e vjetër.

Po, ndoshta disa gjëra janë disi të komplikuara, por kështu ne ruajmë arkitekturën mikroshërbimeve dhe nuk privojmë përdoruesit e Bitrix nga mundësia e tyre të modifikojnë kodin nga paneli i administratës. Pas të gjitha, kjo është një mundësi, mund ta zgjidhni problemin 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ë të Bitrix në Kubernetes, Sergey Bondarev, administratori ynë kryesor i sistemeve, shkroi një Helm chart të veçantë.

Ai kryen ndërtimin e worker, upgrade, cron pod-ëve, konfigurimin e ingress-ëve, shërbimeve, dhe transmeton variablat nga Kubernetes secrets në pod-ët.

Ne e ruajmë kodin në Gitlab, dhe gjithashtu fillojmë ndërtimin e Helm nga Gitlab.

Në përgjithësi, kjo 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 tĂ« bĂ«ni njĂ« "rollback" pa ndĂ«rprerje, nĂ«se ndodhi ndonjĂ« problem gjatĂ« deploy-it. ËshtĂ« e kĂ«ndshme kur nuk jeni nĂ« panik "duke riparuar kodin me ftp sepse prodhimi ka rĂ«nĂ«", por Kubernetes e bĂ«n atĂ« automatikisht, dhe pa ndalese.

Deploy

Po, ne jemi adhurues tĂ« Gitlab & Gitlab CI, e pĂ«rdorim 🙂
Në momentin e commit-it në Gitlab në repositorin e projektit, Gitlab nis një pipeline që kryen shpërndarjen e versionit të ri të ambientit.

Hapat:

  • build (ndĂ«rtojmĂ« imazhin e ri Docker)
  • test (testojmĂ«)
  • clean up (pastroni ambientin e testimit)
  • push (e dĂ«rgojmĂ« atĂ« nĂ« Docker registry)
  • deploy (shpĂ«rndajmĂ« aplikacionin nĂ« Kubernetes pĂ«rmes Helm).

Southbridge në Chelyabinsk dhe Bitrix në Kubernetes

Ura, gati, e zbatojmë!
Ose, bëjmë pyetje nëse ka.

E pra, çfarë bëmë

Nga këndi teknik:

  • Dockerizuam Bitrix;
  • "e copĂ«tuam" Bitrix nĂ« kontejnerĂ«, secili prej tĂ« cilĂ«ve kryen funksione minimale;
  • arritĂ«m njĂ« gjendje stateless tĂ« kontejnerĂ«ve;
  • zgjidhĂ«m problemin e azhurnimit tĂ« Bitrix nĂ« Kubernetes;
  • tĂ« gjitha funksionet e Bitrix vazhduan tĂ« punojnĂ« (pothuajse tĂ« gjitha);
  • ka kaluar pĂ«rmes deploy-it nĂ« Kubernetes dhe rollback-it ndĂ«rmjet versioneve.

Nga këndi i biznesit:

  • rezistencĂ« ndaj gabimeve;
  • mjetet e Kubernetes (integrimi i thjeshtĂ« me Gitlab CI, deploy pa ndĂ«rprerje, etj);
  • fjalĂ«kalimet nĂ« sekrete (shihen vetĂ«m nga ata tĂ« cilĂ«ve u Ă«shtĂ« dhĂ«nĂ« qasje e drejtpĂ«rdrejtĂ« nĂ« fjalĂ«kalime);
  • Ă«shtĂ« e lehtĂ« tĂ« krijosh ambientet shtesĂ« (pĂ«r zhvillim, teste etj.) brenda infrastrukturĂ«s sĂ« vetme.

Burimi: habr.com

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