Southbridge i Tjelyabinsk och Bitrix i Kubernetes

I Chelyabinsk, meetups for system administrators Sysadminka are taking place, and at the last one, I presented on our solution for running applications on 1C-Bitrix in Kubernetes.

Bitrix, Kubernetes, Ceph — a great mix?

I'll explain how we put all of this together into a working solution.

Låt oss köra!

The meetup took place on April 18 in Chelyabinsk. You can read about our meetups in Timepad and watch on YouTube.

If you want to join us as a speaker or as an attendee, feel free to write to vadim.isakanov@gmail.com and on Telegram t.me/vadimisakanov.

My presentation

Bildspel

Solution "Bitrix in Kubernetes, version Southbridge 1.0"

I will discuss our solution in a "for beginners in Kubernetes" format, as it was done at the meetup. However, I assume that you are at least familiar with the terms Bitrix, Docker, Kubernetes, and Ceph at the Wikipedia article level.

What is actually available regarding Bitrix in Kubernetes?

There is very little information on the internet about running applications on Bitrix in Kubernetes.
I found only the following materials:

Presentation by Alexander Serbul, 1C-Bitrix, and Anton Tuzlukov from Qsoft:

I recommend listening to it.

Development of a solution from a user serkyron I detta område har också AI-system nått fram. Smarta algoritmer förutspår serverfel genom att analysera deras "beteende". Till exempel, företaget Litbit.
I also found such a solution.

And... that's basically it.

I warn you, we haven't checked the quality of the solutions linked above 🙂
By the way, while preparing our solution, I communicated with Alexander Serbul, and at that time his presentation wasn't available yet, so there is a point in my slides stating that "Bitrix does not use Kubernetes."

But there are already many ready-made Docker images for running Bitrix in Docker: https://hub.docker.com/search?q=bitrix&type=image

Is this enough to create a full-fledged solution for Bitrix in Kubernetes?
No. There are a lot of problems that need to be solved.

What are the problems with Bitrix in Kubernetes?

The first is that the ready-made images from Dockerhub are not suitable for Kubernetes.

If we want to build a microservices architecture (which we usually want to do in Kubernetes), you need to break the application down into containers and ensure that each container performs one small function (and does it well). Why only one? In short — the simpler, the more reliable.
If you want a longer explanation — please take a look at this article and video: https://habr.com/ru/company/southbridge/blog/426637/

Docker images on Dockerhub are mainly built on the principle of "everything in one", so we had to reinvent the wheel and even create images from scratch.

The second is that the website code is modified from the admin panel.

Vi har skapat en ny sektion på webbplatsen - koden har uppdaterats (en katalog med namnet på den nya sektionen har lagts till).

Egenskaperna för komponenten har ändrats från administrationspanelen - koden har förändrats.

Kubernetes kan inte arbeta med det här som standard, containrar måste vara oföränderliga (Stateless).

Orsaken: varje container (pod) i klustret hanterar endast en del av trafiken. Om koden ändras endast i en container (pod), kommer koden att vara olika i olika pods, webbplatsen kommer att fungera olika, olika användare får se olika versioner av webbplatsen. Så kan vi inte ha det.

Det tredje - vi måste ta itu med frågan om utplacering.

Om vi har en monolit och en "klassisk" server är allt ganska enkelt: vi rullar ut en ny kodbas, genomför databasmigrering, och dirigerar trafiken till den nya versionen av koden. Omkopplingen sker omedelbart.
Om vi har en webbplats i Kubernetes, uppdelad i mikrotjänster, och det finns många containrar med kod - oj. Vi måste bygga containrar med den nya versionen av koden, rulla ut dem istället för de gamla, utföra databasmigreringen korrekt, och helst göra detta utan att besökarna märker det. Lyckligtvis hjälper Kubernetes oss med detta, med en mängd olika typer av utplacering.

Det fjärde - vi måste ta itu med frågan om lagring av statiska filer.

Om din webbplats "bara" väger 10 gigabyte och du rullar ut den helt i containrar, får du containrar som väger 10 gigabyte, som kommer att ta en evighet att distribuera.
De tyngsta delarna av webbplatsen måste lagras utanför containrarna, och frågan är hur man gör detta på rätt sätt.

Vad som saknas i vår lösning.

Hela koden för Bitrix är inte uppdelad på mikro-funktioner/mikrotjänster (så att registrering är separat, modulen för e-handeln separat, och så vidare). Vi lagrar hela kodbasen i varje container i sin helhet.

