Cseljabinszkban Sysadminka rendszeradminisztrátorok számára szerveznek meetupeket, és az utolsón én bemutattam a megoldásunkat, amely 1C-Bitrix alkalmazások Kubernetes környezetben való futtatására szolgál.
Bitrix, Kubernetes, Ceph – jó keverék?
Elmondom, hogyan állítottunk össze egy működő megoldást mindebből.
Kezdjük!
A meetup április 18-án zajlott Cseljabinszkban. A meetupjainkról itt olvashatsz és itt nézheted meg .
Ha szeretnél hozzánk érkezni előadóként vagy hallgatóként – várunk szeretettel, írj a vadim.isakanov@gmail.com címre és a Telegramra t.me/vadimisakanov.
Az előadásom
A "Bitrix Kubernetes környezetben, Southbridge 1.0 verzió" megoldás.
Elmondom a megoldásunkat "Kubernetes kezdőknek" formátumban, ahogyan ezt a meetup-on bemutattuk. De feltételezem, hogy a Bitrix, Docker, Kubernetes és Ceph szavakat legalább a Wikipédia szintjén ismered.
Mi készült eddig a Bitrix Kubernetes környezetbeli működéséről?
Az interneten nagyon kevés információ található a Bitrix alkalmazások Kubernetes környezetbeli futásáról.
Csak ilyen anyagokat találtam:
Alexander Serbul, 1C-Bitrix és Anton Tuzlukov a Qsoft-tól előadása:
Ajánlom, hogy hallgasd meg.
Saját megoldás fejlesztése a felhasználó részéről .
Találtam még .
És… gyakorlatilag ez minden.
Figyelmeztetek, hogy a fenti linkeken található megoldások működésének minőségét nem ellenőriztük 🙂.
Egyébként, a megoldásunk előkészítése során beszéltem Alexander Serbul-lal, akkor még nem volt előadása, ezért a diáim között szerepel a "Bitrix nem használ Kubernetes-t" pont.
De már sok kész Docker képet találhatsz a Bitrix Docker környezetbeli működéséhez:
Elég ez egy teljes értékű megoldás létrehozásához a Bitrix számára Kubernetes környezetben?
Nem. Sok probléma van, amit meg kell oldani.
Mik a problémák a Bitrix-szel a Kubernetes környezetben?
Az első – a Dockerhub-ból származó kész képek nem alkalmasak Kubernetes-re.
Ha mikroszolgáltatás-architektúrát szeretnénk felépíteni (amit Kubernetes-ben általában akarunk), az alkalmazást Kubernetes-ben konténerekre kell bontani, és arra kell törekedni, hogy minden konténer egy kis funkciót végezzen el (és azt jól csinálja). Miért csak egyet? Röviden: minél egyszerűbb, annál megbízhatóbb.
Ha részletesebben - kérlek nézd meg ezt a cikket és videót:
A Dockerhub-ból származó Docker képek többsége "minden egyben" elven működik, ezért végül saját megoldást kellett készítenünk, és még a képeket is nulláról kellett elkészítenünk.
A második – a weboldal kódja az adminisztrációs panelből szerkeszthető.
Létrehoztunk egy új részt az oldalon — frissült a kód (új direktórium került hozzá az új rész nevével).
Megváltoztattuk a komponens tulajdonságait az admin panelből — megváltozott a kód.
A Kubernetes alapértelmezetten nem tud így dolgozni, a konténereknek nem módosíthatóknak kell lenniük (Stateless).
Az ok: minden pod a klaszterben csak a forgalom egy részét kezeli. Ha csak egy konténerben (podban) módosítjuk a kódot, akkor a különböző podokban eltérő kód lesz, a webhely különbözőképpen működik, a különböző felhasználóknak eltérő verziókat fog mutatni a weboldal. Ezt nem lehet így csinálni.
Harmadszor — meg kell oldani a telepítést.
Ha van egy monolitunk és egy „klasszikus” szerverünk, minden nagyon egyszerű: kinyújtjuk az új kódot, elvégezzük az adatbázis migrációt, és átkapcsoljuk a forgalmat az új kód verziójára. Az átkapcsolás azonnal megtörténik.
Ha a weboldalunk Kubernetes-ben van, mikroszolgáltatásokra van szedve, sok konténerrel a kódhoz — ó. Össze kell gyűjteni a konténereket az új kód verziójával, ezeket a régi helyére kell telepíteni, helyesen kell végrehajtani az adatbázis migrációt, és ideálisan mindezt észrevétlenül kell végezni a látogatók számára. Szerencsére a Kubernetes rengeteg különböző telepítési módot támogat.
Negyedszer — meg kell oldani a statikus fájlok tárolását.
Ha a weboldalad „mindössze” 10 gigabájtot nyom, és teljesen konténerekbe telepíted, 10 gigabájtot nyomó konténereket kapsz, amelyek örökké fognak települni.
A leg „nehézebb” részeket a weboldalból a konténereken kívül kell tárolni, és felmerül a kérdés, hogyan érdemes ezt megfelelően megtenni.
Mit nem tartalmaz a megoldásunk.
A Bitrix összes kódja nem lett levágva mikrofunkciókra/mikroszolgáltatásokra (például a regisztráció külön, az internetes bolt modulja külön, stb.). Az összes kódalapot tároljuk minden konténerben teljes egészében.
Az adatbázist a Kubernetes-ben szintén nem tároljuk (mégis dolgoztam ki adatbázissal kapcsolatos megoldásokat Kubernetes-ben fejlesztői környezetek számára, de nem a termeléshez).
Az adminisztrátorok számára észlelhető lesz, hogy a weboldal Kubernetes-ben fut. A „rendszerellenőrzés” funkció nem működik helyesen, a weboldal kódjának szerkesztéséhez az admin panelból először meg kell nyomni a „szeretném szerkeszteni a kódot” gombot.
A problémákat megoldottuk, a mikroszervizelés szükségességét tisztáztuk, a cél világos - működő rendszert szeretnénk kapni a Bitrix alkalmazások Kubernetes-en való működtetéséhez, megőrizve a Bitrix lehetőségeit és a Kubernetes előnyeit. Elkezdjük a megvalósítást.
Architektúra
Sok «munkakör» pod webkiszolgálóval (worker-ek).
Egy pod krónikus feladatokkal (csak egy kötelező).
Egy upgrade pod a weboldal kódjának szerkesztésére az adminisztrációs panelelt (szintén kötelező csak egy).
Kérdéseket oldunk meg:
- Hol tároljuk a session-öket?
- Hol tároljuk a cache-t?
- Hol tároljuk a statikus fájlokat, nem akarjuk gigabájt statikus fájlokat lumpenálni több konténerben?
- Hogyan működik az adatbázis?
Docker kép
A Docker kép összeállításával kezdünk.
Ideális esetben egy univerzális képünk van, amely alapján worker podokat, cron podokat és upgrade podokat kapunk.
.
A kép tartalmazza az nginx, apache/php-fpm (választható az összeállítás során), msmtp a levelek küldéséhez és a cron.
Az kép összeállításakor a /app könyvtárba a weboldal teljes kódalapját másoljuk (kivéve azokat a részeket, amelyeket külön shared storage-ba helyezünk).
Mikroszervizelés, szolgáltatások
worker podok:
- Konténer nginx + konténer apache/php-fpm + msmtp
- Az msmtp-t külön mikroszervizként nem tudtuk kivenni, a Bitrix felháborodik, hogy nem tud közvetlenül levelet küldeni.
- Minden konténerben a teljes kódalap található.
- Tilalom a kód módosítására a konténerekben.
cron pod:
- konténer apache, php, cron
- a csomagban teljes kódalap található
- tilalom a kód módosítására a konténerekben
upgrade pod:
- konténer nginx + konténer apache/php-fpm + msmtp
- nincs tilalom a kód módosítására a konténerekben
session tároló
Bitrix cache tároló
Továbbá fontos: az összes csatlakozási jelszót, az adatbázistól a levelekig, a kubernetes titkokban tároljuk. Bónusz, a jelszavak csak azok számára láthatók, akikkel megadjuk a titkokhoz való hozzáférést, és nem mindenki számára, akinek van hozzáférése a projekt kódalapjához.
Statikus fájlok tárolója
Bármit használhatunk: ceph, nfs (de az nfs-t nem ajánljuk produkcióra), hálózati tároló „felhő” szolgáltatóktól, stb.
A tárolót a konténerekben az /upload/ könyvtárba és más statikus könyvtárakba kell csatlakoztatni.
Adatbázis
Egyszerűség kedvéért ajánljuk az adatbázis kihelyezését a Kubernetes-en kívül. Az adatbázis a Kubernetes-ben - egy külön bonyolult feladat, amely sokkal bonyolultabbá teszi az architektúrát.
Session tároló
A memcached-t használjuk 🙂
Jól kezeli a munkamenetek tárolását, klaszterezhető, a php session.save_path-n „natívan” támogatott. Ez a rendszer már többször bebizonyította magát a klasszikus monolit architektúrában, amikor klasztereket építettünk sok webszerverrel. A telepítéshez helm-et használunk.
$ helm install stable/memcached --name sessionphp.ini — itt a képen be vannak állítva a munkamenetek tárolásához szükséges beállítások memcached-ben.
Környezeti változókat használtunk a memcached hostokról szóló adatok átadására. .
Ez lehetővé teszi ugyanannak a kódnak a használatát a dev, stage, test, prod környezetekben (a memcached hostok neve eltérő lesz, ezért minden környezetbe egyedi neveket kell átadnunk a munkamenetekhez).
Bitrix cache tároló
Szükségünk van egy katasztrófaellenálló tárolóra, ahová minden pod írhat, és ahonnan olvashat.
Emellett memcached-t is használunk.
Ezt a megoldást magától a Bitrixtől ajánlják.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php — itt a Bitrix-ben be van állítva, hol tároljuk a cache-t.
Környezeti változókat szintén használunk.
Cron feladatok
Különböző megközelítések léteznek a cron feladatok végrehajtására Kubernetesben.
- külön deployment pod a cron feladatok végrehajtásához
- cronjob a cron feladatok végrehajtásához (ha ez egy webalkalmazás — wget-tel: , vagy kubectl exec a worker podok egyikébe, stb.)
- stb.
Lehet vitatkozni a legmegfelelőbb megoldásról, de ebben az esetben a "külön deployment podok a cron feladatokhoz" megoldást választottuk.
Hogyan készült:
- cron feladatokat adunk hozzá ConfigMap-en keresztül vagy a config/addcron fájl segítségével.
- egy példányban elindítjuk a konténert, amely azonos a worker poddal + lehetővé tesszük a cron feladatok végrehajtását benne.
- ugyanazt a kódalapot használjuk, köszönhetően az egységesítésnek, a konténer összeállítása egyszerű.
Mit nyerünk:
- a működő cron feladatok a fejlesztők környezetéhez hasonló környezetben futnak (docker).
- a cron feladatokat nem kell "átírni" Kubernetesre, ugyanolyan formában és ugyanabban a kódbázisban működnek, mint korábban.
- a cron feladatokat csapatunk minden tagja hozzáadhatja, akinek van commit joguk a production ágon, nem csak az adminok.
Southbridge K8SDeploy modul és a kód szerkesztése az admin panelből.
Hiszen a pod frissítéséről beszéltünk?
Hogyan irányítsuk oda a forgalmat?
Hurrá, írtunk ehhez egy modult php-n 🙂 Ez egy kis klasszikus modul a Bitrix számára. Még nem érhető el nyilvánosan, de tervezzük, hogy megnyitjuk.
A modul telepítése úgy történik, mint egy szokásos Bitrix modul:
És így néz ki:
Ez lehetővé teszi egy cookie beállítását, amely az oldal adminisztrátorát azonosítja, és lehetővé teszi a Kubernetes számára, hogy forgalmat küldjön a frissítési podra.
Miután a változtatások elkészültek, meg kell nyomni a git push-t, a kódváltozások el fognak küldve a git-be, majd a rendszer új képet készít az új kódverzióval és "kigurítja" azt a klaszterre, felváltva a régi podokat.
Igen, kicsit nehézkes, de így megőrizzük a mikroszolgáltatás-architektúrát és nem vesszük el a Bitrix felhasználóinak kedvenc lehetőségét, hogy a kódot módosítsák az admin felületről. Végül is ez egy opció, a kód módosítási feladatot másként is meg lehet oldani.
Helm chart
Általában a Kubernetes alkalmazások összeállításához a Helm csomagkezelőt használjuk.
A Bitrix megoldásunkhoz Kubernetes alatt Szergej Bondarev, vezető rendszeradminisztrátorunk készített egy speciális Helm chartot.
Ez végrehajtja a worker, upgrade, cron podok összeállítását, beállítja az ingress-eket, a szolgáltatásokat, átadja a változókat a Kubernetes secret-ekből a podokba.
A kódot a Gitlabban tároljuk, és a Helm összeállítást is a Gitlabból indítjuk.
Röviden így néz ki:
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionA Helm lehetővé teszi a "zökkenőmentes" visszaállítást is, ha változtatás közben valami nem működik. Jó, amikor nem pánikban "javítod a kódot ftp-n, mert a production leállt", hanem a Kubernetes automatikusan elvégzi ezt, ráadásul leállás nélkül.
Deploy
Igen, Gitlab & Gitlab CI fanatikusok vagyunk, használjuk 🙂
Gitlabba történő elkötelezéssel a Gitlab elindít egy pipeline-t, amely a projekt új környezetverziójának telepítését végzi.
Lépések:
- build (új Docker kép összeállítása)
- test (tesztelés)
- clean up (tesztelési környezet eltávolítása)
- push (kép elküldése a Docker registrybe)
- deploy (alkalmazás telepítése Kubernetesben a Helmen keresztül).
Hurrá, kész, bevezetjük!
Vagy felvetjük a kérdéseket, ha vannak.
Tehát mit csináltunk?
Technikai szempontból:
- Dockerizáltuk a Bitrix-ot;
- "felvágtuk" a Bitrix-ot konténerekre, amelyek mindegyike minimum funkciókat végez;
- elértük, hogy a konténerek állapotmentesek legyenek;
- megoldottuk a Bitrix frissítési problémáját Kubernetesben;
- a Bitrix összes funkciója továbbra is működött (majdnem mindegyik);
- megoldottuk a Kubernetes telepítést és a verziók közötti visszaállítást.
Üzleti szempontból:
- hibamentesség;
- Kubernetes eszközök (egyszerű integráció a Gitlab CI-vel, zökkenőmentes telepítés, stb.);
- jelszavak a titkokban (csak azok látják, akiknek közvetlen hozzáférésük van a jelszavakhoz);
- Kényelmes több környezetet kialakítani (fejlesztéshez, teszteléshez stb.) egyetlen infrastruktúrában.
Forrás: habr.com
