În Chelyabinsk au loc întâlniri cu administratorul de sistem Sysadminka, iar la ultima am dat un raport despre soluția noastră pentru rularea aplicațiilor pe 1C-Bitrix în Kubernetes.
Bitrix, Kubernetes, Ceph - un amestec grozav?
Vă voi spune cum am pus împreună o soluție funcțională din toate acestea.
Să mergem!
Întâlnirea a avut loc pe 18 aprilie la Chelyabinsk. Puteți citi despre întâlnirile noastre la si uita-te la .
Dacă vrei să vii la noi cu un reportaj sau ca ascultător - bine ai venit, scrie la [e-mail protejat] și pe Telegram t.me/vadimisakanov.
Raportul meu
Soluție „Bitrix în Kubernetes, versiunea Southbridge 1.0”
Voi vorbi despre soluția noastră în formatul „pentru manechine în Kubernetes”, așa cum sa făcut la întâlnire. Dar presupun că știi cuvintele Bitrix, Docker, Kubernetes, Ceph cel puțin la nivelul articolelor de pe Wikipedia.
Ce este gata făcut despre Bitrix în Kubernetes?
Există foarte puține informații pe întregul Internet despre funcționarea aplicațiilor Bitrix în Kubernetes.
Am gasit doar aceste materiale:
Raportul lui Alexander Serbul, 1C-Bitrix și Anton Tuzlukov de la Qsoft:
Recomand să-l ascultați.
Dezvoltarea propriei soluții de la utilizator .
Am găsit mai multe .
Aaand... de fapt, asta-i tot.
Vă avertizez că nu am verificat calitatea soluțiilor din linkurile de mai sus :)
Apropo, când am pregătit soluția noastră, am vorbit cu Alexander Serbul, apoi raportul său nu a apărut încă, așa că în slide-urile mele există un element „Bitrix nu folosește Kubernetes”.
Dar există deja o mulțime de imagini Docker gata făcute pentru rularea Bitrix în Docker:
Este suficient acest lucru pentru a crea o soluție completă pentru Bitrix în Kubernetes?
Nu. Există un număr mare de probleme care trebuie rezolvate.
Care sunt problemele cu Bitrix în Kubernetes?
În primul rând, imaginile gata făcute de la Dockerhub nu sunt potrivite pentru Kubernetes
Dacă dorim să construim o arhitectură de microservicii (și în Kubernetes facem de obicei), trebuie să separăm aplicația noastră Kubernetes în containere și ca fiecare container să îndeplinească o funcție mică (și să o facă bine). De ce doar unul? Pe scurt, cu cât este mai simplu, cu atât mai fiabil.
Pentru a fi mai specific, vizionați acest articol și videoclip, vă rugăm:
Imaginile Docker din Dockerhub sunt în principiu construite pe principiul all-in-one, așa că a trebuit totuși să ne facem propria bicicletă și chiar să facem imagini de la zero.
În al doilea rând - codul site-ului este editat din panoul de administrare
Am creat o nouă secțiune pe site - codul a fost actualizat (a fost adăugat un director cu numele noii secțiuni).
Dacă ați modificat proprietățile unei componente din panoul de administrare, codul s-a schimbat.
Kubernetes „în mod implicit” nu poate funcționa cu aceasta; containerele trebuie să fie apatride.
Motiv: Fiecare container (pod) din cluster procesează doar o parte din trafic. Dacă modificați codul într-un singur container (pod), atunci codul va fi diferit în diferite poduri, site-ul va funcționa diferit și diferite versiuni ale site-ului vor fi afișate utilizatorilor diferiți. Nu poți trăi așa.
În al treilea rând - trebuie să rezolvați problema cu implementarea
Dacă avem un monolit și un server „clasic”, totul este destul de simplu: implementăm o nouă bază de cod, migrăm baza de date, comutăm traficul la noua versiune a codului. Comutarea are loc instantaneu.
Dacă avem un site în Kubernetes, tăiat în microservicii, există o mulțime de containere cu cod - oh. Trebuie să colectați containere cu o nouă versiune a codului, să le lansați în locul celor vechi, să migrați corect baza de date și, în mod ideal, să faceți acest lucru neobservat de vizitatori. Din fericire, Kubernetes ne ajută în acest sens, susținând o mulțime de tipuri diferite de implementări.
În al patrulea rând - trebuie să rezolvați problema stocării statică
Dacă site-ul dvs. are „doar” 10 gigaocteți și îl implementați în întregime în containere, veți ajunge cu containere de 10 gigaocteți care durează o veșnicie să se implementeze.
Trebuie să stocați cele mai „grele” părți ale site-ului în afara containerelor și apare întrebarea cum să faceți acest lucru corect
Ce lipsește din soluția noastră?
Întregul cod Bitrix nu este împărțit în microfuncții/microservicii (astfel încât înregistrarea să fie separată, modulul magazinului online este separat etc.). Stocăm întreaga bază de cod în fiecare container.
De asemenea, nu stocăm baza de date în Kubernetes (am implementat în continuare soluții cu o bază de date în Kubernetes pentru medii de dezvoltare, dar nu pentru producție).
Administratorii site-ului vor fi observați în continuare că site-ul rulează pe Kubernetes. Funcția de „verificare a sistemului” nu funcționează corect pentru a edita codul site-ului din panoul de administrare, trebuie mai întâi să faceți clic pe butonul „Vreau să editez codul”.
Problemele au fost identificate, a fost determinată necesitatea implementării microserviciilor, scopul este clar - obținerea unui sistem funcțional pentru rularea aplicațiilor pe Bitrix în Kubernetes, păstrând atât capacitățile Bitrix, cât și avantajele Kubernetes. Să începem implementarea.
Arhitectură
Există multe pod-uri „funcționale” cu un server web (lucrători).
Unul sub cu sarcini cron (este necesar doar unul).
Un singur upgrade pentru editarea codului site-ului din panoul de administrare (de asemenea, este necesar doar unul).
Rezolvam intrebari:
- Unde să stocați sesiunile?
- Unde să stochezi memoria cache?
- Unde să depozitați static, nu să plasați gigabyte de static într-o grămadă de containere?
- Cum va funcționa baza de date?
Imagine Docker
Începem prin a construi o imagine Docker.
Opțiunea ideală este că avem o singură imagine universală, pe baza acesteia obținem pod-uri pentru lucrători, pod-uri cu Crontask-uri și pod-uri de upgrade.
.
Include nginx, apache/php-fpm (poate fi selectat în timpul construirii), msmtp pentru trimiterea e-mailurilor și cron.
La asamblarea imaginii, întreaga bază de cod a site-ului este copiată în directorul /app (cu excepția acelor părți pe care le vom muta într-un spațiu de stocare partajat separat).
Microservicii, servicii
păstăi de muncitori:
- Container cu nginx + container apache/php-fpm + msmtp
- Nu a ieșit să muți msmtp într-un microserviciu separat, Bitrix începe să se indigneze că nu poate trimite e-mail direct
- Fiecare container are o bază de cod completă.
- Interzicerea schimbării codului în containere.
cron sub:
- container cu apache, php, cron
- bază de cod complet inclusă
- interzicerea modificării codului în containere
upgrade sub:
- container nginx + container apache/php-fpm + msmtp
- Nu există nicio interdicție privind schimbarea codului în containere
stocarea sesiunii
Stocare în cache Bitrix
Un alt lucru important: stocăm parolele pentru conectarea la orice, de la bază de date la mail, în secrete kubernetes. Primim un bonus: parolele sunt vizibile doar celor cărora le dăm acces la secrete și nu tuturor celor care au acces la baza de coduri a proiectului.
Depozitare pentru statică
Puteți folosi orice: ceph, nfs (dar nu recomandăm nfs pentru producție), stocare în rețea de la furnizorii de cloud etc.
Stocarea va trebui conectată în containere la directorul /upload/ al site-ului și la alte directoare cu conținut static.
bază de date
Pentru simplitate, vă recomandăm să mutați baza de date în afara Kubernetes. Baza din Kubernetes este o sarcină complexă separată, va face schema un ordin de mărime mai complexă.
Stocarea sesiunii
Folosim memcached :)
Se ocupă bine de stocarea sesiunii, este grupat și este acceptat „nativ” ca session.save_path în php. Un astfel de sistem a fost testat de multe ori în arhitectura clasică monolitică, când am construit clustere cu un număr mare de servere web. Pentru desfășurare folosim cârma.
$ helm install stable/memcached --name sessionphp.ini - aici imaginea conține setări pentru stocarea sesiunilor în memcached
Am folosit variabilele de mediu pentru a transmite date despre gazde cu memcached .
Acest lucru vă permite să utilizați același cod în mediile de dev, stage, test, prod (numele de gazdă memcached din ele vor fi diferite, așa că trebuie să transmitem un nume de gazdă unic pentru sesiuni fiecărui mediu).
Stocare în cache Bitrix
Avem nevoie de o stocare tolerantă la erori în care toate podurile să poată scrie și din care să citească.
De asemenea, folosim memcached.
Această soluție este recomandată chiar de Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - aici in Bitrix este specificat unde este stocat cache-ul
De asemenea, folosim variabile de mediu.
Krontaski
Există diferite abordări pentru a rula Crontasks în Kubernetes.
- implementare separată cu un pod pentru rularea Crontasks
- cronjob pentru executarea crontask-urilor (dacă aceasta este o aplicație web - cu wget , sau kubectl exec într-unul dintre podurile de lucru etc.)
- etc
Puteți argumenta despre cel mai corect, dar în acest caz am ales opțiunea „implementare separată cu poduri pentru Crontasks”
Cum se face:
- adăugați sarcini cron prin ConfigMap sau prin fișierul config/addcron
- într-un caz lansăm un container identic cu podul lucrător + permitem executarea sarcinilor coroanei în acesta
- se folosește aceeași bază de cod, datorită unificării, asamblarea containerului este simplă
Ce bine avem:
- avem Crontask-uri de lucru într-un mediu identic cu mediul dezvoltatorilor (docker)
- Crontask-urile nu trebuie să fie „rescrise” pentru Kubernetes, ele funcționează în aceeași formă și în aceeași bază de cod ca înainte
- Sarcinile cron pot fi adăugate de toți membrii echipei cu drepturi de commit în ramura de producție, nu doar de administratori
Southbridge K8SDeploy modul și editarea codului din panoul de administrare
Vorbeam despre upgrade sub?
Cum să direcționezi traficul acolo?
Ura, am scris un modul pentru asta în PHP :) Acesta este un mic modul clasic pentru Bitrix. Nu este încă disponibil public, dar intenționăm să-l deschidem.
Modulul este instalat ca un modul obișnuit în Bitrix:
Și arată așa:
Vă permite să setați un cookie care identifică administratorul site-ului și permite Kubernetes să trimită trafic către podul de upgrade.
Când modificările sunt finalizate, trebuie să faceți clic pe git push, modificările codului vor fi trimise la git, apoi sistemul va construi o imagine cu o nouă versiune a codului și o va „dezvolta” în cluster, înlocuind vechile pod-uri. .
Da, este un pic o cârjă, dar în același timp menținem arhitectura microserviciului și nu le luăm utilizatorilor Bitrix oportunitatea preferată de a corecta codul din panoul de administrare. În cele din urmă, aceasta este o opțiune, puteți rezolva problema editării codului într-un mod diferit.
Diagrama de cârmă
Pentru a construi aplicații pe Kubernetes, folosim de obicei managerul de pachete Helm.
Pentru soluția noastră Bitrix din Kubernetes, Sergey Bondarev, administratorul nostru principal de sistem, a scris o diagramă Helm specială.
Acesta creează worker, upgrade, cron pods, configurează intrări, servicii și transferă variabile de la secretele Kubernetes la pod-uri.
Stocăm codul în Gitlab și rulăm și versiunea Helm din Gitlab.
Pe scurt, așa arată
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm vă permite, de asemenea, să faceți o derulare „fără întreruperi” dacă brusc ceva nu merge bine în timpul implementării. Este plăcut când nu sunteți în panică „remediați codul prin ftp, deoarece produsul a căzut”, dar Kubernetes o face automat și fără timpi de nefuncționare.
Implementează
Da, suntem fani ai Gitlab & Gitlab CI, îl folosim :)
Când se angajează în Gitlab în depozitul de proiect, Gitlab lansează o conductă care implementează o nouă versiune a mediului.
etape:
- build (construirea unei noi imagini Docker)
- testare (testare)
- curățare (eliminarea mediului de testare)
- push (o trimitem la registrul Docker)
- deploy (implementăm aplicația în Kubernetes prin Helm).
Ura, e gata, hai să-l implementăm!
Ei bine, sau pune întrebări dacă există.
Deci ce am făcut
Din punct de vedere tehnic:
- Bitrix dockerizat;
- „tăiați” Bitrix în containere, fiecare dintre ele îndeplinește un minim de funcții;
- a atins starea apatridă a containerelor;
- a rezolvat problema cu actualizarea Bitrix în Kubernetes;
- toate funcțiile Bitrix au continuat să funcționeze (aproape toate);
- Am lucrat la implementarea în Kubernetes și la rollback între versiuni.
Din punct de vedere al afacerilor:
- toleranta la erori;
- Instrumente Kubernetes (integrare ușoară cu Gitlab CI, implementare fără întreruperi etc);
- parole secrete (vizibile numai pentru cei cărora li se acordă acces direct la parole);
- Este convenabil să creați medii suplimentare (pentru dezvoltare, teste etc.) într-o singură infrastructură.
Sursa: www.habr.com