L'incontri di l'amministratore di u sistema Sysadminka sò in Chelyabinsk, è à l'ultimu aghju datu un rapportu nantu à a nostra suluzione per eseguisce l'applicazioni in 1C-Bitrix in Kubernetes.
Bitrix, Kubernetes, Ceph - una grande mistura?
Vi dicu cumu si mette inseme una suluzione di travagliu da tuttu questu.
Let's go!
A riunione hè accaduta u 18 d'aprile in Chelyabinsk. Pudete leghje nantu à i nostri incontri à è fighjate .
Sè vo vulete vene à noi cun un rapportu o cum'è ascultore - benvenutu, scrivite à [email prutettu] è in Telegram t.me/vadimisakanov.
U mo rapportu
Soluzione "Bitrix in Kubernetes, versione Southbridge 1.0"
Parlaraghju di a nostra suluzione in u furmatu "per dummies in Kubernetes", cum'è hè statu fattu in u meetingup. Ma suppone chì sapete e parolle Bitrix, Docker, Kubernetes, Ceph almenu à u livellu di l'articuli in Wikipedia.
Cosa hè pronta per Bitrix in Kubernetes?
Ci hè pocu infurmazione nantu à l'Internet sanu nantu à u funziunamentu di l'applicazioni Bitrix in Kubernetes.
Aghju trovu solu questi materiali:
Rapportu di Alexander Serbul, 1C-Bitrix, è Anton Tuzlukov da Qsoft:
Vi cunsigliu di stà à sente.
Sviluppà a vostra propria suluzione da l'utilizatore .
Truvatu di più .
Aaand... in realtà, hè tuttu.
Vi avvistu, ùn avemu micca verificatu a qualità di e soluzioni in i ligami sopra :)
A propositu, quandu preparava a nostra suluzione, aghju parlatu cù Alexander Serbul, allora u so rapportu ùn era ancu apparsu, cusì in i mo slides ci hè un articulu "Bitrix ùn usa micca Kubernetes".
Ma ci sò digià parechje imagine Docker pronte per eseguisce Bitrix in Docker:
Hè abbastanza per creà una suluzione cumpleta per Bitrix in Kubernetes?
Innò. Ci hè un gran numaru di prublemi chì deve esse risoltu.
Chì sò i prublemi cù Bitrix in Kubernetes?
Prima, l'imaghjini pronti da Dockerhub ùn sò micca adattati per Kubernetes
Se vulemu custruisce una architettura di microservizi (è in Kubernetes facemu di solitu), avemu bisognu di separà a nostra applicazione Kubernetes in cuntenituri è avè ogni cuntainer realizanu una piccula funzione (è fà bè). Perchè solu unu? In breve, u più simplice u più affidabile.
Per esse più specificu, fighjate questu articulu è video, per piacè:
L'imaghjini di Docker in Dockerhub sò basamente custruiti nantu à u principiu all-in-one, cusì avemu sempre avutu à fà a nostra propria bicicletta è ancu fà imagine da zero.
Siconda - u codice di u situ hè editatu da u panel admin
Avemu creatu una nova rùbbrica nantu à u situ - u codice hè statu aghjurnatu (un repertoriu cù u nome di a nova rùbbrica hè statu aghjuntu).
Se avete cambiatu e proprietà di un cumpunente da u pannellu admin, u codice cambiatu.
Kubernetes "per difettu" ùn pò micca travaglià cù questu cuntenituri deve esse senza statu.
Ragione: Ogni cuntainer (pod) in u cluster processa solu una parte di u trafficu. Se cambiate u codice in un solu cuntainer (pod), allura u codice serà diversu in diverse pods, u situ hà da travaglià in modu diversu, è diverse versioni di u situ seranu mostrati à diversi utilizatori. Ùn pudete micca campà cusì.
Terzu - avete bisognu di risolve u prublema cù implementazione
Se avemu un monolitu è un servitore "classicu", tuttu hè abbastanza simplice: implementemu una nova basa di codice, migrate a basa di dati, cambiate u trafficu à a nova versione di u codice. U cambiamentu accade istantaneamente.
Se avemu un situ in Kubernetes, cut in microservices, ci sò assai cuntenituri cù codice - oh. Avete bisognu di cullà cuntenituri cù una nova versione di u codice, rollu fora invece di i vechji, migrate currettamente a basa di dati, è idealmente fate questu inosservatu da i visitori. Fortunatamente, Kubernetes ci aiuta cù questu, supportendu una mansa di diversi tipi di implementazioni.
Quartu - avete bisognu di risolve u prublema di guardà statics
Se u vostru situ hè "solu" 10 gigabyte è l'avete implementatu sanu sanu in cuntenituri, vi finiscinu cù cuntenituri di 10 gigabyte chì duranu per sempre per implementà.
Avete bisognu di almacenà e parte "più pesante" di u situ fora di cuntenituri, è a quistione hè di cumu fà questu currettamente.
Chì ci manca à a nostra suluzione ?
Tuttu u codice Bitrix ùn hè micca divisu in microfunzioni / microservizii (per chì a registrazione hè separata, u modulu di a tenda in linea hè separata, etc.). Almacenemu a basa di codice sana in ogni cuntainer.
Ùn avemu micca guardatu ancu a basa di dati in Kubernetes (aghju sempre implementatu suluzioni cù una basa di dati in Kubernetes per l'ambienti di sviluppu, ma micca per a produzzione).
Serà sempre notu à l'amministratori di u situ chì u situ corre nantu à Kubernetes. A funzione "verifica di u sistema" ùn funziona micca bè per edità u codice di u situ da u pannellu di amministrazione, prima deve cliccà u buttone "Vogliu edità u codice".
I prublemi sò stati identificati, a necessità di implementà i microservizi hè stata determinata, u scopu hè chjaru - per ottene un sistema di travagliu per eseguisce l'applicazioni in Bitrix in Kubernetes, priservendu sia e capacità di Bitrix sia i vantaghji di Kubernetes. Cuminciamu a implementazione.
architettura
Ci hè parechje pods "travaglianti" cù un servitore web (travagliatori).
Unu sottu cù compiti cron (solu unu hè necessariu).
Un aghjurnamentu per edità u codice di u situ da u pannellu admin (ancu un solu hè necessariu).
Risolvemu e dumande:
- Induve guardà e sessioni?
- Induve guardà a cache?
- Induve almacenà e statiche, per micca di mette gigabyte di statiche in una mansa di cuntenituri?
- Cumu funzionerà a basa di dati?
Image Docker
Cuminciamu custruendu una maghjina Docker.
L'opzione ideale hè chì avemu una maghjina universale, nantu à a so basa ottenemu pods di travagliadori, pods cù Crontasks, è pods d'aghjurnamentu.
.
Include nginx, apache/php-fpm (pò esse sceltu durante a custruzione), msmtp per mandà mail, è cron.
Quandu assemblea l'imaghjini, tutta a basa di codice di u situ hè copiata à u repertoriu / app (cù l'eccezzioni di quelli parti chì andemu in un almacenamentu spartutu separatu).
Microservizi, servizii
podi di travagliadori:
- Container cù nginx + container apache/php-fpm + msmtp
- Ùn hà micca travagliatu per spustà msmtp in un microserviziu separatu, Bitrix cumencia à indignà chì ùn pò micca mandà mail direttamente.
- Ogni cuntinuu hà una basa di codice cumpleta.
- Pruibizione di cambià u codice in cuntenituri.
cron sottu:
- cuntainer cù apache, php, cron
- basa di codice cumpleta inclusa
- pruibizione di cambià u codice in cuntenituri
aghjurnamentu sottu:
- nginx container + apache/php-fpm container + msmtp
- Ùn ci hè micca pruibizione di cambià u codice in cuntenituri
almacenamiento di sessione
Storage cache Bitrix
Un'altra cosa impurtante: guardemu password per cunnette à tuttu, da a basa di dati à u mail, in secreti kubernetes. Avemu un bonus: i password sò visibili solu per quelli à quale demu accessu à i sicreti, è micca à tutti quelli chì anu accessu à a basa di codice di u prugettu.
Stoccaggio per statica
Pudete utilizà qualcosa: ceph, nfs (ma ùn ricumandemu micca nfs per a produzzione), almacenamentu di rete da i fornituri di nuvola, etc.
L'almacenamiento duverà esse cunnessu in cuntenituri à u /upload/ directory di u situ è altri repertorii cù cuntenutu staticu.
Base di dati
Per simplicità, ricumandemu di spustà a basa di dati fora di Kubernetes. A basa in Kubernetes hè un compitu cumplessu separatu chì farà u schema un ordine di grandezza più cumplessu.
Memoria di sessione
Avemu aduprà memcached :)
Maneghja bè l'almacenamiento di sessione, hè clustered, è hè supportatu "nativamente" cum'è session.save_path in php. Un tali sistema hè statu pruvatu parechje volte in l'architettura monolitica classica, quandu avemu custruitu clusters cù un gran numaru di servitori web. Per u dispiegamentu usemu u timone.
$ helm install stable/memcached --name sessionphp.ini - quì l'imaghjini cuntene paràmetri per almacenà e sessioni in memcached
Avemu usatu Variabili di Ambiente per passà dati nantu à l'ospiti cù memcached .
Questu permette di utilizà u listessu codice in l'ambienti di dev, stage, test, prod (i nomi di l'ospiti memcached in elli seranu diffirenti, cusì avemu bisognu di passà un nome d'ospiti unicu per sessione à ogni ambiente).
Storage cache Bitrix
Avemu bisognu di un almacenamentu tolerante à i difetti chì tutti i pods ponu scrive è leghje.
Avemu ancu aduprà memcached.
Sta suluzione hè cunsigliatu da Bitrix stessu.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - quì in Bitrix hè specificatu induve a cache hè almacenata
Avemu ancu aduprà Variabili di Ambiente.
Krontaski
Ci sò diversi approcci per eseguisce Crontasks in Kubernetes.
- implementazione separata cù un pod per l'esecuzione di Crontasks
- cronjob per eseguisce crontasks (se questa hè una app web - cù wget , o kubectl exec in unu di i podi di u travagliu, etc.)
- etc.
Pudete argumentà nantu à u più currettu, ma in questu casu avemu sceltu l'opzione "spiegamentu separatu cù pods per Crontasks"
Cumu hè fattu:
- aghjunghje compiti cron via ConfigMap o via u schedariu config/addcron
- in un casu, lanciamu un containeru identicu à u pod di u travagliu + permette l'esekzione di e funzioni di a corona in questu
- a stessa basa di codice hè usata, grazia à l'unificazione, l'assemblea di u container hè simplice
Chì bè avemu:
- avemu Crontasks di travagliu in un ambiente identicu à l'ambiente di sviluppatori (docker)
- Crontasks ùn anu micca bisognu di esse "riscritte" per Kubernetes, travaglianu in a stessa forma è in a stessa basa di codice cum'è prima.
- I travaglii cron ponu esse aghjuntu da tutti i membri di a squadra cù diritti di cummissione à u ramu di produzzione, micca solu l'amministratori
Southbridge K8SDeploy modulu è edizione di codice da u pannellu di amministrazione
Avemu parlatu di l'aghjurnamentu sottu?
Cumu dirige u trafficu quì?
Hurrah, avemu scrittu un modulu per questu in PHP :) Questu hè un picculu modulu classicu per Bitrix. Ùn hè ancu dispunibule publicamente, ma avemu pensatu à apre.
U modulu hè stallatu cum'è un modulu regulare in Bitrix:
È pare cusì:
Permette di stabilisce una cookie chì identifica l'amministratore di u situ è permette à Kubernetes di mandà u trafficu à u pod di aghjurnamentu.
Quandu i cambiamenti sò finiti, avete bisognu di cliccà git push, i cambiamenti di codice seranu mandati à git, allora u sistema custruirà una maghjina cù una nova versione di u codice è "sprucerà" in u cluster, rimpiazzà i vechji pods. .
Iè, hè un pocu di una crutch, ma à u stessu tempu mantenemu l'architettura di u microserviziu è ùn caccià micca l'utilizatori di Bitrix a so opportunità preferita per correggerà u codice da u panel admin. In fine, questu hè una opzione chì pudete risolve u prublema di edità u codice in una manera diversa.
Graficu di Helm
Per custruisce applicazioni nantu à Kubernetes, generalmente usemu u gestore di pacchetti Helm.
Per a nostra suluzione Bitrix in Kubernetes, Sergey Bondarev, u nostru principale amministratore di sistema, hà scrittu un graficu Helm speciale.
Custruisce i travagliadori, l'upgrade, cron pods, cunfigura l'ingressi, i servizii, è trasferisce variabili da i secreti Kubernetes à i pods.
Almacenemu u codice in Gitlab, è avemu ancu eseguitu Helm build da Gitlab.
In corta, pare cusì
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm permette ancu di fà un rollback "senza saldatura" se di colpu qualcosa va male durante a implementazione. Hè bellu quandu ùn site micca in panicu "fissa u codice via ftp perchè u prod hè cascatu", ma Kubernetes faci automaticamente, è senza downtime.
Impulsà
Iè, simu fan di Gitlab & Gitlab CI, l'utilimu :)
Quandu s'impegna in Gitlab à u repository di u prugettu, Gitlab lancia un pipeline chì implementa una nova versione di l'ambiente.
Stage:
- custruisce (custruì una nova maghjina Docker)
- essai (test)
- pulisce (eliminà l'ambiente di prova)
- push (mandemu à u registru Docker)
- implementate (spieghemu l'applicazione à Kubernetes via Helm).
Hurrah, hè pronta, mettemu in pratica !
Ebbè, o fate dumande s'ellu ci hè.
Allora chì avemu fattu
Da un puntu di vista tecnicu:
- Dockerized Bitrix;
- "tagliate" Bitrix in cuntenituri, ognuna di quali eseguisce un minimu di funzioni;
- ottenutu statu senza statu di cuntenituri;
- risolviu u prublema cù l'aghjurnamentu di Bitrix in Kubernetes;
- tutte e funzioni Bitrix cuntinuavanu à travaglià (quasi tutti);
- Avemu travagliatu nantu à implementazione à Kubernetes è rollback trà e versioni.
Da un puntu di vista cummerciale:
- tolleranza à i difetti;
- Strumenti Kubernetes (integrazione faciule cù Gitlab CI, implementazione perfetta, etc.);
- password secreti (visibili solu per quelli chì sò direttamente cuncessi l'accessu à e password);
- Hè cunvenutu per creà ambienti supplementari (per u sviluppu, teste, etc.) in una sola infrastruttura.
Source: www.habr.com