Využití kontejnerů a orchestrátorů

Tip

Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma ke stažení, který si můžete přečíst offline.

Stáhnout PDF

Kontejnery a orchestrátory jsou navržené tak, aby řešily problémy, které jsou běžné pro monolitické přístupy k nasazení.

Problémy s monolitickým nasazením

Tradičně se většina aplikací nasadila jako jedna jednotka. Takové aplikace se označují jako monolitické. Tento obecný přístup nasazení aplikací jako jednotlivých jednotek i v případě, že se skládají z více modulů nebo sestavení, se označuje jako monolitická architektura, jak je znázorněno na obrázku 3-1.

Obrázek 3-1 Monolitická architektura.

Přestože mají výhody jednoduchosti, monolitické architektury čelí mnoha výzvám:

Nasazení

Navíc vyžadují restartování aplikace, které může dočasně ovlivnit dostupnost, pokud se při nasazování nepoužijí techniky nulového výpadku.

Škálování

Monolitická aplikace je hostovaná výhradně na jedné instanci počítače, která často vyžaduje hardware s vysokou schopností. Pokud některá část monolitu vyžaduje škálování, musí být na jiný počítač nasazená další kopie celé aplikace. Pomocí monolitu nemůžete škálovat komponenty aplikace jednotlivě – je to všechno nebo nic. Škálování komponent, které nevyžadují škálování, vede k neefektivnímu a nákladnému využití prostředků.

Prostředí

Monolitické aplikace se obvykle nasazují do hostitelského prostředí s předinstalovaným operačním systémem, modulem runtime a závislostmi knihoven. Toto prostředí nemusí odpovídat tomu, na kterém byla aplikace vyvinuta nebo testována. Nekonzistence napříč aplikačními prostředími jsou běžným zdrojem problémů monolitických nasazení.

Tažné

Monolitická aplikace pravděpodobně bude mít vysoké spojení napříč jeho funkčními komponentami. Bez pevných hranic změny systému často vedou k nezamýšleným a nákladným vedlejším účinkům. Nové funkce/opravy jsou složité, časově náročné a nákladné k implementaci. Aktualizace vyžadují rozsáhlé testování. Spojka také ztěžuje refaktoring komponent nebo prohození v alternativních implementacích. I když je postavena s přísným oddělením obav, architektura eroze se s monolitickým základem kódu zhoršuje s nikdy nekončícími "zvláštními případy".

Uzamčení platformy

Monolitická aplikace je vytvořena s jedním technologickým zásobníkem. I když nabízí jednotnost, může se tento závazek stát překážkou pro inovace. Nové funkce a komponenty budou sestaveny pomocí aktuálního zásobníku aplikace – i když může být lepší volbou modernější technologie. Dlouhodobým rizikem je, že vaše technologická sada přestane být zastaralá a zastaralá. Změna architektury celé aplikace na novou, modernější platformu je cenově nejvýhodnější a riziková.

Jaké jsou výhody kontejnerů a orchestrátorů?

Kontejnery jsme zavedli v kapitole 1. Zdůraznili jsme, jak organizace CLOUD Native Computing Foundation (CNCF) řadí kontejnerizaci jako první krok v mapě tras nativní pro cloud – pokyny pro podniky, které začínají na cestě nativní pro cloud. V této části probereme výhody kontejnerů.

Docker je nejoblíbenější platforma pro správu kontejnerů. Funguje s kontejnery v Linuxu i Ve Windows. Kontejnery poskytují samostatná, ale reprodukovatelná aplikační prostředí, která běží stejným způsobem v jakémkoli systému. Díky tomuto aspektu jsou ideální pro vývoj a hostování služeb nativních pro cloud. Kontejnery jsou navzájem izolované. Dva kontejnery na stejném hostitelském hardwaru můžou mít různé verze softwaru, aniž by to způsobilo konflikty.

Kontejnery jsou definovány jednoduchými textovými soubory, které se stanou artefakty projektu a jsou vráceny do správy zdrojového kódu. Zatímco úplné servery a virtuální počítače vyžadují ruční úsilí k aktualizaci, kontejnery jsou snadno řízeny verzemi. Aplikace vytvořené ke spouštění v kontejnerech je možné vyvíjet, testovat a nasazovat pomocí automatizovaných nástrojů v rámci kanálu buildu.

Kontejnery jsou neměnné. Jakmile definujete kontejner, můžete ho znovu vytvořit a spustit stejným způsobem. Tato neměnnost se hodí k návrhu založenému na komponentách. Pokud se některé části aplikace vyvíjejí jinak než jiné, proč znovu nasadit celou aplikaci, když můžete nasadit jenom ty části, které se mění nejčastěji? Různé funkce a průřezové aspekty aplikace je možné rozdělit do samostatných jednotek. Obrázek 3–2 ukazuje, jak monolitická aplikace může využívat kontejnery a mikroslužby delegováním určitých funkcí nebo funkcí. Zbývající funkce samotné aplikace byly také kontejnerizovány.

