Kontejnerizace monolitických aplikací

Návod

Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.

Stáhnout PDF

Můžete chtít vytvořit jednu monolitickou webovou aplikaci nebo službu a nasadit ji jako kontejner. Samotná aplikace nemusí být interně monolitická, ale strukturovaná jako několik knihoven, komponent nebo dokonce vrstev (aplikační vrstva, vrstva domény, vrstva přístupu k datům atd.). Externě se jedná o jeden kontejner – jeden proces, jednu webovou aplikaci nebo jednu službu.

Pokud chcete tento model spravovat, nasadíte jeden kontejner, který bude představovat aplikaci. Pro zvýšení kapacity rozšiřte systém, to znamená, že stačí přidat další kopie a umístit před ně nástroj pro vyrovnávání zatížení. Jednoduchost spočívá ve správě jednoho nasazení v jednom kontejneru nebo virtuálním počítači.

Obrázek 4–1 Příklad architektury kontejnerizované monolitické aplikace

Do každého kontejneru můžete zahrnout více komponent, knihoven nebo interních vrstev, jak je znázorněno na obrázku 4-1. Monolitická kontejnerizovaná aplikace má většinu funkcí v rámci jednoho kontejneru s interními vrstvami nebo knihovnami a škáluje kapacitu klonováním kontejneru na více serverech nebo virtuálních počítačích. Tento monolitický vzor však může být v konfliktu s principem kontejneru "kontejner dělá jednu věc a dělá to v jednom procesu", ale v některých případech může být v pořádku.

Nevýhodou tohoto přístupu se stává zřejmá, pokud aplikace roste, což vyžaduje její škálování. Pokud se celá aplikace může škálovat, není to ve skutečnosti problém. Ve většině případů je však jen několik částí aplikace úzkými místy, která vyžadují škálování, zatímco jiné komponenty se používají méně.

Například v typické aplikaci elektronického obchodování budete pravděpodobně muset škálovat subsystém informací o produktu, protože mnoho dalších zákazníků prochází produkty, než si je kupují. Více zákazníků používá svůj košík, než používá platební kanál. Méně zákazníků přidává komentáře nebo zobrazuje historii nákupů. A možná máte jenom několik zaměstnanců, kteří potřebují spravovat obsah a marketingové kampaně. Pokud škálujete monolitický návrh, všechny kódy pro tyto různé úlohy se nasadí vícekrát a škálují se na stejné úrovni.

Existuje několik způsobů škálování duplikace horizontální aplikace, rozdělení různých oblastí aplikace a dělení podobných obchodních konceptů nebo dat. Kromě problému se škálováním všech komponent ale změny jedné komponenty vyžadují úplné opětovné testování celé aplikace a úplné opětovné nasazení všech instancí.

Monolitický přístup je ale běžný, protože vývoj aplikace je zpočátku jednodušší než u přístupů k mikroslužbám. Mnoho organizací proto vyvíjí tento přístup k architektuře. I když některé organizace měly dostatek výsledků, jiné dosahují limitů. Mnoho organizací navrhlo své aplikace pomocí tohoto modelu, protože nástroje a infrastruktura ztěžovaly sestavování architektur orientovaných na služby (SOA) před lety a neviděly potřebu, dokud aplikace nevyroste.

Z hlediska infrastruktury může každý server spouštět mnoho aplikací v rámci stejného hostitele a má přijatelný poměr efektivity využití prostředků, jak je znázorněno na obrázku 4–2.

Obrázek 4–2 Monolitický přístup: Hostování s více aplikacemi, každá aplikace spuštěná jako kontejner

Monolitické aplikace v Microsoft Azure je možné nasadit pomocí vyhrazených virtuálních počítačů pro každou instanci. Kromě toho můžete pomocí škálovacích sad virtuálních počítačů Azure snadno škálovat virtuální počítače. Azure App Service může také spouštět monolitické aplikace a snadno škálovat instance, aniž byste museli spravovat virtuální počítače. Od roku 2016 může Azure App Services spouštět také izolované instance kontejnerů Dockeru, což zjednodušuje nasazení.

