Er vinden bijeenkomsten voor systeembeheerders voor Sysadminka plaats in Tsjeljabinsk, en bij de laatste heb ik een rapport gegeven over onze oplossing voor het draaien van applicaties op 1C-Bitrix in Kubernetes.
Bitrix, Kubernetes, Ceph - een geweldige mix?
Ik zal je vertellen hoe we hieruit een werkende oplossing hebben samengesteld.
Laten we gaan!
De bijeenkomst vond plaats op 18 april in Tsjeljabinsk. Je kunt over onze bijeenkomsten lezen op en kijk naar .
Als je naar ons toe wilt komen met een verslag of als luisteraar - welkom, schrijf dan naar [e-mail beveiligd] en op Telegram t.me/vadimisakanov.
Mijn verslag
Oplossing "Bitrix in Kubernetes, versie Southbridge 1.0"
Ik zal over onze oplossing praten in het ‘voor dummies in Kubernetes’-formaat, zoals gedaan tijdens de meetup. Maar ik neem aan dat je de woorden Bitrix, Docker, Kubernetes, Ceph tenminste kent op het niveau van artikelen op Wikipedia.
Wat is er kant-en-klaar aan Bitrix in Kubernetes?
Er is op het hele internet zeer weinig informatie te vinden over de werking van Bitrix-applicaties in Kubernetes.
Ik heb alleen deze materialen gevonden:
Verslag door Alexander Serbul, 1C-Bitrix en Anton Tuzlukov van Qsoft:
Ik raad aan ernaar te luisteren.
Vanuit de gebruiker een eigen oplossing ontwikkelen .
Meer gevonden .
Aaand... eigenlijk is dat alles.
Ik waarschuw je, we hebben de kwaliteit van de oplossingen in de bovenstaande links niet gecontroleerd :)
Trouwens, bij het voorbereiden van onze oplossing heb ik met Alexander Serbul gesproken, toen was zijn rapport nog niet verschenen, dus in mijn dia's staat een item "Bitrix gebruikt geen Kubernetes."
Maar er zijn al veel kant-en-klare Docker-images voor het uitvoeren van Bitrix in Docker:
Is dit voldoende om een complete oplossing voor Bitrix in Kubernetes te creëren?
Nee. Er zijn een groot aantal problemen die moeten worden opgelost.
Wat zijn de problemen met Bitrix in Kubernetes?
Ten eerste zijn kant-en-klare images uit Dockerhub niet geschikt voor Kubernetes
Als we een microservices-architectuur willen bouwen (en in Kubernetes doen we dat meestal), moeten we onze Kubernetes-applicatie opdelen in containers en elke container één kleine functie laten uitvoeren (en dat goed doen). Waarom slechts één? Kortom: hoe eenvoudiger, hoe betrouwbaarder.
Om specifieker te zijn, bekijk dit artikel en de video:
Docker-images in Dockerhub zijn voornamelijk gebouwd volgens het alles-in-één-principe, waardoor we nog steeds onze eigen fiets moesten maken en zelfs helemaal opnieuw afbeeldingen moesten maken.
Ten tweede: de sitecode wordt bewerkt vanuit het beheerderspaneel
We hebben een nieuwe sectie op de site gemaakt - de code is bijgewerkt (een map met de naam van de nieuwe sectie is toegevoegd).
Als u de eigenschappen van een component vanuit het beheerdersdashboard veranderde, veranderde de code.
Kubernetes kan hier ‘standaard’ niet mee werken; containers moeten staatloos zijn.
Reden: Elke container (pod) in het cluster verwerkt slechts een deel van het verkeer. Als u de code in slechts één container (pod) wijzigt, zal de code in verschillende pods anders zijn, zal de site anders werken en zullen verschillende versies van de site aan verschillende gebruikers worden getoond. Zo kun je niet leven.
Ten derde: u moet het probleem met de implementatie oplossen
Als we een monoliet en één ‘klassieke’ server hebben, is alles vrij eenvoudig: we implementeren een nieuwe codebasis, migreren de database, schakelen het verkeer over naar de nieuwe versie van de code. Het overstappen gebeurt onmiddellijk.
Als we een site in Kubernetes hebben, opgedeeld in microservices, zijn er veel containers met code - oh. U moet containers verzamelen met een nieuwe versie van de code, deze uitrollen in plaats van de oude, de database correct migreren en dit idealiter onopgemerkt door bezoekers doen. Gelukkig helpt Kubernetes ons hierbij en ondersteunt een hele reeks verschillende soorten implementaties.
Ten vierde - u moet het probleem van het opslaan van statische gegevens oplossen
Als uw site “slechts” 10 gigabyte groot is en u deze volledig in containers implementeert, krijgt u uiteindelijk 10 gigabyte containers die een eeuwigheid duren om te implementeren.
U moet de “zwaarste” delen van het terrein buiten containers opslaan, en de vraag rijst hoe u dit op de juiste manier kunt doen
Wat ontbreekt er in onze oplossing?
De volledige Bitrix-code is niet opgedeeld in microfuncties/microservices (zodat de registratie gescheiden is, de webshopmodule gescheiden etc.). We slaan de volledige codebasis op in elke container.
Ook slaan we de database niet op in Kubernetes (ik heb nog wel oplossingen met een database in Kubernetes geïmplementeerd voor ontwikkelomgevingen, maar niet voor productie).
Voor sitebeheerders zal het nog wel opvallen dat de site op Kubernetes draait. De functie “systeemcontrole” werkt niet correct; om de sitecode vanuit het beheerderspaneel te bewerken, moet u eerst op de knop “Ik wil de code bewerken” klikken.
De problemen zijn geïdentificeerd, de noodzaak om microservices te implementeren is vastgesteld, het doel is duidelijk: een werkend systeem krijgen voor het draaien van applicaties op Bitrix in Kubernetes, waarbij zowel de mogelijkheden van Bitrix als de voordelen van Kubernetes behouden blijven. Laten we beginnen met de implementatie.
Architectuur
Er zijn veel ‘werkende’ pods met een webserver (werknemers).
Eén onder met cron-taken (er is er slechts één vereist).
Eén upgrade voor het bewerken van de sitecode vanuit het beheerdersdashboard (er is ook maar één upgrade vereist).
Wij lossen vragen op:
- Waar sessies opslaan?
- Waar de cache opslaan?
- Waar moeten we de statische gegevens opslaan, en niet waar we gigabytes aan statische gegevens in een aantal containers moeten plaatsen?
- Hoe zal de databank werken?
Docker-afbeelding
We beginnen met het bouwen van een Docker-image.
De ideale optie is dat we één universeel beeld hebben, op basis daarvan krijgen we worker-pods, pods met Crontasks en upgrade-pods.
.
Het bevat nginx, apache/php-fpm (kan worden geselecteerd tijdens het bouwen), msmtp voor het verzenden van e-mail en cron.
Bij het samenstellen van de afbeelding wordt de volledige codebasis van de site gekopieerd naar de map /app (met uitzondering van de delen die we naar een aparte gedeelde opslag zullen verplaatsen).
Microdiensten, diensten
werkerpods:
- Container met nginx + container apache/php-fpm + msmtp
- Het lukte niet om msmtp naar een aparte microservice te verplaatsen, Bitrix begint verontwaardigd te worden dat het niet direct mail kan versturen
- Elke container heeft een volledige codebase.
- Verbod op het wijzigen van de code in containers.
cron onder:
- container met apache, php, cron
- volledige codebasis inbegrepen
- verbod op het wijzigen van code in containers
upgraden onder:
- nginx-container + apache/php-fpm-container + msmtp
- Er bestaat geen verbod op het wijzigen van de code in containers
sessie opslag
Bitrix-cacheopslag
Nog iets belangrijks: we slaan wachtwoorden op om verbinding te maken met alles, van de database tot e-mail, in Kubernetes-geheimen. We krijgen een bonus: wachtwoorden zijn alleen zichtbaar voor degenen aan wie we toegang geven tot de geheimen, en niet voor iedereen die toegang heeft tot de codebasis van het project.
Opslag voor statica
Je kunt alles gebruiken: ceph, nfs (maar we raden nfs niet aan voor productie), netwerkopslag van cloudproviders, enz.
De opslag moet in containers worden verbonden met de map /upload/ van de site en andere mappen met statische inhoud.
databank
Voor de eenvoud raden we u aan de database buiten Kubernetes te verplaatsen. De basis in Kubernetes is een aparte complexe taak; het zal het schema een orde van grootte complexer maken.
Sessie opslag
Wij gebruiken memcached :)
Het kan goed omgaan met sessie-opslag, is geclusterd en wordt “native” ondersteund als session.save_path in php. Een dergelijk systeem is vele malen getest in de klassieke monolithische architectuur, toen we clusters bouwden met een groot aantal webservers. Voor inzet maken wij gebruik van helm.
$ helm install stable/memcached --name sessionphp.ini - hier bevat de afbeelding instellingen voor het opslaan van sessies in memcached
We hebben omgevingsvariabelen gebruikt om gegevens over hosts met memcached door te geven .
Hierdoor kunt u dezelfde code gebruiken in de dev-, stage-, test- en prod-omgevingen (de opgeslagen hostnamen daarin zullen verschillend zijn, dus we moeten een unieke hostnaam doorgeven voor sessies aan elke omgeving).
Bitrix-cacheopslag
We hebben fouttolerante opslag nodig waar alle peulen naar kunnen schrijven en van kunnen lezen.
Wij gebruiken ook memcached.
Deze oplossing wordt aanbevolen door Bitrix zelf.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - hier in Bitrix wordt gespecificeerd waar de cache wordt opgeslagen
We gebruiken ook omgevingsvariabelen.
Krontaski
Er zijn verschillende benaderingen voor het uitvoeren van Crontasks in Kubernetes.
- afzonderlijke implementatie met een pod voor het uitvoeren van Crontasks
- cronjob voor het uitvoeren van crontaken (als dit een webapp is - met wget , of kubectl exec in een van de werkpods, enz.)
- enz.
Je kunt discussiëren over de meest correcte, maar in dit geval hebben we gekozen voor de optie “afzonderlijke implementatie met pods voor Crontasks”
Hoe het gedaan wordt:
- voeg cron-taken toe via ConfigMap of via het config/addcron-bestand
- in één geval lanceren we een container die identiek is aan de werkerpod + maken we de uitvoering van kroontaken daarin mogelijk
- Er wordt gebruik gemaakt van dezelfde codebasis, dankzij unificatie is de montage van containers eenvoudig
Wat voor goeds krijgen we:
- we hebben werkende Crontasks in een omgeving die identiek is aan de ontwikkelaarsomgeving (docker)
- Crontasks hoeven voor Kubernetes niet te worden ‘herschreven’, ze werken in dezelfde vorm en in dezelfde codebasis als voorheen
- cron-taken kunnen worden toegevoegd door alle teamleden met commit-rechten voor de productietak, niet alleen door beheerders
Southbridge K8SDeploy module en codebewerking vanuit het beheerderspaneel
We hadden het over een upgrade onder?
Hoe kan ik het verkeer daarheen leiden?
Hoera, we hebben hiervoor een module geschreven in PHP :) Dit is een kleine klassieke module voor Bitrix. Het is nog niet openbaar beschikbaar, maar we zijn van plan het te openen.
De module wordt geïnstalleerd als een gewone module in Bitrix:
En het ziet er zo uit:
Hiermee kunt u een cookie instellen die de sitebeheerder identificeert en Kubernetes in staat stelt verkeer naar de upgradepod te sturen.
Wanneer de wijzigingen zijn voltooid, moet je op git push klikken, de codewijzigingen worden naar git verzonden, waarna het systeem een image met een nieuwe versie van de code zal bouwen en deze over het hele cluster zal "uitrollen", waarbij de oude pods worden vervangen .
Ja, het is een beetje een kruk, maar tegelijkertijd onderhouden we de microservice-architectuur en ontnemen we Bitrix-gebruikers niet hun favoriete mogelijkheid om de code vanuit het beheerderspaneel te corrigeren. Uiteindelijk is dit een optie; je kunt het probleem van het bewerken van de code op een andere manier oplossen.
Helmgrafiek
Om applicaties op Kubernetes te bouwen, gebruiken we doorgaans de Helm-pakketbeheerder.
Voor onze Bitrix-oplossing in Kubernetes schreef Sergey Bondarev, onze toonaangevende systeembeheerder, een speciaal Helm-diagram.
Het bouwt worker-, ugrade- en cron-pods, configureert ingangen, services en draagt variabelen over van Kubernetes-geheimen naar pods.
We slaan de code op in Gitlab en we voeren ook de Helm-build uit vanuit Gitlab.
Kort gezegd ziet het er zo uit
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionMet Helm kunt u ook een “naadloze” rollback uitvoeren als er tijdens de implementatie plotseling iets misgaat. Het is fijn als je niet in paniek bent ‘repareer de code via ftp omdat de prod is gevallen’, maar Kubernetes doet het automatisch en zonder downtime.
Aanwenden
Ja, we zijn fans van Gitlab & Gitlab CI, we gebruiken het :)
Bij het committeren in Gitlab aan de projectrepository lanceert Gitlab een pijplijn die een nieuwe versie van de omgeving implementeert.
fasen:
- build (een nieuwe Docker-image bouwen)
- testen (testen)
- opschonen (de testomgeving verwijderen)
- push (we sturen het naar het Docker-register)
- implementeren (we implementeren de applicatie via Helm in Kubernetes).
Hoera, het is klaar, laten we het implementeren!
Nou ja, of stel vragen als die er zijn.
Dus wat hebben we gedaan
Vanuit technisch oogpunt:
- gedockeriseerde Bitrix;
- “knip” Bitrix in containers, die elk een minimum aan functies vervullen;
- staatloze staat van containers bereikt;
- het probleem opgelost met het updaten van Bitrix in Kubernetes;
- alle Bitrix-functies bleven werken (bijna allemaal);
- We hebben gewerkt aan de implementatie naar Kubernetes en het terugdraaien tussen versies.
Vanuit zakelijk oogpunt:
- fouttolerantie;
- Kubernetes-tools (eenvoudige integratie met Gitlab CI, naadloze implementatie, enz.);
- geheime wachtwoorden (alleen zichtbaar voor degenen die rechtstreeks toegang hebben tot de wachtwoorden);
- Het is handig om binnen één infrastructuur extra omgevingen (voor ontwikkeling, tests, etc.) te creëren.
Bron: www.habr.com