Obrázek 3–2 Rozložení monolitické aplikace pro přijetí mikroslužeb

Každá nativní cloudová služba je sestavená a nasazená v samostatném kontejneru. Každý z nich se může podle potřeby aktualizovat. Jednotlivé služby je možné hostovat na uzlech s prostředky vhodnými pro každou službu. Prostředí, ve kterém se každá služba spouští, je neměnné, sdílené napříč vývojovými, testovacími a produkčními prostředími a snadnou verzí. K párování mezi různými oblastmi aplikace dochází explicitně jako volání nebo zprávy mezi službami, nikoli závislosti v době kompilace v rámci monolitické. Můžete také zvolit technologii, která nejlépe nastaví danou funkci, aniž byste museli měnit zbytek aplikace.

Kontejnerizované služby vyžadují automatizovanou správu. Není možné ručně spravovat velkou sadu nezávisle nasazených kontejnerů. Představte si například následující úlohy:

• Jak se instance kontejnerů zřídí napříč clusterem mnoha počítačů?
• Jak budou kontejnery po nasazení zjišťovat a komunikovat mezi sebou?
• Jak se kontejnery můžou škálovat nebo navyšovat na vyžádání?
• Jak monitorovat stav každého kontejneru?
• Jak chráníte kontejner před selháním hardwaru a softwaru?
• Jak upgradovat kontejnery pro živou aplikaci s nulovým výpadkem?

Orchestrátory kontejnerů řeší a automatizují tyto a další obavy.

V cloudovém nativním ekologickém systému se Kubernetes stal de facto orchestrátorem kontejnerů. Jedná se o opensourcovou platformu spravovanou platformou CLOUD Native Computing Foundation (CNCF). Kubernetes automatizuje nasazení, škálování a provozní aspekty kontejnerizovaných úloh v clusteru počítačů. Instalace a správa Kubernetes je ale notoricky složitá.

Mnohem lepší přístup je využít Kubernetes jako spravovanou službu od dodavatele cloudu. Cloud Azure nabízí plně spravovanou platformu Kubernetes s názvem Azure Kubernetes Service (AKS). AKS abstrahuje složitost a provozní režii při správě Kubernetes. Kubernetes využíváte jako cloudovou službu; Microsoft zodpovídá za správu a podporu. AKS se také úzce integruje s dalšími službami Azure a vývojáři nástrojů.

AKS je technologie založená na clusterech. Do cloudu Azure se nasadí fond federovaných virtuálních počítačů nebo uzlů. Společně tvoří vysoce dostupné prostředí nebo cluster. Cluster se pro vaši aplikaci nativní pro cloud zobrazuje jako bezproblémová jedna entita. AKS nasadí kontejnerizované služby napříč těmito uzly za předdefinovanou strategii, která rovnoměrně distribuuje zatížení.

Jaké jsou výhody škálování?

Služby založené na kontejnerech můžou využívat výhody škálování poskytované nástroji orchestrace, jako je Kubernetes. Kontejnery návrhu o sobě jen vědí. Jakmile máte více kontejnerů, které potřebují spolupracovat, měli byste je uspořádat na vyšší úrovni. Uspořádání velkého počtu kontejnerů a jejich sdílených závislostí, jako je konfigurace sítě, je místo, kde nástroje orchestrace přicházejí za účelem úspory dne! Kubernetes vytváří abstraktní vrstvu nad skupinami kontejnerů a uspořádá je do podů. Pody běží na pracovních počítačích označovaných jako uzly. Tato uspořádaná struktura se označuje jako cluster. Obrázek 3–3 ukazuje různé komponenty clusteru Kubernetes.

Obrázek 3–3 Komponenty clusteru Kubernetes

Škálování kontejnerizovaných úloh je klíčovou funkcí orchestrátorů kontejnerů. AKS podporuje automatické škálování mezi dvěma dimenzemi: instance kontejnerů a výpočetní uzly. Společně poskytují AKS možnost rychle a efektivně reagovat na špičky v poptávce a přidávat další prostředky. Škálování v AKS probereme dále v této kapitole.

Deklarativní versus imperativní

Kubernetes podporuje deklarativní i imperativní konfiguraci. Imperativní přístup zahrnuje spouštění různých příkazů, které Kubernetes říkají, co dělat jednotlivé kroky. Spusťte tuto image. Odstraňte tento pod. Zveřejnit tento port. Pomocí deklarativního přístupu vytvoříte konfigurační soubor označovaný jako manifest a popíšete, co chcete místo toho, co chcete udělat. Kubernetes přečte manifest a transformuje požadovaný koncový stav na skutečný koncový stav.

