Dienvidu tilts Čeļabinskā un Bitriks Kubernetes pilsētā

Sysadminka sistēmas administratora tikÅ”anās notiek Čeļabinskā, un pēdējā es sniedzu ziņojumu par mÅ«su risinājumu lietojumprogrammu palaiÅ”anai 1C-Bitrix Kubernetes.

Bitrix, Kubernetes, Ceph - lielisks maisījums?

Es jums pastāstÄ«Å”u, kā mēs no tā visa izveidojām funkcionējoÅ”u risinājumu.

Iesim!

Dienvidu tilts Čeļabinskā un Bitriks Kubernetes pilsētā

TikÅ”anās notika 18. aprÄ«lÄ« Čeļabinskā. Par mÅ«su tikÅ”anām varat lasÄ«t vietnē Timepad un paskaties YouTube.

Ja vēlies nākt pie mums ar referātu vai kā klausītājs - laipni lūdzam, raksti uz [e-pasts aizsargāts] un Telegram t.me/vadimisakanov.

Mans ziņojums

Dienvidu tilts Čeļabinskā un Bitriks Kubernetes pilsētā

Slaidi

Risinājums "Bitrix in Kubernetes, versija Southbridge 1.0"

Par mÅ«su risinājumu es runāŔu formātā ā€œmanekeniem Kubernetesā€, kā tas tika darÄ«ts tikÅ”anās reizē. Bet pieņemu, ka vārdus Bitrix, Docker, Kubernetes, Ceph tu zini vismaz Vikipēdijas rakstu lÄ«menÄ«.

Kas ir gatavs par Bitrix pakalpojumā Kubernetes?

Visā internetā ir ļoti maz informācijas par Bitrix lietojumprogrammu darbību Kubernetes.
Es atradu tikai Ŕādus materiālus:

Aleksandra Serbuļa, 1C-Bitrix un Antona Tuzlukova ziņojums no Qsoft:

Iesaku noklausīties.

Sava risinājuma izstrāde no lietotāja puses serkyron uz Habrē.
Atrasts vairāk tāds lēmums.

Ā un... patiesībā tas arī viss.

BrÄ«dinu, mēs neesam pārbaudÄ«juÅ”i augstāk esoÅ”ajās saitēs esoÅ”o risinājumu kvalitāti :)
Starp citu, gatavojot mÅ«su risinājumu, es runāju ar Aleksandru Serbulu, tad viņa ziņojums vēl nebija parādÄ«jies, tāpēc manos slaidos ir vienums ā€œBitrix neizmanto Kubernetesā€.

Bet jau ir daudz gatavu Docker attēlu, lai palaistu Bitrix programmā Docker: https://hub.docker.com/search?q=bitrix&type=image

Vai ar to pietiek, lai izveidotu pilnīgu Bitrix risinājumu Kubernetes?
Nē. Ir liels skaits problēmu, kas ir jāatrisina.

Kādas ir Bitrix problēmas Kubernetes?

Pirmkārt, gatavie attēli no Dockerhub nav piemēroti Kubernetes

Ja mēs vēlamies izveidot mikropakalpojumu arhitektÅ«ru (un Kubernetes mēs to parasti darām), mums ir jāsadala mÅ«su Kubernetes lietojumprogramma konteineros un katram konteineram jāveic viena neliela funkcija (un tas jādara labi). Kāpēc tikai viens? ÄŖsāk sakot, jo vienkārŔāk, jo uzticamāk.
Lai būtu precīzāk, skatiet Ŕo rakstu un videoklipu, lūdzu: https://habr.com/ru/company/southbridge/blog/426637/

Docker attēli programmā Dockerhub galvenokārt ir veidoti pēc "viss vienā" principa, tāpēc mums joprojām bija jāizveido savs velosipēds un pat jāizveido attēli no nulles.

Otrkārt - vietnes kods tiek rediģēts no admin paneļa

Vietnē izveidojām jaunu sadaļu - kods tika atjaunināts (tika pievienots direktorijs ar jaunās sadaļas nosaukumu).

Ja administrÄ“Å”anas panelÄ« mainÄ«jāt komponenta rekvizÄ«tus, kods mainÄ«jās.

Kubernetes ā€œpēc noklusējumaā€ ar to nevar darboties; konteineriem jābÅ«t bezvalstniekiem.

Iemesls: katrs klastera konteiners (pods) apstrādā tikai daļu datplūsmas. Ja maināt kodu tikai vienā konteinerā (pod), tad kods būs atŔķirīgs dažādos aplikumos, vietne darbosies atŔķirīgi, un dažādiem lietotājiem tiks rādītas dažādas vietnes versijas. Jūs nevarat tā dzīvot.

