Les trobades d'administradors del sistema Sysadminka estan tenint lloc a Chelyabinsk, i a la darrera vaig donar un informe sobre la nostra solució per executar aplicacions a 1C-Bitrix a Kubernetes.
Bitrix, Kubernetes, Ceph: una gran barreja?
Us explicaré com hem creat una solució de treball a partir de tot això.
Anem!
La trobada va tenir lloc el 18 d'abril a Chelyabinsk. Pots llegir sobre les nostres trobades a i mira .
Si vols venir a nosaltres amb un reportatge o com a oient - benvingut, escriu-hi [protegit per correu electrònic] i a Telegram t.me/vadimisakanov.
El meu informe
Solució "Bitrix a Kubernetes, versió Southbridge 1.0"
Parlaré de la nostra solució en el format "per a maniquís a Kubernetes", tal com es va fer a la reunió. Però suposo que coneixeu les paraules Bitrix, Docker, Kubernetes, Ceph almenys a nivell d'articles a la Viquipèdia.
Què està fet de Bitrix a Kubernetes?
Hi ha molt poca informació a tot Internet sobre el funcionament de les aplicacions Bitrix a Kubernetes.
Només he trobat aquests materials:
Informe d'Alexander Serbul, 1C-Bitrix i Anton Tuzlukov de Qsoft:
Recomano escoltar-lo.
Desenvolupament de la teva pròpia solució a partir de l'usuari .
N'he trobat més .
Aaand... en realitat, això és tot.
Us adverteixo que no hem comprovat la qualitat de les solucions als enllaços anteriors :)
Per cert, en preparar la nostra solució, vaig parlar amb Alexander Serbul, llavors el seu informe encara no havia aparegut, així que a les meves diapositives hi ha un element "Bitrix no utilitza Kubernetes".
Però ja hi ha moltes imatges de Docker preparades per executar Bitrix a Docker:
És suficient amb això per crear una solució completa per a Bitrix a Kubernetes?
No. Hi ha un gran nombre de problemes que cal resoldre.
Quins són els problemes amb Bitrix a Kubernetes?
En primer lloc, les imatges ja fetes de Dockerhub no són adequades per a Kubernetes
Si volem construir una arquitectura de microserveis (i a Kubernetes solem fer), hem de separar la nostra aplicació Kubernetes en contenidors i que cada contenidor faci una petita funció (i ho faci bé). Per què només un? En resum, com més senzill, més fiable.
Per ser més específic, mireu aquest article i vídeo, si us plau:
Les imatges de Docker a Dockerhub es basen principalment en el principi de tot-en-un, de manera que encara havíem de fer la nostra pròpia bicicleta i fins i tot crear imatges des de zero.
En segon lloc: el codi del lloc s'edita des del tauler d'administració
Vam crear una nova secció al lloc: el codi es va actualitzar (es va afegir un directori amb el nom de la nova secció).
Si heu canviat les propietats d'un component des del tauler d'administració, el codi canvia.
Kubernetes "per defecte" no pot funcionar amb això; els contenidors han de ser sense estat.
Motiu: cada contenidor (pod) del clúster processa només una part del trànsit. Si canvieu el codi només en un contenidor (pod), el codi serà diferent en diferents pods, el lloc funcionarà de manera diferent i es mostraran diferents versions del lloc als diferents usuaris. No pots viure així.
En tercer lloc, heu de resoldre el problema amb el desplegament
Si tenim un monòlit i un servidor "clàssic", tot és bastant senzill: despleguem una nova base de codi, migrem la base de dades, canviem el trànsit a la nova versió del codi. El canvi es produeix a l'instant.
Si tenim un lloc a Kubernetes, tallat en microserveis, hi ha molts contenidors amb codi, oh. Heu de recollir contenidors amb una versió nova del codi, desplegar-los en comptes dels antics, migrar correctament la base de dades i, idealment, fer-ho sense que els visitants s'adonin. Afortunadament, Kubernetes ens ajuda amb això, donant suport a un munt de diferents tipus de desplegaments.
En quart lloc, heu de resoldre el problema d'emmagatzemar estàtica
Si el vostre lloc té "només" 10 gigabytes i el desplegueu completament en contenidors, acabareu amb contenidors de 10 gigabytes que triguen una eternitat a desplegar-se.
Heu d'emmagatzemar les parts "més pesades" del lloc fora dels contenidors, i sorgeix la pregunta de com fer-ho correctament
Què falta a la nostra solució?
Tot el codi Bitrix no està dividit en microfuncions/microserveis (de manera que el registre sigui separat, el mòdul de la botiga en línia està separat, etc.). Emmagatzemem tot el codi base a cada contenidor.
Tampoc emmagatzemem la base de dades a Kubernetes (encara he implementat solucions amb una base de dades a Kubernetes per a entorns de desenvolupament, però no per a producció).
Els administradors del lloc encara podran notar que el lloc s'executa a Kubernetes. La funció de "comprovació del sistema" no funciona correctament; per editar el codi del lloc des del tauler d'administració, primer heu de fer clic al botó "Vull editar el codi".
S'han identificat els problemes, s'ha determinat la necessitat d'implementar microserveis, l'objectiu és clar: aconseguir un sistema que funcioni per executar aplicacions a Bitrix a Kubernetes, preservant tant les capacitats de Bitrix com els avantatges de Kubernetes. Comencem la implementació.
arquitectura
Hi ha molts pods "funcionants" amb un servidor web (treballadors).
Un sota amb tasques cron (només cal un).
Una actualització per editar el codi del lloc des del tauler d'administració (també només cal una).
Resolem preguntes:
- On emmagatzemar les sessions?
- On emmagatzemar la memòria cau?
- On emmagatzemar l'estàtica, no posar gigabytes d'estàtica en un munt de contenidors?
- Com funcionarà la base de dades?
Imatge de Docker
Comencem construint una imatge de Docker.
L'opció ideal és que tinguem una imatge universal, a partir d'ella obtenim pods de treballador, pods amb Crontasks i pods d'actualització.
.
Inclou nginx, apache/php-fpm (es pot seleccionar durant la construcció), msmtp per enviar correu i cron.
En muntar la imatge, tot el codi base del lloc es copia al directori /app (a excepció d'aquelles parts que traslladarem a un emmagatzematge compartit independent).
Microserveis, serveis
càpsules de treballador:
- Contenidor amb nginx + contenidor apache/php-fpm + msmtp
- No va funcionar moure msmtp a un microservei independent, Bitrix comença a indignar-se perquè no pot enviar correu directament
- Cada contenidor té una base de codi completa.
- Prohibició de canviar el codi als contenidors.
cron sota:
- contenidor amb apache, php, cron
- base de codi completa inclosa
- prohibició de canviar el codi als contenidors
actualització a:
- contenidor nginx + contenidor apache/php-fpm + msmtp
- No hi ha prohibició de canviar el codi als contenidors
emmagatzematge de la sessió
Emmagatzematge de memòria cau Bitrix
Una altra cosa important: emmagatzemem contrasenyes per connectar-nos a tot, des de la base de dades fins al correu, en secrets de kubernetes. Tenim un avantatge: les contrasenyes només són visibles per a aquells a qui donem accés als secrets, i no per a tothom que tingui accés al codi base del projecte.
Emmagatzematge per estàtica
Podeu utilitzar qualsevol cosa: ceph, nfs (però no recomanem nfs per a la producció), emmagatzematge en xarxa dels proveïdors de núvol, etc.
L'emmagatzematge haurà d'estar connectat en contenidors al directori /upload/ del lloc i altres directoris amb contingut estàtic.
Base de dades
Per simplificar, recomanem moure la base de dades fora de Kubernetes. La base a Kubernetes és una tasca complexa a part; farà que l'esquema sigui un ordre de magnitud més complex.
Emmagatzematge de la sessió
Utilitzem memcached :)
Gestiona bé l'emmagatzematge de sessions, està agrupat i s'admet "de manera nativa" com a session.save_path a php. Aquest sistema s'ha provat moltes vegades en l'arquitectura monolítica clàssica, quan vam construir clústers amb un gran nombre de servidors web. Per al desplegament fem servir el timó.
$ helm install stable/memcached --name sessionphp.ini: aquí la imatge conté la configuració per emmagatzemar sessions a memcached
Hem utilitzat variables d'entorn per passar dades sobre amfitrions amb memcached .
Això us permet utilitzar el mateix codi als entorns de desenvolupament, fase, prova i prod (els noms d'amfitrió de memcache seran diferents, de manera que hem de passar un nom d'amfitrió únic per a les sessions a cada entorn).
Emmagatzematge de memòria cau Bitrix
Necessitem un emmagatzematge tolerant a errors on tots els pods puguin escriure i llegir.
També fem servir memcached.
Aquesta solució és recomanada pel mateix Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php: aquí a Bitrix s'especifica on s'emmagatzema la memòria cau
També fem servir variables d'entorn.
Krontaski
Hi ha diferents enfocaments per executar Crontasks a Kubernetes.
- desplegament separat amb un pod per executar Crontasks
- cronjob per executar crontasks (si es tracta d'una aplicació web - amb wget , o kubectl exec dins d'un dels pods de treball, etc.)
- etcètera...
Podeu discutir sobre el més correcte, però en aquest cas vam triar l'opció "desplegament separat amb pods per a Crontasks"
Com es fa:
- afegiu tasques cron mitjançant ConfigMap o mitjançant el fitxer config/addcron
- en una instància llancem un contenidor idèntic al pod de treballador + permetem l'execució de tasques de la corona en ell
- s'utilitza la mateixa base de codi, gràcies a la unificació, el muntatge del contenidor és senzill
Què bé ens surt:
- tenim Crontasks en funcionament en un entorn idèntic a l'entorn dels desenvolupadors (docker)
- Les crontasks no necessiten ser "reescrites" per a Kubernetes, funcionen de la mateixa forma i amb la mateixa base de codi que abans
- Les tasques cron les poden afegir tots els membres de l'equip amb drets de commit a la branca de producció, no només els administradors
Southbridge K8SDeploy mòdul i edició de codi des del tauler d'administració
Estàvem parlant d'actualització a?
Com dirigir-hi el trànsit?
Hura, vam escriure un mòdul per a això en PHP :) Aquest és un petit mòdul clàssic per a Bitrix. Encara no està disponible públicament, però tenim previst obrir-lo.
El mòdul s'instal·la com un mòdul normal a Bitrix:
I es veu així:
Us permet establir una galeta que identifica l'administrador del lloc i permet a Kubernetes enviar trànsit al pod d'actualització.
Quan s'hagin completat els canvis, heu de fer clic a git push, els canvis de codi s'enviaran a git i, a continuació, el sistema crearà una imatge amb una nova versió del codi i la "desplegarà" al clúster, substituint els pods antics. .
Sí, és una mica una crossa, però al mateix temps mantenim l'arquitectura del microservei i no traiem als usuaris de Bitrix la seva oportunitat preferida de corregir el codi des del tauler d'administració. Al final, aquesta és una opció; podeu resoldre el problema d'editar el codi d'una altra manera.
Quadre de timó
Per crear aplicacions a Kubernetes, normalment utilitzem el gestor de paquets Helm.
Per a la nostra solució Bitrix a Kubernetes, Sergey Bondarev, el nostre principal administrador del sistema, va escriure un gràfic especial de Helm.
Crea worker, upgrade, cron pods, configura entrades, serveis i transfereix variables dels secrets de Kubernetes als pods.
Emmagatzemem el codi a Gitlab i també executem la compilació Helm des de Gitlab.
En resum, sembla així
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm també us permet fer un retrocés "perfecte" si de sobte alguna cosa va malament durant el desplegament. És bo quan no esteu en pànic "arreglar el codi mitjançant ftp perquè el producte ha caigut", però Kubernetes ho fa automàticament i sense temps d'inactivitat.
Desplega
Sí, som fans de Gitlab i Gitlab CI, el fem servir :)
Quan es compromet a Gitlab amb el dipòsit del projecte, Gitlab llança un pipeline que desplega una nova versió de l'entorn.
Etapes:
- construir (crear una nova imatge de Docker)
- prova (prova)
- neteja (eliminació de l'entorn de prova)
- push (l'enviem al registre de Docker)
- desplega (despleguem l'aplicació a Kubernetes mitjançant Helm).
Hura, ja està llest, posem-ho en pràctica!
Bé, o feu preguntes si n'hi ha.
Aleshores, què vam fer
Des del punt de vista tècnic:
- Bitrix dockeritzat;
- "tallar" Bitrix en contenidors, cadascun dels quals realitza un mínim de funcions;
- s'ha aconseguit l'estat sense estat dels contenidors;
- va resoldre el problema amb l'actualització de Bitrix a Kubernetes;
- totes les funcions de Bitrix van continuar funcionant (gairebé totes);
- Hem treballat en el desplegament a Kubernetes i en el retrocés entre versions.
Des del punt de vista empresarial:
- falta de tolerància;
- Eines de Kubernetes (integració fàcil amb Gitlab CI, implementació perfecta, etc.);
- contrasenyes secretes (visibles només per a aquells que tinguin accés directament a les contrasenyes);
- És convenient crear entorns addicionals (per al desenvolupament, proves, etc.) dins d'una única infraestructura.
Font: www.habr.com