În Chelyabinsk au loc întâlniri ale sistemelor administrațiilor Sysadminka, iar la ultima dintre ele am susținut o prezentare despre soluția noastră pentru aplicarea 1C-Bitrix în Kubernetes.
Bitrix, Kubernetes, Ceph - un amestec excelent?
Voi povesti cum am reușit să construim o soluție funcțională din toate acestea.
Configurarea Mitogen pentru Ansible este foarte simplă:
Întâlnirea a avut loc pe 18 aprilie în Chelyabinsk. Despre întâlnirile noastre puteți citi în și verifica pe .
Dacă doriți să veniți la noi cu o prezentare sau ca ascultător - sunteți bineveniți, scrieți la vadim.isakanov@gmail.com și pe Telegram t.me/vadimisakanov.
Prezentarea mea
Soluția „Bitrix în Kubernetes, versiunea Southbridge 1.0”
Voi vorbi despre soluția noastră într-un format „pentru începători în Kubernetes”, așa cum a fost prezentată la întâlnire. Dar presupun că termenii Bitrix, Docker, Kubernetes, Ceph vă sunt cunoscuți cel puțin la nivel de articole pe Wikipedia.
Ce informații există despre Bitrix în Kubernetes?
Pe internet există foarte puține informații despre funcționarea aplicațiilor cu Bitrix în Kubernetes.
Am găsit doar următoarele materiale:
Prezentarea lui Alexandru Serbul, 1C-Bitrix, și Anton Tuzlukov de la Qsoft:
Recomand să-l ascultați.
Dezvoltarea unei soluții proprii de utilizator .
Am găsit și .
Și… cam atât.
Vă avertizez, nu am verificat calitatea soluțiilor de la linkurile de mai sus 🙂
Apropo, în pregătirea soluției noastre am discutat cu Alexandru Serbul, prezentarea lui nu era disponibilă atunci, așa că în slide-urile mele există un punct denumind „Bitrix nu folosește Kubernetes”.
Dar există deja multe imagini Docker gata pregătite pentru a lucra cu Bitrix în Docker:
Este suficient pentru a crea o soluție completă pentru Bitrix în Kubernetes?
Nu. Există o mulțime de probleme care trebuie rezolvate.
Care sunt problemele cu Bitrix în Kubernetes?
Prima - imaginile pregătite din Dockerhub nu sunt potrivite pentru Kubernetes.
Dacă dorim să construim o arhitectură bazată pe microservicii (și în Kubernetes de obicei dorim), aplicația în Kubernetes trebuie să fie împărțită în containere și să ne asigurăm că fiecare container îndeplinește o mică funcție (și o face bine). De ce doar una? Pe scurt - cu cât este mai simplu, cu atât mai fiabil.
Dacă doriți o explicare mai detaliată - vă rog să vizionați acest articol și video:
Imaginile Docker din Dockerhub sunt construite în principal pe principiul „totul într-unul”, așa că a trebuit să ne creăm propria soluție și chiar să facem imaginile de la zero.
A doua - codul site-ului este modificat din panoul de administrare.
Am creat o nouă secțiune pe site — codul s-a actualizat (a fost adăugată un director cu denumirea noii secțiuni).
Am modificat proprietățile componentei din panoul de administrare — codul s-a schimbat.
Kubernetes „din start” nu poate lucra astfel, containerele trebuie să fie nemodificabile (Stateless).
Motivul: fiecare container (pod) din cluster procesează doar o parte din trafic. Dacă modifici codul doar într-un singur container (pod), atunci în diferite poduri codul va fi diferit, site-ul va funcționa diferit, utilizatorilor le vor fi arătate versiuni diferite ale site-ului. Așa nu se poate trăi.
Al treilea — trebuie să rezolvăm problema cu deployment-ul.
Dacă avem un monolit și un server „clasic”, totul este foarte simplu: desfășurăm o nouă bază de cod, efectuăm migrarea bazei de date, redirecționăm traficul către noua versiune a codului. Schimbarea se face instantaneu.
Dacă avem un site în Kubernetes, împărțit pe microservicii, cu multe containere cu cod — oh. Trebuie să construim containere cu noua versiune a codului, să le lansăm în locul celor vechi, să efectuăm corect migrarea bazei de date, iar ideal ar fi să facem acest lucru fără ca vizitatorii să observe. Din fericire, Kubernetes ne ajută în acest sens, susținând o varietate de tipuri de deployment.
Al patrulea — trebuie să rezolvăm problema cu stocarea staticei.
Dacă site-ul vostru are „doar” 10 gigabytes și îl desfășurați complet în containere, veți obține containere de 10 gigabytes care se vor desfășura o eternitate.
Trebuie să stocăm cele mai „grele” părți ale site-ului în afara containerelor, și apare întrebarea cum să facem acest lucru corect.
Ce nu există în soluția noastră.
Întreg codul Bitrix nu este împărțit pe microfuncții/microservicii (astfel încât, înregistrarea să fie separată, modulul de magazin online separat, etc.). Întreaga bază de cod o păstrăm în fiecare container în întregime.
Baza de date nici în Kubernetes nu este stocată (totuși am implementat soluții cu baza în Kubernetes pentru medii de dezvoltare, dar nu pentru producție).
Administrația site-ului va observa totuși că site-ul funcționează în Kubernetes. Funcția „verificarea sistemului” nu funcționează corect; pentru a edita codul site-ului din panoul de administrare, trebuie mai întâi să apăsați butonul „vreau să editez codul”.
Am identificat problemele, am stabilit necesitatea implementării microserviciilor, obiectivul este clar - a obține un sistem funcțional pentru aplicațiile Bitrix în Kubernetes, păstrând atât funcționalitățile Bitrix, cât și avantajele Kubernetes. Începem implementarea.
Arhitectură
Multe poduri „active” cu server web (worker).
Un pod cu sarcini cron (numai unul este obligatoriu).
Un pod de upgrade pentru editarea codului site-ului din panoul de administrare (de asemenea, obligatoriu doar unul).
Rezolvăm problemele:
- Unde să stocăm sesiunile?
- Unde să stocăm cache-ul?
- Unde să stocăm fișierele statice, nu putem pune gigabytes de fișiere statice într-o mulțime de containere?
- Cum va funcționa baza de date?
Imagine Docker
Începem cu construirea imaginii Docker.
Varianta ideală - avem o imagine universală, pe baza ei obținem atât poduri worker, cât și poduri cu sarcini cron și poduri de upgrade.
.
Aceasta include nginx, apache/php-fpm (poate fi ales la construcție), msmtp pentru trimiterea de emailuri și cron.
La construirea imaginii, întregul cod sursă al site-ului este copiat în directorul /app (cu excepția părților pe care le vom muta într-un stocare partajată separată).
Microservicii, servicii
poduri worker:
- container cu nginx + container apache/php-fpm + msmtp
- msmtp nu a putut fi mutat într-un microserviciu separat, Bitrix începe să protesteze că nu poate trimite emailuri direct.
- Fiecare container are întregul cod sursă.
- Interzicerea modificării codului în containere.
pod cron:
- container cu apache, php, cron
- în pachet se află întregul cod sursă
- interzicerea modificării codului în containere
pod de upgrade:
- container cu nginx + container apache/php-fpm + msmtp
- nu există interdicție de modificare a codului în containere
stocarea sesiunilor
stocarea cache-ului Bitrix
De asemenea, este important: parolele pentru conectarea la tot, de la baze de date la email, le stocăm în secretele Kubernetes. Obținem un avantaj, parolele sunt vizibile doar pentru cei cărora le oferim acces la secrete, nu tuturor celor care au acces la codul sursă al proiectului.
Stocarea pentru fișiere statice
Putem folosi orice: ceph, nfs (dar nfs nu este recomandat pentru producție), stocare de rețea de la furnizorii 'cloud', etc.
Va trebui să conectăm stocarea în containere în directorul /upload/ al site-ului și în alte directoare cu fișiere statice.
Baza de date
Pentru simplitate, recomandăm să scoatem baza din Kubernetes. O bază în Kubernetes este o sarcină complicată separată, va face schema mult mai complexă.
Stocarea sesiunilor
Folosim memcached 🙂
Se descurcă bine cu stocarea sesiunilor, este clusterizat și este suportat „nativ” ca session.save_path în php. Un astfel de sistem a fost testat de multe ori în arhitectura monolitică clasică, când construam clustere cu un număr mare de servere web. Pentru desfășurare, folosim helm.
$ helm install stable/memcached --name sessionphp.ini – aici sunt definite setările pentru stocarea sesiunilor în memcached
Am folosit variabile de mediu pentru a transmite datele despre hosturile cu memcached .
Aceasta permite utilizarea aceluiași cod în medii dev, stage, test, prod (numele hosturilor memcached în ele vor fi diferite, de aceea pentru fiecare mediu trebuie să transmitem un nume unic al hosturilor pentru sesiuni).
Stocarea cache-ului Bitrix
Avem nevoie de un stocaj rezistent la erori, în care toate podurile să poată scrie și din care să poată citi.
De asemenea, folosim memcached.
Această soluție este recomandată de Bitrix în sine.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php – aici în Bitrix este specificat unde stocăm cache-ul
De asemenea, folosim variabile de mediu.
Cron tasks
Există diferite abordări pentru executarea cron task-urilor în Kubernetes.
- o desfășurare separată cu un pod pentru executarea cron task-urilor
- cronjob pentru executarea cron task-urilor (dacă este aplicație web — cu wget , sau kubectl exec în interiorul unuia dintre podurile worker, etc.)
- etc.
Se poate discuta despre cel mai corect, dar în acest caz am ales opțiunea „desfășurare separată cu poduri pentru cron tasks”
Cum este realizat:
- adăugăm cron-task-urile prin ConfigMap sau prin fișierul config/addcron
- într-un singur exemplar lansăm un container, identic cu podul worker + permitem executarea cron-task-urilor în el
- se folosește aceeași bază de cod, datorită unificării construcția containerului este simplă
Ce beneficii obținem:
- avem cron-task-uri funcționale într-un mediu identic cu cel al dezvoltatorilor (docker)
- cron-task-urile nu trebuie „rescrise” pentru Kubernetes, ele funcționează în aceeași formă și în aceeași bază de cod ca înainte
- cron-task-urile pot fi adăugate de toți membrii echipei cu drepturi de commit în ramura de producție, nu doar de administratori
Modulul Southbridge K8SDeploy și editarea codului din panoul de administrare
De fapt, vorbeam despre upgrade-ul pod-ului?
Și cum direcționăm traficul acolo?
Ura, am scris un modul pentru aceasta în php 🙂 Este un mic modul clasic pentru Bitrix. Î încă nu este disponibil public, dar plănuim să-l deschidem.
Modulul se instalează ca un modul obișnuit în Bitrix:
Și arată astfel:
Permite setarea unui cookie care identifică administratorul site-ului și permite Kubernetes să redirecționeze traficul către upgrade pod.
Când modificările sunt finalizate, trebuie să apăsați git push, modificările codului vor fi trimise în git, apoi sistemul va construi o imagine cu noua versiune a codului și o va distribui în cluster, înlocuind podurile vechi.
Da, este puțin mai complicat, dar în același timp păstrăm arhitectura microserviciilor și nu luăm utilizatorilor Bitrix opțiunea preferată de a modifica codul din panoul de administrare. La urma urmei, este o opțiune, puteți rezolva problema modificării codului în alt mod.
Chart Helm
Pentru construirea aplicațiilor în Kubernetes, de obicei, folosim managerul de pachete Helm.
Pentru soluția noastră Bitrix în Kubernetes, Serghei Bondarev, administratorul nostru de sistem principal, a scris un chart Helm special.
Acesta construiește worker, upgrade, cron pod-uri, configurează ingress-uri, servicii, transmite variabilele din secretele Kubernetes în pod-uri.
Codul îl stocăm în Gitlab, iar construcția Helm o lansăm tot din Gitlab.
Pe scurt, arată cam așa
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionDe asemenea, Helm permite să efectuezi un rollback „fără cusur”, dacă, dintr-o dată, ceva nu a mers bine la deploy. Este plăcut când nu ești în panică „fixând codul pe ftp, pentru că producția a căzut”, ci Kubernetes face asta automat, fără downtime.
Deploy
Da, suntem fani Gitlab & Gitlab CI, îl folosim 🙂
La commit în Gitlab în repository-ul proiectului, Gitlab lansează un pipeline care desfășoară o nouă versiune a mediului.
Etapele:
- build (construim o nouă imagine Docker)
- test (testăm)
- clean up (ștergem mediu de testare)
- push (îl trimitem în Docker registry)
- deploy (desfășurăm aplicația în Kubernetes prin Helm).
Ura, este gata, implementăm!
Sau punem întrebări, dacă sunt.
Deci, ce am realizat
Din punct de vedere tehnic:
- am dockerizat Bitrix;
- am „tăiat” Bitrix în containere, fiecare având funcții minime;
- am obținut un stateless pentru containere;
- am rezolvat problema actualizării Bitrix în Kubernetes;
- toate funcțiile Bitrix au continuat să funcționeze (aproape toate);
- am finalizat deploy-ul în Kubernetes și rollback-ul între versiuni.
Din punct de vedere al afacerii:
- reziliență;
- instrumente Kubernetes (integrări simple cu Gitlab CI, deploy fără cusur, etc);
- parole în secrete (vizibile doar celor căror li s-a acordat direct acces la parole);
- Este convenabil să creezi medii suplimentare (pentru dezvoltare, teste etc.) în cadrul unei singure infrastructuri.
Sursa: habr.com