TreÅ”kārt - jums ir jāatrisina problēma ar izvietoÅ”anu

Ja mums ir monolÄ«ts un viens ā€œklasisksā€ serveris, viss ir pavisam vienkārÅ”i: izvietojam jaunu kodu bāzi, migrējam datu bāzi, pārslēdzam trafiku uz jauno koda versiju. PārslēgÅ”anās notiek uzreiz.
Ja mums ir vietne Kubernetes, sagriezta mikropakalpojumos, ir daudz konteineru ar kodu - ak. Jums ir jāapkopo konteineri ar jaunu koda versiju, tie jāizlaiž veco vietā, pareizi jāmigrē datu bāze, un ideālā gadÄ«jumā tas jādara, apmeklētājiem nepamanot. Par laimi, Kubernetes mums palÄ«dz Å”ajā jautājumā, atbalstot veselu virkni dažādu izvietoÅ”anas veidu.

Ceturtkārt - jums jāatrisina statikas saglabāŔanas jautājums

Ja jÅ«su vietne ir ā€œtikaiā€ 10 gigabaiti un jÅ«s to pilnÄ«bā izvietojat konteineros, jÅ«s iegÅ«sit 10 gigabaitu konteinerus, kuru izvietoÅ”ana prasÄ«s visu laiku.
Vietnes ā€œsmagākāsā€ daļas ir jāuzglabā ārpus konteineriem, un rodas jautājums, kā to izdarÄ«t pareizi.

Kas trūkst mūsu risinājumam?

Viss Bitrix kods nav sadalÄ«ts mikrofunkcijās/mikropakalpojumos (lai reÄ£istrācija bÅ«tu atseviŔķa, interneta veikala modulis ir atseviŔķs utt.). Mēs glabājam visu koda bāzi katrā konteinerā.

Mēs arÄ« neuzglabājam datubāzi Kubernetes (es joprojām ieviesu risinājumus ar datu bāzi Kubernetes izstrādes vidēm, bet ne ražoÅ”anai).

Vietņu administratori joprojām bÅ«s pamanāmi, ka vietne darbojas Kubernetes. Funkcija ā€œSistēmas pārbaudeā€ nedarbojas pareizi; lai rediģētu vietnes kodu no administratora paneļa, vispirms jānoklikŔķina uz pogas ā€œEs vēlos rediģēt koduā€.

Problēmas ir apzinātas, mikropakalpojumu ievieÅ”anas nepiecieÅ”amÄ«ba noteikta, mērÄ·is skaidrs - iegÅ«t funkcionējoÅ”u sistēmu aplikāciju darbināŔanai uz Bitrix uz Kubernetes, saglabājot gan Bitrix iespējas, gan Kubernetes priekÅ”rocÄ«bas. Sāksim ievieÅ”anu.

Arhitektūra

Ir daudz ā€œstrādājoÅ”uā€ pākstu ar tÄ«mekļa serveri (darbiniekiem).
Viens zem ar cron uzdevumiem (nepiecieŔams tikai viens).
Viens jauninājums vietnes koda rediģēŔanai no administratora paneļa (arÄ« ir nepiecieÅ”ams tikai viens).

Dienvidu tilts Čeļabinskā un Bitriks Kubernetes pilsētā

Mēs risinām jautājumus:

  • Kur uzglabāt sesijas?
  • Kur glabāt keÅ”atmiņu?
  • Kur glabāt statiku, nevis ievietot gigabaitus statikas konteineru gÅ«zmā?
  • Kā datubāze darbosies?

Docker attēls

Mēs sākam ar Docker attēla izveidi.

Ideāls variants ir tāds, ka mums ir viens universāls attēls, uz kura pamata mēs iegūstam strādnieku, Crontasks un jauninājumu komplektus.

Mēs izveidojām tieÅ”i Ŕādu attēlu.

Tas ietver nginx, apache/php-fpm (var izvēlēties veidoÅ”anas laikā), msmtp pasta sÅ«tÄ«Å”anai un cron.

Saliekot attēlu, visa vietnes koda bāze tiek kopēta /app direktorijā (izņemot tās daļas, kuras pārvietosim uz atseviŔķu koplietojamo krātuvi).

Mikropakalpojumi, pakalpojumi

strādnieku pākstis:

  • Konteiners ar nginx + konteiners apache/php-fpm + msmtp
  • Neizdevās pārvietot msmtp uz atseviŔķu mikropakalpojumu, Bitrix sāk bÅ«t saÅ”utis, ka nevar tieÅ”i nosÅ«tÄ«t pastu
  • Katram konteineram ir pilnÄ«ga kodu bāze.
  • Aizliegums mainÄ«t kodu konteineros.

