En Chelyabinsk okazas renkontiĝoj pri Sysadminka sistemadministranto, kaj ĉe la lasta mi donis raporton pri nia solvo por ruli aplikaĵojn sur 1C-Bitrix en Kubernetes.
Bitrix, Kubernetes, Ceph - ĉu bonega miksaĵo?
Mi rakontos al vi kiel ni kunmetis funkciantan solvon de ĉio ĉi.
Ni iru!
La renkontiĝo okazis la 18-an de aprilo en Chelyabinsk. Vi povas legi pri niaj renkontiĝoj ĉe kaj rigardu .
Se vi volas veni al ni kun raporto aŭ kiel aŭskultanto - bonvenon, skribu al [retpoŝte protektita] kaj ĉe Telegramo t.me/vadimisakanov.
Mia raporto
Solvo "Bitrix en Kubernetes, versio Southbridge 1.0"
Mi parolos pri nia solvo en la formato "por dummioj en Kubernetes", kiel estis farita ĉe la renkontiĝo. Sed mi supozas, ke vi konas la vortojn Bitrix, Docker, Kubernetes, Ceph almenaŭ je la nivelo de artikoloj en Vikipedio.
Kio estas preta pri Bitrix en Kubernetes?
Estas tre malmulte da informoj en la tuta Interreto pri la funkciado de Bitrix-aplikoj en Kubernetes.
Mi trovis nur ĉi tiujn materialojn:
Raporto de Alexander Serbul, 1C-Bitrix, kaj Anton Tuzlukov de Qsoft:
Mi rekomendas aŭskulti ĝin.
Disvolvante vian propran solvon de la uzanto .
Trovis pli .
Aaand... efektive, jen ĉio.
Mi avertas vin, ni ne kontrolis la kvaliton de la solvoj en la supraj ligiloj :)
Cetere, kiam mi preparis nian solvon, mi parolis kun Alexander Serbul, tiam lia raporto ankoraŭ ne aperis, do en miaj lumbildoj estas ero "Bitrix ne uzas Kubernetes".
Sed jam ekzistas multaj pretaj bildoj de Docker por ruli Bitrix en Docker:
Ĉu tio sufiĉas por krei kompletan solvon por Bitrix en Kubernetes?
Ne. Estas granda nombro da problemoj, kiuj devas esti solvitaj.
Kio estas la problemoj kun Bitrix en Kubernetes?
Unue, pretaj bildoj de Dockerhub ne taŭgas por Kubernetes
Se ni volas konstrui mikroservan arkitekturon (kaj en Kubernetes ni kutime faras), ni devas apartigi nian Kubernetes-aplikaĵon en ujojn kaj ke ĉiu ujo plenumu unu malgrandan funkcion (kaj faru ĝin bone). Kial nur unu? Resume, ju pli simpla des pli fidinda.
Por esti pli specifa, spektu ĉi tiun artikolon kaj filmeton, bonvolu:
Docker-bildoj en Dockerhub estas ĉefe konstruitaj laŭ la ĉio-en-unu principo, do ni ankoraŭ devis fari nian propran biciklon kaj eĉ krei bildojn de nulo.
Due - la retejo-kodo estas redaktita de la administra panelo
Ni kreis novan sekcion en la retejo - la kodo estis ĝisdatigita (dosierujo kun la nomo de la nova sekcio estis aldonita).
Se vi ŝanĝis la ecojn de komponanto de la administra panelo, la kodo ŝanĝiĝis.
Kubernetes "defaŭlte" ne povas funkcii kun ĉi tio; ujoj devas esti sennaciaj.
Kialo: Ĉiu ujo (pod) en la areto procesas nur parton de la trafiko. Se vi ŝanĝas la kodon en nur unu ujo (pod), tiam la kodo estos malsama en malsamaj podoj, la retejo funkcios malsame, kaj malsamaj versioj de la retejo estos montritaj al malsamaj uzantoj. Vi ne povas vivi tiel.
Trie - vi devas solvi la problemon kun deplojo
Se ni havas monoliton kaj unu "klasikan" servilon, ĉio estas sufiĉe simpla: ni deplojas novan kodbazon, migras la datumbazon, ŝanĝas trafikon al la nova versio de la kodo. Ŝanĝo okazas tuj.
Se ni havas retejon en Kubernetes, tranĉita en mikroservojn, ekzistas multaj ujoj kun kodo - ho. Vi devas kolekti ujojn kun nova versio de la kodo, ruliĝi ilin anstataŭ la malnovaj, ĝuste migri la datumbazon, kaj ideale fari tion nerimarkite de vizitantoj. Feliĉe, Kubernetes helpas nin kun ĉi tio, subtenante multajn malsamajn specojn de deplojoj.
Kvare - vi devas solvi la problemon de stokado de statiko
Se via retejo estas "nur" 10 gigabajtoj kaj vi disfaldas ĝin tute en ujoj, vi finiĝos kun 10 gigabajtaj ujoj, kiuj daŭras eterne por deploji.
Vi devas konservi la "plej pezajn" partojn de la retejo ekster ujoj, kaj la demando ŝprucas kiel fari tion ĝuste.
Kio mankas al nia solvo?
La tuta Bitrix-kodo ne estas dividita en mikrofunkciojn/mikroservojn (tiel ke registriĝo estu aparta, la retbutiko-modulo estas aparta, ktp.). Ni stokas la tutan kodon en ĉiu ujo.
Ni ankaŭ ne konservas la datumbazon en Kubernetes (mi ankoraŭ efektivigis solvojn kun datumbazo en Kubernetes por evolumedioj, sed ne por produktado).
Al administrantoj de la retejo ankoraŭ rimarkos, ke la retejo funkcias per Kubernetes. La funkcio "sistemkontrolo" ne funkcias ĝuste; por redakti la retejo-kodon de la administra panelo, vi unue devas alklaki la butonon "Mi volas redakti la kodon".
La problemoj estis identigitaj, la bezono efektivigi mikroservojn estis determinita, la celo estas klara - akiri funkciantan sistemon por ruli aplikojn sur Bitrix en Kubernetes, konservante kaj la kapablojn de Bitrix kaj la avantaĝojn de Kubernetes. Ni komencu efektivigon.
arkitekturo
Estas multaj "funkciantaj" podoj kun retservilo (laboristoj).
Unu sub kun cron-taskoj (nur unu necesas).
Unu ĝisdatigo por redaktado de la retejo-kodo de la administra panelo (ankaŭ nur unu necesas).
Ni solvas demandojn:
- Kie konservi kunsidojn?
- Kie konservi la kaŝmemoron?
- Kie stoki statikon, ne meti gigabajtojn da statiko en amason da ujoj?
- Kiel funkcios la datumbazo?
Docker-bildo
Ni komencas konstruante Docker-bildon.
La ideala opcio estas, ke ni havas unu universalan bildon, surbaze de ĝi ni ricevas laboristajn podojn, podojn kun Crontasks kaj ĝisdatigitajn podojn.
.
Ĝi inkluzivas nginx, apache/php-fpm (povas esti elektitaj dum konstruo), msmtp por sendi retpoŝton kaj cron.
Kunveninte la bildon, la tuta koda bazo de la retejo estas kopiita al la dosierujo /app (krom tiuj partoj, kiujn ni movos al aparta komuna stokado).
Mikroservoj, servoj
laborkapsuloj:
- Ujo kun nginx + ujo apache/php-fpm + msmtp
- Ne funkciis movi msmtp en apartan mikroservon, Bitrix komencas indigniĝi, ke ĝi ne povas sendi retpoŝton rekte.
- Ĉiu ujo havas kompletan kodbazon.
- Malpermeso ŝanĝi kodon en ujoj.
cron sub:
- ujo kun apache, php, cron
- kompleta kodo bazo inkluzivita
- malpermeso ŝanĝi kodon en ujoj
ĝisdatigi sub:
- nginx-ujo + apache/php-fpm-ujo + msmtp
- Ne estas malpermeso ŝanĝi kodon en ujoj
sesio-stokado
Bitrix kaŝmemoro stokado
Alia grava afero: ni konservas pasvortojn por konekti al ĉio, de la datumbazo ĝis poŝto, en sekretoj de kubernetes. Ni ricevas gratifikon: pasvortoj estas videblaj nur por tiuj, al kiuj ni donas aliron al la sekretoj, kaj ne por ĉiuj, kiuj havas aliron al la koda bazo de la projekto.
Stokado por statiko
Vi povas uzi ion ajn: ceph, nfs (sed ni ne rekomendas nfs por produktado), retstokado de nubaj provizantoj, ktp.
La stokado devos esti konektita en ujoj al la /upload/ dosierujo de la retejo kaj aliaj dosierujoj kun statika enhavo.
Datumbazo
Por simpleco, ni rekomendas movi la datumbazon ekster Kubernetes. La bazo en Kubernetes estas aparta kompleksa tasko; ĝi faros la skemon grandordo pli kompleksa.
Sesian konservadon
Ni uzas memcached :)
Ĝi bone traktas sean stokadon, estas amasigita, kaj estas subtenata "denaske" kiel session.save_path en php. Tia sistemo estis multfoje provita en la klasika monolita arkitekturo, kiam ni konstruis aretojn kun granda nombro da retserviloj. Por deplojo ni uzas stirilon.
$ helm install stable/memcached --name sessionphp.ini - ĉi tie la bildo enhavas agordojn por stoki sesiojn en memcached
Ni uzis Mediajn Variablojn por transdoni datumojn pri gastigantoj kun memcached .
Ĉi tio ebligas al vi uzi la saman kodon en la dev, scenejo, test, prod medioj (la memcached gastiganto nomoj en ili estos malsamaj, do ni devas pasi unikan gastiganton por sesioj al ĉiu medio).
Bitrix kaŝmemoro stokado
Ni bezonas mistoleran stokadon, al kiu ĉiuj podoj povas skribi kaj legi.
Ni ankaŭ uzas memcached.
Ĉi tiu solvo estas rekomendita de Bitrix mem.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - ĉi tie en Bitrix estas specifita kie la kaŝmemoro estas konservita
Ni ankaŭ uzas Mediajn Variablojn.
Krontaski
Estas malsamaj aliroj por funkcii Crontasks en Kubernetes.
- aparta deplojo kun pod por ruli Crontasks
- cronjob por ekzekuti krontaskojn (se ĉi tio estas TTT-apliko - kun wget , aŭ kubectl exec ene de unu el la laborkapsuloj, ktp.)
- ktp
Vi povas argumenti pri la plej ĝusta, sed en ĉi tiu kazo ni elektis la opcion "aparta disfaldo kun podoj por Crontasks"
Kiel ĝi estas farita:
- aldonu cron-taskojn per ConfigMap aŭ per la konfig/addcron-dosiero
- en unu okazo ni lanĉas ujon identan al la laborista pod + permesas la plenumon de kronaj taskoj en ĝi
- la sama kodbazo estas uzata, danke al unuiĝo, ujo muntado estas simpla
Kion bone ni ricevas:
- ni havas laborantajn Crontasks en medio identa al la medio de la programistoj (docker)
- Crontasks ne bezonas esti "reskribitaj" por Kubernetes, ili funkcias en la sama formo kaj en la sama kodbazo kiel antaŭe.
- cron-taskoj povas esti aldonitaj de ĉiuj teamanoj kun komitrajtoj al la produktadbranĉo, ne nur administrantoj
Southbridge K8SDeploy modulo kaj koda redaktado de la administra panelo
Ni parolis pri altgradigo sub?
Kiel direkti trafikon tien?
Hura, ni skribis modulon por ĉi tio en PHP :) Ĉi tio estas malgranda klasika modulo por Bitrix. Ĝi ankoraŭ ne estas publike havebla, sed ni planas malfermi ĝin.
La modulo estas instalita kiel regula modulo en Bitrix:
Kaj ĝi aspektas jene:
Ĝi permesas al vi agordi kuketon, kiu identigas la retejan administranton kaj permesas al Kubernetes sendi trafikon al la ĝisdatiga podo.
Kiam la ŝanĝoj finiĝos, vi devas alklaki git push, la kodŝanĝoj estos senditaj al git, tiam la sistemo konstruos bildon kun nova versio de la kodo kaj "elvolvos" ĝin tra la areto, anstataŭigante la malnovajn podojn. .
Jes, ĝi estas iom lambastono, sed samtempe ni konservas la mikroservan arkitekturon kaj ne forprenas de Bitrix-uzantoj ilian plej ŝatatan ŝancon korekti la kodon de la administra panelo. Fine, ĉi tio estas opcio; vi povas solvi la problemon redakti la kodon alimaniere.
Helm-diagramo
Por konstrui aplikaĵojn sur Kubernetes, ni kutime uzas la pakaĵmanaĝeron Helm.
Por nia Bitrix-solvo en Kubernetes, Sergey Bondarev, nia ĉefa administranto de la sistemo, skribis specialan Helm-diagramon.
Ĝi konstruas laboriston, altgradigon, kronpodojn, agordas enirojn, servojn kaj transdonas variablojn de Kubernetes-sekretoj al podoj.
Ni konservas la kodon en Gitlab, kaj ni ankaŭ kuras la Helm-konstruaĵon de Gitlab.
Resume, ĝi aspektas tiel
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm ankaŭ ebligas al vi fari "senjuntan" retrovon se subite io misfunkcias dum deplojo. Estas agrable kiam vi ne estas en paniko "ripari la kodon per ftp ĉar la prod falis", sed Kubernetes faras ĝin aŭtomate, kaj sen malfunkcio.
Deploji
Jes, ni estas ŝatantoj de Gitlab & Gitlab CI, ni uzas ĝin :)
Dum engaĝiĝo en Gitlab al la projekta deponejo, Gitlab lanĉas dukton kiu deplojas novan version de la medio.
Etapoj:
- konstrui (konstruante novan Docker-bildon)
- testo (testo)
- purigi (forigante la testan medion)
- push (ni sendas ĝin al la Docker-registro)
- deploji (ni deplojas la aplikaĵon al Kubernetes per Helm).
Hura, ĝi estas preta, ni efektivigu ĝin!
Nu, aŭ faru demandojn se ekzistas.
Kion do ni faris
De teknika vidpunkto:
- dokerigita Bitrix;
- "tranĉi" Bitrix en ujojn, ĉiu el kiuj plenumas minimume da funkcioj;
- atingita sennacia stato de ujoj;
- solvis la problemon kun ĝisdatigo de Bitrix en Kubernetes;
- ĉiuj Bitrix-funkcioj daŭre funkciis (preskaŭ ĉiuj);
- Ni laboris pri disfaldo al Kubernetes kaj restarigo inter versioj.
De komerca vidpunkto:
- kulpo toleremo;
- Kubernetes-iloj (facila integriĝo kun Gitlab CI, senjunta deplojo, ktp);
- sekretaj pasvortoj (videblaj nur por tiuj, al kiuj rekte ricevas aliron al la pasvortoj);
- Estas oportune krei pliajn mediojn (por evoluo, testoj, ktp.) ene de ununura infrastrukturo.
fonto: www.habr.com