Sysadminka systemadministratormøter finner sted i Chelyabinsk, og på den siste ga jeg en rapport om løsningen vår for å kjøre applikasjoner på 1C-Bitrix i Kubernetes.
Bitrix, Kubernetes, Ceph - en flott blanding?
Jeg skal fortelle deg hvordan vi setter sammen en fungerende løsning fra alt dette.
La oss gå!
Møtet fant sted 18. april i Chelyabinsk. Du kan lese om møtene våre på og se på .
Ønsker du å komme til oss med en reportasje eller som lytter – velkommen, skriv til [e-postbeskyttet] og på Telegram t.me/vadimisakanov.
Rapporten min
Løsning "Bitrix i Kubernetes, versjon Southbridge 1.0"
Jeg vil snakke om løsningen vår i formatet "for dummies i Kubernetes", slik det ble gjort på møtet. Men jeg antar at du kjenner ordene Bitrix, Docker, Kubernetes, Ceph i det minste på nivå med artikler på Wikipedia.
Hva er ferdig med Bitrix i Kubernetes?
Det er svært lite informasjon på hele Internett om driften av Bitrix-applikasjoner i Kubernetes.
Jeg fant bare disse materialene:
Rapport av Alexander Serbul, 1C-Bitrix og Anton Tuzlukov fra Qsoft:
Jeg anbefaler å lytte til den.
Utvikle din egen løsning fra brukeren .
Fant mer .
Aaand... faktisk, det er alt.
Jeg advarer deg, vi har ikke sjekket kvaliteten på løsningene i lenkene ovenfor :)
Forresten, da jeg forberedte løsningen vår, snakket jeg med Alexander Serbul, da hadde rapporten hans ennå ikke dukket opp, så i lysbildene mine er det et element "Bitrix bruker ikke Kubernetes."
Men det er allerede mange ferdige Docker-bilder for å kjøre Bitrix i Docker:
Er dette nok til å lage en komplett løsning for Bitrix i Kubernetes?
Nei. Det er et stort antall problemer som må løses.
Hva er problemene med Bitrix i Kubernetes?
For det første er ikke ferdige bilder fra Dockerhub egnet for Kubernetes
Hvis vi ønsker å bygge en mikrotjenester-arkitektur (og det gjør vi vanligvis i Kubernetes), må vi separere Kubernetes-applikasjonen vår i containere og få hver container til å utføre en liten funksjon (og gjøre det bra). Hvorfor bare én? Kort sagt, jo enklere jo mer pålitelig.
For å være mer spesifikk, se denne artikkelen og videoen, vennligst:
Docker-bilder i Dockerhub er hovedsakelig bygget på alt-i-ett-prinsippet, så vi måtte fortsatt lage vår egen sykkel og til og med lage bilder fra bunnen av.
For det andre - nettstedskoden redigeres fra administrasjonspanelet
Vi opprettet en ny seksjon på nettstedet - koden ble oppdatert (en katalog med navnet på den nye seksjonen ble lagt til).
Hvis du endret egenskapene til en komponent fra administrasjonspanelet, ble koden endret.
Kubernetes "som standard" kan ikke fungere med dette; containere må være statsløse.
Årsak: Hver beholder (pod) i klyngen behandler bare en del av trafikken. Hvis du endrer koden i bare én beholder (pod), vil koden være forskjellig i forskjellige pods, siden vil fungere annerledes, og forskjellige versjoner av nettstedet vil bli vist til forskjellige brukere. Du kan ikke leve slik.
For det tredje - du må løse problemet med distribusjon
Hvis vi har en monolitt og en "klassisk" server, er alt ganske enkelt: vi distribuerer en ny kodebase, migrerer databasen, bytter trafikk til den nye versjonen av koden. Bytting skjer umiddelbart.
Hvis vi har et nettsted i Kubernetes, kuttet inn i mikrotjenester, er det mange containere med kode - oh. Du må samle beholdere med en ny versjon av koden, rulle dem ut i stedet for de gamle, migrere databasen på riktig måte, og ideelt sett gjøre dette ubemerket av besøkende. Heldigvis hjelper Kubernetes oss med dette, og støtter en hel haug med forskjellige typer distribusjoner.
For det fjerde - du må løse problemet med lagring av statikk
Hvis nettstedet ditt "bare" er på 10 gigabyte og du distribuerer det helt i containere, vil du ende opp med 10 gigabyte containere som tar evigheter å distribuere.
Du må lagre de "tyngste" delene av nettstedet utenfor containere, og spørsmålet oppstår om hvordan du gjør dette riktig
Hva mangler i løsningen vår?
Hele Bitrix-koden er ikke delt inn i mikrofunksjoner/mikrotjenester (slik at registreringen er separat, nettbutikkmodulen er separat osv.). Vi lagrer hele kodebasen i hver container.
Vi lagrer heller ikke databasen i Kubernetes (jeg implementerte fortsatt løsninger med en database i Kubernetes for utviklingsmiljøer, men ikke for produksjon).
Det vil fortsatt være merkbart for nettstedadministratorer at nettstedet kjører på Kubernetes. "Systemsjekk"-funksjonen fungerer ikke riktig; for å redigere nettstedkoden fra administrasjonspanelet, må du først klikke på "Jeg vil redigere koden".
Problemene er identifisert, behovet for å implementere mikrotjenester er bestemt, målet er klart - å få et fungerende system for å kjøre applikasjoner på Bitrix i Kubernetes, og bevare både mulighetene til Bitrix og fordelene med Kubernetes. La oss starte implementeringen.
arkitektur
Det er mange "fungerende" pods med en webserver (arbeidere).
En under med cron-oppgaver (kun en kreves).
Én oppgradering for å redigere nettstedskoden fra administrasjonspanelet (også bare én er nødvendig).
Vi løser spørsmål:
- Hvor lagrer du økter?
- Hvor lagrer jeg cachen?
- Hvor skal man lagre statikk, ikke plassere gigabyte med statikk i en haug med beholdere?
- Hvordan vil databasen fungere?
Docker-bilde
Vi starter med å bygge et Docker-bilde.
Det ideelle alternativet er at vi har ett universelt bilde, på grunnlag av det får vi arbeider-pods, pods med Crontasks og oppgraderings-pods.
.
Den inkluderer nginx, apache/php-fpm (kan velges under build), msmtp for å sende e-post og cron.
Når du setter sammen bildet, kopieres hele kodebasen til nettstedet til /app-katalogen (med unntak av de delene som vi vil flytte til en separat delt lagring).
Mikrotjenester, tjenester
arbeider pods:
- Container med nginx + container apache/php-fpm + msmtp
- Det fungerte ikke å flytte msmtp inn i en egen mikrotjeneste, Bitrix begynner å bli indignert over at den ikke kan sende e-post direkte
- Hver beholder har en komplett kodebase.
- Forbud mot å endre kode i containere.
cron under:
- beholder med apache, php, cron
- komplett kodebase inkludert
- forbud mot å endre kode i containere
oppgradere under:
- nginx-beholder + apache/php-fpm-beholder + msmtp
- Det er ikke forbud mot å endre kode i containere
øktlagring
Bitrix-bufferlagring
En annen viktig ting: vi lagrer passord for å koble til alt, fra databasen til e-post, i kubernetes hemmeligheter. Vi får en bonus: passord er kun synlige for de vi gir tilgang til hemmelighetene, og ikke for alle som har tilgang til prosjektets kodebase.
Lagring for statikk
Du kan bruke hva som helst: ceph, nfs (men vi anbefaler ikke nfs for produksjon), nettverkslagring fra skyleverandører, etc.
Lagringen må kobles i containere til /upload/-katalogen til nettstedet og andre kataloger med statisk innhold.
Database
For enkelhets skyld anbefaler vi å flytte databasen utenfor Kubernetes. Basen i Kubernetes er en egen kompleks oppgave; det vil gjøre ordningen til en størrelsesorden mer kompleks.
Øktlagring
Vi bruker memcached :)
Den håndterer øktlagring godt, er gruppert og støttes "native" som session.save_path i php. Et slikt system har blitt testet mange ganger i den klassiske monolittiske arkitekturen, da vi bygget klynger med et stort antall webservere. For utplassering bruker vi ror.
$ helm install stable/memcached --name sessionphp.ini - her inneholder bildet innstillinger for lagring av økter i memcached
Vi brukte miljøvariabler til å sende data om verter med memcached .
Dette lar deg bruke den samme koden i dev, stage, test, prod-miljøene (de memcachede vertsnavnene i dem vil være forskjellige, så vi må sende et unikt vertsnavn for økter til hvert miljø).
Bitrix-bufferlagring
Vi trenger feiltolerant lagring som alle poder kan skrive til og lese fra.
Vi bruker også memcached.
Denne løsningen anbefales av Bitrix selv.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - her i Bitrix er det spesifisert hvor cachen er lagret
Vi bruker også miljøvariabler.
Krontaski
Det er forskjellige tilnærminger til å kjøre Crontasks i Kubernetes.
- separat distribusjon med en pod for å kjøre Crontasks
- cronjob for å utføre crontasks (hvis dette er en nettapp - med wget , eller kubectl exec inne i en av arbeiderkapslene osv.)
- og så videre
Du kan krangle om den mest korrekte, men i dette tilfellet valgte vi alternativet "separat distribusjon med pods for Crontasks"
Slik gjøres det:
- legg til cron-oppgaver via ConfigMap eller via config/addcron-filen
- i ett tilfelle lanserer vi en beholder som er identisk med worker pod + tillater utførelse av kroneoppgaver i den
- den samme kodebasen brukes, takket være forening er montering av beholder enkel
Hva godt vi får:
- vi har arbeidende Crontasks i et miljø som er identisk med utviklernes miljø (docker)
- Crontasks trenger ikke å "skrives om" for Kubernetes, de fungerer i samme form og i samme kodebase som før
- cron-oppgaver kan legges til av alle teammedlemmer med commit-rettigheter til produksjonsgrenen, ikke bare administratorer
Southbridge K8SDeploy modul og koderedigering fra administrasjonspanelet
Vi snakket om oppgradering under?
Hvordan dirigere trafikk dit?
Hurra, vi skrev en modul for dette i PHP :) Dette er en liten klassisk modul for Bitrix. Den er ennå ikke offentlig tilgjengelig, men vi planlegger å åpne den.
Modulen er installert som en vanlig modul i Bitrix:
Og det ser slik ut:
Den lar deg sette en informasjonskapsel som identifiserer nettstedadministratoren og lar Kubernetes sende trafikk til oppgraderingsboksen.
Når endringene er fullført, må du klikke git push, kodeendringene sendes til git, så vil systemet bygge et bilde med en ny versjon av koden og "rulle ut" den over klyngen, og erstatte de gamle podene .
Ja, det er litt av en krykke, men samtidig opprettholder vi mikrotjenestearkitekturen og tar ikke fra Bitrix-brukere deres favorittmulighet til å korrigere koden fra adminpanelet. Til slutt er dette et alternativ; du kan løse problemet med å redigere koden på en annen måte.
Hjelmdiagram
For å bygge applikasjoner på Kubernetes bruker vi vanligvis Helm-pakkebehandlingen.
For vår Bitrix-løsning i Kubernetes skrev Sergey Bondarev, vår ledende systemadministrator, et spesielt Helm-diagram.
Den bygger arbeidere, ugrade, cron pods, konfigurerer ingresser, tjenester, overfører variabler fra Kubernetes hemmeligheter til pods.
Vi lagrer koden i Gitlab, og vi kjører også Helm-bygget fra Gitlab.
Kort sagt, det ser slik ut
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm lar deg også gjøre en "sømløs" tilbakerulling hvis noe plutselig går galt under distribusjonen. Det er fint når du ikke er i panikk "fiks koden via ftp fordi proden falt," men Kubernetes gjør det automatisk, og uten nedetid.
Utplassere
Ja, vi er fans av Gitlab & Gitlab CI, vi bruker det :)
Når Gitlab forplikter seg til prosjektdepotet, lanserer Gitlab en pipeline som distribuerer en ny versjon av miljøet.
stadier:
- bygge (bygge et nytt Docker-bilde)
- test (testing)
- rydde opp (fjerne testmiljøet)
- push (vi sender det til Docker-registeret)
- distribuere (vi distribuerer applikasjonen til Kubernetes via Helm).
Hurra, det er klart, la oss implementere det!
Vel, eller still spørsmål hvis det er noen.
Så hva gjorde vi
Fra et teknisk synspunkt:
- dockerized Bitrix;
- "kutt" Bitrix i beholdere, som hver utfører et minimum av funksjoner;
- oppnådd statsløs tilstand av containere;
- løste problemet med å oppdatere Bitrix i Kubernetes;
- alle Bitrix-funksjoner fortsatte å fungere (nesten alle);
- Vi jobbet med distribusjon til Kubernetes og tilbakerulling mellom versjoner.
Fra et forretningsmessig synspunkt:
- feiltoleranse;
- Kubernetes-verktøy (enkel integrasjon med Gitlab CI, sømløs distribusjon, etc);
- hemmelige passord (bare synlig for de som får direkte tilgang til passordene);
- Det er praktisk å lage flere miljøer (for utvikling, tester osv.) innenfor en enkelt infrastruktur.
Kilde: www.habr.com