Imperativní příkazy jsou skvělé pro výuku a interaktivní experimentování. Budete ale chtít deklarativní vytváření souborů manifestu Kubernetes, které budou používat infrastrukturu jako přístup ke kódu, a zajistit tak spolehlivé a opakovatelné nasazení. Soubor manifestu se stane artefaktem projektu a použije se v kanálu CI/CD pro automatizaci nasazení Kubernetes.

Pokud jste cluster už nakonfigurovali pomocí imperativních příkazů, můžete deklarativní manifest exportovat pomocí kubectl get svc SERVICENAME -o yaml > service.yaml. Tento příkaz vytvoří manifest podobný následujícímu:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2019-09-13T13:58:47Z"
  labels:
    component: apiserver
    provider: kubernetes
  name: kubernetes
  namespace: default
  resourceVersion: "153"
  selfLink: /api/v1/namespaces/default/services/kubernetes
  uid: 9b1fac62-d62e-11e9-8968-00155d38010d
spec:
  clusterIP: 10.96.0.1
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 6443
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Při použití deklarativní konfigurace můžete zobrazit náhled změn, které budou provedeny před jejich potvrzením, pomocí kubectl diff -f FOLDERNAME složky, ve které se nacházejí vaše konfigurační soubory. Až budete mít jistotu, že chcete změny použít, spusťte kubectl apply -f FOLDERNAMEpříkaz . Přidejte -R k rekurzivnímu zpracování hierarchie složek.

Můžete také použít deklarativní konfiguraci s dalšími funkcemi Kubernetes, z nichž jedno se nasadí. Deklarativní nasazení pomáhají spravovat vydané verze, aktualizace a škálování. Dávají kontroleru nasazení Kubernetes pokyn, jak nasadit nové změny, škálovat zatížení nebo vrátit zpět předchozí revizi. Pokud je cluster nestabilní, deklarativní nasazení automaticky vrátí cluster zpět do požadovaného stavu. Pokud například dojde k chybovému ukončení uzlu, mechanismus nasazení znovu nasadí náhradu, aby dosáhl požadovaného stavu.

Použití deklarativní konfigurace umožňuje reprezentovat infrastrukturu jako kód, který lze vrátit se změnami a s verzí společně s kódem aplikace. Poskytuje vylepšenou kontrolu změn a lepší podporu průběžného nasazování pomocí kanálu buildu a nasazení.

Jaké scénáře jsou ideální pro kontejnery a orchestrátory?

Následující scénáře jsou ideální pro použití kontejnerů a orchestrátorů.

Aplikace vyžadující vysokou dostupnost a škálovatelnost

Jednotlivé aplikace, které mají požadavky na vysokou dostupnost a škálovatelnost, jsou ideálními kandidáty pro architektury nativní pro cloud pomocí mikroslužeb, kontejnerů a orchestrátorů. Dají se vyvíjet v kontejnerech, testovat ve verzích prostředí a nasazovat do produkčního prostředí s nulovými výpadky. Použití clusterů Kubernetes zajišťuje, že tyto aplikace se také můžou škálovat na vyžádání a automaticky se zotavit ze selhání uzlů.

Velký počet aplikací

Organizace, které nasazují a udržují velký počet aplikací, využívají kontejnery a orchestrátory. Počáteční úsilí o nastavení kontejnerizovaných prostředí a clusterů Kubernetes je primárně pevnými náklady. Nasazení, údržba a aktualizace jednotlivých aplikací má náklady, které se liší podle počtu aplikací. Kromě několika aplikací složitost údržby vlastních aplikací ručně překračuje náklady na implementaci řešení pomocí kontejnerů a orchestrátorů.

Kdy byste se měli vyhnout používání kontejnerů a orchestrátorů?

Pokud nemůžete sestavit aplikaci podle principů dvanáctifaktorové aplikace, měli byste se vyhnout kontejnerům a orchestrátorům. V těchto případech zvažte hostující platformu založenou na virtuálních počítačích nebo možná nějaký hybridní systém. Díky tomu můžete určité části funkcí kdykoli vypnout do samostatných kontejnerů nebo dokonce bezserverových funkcí.

Vývojové prostředky

Tato část obsahuje krátký seznam vývojových prostředků, které vám můžou pomoct začít používat kontejnery a orchestrátory pro vaši další aplikaci. Pokud hledáte pokyny k návrhu aplikace architektury mikroslužeb nativní pro cloud, přečtěte si doprovodné materiály této knihy Mikroslužby .NET: Architektura pro kontejnerizované aplikace .NET.

Místní vývoj Kubernetes