Jako prostředí pro kontrolu kvality nebo omezené produkční prostředí můžete nasadit několik hostitelských virtuálních počítačů Dockeru a vyvážit je pomocí nástroje pro vyrovnávání výkonu Azure, jak je znázorněno na obrázku 4–3. Díky tomu můžete spravovat škálování pomocí hrubého přístupu, protože celá aplikace se nachází v jednom kontejneru.

Obrázek 4–3 Příklad vertikálního navýšení kapacity jedné aplikace typu kontejner na více hostitelů

Nasazení na různé hostitele je možné spravovat pomocí tradičních technik nasazení. Hostitele Dockeru je možné spravovat pomocí příkazů, které lze provádět ručně, nebo prostřednictvím automatizace, jako jsou kanály CI/CD.

Nasazení monolitické aplikace jako kontejneru

Používání kontejnerů k řízení nasazení monolitických aplikací přináší výhody. Škálování instancí kontejnerů je mnohem rychlejší a jednodušší než nasazení dalších virtuálních počítačů. I když používáte škálovací sady virtuálních počítačů, spuštění virtuálních počítačů chvíli trvá. Při nasazení jako tradiční instance aplikace místo kontejnerů se konfigurace aplikace spravuje jako součást virtuálního počítače, což není ideální.

Nasazování aktualizací s využitím imagí Dockeru je mnohem rychlejší a efektivní v síti. Image Dockeru se obvykle spouštějí v sekundách, což urychluje zavádění. Odstranění instance image Dockeru je stejně snadné jako vydání docker stop příkazu a obvykle se dokončí za méně než sekundu.

Vzhledem k tomu, že kontejnery jsou neměnné podle návrhu, nemusíte se starat o poškozené virtuální počítače. Naproti tomu aktualizační skripty pro virtuální počítač můžou zapomenout počítat s určitou konfigurací nebo souborem, které zůstaly na disku.

I když monolitické aplikace mohou těžit z Dockeru, dotkneme se jen výhod. Další výhody správy kontejnerů pocházejí z nasazení pomocí orchestrátorů kontejnerů, které spravují různé instance a životní cyklus každé instance kontejneru. Rozdělení monolitické aplikace do subsystémů, které je možné škálovat, vyvíjet a nasazovat jednotlivě, je vaším vstupním bodem do sféry mikroslužeb.

Publikování aplikace založené na jednom kontejneru do služby Azure App Service

Bez ohledu na to, jestli chcete získat ověření kontejneru nasazeného do Azure, nebo když je aplikace jednoduše aplikace s jedním kontejnerem, nabízí služba Azure App Service skvělý způsob, jak poskytovat škálovatelné služby založené na jednom kontejneru. Použití služby Azure App Service je jednoduché. Poskytuje skvělou integraci s Git pro snadné převzetí vašeho kódu, jeho sestavení ve Visual Studio a nasazení přímo do Azure.

Obrázek 4–4 Publikování aplikace s jedním kontejnerem do služby Azure App Service ze sady Visual Studio 2022

Pokud jste bez Dockeru potřebovali další funkce, architektury nebo závislosti, které nejsou ve službě Azure App Service podporované, museli jste počkat, dokud tým Azure tyto závislosti ve službě App Service neaktualizuje. Nebo jste museli přejít na jiné služby, jako jsou Azure Cloud Services nebo virtuální počítače, kde jste měli další kontrolu a mohli jste nainstalovat požadovanou komponentu nebo architekturu pro vaši aplikaci.

Podpora kontejnerů v sadě Visual Studio 2017 a novějších verzích umožňuje zahrnout vše, co chcete v prostředí aplikace, jak je znázorněno na obrázku 4–4. Vzhledem k tomu, že ji spouštíte v kontejneru, můžete ji zahrnout do souboru Dockerfile nebo image Dockeru, pokud do aplikace přidáte závislost.

Jak je vidět také na obrázku 4-4, publikační tok odesílá obraz pomocí registru kontejnerů. Může to být Azure Container Registry (registr blízko vašich nasazení v Azure a zabezpečený pomocí skupin a účtů Azure Active Directory) nebo jakéhokoli jiného registru Dockeru, jako je Docker Hub nebo místní registr.

předchozíDalší