Tšeljabinskis toimuvad Sysadminka süsteemiadministraatorite kohtumised ja viimasel kohtumisel andsin aruande meie lahendusest rakenduste käitamiseks Kubernetes 1C-Bitrixis.
Bitrix, Kubernetes, Ceph – suurepärane segu?
Ma räägin teile, kuidas me sellest kõigest toimiva lahenduse kokku panime.
Mine!
Kohtumine toimus 18. aprillil Tšeljabinskis. Meie kohtumiste kohta saate lugeda aadressilt ja vaata .
Kui soovid tulla meie juurde reportaažiga või kuulajaks - tere tulemast, kirjuta [meiliga kaitstud] ja Telegramis t.me/vadimisakanov.
Minu aruanne
Lahendus "Bitrix in Kubernetes, versioon Southbridge 1.0"
Räägin meie lahendusest vormingus “Kubernetese mannekeenidele”, nagu kohtumisel tehti. Aga eeldan, et tead sõnu Bitrix, Docker, Kubernetes, Ceph vähemalt Vikipeedia artiklite tasemel.
Mis on Bitrixi kohta Kubernetesis valmis?
Kogu Internetis on väga vähe teavet Bitrixi rakenduste töö kohta Kubernetes.
Leidsin ainult need materjalid:
Qsofti Alexander Serbuli, 1C-Bitrixi ja Anton Tuzlukovi aruanne:
Soovitan seda kuulata.
Kasutajalt oma lahenduse väljatöötamine .
Leiti rohkem .
Aaand... tegelikult on see kõik.
Hoiatan, me pole ülaltoodud linkidelt lahenduste kvaliteeti kontrollinud :)
Muide, meie lahenduse ettevalmistamisel rääkisin Aleksander Serbuliga, siis polnud tema aruannet veel ilmunud, nii et minu slaididel on üksus "Bitrix ei kasuta Kubernetest".
Kuid Bitrixi käitamiseks Dockeris on juba palju valmis Dockeri pilte:
Kas sellest piisab, et luua Bitrixi jaoks Kubernetesis terviklik lahendus?
Ei. Probleeme, mis vajavad lahendamist, on suur hulk.
Millised on Bitrixi probleemid Kubernetesis?
Esiteks ei sobi Dockerhubi valmiskujutised Kubernetesele
Kui tahame luua mikroteenuste arhitektuuri (ja Kubernetesis me seda tavaliselt teeme), peame eraldama oma Kubernetese rakenduse konteineriteks ja laskma igal konteineril täita ühte väikest funktsiooni (ja seda hästi teha). Miks ainult üks? Lühidalt, mida lihtsam, seda usaldusväärsem.
Täpsemalt vaadake seda artiklit ja videot:
Dockerhubis olevad Dockeri pildid on üles ehitatud peamiselt kõik-ühes põhimõttel, nii et pidime ikkagi oma jalgratta tegema ja isegi pilte nullist looma.
Teiseks – saidi koodi redigeeritakse administraatoripaneelilt
Lõime saidile uue jaotise - koodi värskendati (lisati kataloog uue jaotise nimega).
Kui muutsite administraatoripaneelil komponendi atribuute, muutus kood.
Kubernetes vaikimisi ei saa sellega töötada; konteinerid peavad olema olekuta.
Põhjus: iga klastri konteiner (pod) töötleb ainult osa liiklusest. Kui muudate koodi ainult ühes konteineris (podis), on kood erinevates kaustades erinev, sait töötab erinevalt ja erinevatele kasutajatele näidatakse saidi erinevaid versioone. Sa ei saa nii elada.
Kolmandaks - peate probleemi lahendama juurutamisega
Kui meil on monoliit ja üks "klassikaline" server, on kõik üsna lihtne: juurutame uue koodibaasi, migreerime andmebaasi, lülitame liikluse koodi uuele versioonile. Üleminek toimub koheselt.
Kui meil on Kubernetesis mikroteenusteks lõigatud sait, on seal palju konteinereid koodiga - oh. Peate koguma konteinerid koodi uue versiooniga, need vanade asemel välja rullima, andmebaasi õigesti migreerima ja ideaalis tegema seda külastajatele märkamatult. Õnneks aitab Kubernetes meid selles, toetades tervet hulka erinevat tüüpi juurutusi.
Neljandaks - peate lahendama staatika salvestamise küsimuse
Kui teie sait on "ainult" 10 gigabaiti ja juurutate selle täielikult konteinerites, saate lõpuks 10 gigabaidise konteineri, mille juurutamine võtab igaviku.
Peate hoidma saidi "raskeimad" osad väljaspool konteinereid ja tekib küsimus, kuidas seda õigesti teha
Mis meie lahendusest puudu on?
Kogu Bitrixi kood ei ole jagatud mikrofunktsioonideks/mikroteenusteks (et registreerimine oleks eraldi, veebipoe moodul eraldi jne). Igasse konteinerisse salvestame kogu koodibaasi.
Samuti ei säilita me andmebaasi Kubernetes (arenduskeskkondadele juurutasin Kubernetes andmebaasiga lahendused ikka, aga tootmiseks mitte).
Saidi administraatorid on endiselt märgatavad, et sait töötab Kubernetesis. Funktsioon "Süsteemikontroll" ei tööta korralikult; saidi koodi redigeerimiseks administraatoripaneelilt peate esmalt klõpsama nuppu "Soovin koodi redigeerida".
Probleemid on tuvastatud, mikroteenuste juurutamise vajadus kindlaks tehtud, eesmärk selge - saada Kuberneteses Bitrixil rakenduste jooksmiseks töötav süsteem, säilitades nii Bitrixi võimalused kui ka Kubernetese eelised. Alustame rakendamist.
arhitektuur
Veebiserveriga (töölised) on palju "töötavaid" kausid.
Üks alla koos cron-ülesannetega (vajalik on ainult üks).
Üks täiendus saidi koodi redigeerimiseks administraatoripaneelilt (samuti on vaja ainult ühte).
Lahendame küsimusi:
- Kuhu seansse salvestada?
- Kuhu vahemälu salvestada?
- Kuhu hoida staatikat, mitte panna gigabaite staatikat hunnikusse anumatesse?
- Kuidas andmebaas töötab?
Dockeri pilt
Alustame Dockeri pildi loomisega.
Ideaalne variant on see, et meil on üks universaalne pilt, mille alusel saame töötajad, Crontaskiga kaustad ja uuendused.
.
See sisaldab nginxi, apache/php-fpm-i (saab valida koostamise ajal), msmtp-d kirjade saatmiseks ja cronit.
Pildi kokkupanemisel kopeeritakse kogu saidi koodibaas /app kataloogi (välja arvatud need osad, mille viime eraldi jagatud salvestusruumi).
Mikroteenused, teenused
töötaja kaunad:
- Konteiner koos nginxiga + konteiner apache/php-fpm + msmtp
- Msmtp eraldi mikroteenusesse teisaldamine ei õnnestunud, Bitrix hakkab nördima, et ta ei saa otse kirju saata
- Igal konteineril on täielik koodibaas.
- Koodi muutmise keeld konteinerites.
cron all:
- konteiner apache, php, croniga
- kaasas täielik koodibaas
- koodi muutmise keeld konteinerites
uuendada all:
- nginxi konteiner + apache/php-fpm konteiner + msmtp
- Konteinerites koodi vahetamise keeldu ei ole
seansi salvestamine
Bitrixi vahemälu salvestusruum
Veel üks oluline asi: salvestame kubernetese saladustesse paroolid ühenduse loomiseks kõigega, andmebaasist postini. Saame boonuse: paroolid on nähtavad ainult neile, kellele anname juurdepääsu saladustele, mitte kõigile, kellel on juurdepääs projekti koodibaasile.
Panipaik staatika jaoks
Võite kasutada kõike: ceph, nfs (kuid me ei soovita nfs-i tootmiseks), pilveteenuse pakkujate võrgusalvestust jne.
Salvestusruum tuleb konteinerites ühendada saidi /upload/ kataloogiga ja muude staatilise sisuga kataloogidega.
Andmebaas
Lihtsuse huvides soovitame andmebaasi Kubernetesist väljapoole teisaldada. Kubernetese baas on omaette keeruline ülesanne; see muudab skeemi suurusjärgus keerukamaks.
Seansi salvestamine
Kasutame memcachedit :)
See käsitleb hästi seansi salvestamist, on rühmitatud ja seda toetatakse php-s "natiivselt" kui session.save_path. Sellist süsteemi on klassikalises monoliitarhitektuuris korduvalt testitud, kui ehitasime suure hulga veebiservereid sisaldavaid klastreid. Kasutuselevõtmiseks kasutame tüüri.
$ helm install stable/memcached --name sessionphp.ini - siin sisaldab pilt sätteid seansside salvestamiseks memcached
Memcached-iga hostide andmete edastamiseks kasutasime keskkonnamuutujaid .
See võimaldab teil kasutada sama koodi arendus-, etapi-, testi- ja tootmiskeskkondades (nende vahemällu salvestatud hostinimed on erinevad, seega peame igale keskkonnale seansside jaoks unikaalse hostinime edastama).
Bitrixi vahemälu salvestusruum
Vajame tõrkekindlat salvestusruumi, kuhu kõik taskud saaksid kirjutada ja kust lugeda.
Kasutame ka memcachedit.
Seda lahendust soovitab Bitrix ise.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - siin on Bitrixis määratud, kuhu vahemälu salvestatakse
Kasutame ka keskkonnamuutujaid.
Krontaski
Crontasksi käitamiseks Kubernetesis on erinevaid lähenemisviise.
- eraldi juurutamine koos podiga Crontasksi käitamiseks
- cronjob crontaskide täitmiseks (kui see on veebirakendus - koos wget , või kubectl exec ühes töötajate kaustas jne)
- ja nii edasi
Võite vaielda kõige õigema üle, kuid sel juhul valisime valiku "Crontasksi jaoks eraldi juurutamine podidega".
Kuidas seda tehakse:
- lisage cron-ülesanded ConfigMapi või faili config/addcron kaudu
- ühel juhul käivitame konteineri, mis on identne worker podiga + lubame selles kroonülesannete täitmist
- kasutatakse sama koodibaasi, tänu ühtlustamisele on konteineri kokkupanek lihtne
Mida head saame:
- meil on töötavad Crontaskid keskkonnas, mis on identne arendaja keskkonnaga (docker)
- Crontese ei pea Kubernetese jaoks "ümber kirjutama", need töötavad samal kujul ja samas koodibaasis nagu varem
- cron ülesandeid saavad lisada kõik tootmisharu sidumisõigustega meeskonnaliikmed, mitte ainult administraatorid
Southbridge K8SDeploy mooduli ja koodi redigeerimine administraatori paneelilt
Me rääkisime uuendamisest all?
Kuidas liiklust sinna suunata?
Hurraa, me kirjutasime selle jaoks PHP-s mooduli :) See on väike klassikaline moodul Bitrixile. See pole veel avalikult saadaval, kuid plaanime selle avada.
Moodul paigaldatakse nagu tavaline Bitrixi moodul:
Ja see näeb välja selline:
See võimaldab teil määrata küpsise, mis tuvastab saidi administraatori ja võimaldab Kubernetesel saata liiklust täienduskomplekti.
Kui muudatused on lõpule viidud, peate klõpsama nuppu git push, koodimuudatused saadetakse gitile, seejärel koostab süsteem koodi uue versiooniga pildi ja "rullib" selle kogu klastris välja, asendades vanad kaustad. .
Jah, see on natuke kark, kuid samal ajal säilitame mikroteenuste arhitektuuri ega võta Bitrixi kasutajatelt ära nende lemmikvõimalust administraatoripaneelilt koodi parandada. Lõpuks on see valik; saate koodi redigeerimise probleemi lahendada erineval viisil.
Helmi diagramm
Rakenduste loomiseks Kubernetesis kasutame tavaliselt Helmi paketihaldurit.
Meie juhtiv süsteemiadministraator Sergey Bondarev kirjutas meie Bitrixi lahenduse jaoks Kubernetesis spetsiaalse Helmi diagrammi.
See loob worker, ugrade, cron podsid, konfigureerib sisestusi, teenuseid ja edastab muutujad Kubernetese saladustest kaustadesse.
Talletame koodi Gitlabis ja käitame ka Gitlabi Helmi ehitamist.
Lühidalt, see näeb välja selline
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm võimaldab teil ka "tõrgeteta" tagasipööramist teha, kui kasutuselevõtu ajal läheb äkki midagi valesti. On tore, kui te pole paanikas "parandage kood ftp kaudu, kuna prod kukkus", vaid Kubernetes teeb seda automaatselt ja ilma seisakuta.
Kasutusele võtta
Jah, me oleme Gitlabi ja Gitlab CI fännid, kasutame seda :)
Gitlabis projektihoidlasse sidudes käivitab Gitlab konveieri, mis juurutab keskkonna uue versiooni.
Astmed:
- ehitamine (uue Dockeri pildi loomine)
- test (testimine)
- puhastamine (testikeskkonna eemaldamine)
- push (saatame selle Dockeri registrisse)
- juurutada (juurutame rakenduse Helmi kaudu Kubernetesesse).
Hurraa, see on valmis, viime selle ellu!
Noh, või küsige küsimusi, kui neid on.
Mida me siis tegime
Tehnilisest vaatenurgast:
- dokitud Bitrix;
- "lõigake" Bitrix konteineritesse, millest igaüks täidab minimaalselt funktsioone;
- saavutatud konteinerite olekuta olek;
- lahendas probleemi Bitrixi värskendamisega Kubernetesis;
- kõik Bitrixi funktsioonid jätkasid tööd (peaaegu kõik);
- Töötasime Kubernetes juurutamise ja versioonide vahel tagasipööramise kallal.
Ärilisest vaatenurgast:
- veataluvus;
- Kubernetese tööriistad (lihtne integreerimine Gitlab CI-ga, sujuv juurutamine jne);
- salajased paroolid (nähtavad ainult need, kellel on otsene juurdepääs paroolidele);
- Mugav on luua täiendavaid keskkondi (arenduseks, testimiseks jne) ühe infrastruktuuri sees.
Allikas: www.habr.com