Southbridge huko Chelyabinsk na Bitrix huko Kubernetes

Mikutano ya wasimamizi wa mfumo wa Sysadminka inafanyika huko Chelyabinsk, na mwishowe nilitoa ripoti juu ya suluhisho letu la kuendesha programu kwenye 1C-Bitrix huko Kubernetes.

Bitrix, Kubernetes, Ceph - mchanganyiko mkubwa?

Nitakuambia jinsi tunavyoweka pamoja suluhisho la kufanya kazi kutoka kwa haya yote.

Hebu kwenda!

Southbridge huko Chelyabinsk na Bitrix huko Kubernetes

Mkutano ulifanyika mnamo Aprili 18 huko Chelyabinsk. Unaweza kusoma kuhusu mikutano yetu kwenye Timepad na tazama YouTube.

Ikiwa unataka kuja kwetu na ripoti au kama msikilizaji - karibu, tuandikie [barua pepe inalindwa] na kwenye Telegram t.me/vadikisakanov.

Ripoti yangu

Southbridge huko Chelyabinsk na Bitrix huko Kubernetes

Slaidi

Suluhisho "Bitrix katika Kubernetes, toleo la Southbridge 1.0"

Nitazungumza juu ya suluhisho letu katika umbizo la "kwa dummies katika Kubernetes", kama ilifanyika kwenye mkutano. Lakini nadhani unajua maneno Bitrix, Docker, Kubernetes, Ceph angalau katika kiwango cha vifungu kwenye Wikipedia.

Ni nini kimetengenezwa tayari kuhusu Bitrix huko Kubernetes?

Kuna habari kidogo sana kwenye Mtandao mzima kuhusu utendakazi wa programu za Bitrix katika Kubernetes.
Nilipata nyenzo hizi tu:

Ripoti ya Alexander Serbul, 1C-Bitrix, na Anton Tuzlukov kutoka Qsoft:

Ninapendekeza kuisikiliza.

Kutengeneza suluhisho lako mwenyewe kutoka kwa mtumiaji serkyron juu ya Habre.
Imepatikana zaidi uamuzi kama huo.

Aaand ... kwa kweli, hiyo ndiyo yote.

Ninakuonya, hatujaangalia ubora wa suluhisho kwenye viungo hapo juu :)
Kwa njia, wakati wa kuandaa suluhisho letu, nilizungumza na Alexander Serbul, basi ripoti yake ilikuwa bado haijaonekana, kwa hivyo kwenye slaidi zangu kuna kitu "Bitrix haitumii Kubernetes."

Lakini tayari kuna picha nyingi za Docker zilizotengenezwa tayari za kuendesha Bitrix kwenye Docker: https://hub.docker.com/search?q=bitrix&type=image

Hii inatosha kuunda suluhisho kamili kwa Bitrix huko Kubernetes?
Hapana. Kuna idadi kubwa ya matatizo ambayo yanahitaji kutatuliwa.

Je, ni matatizo gani ya Bitrix katika Kubernetes?

Kwanza, picha zilizotengenezwa tayari kutoka kwa Dockerhub hazifai Kubernetes

Ikiwa tunataka kujenga usanifu wa huduma ndogo (na katika Kubernetes huwa tunafanya), tunahitaji kutenganisha programu yetu ya Kubernetes kwenye vyombo na kila kontena litekeleze kazi moja ndogo (na kuifanya vizuri). Kwa nini moja tu? Kwa kifupi, rahisi zaidi ya kuaminika.
Ili kuwa maalum zaidi, tazama nakala hii na video, tafadhali: https://habr.com/ru/company/southbridge/blog/426637/

Picha za Docker katika Dockerhub zimejengwa kwa msingi wa kanuni ya yote kwa moja, kwa hivyo bado tulilazimika kutengeneza baiskeli yetu wenyewe na hata kuunda picha kutoka mwanzo.

Pili - msimbo wa tovuti umehaririwa kutoka kwa jopo la admin

Tuliunda sehemu mpya kwenye tovuti - msimbo ulisasishwa (saraka iliyo na jina la sehemu mpya iliongezwa).

Ikiwa ulibadilisha sifa za kipengee kutoka kwa paneli ya msimamizi, msimbo ulibadilika.

Kubernetes "kwa chaguo-msingi" haiwezi kufanya kazi na hii;