cron zem:

  • konteiners ar apache, php, cron
  • iekļauta pilnÄ«ga koda bāze
  • aizliegums mainÄ«t kodu konteineros

jaunināŔana zem:

  • nginx konteiners + apache/php-fpm konteiners + msmtp
  • Nav aizliegts mainÄ«t kodu konteineros

sesijas krātuve

Bitrix keÅ”atmiņas krātuve

Vēl viena svarÄ«ga lieta: paroles, lai izveidotu savienojumu ar visu, no datu bāzes lÄ«dz pastam, mēs glabājam kubernetes noslēpumos. Mēs saņemam bonusu: paroles ir redzamas tikai tiem, kam pieŔķiram piekļuvi noslēpumiem, nevis visiem, kam ir pieeja projekta kodu bāzei.

Krātuve statikai

Varat izmantot jebko: ceph, nfs (bet mēs neiesakām nfs ražoÅ”anai), tÄ«kla krātuvi no mākoņpakalpojumu sniedzējiem utt.

Krātuve būs jāsavieno konteineros ar vietnes direktoriju /upload/ un citiem direktorijiem ar statisku saturu.

Datu bāze

VienkārŔības labad mēs iesakām pārvietot datu bāzi ārpus Kubernetes. Kubernetes bāze ir atseviŔķs sarežģīts uzdevums; tas padarÄ«s shēmu par lielumu sarežģītāku.

Sesiju krātuve

Izmantojam memcached :)

Tas labi apstrādā sesiju krātuvi, ir grupēts un tiek ā€œnativelyā€ atbalstÄ«ts kā session.save_path php. Šāda sistēma ir daudzkārt pārbaudÄ«ta klasiskajā monolÄ«tajā arhitektÅ«rā, kad mēs veidojām klasterus ar lielu skaitu tÄ«mekļa serveru. IzvietoÅ”anai mēs izmantojam stÅ«ri.

$ helm install stable/memcached --name session

php.ini - Å”eit attēlā ir iestatÄ«jumi sesiju glabāŔanai memcached

Mēs izmantojām vides mainīgos, lai nodotu datus par saimniekdatoriem ar memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Tas ļauj izmantot vienu un to paÅ”u kodu izstrādes, stadijas, testa, prod vidēs (atmiņā saglabātie resursdatora nosaukumi tajās bÅ«s atŔķirÄ«gi, tāpēc mums katrai videi ir jānodod unikāls resursdatora nosaukums sesijām).
Bitrix keÅ”atmiņas krātuve

Mums ir nepiecieÅ”ama kļūmēm izturÄ«ga krātuve, kurā visi podi var rakstÄ«t un lasÄ«t.

Mēs arī izmantojam memcached.
Šo risinājumu iesaka pats Bitrix.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - Å”eit Bitrix ir norādÄ«ts, kur tiek glabāta keÅ”atmiņa

Mēs izmantojam arī vides mainīgos.

Krontaski

Crontasks palaiŔanai Kubernetes ir dažādas pieejas.

  • atseviŔķa izvietoÅ”ana ar podziņu Crontasks palaiÅ”anai
  • cronjob crontasks izpildei (ja Ŕī ir tÄ«mekļa lietotne - ar wget https://$host$cronjobname, vai kubectl exec vienā no darbinieka podiem utt.)
  • un tā joprojām

JÅ«s varat strÄ«dēties par pareizāko, taču Å”ajā gadÄ«jumā mēs izvēlējāmies opciju ā€œatseviŔķa izvietoÅ”ana ar podiem Crontasksā€.

Kā tas tiek darīts:

  • pievienojiet cron uzdevumus, izmantojot ConfigMap vai failu config/addcron
  • vienā gadÄ«jumā mēs palaižam konteineru, kas ir identisks worker pod + ļaujam tajā izpildÄ«t crown uzdevumus
  • tiek izmantota tā pati koda bāze, pateicoties unifikācijai, konteinera montāža ir vienkārÅ”a

Ko mēs iegūstam:

  • mums ir darba Crontasks vidē, kas ir identiska izstrādātāju videi (docker)
  • Kubernetes Crontaski nav ā€œjāpārrakstaā€, tie darbojas tādā paŔā formā un tajā paŔā kodu bāzē kā iepriekÅ”
  • cron uzdevumus var pievienot visi komandas dalÄ«bnieki ar saistÄ«bu tiesÄ«bām ražoÅ”anas filiālei, ne tikai administratori

Southbridge K8SDeploy moduļa un koda rediģēŔanu no administratora paneļa

Mēs runājām par jaunināŔanu saskaņā ar?
Kā tur novirzīt satiksmi?
Urā, Å”im mēs uzrakstÄ«jām moduli PHP :) Å is ir mazs klasisks modulis priekÅ” Bitrix. Tas vēl nav publiski pieejams, taču plānojam to atvērt.
Modulis ir instalēts kā parasts modulis Bitrix:

