Sysadminka systeembehearder meetups binne plak yn Chelyabinsk, en by de lêste joech ik in rapport oer ús oplossing foar it útfieren fan applikaasjes op 1C-Bitrix yn Kubernetes.
Bitrix, Kubernetes, Ceph - in geweldige mingsel?
Ik sil jo fertelle hoe't wy in wurkjende oplossing út dit alles sette.
Lit ús gean!
De gearkomste fûn plak op 18 april yn Chelyabinsk. Jo kinne lêze oer ús moetings op en sjoch .
Wolle jo by ús komme mei in ferslach of as harker - wolkom, skriuw nei [e-post beskerme] en op Telegram t.me/vadimisakanov.
Myn ferslach
Oplossing "Bitrix yn Kubernetes, ferzje Southbridge 1.0"
Ik sil prate oer ús oplossing yn it "foar dummies yn Kubernetes"-formaat, lykas dien waard by de gearkomste. Mar ik nim oan dat jo de wurden Bitrix, Docker, Kubernetes, Ceph op syn minst op it nivo fan artikels op Wikipedia kenne.
Wat is klear makke oer Bitrix yn Kubernetes?
D'r is heul min ynformaasje op it heule ynternet oer de wurking fan Bitrix-applikaasjes yn Kubernetes.
Ik fûn allinich dizze materialen:
Ferslach fan Alexander Serbul, 1C-Bitrix, en Anton Tuzlukov fan Qsoft:
Ik riede oan harkje nei it.
It ûntwikkeljen fan jo eigen oplossing fan 'e brûker .
Mear fûn .
Aaand... eins, dat is alles.
Ik warskôgje jo, wy hawwe de kwaliteit fan 'e oplossingen net kontrolearre yn' e boppesteande keppelings :)
Trouwens, by it tarieden fan ús oplossing, praat ik mei Alexander Serbul, doe't syn rapport noch net ferskynde, dus yn myn dia's is d'r in item "Bitrix brûkt gjin Kubernetes."
Mar d'r binne al in protte klearmakke Docker-ôfbyldings foar it útfieren fan Bitrix yn Docker:
Is dit genôch om in folsleine oplossing foar Bitrix yn Kubernetes te meitsjen?
Nee. Der binne in grut tal problemen dy't oplost wurde moatte.
Wat binne de problemen mei Bitrix yn Kubernetes?
Earst binne klearmakke ôfbyldings fan Dockerhub net geskikt foar Kubernetes
As wy in arsjitektuer foar mikrotsjinsten bouwe wolle (en yn Kubernetes dogge wy normaal), moatte wy ús Kubernetes-applikaasje yn konteners skiede en elke kontener ien lytse funksje útfiere (en it goed dwaan). Wêrom mar ien? Koartsein, hoe ienfâldiger, hoe betrouberer.
Om mear spesifyk te wêzen, besjoch dit artikel en fideo, asjebleaft:
Docker-ôfbyldings yn Dockerhub binne benammen boud op it alles-yn-ien-prinsipe, dus wy moasten noch ús eigen fyts meitsje en sels ôfbyldings meitsje fanôf it begjin.
Twadde - de sidekoade wurdt bewurke fanút it adminpaniel
Wy hawwe in nije seksje op 'e side makke - de koade is bywurke (in map mei de namme fan' e nije seksje is tafoege).
As jo de eigenskippen fan in komponint fan it adminpaniel feroare hawwe, is de koade feroare.
Kubernetes "standert" kin hjirmei net wurkje; konteners moatte steatleas wêze.
Reden: Elke kontener (pod) yn it kluster ferwurket mar in diel fan it ferkear. As jo de koade yn mar ien kontener (pod) feroarje, dan sil de koade oars wêze yn ferskate pods, de side sil oars wurkje, en ferskate ferzjes fan 'e side sille wurde toand oan ferskate brûkers. Sa kinne jo net libje.
Tredde - jo moatte it probleem oplosse mei ynset
As wy in monolith en ien "klassike" tsjinner hawwe, is alles frij ienfâldich: wy sette in nije koadebasis yn, migrearje de databank, wikselje ferkear nei de nije ferzje fan 'e koade. It wikseljen bart direkt.
As wy in side hawwe yn Kubernetes, snije yn mikrotsjinsten, binne d'r in protte konteners mei koade - oh. Jo moatte konteners sammelje mei in nije ferzje fan 'e koade, rôlje se út ynstee fan' e âlde, korrekt migrearje de databank, en ideaal dwaan dit ûngemurken troch besikers. Gelokkich helpt Kubernetes ús hjirmei, en stipet in hiele bosk ferskate soarten ynset.
Fjirde - jo moatte oplosse it probleem fan it opslaan fan statyske
As jo side "allinich" 10 gigabytes is en jo it folslein yn konteners ynsette, sille jo einigje mei 10 gigabyte konteners dy't foar altyd nimme om te ynsetten.
Jo moatte de "swierste" dielen fan 'e side bûten konteners opslaan, en de fraach ûntstiet hoe't jo dit korrekt dwaan
Wat mist oan ús oplossing?
De hiele Bitrix-koade is net ferdield yn mikrofunksjes/mikrotsjinsten (sadat registraasje apart is, de online winkelmodule apart, ensfh.). Wy bewarje de hiele koadebasis yn elke kontener.
Wy bewarje de databank ek net yn Kubernetes (ik haw noch oplossingen ymplementearre mei in databank yn Kubernetes foar ûntwikkelingsomjouwings, mar net foar produksje).
It sil noch altyd merkber wêze foar sidebehearders dat de side op Kubernetes rint. De funksje "systeemkontrôle" wurket net goed; om de sidekoade fan it adminpaniel te bewurkjen, moatte jo earst op de knop "Ik wol de koade bewurkje".
De problemen binne identifisearre, de needsaak om mikrotsjinsten út te fieren is bepaald, it doel is dúdlik - om in wurkjend systeem te krijen foar it útfieren fan applikaasjes op Bitrix yn Kubernetes, it behâld fan sawol de mooglikheden fan Bitrix as de foardielen fan Kubernetes. Litte wy de ymplemintaasje begjinne.
arsjitektuer
D'r binne in protte "wurkjende" pods mei in webserver (wurkers).
Ien ûnder mei cron-taken (mar ien is fereaske).
Ien upgrade foar it bewurkjen fan de sidekoade fan it adminpaniel (ek mar ien is fereaske).
Wy losse fragen op:
- Wêr sesjes op te slaan?
- Wêr te bewarjen de cache?
- Wêr statyk op te slaan, net gigabytes statyk te pleatsen yn in boskje konteners?
- Hoe sil de databank wurkje?
Docker ôfbylding
Wy begjinne mei it bouwen fan in Docker-ôfbylding.
De ideale opsje is dat wy ien universele ôfbylding hawwe, op basis dêrfan krije wy arbeiderspods, pods mei Crontasks, en upgrade pods.
.
It omfettet nginx, apache/php-fpm (kin selekteare wurde by build), msmtp foar it ferstjoeren fan e-post, en cron.
By it gearstallen fan de ôfbylding wurdt de folsleine koadebasis fan 'e side kopiearre nei de map / app (mei útsûndering fan dy dielen dy't wy sille ferpleatse nei in aparte dielde opslach).
Mikrotsjinsten, tsjinsten
arbeider pods:
- Container mei nginx + container apache/php-fpm + msmtp
- It slagge net om msmtp yn in aparte mikrotsjinst te ferpleatsen, Bitrix begjint fergriemd te wurden dat it gjin e-post direkt kin ferstjoere
- Elke kontener hat in folsleine koadebase.
- Ferbod op it feroarjen fan koade yn konteners.
cron ûnder:
- kontener mei apache, php, cron
- folsleine koade basis ynbegrepen
- ferbod op it feroarjen fan koade yn konteners
upgrade ûnder:
- nginx container + apache/php-fpm container + msmtp
- D'r is gjin ferbod op it feroarjen fan koade yn konteners
sesje opslach
Bitrix-cache opslach
In oar wichtich ding: wy bewarje wachtwurden foar ferbining mei alles, fan 'e databank oant e-post, yn kubernetes-geheimen. Wy krije in bonus: wachtwurden binne allinich sichtber foar dyjingen oan wa't wy tagong jouwe ta de geheimen, en net foar elkenien dy't tagong hat ta de koadebasis fan it projekt.
Opslach foar statyske
Jo kinne alles brûke: ceph, nfs (mar wy riede nfs net oan foar produksje), netwurk opslach fan wolkproviders, ensfh.
De opslach sil yn konteners ferbûn wêze moatte mei de /upload/-map fan 'e side en oare mappen mei statyske ynhâld.
Databank
Foar ienfâld riede wy oan om de databank bûten Kubernetes te ferpleatsen. De basis yn Kubernetes is in aparte komplekse taak; it sil it skema in folchoarder fan grutte komplekser meitsje.
Sesje opslach
Wy brûke memcached :)
It behannelet sesje opslach goed, is klustere, en wurdt "natively" stipe as session.save_path yn php. Sa'n systeem is in protte kearen hifke yn 'e klassike monolityske arsjitektuer, doe't wy klusters bouden mei in grut oantal webservers. Foar ynset brûke wy helm.
$ helm install stable/memcached --name sessionphp.ini - hjir befettet de ôfbylding ynstellings foar it bewarjen fan sesjes yn memcached
Wy brûkten omjouwingsfariabelen om gegevens oer hosts mei memcached troch te jaan .
Hjirmei kinne jo deselde koade brûke yn 'e dev-, poadium-, test-, prod-omjouwings (de memcached hostnammen yn har sille oars wêze, dus wy moatte in unike hostnamme foar sesjes trochjaan oan elke omjouwing).
Bitrix-cache opslach
Wy hawwe flater-tolerante opslach nedich dêr't alle pods nei kinne skriuwe en lêze.
Wy brûke ek memcached.
Dizze oplossing wurdt oanrikkemandearre troch Bitrix sels.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - hjir yn Bitrix wurdt oanjûn wêr't de cache opslein is
Wy brûke ek omjouwingsfariabelen.
Krontaski
D'r binne ferskate oanpak foar it útfieren fan Crontasks yn Kubernetes.
- aparte ynset mei in pod foar it útfieren fan Crontasks
- cronjob foar it útfieren fan crontasks (as dit in webapp is - mei wget , of kubectl exec binnen ien fan 'e arbeider pods, ensfh.)
- ensfh
Jo kinne argumearje oer de meast korrekte, mar yn dit gefal hawwe wy keazen foar de opsje "aparte ynset mei pods foar Crontasks"
Hoe't it wurdt dien:
- cron-taken tafoegje fia ConfigMap of fia it config/addcron-bestân
- yn ien eksimplaar lansearje wy in kontener identyk oan 'e worker pod + tastean de útfiering fan kroantaken dêryn
- deselde koade basis wurdt brûkt, tank oan ienwurding, container gearkomste is simpel
Wat goed krije wy:
- wy hawwe wurkjende Crontasks yn in omjouwing identyk oan de omjouwing fan 'e ûntwikkelders (docker)
- Crontasks hoege net te "werskreaun" foar Kubernetes, se wurkje yn deselde foarm en yn deselde koadebasis as earder
- cron-taken kinne wurde tafoege troch alle teamleden mei commit-rjochten foar de produksjetak, net allinich admins
Southbridge K8SDeploy module en koade bewurkjen fan de admin paniel
Wy hiene it oer upgrade ûnder?
Hoe kinne jo ferkear dêrhinne rjochtsje?
Hoera, wy hawwe hjir in module foar skreaun yn PHP :) Dit is in lytse klassike module foar Bitrix. It is noch net iepenbier beskikber, mar wy binne fan plan it te iepenjen.
De module is ynstalleare as in gewoane module yn Bitrix:
En it sjocht der sa út:
It lit jo in koekje ynstelle dat de sidebehearder identifisearret en lit Kubernetes ferkear stjoere nei de upgradepod.
As de wizigingen foltôge binne, moatte jo op git push klikke, de koadewizigingen sille wurde stjoerd nei git, dan sil it systeem in ôfbylding bouwe mei in nije ferzje fan 'e koade en it "útrolje" oer it kluster, it ferfangen fan de âlde pods .
Ja, it is in bytsje fan in kruk, mar tagelyk behâlde wy de mikroservice-arsjitektuer en nimme Bitrix-brûkers net har favorite kâns om de koade fan it adminpaniel te korrigearjen. Op it lêst is dit in opsje; jo kinne it probleem oplosse fan it bewurkjen fan de koade op in oare manier.
Helm chart
Om applikaasjes op Kubernetes te bouwen, brûke wy typysk de Helm-pakketbehearder.
Foar ús Bitrix-oplossing yn Kubernetes skreau Sergey Bondarev, ús liedende systeembehearder, in spesjale Helm-diagram.
It bout arbeider, ugrade, cron pods, konfigurearret yngongen, tsjinsten, en ferpleatst fariabelen fan Kubernetes-geheimen nei pods.
Wy bewarje de koade yn Gitlab, en wy rinne ek de Helm build fan Gitlab.
Koartsein, it sjocht der sa út
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm lit jo ek in "naadleaze" rollback dwaan as ynienen wat mis giet by ynset. It is moai as jo net yn panyk binne "fix de koade fia ftp omdat de prod foel," mar Kubernetes docht it automatysk, en sûnder downtime.
Ynsette
Ja, wy binne fans fan Gitlab & Gitlab CI, wy brûke it :)
By it ynsette yn Gitlab oan it projektrepository, lanseart Gitlab in pipeline dy't in nije ferzje fan 'e omjouwing ynset.
Stappen:
- bouwe (in nije Docker-ôfbylding bouwe)
- test (test)
- opromje (de testomjouwing fuortsmite)
- push (wy stjoere it nei it Docker-register)
- ynsette (wy ynsette de applikaasje nei Kubernetes fia Helm).
Hoera, it is klear, lit ús it útfiere!
No, of freegje fragen as d'r ien binne.
Dus wat hawwe wy dien
Ut in technysk eachpunt:
- dockerized Bitrix;
- "snije" Bitrix yn konteners, elk fan dat docht in minimum fan funksjes;
- berikke steatleaze steat fan konteners;
- it probleem oplost mei it bywurkjen fan Bitrix yn Kubernetes;
- alle Bitrix-funksjes bleauwen wurkje (hast allegear);
- Wy wurken oan ynset nei Kubernetes en rollback tusken ferzjes.
Ut in saaklik eachpunt:
- marzje foar flaters;
- Kubernetes-ark (maklike yntegraasje mei Gitlab CI, naadleaze ynset, ensfh.);
- geheime wachtwurden (allinich sichtber foar dyjingen dy't direkt tagong krije ta de wachtwurden);
- It is handich om ekstra omjouwings te meitsjen (foar ûntwikkeling, tests, ensfh.) Binnen ien ynfrastruktuer.
Boarne: www.habr.com