A Sysadminka rendszeradminisztrátori találkozókra Cseljabinszkban került sor, a legutóbbi alkalmon pedig beszámoltam a Kubernetes 1C-Bitrixen futó alkalmazások futtatására szolgáló megoldásunkról.
Bitrix, Kubernetes, Ceph – remek keverék?
Elmondom, hogyan állítunk össze egy működő megoldást mindebből.
Gyerünk!
A találkozóra április 18-án került sor Cseljabinszkban. Találkozóinkról itt olvashat és nézd meg .
Ha riporttal vagy hallgatóként szeretne eljönni hozzánk - üdvözöljük, írjon a címre [e-mail védett] és a Telegramon t.me/vadimisakanov.
A jelentésem
Megoldás "Bitrix in Kubernetes, Southbridge 1.0 verzió"
Megoldásunkról a „kubernetes bábukért” formátumban fogok beszélni, ahogy az a meetupon is történt. De feltételezem, hogy legalább a Wikipédia cikkeinek szintjén ismeri a Bitrix, Docker, Kubernetes, Ceph szavakat.
Mi a kész Bitrix a Kubernetesben?
A teljes interneten nagyon kevés információ található a Bitrix alkalmazások Kubernetesben történő működéséről.
Csak ezeket az anyagokat találtam:
Alexander Serbul, 1C-Bitrix és Anton Tuzlukov jelentése a Qsofttól:
Javaslom meghallgatni.
Saját megoldás kidolgozása a felhasználótól .
Többet talált .
Aaand... valójában ez minden.
Figyelmeztetlek, nem ellenőriztük a fenti linkeken található megoldások minőségét :)
Egyébként a megoldásunk elkészítésekor Alexander Serbullal beszélgettem, akkor még nem jelent meg a jelentése, így a diákjaimban van egy „Bitrix nem használja a Kuberneteset” tétel.
De már sok kész Docker-kép létezik a Bitrix futtatásához a Dockerben:
Ez elég egy komplett megoldás létrehozásához a Bitrix számára a Kubernetesben?
Nem. Nagyon sok probléma van, amelyeket meg kell oldani.
Mik a problémák a Bitrix-szel a Kubernetesben?
Először is, a Dockerhub kész képei nem alkalmasak a Kubernetes számára
Ha mikroszolgáltatási architektúrát akarunk építeni (és a Kubernetesben általában ezt tesszük), Kubernetes alkalmazásunkat konténerekre kell szétválasztanunk, és mindegyik konténernek egy kis funkciót kell végrehajtania (és jól csinálni). Miért csak egy? Röviden, minél egyszerűbb, annál megbízhatóbb.
Ha pontosabb akar lenni, nézze meg ezt a cikket és videót:
A Dockerhubban található Docker-képek főként az all-in-one elven épülnek fel, így továbbra is saját kerékpárt kellett készítenünk, sőt a semmiből készített képeket is.
Másodszor - a webhely kódja az adminisztrációs panelről szerkeszthető
Létrehoztunk egy új részt az oldalon - a kód frissítve lett (egy könyvtár hozzáadva az új rész nevével).
Ha az adminisztrációs panelről módosította egy összetevő tulajdonságait, a kód megváltozott.
A Kubernetes „alapértelmezés szerint” nem működik ezzel; a tárolóknak hontalannak kell lenniük.
Ok: A fürtben minden tároló (pod) csak a forgalom egy részét dolgozza fel. Ha csak egy tárolóban (podban) változtatja meg a kódot, akkor a kód eltérő lesz a különböző podokban, a webhely eltérően fog működni, és a webhely különböző verziói jelennek meg a különböző felhasználók számára. Nem élhetsz így.
Harmadszor - meg kell oldania a problémát a telepítéssel
Ha van egy monolit és egy „klasszikus” szerverünk, akkor minden nagyon egyszerű: új kódbázist telepítünk, áttelepítjük az adatbázist, átállítjuk a forgalmat a kód új verziójára. A váltás azonnal megtörténik.
Ha van egy oldalunk Kubernetesben, mikroszolgáltatásokra vágva, nagyon sok konténer van kóddal - oh. Össze kell gyűjtenie a konténereket a kód új verziójával, ki kell dobnia a régiek helyett, megfelelően kell migrálnia az adatbázist, és ezt ideális esetben a látogatók észrevétlenül kell megtennie. Szerencsére a Kubernetes segít nekünk ebben, egy csomó különféle telepítést támogat.
Negyedszer - meg kell oldania a statika tárolásának kérdését
Ha a webhelye „csak” 10 gigabájtos, és teljes egészében konténerekben telepíti, akkor 10 gigabájtos konténereket kap, amelyek telepítése örökké tart.
A webhely „legnehezebb” részeit konténereken kívül kell tárolnia, és felmerül a kérdés, hogyan kell ezt helyesen megtenni.
Mi hiányzik a megoldásunkból?
A teljes Bitrix kód nincs felosztva mikrofunkciókra/mikroszolgáltatásokra (hogy külön legyen a regisztráció, külön az online áruház modul stb.). Minden tárolóban tároljuk a teljes kódbázist.
Az adatbázist sem Kubernetesben tároljuk (a fejlesztői környezetekhez még mindig Kubernetesben valósítottam meg adatbázissal a megoldásokat, de nem termeléshez).
A webhely rendszergazdái továbbra is észrevehetik, hogy a webhely Kubernetesen fut. A „rendszerellenőrzés” funkció nem működik megfelelően; a webhely kódjának az adminisztrációs panelről történő szerkesztéséhez először kattintson a „Szeretném szerkeszteni a kódot” gombra.
A problémákat azonosították, a mikroszolgáltatások bevezetésének szükségességét meghatározták, a cél egyértelmű - egy működő rendszer létrehozása az alkalmazások Bitrix-en való futtatásához Kubernetesben, megőrizve a Bitrix képességeit és a Kubernetes előnyeit. Kezdjük a megvalósítást.
építészet
Sok „működő” pod van webszerverrel (munkásokkal).
Egy under cron feladatokkal (csak egy szükséges).
Egy frissítés a webhely kódjának szerkesztéséhez az adminisztrációs panelről (szintén csak egy szükséges).
Kérdéseket oldunk meg:
- Hol tároljuk a munkameneteket?
- Hol tároljuk a gyorsítótárat?
- Hol tároljuk a statikát, ne rakjunk gigabájtnyi statikát egy csomó konténerbe?
- Hogyan fog működni az adatbázis?
Docker kép
Kezdjük egy Docker image felépítésével.
Az ideális megoldás az, hogy egyetlen univerzális képünk van, ennek alapján kapunk worker podokat, Crontaskkal ellátott podokat és upgrade podokat.
.
Tartalmazza az nginxet, az apache/php-fpm-et (kiválasztható az összeállítás során), az msmtp-t levélküldéshez és a cront.
A kép összeállításakor az oldal teljes kódbázisa az /app könyvtárba másolódik (kivéve azokat a részeket, amelyeket külön megosztott tárhelyre helyezünk át).
Mikroszolgáltatások, szolgáltatások
munkásdobozok:
- Tároló nginx-szel + konténer apache/php-fpm + msmtp
- Nem sikerült az msmtp-t külön mikroszolgáltatásba költöztetni, a Bitrix kezd felháborodni, hogy nem tud közvetlenül levelet küldeni
- Minden tárolónak teljes kódbázisa van.
- A kód megváltoztatásának tilalma a konténerekben.
cron alatt:
- tároló apache, php, cron
- teljes kódalapot tartalmazza
- a kód megváltoztatásának tilalma a konténerekben
frissítés alatt:
- nginx tároló + apache/php-fpm tároló + msmtp
- Nincs tiltva a kód megváltoztatása a konténerekben
munkamenet tárolása
Bitrix gyorsítótár
Egy másik fontos dolog: a kubernetes titkosokban tároljuk a jelszavakat, amelyek segítségével mindenhez kapcsolódhatunk, az adatbázistól a levelezésig. Bónuszt kapunk: a jelszavakat csak azok láthatják, akiknek hozzáférést biztosítunk a titkokhoz, és nem mindenki, aki hozzáfér a projekt kódbázisához.
Statika tárolására
Bármit használhat: ceph, nfs (de nem ajánljuk az nfs-t élesre), hálózati tárhely felhőszolgáltatóktól stb.
A tárolót konténerekben kell csatlakoztatni a webhely /upload/ könyvtárához és más statikus tartalmú könyvtárakhoz.
Adatbázis
Az egyszerűség kedvéért javasoljuk, hogy helyezze át az adatbázist a Kubernetesen kívülre. A kubernetesi bázis egy különálló összetett feladat, nagyságrenddel bonyolultabbá teszi a sémát.
Munkamenet tárolása
Mi memcachedet használunk :)
Jól kezeli a munkamenet-tárolást, fürtözött, és „natívan” session.save_path néven támogatott a php-ban. Egy ilyen rendszert sokszor teszteltek a klasszikus monolitikus architektúrában, amikor nagyszámú webszerverrel építettünk klasztereket. A telepítéshez sisakot használunk.
$ helm install stable/memcached --name sessionphp.ini - itt a kép a munkamenetek memcachedben való tárolására vonatkozó beállításokat tartalmazza
Környezeti változókat használtunk a memcached-el rendelkező gazdagépek adatainak átadására .
Ez lehetővé teszi, hogy ugyanazt a kódot használjuk a fejlesztői, színpadi, teszt-, prod-környezetben (a bennük lévő memcached hosztnevek eltérőek lesznek, ezért minden környezetnek egyedi hosztnevet kell átadnunk a munkamenetekhez).
Bitrix gyorsítótár
Hibatűrő tárhelyre van szükségünk, amelyre minden pod tud írni és olvasni tud.
Memcachedet is használunk.
Ezt a megoldást maga a Bitrix ajánlja.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - itt a Bitrixben meg van adva, hogy hol van a gyorsítótár tárolása
Környezeti változókat is használunk.
Krontaski
Különféle megközelítések léteznek a Crontasks futtatására a Kubernetesben.
- külön telepítés egy pod a Crontasks futtatásához
- cronjob a crontask végrehajtásához (ha ez egy webalkalmazás - wget , vagy kubectl exec az egyik worker podban stb.)
- elvisszük helyi falvakba ahol megismerkedhet az őslakosok kultúrájával; ...
Lehet vitatkozni a leghelyesebben, de ebben az esetben a „külön telepítés podokkal a Crontasks számára” opciót választottuk.
Hogyan készül:
- adjon hozzá cron feladatokat a ConfigMap vagy a config/addcron fájl segítségével
- egy esetben elindítunk egy konténert, ami megegyezik a worker pod-al + lehetővé tesszük benne a crown feladatok végrehajtását
- ugyanazt a kódbázist használják, az egységesítésnek köszönhetően a konténer összeszerelése egyszerű
Mire jót kapunk:
- működő Crontask-jaink vannak a fejlesztői környezettel azonos környezetben (docker)
- A crontask-okat nem kell „újraírni” a Kuberneteshez, ugyanolyan formában és kódbázisban működnek, mint korábban
- A cron feladatokat nem csak az adminisztrátorok, hanem a termelési ághoz a véglegesítési joggal rendelkező csapattagok is hozzáadhatják
Southbridge K8SDeploy modul és kódszerkesztés az adminisztrációs panelről
alatti frissítésről beszéltünk?
Hogyan lehet oda irányítani a forgalmat?
Hurrá, ehhez írtunk egy modult PHP-ben :) Ez egy kis klasszikus modul a Bitrixhez. Nyilvánosan még nem elérhető, de tervezzük megnyitni.
A modul úgy van telepítve, mint egy normál modul a Bitrixben:
És így néz ki:
Lehetővé teszi olyan cookie beállítását, amely azonosítja a webhely rendszergazdáját, és lehetővé teszi a Kubernetes számára, hogy forgalmat küldjön a frissítési podba.
Ha a változtatások befejeződtek, rá kell kattintani a git push gombra, a kódmódosítások elküldésre kerülnek a git-nek, majd a rendszer létrehoz egy képet a kód új verziójával, és a régi podokat lecserélve „kiteríti” a fürtre. .
Igen, ez egy kis mankó, de ugyanakkor fenntartjuk a mikroszolgáltatási architektúrát, és nem vonjuk el a Bitrix felhasználóktól a kedvenc lehetőségüket, hogy javítsák a kódot az adminisztrációs panelen. Végül ez egy lehetőség, a kód szerkesztésének problémáját más módon is megoldhatja.
Helm diagram
Alkalmazások Kubernetesen történő készítéséhez általában a Helm csomagkezelőt használjuk.
A kubernetesi Bitrix megoldásunkhoz Sergey Bondarev, vezető rendszergazdánk egy speciális Helm-diagramot írt.
Worker, ugrade, cron podokat épít, bemeneteket, szolgáltatásokat konfigurál, és változókat visz át a Kubernetes titkokból a podokra.
A kódot a Gitlabban tároljuk, és a Helm buildet is a Gitlabból futtatjuk.
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 hirtelen valami elromlik a telepítés során. Jó, ha nincs pánik „javítsd ki a kódot ftp-n keresztül, mert leesett a prod”, de a Kubernetes ezt automatikusan, leállás nélkül teszi.
Telepítés
Igen, a Gitlab & Gitlab CI rajongói vagyunk, használjuk :)
Amikor a Gitlabban elkötelezi magát a projekttárhoz, a Gitlab elindít egy folyamatot, amely a környezet új verzióját telepíti.
Szakasz:
- build (új Docker-imázs készítése)
- teszt (teszt)
- tisztítás (a tesztkörnyezet eltávolítása)
- push (küldjük a Docker registry-be)
- telepíteni (az alkalmazást a Kubernetesre a Helmen keresztül telepítjük).
Hurrá, kész van, valósítsuk meg!
Nos, vagy kérdezz, ha van.
Szóval mit csináltunk
Technikai szempontból:
- dokkolós Bitrix;
- „vágja” a Bitrixet tartályokba, amelyek mindegyike minimális funkciót lát el;
- elérte a konténerek állapotmentes állapotát;
- megoldotta a problémát a Bitrix frissítésével Kubernetesben;
- az összes Bitrix funkció továbbra is működött (majdnem mindegyik);
- Dolgoztunk a Kubernetes-be való telepítésen és a verziók közötti visszaállításon.
Üzleti szempontból:
- hibatűrés;
- Kubernetes eszközök (egyszerű integráció a Gitlab CI-vel, zökkenőmentes telepítés stb.);
- titkos jelszavak (csak azok láthatják, akik közvetlenül hozzáférnek a jelszavakhoz);
- Kényelmes további környezetek létrehozása (fejlesztéshez, tesztekhez stb.) egyetlen infrastruktúrán belül.
Forrás: will.com