Sysadminka-stelseladministrateurvergaderings vind in Chelyabinsk plaas, en by die laaste een het ek 'n verslag gegee oor ons oplossing om toepassings op 1C-Bitrix in Kubernetes te laat loop.
Bitrix, Kubernetes, Ceph - 'n wonderlike mengsel?
Ek sal jou vertel hoe ons 'n werkende oplossing uit dit alles saamstel.
Kom ons gaan!
Die ontmoeting het op 18 April in Chelyabinsk plaasgevind. Jy kan lees oor ons ontmoetings by en kyk na .
As jy met 'n verslag of as luisteraar na ons toe wil kom - welkom, skryf aan [e-pos beskerm] en op Telegram t.me/vadimisakanov.
My verslag
Oplossing "Bitrix in Kubernetes, weergawe Southbridge 1.0"
Ek sal oor ons oplossing in die "vir dummies in Kubernetes"-formaat praat, soos tydens die ontmoeting gedoen is. Maar ek neem aan dat jy die woorde Bitrix, Docker, Kubernetes, Ceph ten minste op die vlak van artikels op Wikipedia ken.
Wat is gereed gemaak oor Bitrix in Kubernetes?
Daar is baie min inligting op die hele internet oor die werking van Bitrix-toepassings in Kubernetes.
Ek het net hierdie materiaal gevind:
Verslag deur Alexander Serbul, 1C-Bitrix, en Anton Tuzlukov van Qsoft:
Ek beveel aan om daarna te luister.
Ontwikkel jou eie oplossing vanaf die gebruiker .
Meer gevind .
Aaand... eintlik is dit al.
Ek waarsku jou, ons het nie die kwaliteit van die oplossings in die skakels hierbo nagegaan nie :)
Terloops, toe ek ons oplossing voorberei het, het ek met Alexander Serbul gepraat, toe het sy verslag nog nie verskyn nie, so in my skyfies is daar 'n item "Bitrix gebruik nie Kubernetes nie."
Maar daar is reeds baie klaargemaakte Docker-beelde om Bitrix in Docker te laat loop:
Is dit genoeg om 'n volledige oplossing vir Bitrix in Kubernetes te skep?
Geen. Daar is 'n groot aantal probleme wat opgelos moet word.
Wat is die probleme met Bitrix in Kubernetes?
Eerstens is gereedgemaakte beelde van Dockerhub nie geskik vir Kubernetes nie
As ons 'n mikrodienste-argitektuur wil bou (en in Kubernetes doen ons dit gewoonlik), moet ons ons Kubernetes-toepassing in houers skei en elke houer een klein funksie laat uitvoer (en dit goed doen). Hoekom net een? Kortom, hoe eenvoudiger hoe meer betroubaar.
Om meer spesifiek te wees, kyk asseblief na hierdie artikel en video:
Docker-beelde in Dockerhub is hoofsaaklik gebou op die alles-in-een-beginsel, so ons moes steeds ons eie fiets maak en selfs beelde van nuuts af skep.
Tweedens word die werfkode vanaf die administrasiepaneel geredigeer
Ons het 'n nuwe afdeling op die webwerf geskep - die kode is opgedateer ('n gids met die naam van die nuwe afdeling is bygevoeg).
As jy die eienskappe van 'n komponent vanaf die administrasiepaneel verander het, het die kode verander.
Kubernetes kan “by verstek” nie hiermee werk nie; houers moet staatloos wees.
Rede: Elke houer (peul) in die groep verwerk slegs 'n gedeelte van die verkeer. As jy die kode in slegs een houer (peul) verander, dan sal die kode verskil in verskillende peule, die werf sal anders werk, en verskillende weergawes van die werf sal aan verskillende gebruikers gewys word. Jy kan nie so lewe nie.
Derdens - jy moet die probleem met ontplooiing oplos
As ons 'n monoliet en een "klassieke" bediener het, is alles redelik eenvoudig: ons ontplooi 'n nuwe kodebasis, migreer die databasis, skakel verkeer oor na die nuwe weergawe van die kode. Omskakeling vind onmiddellik plaas.
As ons 'n webwerf in Kubernetes het, gesny in mikrodienste, is daar baie houers met kode - o. Jy moet houers met 'n nuwe weergawe van die kode versamel, dit uitrol in plaas van die oues, die databasis korrek migreer, en ideaal gesproke dit ongemerk deur besoekers doen. Gelukkig help Kubernetes ons hiermee en ondersteun 'n hele klomp verskillende tipes ontplooiings.
Vierdens - jy moet die kwessie van die stoor van statika oplos
As jou werf “net” 10 gigagrepe is en jy dit geheel en al in houers ontplooi, sal jy eindig met 10 gigagrepe houers wat vir ewig neem om te ontplooi.
Jy moet die "swaarste" dele van die terrein buite houers stoor, en die vraag ontstaan hoe om dit korrek te doen
Wat ontbreek in ons oplossing?
Die hele Bitrix-kode is nie in mikrofunksies/mikrodienste verdeel nie (sodat registrasie apart is, die aanlynwinkelmodule apart is, ens.). Ons stoor die hele kodebasis in elke houer.
Ons stoor ook nie die databasis in Kubernetes nie (ek het steeds oplossings geïmplementeer met 'n databasis in Kubernetes vir ontwikkelingsomgewings, maar nie vir produksie nie).
Dit sal steeds opmerklik wees vir werfadministrateurs dat die werf op Kubernetes loop. Die "stelselkontrole"-funksie werk nie korrek nie; om die webwerfkode vanaf die administrasiepaneel te wysig, moet jy eers op die "Ek wil die kode wysig"-knoppie klik.
Die probleme is geïdentifiseer, die behoefte om mikrodienste te implementeer is bepaal, die doelwit is duidelik - om 'n werkende stelsel te kry om toepassings op Bitrix in Kubernetes te laat loop, wat beide die vermoëns van Bitrix en die voordele van Kubernetes behou. Kom ons begin implementering.
Argitektuur
Daar is baie "werkende" peule met 'n webbediener (werkers).
Een onder met cron-take (slegs een word vereis).
Een opgradering vir die wysiging van die werfkode vanaf die administrasiepaneel (ook net een word vereis).
Ons los vrae op:
- Waar om sessies te stoor?
- Waar om die kas te stoor?
- Waar om statika te stoor, om nie gigagrepe statika in 'n klomp houers te plaas nie?
- Hoe sal die databasis werk?
Docker-beeld
Ons begin deur 'n Docker-beeld te bou.
Die ideale opsie is dat ons een universele beeld het, op grond daarvan kry ons werkerspeule, peule met Crontasks en opgradeer peule.
.
Dit bevat nginx, apache/php-fpm (kan tydens bou gekies word), msmtp vir die stuur van pos en cron.
Wanneer die prent saamgestel word, word die hele kodebasis van die webwerf na die /app-gids gekopieer (met die uitsondering van daardie dele wat ons na 'n aparte gedeelde berging sal skuif).
Mikrodienste, dienste
werker peule:
- Houer met nginx + houer apache/php-fpm + msmtp
- Dit het nie uitgewerk om msmtp na 'n aparte mikrodiens te skuif nie, Bitrix begin verontwaardig raak dat dit nie direk pos kan stuur nie
- Elke houer het 'n volledige kodebasis.
- Verbod op die verandering van kode in houers.
cron onder:
- houer met apache, php, cron
- volledige kodebasis ingesluit
- verbod op die verandering van kode in houers
opgradeer onder:
- nginx-houer + apache/php-fpm-houer + msmtp
- Daar is geen verbod op die verandering van kode in houers nie
sessie stoor
Bitrix-kasberging
Nog 'n belangrike ding: ons stoor wagwoorde om aan alles te koppel, van die databasis tot pos, in kubernetes-geheime. Ons kry 'n bonus: wagwoorde is slegs sigbaar vir diegene aan wie ons toegang tot die geheime gee, en nie vir almal wat toegang het tot die projek se kodebasis nie.
Berging vir statika
Jy kan enigiets gebruik: ceph, nfs (maar ons beveel nie nfs vir produksie aan nie), netwerkberging van wolkverskaffers, ens.
Die berging sal in houers gekoppel moet word aan die /upload/-gids van die werf en ander dopgehou met statiese inhoud.
databasis
Vir eenvoud beveel ons aan om die databasis buite Kubernetes te skuif. Die basis in Kubernetes is 'n aparte komplekse taak; dit sal die skema 'n orde van grootte meer kompleks maak.
Sessieberging
Ons gebruik memcached :)
Dit hanteer sessieberging goed, is gegroepeer, en word "natively" ondersteun as session.save_path in php. So 'n stelsel is al baie keer getoets in die klassieke monolitiese argitektuur, toe ons groepe met 'n groot aantal webbedieners gebou het. Vir ontplooiing gebruik ons stuur.
$ helm install stable/memcached --name sessionphp.ini - hier bevat die prent instellings vir die stoor van sessies in memcached
Ons het omgewingsveranderlikes gebruik om data oor gashere met memcached deur te gee .
Dit laat jou toe om dieselfde kode in die dev, stage, test, prod omgewings te gebruik (die memcached gasheer name in hulle sal anders wees, so ons moet 'n unieke gasheer naam vir sessies aan elke omgewing deurgee).
Bitrix-kasberging
Ons benodig foutverdraagsame berging waarna alle peule kan skryf en van lees.
Ons gebruik ook memcached.
Hierdie oplossing word deur Bitrix self aanbeveel.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - hier in Bitrix word gespesifiseer waar die kas gestoor word
Ons gebruik ook omgewingsveranderlikes.
Krontaski
Daar is verskillende benaderings om Crontasks in Kubernetes te bestuur.
- aparte ontplooiing met 'n pod om Crontasks te laat loop
- cronjob vir die uitvoering van crontasks (as dit 'n webtoepassing is - met wget , of kubectl exec binne een van die werkerspeule, ens.)
- ens.
Jy kan argumenteer oor die mees korrekte een, maar in hierdie geval het ons die opsie gekies "aparte ontplooiing met peule vir Crontasks"
Hoe dit gedoen word:
- voeg cron-take by via ConfigMap of via die config/addcron-lêer
- in een geval loods ons 'n houer wat identies is aan die werkerpeul + laat die uitvoering van kroontake daarin toe
- dieselfde kodebasis word gebruik, danksy eenwording is houersamestelling eenvoudig
Wat goed kry ons:
- ons het werkende Crontasks in 'n omgewing identies aan die ontwikkelaarsomgewing (doker)
- Crontasks hoef nie vir Kubernetes “herskryf” te word nie, hulle werk in dieselfde vorm en in dieselfde kodebasis as voorheen
- cron-take kan bygevoeg word deur alle spanlede met commit-regte tot die produksietak, nie net admins nie
Southbridge K8SDeploy module en kode redigering vanaf die admin paneel
Ons het gepraat van opgradering onder?
Hoe om verkeer daarheen te lei?
Hoera, ons het 'n module hiervoor in PHP geskryf :) Dit is 'n klein klassieke module vir Bitrix. Dit is nog nie publiek beskikbaar nie, maar ons beplan om dit oop te maak.
Die module word soos 'n gewone module in Bitrix geïnstalleer:
En dit lyk so:
Dit laat jou toe om 'n koekie te stel wat die werfadministrateur identifiseer en laat Kubernetes toe om verkeer na die opgraderingspod te stuur.
Wanneer die veranderinge voltooi is, moet jy op git push klik, die kodeveranderings sal na git gestuur word, dan sal die stelsel 'n prent met 'n nuwe weergawe van die kode bou en dit oor die groep "uitrol", en die ou peule vervang .
Ja, dit is 'n bietjie van 'n kruk, maar terselfdertyd handhaaf ons die mikrodiensargitektuur en neem nie Bitrix-gebruikers hul gunstelinggeleentheid weg om die kode van die administrasiepaneel reg te stel nie. Op die ou end is dit 'n opsie; jy kan die probleem oplos om die kode op 'n ander manier te wysig.
Roerkaart
Om toepassings op Kubernetes te bou, gebruik ons gewoonlik die Helm-pakketbestuurder.
Vir ons Bitrix-oplossing in Kubernetes, het Sergey Bondarev, ons voorste stelseladministrateur, 'n spesiale Helm-kaart geskryf.
Dit bou werker-, ugrade-, cron-peule, konfigureer ingange, dienste en dra veranderlikes van Kubernetes-geheime na peule oor.
Ons stoor die kode in Gitlab, en ons bestuur ook die Helm-bou vanaf Gitlab.
Kortom, dit lyk so
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm laat jou ook toe om 'n "naatlose" terugrol te doen as iets skielik tydens ontplooiing verkeerd gaan. Dit is lekker as jy nie paniekbevange is nie "maak die kode reg via ftp omdat die prod geval het," maar Kubernetes doen dit outomaties, en sonder stilstand.
Ontplooi
Ja, ons is aanhangers van Gitlab & Gitlab CI, ons gebruik dit :)
Wanneer Gitlab tot die projekbewaarplek verbind word, loods Gitlab 'n pyplyn wat 'n nuwe weergawe van die omgewing ontplooi.
Stadiums:
- bou (bou van 'n nuwe Docker-beeld)
- toets (toets)
- skoonmaak (verwydering van die toetsomgewing)
- druk (ons stuur dit na die Docker-register)
- ontplooi (ons ontplooi die toepassing na Kubernetes via Helm).
Hoera, dit is gereed, kom ons implementeer dit!
Wel, of vra vrae as daar enige is.
So wat het ons gedoen
Vanuit 'n tegniese oogpunt:
- gedokteriseerde Bitrix;
- "sny" Bitrix in houers, wat elkeen 'n minimum van funksies verrig;
- staatlose toestand van houers bereik het;
- het die probleem opgelos met die opdatering van Bitrix in Kubernetes;
- alle Bitrix-funksies het bly werk (byna almal);
- Ons het gewerk aan ontplooiing na Kubernetes en terugrol tussen weergawes.
Vanuit 'n besigheidsoogpunt:
- fout verdraagsaamheid;
- Kubernetes-nutsgoed (maklike integrasie met Gitlab CI, naatlose ontplooiing, ens.);
- geheime wagwoorde (slegs sigbaar vir diegene wat direk toegang tot die wagwoorde kry);
- Dit is gerieflik om bykomende omgewings (vir ontwikkeling, toetse, ens.) binne 'n enkele infrastruktuur te skep.
Bron: will.com