Dienvidu tilts Čeļabinskā un Bitriks Kubernetes pilsētā

Un tas izskatās Ŕādi:

Dienvidu tilts Čeļabinskā un Bitriks Kubernetes pilsētā

Tas ļauj iestatÄ«t sÄ«kfailu, kas identificē vietnes administratoru, un ļauj Kubernetes nosÅ«tÄ«t trafiku uz jaunināŔanas bloku.

Kad izmaiņas ir pabeigtas, jums jānoklikŔķina uz git push, koda izmaiņas tiks nosÅ«tÄ«tas uz git, pēc tam sistēma izveidos attēlu ar jaunu koda versiju un ā€œizlaidÄ«sā€ to klasterÄ«, aizstājot vecās podi. .

Jā, tas ir nedaudz apgrÅ«tinoÅ”s, taču tajā paŔā laikā mēs uzturam mikropakalpojumu arhitektÅ«ru un neatņemam Bitrix lietotājiem viņu iecienÄ«tāko iespēju labot kodu no administratora paneļa. Galu galā Ŕī ir iespēja; jÅ«s varat atrisināt koda rediģēŔanas problēmu citādā veidā.

Stūres diagramma

Lai izveidotu lietojumprogrammas Kubernetes, mēs parasti izmantojam Helm pakotņu pārvaldnieku.
MÅ«su vadoÅ”ais sistēmas administrators Sergejs Bondarevs mÅ«su Bitrix risinājumam Kubernetes uzrakstÄ«ja Ä«paÅ”u Helm diagrammu.

Tas veido Worker, Ugrade, Cron pods, konfigurē ieejas, pakalpojumus un pārsūta mainīgos no Kubernetes noslēpumiem uz podiem.

Mēs glabājam kodu Gitlab, kā arī palaižam Helm būvējumu no Gitlab.

ÄŖsāk sakot, tas izskatās Ŕādi

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

Helm arÄ« ļauj veikt ā€œnevainojamuā€ atcelÅ”anu, ja izvietoÅ”anas laikā pēkŔņi kaut kas noiet greizi. Ir jauki, ja neesat panikā ā€œlabojiet kodu, izmantojot ftp, jo prod nokritaā€, bet Kubernetes to dara automātiski un bez dÄ«kstāves.

Izvietot

Jā, mēs esam Gitlab & Gitlab CI fani, mēs to izmantojam :)
Kad Gitlab pievienojas projekta repozitorijai, Gitlab palaiž konveijeru, kas izvieto jaunu vides versiju.

Posmi:

  • veidot (jauna Docker attēla izveide)
  • pārbaude (pārbaude)
  • notÄ«rÄ«t (pārbaudes vides noņemÅ”ana)
  • push (mēs to nosÅ«tām uz Docker reÄ£istru)
  • izvietot (mēs izvietojam lietojumprogrammu Kubernetes, izmantojot Helm).

Dienvidu tilts Čeļabinskā un Bitriks Kubernetes pilsētā

Urā, gatavs, īstenosim!
Nu, vai uzdodiet jautājumus, ja tādi ir.

Tātad, ko mēs darījām

No tehniskā viedokļa:

  • dokerizēts Bitrix;
  • ā€œsagriežā€ Bitrix konteineros, no kuriem katrs veic minimālu funkciju;
  • sasniegts konteineru bezvalsts stāvoklis;
  • atrisināja problēmu ar Bitrix atjaunināŔanu Kubernetes;
  • visas Bitrix funkcijas turpināja darboties (gandrÄ«z visas);
  • Mēs strādājām pie izvietoÅ”anas Kubernetes un atgrieÅ”anās starp versijām.

No biznesa viedokļa:

  • defektu tolerance;
  • Kubernetes rÄ«ki (ērta integrācija ar Gitlab CI, netraucēta izvietoÅ”ana utt.);
  • slepenas paroles (redzamas tikai tiem, kam ir tieÅ”i pieŔķirta piekļuve parolēm);
  • Ir ērti izveidot papildu vides (izstrādei, testiem utt.) vienā infrastruktÅ«rā.

Avots: www.habr.com

Pievieno komentāru