Vi lagrar även inte databasen i Kubernetes (jag har använt lösningar med databasen i Kubernetes för utvecklarmiljöer, men inte för produktion).

Webbplatsens administratörer kommer att märka att webbplatsen arbetar i Kubernetes. Funktionen "systemkontroll" fungerar inte korrekt, för att redigera koden på webbplatsen från administrationspanelen måste man först klicka på knappen "jag vill redigera koden".

Problemmerne er blevet løst, behovet for implementering af mikrotjenester er afklaret, målet er klart - at få et fungerende system til anvendelse af Bitrix i Kubernetes, mens vi bevarer både Bitrix-funktionalitet og Kubernetes-fordele. Vi starter implementeringen.

Arkitektur

Mange 'arbejdende' pods med webserver (arbejdere).
En pod med cron-opgaver (kun én kræves).
En upgrade pod til redigering af hjemmesidens kode fra administrationspanelet (også kun én kræves).

Vi løser spørgsmålene:

• Hvor skal sessioner gemmes?
• Hvor skal cache gemmes?
• Hvor skal statiske filer gemmes, skal vi virkelig placere gigabyte statiske filer i en bunke containere?
• Hvordan vil databasen fungere?

Docker-billede

Vi starter med at opbygge Docker-billedet.

Den ideelle løsning er, at vi har et universelt billede, på grundlag af dette får vi både arbejdende pods, pods med cron-opgaver og upgrade pods.

Vi har netop lavet et sådant billede.

Det inkluderer nginx, apache/php-fpm (kan vælges ved opbygning), msmtp til mailudsendelse og cron.

Under opbygningen kopieres hele kodebasen for hjemmesiden til mappen /app (undtagen de dele, vi vil flytte til et separat fælles lager).

Mikrotjenester, services

arbejdende pods:

• Container med nginx + container apache/php-fpm + msmtp
• Msmtp kunne ikke flyttes til en separat mikrotjeneste, Bitrix bliver utilfreds, fordi det ikke kan sende mails direkte.
• I hver container er der hele kodebasen.
• Der er forbud mod at ændre koden i containere.

cron pod:

• container med apache, php, cron
• sammen med hele kodebasen
• forbud mod at ændre koden i containere

upgrade pod:

• container med nginx + container apache/php-fpm + msmtp
• der er ikke forbud mod at ændre koden i containere

sessionlager

cachelager for Bitrix

Det er også vigtigt: adgangskoder til forbindelse til alt, fra databasen til mail, opbevares i Kubernetes secrets. Vi får en bonus, adgangskoderne kan kun ses af dem, vi giver adgang til secrets, og ikke alle, der har adgang til kodebasen.

Lager til statiske filer

Vi kan bruge hvad som helst: ceph, nfs (men vi anbefaler ikke nfs til produktion), netværkslager fra 'cloud'-udbydere osv.

Lageret skal tilsluttes i containere i /upload/ mappen på hjemmesiden og andre mapper med statiske filer.

Databas

For enkelhedens skyld anbefaler vi at flytte databasen uden for Kubernetes. At have databasen i Kubernetes er en kompleks opgave, der vil gøre strukturen væsentligt mere kompleks.

sessionlager

Vi bruger memcached 🙂

Det hanterar sessioner väl, är klusterbaserat och stöds "naturligt" som session.save_path i php. Sådana system har gång på gång använts i den klassiska monolitiska arkitekturen, när vi byggde kluster med ett stort antal webbservrar. För distribution använder vi helm.

$ helm install stable/memcached --name session

php.ini – här ställs inställningar för lagring av sessioner i memcached in i bilden

Vi använde miljövariabler för att överföra data om värdar med memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Detta möjliggör att använda samma kod i miljöer som dev, stage, test, prod (namnen på värdarna för memcached kommer att skilja sig åt, så vi behöver överföra unika värdnamn för sessioner till varje miljö).
Cache-lagring i Bitrix

Vi behöver en kaustikresistent lagring dit alla pods kan skriva och läsa.

Vi använder även memcached.
Denna lösning rekommenderas av Bitrix själva.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php – här anges var vi lagrar cachen i Bitrix

Vi använder också miljövariabler.

Cron-jobb

Det finns olika tillvägagångssätt för att köra cron-jobb i Kubernetes.

