Setkání systémových administrátorů Sysadminka se konají v Čeljabinsku a na posledním jsem podal zprávu o našem řešení pro běh aplikací na 1C-Bitrix v Kubernetes.
Bitrix, Kubernetes, Ceph - skvělá směs?
Řeknu vám, jak jsme z toho všeho dali dohromady funkční řešení.
Pojďme!
Setkání se uskutečnilo 18. dubna v Čeljabinsku. O našich setkáních si můžete přečíst na a podívejte se .
Pokud k nám chcete přijít s reportáží nebo jako posluchač - vítejte, napište na [chráněno e-mailem] a na Telegramu t.me/vadimisakanov.
Moje zpráva
Řešení "Bitrix v Kubernetes, verze Southbridge 1.0"
Budu hovořit o našem řešení ve formátu „pro figuríny v Kubernetes“, jak bylo provedeno na setkání. Předpokládám ale, že slova Bitrix, Docker, Kubernetes, Ceph znáte minimálně na úrovni článků na Wikipedii.
Co je na Bitrixu v Kubernetes připraveno?
Na celém internetu je velmi málo informací o fungování Bitrix aplikací v Kubernetes.
Našel jsem pouze tyto materiály:
Zpráva Alexandra Serbula, 1C-Bitrix a Antona Tuzlukova z Qsoft:
Doporučuji poslechnout.
Vývoj vlastního řešení od uživatele .
Nalezeno více .
Aaa... vlastně, to je vše.
Varuji vás, kvalitu řešení ve výše uvedených odkazech jsme nekontrolovali :)
Mimochodem, při přípravě našeho řešení jsem mluvil s Alexandrem Serbulem, pak se jeho zpráva ještě neobjevila, takže v mých snímcích je položka „Bitrix nepoužívá Kubernetes“.
Ale již existuje spousta hotových obrazů Dockeru pro spuštění Bitrixu v Dockeru:
Stačí to k vytvoření kompletního řešení pro Bitrix v Kubernetes?
Ne. Problémů, které je třeba vyřešit, je velké množství.
Jaké jsou problémy s Bitrixem v Kubernetes?
Za prvé, hotové obrázky z Dockerhubu nejsou vhodné pro Kubernetes
Pokud chceme vybudovat architekturu mikroslužeb (a v Kubernetes to obvykle děláme), musíme naši aplikaci Kubernetes rozdělit do kontejnerů a nechat každý kontejner vykonávat jednu malou funkci (a dělat to dobře). Proč jen jeden? Zkrátka čím jednodušší, tím spolehlivější.
Chcete-li být konkrétnější, podívejte se na tento článek a video:
Obrázky Dockeru v Dockerhubu jsou postaveny hlavně na principu all-in-one, takže jsme si stále museli vyrobit vlastní kolo a dokonce vytvořit obrázky od začátku.
Za druhé - kód webu se upravuje z panelu administrátora
Vytvořili jsme novou sekci na webu - byl aktualizován kód (byl přidán adresář s názvem nové sekce).
Pokud jste změnili vlastnosti komponenty z panelu správce, kód se změnil.
Kubernetes s tím „ve výchozím nastavení“ nemůže pracovat; kontejnery musí být bezstavové.
Důvod: Každý kontejner (pod) v clusteru zpracovává pouze část provozu. Pokud změníte kód pouze v jednom kontejneru (podu), pak se kód bude v různých podech lišit, web bude fungovat jinak a různé verze webu se budou zobrazovat různým uživatelům. Takhle se žít nedá.
Za třetí - musíte vyřešit problém s nasazením
Pokud máme monolit a jeden „klasický“ server, je vše docela jednoduché: nasadíme novou kódovou základnu, migrujeme databázi, přepneme provoz na novou verzi kódu. Přepínání probíhá okamžitě.
Pokud máme web v Kubernetes, rozřezaný na mikroslužby, je tam spousta kontejnerů s kódem – ach. Je třeba shromáždit kontejnery s novou verzí kódu, zavést je místo starých, správně migrovat databázi a ideálně to udělat bez povšimnutí návštěvníků. Naštěstí nám s tím pomáhá Kubernetes, který podporuje celou řadu různých typů nasazení.
Za čtvrté - musíte vyřešit otázku ukládání statiky
Pokud má váš web „pouhých“ 10 gigabajtů a nasadíte jej výhradně v kontejnerech, skončíte s kontejnery o velikosti 10 gigabajtů, jejichž nasazení trvá věčnost.
„Nejtěžší“ části webu potřebujete skladovat mimo kontejnery a vyvstává otázka, jak to udělat správně
Co v našem řešení chybí?
Celý kód Bitrix není rozdělen na mikrofunkce/mikroslužby (aby byla samostatná registrace, samostatný modul internetového obchodu atd.). V každém kontejneru uložíme celou základnu kódu.
Databázi také neukládáme do Kubernetes (pořád jsem implementoval řešení s databází v Kubernetes pro vývojová prostředí, ale ne pro produkci).
Správci webu si stále všimnou, že web běží na Kubernetes. Funkce „kontrola systému“ nefunguje správně, pro úpravu kódu webu z administračního panelu musíte nejprve kliknout na tlačítko „Chci upravit kód“.
Problémy byly identifikovány, potřeba implementace mikroslužeb stanovena, cíl je jasný – získat fungující systém pro běh aplikací na Bitrixu v Kubernetes se zachováním jak možností Bitrixu, tak výhod Kubernetes. Začněme implementací.
architektura
Existuje mnoho „pracovních“ modulů s webovým serverem (pracovníky).
Jeden pod s úlohami cron (vyžaduje se pouze jeden).
Jeden upgrade pro úpravu kódu webu z panelu administrátora (je také vyžadován pouze jeden).
Řešíme otázky:
- Kam ukládat relace?
- Kam uložit cache?
- Kam uložit statiku, neumisťovat gigabajty statiky do hromady kontejnerů?
- Jak bude databáze fungovat?
Obrázek dockeru
Začneme vytvořením obrazu Dockeru.
Ideální variantou je, že máme jeden univerzální obrázek, na jehož základě získáme worker pody, pody s Crontasky a upgradovací pody.
.
Zahrnuje nginx, apache/php-fpm (lze vybrat během sestavování), msmtp pro odesílání pošty a cron.
Při sestavování obrázku se celý kódový základ webu zkopíruje do adresáře /app (s výjimkou těch částí, které přesuneme do samostatného sdíleného úložiště).
Mikroslužby, služby
pracovní moduly:
- Kontejner s nginx + kontejner apache/php-fpm + msmtp
- Přesunutí msmtp do samostatné mikroslužby nevyšlo, Bitrix začíná být rozhořčen, že nemůže posílat poštu přímo
- Každý kontejner má kompletní kódovou základnu.
- Zákaz změny kódu v kontejnerech.
cron pod:
- kontejner s apache, php, cron
- včetně kompletní kódové základny
- zákaz změny kódu v kontejnerech
upgrade pod:
- kontejner nginx + kontejner apache/php-fpm + msmtp
- Neexistuje žádný zákaz změny kódu v kontejnerech
úložiště relace
Bitrix cache úložiště
Další důležitá věc: hesla pro připojení ke všemu, od databáze po poštu, ukládáme do tajů kubernetes. Získáváme bonus: hesla jsou viditelná pouze pro ty, kterým dáváme přístup k tajemstvím, a ne pro každého, kdo má přístup ke kódové základně projektu.
Úložný prostor pro statiku
Můžete použít cokoli: ceph, nfs (ale nedoporučujeme nfs pro produkci), síťové úložiště od poskytovatelů cloudu atd.
Úložiště bude muset být připojeno v kontejnerech k adresáři /upload/ webu a dalším adresářům se statickým obsahem.
Databáze
Pro jednoduchost doporučujeme přesunout databázi mimo Kubernetes. Základ v Kubernetes je samostatný komplexní úkol, díky tomu bude schéma o řád složitější.
Úložiště relace
Používáme memcached :)
Dobře zachází s úložištěm relací, je klastrovaný a je podporován „nativně“ jako session.save_path v php. Takový systém byl mnohokrát testován v klasické monolitické architektuře, kdy jsme stavěli clustery s velkým počtem webových serverů. Pro nasazení používáme přilbu.
$ helm install stable/memcached --name sessionphp.ini - zde obrázek obsahuje nastavení pro ukládání relací v memcached
Pro předávání dat o hostitelích s memcached jsme použili proměnné prostředí .
To vám umožňuje používat stejný kód v prostředích dev, stage, test, prod (názvy hostitelů memcached v nich se budou lišit, takže musíme každému prostředí předat jedinečný název hostitele pro relace).
Bitrix cache úložiště
Potřebujeme úložiště odolné proti chybám, do kterého mohou zapisovat a číst všechny moduly.
Používáme také memcached.
Toto řešení doporučuje samotný Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - zde v Bitrixu je specifikováno, kde je uložena cache
Používáme také proměnné prostředí.
Krontaski
Existují různé přístupy ke spuštění Crontasks v Kubernetes.
- samostatné nasazení s modulem pro spouštění Crontasks
- cronjob pro spouštění crontasks (pokud se jedná o webovou aplikaci - s wget nebo kubectl exec uvnitř jednoho z pracovních modulů atd.)
- atd.
Můžete polemizovat o tom nejsprávnějším, ale v tomto případě jsme zvolili možnost „samostatné nasazení s pody pro Crontasky“
Jak se to dělá:
- přidat úlohy cron přes ConfigMap nebo přes soubor config/addcron
- v jedné instanci spustíme kontejner identický s worker podem + umožníme v něm provádění korunových úloh
- je použit stejný základ kódu, díky sjednocení je montáž kontejneru jednoduchá
Co dobrého získáme:
- máme pracovní Crontasky v prostředí identickém s prostředím vývojářů (docker)
- Crontasky není třeba „přepisovat“ pro Kubernetes, fungují ve stejné podobě a ve stejné základně kódu jako dříve
- Úlohy cron mohou přidávat všichni členové týmu s právy k odevzdání do produkční větve, nejen správci
Modul Southbridge K8SDeploy a úpravy kódu z panelu administrátora
Mluvili jsme o upgradu pod?
Jak tam nasměrovat provoz?
Hurá, napsali jsme na to modul v PHP :) Toto je malý klasický modul pro Bitrix. Zatím není veřejně přístupná, ale plánujeme ji otevřít.
Modul se instaluje jako běžný modul v Bitrix:
A vypadá to takto:
Umožňuje vám nastavit soubor cookie, který identifikuje správce webu a umožňuje Kubernetes posílat provoz do upgradu.
Když jsou změny dokončeny, musíte kliknout na git push, změny kódu budou odeslány do git, poté systém vytvoří obrázek s novou verzí kódu a „rozbalí“ jej napříč clusterem a nahradí staré moduly. .
Ano, je to trochu berlička, ale zároveň zachováváme architekturu mikroslužeb a nebereme uživatelům Bitrixu jejich oblíbenou příležitost opravit kód z panelu administrátora. Nakonec je to možnost, problém s úpravou kódu můžete vyřešit jiným způsobem.
Tabulka kormidla
K vytváření aplikací na Kubernetes obvykle používáme správce balíčků Helm.
Pro naše řešení Bitrix v Kubernetes napsal Sergey Bondarev, náš přední správce systému, speciální Helmův diagram.
Vytváří worker, upgrade, cron pody, konfiguruje vstupy, služby a přenáší proměnné z tajných klíčů Kubernetes do podů.
Kód ukládáme v Gitlabu a také spouštíme sestavení Helm z Gitlabu.
Zkrátka to vypadá 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 také umožňuje provést „plynulý“ návrat, pokud se během nasazení náhle něco pokazí. Je hezké, když nejste v panice „opravte kód přes ftp, protože produkt spadl“, ale Kubernetes to dělá automaticky a bez prostojů.
Nasadit
Ano, jsme fanoušky Gitlab & Gitlab CI, používáme je :)
Při odevzdání v Gitlabu do úložiště projektu Gitlab spustí kanál, který nasadí novou verzi prostředí.
Etapy:
- build (vytvoření nového obrazu Dockeru)
- test (testování)
- vyčištění (odstranění testovacího prostředí)
- push (odešleme do registru Docker)
- deploy (aplikaci nasazujeme do Kubernetes přes Helm).
Hurá, je to připraveno, pojďme to implementovat!
No, nebo se zeptejte, pokud nějaké existují.
Tak co jsme udělali
Z technického hlediska:
- ukotvený Bitrix;
- „rozřezat“ Bitrix do kontejnerů, z nichž každý vykonává minimum funkcí;
- dosažený bezstavový stav kontejnerů;
- vyřešil problém s aktualizací Bitrixu v Kubernetes;
- všechny funkce Bitrixu nadále fungovaly (téměř všechny);
- Pracovali jsme na nasazení do Kubernetes a rollbacku mezi verzemi.
Z obchodního hlediska:
- odolnost proti chybám;
- Nástroje Kubernetes (snadná integrace s Gitlab CI, bezproblémové nasazení atd.);
- tajná hesla (viditelná pouze pro ty, kterým je přímo udělen přístup k heslům);
- Je vhodné vytvářet další prostředí (pro vývoj, testy atd.) v rámci jediné infrastruktury.
Zdroj: www.habr.com