Sysadminka kerfisstjórafundir eru í gangi í Chelyabinsk og á þeim síðasta gaf ég skýrslu um lausn okkar til að keyra forrit á 1C-Bitrix í Kubernetes.
Bitrix, Kubernetes, Ceph - frábær blanda?
Ég skal segja þér hvernig við settum saman vinnulausn úr þessu öllu.
Við skulum fara!
Fundurinn fór fram 18. apríl í Chelyabinsk. Þú getur lesið um fundina okkar á og skoða .
Ef þú vilt koma til okkar með skýrslu eða sem hlustandi - velkominn, skrifaðu til [netvarið] og á Telegram t.me/vadimisakanov.
Skýrslan mín
Lausn "Bitrix í Kubernetes, útgáfa Southbridge 1.0"
Ég mun tala um lausnina okkar á „fyrir dúllur í Kubernetes“ sniði, eins og gert var á fundinum. En ég geri ráð fyrir að þú þekkir orðin Bitrix, Docker, Kubernetes, Ceph að minnsta kosti á stigi greina á Wikipedia.
Hvað er tilbúið um Bitrix í Kubernetes?
Það eru mjög litlar upplýsingar á öllu internetinu um rekstur Bitrix forrita í Kubernetes.
Ég fann bara þessi efni:
Skýrsla Alexander Serbul, 1C-Bitrix, og Anton Tuzlukov frá Qsoft:
Ég mæli með því að hlusta á það.
Að þróa þína eigin lausn frá notandanum .
Fann meira .
Aaand... reyndar, það er allt.
Ég vara þig við, við höfum ekki athugað gæði lausnanna í tenglum hér að ofan :)
Við the vegur, þegar ég undirbjó lausn okkar, talaði ég við Alexander Serbul, þá hafði skýrslan hans ekki enn birst, svo í glærunum mínum er hlutur „Bitrix notar ekki Kubernetes.
En það eru nú þegar til fullt af tilbúnum Docker myndum til að keyra Bitrix í Docker:
Er þetta nóg til að búa til heildarlausn fyrir Bitrix í Kubernetes?
Nei. Það er mikill fjöldi vandamála sem þarf að leysa.
Hver eru vandamálin með Bitrix í Kubernetes?
Í fyrsta lagi henta tilbúnar myndir frá Dockerhub ekki fyrir Kubernetes
Ef við viljum byggja örþjónustuarkitektúr (og það gerum við venjulega í Kubernetes), þurfum við að aðgreina Kubernetes forritið okkar í gáma og láta hvern gám framkvæma eina litla aðgerð (og gera það vel). Af hverju bara einn? Í stuttu máli, því einfaldara því áreiðanlegra.
Til að vera nákvæmari skaltu horfa á þessa grein og myndband, vinsamlegast:
Docker myndir í Dockerhub eru aðallega byggðar á allt-í-einn meginreglunni, svo við þurftum samt að búa til okkar eigin hjól og jafnvel búa til myndir frá grunni.
Í öðru lagi - síðukóðanum er breytt frá stjórnborðinu
Við bjuggum til nýjan hluta á síðunni - kóðinn var uppfærður (möppu með nafni nýja hlutans var bætt við).
Ef þú breyttir eiginleikum íhluta frá stjórnborðinu breyttist kóðinn.
Kubernetes „sjálfgefið“ getur ekki unnið með þetta; gámar verða að vera ríkisfangslausir.
Ástæða: Hver ílát (belgur) í þyrpingunni vinnur aðeins hluta af umferðinni. Ef þú breytir kóðanum í aðeins einum íláti (pod), þá verður kóðinn öðruvísi í mismunandi pods, síðan mun virka öðruvísi og mismunandi útgáfur af síðunni verða sýndar mismunandi notendum. Þú getur ekki lifað svona.
Í þriðja lagi - þú þarft að leysa málið með dreifingu
Ef við erum með einliða og einn „klassískan“ netþjón er allt frekar einfalt: við setjum upp nýjan kóðagrunn, flytjum gagnagrunninn, skiptum um umferð yfir í nýju útgáfuna af kóðanum. Skipting á sér stað samstundis.
Ef við erum með síðu í Kubernetes, skera í örþjónustur, þá eru fullt af gámum með kóða - ó. Þú þarft að safna gámum með nýrri útgáfu af kóðanum, rúlla þeim út í stað þeirra gömlu, flytja gagnagrunninn rétt, og helst gera þetta án þess að gestir sjái það. Sem betur fer hjálpar Kubernetes okkur með þetta og styður fullt af mismunandi tegundum dreifingar.
Í fjórða lagi - þú þarft að leysa vandamálið um að geyma truflanir
Ef vefsíðan þín er „aðeins“ 10 gígabæta og þú setur hana algjörlega í gáma, muntu endar með 10 gígabæta gáma sem tekur eilífð að dreifa.
Þú þarft að geyma „þyngstu“ hluta síðunnar utan gáma og spurningin vaknar um hvernig á að gera þetta rétt
Hvað vantar í lausnina okkar?
Allur Bitrix kóðann er ekki skipt í öraðgerðir/örþjónustur (svo að skráning er aðskilin, netverslunareiningin aðskilin o.s.frv.). Við geymum allan kóðagrunninn í hverjum íláti.
Við geymum heldur ekki gagnagrunninn í Kubernetes (ég innleiddi samt lausnir með gagnagrunni í Kubernetes fyrir þróunarumhverfi, en ekki fyrir framleiðslu).
Það mun samt vera áberandi fyrir síðustjórnendur að síðan keyrir á Kubernetes. „Kerfaskoðun“ aðgerðin virkar ekki rétt; til að breyta síðukóðanum frá stjórnborðinu verður þú fyrst að smella á „Ég vil breyta kóðanum“ hnappinn.
Vandamálin hafa verið greind, þörfin á að innleiða örþjónustu hefur verið ákveðin, markmiðið er skýrt - að fá vinnukerfi til að keyra forrit á Bitrix í Kubernetes, varðveita bæði getu Bitrix og kosti Kubernetes. Hefjum framkvæmdina.
arkitektúr
Það eru margir „vinnandi“ belg með vefþjóni (starfsmenn).
Einn undir með cron verkefni (aðeins eitt er krafist).
Ein uppfærsla til að breyta vefkóðanum frá stjórnborðinu (einnig er aðeins krafist).
Við leysum spurningar:
- Hvar á að geyma fundi?
- Hvar á að geyma skyndiminni?
- Hvar á að geyma truflanir, ekki að setja gígabæta af truflanir í fullt af ílátum?
- Hvernig mun gagnagrunnurinn virka?
Docker mynd
Við byrjum á því að byggja Docker mynd.
Kjörinn valkostur er að við höfum eina alhliða mynd, á grundvelli hennar fáum við vinnubelg, fræbelg með Crontasks og uppfærslubelg.
.
Það inniheldur nginx, apache/php-fpm (hægt að velja meðan á byggingu stendur), msmtp til að senda póst og cron.
Þegar myndin er sett saman er allur kóðagrunnur síðunnar afritaður í /app möppuna (að undanskildum þeim hlutum sem við munum færa í sérstaka sameiginlega geymslu).
Örþjónusta, þjónusta
verkamannabelgur:
- Gámur með nginx + gáma apache/php-fpm + msmtp
- Það gekk ekki upp að færa msmtp yfir í sérstaka örþjónustu, Bitrix er farin að verða reið yfir því að geta ekki sent póst beint
- Hver gámur hefur heilan kóðagrunn.
- Bann við að breyta kóða í gámum.
cron undir:
- ílát með apache, php, cron
- heill kóðagrunnur fylgir
- bann við að breyta kóða í gámum
uppfærsla undir:
- nginx gámur + apache/php-fpm gámur + msmtp
- Það er ekkert bannað að breyta kóða í gámum
fundur geymsla
Bitrix skyndiminni geymsla
Annar mikilvægur hlutur: við geymum lykilorð til að tengjast öllu, frá gagnagrunni til pósts, í kubernetes leyndarmálum. Við fáum bónus: lykilorð eru aðeins sýnileg þeim sem við veitum aðgang að leyndarmálum en ekki öllum sem hafa aðgang að kóðagrunni verkefnisins.
Geymsla fyrir truflanir
Þú getur notað hvað sem er: ceph, nfs (en við mælum ekki með nfs til framleiðslu), netgeymslu frá skýjaveitum osfrv.
Geymslan þarf að vera tengd í gámum við /upload/ möppuna á síðunni og aðrar möppur með kyrrstæðu efni.
Gagnagrunnur
Til einföldunar mælum við með að færa gagnagrunninn út fyrir Kubernetes. Grunnurinn í Kubernetes er sérstakt flókið verkefni; það mun gera kerfið að stærðargráðu flóknara.
Session geymsla
Við notum memcached :)
Það höndlar lotugeymslu vel, er þyrpað og er stutt „natively“ sem session.save_path í php. Slíkt kerfi hefur margsinnis verið prófað í klassískum monolithic arkitektúr, þegar við byggðum klasa með miklum fjölda vefþjóna. Við uppsetningu notum við stýri.
$ helm install stable/memcached --name sessionphp.ini - hér inniheldur myndin stillingar til að geyma lotur í memcached
Við notuðum umhverfisbreytur til að senda gögn um vélar með memcached .
Þetta gerir þér kleift að nota sama kóða í dev, stage, test, prod umhverfinu (memcached host nöfnin í þeim verða mismunandi, þannig að við þurfum að senda einstakt host nafn fyrir lotur í hvert umhverfi).
Bitrix skyndiminni geymsla
Við þurfum bilanaþolna geymslu sem allir belg geta skrifað í og lesið úr.
Við notum líka memcached.
Bitrix sjálft mælir með þessari lausn.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - hér í Bitrix er tilgreint hvar skyndiminni er geymt
Við notum líka umhverfisbreytur.
Krontaski
Það eru mismunandi aðferðir við að keyra Crontasks í Kubernetes.
- aðskilin dreifing með belg til að keyra Crontasks
- cronjob til að framkvæma crontasks (ef þetta er vefforrit - með wget , eða kubectl exec inni í einum af verkamannabekkjunum osfrv.)
- o.fl.
Þú getur deilt um það réttasta, en í þessu tilfelli völdum við valkostinn „aðskilin dreifing með belg fyrir Crontasks“
Hvernig það er gert:
- bæta við cron verkefnum í gegnum ConfigMap eða í gegnum config/addcron skrána
- í einu tilviki ræsum við ílát sem er eins og verkamannabelgurinn + leyfum framkvæmd kórónuverkefna í honum
- sami kóðagrunnurinn er notaður, þökk sé sameiningu er samsetning gáma einföld
Það sem við fáum gott:
- við erum með Crontasks að vinna í umhverfi sem er eins og umhverfi þróunaraðila (bryggju)
- Crontasks þarf ekki að „endurskrifa“ fyrir Kubernetes, þau vinna á sama formi og í sama kóðagrunni og áður
- cron verkefni geta verið bætt við af öllum liðsmönnum með skuldbindingarréttindi í framleiðslugreininni, ekki bara stjórnendum
Southbridge K8SDeploy einingu og kóða klippingu frá stjórnborðinu
Við vorum að tala um uppfærslu undir?
Hvernig á að beina umferð þangað?
Húrra, við skrifuðum mát fyrir þetta í PHP :) Þetta er lítil klassísk mát fyrir Bitrix. Það er ekki enn aðgengilegt almenningi, en við ætlum að opna það.
Einingin er sett upp eins og venjuleg eining í Bitrix:
Og það lítur svona út:
Það gerir þér kleift að setja vafraköku sem auðkennir síðustjórann og gerir Kubernetes kleift að senda umferð á uppfærslustöðina.
Þegar breytingunum er lokið þarftu að smella á git push, kóðabreytingarnar verða sendar til git, síðan mun kerfið byggja mynd með nýrri útgáfu af kóðanum og „rúlla“ henni út um þyrpinguna og kemur í stað gömlu belgjanna .
Já, það er smá hækja, en á sama tíma höldum við örþjónustuarkitektúrnum og tökum ekki frá Bitrix notendum uppáhalds tækifærið þeirra til að leiðrétta kóðann frá stjórnborðinu. Að lokum er þetta valkostur; þú getur leyst vandamálið við að breyta kóðanum á annan hátt.
Hjálmarkort
Til að byggja forrit á Kubernetes notum við venjulega Helm pakkastjórann.
Fyrir Bitrix lausnina okkar í Kubernetes skrifaði Sergey Bondarev, leiðandi kerfisstjóri okkar, sérstakt Helm töflu.
Það smíðar starfsmann, ugrade, cron belg, stillir innrásir, þjónustur og flytur breytur frá Kubernetes leyndarmálum yfir í belg.
Við geymum kóðann í Gitlab og keyrum líka Helm buildið frá Gitlab.
Í stuttu máli lítur þetta svona út
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm gerir þér einnig kleift að gera „óaðfinnanlega“ afturköllun ef skyndilega eitthvað fer úrskeiðis við uppsetningu. Það er fínt þegar þú ert ekki í læti „lagaðu kóðann í gegnum ftp vegna þess að prod féll,“ en Kubernetes gerir það sjálfkrafa og án niður í miðbæ.
Dreifa
Já, við erum aðdáendur Gitlab & Gitlab CI, við notum það :)
Þegar þú skuldbindur sig í Gitlab til verkefnageymslunnar setur Gitlab af stað leiðslu sem setur upp nýja útgáfu af umhverfinu.
Stig:
- byggja (byggja nýja Docker mynd)
- próf (prófun)
- hreinsa upp (fjarlægja prófunarumhverfið)
- ýta (við sendum það til Docker registry)
- dreifa (við sendum forritið til Kubernetes í gegnum Helm).
Húrra, það er tilbúið, við skulum útfæra það!
Jæja, eða spurðu spurninga ef það eru einhverjar.
Svo hvað gerðum við
Frá tæknilegu sjónarhorni:
- dockerized Bitrix;
- „skera“ Bitrix í ílát, sem hver um sig sinnir lágmarksaðgerðum;
- náð ríkisfangslausu ástandi gáma;
- leysti vandamálið með að uppfæra Bitrix í Kubernetes;
- allar Bitrix aðgerðir héldu áfram að virka (nánast allar);
- Við unnum að uppsetningu á Kubernetes og afturköllun á milli útgáfur.
Frá viðskiptalegu sjónarhorni:
- bilanaþol;
- Kubernetes verkfæri (auðveld samþætting við Gitlab CI, óaðfinnanlegur dreifing osfrv);
- leyndarmál lykilorð (aðeins sýnilegt þeim sem hafa beinan aðgang að lykilorðunum);
- Það er þægilegt að búa til viðbótarumhverfi (til þróunar, prófana osfrv.) innan eins innviða.
Heimild: www.habr.com