Southbridge i Tsjeljabinsk og Bitrix i Kubernetes

I Tsjeljabinsk holdes det møter for systemadministratoren Sysadminka, og på det siste møtet presenterte jeg vår løsning for å kjøre applikasjoner på 1С-Bitrix i Kubernetes.

Bitrix, Kubernetes, Ceph – en utmerket kombinasjon?

Jeg vil fortelle hvordan vi bygde en fungerende løsning ut av alt dette.

La oss gå!

Møtet fant sted 18. april i Tsjeljabinsk. Du kan lese om våre møter i Timepad og se dem på YouTube.

Hvis du ønsker å komme til oss med en presentasjon eller som lytter – velkommen, skriv til vadim.isakanov@gmail.com og på Telegram t.me/vadimisakanov.

Min presentasjon

Lysbilder

Løsningen «Bitrix i Kubernetes, versjon Southbridge 1.0»

Jeg vil fortelle om vår løsning i formatet «for nybegynnere i Kubernetes», slik det ble gjort på møtet. Men jeg antar at ordene Bitrix, Docker, Kubernetes, Ceph er kjent for deg, om ikke annet på nivået av artikler på Wikipedia.

Hva finnes egentlig av klare løsninger for Bitrix i Kubernetes?

Det finnes veldig lite informasjon på internett om kjøring av applikasjoner på Bitrix i Kubernetes.
Jeg fant bare disse materialene:

Presentasjonen til Alexander Serbul, 1С-Bitrix, og Anton Tuzlukov fra Qsoft:

Jeg anbefaler å høre på den.

Utvikling av en egen løsning fra brukeren serkyron på Habré.
Fant også slike løsninger.

Og… faktisk, det er alt.

Jeg advarer, kvaliteten på løsningene i lenkene ovenfor har vi ikke sjekket 🙂
Forresten, under forberedelsen av vår løsning snakket jeg med Alexander Serbul, da hans presentasjon ennå ikke var tilgjengelig, så i lysbildene mine er det et punkt som sier «Bitrix bruker ikke Kubernetes».

Men det finnes allerede mange klare Docker-bilder for å jobbe med Bitrix i Docker: https://hub.docker.com/search?q=bitrix&type=image

Er dette nok for å lage en fullverdig løsning for Bitrix i Kubernetes?
Nei. Det er mange problemer som må løses.

Hva er problemene med Bitrix i Kubernetes?

Det første – klare bilder fra Dockerhub er ikke egnet for Kubernetes

Hvis vi ønsker å bygge en mikrotjenestearkitektur (som vi vanligvis ønsker i Kubernetes), må applikasjonen i Kubernetes deles inn i containere og sørge for at hver container utfører en liten funksjon (og gjør det godt). Hvorfor bare en? Kort sagt – jo enklere, jo mer pålitelig.
For en lengre forklaring – vennligst sjekk denne artikkelen og videoen: https://habr.com/ru/company/southbridge/blog/426637/

Docker-bildene i Dockerhub er hovedsakelig bygget etter prinsippet «alt i ett», derfor måtte vi faktisk lage vår egen løsning og til og med bygge bildene fra bunnen av.

Det andre – koden til nettsiden blir endret fra administrasjonspanelet

Vi har opprettet en ny seksjon på nettstedet — koden har blitt oppdatert (en katalog med navnet på den nye seksjonen har blitt lagt til).

Vi har endret egenskapene til komponenten fra administrasjonspanelet — koden har endret seg.

Kubernetes kan ikke jobbe med dette «som standard», containere må være uforanderlige (Stateless).

Årsaken: hver container (pod) i klyngen håndterer bare en del av trafikken. Hvis koden bare endres i én container (pod), vil koden være forskjellig i forskjellige podder, nettstedet vil fungere forskjellig, og forskjellige brukere vil se forskjellige versjoner av nettstedet. Dette er ikke bærekraftig.

Det tredje — vi må løse problemet med deploy.

Hvis vi har et monolithisk system og én «klassisk» server, er alt ganske enkelt: vi distribuerer den nye kodebasen, gjennomfører databasemigrering, og omdirigerer trafikken til den nye koden. Omdirigeringen skjer umiddelbart.
Hvis vi har et nettsted i Kubernetes, delt opp i mikrotjenester, og det er mange containere med kode — åh. Vi må bygge containere med den nye versjonen av koden, rulle dem ut i stedet for de gamle, utføre databasemigreringen riktig, og ideelt sett gjøre dette uten at besøkende merker det. Heldigvis hjelper Kubernetes oss med dette, og støtter en rekke forskjellige typer deploy.

Det fjerde — vi må løse lagringsproblemene for statisk innhold.

