Stretnutia systémových administrátorov Sysadminka sa konajú v Čeľabinsku a na poslednom som podal správu o našom riešení pre spúšťanie aplikácií na 1C-Bitrix v Kubernetes.
Bitrix, Kubernetes, Ceph - skvelá zmes?
Poviem vám, ako sme z toho všetkého dali dohromady fungujúce riešenie.
Poďme!
Stretnutie sa uskutočnilo 18. apríla v Čeľabinsku. O našich stretnutiach si môžete prečítať na a pozri sa .
Ak k nám chcete prísť s reportážou alebo ako poslucháč - vitajte, napíšte na [chránené e-mailom] a na telegrame t.me/vadimisakanov.
Moja správa
Riešenie "Bitrix v Kubernetes, verzia Southbridge 1.0"
Budem hovoriť o našom riešení vo formáte „pre figuríny v Kubernetes“, ako to bolo urobené na stretnutí. Predpokladám ale, že slová Bitrix, Docker, Kubernetes, Ceph poznáte aspoň na úrovni článkov na Wikipédii.
Čo je hotové o Bitrixe v Kubernetes?
O fungovaní Bitrix aplikácií v Kubernetes je na celom internete veľmi málo informácií.
Našiel som len tieto materiály:
Správa Alexandra Serbula, 1C-Bitrixa a Antona Tuzlukova zo spoločnosti Qsoft:
Odporúčam si to vypočuť.
Vývoj vlastného riešenia od používateľa .
Našlo sa viac .
Aaa... vlastne, to je všetko.
Upozorňujem, kvalitu riešení v odkazoch vyššie sme nekontrolovali :)
Mimochodom, pri príprave nášho riešenia som hovoril s Alexandrom Serbulom, potom sa jeho správa ešte neobjavila, takže v mojich snímkach je položka „Bitrix nepoužíva Kubernetes“.
Ale už existuje veľa hotových obrazov Docker na spustenie Bitrix v Docker:
Stačí to na vytvorenie kompletného riešenia pre Bitrix v Kubernetes?
Nie Existuje veľké množstvo problémov, ktoré je potrebné vyriešiť.
Aké sú problémy s Bitrixom v Kubernetes?
Po prvé, hotové obrázky z Dockerhubu nie sú vhodné pre Kubernetes
Ak chceme vybudovať architektúru mikroslužieb (a v Kubernetes to zvyčajne robíme), musíme našu aplikáciu Kubernetes rozdeliť do kontajnerov a nechať každý kontajner vykonávať jednu malú funkciu (a robiť to dobre). Prečo len jeden? Stručne povedané, čím jednoduchšie, tým spoľahlivejšie.
Ak chcete byť konkrétnejší, pozrite si tento článok a video:
Obrázky Docker v Dockerhub sú postavené hlavne na princípe všetko v jednom, takže sme si stále museli vyrobiť vlastný bicykel a dokonca vytvárať obrázky od začiatku.
Po druhé - kód stránky sa upravuje z administračného panela
Na stránke sme vytvorili novú sekciu - kód bol aktualizovaný (pridaný bol adresár s názvom novej sekcie).
Ak ste zmenili vlastnosti komponentu z administračného panela, kód sa zmenil.
Kubernetes „v predvolenom nastavení“ s tým nemôže pracovať; kontajnery musia byť bez štátu.
Dôvod: Každý kontajner (pod) v klastri spracováva iba časť prevádzky. Ak zmeníte kód iba v jednom kontajneri (pod), potom sa kód bude líšiť v rôznych podoch, stránka bude fungovať inak a rôzne verzie stránky sa budú zobrazovať rôznym používateľom. Takto sa žiť nedá.
Po tretie - musíte vyriešiť problém s nasadením
Ak máme monolit a jeden „klasický“ server, všetko je celkom jednoduché: nasadíme novú kódovú základňu, migrujeme databázu, prepneme prevádzku na novú verziu kódu. Prepínanie prebieha okamžite.
Ak máme stránku v Kubernetes, rozrezanú na mikroslužby, existuje veľa kontajnerov s kódom - oh. Musíte zbierať kontajnery s novou verziou kódu, zaviesť ich namiesto starých, správne migrovať databázu a v ideálnom prípade to urobiť bez povšimnutia návštevníkov. Našťastie nám s tým pomáha Kubernetes, ktorý podporuje množstvo rôznych typov nasadení.
Po štvrté - musíte vyriešiť otázku ukladania statiky
Ak má váš web „iba“ 10 gigabajtov a nasadíte ho celý v kontajneroch, skončíte s 10 gigabajtovými kontajnermi, ktorých nasadenie trvá večnosť.
„Najťažšie“ časti lokality musíte skladovať mimo kontajnerov a vyvstáva otázka, ako to urobiť správne
Čo v našom riešení chýba?
Celý kód Bitrix nie je rozdelený na mikrofunkcie/mikroslužby (aby bola samostatná registrácia, samostatný modul internetového obchodu atď.). V každom kontajneri uložíme celú základňu kódu.
Databázu tiež neukladáme v Kubernetes (ešte som implementoval riešenia s databázou v Kubernetes pre vývojové prostredia, ale nie pre produkciu).
Správcom stránok bude stále zrejmé, že stránka beží na Kubernetes. Funkcia „kontrola systému“ nefunguje správne, ak chcete upraviť kód stránky z panela správcu, musíte najskôr kliknúť na tlačidlo „Chcem upraviť kód“.
Problémy sú identifikované, potreba implementácie mikroslužieb je určená, cieľ je jasný – získať funkčný systém pre beh aplikácií na Bitrixe v Kubernetes so zachovaním možností Bitrixu aj výhod Kubernetes. Začnime s implementáciou.
architektúra
Existuje veľa „pracovných“ modulov s webovým serverom (pracovníkov).
Jeden pod s úlohami cron (vyžaduje sa iba jeden).
Jedna inovácia na úpravu kódu lokality z panela správcu (vyžaduje sa tiež iba jedna).
Riešime otázky:
- Kde ukladať relácie?
- Kde uložiť vyrovnávaciu pamäť?
- Kde skladovať statiku, neumiestňovať gigabajty statiky do kopy kontajnerov?
- Ako bude databáza fungovať?
Obrázok Docker
Začneme vytvorením obrazu Docker.
Ideálnou možnosťou je, že máme jeden univerzálny obrázok, na základe ktorého získame worker pody, pody s Crontaskmi a upgradujeme pody.
.
Zahŕňa nginx, apache/php-fpm (možno vybrať počas zostavovania), msmtp na odosielanie pošty a cron.
Pri zostavovaní obrázka sa celá kódová základňa stránky skopíruje do adresára /app (s výnimkou tých častí, ktoré presunieme do samostatného zdieľaného úložiska).
Mikroslužby, služby
pracovné moduly:
- Kontajner s nginx + kontajner apache/php-fpm + msmtp
- Nepodarilo sa presunúť msmtp do samostatnej mikroslužby, Bitrix začína byť rozhorčený, že nemôže posielať poštu priamo
- Každý kontajner má kompletnú kódovú základňu.
- Zákaz zmeny kódu v kontajneroch.
cron pod:
- kontajner s apache, php, cron
- vrátane kompletnej kódovej základne
- zákaz zmeny kódu v kontajneroch
upgrade pod:
- kontajner nginx + kontajner apache/php-fpm + msmtp
- Neexistuje žiadny zákaz meniť kód v kontajneroch
úložisko relácie
Vyrovnávacia pamäť Bitrix
Ďalšia dôležitá vec: heslá na pripojenie ku všetkému, od databázy až po poštu, ukladáme do tajomstiev kubernetes. Dostávame bonus: heslá sú viditeľné iba pre tých, ktorým dávame prístup k tajomstvám, a nie pre každého, kto má prístup ku kódovej základni projektu.
Úložný priestor pre statiku
Môžete použiť čokoľvek: ceph, nfs (neodporúčame však nfs na produkciu), sieťové úložisko od poskytovateľov cloudu atď.
Úložisko bude potrebné v kontajneroch prepojiť s adresárom /upload/ lokality a ďalšími adresármi so statickým obsahom.
databázy
Pre jednoduchosť odporúčame presunúť databázu mimo Kubernetes. Základňa v Kubernetes je samostatná komplexná úloha, vďaka ktorej bude schéma rádovo zložitejšia.
Ukladanie relácií
Používame memcached :)
Dobre si poradí s ukladaním relácií, je klastrovaný a je podporovaný „natívne“ ako session.save_path v php. Takýto systém bol mnohokrát testovaný v klasickej monolitickej architektúre, kedy sme budovali klastre s veľkým počtom webových serverov. Na nasadenie používame prilbu.
$ helm install stable/memcached --name sessionphp.ini - tu obrázok obsahuje nastavenia pre ukladanie relácií do memcached
Na odovzdávanie údajov o hostiteľoch s memcached sme použili premenné prostredia .
To vám umožňuje používať rovnaký kód v prostrediach dev, stage, test, prod (názvy hostiteľov memcached v nich budú odlišné, takže musíme každému prostrediu odovzdať jedinečný názov hostiteľa pre relácie).
Vyrovnávacia pamäť Bitrix
Potrebujeme úložisko odolné voči chybám, do ktorého môžu zapisovať a čítať všetky moduly.
Používame aj memcached.
Toto riešenie odporúča samotný Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - tu v Bitrixe je špecifikované, kde je uložená cache
Používame aj premenné prostredia.
Krontaski
Existujú rôzne prístupy k spusteniu Crontask v Kubernetes.
- samostatné nasadenie s modulom na spustenie Crontask
- cronjob na vykonávanie crontask (ak ide o webovú aplikáciu - s wget alebo kubectl exec vo vnútri jedného z pracovných modulov atď.)
- a tak ďalej
Môžete polemizovať o tom najsprávnejšom, ale v tomto prípade sme zvolili možnosť „samostatné nasadenie s modulmi pre Crontask“
Ako sa to robí:
- pridajte úlohy cron cez ConfigMap alebo cez súbor config/addcron
- v jednom prípade spustíme kontajner identický s worker podom + umožníme v ňom vykonávať korunové úlohy
- používa sa rovnaký základ kódu, vďaka zjednoteniu je montáž kontajnera jednoduchá
Čo dobré získame:
- máme pracovné Crontask v prostredí identickom s prostredím vývojárov (docker)
- Crontasky nie je potrebné „prepisovať“ pre Kubernetes, fungujú v rovnakej forme a na rovnakej báze kódu ako predtým
- Úlohy cron môžu pridávať všetci členovia tímu s právami na odovzdanie do produkčnej vetvy, nielen správcovia
Modul Southbridge K8SDeploy a úprava kódu z administračného panela
Hovorili sme o upgrade pod?
Ako tam nasmerovať premávku?
Hurá, napísali sme na to modul v PHP :) Toto je malý klasický modul pre Bitrix. Zatiaľ nie je verejne prístupný, ale plánujeme ho otvoriť.
Modul sa inštaluje ako bežný modul v Bitrix:
A vyzerá to takto:
Umožňuje vám nastaviť súbor cookie, ktorý identifikuje správcu lokality a umožňuje spoločnosti Kubernetes odosielať návštevnosť do modulu inovácie.
Po dokončení zmien musíte kliknúť na git push, zmeny kódu sa odošlú do git, potom systém vytvorí obrázok s novou verziou kódu a „rozbalí“ ho v klastri, pričom nahradí staré moduly. .
Áno, je to trochu barlička, ale zároveň zachovávame architektúru mikroslužieb a neberieme používateľom Bitrix ich obľúbenú príležitosť opraviť kód z panela správcu. Nakoniec je to možnosť, problém s úpravou kódu môžete vyriešiť iným spôsobom.
Tabuľka kormidla
Na vytváranie aplikácií na Kubernetes zvyčajne používame správcu balíkov Helm.
Pre naše riešenie Bitrix v Kubernetes napísal Sergey Bondarev, náš popredný správca systému, špeciálny graf Helm.
Vytvára pracovníkov, upgraduje, cron pody, konfiguruje vstupy, služby, prenáša premenné z tajomstiev Kubernetes do podov.
Kód ukladáme v Gitlabe a spúšťame aj zostavu Helm z Gitlabu.
Skrátka to vyzerá takto
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm vám tiež umožňuje vykonať „plynulý“ návrat, ak sa počas nasadenia náhle niečo pokazí. Je pekné, keď nie ste v panike „opravte kód cez ftp, pretože produkt spadol“, ale Kubernetes to robí automaticky a bez prestojov.
Nasadiť
Áno, sme fanúšikmi Gitlab & Gitlab CI, používame ho :)
Keď sa v Gitlabe zaviažete do projektového úložiska, Gitlab spustí kanál, ktorý nasadí novú verziu prostredia.
etapy:
- zostaviť (vytvoriť nový obrázok Docker)
- test (testovanie)
- vyčistiť (odstrániť testovacie prostredie)
- push (odošleme do registra Docker)
- nasadiť (aplikáciu nasadíme do Kubernetes cez Helm).
Hurá, je to pripravené, poďme na to!
Alebo sa opýtajte, ak nejaké existujú.
Tak čo sme urobili
Z technického hľadiska:
- ukotvený Bitrix;
- „rozrezať“ Bitrix do kontajnerov, z ktorých každý vykonáva minimum funkcií;
- dosiahnutý bezstavový stav kontajnerov;
- vyriešil problém s aktualizáciou Bitrix v Kubernetes;
- všetky funkcie Bitrix naďalej fungovali (takmer všetky);
- Pracovali sme na nasadení do Kubernetes a vrátení medzi verziami.
Z obchodného hľadiska:
- odolnosť proti chybám;
- nástroje Kubernetes (jednoduchá integrácia s Gitlab CI, bezproblémové nasadenie atď.);
- tajné heslá (viditeľné iba pre tých, ktorí majú priamo povolený prístup k heslám);
- Je vhodné vytvárať ďalšie prostredia (na vývoj, testy atď.) v rámci jedinej infraštruktúry.
Zdroj: hab.com