Nasazení Kubernetes poskytují skvělou hodnotu v produkčních prostředích, ale můžou také běžet místně na vývojovém počítači. I když můžete pracovat na jednotlivých mikroslužbách nezávisle, může docházet k tomu, že budete muset spustit celý systém místně – stejně jako při nasazení do produkčního prostředí. Existuje několik nástrojů, které vám můžou pomoct: Minikube a Docker Desktop. Visual Studio také poskytuje nástroje pro vývoj Dockeru.

Minikube

Co je Minikube? Projekt Minikube říká" Minikube implementuje místní cluster Kubernetes v systémech macOS, Linux a Windows. Jeho hlavním cílem je "být nejlepším nástrojem pro vývoj místních aplikací Kubernetes a podporovat všechny funkce Kubernetes, které vyhovují.". Instalace Minikube je oddělená od Dockeru, ale Minikube podporuje různé hypervisory než Docker Desktop podporuje. Minikube v současné době podporuje následující funkce Kubernetes:

• DNS
• NodePorts
• Konfigurace Mapy a tajné kódy
• Řídicí panely
• Moduly runtime kontejnerů: Docker, rkt, CRI-O a containerd
• Povolení rozhraní CNI (Container Network Interface)
• Příchozí přenos dat

Po instalaci Minikube ho můžete rychle začít používat spuštěním minikube start příkazu, který stáhne image a spustí místní cluster Kubernetes. Po spuštění clusteru s ním komunikujete pomocí standardních příkazů Kubernetes kubectl .

Docker Desktop

Můžete také pracovat s Kubernetes přímo z Docker Desktopu ve Windows. Je to jediná možnost, pokud používáte kontejnery Windows a je skvělou volbou i pro kontejnery mimo Windows. Obrázek 3–4 ukazuje, jak povolit místní podporu Kubernetes při spuštění Docker Desktopu.

Obrázek 3–4 Konfigurace Kubernetes v Docker Desktopu

Docker Desktop je nejoblíbenější nástroj pro místní konfiguraci a spouštění kontejnerizovaných aplikací. Při práci s Docker Desktopem můžete vyvíjet místně na stejné sadě imagí kontejnerů Dockeru, které nasadíte do produkčního prostředí. Docker Desktop je navržený pro místní sestavování, testování a dodávání kontejnerizovaných aplikací. Podporuje kontejnery Linuxu i Windows. Po nasdílení imagí do registru imagí, jako je Azure Container Registry nebo Docker Hub, může AKS vyžádat a nasadit je do produkčního prostředí.

Nástroje Docker sady Visual Studio

Visual Studio podporuje vývoj Dockeru pro webové aplikace. Když vytvoříte novou aplikaci ASP.NET Core, máte možnost ji nakonfigurovat s podporou Dockeru, jak je znázorněno na obrázku 3–5.

Obrázek 3–5 Povolení podpory Dockeru v sadě Visual Studio

Když vyberete tuto možnost, projekt se vytvoří v Dockerfile kořenovém adresáři, který se dá použít k sestavení a hostování aplikace v kontejneru Dockeru. Příklad souboru Dockerfile je znázorněn na obrázku 3-6.

FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY ["eShopWeb/eShopWeb.csproj", "eShopWeb/"]
RUN dotnet restore "eShopWeb/eShopWeb.csproj"
COPY . .
WORKDIR "/src/eShopWeb"
RUN dotnet build "eShopWeb.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "eShopWeb.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "eShopWeb.dll"]

Obrázek 3-6 Vygenerovaný soubor Dockerfile v sadě Visual Studio

Po přidání podpory můžete aplikaci spustit v kontejneru Dockeru v sadě Visual Studio. Obrázek 3–7 ukazuje různé možnosti spuštění dostupné v novém projektu ASP.NET Core vytvořeném s přidanou podporou Dockeru.

Obrázek 3–7 Možnosti spuštění Dockeru v sadě Visual Studio

Do existující aplikace ASP.NET Core můžete také kdykoli přidat podporu Dockeru. V Průzkumník řešení sady Visual Studio klikněte pravým tlačítkem myši na projekt a vyberte Přidat>podporu Dockeru, jak je znázorněno na obrázku 3-8.

Obrázek 3–8 Přidání podpory Dockeru do sady Visual Studio

Nástroje Dockeru v editoru Visual Studio Code

Pro Visual Studio Code je k dispozici mnoho rozšíření, která podporují vývoj Dockeru.

Microsoft poskytuje rozšíření Docker for Visual Studio Code. Toto rozšíření zjednodušuje proces přidávání podpory kontejnerů do aplikací. Vygeneruje požadované soubory, sestavuje image Dockeru a umožňuje ladit aplikaci v kontejneru. Rozšíření obsahuje průzkumníka vizuálů, který usnadňuje provádění akcí u kontejnerů a imagí, jako je spuštění, zastavení, kontrola, odebrání atd. Rozšíření také podporuje Docker Compose, který umožňuje spravovat více spuštěných kontejnerů jako jednu jednotku.

PředchozíDalší