Hvis nettstedet ditt bare veier «10 gigabyte», og du distribuerer det helt i containere, får du containere som veier 10 gigabyte, som vil bli deployet i en evighet.
Vi må lagre de «tyngste» delene av nettstedet utenfor containerne, og spørsmålet oppstår om hvordan vi skal gjøre dette på riktig måte.

Hva som ikke er inkludert i vår løsning.

Hele Bitrix-koden er ikke delt opp i mikrofunksjoner/mikrotjenester (for eksempel er registrering separat, modulen for nettbutikken separat, osv.). Vi lagrer hele kodebasen i hver container i sin helhet.

Vi lagrer heller ikke databasen i Kubernetes (jeg har faktisk implementert løsninger med databasen i Kubernetes for utviklermiljøer, men ikke for produksjon).

Administratorene på nettstedet vil likevel merke at nettstedet kjører på Kubernetes. Funksjonen «systemkontroll» fungerer ikke korrekt, og for å redigere nettstedets kode fra administrasjonspanelet må du først trykke på knappen «jeg vil redigere koden».

Vi har identifisert problemene, vi har bestemt nødvendigheten av mikrotjenester, målet er klart - å få et fungerende system for applikasjoner på Bitrix i Kubernetes, samtidig som vi opprettholder mulighetene fra Bitrix og fordelene ved Kubernetes. Vi begynner implementeringen.

Arkitektur

Mange "arbeids" pods med webserver (arbeidere).
Én pod med cron-jobber (kun én er obligatorisk).
Én upgrade pod for redigering av nettstedkode fra administrasjonspanelet (kun én er også obligatorisk).

Vi løser spørsmålene:

• Hvor skal vi lagre sesjoner?
• Hvor skal vi lagre cache?
• Hvor skal vi lagre statiske filer, vi kan ikke plassere gigabyte med statiske filer i en haug med containere?
• Hvordan vil databasen fungere?

Docker-bilde

Vi begynner med å bygge Docker-bildet.

Den ideelle løsningen er at vi har ett universelt bilde, på grunnlag av dette får vi både arbeids-pods, pods med cron-jobber, og upgrade pods.

Vi har laget nettopp et slikt bilde..

Det inkluderer nginx, apache/php-fpm (kan velges under byggingen), msmtp for sending av e-post, og cron.

Under byggingen kopieres hele kodebasen til /app-mappen (unntatt de delene vi vil flytte til en egen delt lagring).

Mikrotjenester, tjenester

arbeider-pods:

• Container med nginx + container apache/php-fpm + msmtp
• Det ble ikke mulig å flytte msmtp til en egen mikrotjeneste, Bitrix begynner å klage over at den ikke kan sende e-post direkte.
• Hver container har hele kodebasen.
• Forbud mot å endre kode i containerne.

cron pod:

• container med apache, php, cron
• med full kodebase inkludert
• forbud mot å endre kode i containerne

upgrade pod:

• container med nginx + container apache/php-fpm + msmtp
• det er ingen forbud mot å endre kode i containerne

lagringsløsning for sesjoner

cache-lagring for Bitrix

Det er også viktig: passord for tilkobling til alt, fra databasen til e-post, lagrer vi i Kubernetes secrets. Vi får en bonus, passordene kan kun sees av de vi gir tilgang til hemmelighetene, og ikke av alle som har tilgang til kodebasen.

Lagring for statiske filer

Vi kan bruke hva som helst: ceph, nfs (men vi anbefaler ikke nfs for produksjon), nettverkslagring fra "skyleverandører", osv.

Lagring må kobles til containerne i /upload/-mappen på nettstedet og andre mapper med statiske filer.

Database

For enkelhetens skyld anbefaler vi å flytte databasen utenfor Kubernetes. En database i Kubernetes er en egen kompleks oppgave, og den vil gjøre systemet betydelig mer komplisert.

Lagring for sesjoner

Vi bruker memcached 🙂

Det gjør en god jobb med sesjonslagring, kanClusters, og støttes «nativt» som session.save_path i php. Et slikt system er allerede godt utprøvd i klassisk monolitisk arkitektur, da vi bygde klynger med et stort antall webservere. For distribusjon bruker vi helm.

$ helm install stable/memcached --name session

php.ini — her er konfigurasjonene for sesjonslagring i memcached angitt i bildet

Vi har brukt miljøvariabler for å overføre data om vertene med memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Dette gjør at vi kan bruke den samme koden i dev-, stage-, test- og prod-miljøene (vertens navn for memcached vil variere, så i hvert miljø må vi overføre unike vertsnavn for sesjoner).
Cache-lager for Bitrix

Vi trenger et distribuert lager som alle podene kan skrive til og lese fra.

Vi bruker også memcached.
Denne løsningen anbefales av Bitrix selv.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php — her angis hvor vårt cachelagring er i Bitrix