Sababu: Kila kontena (ganda) kwenye nguzo huchakata tu sehemu ya trafiki. Ikiwa unabadilisha msimbo katika chombo kimoja tu (pod), basi msimbo utakuwa tofauti katika pods tofauti, tovuti itafanya kazi tofauti, na matoleo tofauti ya tovuti yataonyeshwa kwa watumiaji tofauti. Huwezi kuishi hivyo.

Tatu - unahitaji kutatua suala hilo na kupelekwa

Ikiwa tuna seva ya monolith na moja ya "classic", kila kitu ni rahisi sana: tunapeleka msingi mpya wa nambari, kuhamisha hifadhidata, kubadili trafiki kwa toleo jipya la msimbo. Kubadilisha hutokea mara moja.
Ikiwa tuna tovuti huko Kubernetes, kata ndani ya huduma ndogo, kuna vyombo vingi vilivyo na msimbo - oh. Unahitaji kukusanya kontena zilizo na toleo jipya la msimbo, ziondoe badala ya zile za zamani, uhamishe hifadhidata kwa usahihi, na ufanye hivi bila kutambuliwa na wageni. Kwa bahati nzuri, Kubernetes hutusaidia na hili, kusaidia kundi zima la aina tofauti za upelekaji.

Nne - unahitaji kutatua suala la kuhifadhi statics

Ikiwa tovuti yako ni "pekee" gigabytes 10 na unaipeleka kabisa kwenye vyombo, utaishia na vyombo 10 vya gigabyte ambavyo huchukua milele kupelekwa.
Unahitaji kuhifadhi sehemu "nzito" za tovuti nje ya vyombo, na swali linatokea jinsi ya kufanya hivyo kwa usahihi.

Ni nini kinakosekana kutoka kwa suluhisho letu?

Nambari nzima ya Bitrix haijagawanywa katika microfuncs/microservices (ili usajili utenganishwe, moduli ya duka la mtandaoni ni tofauti, nk). Tunahifadhi msingi wote wa kanuni katika kila chombo.

Pia hatuhifadhi hifadhidata katika Kubernetes (bado nilitekeleza suluhu na hifadhidata katika Kubernetes kwa mazingira ya maendeleo, lakini si kwa ajili ya uzalishaji).

Bado itaonekana kwa wasimamizi wa tovuti kuwa tovuti inaendeshwa kwenye Kubernetes. Kazi ya "angalia mfumo" haifanyi kazi kwa usahihi; ili kuhariri msimbo wa tovuti kutoka kwa paneli ya msimamizi, lazima kwanza ubofye kitufe cha "Nataka kuhariri msimbo".

Shida zimegunduliwa, hitaji la kutekeleza huduma ndogo imedhamiriwa, lengo ni wazi - kupata mfumo wa kufanya kazi wa kuendesha programu kwenye Bitrix huko Kubernetes, kuhifadhi uwezo wote wa Bitrix na faida za Kubernetes. Tuanze utekelezaji.

usanifu

Kuna maganda mengi ya "kufanya kazi" na seva ya wavuti (wafanyakazi).
Moja chini na kazi za cron (moja tu inahitajika).
Uboreshaji mmoja wa kuhariri msimbo wa tovuti kutoka kwa paneli ya msimamizi (pia ni moja tu inahitajika).

Southbridge huko Chelyabinsk na Bitrix huko Kubernetes

Tunatatua maswali:

  • Mahali pa kuhifadhi vipindi?
  • Mahali pa kuhifadhi kache?
  • Wapi kuhifadhi statics, si kuweka gigabytes ya statics katika kundi la vyombo?
  • Je, hifadhidata itafanyaje kazi?

Picha ya Docker

Tunaanza kwa kujenga picha ya Docker.

Chaguo bora ni kwamba tuna picha moja ya ulimwengu wote, kwa msingi wake tunapata maganda ya wafanyikazi, maganda na Crontasks, na kuboresha maganda.

Tulitengeneza picha kama hiyo.

Inajumuisha nginx, apache/php-fpm (inaweza kuchaguliwa wakati wa kujenga), msmtp kwa kutuma barua, na cron.

Wakati wa kukusanya picha, msingi wote wa msimbo wa tovuti unakiliwa kwenye saraka ya programu (isipokuwa sehemu hizo ambazo tutahamia kwenye hifadhi tofauti iliyoshirikiwa).

Huduma ndogo, huduma

vifuniko vya wafanyikazi:

  • Chombo kilicho na nginx + chombo apache/php-fpm + msmtp
  • Haikufaulu kuhamisha msmtp kwenye huduma ndogo tofauti, Bitrix anaanza kukasirika kwamba haiwezi kutuma barua moja kwa moja.
  • Kila chombo kina codebase kamili.
  • Marufuku ya kubadilisha msimbo katika vyombo.

