Ang Sysadminka system administrator meetup ay nagaganap sa Chelyabinsk, at sa huli ay nagbigay ako ng ulat sa aming solusyon para sa pagpapatakbo ng mga application sa 1C-Bitrix sa Kubernetes.
Bitrix, Kubernetes, Ceph - isang mahusay na timpla?
Sasabihin ko sa iyo kung paano namin pinagsama-sama ang isang gumaganang solusyon mula sa lahat ng ito.
Sabihin pumunta!
Ang meetup ay naganap noong Abril 18 sa Chelyabinsk. Mababasa mo ang tungkol sa aming mga pagkikita sa at tumingin sa .
Kung gusto mong pumunta sa amin na may dalang ulat o bilang isang tagapakinig - maligayang pagdating, sumulat sa [protektado ng email] at sa Telegram t.me/vadimisakanov.
Aking ulat
Solusyon "Bitrix sa Kubernetes, bersyon Southbridge 1.0"
Pag-uusapan ko ang aming solusyon sa format na "para sa mga dummies sa Kubernetes," gaya ng ginawa sa meetup. Ngunit ipinapalagay ko na alam mo ang mga salitang Bitrix, Docker, Kubernetes, Ceph kahit sa antas ng mga artikulo sa Wikipedia.
Ano ang handa na tungkol sa Bitrix sa Kubernetes?
Napakakaunting impormasyon sa buong Internet tungkol sa pagpapatakbo ng mga application ng Bitrix sa Kubernetes.
Nahanap ko lang ang mga materyales na ito:
Ulat ni Alexander Serbul, 1C-Bitrix, at Anton Tuzlukov mula sa Qsoft:
Inirerekomenda kong pakinggan ito.
Pagbuo ng iyong sariling solusyon mula sa gumagamit .
Nakahanap ng higit pa .
Aaand... actually, yun lang.
Binabalaan kita, hindi namin nasuri ang kalidad ng mga solusyon sa mga link sa itaas :)
Sa pamamagitan ng paraan, kapag inihahanda ang aming solusyon, nakipag-usap ako kay Alexander Serbul, pagkatapos ay hindi pa lumalabas ang kanyang ulat, kaya sa aking mga slide mayroong isang item na "Ang Bitrix ay hindi gumagamit ng Kubernetes."
Ngunit mayroon nang maraming handa na mga imahe ng Docker para sa pagpapatakbo ng Bitrix sa Docker:
Sapat na ba ito upang lumikha ng kumpletong solusyon para sa Bitrix sa Kubernetes?
Hindi. Mayroong isang malaking bilang ng mga problema na kailangang malutas.
Ano ang mga problema sa Bitrix sa Kubernetes?
Una, ang mga yari na larawan mula sa Dockerhub ay hindi angkop para sa Kubernetes
Kung gusto naming bumuo ng isang microservices architecture (at sa Kubernetes na karaniwan naming ginagawa), kailangan naming paghiwalayin ang aming Kubernetes application sa mga container at hayaan ang bawat container na gumanap ng isang maliit na function (at gawin ito ng maayos). Bakit isa lang? Sa madaling salita, ang mas simple ay mas maaasahan.
Upang maging mas tiyak, panoorin ang artikulo at video na ito, mangyaring:
Pangunahing binuo ang mga larawan ng Docker sa Dockerhub sa all-in-one na prinsipyo, kaya kailangan pa rin naming gumawa ng sarili naming bike at kahit na lumikha ng mga larawan mula sa simula.
Pangalawa - ang code ng site ay na-edit mula sa admin panel
Gumawa kami ng bagong seksyon sa site - na-update ang code (naidagdag ang isang direktoryo na may pangalan ng bagong seksyon).
Kung binago mo ang mga katangian ng isang bahagi mula sa admin panel, nagbago ang code.
Ang mga Kubernetes "bilang default" ay hindi maaaring gumana sa mga ito;
Dahilan: Ang bawat container (pod) sa cluster ay nagpoproseso lamang ng isang bahagi ng trapiko. Kung babaguhin mo ang code sa isang lalagyan (pod) lang, mag-iiba ang code sa iba't ibang pod, iba ang gagana sa site, at iba't ibang bersyon ng site ang ipapakita sa iba't ibang user. Hindi ka mabubuhay ng ganyan.
Pangatlo - kailangan mong lutasin ang isyu sa pag-deploy
Kung mayroon kaming isang monolith at isang "classic" na server, ang lahat ay medyo simple: nag-deploy kami ng isang bagong base ng code, migrate ang database, lumipat ng trapiko sa bagong bersyon ng code. Ang paglipat ay nangyayari kaagad.
Kung mayroon kaming isang site sa Kubernetes, gupitin sa mga microservice, maraming mga lalagyan na may code - oh. Kailangan mong mangolekta ng mga container na may bagong bersyon ng code, i-roll out ang mga ito sa halip na ang mga luma, i-migrate nang tama ang database, at perpektong gawin ito nang hindi napapansin ng mga bisita. Sa kabutihang palad, tinutulungan kami ng Kubernetes dito, na sumusuporta sa isang buong grupo ng iba't ibang uri ng deployment.
Pang-apat - kailangan mong lutasin ang isyu ng pag-iimbak ng statics
Kung ang iyong site ay "lamang" na 10 gigabytes at ganap mong i-deploy ito sa mga container, magkakaroon ka ng 10 gigabyte na container na magtatagal bago i-deploy.
Kailangan mong iimbak ang "pinakamabigat" na bahagi ng site sa labas ng mga lalagyan, at ang tanong ay lumitaw kung paano ito gagawin nang tama
Ano ang kulang sa aming solusyon?
Ang buong Bitrix code ay hindi nahahati sa mga microfunction/microservices (para magkahiwalay ang pagpaparehistro, hiwalay ang module ng online store, atbp.). Iniimbak namin ang buong code base sa bawat lalagyan.
Hindi rin namin iniimbak ang database sa Kubernetes (nagpatupad pa rin ako ng mga solusyon na may database sa Kubernetes para sa mga development environment, ngunit hindi para sa produksyon).
Mapapansin pa rin sa mga administrator ng site na tumatakbo ang site sa Kubernetes. Ang function na "system check" ay hindi gumagana nang tama upang i-edit ang code ng site mula sa admin panel, kailangan mo munang i-click ang pindutang "Gusto kong i-edit ang code".
Natukoy na ang mga problema, natukoy ang pangangailangang magpatupad ng mga microservice, malinaw ang layunin - makakuha ng gumaganang sistema para sa pagpapatakbo ng mga aplikasyon sa Bitrix sa Kubernetes, na pinapanatili ang parehong mga kakayahan ng Bitrix at ang mga pakinabang ng Kubernetes. Simulan natin ang pagpapatupad.
arkitektura
Maraming "nagtatrabaho" na pod na may web server (mga manggagawa).
Isa sa ilalim na may mga gawain sa cron (isa lang ang kailangan).
Isang upgrade para sa pag-edit ng code ng site mula sa admin panel (isa lang din ang kailangan).
Lutasin namin ang mga tanong:
- Saan mag-iimbak ng mga session?
- Saan iimbak ang cache?
- Saan mag-imbak ng statics, hindi maglagay ng gigabytes ng statics sa isang grupo ng mga container?
- Paano gagana ang database?
Larawan ng docker
Nagsisimula kami sa pagbuo ng isang imahe ng Docker.
Ang perpektong opsyon ay mayroon kaming isang unibersal na imahe, sa batayan nito ay nakakakuha kami ng mga worker pod, mga pod na may Crontasks, at mga upgrade na pod.
.
Kabilang dito ang nginx, apache/php-fpm (maaaring mapili sa panahon ng build), msmtp para sa pagpapadala ng mail, at cron.
Kapag ini-assemble ang larawan, ang buong code base ng site ay kinokopya sa /app na direktoryo (maliban sa mga bahaging iyon na ililipat namin sa isang hiwalay na nakabahaging storage).
Mga microservice, serbisyo
mga pod ng manggagawa:
- Container na may nginx + container apache/php-fpm + msmtp
- Hindi nagtagumpay na ilipat ang msmtp sa isang hiwalay na microservice, nagsisimula nang magalit si Bitrix na hindi ito direktang makapagpadala ng mail
- Ang bawat container ay may kumpletong codebase.
- Pagbabawal sa pagpapalit ng code sa mga lalagyan.
cron sa ilalim ng:
- lalagyan na may apache, php, cron
- kasama ang kumpletong code base
- pagbabawal sa pagpapalit ng code sa mga lalagyan
mag-upgrade sa ilalim ng:
- nginx container + apache/php-fpm container + msmtp
- Walang pagbabawal sa pagpapalit ng code sa mga lalagyan
imbakan ng session
Imbakan ng cache ng Bitrix
Isa pang mahalagang bagay: nag-iimbak kami ng mga password para sa pagkonekta sa lahat, mula sa database hanggang sa mail, sa mga lihim ng kubernetes. Makakakuha kami ng bonus: ang mga password ay makikita lamang sa mga binibigyan namin ng access sa mga lihim, at hindi sa lahat ng may access sa code base ng proyekto.
Imbakan para sa statics
Maaari kang gumamit ng anuman: ceph, nfs (ngunit hindi namin inirerekomenda ang nfs para sa produksyon), network storage mula sa mga cloud provider, atbp.
Ang imbakan ay kailangang ikonekta sa mga lalagyan sa /upload/ direktoryo ng site at iba pang mga direktoryo na may static na nilalaman.
Database
Para sa pagiging simple, inirerekomenda naming ilipat ang database sa labas ng Kubernetes. Ang base sa Kubernetes ay isang hiwalay na kumplikadong gawain;
Imbakan ng session
Gumagamit kami ng memcached :)
Mahusay itong pinangangasiwaan ang pag-iimbak ng session, naka-cluster, at sinusuportahan "native" bilang session.save_path sa php. Ang ganitong sistema ay nasubok nang maraming beses sa klasikal na monolitikong arkitektura, noong nagtayo kami ng mga kumpol na may malaking bilang ng mga web server. Para sa deployment ginagamit namin ang timon.
$ helm install stable/memcached --name sessionphp.ini - dito ang larawan ay naglalaman ng mga setting para sa pag-iimbak ng mga session sa memcached
Gumamit kami ng Environment Variables para magpasa ng data tungkol sa mga host na may memcached .
Binibigyang-daan ka nitong gumamit ng parehong code sa dev, stage, test, prod environment (magiiba ang memcached host name sa mga ito, kaya kailangan naming magpasa ng natatanging host name para sa mga session sa bawat environment).
Imbakan ng cache ng Bitrix
Kailangan namin ng fault-tolerant na storage kung saan maaaring sulatan at basahin ng lahat ng pod.
Gumagamit din kami ng memcached.
Ang solusyon na ito ay inirerekomenda ng Bitrix mismo.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - dito sa Bitrix ito ay tinukoy kung saan naka-imbak ang cache
Gumagamit din kami ng Environment Variables.
Krontaski
Mayroong iba't ibang mga diskarte sa pagpapatakbo ng Crontasks sa Kubernetes.
- hiwalay na deployment na may pod para sa pagpapatakbo ng Crontasks
- cronjob para sa pagpapatupad ng mga crontask (kung ito ay isang web app - na may wget , o kubectl exec sa loob ng isa sa mga worker pod, atbp.)
- at iba pa
Maaari kang magtaltalan tungkol sa pinakatama, ngunit sa kasong ito pinili namin ang opsyon na "hiwalay na pag-deploy na may mga pod para sa Crontasks"
Paano ito ginawa:
- magdagdag ng mga gawain sa cron sa pamamagitan ng ConfigMap o sa pamamagitan ng config/addcron file
- sa isang pagkakataon naglulunsad kami ng isang lalagyan na kapareho ng pod ng manggagawa + pinapayagan ang pagpapatupad ng mga gawain sa korona dito
- ang parehong code base ay ginagamit, salamat sa unification, container assembly ay simple
Anong magandang makukuha natin:
- mayroon kaming mga gumaganang Crontasks sa isang kapaligiran na kapareho ng kapaligiran ng mga developer (docker)
- Ang mga Crontask ay hindi kailangang "muling isulat" para sa Kubernetes, gumagana ang mga ito sa parehong anyo at sa parehong code base tulad ng dati
- Ang mga gawain ng cron ay maaaring idagdag ng lahat ng miyembro ng koponan na may mga karapatan sa pag-commit sa sangay ng produksyon, hindi lamang ng mga admin
Southbridge K8SDeploy module at pag-edit ng code mula sa admin panel
Pinag-uusapan natin ang tungkol sa pag-upgrade sa ilalim?
Paano idirekta ang trapiko doon?
Hurray, nagsulat kami ng module para dito sa PHP :) Ito ay isang maliit na classic na module para sa Bitrix. Hindi pa ito available sa publiko, ngunit plano naming buksan ito.
Ang module ay naka-install tulad ng isang regular na module sa Bitrix:
At ganito ang hitsura:
Binibigyang-daan ka nitong magtakda ng cookie na nagpapakilala sa administrator ng site at nagbibigay-daan sa Kubernetes na magpadala ng trapiko sa upgrade pod.
Kapag nakumpleto na ang mga pagbabago, kailangan mong i-click ang git push, ang mga pagbabago sa code ay ipapadala sa git, pagkatapos ay bubuo ang system ng isang imahe na may bagong bersyon ng code at "i-roll out" ito sa buong cluster, na papalitan ang mga lumang pod .
Oo, ito ay isang maliit na saklay, ngunit sa parehong oras ay pinapanatili namin ang microservice architecture at hindi inaalis sa mga gumagamit ng Bitrix ang kanilang paboritong pagkakataon upang itama ang code mula sa admin panel. Sa huli, ito ay isang opsyon na maaari mong lutasin ang problema sa pag-edit ng code sa ibang paraan.
Helm chart
Upang bumuo ng mga application sa Kubernetes, karaniwang ginagamit namin ang Helm package manager.
Para sa aming solusyon sa Bitrix sa Kubernetes, si Sergey Bondarev, ang aming nangungunang system administrator, ay nagsulat ng isang espesyal na Helm chart.
Bumubuo ito ng manggagawa, ugrade, mga cron pod, nagko-configure ng mga pagpasok, mga serbisyo, at naglilipat ng mga variable mula sa mga lihim ng Kubernetes patungo sa mga pod.
Iniimbak namin ang code sa Gitlab, at pinapatakbo din namin ang Helm build mula sa Gitlab.
Sa madaling salita, ganito ang hitsura
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionBinibigyang-daan ka rin ng Helm na gumawa ng "seamless" na rollback kung biglang may mali sa panahon ng deployment. Masarap kapag hindi ka nag-panic "ayusin ang code sa pamamagitan ng ftp dahil nahulog ang prod," ngunit awtomatikong ginagawa ito ng Kubernetes, at walang downtime.
I-deploy
Oo, kami ay mga tagahanga ng Gitlab at Gitlab CI, ginagamit namin ito :)
Kapag nag-commit sa Gitlab sa repository ng proyekto, naglulunsad ang Gitlab ng pipeline na nagde-deploy ng bagong bersyon ng environment.
Mga yugto:
- build (pagbuo ng bagong imahe ng Docker)
- pagsubok (pagsubok)
- linisin (inaalis ang kapaligiran ng pagsubok)
- push (ipinapadala namin ito sa registry ng Docker)
- deploy (i-deploy namin ang application sa Kubernetes sa pamamagitan ng Helm).
Hurray, handa na, ipatupad natin!
Well, o magtanong kung mayroon man.
So anong ginawa namin
Mula sa teknikal na pananaw:
- dockerized Bitrix;
- "gupitin" ang Bitrix sa mga lalagyan, na ang bawat isa ay gumaganap ng isang minimum na mga function;
- nakamit ang stateless na estado ng mga lalagyan;
- nalutas ang problema sa pag-update ng Bitrix sa Kubernetes;
- ang lahat ng mga function ng Bitrix ay patuloy na gumana (halos lahat);
- Nagtrabaho kami sa deployment sa Kubernetes at rollback sa pagitan ng mga bersyon.
Mula sa pananaw ng negosyo:
- pagpapahintulot sa kasalanan;
- Mga tool ng Kubernetes (madaling pagsasama sa Gitlab CI, tuluy-tuloy na pag-deploy, atbp);
- mga lihim na password (makikita lamang sa mga direktang nabigyan ng access sa mga password);
- Maginhawang lumikha ng mga karagdagang kapaligiran (para sa pag-unlad, mga pagsubok, atbp.) sa loob ng iisang imprastraktura.
Pinagmulan: www.habr.com