Sysadminka-systemadministratormøder finder sted i Chelyabinsk, og ved det sidste gav jeg en rapport om vores løsning til at køre applikationer på 1C-Bitrix i Kubernetes.
Bitrix, Kubernetes, Ceph - en god blanding?
Jeg vil fortælle dig, hvordan vi sammensætter en fungerende løsning ud fra alt dette.
Lad os gå!
Mødet fandt sted den 18. april i Chelyabinsk. Du kan læse om vores møder på og se på .
Har du lyst til at komme til os med en beretning eller som lytter - velkommen, så skriv til [e-mail beskyttet] og på Telegram t.me/vadimisakanov.
Min rapport
Løsning "Bitrix i Kubernetes, version Southbridge 1.0"
Jeg vil tale om vores løsning i formatet "for dummies i Kubernetes", som det blev gjort ved mødet. Men jeg går ud fra, at du kender ordene Bitrix, Docker, Kubernetes, Ceph i det mindste på niveau med artikler på Wikipedia.
Hvad er færdigt ved Bitrix i Kubernetes?
Der er meget lidt information på hele internettet om driften af Bitrix-applikationer i Kubernetes.
Jeg fandt kun disse materialer:
Rapport af Alexander Serbul, 1C-Bitrix og Anton Tuzlukov fra Qsoft:
Jeg anbefaler at lytte til den.
Udvikling af din egen løsning fra brugeren .
Fandt mere .
Aaand... faktisk, det er alt.
Jeg advarer dig, vi har ikke kontrolleret kvaliteten af løsningerne i linksene ovenfor :)
Forresten, da jeg forberedte vores løsning, talte jeg med Alexander Serbul, så var hans rapport endnu ikke dukket op, så i mine dias er der et punkt "Bitrix bruger ikke Kubernetes."
Men der er allerede en masse færdige Docker-billeder til at køre Bitrix i Docker:
Er dette nok til at skabe en komplet løsning til Bitrix i Kubernetes?
Ingen. Der er en lang række problemer, der skal løses.
Hvad er problemerne med Bitrix i Kubernetes?
For det første er færdige billeder fra Dockerhub ikke egnede til Kubernetes
Hvis vi vil bygge en mikroservicearkitektur (og det gør vi normalt i Kubernetes), skal vi adskille vores Kubernetes-applikation i containere og få hver container til at udføre en lille funktion (og gøre det godt). Hvorfor kun én? Kort sagt, jo enklere jo mere pålideligt.
For at være mere specifik, se denne artikel og video, venligst:
Docker-billeder i Dockerhub er hovedsageligt bygget efter alt-i-én-princippet, så vi skulle stadig lave vores egen cykel og endda lave billeder fra bunden.
For det andet - webstedskoden redigeres fra administratorpanelet
Vi oprettede en ny sektion på webstedet - koden blev opdateret (en mappe med navnet på den nye sektion blev tilføjet).
Hvis du ændrede egenskaberne for en komponent fra administrationspanelet, blev koden ændret.
Kubernetes "som standard" kan ikke arbejde med dette; containere skal være statsløse.
Årsag: Hver container (pod) i klyngen behandler kun en del af trafikken. Hvis du kun ændrer koden i én container (pod), så vil koden være forskellig i forskellige pods, siden vil fungere forskelligt, og forskellige versioner af siden vil blive vist til forskellige brugere. Sådan kan man ikke leve.
For det tredje - du skal løse problemet med implementering
Hvis vi har en monolit og en "klassisk" server, er alt ganske enkelt: vi implementerer en ny kodebase, migrerer databasen, skifter trafik til den nye version af koden. Skiftet sker øjeblikkeligt.
Hvis vi har et websted i Kubernetes, skåret i mikrotjenester, er der mange containere med kode - åh. Du skal indsamle containere med en ny version af koden, rulle dem ud i stedet for de gamle, migrere databasen korrekt og ideelt set gøre dette ubemærket af besøgende. Heldigvis hjælper Kubernetes os med dette og understøtter en hel masse forskellige typer implementeringer.
For det fjerde - du skal løse problemet med lagring af statik
Hvis dit websted "kun" er på 10 gigabyte, og du implementerer det helt i containere, vil du ende med 10 gigabyte containere, som tager evigheder at implementere.
Du skal opbevare de "tyngste" dele af webstedet uden for containere, og spørgsmålet opstår om, hvordan du gør dette korrekt
Hvad mangler der i vores løsning?
Hele Bitrix-koden er ikke opdelt i mikrofunktioner/mikrotjenester (så tilmelding er adskilt, netbutiksmodulet er separat osv.). Vi opbevarer hele kodebasen i hver container.
Vi gemmer heller ikke databasen i Kubernetes (jeg implementerede stadig løsninger med en database i Kubernetes til udviklingsmiljøer, men ikke til produktion).
Det vil stadig være bemærkelsesværdigt for webstedsadministratorer, at webstedet kører på Kubernetes. "Systemcheck"-funktionen fungerer ikke korrekt; for at redigere webstedskoden fra adminpanelet skal du først klikke på knappen "Jeg vil redigere koden".
Problemerne er blevet identificeret, behovet for at implementere mikrotjenester er blevet fastlagt, målet er klart - at få et fungerende system til at køre applikationer på Bitrix i Kubernetes, der bevarer både Bitrix's muligheder og fordelene ved Kubernetes. Lad os begynde implementeringen.
arkitektur
Der er mange "fungerende" pods med en webserver (arbejdere).
En under med cron-opgaver (kun én er påkrævet).
Én opgradering til redigering af webstedskoden fra adminpanelet (også kun én er påkrævet).
Vi løser spørgsmål:
- Hvor skal sessioner opbevares?
- Hvor skal cachen opbevares?
- Hvor skal man gemme statik, ikke at placere gigabyte statik i en masse beholdere?
- Hvordan vil databasen fungere?
Docker billede
Vi starter med at bygge et Docker-billede.
Den ideelle mulighed er, at vi har et universelt billede, på grundlag af det får vi worker pods, pods med Crontasks og opgraderer pods.
.
Det inkluderer nginx, apache/php-fpm (kan vælges under build), msmtp til afsendelse af mail og cron.
Når billedet samles, kopieres hele kodebasen på webstedet til mappen /app (med undtagelse af de dele, som vi flytter til et separat delt lager).
Mikrotjenester, tjenester
arbejderkapsler:
- Container med nginx + container apache/php-fpm + msmtp
- Det lykkedes ikke at flytte msmtp ind i en separat mikrotjeneste, Bitrix begynder at blive forarget over, at den ikke kan sende mail direkte
- Hver container har en komplet kodebase.
- Forbud mod ændring af kode i containere.
cron under:
- beholder med apache, php, cron
- komplet kodebase inkluderet
- forbud mod ændring af kode i containere
opgrader under:
- nginx container + apache/php-fpm container + msmtp
- Der er intet forbud mod at ændre kode i containere
session opbevaring
Bitrix cache lagring
En anden vigtig ting: vi gemmer adgangskoder til at oprette forbindelse til alt, fra databasen til mail, i kubernetes hemmeligheder. Vi får en bonus: adgangskoder er kun synlige for dem, som vi giver adgang til hemmelighederne, og ikke for alle, der har adgang til projektets kodebase.
Opbevaring til statik
Du kan bruge hvad som helst: ceph, nfs (men vi anbefaler ikke nfs til produktion), netværkslagring fra cloud-udbydere osv.
Lageret skal være forbundet i containere til /upload/-biblioteket på webstedet og andre mapper med statisk indhold.
database
For nemheds skyld anbefaler vi at flytte databasen uden for Kubernetes. Basen i Kubernetes er en separat kompleks opgave; det vil gøre ordningen til en størrelsesorden mere kompleks.
Sessionsopbevaring
Vi bruger memcached :)
Den håndterer sessionslagring godt, er klynget og understøttes "natively" som session.save_path i php. Sådan et system er blevet testet mange gange i den klassiske monolitiske arkitektur, hvor vi byggede klynger med et stort antal webservere. Til indsættelse bruger vi roret.
$ helm install stable/memcached --name sessionphp.ini - her indeholder billedet indstillinger for lagring af sessioner i memcached
Vi brugte miljøvariabler til at videregive data om værter med memcached .
Dette giver dig mulighed for at bruge den samme kode i dev-, stage-, test-, prod-miljøerne (de memcachede værtsnavne i dem vil være forskellige, så vi skal videregive et unikt værtsnavn for sessioner til hvert miljø).
Bitrix cache lagring
Vi har brug for fejltolerant lager, som alle pods kan skrive til og læse fra.
Vi bruger også memcached.
Denne løsning anbefales af Bitrix selv.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - her i Bitrix er det angivet hvor cachen er gemt
Vi bruger også miljøvariabler.
Krontaski
Der er forskellige tilgange til at køre Crontasks i Kubernetes.
- separat udrulning med en pod til at køre Crontasks
- cronjob til at udføre crontasks (hvis dette er en webapp - med wget , eller kubectl exec inde i en af worker pods osv.)
- etc.
Du kan skændes om den mest korrekte, men i dette tilfælde valgte vi muligheden "separat udrulning med pods til Crontasks"
Sådan gøres det:
- tilføje cron-opgaver via ConfigMap eller via config/addcron-filen
- i et tilfælde starter vi en container, der er identisk med worker pod + tillader udførelse af kroneopgaver i den
- den samme kodebase bruges, takket være forening er containersamlingen enkel
Hvad godt vi får:
- vi har arbejdende Crontasks i et miljø, der er identisk med udviklernes miljø (docker)
- Crontasks behøver ikke at blive "omskrevet" til Kubernetes, de fungerer i samme form og i samme kodebase som før
- cron-opgaver kan tilføjes af alle teammedlemmer med commit-rettigheder til produktionsgrenen, ikke kun administratorer
Southbridge K8SDeploy modul og koderedigering fra administrationspanelet
Vi talte om opgradering under?
Hvordan dirigerer man trafikken dertil?
Hurra, vi skrev et modul til dette i PHP :) Dette er et lille klassisk modul til Bitrix. Det er endnu ikke offentligt tilgængeligt, men vi planlægger at åbne det.
Modulet er installeret som et almindeligt modul i Bitrix:
Og det ser sådan ud:
Det giver dig mulighed for at sætte en cookie, der identificerer webstedsadministratoren, og tillader Kubernetes at sende trafik til opgraderingspoden.
Når ændringerne er gennemført, skal du klikke på git push, kodeændringerne sendes til git, hvorefter systemet bygger et billede med en ny version af koden og "ruller" det ud på tværs af klyngen og erstatter de gamle pods .
Ja, det er lidt af en krykke, men samtidig bevarer vi mikroservicearkitekturen og tager ikke Bitrix-brugere deres foretrukne mulighed for at rette koden fra adminpanelet fra. I sidste ende er dette en mulighed; du kan løse problemet med at redigere koden på en anden måde.
Hjelm diagram
For at bygge applikationer på Kubernetes bruger vi typisk Helm-pakkehåndteringen.
Til vores Bitrix-løsning i Kubernetes skrev Sergey Bondarev, vores førende systemadministrator, et særligt Helm-diagram.
Det bygger arbejdere, ugrade, cron pods, konfigurerer indgange, tjenester, overfører variabler fra Kubernetes-hemmeligheder til pods.
Vi gemmer koden i Gitlab, og vi kører også Helm build fra Gitlab.
Kort sagt ser det sådan ud
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm giver dig også mulighed for at foretage en "sømløs" rollback, hvis noget pludselig går galt under implementeringen. Det er rart, når du ikke er i panik "fix koden via ftp, fordi proppen faldt", men Kubernetes gør det automatisk og uden nedetid.
Indsætte
Ja, vi er fans af Gitlab & Gitlab CI, vi bruger det :)
Når Gitlab forpligter sig til projektlageret, lancerer Gitlab en pipeline, der implementerer en ny version af miljøet.
faser:
- build (opbygning af et nyt Docker-billede)
- test (test)
- rydde op (fjerne testmiljøet)
- push (vi sender det til Docker-registret)
- implementere (vi implementerer applikationen til Kubernetes via Helm).
Hurra, den er klar, lad os implementere den!
Nå, eller stil spørgsmål, hvis der er nogen.
Så hvad gjorde vi
Fra et teknisk synspunkt:
- dockeriseret Bitrix;
- "skære" Bitrix i beholdere, som hver udfører et minimum af funktioner;
- opnået statsløs tilstand af containere;
- løste problemet med at opdatere Bitrix i Kubernetes;
- alle Bitrix-funktioner fortsatte med at fungere (næsten alle);
- Vi arbejdede på udrulning til Kubernetes og rollback mellem versioner.
Fra et forretningsmæssigt synspunkt:
- fejltolerance;
- Kubernetes-værktøjer (let integration med Gitlab CI, problemfri implementering osv.);
- hemmelige adgangskoder (kun synlige for dem, der får direkte adgang til adgangskoden);
- Det er praktisk at skabe yderligere miljøer (til udvikling, test osv.) inden for en enkelt infrastruktur.
Kilde: www.habr.com