Vi bruker også miljøvariabler.

Kronoppgaver

Det er ulike tilnærminger til å kjøre kronoppgaver i Kubernetes.

• separat distribusjon med pod for å kjøre kronoppgaver
• cronjob for å gjennomføre kronoppgaver (hvis dette er en webapp — med wget https://$host$cronjobname, eller kubectl exec inne i en av worker-podene, osv.)
• etc.

Man kan diskutere hva som er mest korrekt, men i dette tilfellet valgte vi alternativet «separat distribusjon med podder for kronoppgaver»

Slik er det gjort:

• kronoppgaver legges til gjennom ConfigMap eller gjennom filen config/addcron
• vi kjører en enkel container, identisk med worker-poden + tillater kjøring av kronoppgaver i den
• den samme kodebasen brukes, takket være standardiseringen, er containeropprettelsen enkel

Hva får vi ut av dette:

• vi har fungerende kronoppgaver i et miljø som ligner utviklermiljøet (docker)
• kronoppgaver trenger ikke å «skribles» for Kubernetes, de fungerer i sin originale form og med den samme kodebasen som før
• kronoppgaver kan bli lagt til av alle teammedlemmer med commit-rettigheter i produksjonsgrenen, ikke bare administratorer

Modul Southbridge K8SDeploy og redigering av kode fra admin-panelet

Vi snakket jo om oppgradering av pod, ikke sant?
Hvordan dirigerer vi trafikken dit?
Hurra, vi har skrevet en modul for dette i php 🙂 Det er en liten klassisk modul for Bitrix. Den er ikke tilgjengelig offentlig ennå, men vi planlegger å gjøre den tilgjengelig.
Modulen installeres som en vanlig modul i Bitrix:

Og ser slik ut:

Det lar deg angi en cookie som identifiserer nettstedets administrator, og lar Kubernetes sende trafikk til oppgraderingspodden.

Når endringene er fullført, må du trykke på git push, endringene i koden vil bli sendt til git, deretter vil systemet bygge et bilde med den nye versjonen av koden og "rulle den ut" over klyngen, og erstatte gamle podder.

Ja, litt klønete, men vi bevarer mikroservicearkitekturen og tar ikke bort Bitrix-brukernes elskede mulighet til å endre koden fra adminpanelet. Til syvende og sist er dette et valg, og man kan løse oppgave om å redigere koden på en annen måte.

Helm-diagram

For å bygge applikasjoner i Kubernetes bruker vi vanligvis pakkehåndtereren Helm.
For vår Bitrix-løsning i Kubernetes har Sergej Bondarev, vår ledende systemadministrator, skrevet et spesialdesignert Helm-diagram.

Det bygger worker-, upgrade-, cron-podder, konfigurerer ingress-er, tjenester, og overfører variabler fra Kubernetes-hemmeligheter til podder.

Vi lagrer koden i Gitlab, og vi starter også Helm-byggeren fra Gitlab.

I korte trekk ser det slik ut

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

Helm lar deg også gjøre en "sømløs" tilbakestilling hvis noe går galt under distribusjonen. Det er fint at du ikke er i panikk og "fikser koden via ftp fordi produksjonen har falt", mens Kubernetes gjør dette automatisk, uten nedetid.

UTPLASSERING

Ja, vi er fans av Gitlab & Gitlab CI, vi bruker det 🙂
Ved committing til Gitlab i prosjektets repository, starter Gitlab en pipeline som distribuerer den nye versjonen av miljøet.

Faser:

• build (bygger et nytt Docker-bilde)
• test (testar)
• clean up (fjerner testmiljøet)
• push (sender det til Docker registry)
• deploy (distribuerer applikasjonen i Kubernetes via Helm).

Hurra, ferdig, implementerer!
Eller stiller spørsmål hvis det finnes.

Så, hva har vi gjort

Fra et teknisk perspektiv:

• dockeriserte vi Bitrix;
• "delte" vi Bitrix i containere, hver av dem utfører minimum funksjoner;
• oppnådde stateless tilstand for containerne;
• løste vi problemet med oppdatering av Bitrix i Kubernetes;
• alle funksjoner i Bitrix fortsatte å fungere (nesten alle);
• vi har gjennomført distribusjon i Kubernetes og tilbakekobling mellom versjoner.

Fra et forretningsperspektiv:

• feiltoleranse;
• Kubernetes-verktøy (enkel integrasjon med Gitlab CI, sømløs distribusjon, etc);
• passord i hemmeligheter (synlig kun for de som har fått direkte tilgang til passordene);
• Det er praktisk å lage ekstra miljøer (for utvikling, testing osv.) innenfor én infrastruktur.

Kilde: habr.com