cron chini:

  • chombo kilicho na apache, php, cron
  • kamili code msingi pamoja
  • kupiga marufuku kubadilisha msimbo kwenye vyombo

sasisha chini ya:

  • chombo cha nginx + apache/php-fpm chombo + msmtp
  • Hakuna marufuku ya kubadilisha nambari kwenye vyombo

uhifadhi wa kikao

Hifadhi ya kashe ya Bitrix

Jambo lingine muhimu: tunahifadhi nywila za kuunganisha kwa kila kitu, kutoka kwa hifadhidata hadi barua, katika siri za kubernetes. Tunapata bonasi: nywila zinaonekana tu kwa wale ambao tunawapa ufikiaji wa siri, na sio kwa kila mtu anayeweza kufikia msingi wa msimbo wa mradi.

Hifadhi kwa tuli

Unaweza kutumia chochote: ceph, nfs (lakini hatupendekeza nfs kwa ajili ya uzalishaji), hifadhi ya mtandao kutoka kwa watoa huduma za wingu, nk.

Hifadhi itahitaji kuunganishwa katika vyombo kwenye /kupakia/ saraka ya tovuti na saraka nyingine zilizo na maudhui tuli.

Database

Kwa urahisi, tunapendekeza kuhamisha hifadhidata nje ya Kubernetes. Msingi katika Kubernetes ni kazi tofauti ngumu; itafanya mpango kuwa utaratibu wa ukubwa zaidi.

Hifadhi ya kikao

Tunatumia memcached :)

Inashughulikia uhifadhi wa kipindi vizuri, imeunganishwa, na inatumika "asili" kama session.save_path katika php. Mfumo huo umejaribiwa mara nyingi katika usanifu wa classical monolithic, wakati tulijenga makundi yenye idadi kubwa ya seva za mtandao. Kwa kupeleka tunatumia helm.

$ helm install stable/memcached --name session

php.ini - hapa picha ina mipangilio ya kuhifadhi vikao kwenye memcached

Tulitumia Vigeu vya Mazingira kupitisha data kuhusu wapangishaji na memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Hii hukuruhusu kutumia msimbo sawa katika mazingira ya dev, hatua, jaribio, uzalishaji (majina ya seva pangishi yaliyohifadhiwa ndani yake yatakuwa tofauti, kwa hivyo tunahitaji kupitisha jina la kipekee la mwenyeji kwa vipindi kwa kila mazingira).
Hifadhi ya kashe ya Bitrix

Tunahitaji hifadhi inayostahimili makosa ambayo maganda yote yanaweza kuandikia na kusoma.

Pia tunatumia memcached.
Suluhisho hili linapendekezwa na Bitrix yenyewe.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - hapa kwenye Bitrix imeelezwa ambapo cache imehifadhiwa

Pia tunatumia Vigezo vya Mazingira.

Krontaski

Kuna mbinu tofauti za kuendesha Crontasks huko Kubernetes.

  • uwekaji tofauti na ganda la kuendesha Crontasks
  • cronjob ya kutekeleza crontasks (ikiwa hii ni programu ya wavuti - iliyo na wget https://$host$cronjobname, au kubectl exec ndani ya moja ya maganda ya mfanyakazi, nk.)
  • nk

Unaweza kubishana juu ya moja sahihi zaidi, lakini katika kesi hii tulichagua chaguo "kupeleka tofauti na maganda ya Crontasks"

Jinsi imefanywa:

  • ongeza kazi za cron kupitia ConfigMap au kupitia faili ya usanidi/addcron
  • kwa mfano mmoja tunazindua chombo kinachofanana na ganda la mfanyakazi + kuruhusu utekelezaji wa kazi za taji ndani yake.
  • msingi huo wa nambari hutumiwa, shukrani kwa kuunganishwa, mkutano wa chombo ni rahisi

Ni nini kizuri tunachopata:

  • tuna Crontasks zinazofanya kazi katika mazingira sawa na mazingira ya watengenezaji (docker)
  • Crontasks hazihitaji "kuandikwa upya" kwa Kubernetes, hufanya kazi kwa fomu sawa na kwa msingi wa nambari sawa na hapo awali.
  • majukumu ya cron yanaweza kuongezwa na washiriki wote wa timu walio na haki za kujitolea kwa tawi la uzalishaji, sio wasimamizi tu

Moduli ya Southbridge K8SDDeploy na uhariri wa msimbo kutoka kwa paneli ya msimamizi

Tulikuwa tunazungumza juu ya uboreshaji chini?
Jinsi ya kuelekeza trafiki huko?
Hurray, tuliandika moduli kwa hili katika PHP :) Hii ni moduli ndogo ya classic kwa Bitrix. Bado haipatikani hadharani, lakini tunapanga kuifungua.
Moduli imewekwa kama moduli ya kawaida katika Bitrix:

Southbridge huko Chelyabinsk na Bitrix huko Kubernetes

Na inaonekana kama hii:

Southbridge huko Chelyabinsk na Bitrix huko Kubernetes

Inakuruhusu kuweka kidakuzi kinachomtambulisha msimamizi wa tovuti na kuruhusu Kubernetes kutuma trafiki kwenye ganda la uboreshaji.

Mabadiliko yanapokamilika, unahitaji kubofya git push, mabadiliko ya msimbo yatatumwa kwa git, kisha mfumo utaunda picha na toleo jipya la msimbo na "kuitoa" kwenye nguzo, ikibadilisha maganda ya zamani. .

Ndiyo, ni mkongojo kidogo, lakini wakati huo huo tunadumisha usanifu wa huduma ndogo na hatuwaondolei watumiaji wa Bitrix fursa wanayopenda ya kusahihisha msimbo kutoka kwa paneli ya msimamizi. Mwishoni, hii ni chaguo; unaweza kutatua tatizo la kuhariri msimbo kwa njia tofauti.

Chati ya usukani

Ili kuunda programu kwenye Kubernetes, sisi hutumia kidhibiti cha kifurushi cha Helm.
Kwa suluhisho letu la Bitrix huko Kubernetes, Sergey Bondarev, msimamizi wetu mkuu wa mfumo, aliandika chati maalum ya Helm.

Huunda mfanyakazi, kuboresha, cron pods, kusanidi ingresses, huduma, na uhamisho vigezo kutoka Kubernetes siri hadi pods.

Tunahifadhi msimbo katika Gitlab, na pia tunaendesha ujenzi wa Helm kutoka Gitlab.

Kwa kifupi, inaonekana kama hii

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

Helm pia hukuruhusu kufanya urejeshaji wa "imefumwa" ikiwa ghafla kitu kitaenda vibaya wakati wa kupeleka. Ni vizuri wakati huna hofu "rekebisha msimbo kupitia ftp kwa sababu prod ilianguka," lakini Kubernetes hufanya hivyo kiotomatiki, na bila muda wa chini.

Weka

Ndio, sisi ni mashabiki wa Gitlab & Gitlab CI, tunaitumia :)
Wakati wa kujitolea katika Gitlab kwenye hazina ya mradi, Gitlab inazindua bomba ambalo linatumia toleo jipya la mazingira.

Hatua:

  • jenga (kujenga picha mpya ya Docker)
  • mtihani (mtihani)
  • kusafisha (kuondoa mazingira ya mtihani)
  • kushinikiza (tunaituma kwa Usajili wa Docker)
  • peleka (tunapeleka programu kwa Kubernetes kupitia Helm).

Southbridge huko Chelyabinsk na Bitrix huko Kubernetes

Hurray, iko tayari, wacha tuitekeleze!
Kweli, au uulize maswali ikiwa kuna yoyote.

Kwa hiyo tulifanya nini

Kwa mtazamo wa kiufundi:

  • dockerized Bitrix;
  • "kata" Bitrix ndani ya vyombo, ambayo kila mmoja hufanya kazi ndogo;
  • kufikia hali ya kutokuwa na uraia ya makontena;
  • ilitatua tatizo kwa kusasisha Bitrix katika Kubernetes;
  • kazi zote za Bitrix ziliendelea kufanya kazi (karibu zote);
  • Tulifanya kazi ya kupeleka Kubernetes na kurejesha kati ya matoleo.

Kwa mtazamo wa biashara:

  • uvumilivu wa makosa;
  • Zana za Kubernetes (muunganisho rahisi na Gitlab CI, kupeleka bila mshono, nk);
  • nywila za siri (zinazoonekana tu kwa wale ambao wamepewa ufikiaji wa nywila moja kwa moja);
  • Inafaa kuunda mazingira ya ziada (ya ukuzaji, majaribio, n.k.) ndani ya miundombinu moja.

Chanzo: mapenzi.com

Kuongeza maoni