Sysadminka sistemako administratzaileen topaketak egiten ari dira Chelyabinsken, eta azken batean Kubernetes-en 1C-Bitrix-en aplikazioak exekutatzeko gure irtenbideari buruzko txostena eman nuen.
Bitrix, Kubernetes, Ceph - nahasketa bikaina?
Esango dizut nola bildu dugun guzti honetatik lan-irtenbide bat.
Goazen!
Topaketa apirilaren 18an izan zen Chelyabinsken. Gure topaketen berri hemen irakur dezakezu eta begiratu .
Gurera erreportaje batekin edo entzule gisa etorri nahi baduzu - ongi etorri, idatzi hona [posta elektroniko bidez babestua] eta Telegram t.me/vadimisakanov-en.
Nire txostena
Soluzioa "Bitrix Kubernetes-en, Southbridge 1.0 bertsioa"
Gure konponbideari buruz hitz egingo dut "Kubernetes-eko dummiak" formatuan, topaketan egin zen bezala. Baina suposatzen dut Wikipediako artikuluen mailan behintzat ezagutzen dituzula Bitrix, Docker, Kubernetes, Ceph hitzak.
Zer dago prest Bitrix-en Kubernetes-en?
Internet osoan oso informazio gutxi dago Kubernetes-en Bitrix aplikazioen funtzionamenduari buruz.
Material hauek bakarrik aurkitu ditut:
Qsoft-eko Alexander Serbul, 1C-Bitrix eta Anton Tuzlukov-en txostena:
Entzutea gomendatzen dut.
Erabiltzailetik zure irtenbide propioa garatzea .
Gehiago aurkitu .
Aaand... egia esan, hori da dena.
Ohartarazten dizut, ez dugu konponbideen kalitatea egiaztatu goiko esteketan :)
Bide batez, gure irtenbidea prestatzerakoan, Alexander Serbulekin hitz egin nuen, orduan bere txostena oraindik ez zen agertu, beraz, nire diapositibetan "Bitrix-ek ez du Kubernetes erabiltzen" elementua dago.
Baina dagoeneko prest dauden Docker irudi asko daude Bitrix Docker-en exekutatzeko:
Nahikoa al da Kubernetes-en Bitrix-erako soluzio osoa sortzeko?
Ez. Arazo ugari daude konpondu beharrekoak.
Zeintzuk dira Bitrix-en arazoak Kubernetes-en?
Lehenik eta behin, Dockerhub-eko prest egindako irudiak ez dira egokiak Kubernetesentzat
Mikrozerbitzuen arkitektura bat eraiki nahi badugu (eta Kubernetes-en egin ohi dugu), gure Kubernetes aplikazioa edukiontzietan banatu behar dugu eta edukiontzi bakoitzak funtzio txiki bat bete behar du (eta ondo egin). Zergatik bakarra? Laburbilduz, zenbat eta sinpleago orduan eta fidagarriagoa.
Zehatzago izateko, ikusi artikulu eta bideo hau, mesedez:
Dockerhub-eko Docker-en irudiak bat-bateko printzipioaren arabera eraikitzen dira batez ere, beraz, oraindik ere gure bizikleta egin behar izan genuen eta baita irudiak hutsetik sortu ere.
Bigarrena - gunearen kodea administrazio paneletik editatzen da
Atal berri bat sortu dugu webgunean - kodea eguneratu da (atal berriaren izena duen direktorio bat gehitu da).
Admin paneleko osagai baten propietateak aldatu badituzu, kodea aldatu egiten da.
Kubernetes "lehenespenez" ezin da honekin funtzionatu; edukiontziak estaturik gabekoak izan behar dira.
Arrazoia: klusterreko edukiontzi (pod) bakoitzak trafikoaren zati bat soilik prozesatzen du. Kodea ontzi bakarrean (pod) aldatzen baduzu, orduan kodea ezberdina izango da ontzi desberdinetan, guneak modu ezberdinean funtzionatuko du eta webgunearen bertsio desberdinak erabiltzaile ezberdinei erakutsiko zaizkie. Ezin zara horrela bizi.
Hirugarrena - hedapenarekin arazoa konpondu behar duzu
Monolito bat eta zerbitzari "klasiko" bat baditugu, dena nahiko erraza da: kode-oinarri berri bat zabaltzen dugu, datu-basea migratzen dugu, trafikoa kodearen bertsio berrira aldatzen dugu. Aldaketa berehala gertatzen da.
Kubernetesen gune bat badugu, mikrozerbitzuetan moztuta, kodedun edukiontzi asko daude - oh. Kodearen bertsio berri bat duten edukiontziak bildu behar dituzu, zaharraren ordez zabaldu, datu-basea behar bezala migratu eta, hobe da, bisitariek oharkabean egin. Zorionez, Kubernetes-ek horretan laguntzen digu, inplementazio mota asko onartzen ditu.
Laugarren - estatikoak gordetzeko arazoa konpondu behar duzu
Zure gunea 10 gigabyte "soilik" bada eta edukiontzietan guztiz zabaltzen baduzu, betiko zabaltzen diren 10 gigabyte edukiontziekin amaituko duzu.
Gunearen zati "astunenak" edukiontzietatik kanpo gorde behar dituzu, eta hau zuzen nola egin galdera sortzen da.
Zer falta zaio gure irtenbideari?
Bitrix kode osoa ez dago mikrofuntzio/mikrozerbitzuetan banatuta (erregistroa bereizita egon dadin, lineako dendaren modulua bereizita, etab.). Kode-oinarri osoa edukiontzi bakoitzean gordetzen dugu.
Datu-basea ere ez dugu Kubernetes-en gordetzen (kubernetes-en datu-base batekin soluzioak ezarri nituen oraindik garapen-inguruneetarako, baina ez produkziorako).
Oraindik ere nabarituko zaie guneko administratzaileei gunea Kubernetesen exekutatzen dela. "Sistema egiaztatzeko" funtzioak ez du behar bezala funtzionatzen; gunearen kodea administrazio-paneletik editatzeko, lehenik "Kodea editatu nahi dut" botoia sakatu behar duzu.
Arazoak identifikatu dira, mikrozerbitzuak ezartzeko beharra zehaztu da, helburua argia da - Kubernetes-en Bitrix-en aplikazioak exekutatzeko lan-sistema bat lortzea, Bitrix-en gaitasunak eta Kubernetes-en abantailak gordez. Hasi gaitezen inplementazioa.
arkitektura
Web zerbitzari batekin (langileak) "lan egiten" duten pods asko daude.
Bat azpian cron zereginekin (bakarrik behar da).
Eguneratze bat administrazio paneletik gunearen kodea editatzeko (bakarrik ere behar da).
Galderak ebazten ditugu:
- Non gorde saioak?
- Non gorde cachea?
- Non gorde estatika, ez gigabyte estatiko edukiontzi mordo batean jartzeko?
- Nola funtzionatuko du datu-baseak?
Docker irudia
Docker irudi bat eraikitzen hasiko gara.
Aukera aproposa irudi unibertsal bat izatea da, bere oinarrian langileen podsak, Crontasks dituzten podsak eta bertsio berritzea lortzen ditugu.
.
Nginx, apache/php-fpm (eraikitzean hauta daiteke), posta bidaltzeko msmtp eta cron barne hartzen ditu.
Irudia muntatzean, guneko kode-oinarri osoa /app direktoriora kopiatzen da (partikatutako biltegiratze bereizi batera eramango ditugun zatiak izan ezik).
Mikrozerbitzuak, zerbitzuak
langile-taldeak:
- Edukiontziarekin nginx + edukiontzi apache/php-fpm + msmtp
- Ez zuen funtzionatu msmtp mikrozerbitzu bereizi batera eramatea, Bitrix haserretzen hasi da ezin duelako zuzenean mezurik bidali
- Edukiontzi bakoitzak kode-base osoa du.
- Edukiontzietan kodea aldatzeko debekua.
cron azpian:
- edukiontzi apache, php, cron
- kode-oinarri osoa barne
- edukiontzietan kodea aldatzeko debekua
berritu azpian:
- nginx edukiontzia + apache/php-fpm edukiontzia + msmtp
- Ez dago ontzietan kodea aldatzeko debekurik
saioa biltegiratzea
Bitrix cache biltegiratzea
Beste gauza garrantzitsu bat: denetara konektatzeko pasahitzak gordetzen ditugu, datu-basetik hasi eta postara, kubernetes sekretuetan. Hobari bat lortzen dugu: pasahitzak sekretuetarako sarbidea ematen diegunentzat bakarrik daude ikusgai, eta ez proiektuaren kode-oinarrirako sarbidea duten guztientzat.
Estatikarako biltegiratzea
Edozer erabil dezakezu: ceph, nfs (baina ez dugu produkziorako nfs gomendatzen), hodeiko hornitzaileen sareko biltegiratzea, etab.
Biltegiratzea edukiontzietan konektatu beharko da guneko /upload/ direktoriora eta eduki estatikoa duten beste direktorio batzuetara.
Datu-basea
Sinpletasuna lortzeko, datu-basea Kubernetesetik kanpo eramatea gomendatzen dugu. Kubernetes-en oinarria aparteko zeregin konplexua da; eskema konplexuagoa izango da.
Saioa biltegiratzea
Memcached erabiltzen dugu :)
Saioen biltegiratzea ondo kudeatzen du, multzokatuta dago eta php-n session.save_path gisa onartzen da "natiboki". Halako sistema bat askotan probatu da arkitektura monolitiko klasikoan, web zerbitzari kopuru handiarekin klusterrak eraiki genituenean. Zabaltzeko helm erabiltzen dugu.
$ helm install stable/memcached --name sessionphp.ini - hemen irudiak saioak memcached-en gordetzeko ezarpenak ditu
Memcached-ekin ostalariei buruzko datuak pasatzeko Ingurune Aldagaiak erabili ditugu .
Horri esker, dev, stage, test, prod inguruneetan kode bera erabil dezakezu (hauetan memcached ostalari-izenak desberdinak izango dira, beraz, saioetarako ostalari-izen esklusibo bat pasatu behar dugu ingurune bakoitzari).
Bitrix cache biltegiratzea
Akatsekiko tolerantzia-biltegiratzea behar dugu, pods guztiek idatzi eta irakurri ahal izateko.
Memcached ere erabiltzen dugu.
Irtenbide hau Bitrixek berak gomendatzen du.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - hemen Bitrix-en cachea non gordetzen den zehazten da
Inguruneko aldagaiak ere erabiltzen ditugu.
Krontaski
Kubernetesen Crontasks exekutatzeko planteamendu desberdinak daude.
- inplementazio bereizia Crontasks exekutatzeko pod batekin
- cronjob crontasks exekutatzeko (hau web aplikazioa bada - wget , edo kubectl exec langile-podetako baten barruan, etab.)
- eta abar.
Zuzenenari buruz eztabaidatu dezakezu, baina kasu honetan "bereizi inplementazioa Crontask-etarako podekin" aukera aukeratu dugu.
Nola egiten den:
- gehitu cron zereginak ConfigMap bidez edo config/addcron fitxategiaren bidez
- kasu batean langile-podaren berdin-berdina den edukiontzi bat abiarazten dugu + bertan koroaren zereginak exekutatzeko aukera ematen dugu
- kode-oinarri bera erabiltzen da, bateratzeari esker, edukiontzien muntaketa erraza da
Zer ondo ateratzen zaigu:
- Crontasks lan egiten dugu garatzaileen ingurunearen (docker) berdina den ingurune batean
- Crontask-ek ez dute "berridatzi" behar Kubernetes-erako, aurreko forma berean eta kode-oinarri berean funtzionatzen dute.
- cron atazak ekoizpen adarrean konprometitzeko eskubideak dituzten taldekide guztiek gehi ditzakete, ez administratzaileek soilik
Southbridge K8SDeploy modulua eta kodearen edizioa administrazio paneletik
Berrikuntzari buruz hitz egiten ari ginen?
Nola bideratu trafikoa bertara?
Hurra, honetarako modulu bat idatzi dugu PHPn :) Bitrix-erako modulu klasiko txiki bat da. Oraindik ez dago publikoki eskuragarri, baina irekitzeko asmoa dugu.
Modulua Bitrix-en modulu arrunt bat bezala instalatzen da:
Eta itxura hau:
Gunearen administratzailea identifikatzen duen cookie bat ezartzeko aukera ematen du eta Kubernetes-ek trafikoa bertsio berritze-ontzira bidaltzeko aukera ematen du.
Aldaketak amaitzen direnean, git push sakatu behar duzu, kodearen aldaketak git-era bidaliko dira, gero sistemak irudi bat eraikiko du kodearen bertsio berri batekin eta "zabalduko" du kluster osoan, pod zaharrak ordezkatuz. .
Bai, makulu pixka bat da, baina, aldi berean, mikrozerbitzuen arkitektura mantentzen dugu eta ez diegu kentzen Bitrix erabiltzaileei administrazio paneleko kodea zuzentzeko duten aukera gogokoena. Azkenean, hau aukera bat da; kodea editatzeko arazoa beste modu batera konpondu dezakezu.
Helm taula
Kubernetes-en aplikazioak eraikitzeko, normalean Helm pakete-kudeatzailea erabiltzen dugu.
Kubernetes-en dugun Bitrix soluziorako, Sergey Bondarev-ek, gure sistema-administratzaile nagusiak, Helm grafiko berezi bat idatzi zuen.
Langilea, bertsio berritzea, cron podak eraikitzen ditu, sarrerak, zerbitzuak konfiguratzen ditu eta aldagaiak Kubernetes sekretuetatik podetara transferitzen ditu.
Kodea Gitlab-en gordetzen dugu, eta Helm eraikitzea ere exekutatzen dugu Gitlab-en.
Laburbilduz, hau dirudi
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm-ek itzulera "emangabea" egiteko aukera ere ematen dizu, bat-batean zerbait gaizki gertatzen bada hedapenean. Polita da izuan ez zaudenean "konpondu kodea ftp bidez produktua erori delako", baina Kubernetesek automatikoki egiten du, eta geldialdirik gabe.
Zabaldu
Bai, Gitlab eta Gitlab CIren zaleak gara, erabiltzen dugu :)
Gitlab-en proiektuaren biltegian konpromisoa hartzen duenean, Gitlab-ek ingurunearen bertsio berri bat zabaltzen duen kanalizazio bat abiarazten du.
faseak:
- eraiki (Docker irudi berri bat eraikitzea)
- proba (proba)
- garbitu (proba ingurunea kendu)
- push (Docker erregistrora bidaltzen dugu)
- zabaldu (helm bidez hedatzen dugu aplikazioa Kubernetes-en).
Aupa, prest dago, ezar dezagun!
Tira, edo galderarik badago.
Beraz, zer egin genuen
Ikuspuntu teknikotik:
- Dockerized Bitrix;
- "moztu" Bitrix ontzietan, eta horietako bakoitzak funtzio minimo bat betetzen du;
- edukiontzien estaturik gabeko egoera lortu du;
- Kubernetes-en Bitrix eguneratzearen arazoa konpondu zuen;
- Bitrix funtzio guztiek lanean jarraitu zuten (ia guztiak);
- Kubernetesen inplementazioan eta bertsioen arteko itzuleran lan egin genuen.
Negozioaren ikuspuntutik:
- akatsen tolerantzia;
- Kubernetes tresnak (Gitlab CI-rekin integrazio erraza, inplementaziorik gabekoa, etab);
- pasahitz sekretuak (pasahitzetarako sarbidea zuzenean ematen zaienentzat bakarrik ikusgai);
- Erosoa da azpiegitura bakar baten barruan ingurune osagarriak sortzea (garapenerako, probak egiteko, etab.).
Iturria: www.habr.com