V Čeljabinsku probíhají meetupy systémových administrátorů Sysadminka, a na posledním z nich jsem měl přednášku o našem řešení pro provoz aplikací na 1C-Bitrix v Kubernetes.
Bitrix, Kubernetes, Ceph — skvělá kombinace?
Povím vám, jak jsme z toho všeho sestavili funkční řešení.
Začínáme!
Meetup proběhl 18. dubna v Čeljabinsku. O našich meetupech si můžete přečíst na a podívat se na .
Pokud chcete přijít k nám s přednáškou nebo jako posluchač — vítejte, pište na vadim.isakanov@gmail.com a na Telegram t.me/vadimisakanov.
Moje přednáška
Řešení „Bitrix v Kubernetes, verze Southbridge 1.0“
Povím o našem řešení ve formátu „pro začátečníky v Kubernetes“, jak to bylo prezentováno na meetupu. Ale předpokládám, že slova Bitrix, Docker, Kubernetes, Ceph vám jsou známá alespoň na úrovni článků na Wikipedii.
Jaké informace jsou k dispozici o Bitrix v Kubernetes?
Na celém internetu je velmi málo informací o provozu aplikací na Bitrix v Kubernetes.
Našel jsem jen takové materiály:
Přednáška Alexandra Serbula, 1C-Bitrix, a Antona Tuzlukova z Qsoft:
Doporučuji ji poslechnout.
Vývoj vlastního řešení od uživatele .
Našel jsem také .
A…. vlastně, to je všechno.
Varuji, kvalitu práce řešení na výše uvedených odkazech jsme nezkoušeli 🙂
Mimochodem, při přípravě našeho řešení jsem mluvil s Alexandrem Serbulou, jehož přednáška ještě nebyla, a proto mám v mých prezentacích bod „Bitrix nepoužívá Kubernetes“.
Ale hotových Docker obrazů pro práci Bitrix v Dockeru už je hodně:
Je toho dost pro vytvoření plnohodnotného řešení pro Bitrix v Kubernetes?
Ne. Existuje mnoho problémů, které je třeba vyřešit.
Jaké jsou problémy s Bitrix v Kubernetes?
První — hotové obrazy z Dockerhubu nejsou vhodné pro Kubernetes.
Pokud chceme postavit mikroslužbovou architekturu (a v Kubernetes obvykle chceme), je třeba aplikaci v Kubernetes rozdělit na kontejnery a zajistit, aby každý kontejner vykonával jednu malou funkci (a dělalo to dobře). Proč jen jednu? Ve zkratce — čím jednodušší, tím spolehlivější.
Pokud podrobněji — prosím, podívejte se na tento článek a video:
Docker obrazy na Dockerhubu jsou většinou postaveny na principu „vše v jednom“, takže jsme museli nakonec vytvořit naše vlastní kolo a dokonce obrazy vytvořit od začátku.
Druhá — kód webu se opravuje z administrativního panelu.
Vytvořili jsme novou sekci na webu — kód se aktualizoval (přidala se složka s názvem nové sekce).
Změnili jsme vlastnosti komponenty z administrátorského panelu — kód se změnil.
Kubernetes „ve výchozím nastavení“ s tímto nepracuje, kontejnery musí být neměnné (Stateless).
Důvod: každý kontejner (pod) v klastru zpracovává pouze část provozu. Pokud změníte kód pouze v jednom kontejneru (podu), bude kód v různých podech různý, web bude fungovat různě, různým uživatelům budou zobrazeny různé verze webu. Takto se nedá žít.
Třetí — je potřeba řešit otázku nasazení.
Pokud máme monolit a jeden „klasický“ server, je to úplně jednoduché: nasadíme novou kódovou základnu, provedeme migraci databáze, přepneme provoz na novou verzi kódu. Přepnutí probíhá okamžitě.
Pokud máme web v Kubernetes, rozdělený na mikroslužby, s mnoha kontejnery s kódem — ach. Musíme sestavit kontejnery s novou verzí kódu, nasadit je místo starých, správně provést migraci databáze, a ideálně to provést nepozorovaně pro návštěvníky. Naštěstí nám v tom Kubernetes pomáhá, podporuje celou řadu různých typů nasazení.
Čtvrté — je potřeba řešit otázku ukládání statického obsahu.
Pokud váš web váží „jen“ 10 gigabajtů a nasadíte ho celý v kontejnerech, dostanete kontejnery o hmotnosti 10 gigabajtů, které se budou nasazovat věčnost.
Je potřeba ukládat nej "těžší" části webu mimo kontejnery, a vznáší se otázka, jak to správně udělat.
Co v našem řešení není.
Celý kód Bitrix není rozdělen na mikrofunkce/mikroslužby (tak, aby registrace byla odděleně, modul internetového obchodu odděleně atd.). Celou kódovou základnu ukládáme v každém kontejneru v celku.
Databázi v Kubernetes také neuchováváme (přesto jsem realizoval řešení s databází v Kubernetes pro vývojová prostředí, ale ne pro produkci).
Administrátorům webu bude přesto znatelné, že web funguje v Kubernetes. Funkce „ověření systému“ nefunguje správně, pro úpravu kódu webu z administrátorského panelu je potřeba nejprve stisknout tlačítko „chci upravit kód“.
Problémy jsme vyřešili, potřebnost implementace mikroslužeb jsme vyjasnili, cíl je jasný – získat funkční systém pro aplikace na Bitrixu běžící v Kubernetes, přičemž zachováme výhody jak Bitrixu, tak Kubernetes. Začínáme s realizací.
Architektura
Více „pracovních“ podů s webovým serverem (pracovníci).
Jeden pod s cron úlohami (nutně pouze jeden).
Jeden upgrade pod pro úpravu kódu webu z administračního panelu (také nutně pouze jeden).
Řešíme otázky:
- Kde uchovávat relace?
- Kde uchovávat cache?
- Kde uchovávat statické soubory, nemůžeme přeci mít gigabajty statiky v hromadě kontejnerů?
- Jak bude fungovat databáze?
Docker obraz
Začínáme se sestavením Docker obrazu.
Ideální variantou je mít jeden univerzální obraz, na jehož bázi získáme jak worker pody, tak pody s cron úlohami a upgrade pody.
.
Obsahuje nginx, apache/php-fpm (lze vybrat při sestavení), msmtp pro odesílání e-mailů a cron.
Při sestavení obrazu se do adresáře /app zkopíruje kompletní kódová základna webu (vyjma částí, které přesuneme do samostatného sdíleného úložiště).
Mikroslužby, služby
worker pody:
- Kontejner s nginx + kontejner apache/php-fpm + msmtp
- msmtp se nepodařilo přesunout do samostatné mikroslužby, Bitrix začíná protestovat, že nemůže posílat e-maily přímo.
- V každém kontejneru je kompletní kódová základna.
- Zákaz úpravy kódu v kontejnerech.
cron pod:
- kontejner s apache, php, cron
- součástí je kompletní kódová základna
- zákaz úpravy kódu v kontejnerech
upgrade pod:
- kontejner s nginx + kontejner apache/php-fpm + msmtp
- na zákazy úpravy kódu v kontejnerech se nevztahují
úložiště relací
úložiště cache pro Bitrix
Je také důležité: hesla pro připojení ke všemu, od databáze po e-mail, uchováváme v Kubernetes secrets. Získáváme tak bonus, hesla jsou viditelná pouze těm, kterým dáváme přístup k tajemstvím, a ne všem, kdo mají přístup ke kódové základně projektu.
Úložiště pro statiku
Můžete použít cokoliv: ceph, nfs (ale nfs nedoporučujeme pro produkční prostředí), síťové úložiště od 'cloud' poskytovatelů, atd.
Úložiště bude třeba připojit v kontejnerech do adresáře /upload/ webu a dalších adresářů se statikou.
Databáze
Pro jednoduchost doporučujeme vyvést databázi mimo Kubernetes. Databáze v Kubernetes je samostatný složitý úkol, který schéma výrazně zkomplikuje.
Úložiště relací
Používáme memcached 🙂
Dobrý den, dobře se stará o ukládání sezení, je škálovatelný a je 'nativně' podporován jako session.save_path v php. Takový systém byl mnohokrát vyzkoušen již v klasické monolitické architektuře, kdy jsme stavěli clustery s velkým počtem webových serverů. Pro nasazení používáme helm.
$ helm install stable/memcached --name sessionphp.ini - zde jsou v obrazu nastavena nastavení pro ukládání sezení do memcached
Použili jsme Environment Variables pro předání údajů o hostitelích s memcached .
To umožňuje použít stejný kód ve vývojových, stagingových, testovacích a produkčních prostředích (jména hostitelů memcached se budou lišit, takže do každého prostředí musíme předat unikátní jména hostitelů pro sezení).
Úložiště cache Bitrix
Potřebujeme odolné úložiště, do kterého mohou zapisovat všechny pody a číst z něj.
Také používáme memcached.
Toto řešení doporučuje samotný Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - zde v Bitrix je určeno, kde máme uloženou cache
Také používáme Environment Variables.
Cron úlohy
Existují různé přístupy k provádění cron úloh v Kubernetes.
- samostatné nasazení s podem pro provádění cron úloh
- cronjob pro provádění cron úloh (pokud je to webová aplikace - s wget , nebo kubectl exec uvnitř jednoho z pracovníků podů atd.)
- atd.
O nejlepším přístupu lze diskutovat, ale v tomto případě jsme zvolili variantu 'samostatné nasazení s pody pro cron úlohy'
Jak to funguje:
- cron úlohy přidáváme přes ConfigMap nebo skrze soubor config/addcron
- v jednom exempláři spustíme kontejner identický s pracovním pod’em + povolíme provádění cron úloh v něm
- používá se stejná kódová báze, díky unifikaci je sestavení kontejneru jednoduché
Co dobrého získáváme:
- máme funkční cron úlohy v prostředí, které je identické s prostředím vývojářů (docker)
- cron úlohy nemusí být 'přepisovány' pro Kubernetes, fungují ve stejném formátu a se stejnou kódovou bází jako dříve
- cron úlohy mohou přidávat všichni členové týmu s právem commit do produkční větve, nejen administrátoři
Modul Southbridge K8SDeploy a úprava kódu z administračního panelu
Vždyť jsme mluvili o upgradu podu?
A jak směrovat provoz tam?
Hurá, napsali jsme pro to modul na php 🙂 Je to malý klasický modul pro Bitrix. Ještě není veřejně dostupný, ale plánujeme ho zveřejnit.
Modul se instaluje jako běžný modul v Bitrix:
A vypadá takto:
Umožňuje nastavit cookie, která identifikuje správce webu, a umožňuje Kubernetes směrovat provoz na upgrade pod.
Po dokončení změn je třeba stisknout git push, změny kódu budou odeslány do git, poté systém sestaví obraz s novou verzí kódu a "rozesílá" ji po clusteru, a nahradí staré pody.
Ano, je to trochu kaskádovitě, ale zachováváme mikroservisní architekturu a nepřicházíme o oblíbenou možnost uživatelů Bitrixu upravit kód z administrace. Nakonec je to volba, úpravu kódu lze vyřešit jinak.
Helm chart
Pro sestavení aplikací v Kubernetes obvykle používáme správce balíčků Helm.
Pro naše řešení Bitrix v Kubernetes napsal Sergey Bondarev, náš vedoucí systémový administrátor, speciální Helm chart.
Provádí sestavení worker, upgrade, cron podů, nastavuje ingressy, služby a předává proměnné z Kubernetes secrets do podů.
Kód uchováváme v Gitlabu a sestavení Helm také spouštíme z Gitlabu.
Pokud stručně, vypadá to takto
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm také umožňuje provést "bezproblémový" rollback, pokud při nasazení došlo k nějakému problému. Je příjemné, když nemusíte panikařit a "opravovat kód přes FTP, protože produkce spadla", ale Kubernetes to dělá automaticky, a to bez prostoje.
Nasazení
Ano, jsme fanoušci Gitlab & Gitlab CI, používáme ho 🙂
Při commitu do Gitlabu do repozitáře projektu Gitlab spustí pipeline, která provede nasazení nové verze prostředí.
Etapy:
- build (sestavujeme nový Docker obraz)
- test (testujeme)
- clean up (odstraňujeme testovací prostředí)
- push (odesíláme ho do Docker registry)
- deploy (nasazujeme aplikaci v Kubernetes přes Helm).
Hurá, hotovo, implementujeme!
Nebo se ptáme, pokud nějaké jsou.
Tak co jsme udělali?
Z technického hlediska:
- dockerizovali Bitrix;
- "rozdělili" Bitrix na kontejnery, každý z nich vykonává minimální funkce;
- dosáhli stateless stavu kontejnerů;
- vyřešili problém s aktualizací Bitrixu v Kubernetes;
- všechny funkce Bitrixu fungují dál (téměř všechny);
- provedli nasazení v Kubernetes a rollback mezi verzemi.
Z hlediska podnikání:
- odolnost vůči chybám;
- nástroje Kubernetes (jednoduchá integrace s Gitlab CI, bezproblémové nasazení atd.);
- hesla v tajných údajích (vidí je jen ti, kteří mají přímý přístup k heslům);
- je pohodlné vytvořit další prostředí (pro vývoj, testy atd.) v rámci jediné infrastruktury.
Zdroj: habr.com
