Mae cyfarfodydd gweinyddwr system Sysadminka yn cael eu cynnal yn Chelyabinsk, ac yn yr un olaf rhoddais adroddiad ar ein datrysiad ar gyfer rhedeg cymwysiadau ar 1C-Bitrix yn Kubernetes.
Bitrix, Kubernetes, Ceph - cymysgedd gwych?
Dywedaf wrthych sut yr ydym wedi llunio datrysiad gweithio o hyn i gyd.
Gadewch i ni fynd!
Cynhaliwyd y cyfarfod ar Ebrill 18 yn Chelyabinsk. Gallwch ddarllen am ein cyfarfodydd yn ac edrych ar .
Os ydych am ddod atom gydag adroddiad neu fel gwrandäwr - croeso, ysgrifennwch at [e-bost wedi'i warchod] ac ar Telegram t.me/vadimisakanov.
Fy adroddiad
Ateb "Bitrix in Kubernetes, fersiwn Southbridge 1.0"
Byddaf yn siarad am ein datrysiad yn y fformat “ar gyfer dymis yn Kubernetes”, fel y gwnaed yn y cyfarfod. Ond dwi'n cymryd eich bod chi'n gwybod y geiriau Bitrix, Docker, Kubernetes, Ceph o leiaf ar lefel erthyglau ar Wicipedia.
Beth sy'n barod am Bitrix yn Kubernetes?
Ychydig iawn o wybodaeth sydd ar y Rhyngrwyd cyfan am weithrediad cymwysiadau Bitrix yn Kubernetes.
Dim ond y deunyddiau hyn wnes i ddod o hyd i:
Adroddiad gan Alexander Serbul, 1C-Bitrix, ac Anton Tuzlukov gan Qsoft:
Rwy'n argymell gwrando arno.
Datblygu eich datrysiad eich hun gan y defnyddiwr .
Wedi dod o hyd i fwy .
Aaa... mewn gwirionedd, dyna i gyd.
Rwy'n eich rhybuddio, nid ydym wedi gwirio ansawdd yr atebion yn y dolenni uchod :)
Gyda llaw, wrth baratoi ein datrysiad, siaradais ag Alexander Serbul, yna nid oedd ei adroddiad wedi ymddangos eto, felly yn fy sleidiau mae eitem “Nid yw Bitrix yn defnyddio Kubernetes.”
Ond mae yna lawer o ddelweddau Docker parod eisoes ar gyfer rhedeg Bitrix yn Docker:
A yw hyn yn ddigon i greu datrysiad cyflawn ar gyfer Bitrix yn Kubernetes?
Nac ydw. Mae yna nifer fawr o broblemau y mae angen eu datrys.
Beth yw'r problemau gyda Bitrix yn Kubernetes?
Yn gyntaf, nid yw delweddau parod o Dockerhub yn addas ar gyfer Kubernetes
Os ydym am adeiladu pensaernïaeth microservices (ac yn Kubernetes rydym fel arfer yn ei wneud), mae angen i ni wahanu ein cymhwysiad Kubernetes yn gynwysyddion a chael pob cynhwysydd i gyflawni un swyddogaeth fach (a'i wneud yn dda). Pam dim ond un? Yn fyr, y symlaf y mwyaf dibynadwy.
I fod yn fwy penodol, gwyliwch yr erthygl a'r fideo hwn, os gwelwch yn dda:
Mae delweddau docwyr yn Dockerhub wedi'u hadeiladu'n bennaf ar yr egwyddor popeth-mewn-un, felly roedd yn rhaid i ni wneud ein beic ein hunain a hyd yn oed greu delweddau o'r dechrau.
Yn ail - mae cod y wefan yn cael ei olygu o'r panel gweinyddol
Fe wnaethon ni greu adran newydd ar y safle - cafodd y cod ei ddiweddaru (ychwanegwyd cyfeiriadur gydag enw'r adran newydd).
Os gwnaethoch newid priodweddau cydran o'r panel gweinyddol, newidiodd y cod.
Ni all Kubernetes “yn ddiofyn” weithio gyda hyn; rhaid i gynwysyddion fod yn ddi-wladwriaeth.
Rheswm: Mae pob cynhwysydd (pod) yn y clwstwr yn prosesu cyfran o'r traffig yn unig. Os byddwch chi'n newid y cod mewn un cynhwysydd yn unig (pod), yna bydd y cod yn wahanol mewn gwahanol godiau, bydd y wefan yn gweithio'n wahanol, a bydd gwahanol fersiynau o'r wefan yn cael eu dangos i wahanol ddefnyddwyr. Ni allwch fyw felly.
Trydydd - mae angen i chi ddatrys y mater gyda defnyddio
Os oes gennym ni monolith ac un gweinydd “clasurol”, mae popeth yn eithaf syml: rydyn ni'n defnyddio sylfaen cod newydd, yn mudo'r gronfa ddata, yn newid traffig i'r fersiwn newydd o'r cod. Mae newid yn digwydd ar unwaith.
Os oes gennym wefan yn Kubernetes, wedi'i dorri'n ficrowasanaethau, mae yna lawer o gynwysyddion gyda chod - o. Mae angen i chi gasglu cynwysyddion gyda fersiwn newydd o'r cod, eu cyflwyno yn lle'r hen rai, mudo'r gronfa ddata yn gywir, ac yn ddelfrydol yn gwneud hyn heb i ymwelwyr sylwi. Yn ffodus, mae Kubernetes yn ein helpu gyda hyn, gan gefnogi criw cyfan o wahanol fathau o leoliadau.
Pedwerydd - mae angen i chi ddatrys y mater o storio statig
Os mai 10 gigabeit “yn unig” yw eich gwefan a'ch bod yn ei ddefnyddio'n gyfan gwbl mewn cynwysyddion, bydd gennych chi 10 o gynwysyddion gigabyte yn y pen draw sy'n cymryd am byth i'w defnyddio.
Mae angen i chi storio'r rhannau “trwmaf” o'r safle y tu allan i gynwysyddion, ac mae'r cwestiwn yn codi sut i wneud hyn yn gywir
Beth sydd ar goll o'n datrysiad?
Nid yw'r cod Bitrix cyfan wedi'i rannu'n ficro-swyddogaethau / microwasanaethau (fel bod y cofrestriad ar wahân, mae'r modiwl siop ar-lein ar wahân, ac ati). Rydym yn storio'r sylfaen cod cyfan ym mhob cynhwysydd.
Nid ydym hefyd yn storio'r gronfa ddata yn Kubernetes (rwyf yn dal i weithredu atebion gyda chronfa ddata yn Kubernetes ar gyfer amgylcheddau datblygu, ond nid ar gyfer cynhyrchu).
Bydd yn dal i fod yn amlwg i weinyddwyr y wefan bod y wefan yn rhedeg ar Kubernetes. Nid yw'r swyddogaeth “gwirio system” yn gweithio'n gywir; i olygu cod y wefan o'r panel gweinyddol, yn gyntaf rhaid i chi glicio ar y botwm “Rwyf am olygu'r cod”.
Mae'r problemau wedi'u nodi, mae'r angen i weithredu microwasanaethau wedi'i bennu, mae'r nod yn glir - cael system weithredol ar gyfer rhedeg cymwysiadau ar Bitrix yn Kubernetes, gan gadw galluoedd Bitrix a manteision Kubernetes. Gadewch i ni ddechrau gweithredu.
pensaernïaeth
Mae yna lawer o godau “gweithio” gyda gweinydd gwe (gweithwyr).
Un o dan gyda thasgau cron (dim ond un sydd ei angen).
Un uwchraddiad ar gyfer golygu cod y wefan o'r panel gweinyddol (dim ond un sydd ei angen hefyd).
Rydym yn datrys cwestiynau:
- Ble i storio sesiynau?
- Ble i storio'r storfa?
- Ble i storio statig, nid i osod gigabeit o statigau mewn criw o gynwysyddion?
- Sut bydd y gronfa ddata yn gweithio?
Delwedd docwr
Dechreuwn trwy adeiladu delwedd Docker.
Yr opsiwn delfrydol yw bod gennym un ddelwedd gyffredinol, ar ei sail rydym yn cael codennau gweithwyr, codennau gyda Crontasks, a phodiau uwchraddio.
.
Mae'n cynnwys nginx, apache / php-fpm (gellir ei ddewis yn ystod adeiladu), msmtp ar gyfer anfon post, a cron.
Wrth gydosod y ddelwedd, mae sylfaen cod cyfan y wefan yn cael ei chopïo i'r cyfeiriadur / app (ac eithrio'r rhannau hynny y byddwn yn eu symud i storfa a rennir ar wahân).
Microwasanaethau, gwasanaethau
codennau gweithwyr:
- Cynhwysydd gyda nginx + cynhwysydd apache/php-fpm + msmtp
- Ni weithiodd allan i symud msmtp i mewn i ficrowasanaeth ar wahân, mae Bitrix yn dechrau mynd yn ddig na all anfon post yn uniongyrchol
- Mae gan bob cynhwysydd sylfaen god gyflawn.
- Gwahardd newid cod mewn cynwysyddion.
cron o dan:
- cynhwysydd gydag apache, php, cron
- sylfaen cod cyflawn wedi'i chynnwys
- gwaharddiad ar newid cod mewn cynwysyddion
uwchraddio o dan:
- nginx cynhwysydd + apache/php-fpm cynhwysydd + msmtp
- Nid oes unrhyw waharddiad ar newid cod mewn cynwysyddion
storfa sesiwn
Storio storfa Bitrix
Peth pwysig arall: rydym yn storio cyfrineiriau ar gyfer cysylltu â phopeth, o'r gronfa ddata i'r post, mewn cyfrinachau kubernetes. Rydyn ni'n cael bonws: dim ond i'r rhai rydyn ni'n rhoi mynediad i'r cyfrinachau iddyn nhw y mae cyfrineiriau'n weladwy, ac nid i bawb sydd â mynediad i sylfaen cod y prosiect.
Storio ar gyfer statig
Gallwch ddefnyddio unrhyw beth: ceph, nfs (ond nid ydym yn argymell nfs ar gyfer cynhyrchu), storfa rhwydwaith gan ddarparwyr cwmwl, ac ati.
Bydd angen cysylltu'r storfa mewn cynwysyddion â chyfeiriadur / uwchlwytho / y wefan a chyfeiriaduron eraill gyda chynnwys statig.
Cronfa Ddata
Er mwyn symlrwydd, rydym yn argymell symud y gronfa ddata y tu allan i Kubernetes. Mae'r ganolfan yn Kubernetes yn dasg gymhleth ar wahân; bydd yn gwneud y cynllun yn drefn maint yn fwy cymhleth.
Storfa sesiwn
Rydyn ni'n defnyddio memcached :)
Mae'n trin storio sesiwn yn dda, wedi'i glystyru, ac yn cael ei gefnogi'n "frodorol" fel session.save_path yn php. Mae system o'r fath wedi'i phrofi sawl gwaith yn y bensaernïaeth monolithig clasurol, pan wnaethom adeiladu clystyrau gyda nifer fawr o weinyddion gwe. Ar gyfer lleoli rydym yn defnyddio helm.
$ helm install stable/memcached --name sessionphp.ini - yma mae'r ddelwedd yn cynnwys gosodiadau ar gyfer storio sesiynau yn memcached
Fe wnaethom ddefnyddio Newidynnau Amgylcheddol i drosglwyddo data am westeion gyda memcached .
Mae hyn yn caniatáu ichi ddefnyddio'r un cod yn yr amgylcheddau dev, llwyfan, prawf, prod (bydd yr enwau gwesteiwr memcached ynddynt yn wahanol, felly mae angen i ni drosglwyddo enw gwesteiwr unigryw ar gyfer sesiynau i bob amgylchedd).
Storio storfa Bitrix
Mae arnom angen storfa sy'n gallu goddef diffygion y gall pob cod ysgrifennu ato a darllen ohoni.
Rydym hefyd yn defnyddio memcached.
Argymhellir yr ateb hwn gan Bitrix ei hun.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - yma yn Bitrix nodir lle mae'r storfa yn cael ei storio
Rydym hefyd yn defnyddio Newidynnau Amgylcheddol.
Crontaski
Mae yna wahanol ddulliau o redeg Crontasks yn Kubernetes.
- lleoliad ar wahân gyda pod ar gyfer rhedeg Crontasks
- cronjob ar gyfer gweithredu crontasks (os yw hwn yn app gwe - gyda wget , neu kubectl exec y tu mewn i un o'r codennau gweithwyr, ac ati.)
- ac ati
Gallwch ddadlau am yr un mwyaf cywir, ond yn yr achos hwn fe wnaethom ddewis yr opsiwn “defnyddio ar wahân gyda chodau ar gyfer Crontasks”
Sut mae'n cael ei wneud:
- ychwanegu tasgau cron trwy ConfigMap neu drwy'r ffeil config/addcron
- mewn un achos rydym yn lansio cynhwysydd union yr un fath â'r pod gweithiwr + caniatáu cyflawni tasgau'r goron ynddo
- defnyddir yr un sylfaen cod, diolch i uno, mae cynulliad cynhwysydd yn syml
Pa ddaioni a gawn:
- mae gennym Crontasks gweithio mewn amgylchedd sy'n union yr un fath ag amgylchedd y datblygwyr (docer)
- Nid oes angen “ailysgrifennu” Crontasks ar gyfer Kubernetes, maent yn gweithio yn yr un ffurf ac yn yr un sylfaen cod ag o'r blaen
- gall holl aelodau'r tîm sydd â hawliau ymrwymo i'r gangen gynhyrchu ychwanegu tasgau cron, nid dim ond gweinyddwyr
Southbridge K8SDDeploy golygu modiwl a chod o'r panel gweinyddol
Roeddem yn sôn am uwchraddio o dan?
Sut i gyfeirio traffig yno?
Hurray, ysgrifennon ni fodiwl ar gyfer hyn yn PHP :) Modiwl bach clasurol yw hwn ar gyfer Bitrix. Nid yw ar gael yn gyhoeddus eto, ond bwriadwn ei agor.
Mae'r modiwl wedi'i osod fel modiwl rheolaidd yn Bitrix:
Ac mae'n edrych fel hyn:
Mae'n caniatáu ichi osod cwci sy'n nodi gweinyddwr y wefan ac yn caniatáu i Kubernetes anfon traffig i'r pod uwchraddio.
Pan fydd y newidiadau wedi'u cwblhau, mae angen i chi glicio git push, bydd y newidiadau cod yn cael eu hanfon i git, yna bydd y system yn adeiladu delwedd gyda fersiwn newydd o'r cod a'i “rholio” ar draws y clwstwr, gan ddisodli'r hen godau .
Ydy, mae'n dipyn o fagwraeth, ond ar yr un pryd rydym yn cynnal y bensaernïaeth microwasanaeth ac nid ydym yn cymryd oddi wrth ddefnyddwyr Bitrix eu hoff gyfle i gywiro'r cod o'r panel gweinyddol. Yn y diwedd, mae hwn yn opsiwn; gallwch chi ddatrys y broblem o olygu'r cod mewn ffordd wahanol.
Siart llyw
I adeiladu cymwysiadau ar Kubernetes, rydym fel arfer yn defnyddio rheolwr pecyn Helm.
Ar gyfer ein datrysiad Bitrix yn Kubernetes, ysgrifennodd Sergey Bondarev, ein gweinyddwr system blaenllaw, siart Helm arbennig.
Mae'n adeiladu codennau gweithiwr, ugrade, cron, yn ffurfweddu mewnlifiadau, gwasanaethau, ac yn trosglwyddo newidynnau o gyfrinachau Kubernetes i godennau.
Rydyn ni'n storio'r cod yn Gitlab, ac rydyn ni hefyd yn rhedeg yr Helm build o Gitlab.
Yn fyr, mae'n edrych fel hyn
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionMae Helm hefyd yn caniatáu ichi ddychwelyd yn “ddi-dor” os aiff rhywbeth o'i le yn sydyn yn ystod y defnydd. Mae'n braf pan nad ydych chi mewn panig “trwsiwch y cod trwy ftp oherwydd gostyngodd y prod,” ond mae Kubernetes yn ei wneud yn awtomatig, a heb amser segur.
Defnyddio
Ydym, rydyn ni'n gefnogwyr Gitlab & Gitlab CI, rydyn ni'n ei ddefnyddio :)
Wrth ymrwymo yn Gitlab i ystorfa'r prosiect, mae Gitlab yn lansio piblinell sy'n defnyddio fersiwn newydd o'r amgylchedd.
Camau:
- adeiladu (adeiladu delwedd Docker newydd)
- prawf (profi)
- glanhau (tynnu'r amgylchedd prawf)
- gwthio (rydym yn ei anfon i gofrestrfa'r Docker)
- defnyddio (rydym yn defnyddio'r cais i Kubernetes trwy Helm).
Hurray, mae'n barod, gadewch i ni ei weithredu!
Wel, neu gofynnwch gwestiynau os oes rhai.
Felly beth wnaethom ni
O safbwynt technegol:
- Bitrix docedig;
- “torri” Bitrix yn gynwysyddion, y mae pob un ohonynt yn cyflawni lleiafswm o swyddogaethau;
- cyflawni cyflwr di-wladwriaeth o gynwysyddion;
- datrys y broblem gyda diweddaru Bitrix yn Kubernetes;
- roedd holl swyddogaethau Bitrix yn parhau i weithio (bron i gyd);
- Buom yn gweithio ar leoli i Kubernetes a dychwelyd rhwng fersiynau.
O safbwynt busnes:
- goddefgarwch fai;
- Offer Kubernetes (integreiddio hawdd â Gitlab CI, defnydd di-dor, ac ati);
- cyfrineiriau cyfrinachol (dim ond yn weladwy i'r rhai sy'n cael mynediad uniongyrchol i'r cyfrineiriau);
- Mae'n gyfleus creu amgylcheddau ychwanegol (ar gyfer datblygu, profion, ac ati) o fewn un seilwaith.
Ffynhonnell: hab.com