I Charkov afholdes der meetups for systemadministratorer, og på det seneste lavede jeg et oplæg om vores løsning til at køre applikationer på 1C-Bitrix i Kubernetes.
Bitrix, Kubernetes, Ceph — en fremragende kombination?
Jeg vil fortælle, hvordan vi samlet viste en fungerende løsning ud af alt dette.
Lad os komme i gang!
Meetup'en fandt sted den 18. april i Charkov. Om vores meetups kan du læse i og se på .
Hvis du ønsker at komme til os med et oplæg eller som deltager - så er du velkommen, skriv til vadim.isakanov@gmail.com og på Telegram t.me/vadimisakanov.
Mit oplæg
Løsning "Bitrix i Kubernetes, version Southbridge 1.0"
Jeg vil tale om vores løsning i formatet "for nybegyndere i Kubernetes", hvordan det blev gjort på meetup'en. Men jeg antager, at du allerede kender til ordene Bitrix, Docker, Kubernetes, Ceph, i det mindste på niveau med artikler fra Wikipedia.
Hvad findes der overhovedet af materialer om Bitrix i Kubernetes?
Der er meget lidt information på internettet om at køre applikationer på Bitrix i Kubernetes.
Jeg fandt kun disse materialer:
Oplæg af Alexander Serbul, 1C-Bitrix, og Anton Tuzlukov fra Qsoft:
Jeg anbefaler at lytte til det.
Udvikling af en egen løsning fra brugerens side .
Jeg fandt også .
Og... ja, det var det.
Jeg advarer om, at kvaliteten af løsningerne i ovenstående links ikke er blevet kontrolleret 🙂
Forresten, mens jeg forberedte vores løsning, talte jeg med Alexander Serbul, hans oplæg var endnu ikke tilgængeligt, derfor er der et punkt i mine slides, "Bitrix bruger ikke Kubernetes".
Men der er mange færdige Docker-billeder til at køre Bitrix i Docker allerede:
Er dette tilstrækkeligt til at skabe en fuldgyldig løsning for Bitrix i Kubernetes?
Nej. Der er mange problemer, der skal løses.
Hvad er problemerne med Bitrix i Kubernetes?
Den første — færdige billeder fra Dockerhub er ikke egnet til Kubernetes.
Hvis vi ønsker at bygge en mikrotjenestearkitektur (og i Kubernetes vil vi typisk gerne det), skal applikationen i Kubernetes opdeles i containere og sikre, at hver container udfører én lille funktion (og gør det godt). Hvorfor kun én? Kort sagt — jo simplere, jo mere pålideligt.
For en længere forklaring - se venligst denne artikel og video:
Docker-billeder i Dockerhub er hovedsageligt bygget med princippet "alt i ét", så vi måtte alligevel lave vores egen cykel og til og med skabe billeder fra bunden.
Den anden — websitets kode ændres fra administrationspanelet.
Vi har oprettet en ny sektion på hjemmesiden – koden er blevet opdateret (der er tilføjet et bibliotek med navnet på den nye sektion).
Vi har ændret egenskaberne for komponenten fra adminpanelet – koden er ændret.
Kubernetes kan ikke arbejde med dette 'som standard'; containere skal være uforanderlige (Stateless).
Årsag: hver container (pod) i klyngen håndterer kun en del af trafikken. Hvis man ændrer koden kun i én container (pod), vil der være forskellige versioner af koden i forskellige pods, og hjemmesiden vil opføre sig forskelligt, hvilket betyder, at forskellige brugere vil se forskellige versioner af hjemmesiden. Det er ikke en holdbar løsning.
For det tredje – det er nødvendigt at løse spørgsmålet om deployment.
Hvis vi har et monolitisk system og én 'klassisk' server, så er det ret simpelt: vi deployer en ny kodebase, udfører database-migration, og skifter trafikken til den nye version af koden. Skiftet sker straks.
Hvis vores hjemmeside kører på Kubernetes, opdelt i mikrotjenester, og der er mange containere med kode – uh-oh. Vi skal samle containere med den nye version af koden, udskifte dem med de gamle, korrekt udføre database-migration, og ideelt set gøre det usynligt for besøgende. Heldigvis hjælper Kubernetes os her ved at understøtte en hel række forskellige typer deployment.
For det fjerde – det er nødvendigt at løse spørgsmålet om opbevaring af statiske filer.
Hvis din hjemmeside kun vejer ‘kun’ 10 gigabyte, og du deployer den helt i containere, får du containere, der vejer 10 gigabyte, som vil blive deployet i en evighed.
Det er nødvendigt at opbevare de 'tungeste' dele af hjemmesiden uden for containerne, og der opstår spørgsmålet om, hvordan man korrekt gør dette.
Hvad der ikke er i vores løsning.
Hele Bitrix-koden er ikke opdelt i mikro-funktioner/mikrotjenester (sådan at registrering er adskilt, internetbutiksmodulet er adskilt osv.). Vi opbevarer hele kodebasen i hver container.
Vi gemmer også ikke databasen i Kubernetes (jeg har dog implementeret løsninger med databasen i Kubernetes til udviklingsmiljøer, men ikke til produktion).
Webstedets administratorer vil alligevel bemærke, at webstedet kører i Kubernetes. 'Systemcheck'-funktionen fungerer ikke korrekt, og for at redigere koden på hjemmesiden fra adminpanelet skal man først trykke på knappen 'Jeg vil redigere koden'.
Vi har identificeret problemerne, vi er blevet enige om nødvendigheden af at implementere mikrotjenester, og målet er klart — at få et fungerende system til kørsel af applikationer på Bitrix i Kubernetes, samtidig med at vi bevarer både Bitrix's funktioner og Kubernetes's fordele. Vi starter implementeringen.
Arkitektur
Mange "arbejdende" pods med webserver (workere).
En pod med cron-jobs (af dem kun én er obligatorisk).
En upgrade pod til redigering af webstedskoden fra administrationspanelet (også obligatorisk kun én).
Vi løser spørgsmålene:
- Hvor opbevarer vi sessioner?
- Hvor opbevarer vi cache?
- Hvor opbevarer vi statiske filer, vi kan ikke lægge gigabytes af statisk indhold i en bunke containere?
- Hvordan vil databasen fungere?
Docker-billede
Vi starter med at bygge Docker-billedet.
Den ideelle løsning — vi har et universelt billede, baseret på det får vi både worker-pods, pods med cron-jobs og upgrade pods.
.
Det inkluderer nginx, apache/php-fpm (kan vælges ved bygning), msmtp til e-mail forsendelse, og cron.
Når billedet bygges, kopieres den fulde kodebase til direktoret /app (med undtagelse af de dele, vi vil flytte til en separat delt lager).
Mikrotjenester, tjenester
worker pods:
- Container med nginx + container apache/php-fpm + msmtp
- msmtp kunne ikke flyttes til en separat mikrotjeneste, Bitrix begynder at klage over, at det ikke kan sende e-mails direkte.
- Hver container har den fulde kodebase.
- Forbud mod ændring af kode i containere.
cron pod:
- container med apache, php, cron
- komplet med den fulde kodebase
- forbud mod ændring af kode i containere
upgrade pod:
- container med nginx + container apache/php-fpm + msmtp
- der er ikke noget forbud mod ændring af kode i containere
sessionslager
cachelager for Bitrix
Det er også vigtigt: adgangskoder til alt fra databasen til e-mail opbevarer vi i kubernetes secrets. Vi får en bonus, adgangskoderne er kun synlige for dem, vi giver adgang til hemmelighederne, og ikke alle, der har adgang til kodebasen.
Lager til statisk indhold
Du 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 til /upload/ webstedets direkte og andre direktiver med statisk indhold.
Database
For enkelhed anbefaler vi at tage databasen uden for Kubernetes. En database i Kubernetes er en separat kompleks opgave, som vil gøre opsætningen væsentligt mere kompliceret.
sessionslager
Vi bruger memcached 🙂
Det håndterer sessioner godt, kan klynge og understøttes "nativt" som session.save_path i php. Et sådant system er blevet afprøvet mange gange før i klassisk monolitisk arkitektur, hvor vi byggede klynger med mange webservere. Til deployment bruger vi helm.
$ helm install stable/memcached --name sessionphp.ini - her er indstillingerne for opbevaring af sessioner i memcached angivet i billedet
Vi har brugt miljøvariable til at overføre oplysninger om værter med memcached .
Dette giver mulighed for at bruge den samme kode i dev, stage, test, prod miljøer (navnene på memcached-værterne vil være forskellige, så vi skal overføre unikt navn på værter til sessioner i hvert miljø).
Cache-lager Bitrix
Vi har brug for et fejltolerant lager, hvor 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 angives, hvor vores cache opbevares
Vi bruger også miljøvariable.
Cron-opgaver
Der er forskellige tilgange til at udføre cron-opgaver i Kubernetes.
- separat deployment med en pod til at udføre cron-opgaver
- cronjob til at udføre cron-opgaver (hvis det er en webapp - med wget , eller kubectl exec ind i en af worker-podene, osv.)
- etc.
Man kan argumentere for, hvad der er den mest korrekte, men i dette tilfælde valgte vi løsningen "separat deployment med pods til cron-opgaver"
Sådan er det gjort:
- cron-opgaver tilføjes via ConfigMap eller via filen config/addcron
- i ét eksemplar kører vi en container, der er identisk med worker-poden + tillader udførelse af cron-opgaver i den
- den samme kodebase bruges, hvilket gør containeropbygningen enkel
Hvad får vi ud af det:
- vi har fungerende cron-opgaver i et miljø, der ligner udviklernes miljø (docker)
- cron-opgaver skal ikke "omskrives" til Kubernetes, de fungerer i den samme form og med den samme kodebase som før
- alle teammedlemmer med commit-rettigheder i produktionsgrenen kan tilføje cron-opgaver, ikke kun administratorer
Modulet Southbridge K8SDeploy og koderedigering fra admin-panelet
Vi talte jo om opgraderingen af pod-en?
Hvordan dirigerer vi trafik dertil?
Hurra, vi har skrevet et modul til dette i php 🙂 Det er et lille klassisk modul til Bitrix. Det er endnu ikke offentligt tilgængeligt, men vi planlægger at åbne det.
Modulet installeres som et almindeligt modul i Bitrix:
Og det ser sådan ud:
Det giver mulighed for at angive en cookie, der identificerer websitets administrator, og gør det muligt for Kubernetes at sende trafik til opgraderingspodden.
Når ændringerne er afsluttet, skal du trykke på git push, så vil kodeændringerne blive sendt til git. Systemet vil dernæst bygge et billede med den nye version af koden og "rulle" det ud på klyngen og erstatte de gamle pods.
Ja, det er lidt klodset, men vi bevarer samtidig den mikroservices arkitektur og fjerner ikke den mulighed fra Bitrix-brugere, som de holder af, at redigere koden fra adminpanelet. I sidste ende er det en mulighed; opgaven med at redigere koden kan løses på andre måder.
Helm chart
Til at bygge applikationer i Kubernetes bruger vi som regel pakkeadministratoren Helm.
Til vores Bitrix-løsning i Kubernetes har Sergey Bondarev, vores førende systemadministrator, skrevet et specielt Helm chart.
Det udfører opbygning af worker, upgrade, cron-pods, konfigurerer ingresses, tjenester, og overfører variable fra Kubernetes secrets til pods.
Vi gemmer koden i Gitlab, og vi starter også byggeprocessen af Helm 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 tillader også at gøre en "sømløs" rollback, hvis noget går galt under deployment. Det er rart, når det ikke er dig, der panisk "fixer koden via ftp, fordi produktionen er nede", men Kubernetes gør det automatisk, og uden nedetid.
Deploy
Ja, vi er fans af Gitlab & Gitlab CI, vi bruger det 🙂
Ved commit i Gitlab til projektets repository aktiverer Gitlab en pipeline, der udfører deployment af den nye version af miljøet.
Trin:
- build (bygger et nyt Docker-billede)
- test (tester)
- clean up (fjerner testmiljøet)
- push (sender det til Docker registry)
- deploy (udruller applikationen i Kubernetes via Helm).
Hurra, det er klar, vi implementerer!
Eller også stiller vi spørgsmål, hvis der er nogen.
Så, hvad har vi gjort?
Fra et teknisk synspunkt:
- dockeriseret Bitrix;
- "skåret" Bitrix op i containere, hvor hver udfører minimum af funktioner;
- opnået stateless tilstand for containerne;
- løst problemet med opdatering af Bitrix i Kubernetes;
- alle funktioner i Bitrix fortsatte med at fungere (næsten alle);
- arbejdede med deployment i Kubernetes og rollback mellem versioner.
Fra et forretningsmæssigt synspunkt:
- fejltolerance;
- Kubernetes-værktøjer (nem integration med Gitlab CI, sømløs deployment, osv.);
- adgangskoder i secrets (synlige kun for dem, der har direkte adgang til adgangskoderne);
- Det er praktisk at skabe yderligere miljøer (til udvikling, test osv.) inden for en samlet infrastruktur.
Kilde: habr.com