• separat deployment med en pod för att köra cron-jobb
• cronjob för att utföra cron-jobb (om det är webapp – med wget https://$host$cronjobname, eller kubectl exec in i en av worker-pods, osv.)
• med flera.

Man kan diskutera vad som är mest korrekt, men i det här fallet valde vi alternativet "separat deployment med pods för cron-jobb"

Hur det görs:

• funktionerna läggs till via ConfigMap eller genom filen config/addcron
• i en instans kör vi en container som är identisk med worker-poden + vi tillåter körning av cron-jobb i den
• den samma kodbas används, tack vare standardiseringen är det enkelt att bygga containern

Vad vi får bra:

• vi har fungerande cron-jobb i en miljö som är identisk med utvecklarnas miljö (docker)
• cron-jobb behöver inte "skrivas om" för Kubernetes, de fungerar i samma form och i samma kodbas som tidigare
• cro-jobb kan läggas till av alla teammedlemmar med commit-rättigheter till produktionsgrenen, inte bara administratörer

Modul Southbridge K8SDeploy och redigering av kod från adminpanelen

Vi talade ju om uppgradering av podden?
Och hur dirigerar vi trafiken dit?
Hurra, vi har skrivit en modul för detta i php 🙂 Det är en liten klassisk modul för Bitrix. Den finns ännu inte tillgänglig offentligt, men vi planerar att göra den tillgänglig.
Modulen installeras som en vanlig modul i Bitrix:

Och ser så här ut:

Det gör det möjligt att ställa in en cookie som identifierar webbplatsadministratören och låter Kubernetes dirigera trafik till uppgraderingspodden.

När ändringarna är klara måste du trycka på git push, ändringarna i koden skickas till git, och systemet kommer sedan att bygga en bild med den nya versionen av koden och "rulla" ut den i klustret, vilket ersätter de gamla poddarna.

Ja, lite krångligt, men vi bevarar samtidigt mikrotjänstarkitekturen och tar inte bort Bitrix-användarnas favoritfunktion att justera koden från adminpanelen. I slutändan är det ett alternativ, man kan lösa kodjusteringsuppgiften på ett annat sätt.

Helm-diagram

För att bygga appar i Kubernetes använder vi vanligtvis paketchefen Helm.
För vår Bitrix-lösning i Kubernetes har Sergey Bondarev, vår ledande systemadministratör, skrivit ett specialanpassat Helm-diagram.

Det utför byggandet av worker-, upgrade- och cron-poddar, konfigurerar ingressar, tjänster och överför variabler från Kubernetes-secrets till poddarna.

Vi lagrar koden i Gitlab och initierar även Helm-byggnaden från Gitlab.

Det ser ungefär ut så här

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

Helm möjliggör också "sömlös" nedgradering om något går fel vid distributionen. Det är trevligt när det inte är du som panikartat "fixar koden via ftp för att produktionen har kraschat", utan Kubernetes gör det automatiskt, dessutom utan driftstopp.

Utveckla

Ja, vi är fans av Gitlab & Gitlab CI, vi använder det 🙂
Vid commit i Gitlab i projektets repository startar Gitlab en pipeline som utför distributionen av den nya versionen av miljön.

Steg:

• build (bygger en ny Docker-bild)
• test (testar)
• clean up (tar bort testmiljön)
• push (skickar den till Docker registry)
• deploy (distribuerar applikationen i Kubernetes via Helm).

Hurra, klart, vi implementerar!
Eller ställer frågor om det finns några.

Så, vad har vi gjort

Ur ett tekniskt perspektiv:

• dockeriserade Bitrix;
• "skar upp" Bitrix i containrar, där varje utför minimalt med funktioner;
• uppnådde stateless tillstånd i containrarna;
• löste problemet med att uppdatera Bitrix i Kubernetes;
• alla funktioner i Bitrix fortsatte att fungera (nästan allt);
• testade distributionen i Kubernetes och nedgradering mellan versioner.

Ur ett affärsperspektiv:

• felfunktionstolerans;
• Kubernetes-verktyg (enkel integration med Gitlab CI, sömlös distribution, etc);
• lösenord i secrets (synliga endast för dem som direkt beviljas åtkomst till lösenorden);
• Det är enkelt att skapa ytterligare miljöer (för utveckling, tester m.m.) inom en och samma infrastruktur.

Källa: habr.com