Sdílet prostřednictvím


Kontejnerizování monolitických aplikací

Tip

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.

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

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. Pokud chcete zvýšit kapacitu, navyšte kapacitu na více instancí, stačí přidat další kopie s nástrojem pro vyrovnávání zatížení předem. Jednoduchost spočívá ve správě jednoho nasazení v jednom kontejneru nebo virtuálním počítači.

Diagram showing a monolithic containerized application's components.

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 je zřejmé, jestli aplikace roste, což vyžaduje š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 body, 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.

Diagram showing one host running many apps in containers.

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. Aplikace Azure Služba může také spouštět monolitické aplikace a snadno škálovat instance bez nutnosti správy virtuálních počítačů. Od roku 2016 můžou služby Aplikace Azure 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.

Diagram showing several hosts running the monolithic app containers.

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ů, jako jsou docker run příkazy nebo docker-compose provádět ručně, nebo prostřednictvím automatizace, jako jsou kanály průběžného doručování (CD).

Nasazení monolitické aplikace jako kontejneru

Používání kontejnerů ke správě monolitických nasazení 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 Aplikace Azure 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, Aplikace Azure Service poskytuje skvělý způsob, jak poskytovat škálovatelné služby založené na jednom kontejneru. Použití Aplikace Azure Service je jednoduché. Poskytuje skvělou integraci s Gitem, aby byl kód snadný, sestavil ho v sadě Visual Studio a nasadil ho přímo do Azure.

Screenshot of Create App Service dialog showing a Container Registry.

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

Pokud jste bez Dockeru potřebovali další funkce, architektury nebo závislosti, které nejsou ve službě Aplikace Azure Service podporované, museli jste počkat, až tým Azure tyto závislosti ve službě App Service aktualizuje. 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 až 4, tok publikování odešle image prostřednictvím registru kontejneru. 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.