Tšeljabinskis toimuvad süsteemihaldurite Sysadminka kohtumised, ja viimasel neist tegin ettekande meie lahendusest 1C-Bitrix rakenduste töötamiseks Kuberneteses.
Bitrix, Kubernetes, Ceph — suurepärane segu?
Räägin, kuidas me sellest kõik koos töötava lahenduse kokku panime.
Lähme!
Kohtumine toimus 18. aprillil Tšeljabinskis. Meie kohtumiste kohta saate lugeda ja vaadata .
Kui soovite meiega esitlema tulla või lihtsalt kuulajana, kirjutage aadressile vadim.isakanov@gmail.com ja Telegramis t.me/vadimisakanov.
Minu ettekande teema
Lahendus „Bitrix Kuberneteses, versioon Southbridge 1.0“
Räägin meie lahendusest formaadis „Kubernetesi algajatele“, kuidas see kohtumisel tehtud oli. Kuid eeldan, et sõnad Bitrix, Docker, Kubernetes, Ceph on teile vähemalt tuntud Wikipediast.
Mis on üldiselt valmislahendusi Bitrixi jaoks Kuberneteses?
Internetrus on Bitrixi rakenduste töötamise kohta Kuberneteses väga vähe teavet.
Leidsin vaid sellised materjalid:
Ettekande autoriks on Aleksandr Serbul, 1C-Bitrix ja Anton Tuzlukov Qsoftist:
Soovitan seda kuulata.
Oma lahenduse arendus kasutaja poolt .
Leidsin veel .
Ja… tegelikult kõik.
Hoiatan, et nende linkide kvaliteeti me ei ole kontrollinud 🙂
Muide, meie lahenduse ettevalmistamise käigus sukeldu, et Aleksandr Serbul vähemalt tookord oma ettekannet ei olnud, seetõttu on mu slaididel punkti „Bitrix ei kasuta Kuberneteset“.
Kuid siiski on Bitrixi töötamiseks Dockeris juba palju valmis Docker-image'e:
Kas seda piisab, et luua täiuslik lahendus Bitrixi jaoks Kuberneteses?
Ei. On palju probleeme, mis tuleb lahendada.
Millised on probleemid Bitrixiga Kuberneteses?
Esimene — valmis pildid Dockerhubis ei sobi Kubernetesesse.
Kui soovime ehitada mikroteenuste arhitektuuri (ja Kuberneteses soovime seda tavaliselt), siis tuleb rakendus Kuberneteses jagada konteineriteks ja saavutada, et iga konteiner täidab ühe väikese funktsiooni (ja teeb seda hästi). Miks ainult üks? Lühidalt — mida lihtsam, seda usaldusväärsem.
Kui pikemalt — palun vaadake seda artiklit ja videot:
Docker pildid Dockerhubis on peamiselt ehitatud põhimõttel „kõik ühes“, seetõttu pidime ikkagi oma jalgratta valmistama ja isegi pildid nullist tegema.
Teine — saidi kood muudetakse administraatori paneelilt.
Loomi uus jaotis saidil — kood on uuendatud (ilmunud uue jaotise nimega kaust).
Komponendi omadusi muudeti admin-paneelist — kood muutus.
Kubernetes ei oska sellisega vaikimisi töötada, konteinerid peavad olema muutumatud (Stateless).
Põhjus: iga konteiner (pod) klastris töötab ainult osa liiklust. Kui muuta koodi ainult ühes konteineris (podis), on erinevates podides erinev kood, veebisait töötab erinevalt, erinevatele kasutajatele kuvatakse erinevaid versioone veebisaidist. Nii ei saa elada.
Kolmas — tuleb lahendada juurutamise küsimus.
Kui meil on monoliitne ja üks «klassikaline» server, on kõik väga lihtne: tõstame uue koodibaasi üles, teeme andmebaasi migratsiooni, suuname liikluse uue koodi versiooni peale. Üleminek toimub hetkega.
Kui meie sait on Kuberneteses, jagatud mikroteenusteks, konteineri koode on palju — see on keerulisem. Peame koguma konteinerid uue koodi versiooniga, vabastama need vanade asemel, õigesti teostama andmebaasi migratsiooni ning ideaaljuhul tegema seda külastajate jaoks märkamatult. Õnneks aitab Kubernetes meid selles, toetades mitmeid erinevaid juurutamise viise.
Neljas — tuleb lahendada staatika hoidmise küsimus.
Kui teie sait kaalub «vaid» 10 gigabaiti ja te tõstate selle täielikult konteineritesse, saate 10-gigabaitised konteinerid, mis juurutatakse igavesti.
Peame hoidma kõige «raskemaid» osi saidist väljaspool konteinerite, ja tekib küsimus, kuidas seda õigesti teha.
Mida meie lahendus ei paku.
Kogu Bitrixi kood ei ole jagatud mikroteenusteks (nii, et registreerimine eraldi, internetipood eraldi jne). Kogu koodibaas on meil igas konteineris täielikult tallel.
Me ei hoia andmebaasi Kuberneteses (olen küll rakendanud lahendusi andmebaasiga Kuberneteses arenduskeskkondade jaoks, aga mitte tootmises).
Saidihaldurid märkavad siiski, et sait töötab Kuberneteses. Funktsioon «süsteemi kontroll» töötab valesti, et muuta saidi koodi admin-paneelist, tuleb esmalt vajutada nuppu «tahan koodi redigeerida».
Oleme probleemid lahendanud, mikroteenuste rakendamise vajadusega selgeks saanud, eesmärk on selge — luua toimiv süsteem Bitrixi rakenduste käitamiseks Kuberneteses, säilitades nii Bitrixi funktsionaalsuse kui ka Kubernetesi eelised. Alustame rakendamist.
Arhitektuur
Palju 'töötavaid' pod'e veebiserveriga (töötajad).
Üks pod krontööride jaoks (kindlasti ainult üks).
Üks upgrade pod saidi koodi redigeerimiseks administraatori paneelist (ka kindlasti ainult üks).
Lahendame küsimused:
- Kus salvestada sessioonid?
- Kus salvestada cache?
- Kus salvestada statikat, ei saa ju gigabaitide kaupa statikat hunnikus konteinerites hoida?
- Kuidas töötatakse andmebaasiga?
Docker’i pilt
Alustame Docker’i pildi koostamisest.
Ideaalne variant — meil on üks universaalne pilt, mille põhjal saame nii töötajate pod'id, kui ka pod'id krontööride ja upgrade'i jaoks.
.
Siia on lisatud nginx, apache/php-fpm (võib valida koostamisel), msmtp e-kirjade saatmiseks ning cron.
Pildi koostamisel kopeeritakse kausta /app kogu saidi koodibaas (välja arvatud need osad, mis viime eraldi jagatud salvestusse).
Mikroteenused, teenused
Töötajate pod'id:
- Konteiner nginx'i + konteiner apache/php-fpm + msmtp
- msmtp eraldamine eraldi mikroteenuseks ei õnnestunud, Bitrix hakkab nurisema, et ei saa otse e-kirju saata
- Igas konteineris on terve koodibaas.
- Koodimuutuste keeld konteinerites.
cron pod:
- konteiner apache, php, cron
- komplektis on täiuslik koodibaas
- koodimuutuste keeld konteinerites
upgrade pod:
- konteiner nginx + konteiner apache/php-fpm + msmtp
- koodimuutuste keeld konteinerites ei ole
sessioonide salvestus
Bitrixi cache'i salvestus
Veel oluline: kõik paroolid, sealhulgas andmebaasi ja e-kirjade ühendamiseks, salvestame Kubernetesi saladustesse. Saame plussi — paroolid on nähtavad ainult neile, kellele anname õigused saladustele, mitte kõigile, kellel on pääs projekti koodibaasi.
Statika salvestus
Võib kasutada ükskõik mida: ceph, nfs (aga nfs ei ole soovitatav tootmises), pilveteenuse pakkujate võrgu salvestus jne.
Salvestus tuleb konteinerites ühendada saidi /upload/ kausta ja teiste statika kaustadega.
Andmebaas
Kerguse huvides soovitame viia andmebaas Kubernetesest välja. Andmebaas Kuberneteses — eraldi keeruline ülesanne, muudab süsteemi oluliselt keerulisemaks.
Sessioonide salvestus
Kasutame memcached 🙂
Seegehul on hästi hakkama saama sessioonide salvestamisega, see rühmitatakse, toetatakse "natiivselt" nagu session.save_path php-s. Selline süsteem on mitmeid kordi tööle pandud klassikalises monoliitses arhitektuuris, kui me ehitasime klastreid suure arvu veebiserveritega. Käivitamiseks kasutame helm.
$ helm install stable/memcached --name sessionphp.ini — siin on pildis määratud seadistused sessioonide salvestamiseks memcachedis
Kasutasime keskkonnamuutujaid memcachedi hostide andmete edastamiseks .
See võimaldab sama koodi kasutada dev, stage, test, prod keskkondades (memcachedi hostide nimed on erinevad, seega peame iga keskkonna jaoks edastama unikaalsed hostinimed sessioonide jaoks).
Bitrixi puhvrihoidla
Meil on vaja talitlushäiretega vastupidavat hoidlit, kuhu kõik pod'id saaksid kirjutada ja kust lugeda.
Kasutame ka memcachedi.
Seda lahendust soovitab Bitrix ise.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php — siin Bitrixis määratakse, kus meie vahemälu asub
Kasutame ka keskkonnamuutujaid.
Kronitööd
Kuberneteses on erinevaid lähenemisviise kronitööde täitmiseks.
- eraldi rakendamine pod'i jaoks, et täita kronitöid
- cronjob kronitööde täitmiseks (kui see on veebirakendus — koos wget , või kubectl exec ühe töötluspod'i sisse jne.)
- jne.
Võib vaielda selle üle, mis on õigesti, aga sel juhul valisime variandi „eraldi rakendamine pod'ide jaoks kronitööde jaoks“
Kuidas see on tehtud:
- kronitöid lisame läbi ConfigMap'i või läbi faili config/addcron
- käivitame konteineri ühes eksemplaris, mis on identne töötluspod'iga + lubame sellel täita kronitöid
- kasutatakse sama koodibaasi, tänu ühtlustamisele on konteineri koostamine lihtne
Mida head me saame:
- meil on töötavad kronitööd keskkonnas, mis on identne arendajate keskkonnaga (docker)
- kronitöid ei pea Kubernetesesse „ületama”, need töötavad samas vormis ja samas koodibaasis nagu varem
- kronitöid võivad lisada kõik meeskonna liikmed, kellel on õigused commiteerida tootmispuusse, mitte ainult administraatorid
Moodul Southbridge K8SDeploy ja koodi redigeerimine halduspaneelist
Kas me ei rääkinud pod'i uuendamisest?
Kuidas suunata sinna liiklust?
Hoorraa, me kirjutasime selle jaoks mooduli php-s 🙂 See on väike klassikaline moodul Bitrixi jaoks. Seda ei ole veel avalikult saadaval, aga me plaanime selle avada.
Moodul installitakse nagu tavaline moodul Bitrixis:
Ja see näeb välja nii:
See võimaldab seada küpsist, mis tuvastab saidi administraatori ja lubab Kubernetesel suunata liiklus uuendamise podi peale.
Kui muudatused on lõpetatud, tuleb vajutada git push, koodimuudatused saadetakse git'i, seejärel kogub süsteem pildi uue koodiversiooniga ja "teeb" sellest klastrisse, asendades vanad podid.
Jah, see on veidi kohmakas, kuid sellegipoolest säilitame mikroteenuse arhitektuuri ja ei võta Bitrixi kasutajatelt ära nende armastatud võimalust oma koodi admin paneelilt muuta. Lõppude lõpuks on see valik, koodi muutmise ülesande saab lahendada ka teisiti.
Helm chart
Rakenduste kogumiseks Kuberneteses kasutame me tavaliselt pakihaldurit Helm.
Meie Bitrixi lahendus Kuberneteses on spetsiaalselt kirjutatud Helm chart, mille autoriks on meie peamine süsteemiadministraator Sergei Bondarev.
See kogub töötaja, uuendamis- ja cron podid, seadistab ingress'id, teenused, edastab muutujad Kubernetesi saladustest podidesse.
Koodi hoiame Gitlabis ja Helm'i kogumise käivitame samuti Gitlabist.
Lühidalt öeldes, see näeb välja nii
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm võimaldab ka "katkestusteta" tagasipöördumist, kui midagi läheb juurutamisel valesti. On tore, kui sa ei pea paanikas "koodi FTP kaudu parandama, kuna tootmine on välja kukkunud", vaid Kubernetes teeb seda automaatselt, ja veel ilma seisakuajata.
Käivitamine
Jah, me oleme Gitlab & Gitlab CI fännid, kasutame seda 🙂
Kui Gitlabisse projektirepositooriumisse commiti, käivitab Gitlab toru, mis teostab uue keskkonna versiooni juurutamise.
Etapid:
- build (kogume uue Docker pildi)
- test (testime)
- clean up (eemaldame testkeskkonna)
- push (saadame selle Docker registrisse)
- deploy (juurutame rakenduse Kuberneteses läbi Helmi).
Hooray, valmis, viime ellu!
Või esitame küsimusi, kui neid on.
Nii et, mida me tegime
Tehnilisest küljest:
- dockeriseerisime Bitrixi;
- "lõikasime" Bitrixi konteineriteks, millest igaüks täidab minimaalset funktsiooni;
- saavutasime konteinerite state-less oleku;
- lahendasime Bitrixi uuendamise probleemi Kuberneteses;
- kõik Bitrixi funktsioonid jätkasid töötamist (peaaegu kõik);
- töötasime välja juurutamise Kuberneteses ja tagasipöörde versioonide vahel.
Äri seisukohalt:
- veakindlus;
- Kubernetes'i tööriistad (lihtne integratsioon Gitlab CI-ga, katkestusteta juurutamine jne);
- paroolid saladustes (nähtavad ainult neile, kellele on otseselt antud juurdepääs paroolidele);
- veebikeskkonnas on mugav luua täiendavaid keskkondi (arendamiseks, testimiseks jne).
Allikas: habr.com
