My ve společnosti True Engineering jsme nastavili proces pro nepřetržité doručování aktualizací na zákaznické servery a chceme se o tuto zkušenost podělit.
Nejprve jsme pro zákazníka vyvinuli online systém a nasadili jej v našem vlastním clusteru Kubernetes. Nyní se naše vysoce zátěžové řešení přesunulo na zákaznickou platformu, pro kterou jsme nastavili plně automatický proces kontinuálního nasazení. Díky tomu jsme zrychlili time-to-market – dodání změn do produktového prostředí.
V tomto článku budeme hovořit o všech fázích procesu Continuous Deployment (CD) nebo dodání aktualizací na platformu zákazníka:
- Jak tento proces začíná?
- synchronizace s Git repozitářem zákazníka,
- montáž backendu a frontendu,
- automatické nasazení aplikací v testovacím prostředí,
- automatické nasazení do Prod.
Podrobnosti o nastavení budeme sdílet během cesty.
1. Spusťte CD
Nepřetržité nasazení začíná tím, že vývojář zatlačí změny do větve vydání našeho úložiště Git.
Naše aplikace běží na mikroservisní architektuře a všechny její součásti jsou uloženy v jednom úložišti. Díky tomu se shromažďují a instalují všechny mikroslužby, i když se jedna z nich změnila.
Uspořádali jsme práci prostřednictvím jednoho úložiště z několika důvodů:
- Snadný vývoj – aplikace se aktivně vyvíjí, takže můžete pracovat s veškerým kódem najednou.
- Jediný kanál CI/CD, který zaručuje, že aplikace jako jediný systém projde všemi testy a bude doručena do produkčního prostředí zákazníka.
- Odstraňujeme zmatky ve verzích – nemusíme ukládat mapu verzí mikroslužby a popisovat její konfiguraci pro každou mikroslužbu ve skriptech Helm.
2. Synchronizace zdrojového kódu zákazníka s úložištěm Git
Provedené změny se automaticky synchronizují s úložištěm Git zákazníka. Tam se konfiguruje sestavení aplikace, které se spouští po aktualizaci větve a nasazení do pokračování. Oba procesy pocházejí ze svého prostředí z úložiště Git.
Nemůžeme pracovat přímo s úložištěm zákazníka, protože potřebujeme vlastní prostředí pro vývoj a testování. K těmto účelům používáme naše úložiště Git – je synchronizované s jejich úložištěm Git. Jakmile vývojář odešle změny do příslušné větve našeho úložiště, GitLab tyto změny okamžitě zašle zákazníkovi.
Poté musíte provést montáž. Skládá se z několika fází: backend a frontend montáž, testování a dodání do výroby.
3. Sestavení backendu a frontendu
Sestavení backendu a frontendu jsou dvě paralelní úlohy, které se provádějí v systému GitLab Runner. Jeho původní konfigurace sestavy je umístěna ve stejném úložišti.
.
GitLab Runner vezme kód z požadovaného úložiště, sestaví jej pomocí příkazu Java application build a odešle do registru Docker. Zde sestavujeme backend a frontend, získáváme obrazy Dockeru, které ukládáme do úložiště na straně zákazníka. Ke správě obrázků Docker používáme .
Verze našich obrázků synchronizujeme s verzí, která bude publikována v Dockeru. Pro bezproblémový provoz jsme provedli několik úprav:
1. Kontejnery se mezi testovacím prostředím a produkčním prostředím nepřestavují. Udělali jsme parametrizace tak, aby stejný kontejner mohl pracovat se všemi nastaveními, proměnnými prostředí a službami jak v testovacím prostředí, tak v produkčním prostředí bez přestavby.
2. Chcete-li aktualizovat aplikaci pomocí Helm, musíte zadat její verzi. Stavíme backend, frontend a aktualizujeme aplikaci – to jsou tři různé úkoly, proto je důležité všude používat stejnou verzi aplikace. Pro tento úkol používáme data z historie Git, protože naše konfigurace clusteru K8S a aplikace jsou ve stejném úložišti Git.
Verzi aplikace získáme z výsledků provádění příkazu
git describe --tags --abbrev=7.
4. Automatické nasazení všech změn do testovacího prostředí (UAT)
Dalším krokem v tomto sestavení skriptu je automatická aktualizace clusteru K8S. K tomu dochází za předpokladu, že byla vytvořena celá aplikace a všechny artefakty byly publikovány do registru Docker. Poté se spustí aktualizace testovacího prostředí.
Aktualizace clusteru se spouští pomocí . Pokud v důsledku toho něco nejde podle plánu, Helm automaticky a nezávisle vrátí všechny své změny zpět. Jeho práci není třeba kontrolovat.
Klastrovou konfiguraci K8S dodáváme spolu s montáží. Dalším krokem je tedy jeho aktualizace: configMaps, nasazení, služby, tajemství a jakékoli další konfigurace K8S, které jsme změnili.
Helm poté spustí RollOut aktualizaci samotné aplikace v testovacím prostředí. Před nasazením aplikace do produkce. To se provádí tak, aby uživatelé mohli ručně testovat obchodní funkce, které jsme vložili do testovacího prostředí.
5. Automatické nasazení všech změn do Prod
K nasazení aktualizace do produkčního prostředí stačí kliknout na jedno tlačítko v GitLabu – a kontejnery jsou okamžitě doručeny do produkčního prostředí.
Stejná aplikace může fungovat v různých prostředích – testovacích a produkčních – bez přestavby. Používáme stejné artefakty, aniž bychom v aplikaci cokoliv měnili, a parametry nastavujeme externě.
Flexibilní parametrizace nastavení aplikace závisí na prostředí, ve kterém bude aplikace spouštěna. Veškerá nastavení prostředí jsme přesunuli externě: vše je parametrizováno přes konfiguraci K8S a parametry Helm. Když Helm nasadí sestavení do testovacího prostředí, použijí se na něj testovací nastavení a nastavení produktu se použijí na produkční prostředí.
Nejobtížnější bylo parametrizovat všechny používané služby a proměnné, které závisí na prostředí, a převést je do proměnných prostředí a popis-konfigurací parametrů prostředí pro Helm.
Nastavení aplikace používá proměnné prostředí. Jejich hodnoty se nastavují v kontejnerech pomocí konfigurační mapy K8S, která je šablonována pomocí šablon Go. Například nastavení proměnné prostředí na název domény lze provést takto:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – tato proměnná ukládá název prostředí (prod, stage, UAT).
.Values.app.properties.app_external_domain – v této proměnné nastavíme požadovanou doménu v souboru .Values.yaml
Při aktualizaci aplikace Helm vytvoří soubor configmap.yaml ze šablon a naplní hodnotu APP_EXTERNAL_DOMAIN požadovanou hodnotou v závislosti na prostředí, ve kterém se aktualizace aplikace spouští. Tato proměnná je již nastavena v kontejneru. Lze k ní přistupovat z aplikace, takže každé prostředí aplikace bude mít pro tuto proměnnou jinou hodnotu.
Relativně nedávno se v Spring Cloudu objevila podpora K8S, včetně práce s configMaps: . Zatímco se projekt aktivně vyvíjí a radikálně mění, nemůžeme jej použít ve výrobě. Ale aktivně sledujeme jeho stav a používáme ho v konfiguracích DEV. Jakmile se stabilizuje, přejdeme z používání proměnných prostředí na něj.
Celkem
Průběžné nasazení je tedy nakonfigurováno a funguje. Všechny aktualizace probíhají jedním stisknutím klávesy. Doručování změn do prostředí produktu je automatické. A co je důležité, aktualizace nezastaví systém.
Plány do budoucna: automatická migrace databáze
Přemýšleli jsme o upgradu databáze a možnosti vrátit tyto změny zpět. Koneckonců, současně běží dvě různé verze aplikace: stará běží a nová běží. A starou vypneme, až když jsme si jisti, že nová verze funguje. Migrace databáze by vám měla umožnit pracovat s oběma verzemi aplikace.
Nemůžeme tedy jednoduše změnit název sloupce nebo jiné údaje. Můžeme ale vytvořit nový sloupec, zkopírovat do něj data ze starého sloupce a napsat triggery, které je při aktualizaci dat současně zkopírují a aktualizují v jiném sloupci. A po úspěšném nasazení nové verze aplikace, po období podpory po spuštění, budeme moci smazat starý sloupec a spouštěč, který se stal nepotřebným.
Pokud nová verze aplikace nefunguje správně, můžeme se vrátit k předchozí verzi včetně předchozí verze databáze. Stručně řečeno, naše změny vám umožní pracovat současně s několika verzemi aplikace.
Plánujeme automatizovat migraci databáze prostřednictvím úlohy K8S a integrovat ji do procesu CD. A o tento zážitek se na Habrého určitě podělíme.
Zdroj: www.habr.com