Sdílet prostřednictvím

Nasazení mikroslužeb do Azure Container Apps

Azure Container Apps
Azure Cosmos DB
Azure Service Bus

Tento scénář ukazuje existující úlohu původně navrženou pro Kubernetes, která se znovu vytvoří pro spuštění v Azure Container Apps. Container Apps podporuje úlohy v zaostalých projektech, kde týmy chtějí zjednodušit správu infrastruktury a orchestrace kontejnerů.

Ukázková úloha je kontejnerizovaná aplikace mikroslužeb. Opakovaně používá stejnou úlohu definovanou v architektuře mikroslužeb ve službě Azure Kubernetes Service (AKS). Tato architektura přehostuje úlohu v Container Apps jako její aplikační platformu.

Důležité

Tato architektura se zaměřuje na minimalizaci změn kódu aplikace a přístupu k přechodu z AKS na Container Apps jako na migraci platformy. Cílem je replikovat stávající implementaci a odložit optimalizace kódu nebo infrastruktury, které můžou ohrozit migraci.

Pro nové úlohy použijte Nasazení mikroslužeb pomocí Container Apps a Dapr.

Návod

Příklad implementace podporuje tuto architekturu a ilustruje některé z možností návrhu popsaných v tomto článku.

Architektura

Diagram znázorňující architekturu modulu runtime pro řešení

Stáhněte si soubor aplikace Visio s touto architekturou.

Služby, které sdílejí stejný prostředí, z toho těží následujícími způsoby:

  • Interní příchozí přenos dat a zjišťování služeb
  • Jeden pracovní prostor služby Log Analytics pro protokolování za běhu
  • Metoda zabezpečené správy tajných kódů a certifikátů

Tok dat

  1. Služba příjmu dat: Přijímá požadavky klientů, ukládá je do vyrovnávací paměti a pak je publikuje do služby Azure Service Bus. Je to jediný vstupní bod do pracovní zátěže.

  2. Služba pracovního postupu: Využívá zprávy ze služby Service Bus a odesílá je do podkladových mikroslužeb.

  3. Služba balíčků: Spravuje balíčky. Služba udržuje svůj vlastní stav ve službě Azure Cosmos DB.

  4. Služba plánovače dronů: Naplánuje drony a monitoruje letové drony. Služba udržuje svůj vlastní stav ve službě Azure Cosmos DB.

  5. Služba doručování: Spravuje plánované nebo tranzitní dodávky. Služba udržuje svůj vlastní stav ve službě Azure Managed Redis.

  6. Načítání tajných kódů: Vzhledem k tomu, že se jedná o existující úlohu, mají přístup ke službě Azure Key Vault jenom některé komponenty, aby získaly tajné kódy modulu runtime. Ostatní služby obdrží tyto tajné kódy z prostředí Container Apps.

  7. Protokoly a metriky: Prostředí a všechny kontejnerové aplikace generují protokoly a metriky, které azure Monitor nabízí, a pak shromáždí a vizualizuje.

  8. Obrazy kontejnerů: Obrazy kontejnerů se stahují z existující služby Azure Container Registry, která se dříve používala pro AKS a nasazovány do prostředí Container Apps.

Komponenty

Úloha používá při koordinaci mezi sebou následující služby Azure:

  • Container Apps je bezserverová platforma kontejneru, která zjednodušuje orchestraci a správu kontejnerů. V této architektuře služba Container Apps slouží jako primární hostitelská platforma pro všechny mikroslužby.

    Mnohé z funkcí předchozí architektury AKS nahrazují následující funkce:

    • Integrované zjišťování služeb
    • Spravované koncové body HTTP a HTTP/2
    • Integrované vyrovnávání zatížení
    • Protokolování a monitorování
    • Automatické škálování na základě provozu HTTP nebo událostí využívajících automatické škálování řízené událostmi založenými na Kubernetes (KEDA)
    • Upgrady aplikací a správa verzí

  • Container Registry je spravovaná služba registru pro ukládání a správu privátních imagí kontejnerů. V této architektuře je zdrojem všech imagí kontejnerů nasazených do prostředí Container Apps. Registr je stejný jako v implementaci AKS.

  • Azure Cosmos DB je globálně distribuovaná databázová služba s více modely. V této architektuře služba plánovače dronů používá službu Azure Cosmos DB jako své úložiště dat.

  • Azure DocumentDB je plně spravovaná databázová služba kompatibilní s MongoDB pro vytváření moderních aplikací. V této architektuře služba balíčků používá azure DocumentDB jako své úložiště dat.

  • Service Bus je cloudová služba zasílání zpráv, která poskytuje asynchronní komunikační funkce a hybridní integraci. V této architektuře zpracovává asynchronní zasílání zpráv mezi službou příjmu dat a mikroslužbou pracovního postupu založenou na úlohách. Zbývající služby v existující aplikaci jsou navržené tak, aby je ostatní služby mohly vyvolat pomocí požadavků HTTP.

  • Azure Managed Redis je služba pro ukládání do mezipaměti v paměti. V této architektuře snižuje latenci a zlepšuje propustnost pro často přístupná data doručování pomocí dronů.

  • Key Vault je cloudová služba pro bezpečné ukládání tajných kódů, jako jsou klíče rozhraní API, hesla a certifikáty. V této architektuře plánovač dronů a služby doručování používají spravované identity přiřazené uživatelem k ověření ve službě Key Vault a načítání tajných kódů potřebných pro jejich požadavky na modul runtime.

  • Azure Monitor je komplexní řešení monitorování, které shromažďuje a analyzuje telemetrická data. V této architektuře shromažďuje a ukládá metriky a protokoly ze všech komponent aplikací prostřednictvím pracovního prostoru služby Log Analytics. Tato data slouží k monitorování aplikace, nastavení výstrah a řídicích panelů a provádění analýzy původní příčiny selhání.

    • Application Insights je služba pro správu výkonu aplikací, která poskytuje rozšiřitelné možnosti monitorování. V této architektuře se každá služba instrumentuje se sadou Application Insights SDK pro monitorování výkonu aplikace.

Alternativy

Pokročilá architektura mikroslužeb AKS popisuje alternativní scénář tohoto příkladu, který používá Kubernetes.

Podrobnosti scénáře

Nasazení a správu kontejnerů mikroslužeb můžete zjednodušit pomocí Container Apps, bezserverového prostředí pro hostování kontejnerizovaných aplikací.

Společnost Fabrikam, Inc., fiktivní společnost, implementuje úlohu doručování pomocí dronů, ve které uživatelé požadují, aby dron vyzvedl zboží a doručí je. Když zákazník naplánuje vyzvednutí, back-endový systém přiřadí dron a upozorní uživatele odhadovanou dobou vyzvednutí.

Aplikace mikroslužeb byla nasazena do clusteru AKS. Tým Fabrikam ale nevyužil pokročilé funkce AKS ani funkce AKS specifické pro danou platformu. Migrovali aplikaci do Container Apps, která jim umožnila provádět následující akce:

  • Při přesouvání aplikace z AKS do Container Apps používejte minimální změny kódu. Změny kódu souvisely s knihovnami pozorovatelnosti, které rozšířily protokoly a metriky o informace o uzlech Kubernetes, které v novém prostředí nejsou relevantní.

  • Nasazení infrastruktury i úlohy pomocí šablon Bicep: K nasazení kontejnerů aplikací nebyly potřeba žádné manifesty YAML Kubernetes.

  • Zpřístupnění aplikace prostřednictvím spravovaného přístupu Integrovaná podpora externího příchozího připojení založeného na HTTPS pro zpřístupnění služby příjmu odstranila potřebu konfigurovat vlastní příchozí přístup.

  • Načítá image kontejneru ze služby Container Registry. Container Apps je kompatibilní s jakoukoli základní imagí Linuxu uloženou v libovolném dostupném úložišti.

  • Pomocí funkce revize můžete podporovat potřeby životního cyklu aplikace. Mohou spouštět více revizí konkrétní kontejnerové aplikace a rozdělit mezi ně provoz pro scénáře A/B testování nebo blue/green nasazení.

  • Použijte spravovanou identitu k ověření ve službě Key Vault a container Registry.

Potenciální případy použití

Nasaďte aplikaci založenou na mikroslužbách brownfield do platformy jako služby (PaaS), abyste zjednodušili správu a vyhnuli se složitosti spouštění orchestrátoru kontejnerů. Brownfieldová zátěž ušetřila peníze díky této architektuře oproti nasazení na Kubernetes z následujících důvodů:

  • Volba profilů úloh
  • Méně času stráveného na provozních úkolech druhého dne pro operační tým.
  • Možnost vyhnout se nadměrnému zřizování

Poznámka:

Ne všechny úlohy přinášejí takové úspory nákladů.

Zvažte další běžné použití container Apps:

  • Spouštění kontejnerizovaných úloh na bezserverové platformě založené na spotřebě
  • Automatické škálování aplikací na základě provozu HTTP nebo HTTPS a triggerů řízených událostmi, které podporuje KEDA.
  • Minimalizujte režijní náklady na údržbu pro kontejnerizované aplikace.
  • Nasaďte koncové body rozhraní API.
  • Hostovat aplikace pro zpracování na pozadí
  • Zpracování řízené událostmi.

Optimizations

Cílem týmu úloh je migrovat stávající úlohu do Container Apps s minimálními změnami kódu. Po migraci byste ale měli provést několik optimalizací, abyste zlepšili architekturu a implementaci úloh.

Vylepšení správy tajných kódů

Úloha používá hybridní přístup ke správě tajemství. Spravované identity se vztahují pouze na služby, ve kterých přepnutí na spravované identity nevyžaduje úpravy kódu. Plánovač dronů a služby doručování využívají spravované identity přiřazené uživatelem se službou Key Vault pro přístup k uloženým tajným kódům. Zbývající služby vyžadují změny kódu pro přijetí spravovaných identit, takže tyto služby používají tajné kódy, které poskytuje prostředí Container Apps.

Lepším přístupem je aktualizovat veškerý kód tak, aby podporoval spravované identity pomocí aplikace nebo identity úlohy místo tajných kódů poskytovaných prostředím. Další informace o pracovních identitách naleznete v Spravované identity v aplikacích Container Apps.

Vyhněte se návrhům, které vyžadují režim jedné revize.

Aplikace kontejneru služby pracovního postupu se spouští v režimu jedné revize. V režimu jedné revize má aplikace jednu revizi podporovanou nulou nebo více replikami. Replika se skládá z kontejneru aplikace a jakýchkoli potřebných vedlejších komponent. Tento příklad nepoužívá sidecary, takže každá replika je samostatným kontejnerem. Služba pracovního postupu není navržena pro zabezpečení kompatibility se schématy zpráv v budoucnosti. Dvě různé verze služby by se nikdy neměly spouštět souběžně.

Pokud se musí změnit schéma zpráv služby Service Bus, musíte sběrnici před nasazením nové verze služby pracovního postupu vyprázdnět. Lepším přístupem je aktualizace kódu služby pro zajištění budoucí kompatibility a použití režimu více revizí k omezení výpadků spojených s vyprazdňováním front.

Zvažte práci založenou na úlohách.

Služba pracovního postupu se realizuje jako kontejnerová aplikace s dlouhým trváním. Může ale také běžet jako úloha v Container Apps. Úloha je kontejnerizovaná aplikace, která začíná na vyžádání, běží až do dokončení podle dostupné práce, poté se vypne a uvolní prostředky. Úlohy mohou být úspornější než nepřetržitě spuštěné repliky. Migrace služby tak, aby běžela jako úloha Container Apps na základě dostupné práce ve frontě, může být praktickou variantou. Závisí na typickém objemu fronty a na tom, jak je služba pracovního postupu psaná jako omezená, paralelizovatelná a optimalizovaná z hlediska zdrojů. Experimentujte a ověřte, jak určit nejlepší přístup.

Implementace řízení příchozího provozu

Úloha využívá integrovanou funkci externího příchozího přenosu dat služby Container Apps k zveřejnění služby pro příjem dat. Řízení příchozího přenosu dat neposkytuje možnost zcela umístit váš bod příchozího přenosu dat za firewall webových aplikací (WAF) ani ho zahrnout do plánů služby Azure DDoS Protection. Musíte chránit všechny webově orientované pracovní zátěže pomocí WAF. Pokud chcete tuto konfiguraci dosáhnout v prostředí Container Apps, měli byste zakázat integrované veřejné příchozí přenosy dat a přidat Application Gateway nebo Azure Front Door.

Poznámka:

Brány vyžadují smysluplné sondy stavu, které udržují příchozí službu v provozu a brání jejímu škálování na nulu.

Modernizace pomocí Dapr

Úlohu můžete dále modernizovat integrací s distribuovaným modulem Application Runtime (Dapr). Přidává abstrakci mezi úložištěm kódu úloh a stavovými úložišti, systémy zasílání zpráv a mechanismy zjišťování služeb. Další informace najdete v tématu Nasazení mikroslužeb pomocí Container Apps a Dapr. Pokud vaše úloha v Kubernetes už používá Dapr nebo běžné škálovací nástroje KEDA, migrace do Container Apps je často jednoduchá a může tuto funkci zachovat.

Migrace na autentizaci a autorizaci uživatelů

Zatížení nepředává autorizaci na bránu. Služba příjmu dat zpracovává autorizaci svých klientů. Lepším přístupem je přesměrovat tuto odpovědnost na předdefinované funkce ověřování a autorizace, často označované jako Easy Auth. Tato změna využívá možnosti platformy a snižuje vlastní kód v mikroslužbě příjmu dat.

Důležité informace

Následující aspekty implementují pilíře rozhraní Microsoft Azure Well-Architected Framework, což je sada hlavních principů, které můžete použít ke zlepšení kvality úlohy. Další informace najdete v tématu Azure Well-Architected Framework.

Spolehlivost

Spolehlivost pomáhá zajistit, aby vaše aplikace splňovala závazky, které uděláte pro vaše zákazníky. Další informace naleznete v tématu Kontrolní seznam pro kontrolu spolehlivosti.

Container Apps pomáhá nasazovat, spravovat, udržovat a monitorovat aplikace v úloze. Spolehlivost můžete zlepšit pomocí základních doporučení. Během migrace z Kubernetes se implementují některá doporučení.

  • Revize vám pomůžou nasadit aktualizace aplikací s nulovým výpadkem. Revize můžete použít ke správě nasazení aktualizací aplikací a rozdělení provozu mezi revizemi, které podporují modrá/zelená nasazení a testování A/B.

  • Díky pozorovatelným funkcím Container Apps máte přehled o komponentách, které běží v rámci prostředí. Container Apps se integruje s Application Insights a Log Analytics. Tato data používáte ke sledování operací a nastavení výstrah na základě metrik a událostí v rámci systému pozorovatelnosti.

    Monitorování výkonu pomáhá vyhodnotit aplikaci při zatížení. Metriky a protokoly poskytují data pro rozpoznávání trendů, zkoumání selhání a provádění analýzy původní příčiny.

  • Význam sond stavu a připravenosti spočívá v řešení pomalého spouštění kontejnerů a umožňuje vyhnout se směrování provozu, než jsou připraveny. Implementace Kubernetes zahrnuje tyto koncové body. Pokud poskytují efektivní signály, pokračujte v jejich používání.

  • Když se služba neočekávaně ukončí, služba Container Apps ji automaticky restartuje. Zjišťování služeb je povolené, aby workflow služba mohla zjistit podřízené mikroslužby. Pomocí zásad odolnosti můžete zpracovávat časové limity a zavádět logiku jističe, aniž byste museli kód dále upravovat.

  • Povolte pravidla automatického škálování, aby se splnila poptávka při nárůstu provozu a úloh.

  • Ke zlepšení dostupnosti využijte dynamické vyrovnávání zatížení a funkce škálování služby Container Apps. Zřiďte podsíť vašeho prostředí tak, aby vždy byla dostatek dostupných IP adres pro budoucí repliky nebo úlohy.

  • Vyhněte se ukládání stavu přímo v prostředí Container Apps, protože při vypnutí repliky dojde ke ztrátě veškerého stavu. Externalizace stavu do vyhrazeného úložiště stavu pro každou mikroslužbu Tato architektura distribuuje stav napříč třemi různými úložišti: Azure Managed Redis, Azure Cosmos DB for NoSQL a Azure DocumentDB.

  • Nasaďte všechny prostředky, včetně container Apps, pomocí topologie s více zónami. Další informace najdete v tématu Podpora zón dostupnosti v Container Apps.

    Nastavte minimální počet replik pro netransientní aplikace na alespoň jednu repliku pro každou zónu dostupnosti. Během typických provozních podmínek jsou repliky spolehlivě distribuovány a vyváženy napříč zónami dostupnosti v dané oblasti.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace naleznete v tématu Kontrolní seznam pro kontrolu návrhu prozabezpečení .

Tajné kódy

  • Vaše aplikace kontejneru může ukládat a načítat citlivé hodnoty jako tajné kódy. Jakmile definujete tajný kód pro aplikaci kontejneru, je k dispozici pro použití aplikací a všechna přidružená pravidla škálování. Pokud používáte režim více revizí, všechny revize sdílejí stejné tajné kódy. Protože se tajné kódy považují za změny rozsahu aplikace, pokud změníte hodnotu tajného kódu, nová revize se nevytvořila. Pokud ale všechny spuštěné revize načtou novou hodnotu tajného kódu, musíte je restartovat. V tomto scénáři se používají hodnoty proměnných aplikací a prostředí.

  • Přepište kód služby tak, aby používal vlastní spravovanou identitu aplikace k ověření závislostí místo předsdílených tajných kódů. Všechny závislosti mají sady SDK, které podporují ověřování spravovaných identit.

  • Citlivé hodnoty můžete bezpečně ukládat do proměnných prostředí na úrovni aplikace. Při změně proměnných prostředí vytvoří aplikace kontejneru novou revizi.

Zabezpečení sítě

  • Pokud chcete omezit externí přístup, nakonfiguruje se pro externí příchozí přenos dat pouze služba příjmu dat. K back-endovým službám je možné přistupovat pouze prostřednictvím interní virtuální sítě v prostředí Container Apps a jsou nakonfigurované jako interní režim. V případě potřeby zpřístupňujte pouze služby na internetu.

    Vzhledem k tomu, že tato architektura používá vestavěnou funkci externího příchozího bodu, toto řešení neposkytuje možnost váš příchozí bod zcela umístit za WAF nebo ho zahrnout do plánů ochrany před útoky DDoS. Postavte všechny pracovní zátěže orientované na web před firewall aplikace pro web. Další informace o vylepšeních příchozího přenosu dat najdete v tématu Implementace řízení příchozího přenosu dat.

  • Při vytváření prostředí můžete zadat vlastní virtuální síť. Jinak Microsoft automaticky vygeneruje a spravuje virtuální síť. S touto virtuální sítí spravovanou Microsoftem nemůžete manipulovat, například přidáním skupin zabezpečení sítě (NSG) nebo vynucením tunelového propojení do výstupní brány firewall. Příklad používá automaticky vygenerovanou virtuální síť, ale vlastní virtuální síť zlepšuje kontrolu zabezpečení. Vlastní síť vám umožňuje aplikovat NSG a směrování založené na UDR prostřednictvím Azure Firewall.

Další informace o možnostech síťové topologie, včetně podpory privátních koncových bodů pro příchozí přenos dat, najdete v tématu Síťová architektura v Container Apps.

Identity úloh

  • Container Apps podporuje spravované identity Microsoft Entra, které vaší aplikaci umožňují ověřit se v jiných prostředcích chráněných ID Microsoft Entra, jako je Key Vault, bez správy přihlašovacích údajů v aplikaci kontejneru. Aplikace kontejneru může používat identity přiřazené systémem, uživatelem přiřazené identity nebo obojí. Pro služby, které nepodporují ověřování pomocí Microsoft Entra ID, ukládejte tajemství ve službě Key Vault a pro přístup k tajemstvím použijte spravovanou identitu.

  • Pro přístup ke službě Container Registry použijte jednu vyhrazenou spravovanou identitu přiřazenou uživatelem. Container Apps podporuje použití jiné spravované identity pro provoz úloh než pro přístup k registru kontejnerů. Tento přístup poskytuje podrobné řízení přístupu. Pokud má vaše úloha více prostředí Container Apps, nesdílejte identitu napříč instancemi.

  • Pomocí spravovaných identit přiřazených systémem pro identity úloh můžete svázat životní cyklus identity s životním cyklem součástí úlohy.

Další doporučení zabezpečení

  • Implementace Kubernetes této úlohy poskytuje ochranu pomocí funkcí Microsoft Defenderu for Containers. V této architektuře Defender for Containers vyhodnocuje pouze ohrožení zabezpečení kontejnerů ve službě Container Registry. Defender for Containers neposkytuje ochranu za běhu pro Container Apps. Pokud je požadavkem ochrana za běhu, vyhodnoťte doplnění řešení zabezpečení od jiných společností než Microsoft.

  • Nespousívejte úlohu ve sdíleném prostředí Container Apps. Segmentujte ho z jiných úloh nebo komponent, které nepotřebují přístup k těmto mikroslužbám. Vytvořte samostatná prostředí Container Apps. Aplikace a úlohy, které běží v prostředí Container Apps, můžou zjišťovat a kontaktovat jakoukoli službu, která běží v prostředí s povoleným interním příchozím přenosem dat.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace naleznete v tématu Kontrolní seznam pro kontrolu návrhu proOptimalizace nákladů .

  • Projděte si ukázkový odhad ceny pro úlohu. Použijte cenovou kalkulačku Azure. Konfigurace se liší, takže ji upravte tak, aby odpovídala vašemu scénáři.

  • V tomto scénáři jsou hlavními ovladači nákladů Azure Cosmos DB, Azure Managed Redis a Service Bus Premium.

  • U kontejnerů, které obvykle spotřebovávají nízké množství procesoru a paměti, nejprve vyhodnoťte profil úlohy spotřeby. Odhad nákladů na profil spotřeby na základě využití vám pomůže shromáždit základní data nákladů a vyhodnotit další profily. Můžete například použít vyhrazený profil úlohy pro komponenty, které mají vysoce předvídatelné a stabilní využití a můžou sdílet vyhrazené uzly. Kvůli optimalizaci nákladů udržujte pro každý vyhrazený profil několik tří uzlů, abyste zajistili dostatečné výpočetní hostitele a distribuci replik napříč zónami dostupnosti.

  • Eliminujte náklady na výpočetní prostředky během období nečinnosti tím, že se komponenty můžou škálovat na nulu, takže platíte jenom v případě potřeby. Tento přístup snižuje náklady na aplikace, které mají proměnlivé nebo občasné využití. Kontroly stavu obvykle brání úplnému škálování na nulu. V architektuře můžete službu pracovního postupu znovu vytvořit jako úlohu, abyste během období nečinnosti využili výhod škálování na nulu. Tento přístup se dobře hodí pro úlohy, které můžou využívat plán spotřeby.

  • Pokud se chcete vyhnout poplatkům za síť mezi oblastmi, nasaďte všechny komponenty, jako jsou úložiště stavů a registr kontejnerů, ve stejné oblasti.

Efektivita provozu

Efektivita provozu se zabývá provozními procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace naleznete v tématu kontrolní seznam pro kontrolu efektivity provozu.

  • Pomocí integrace GitHub Actions nebo Azure Pipelines můžete nastavit automatizované kanály kontinuální integrace a průběžného nasazování (CI/CD).

  • Pomocí režimu více revizí s rozdělením provozu otestujte změny kódu úloh a pravidel škálování.

  • Integrujte se službou Application Insights a Log Analytics, abyste mohli získat přehled o vašich úlohách. Používejte stejný pracovní prostor služby Log Analytics jako zbytek komponent vaší úlohy, abyste měli všechny přehledy o úlohách pohromadě.

  • Ke správě všech nasazení infrastruktury použijte infrastrukturu jako kód (IaC), například Bicep nebo Terraform. Nasazení zahrnují prostředí Container Apps, registr kontejnerů a úložiště stavu mikroslužeb. Oddělte kanály nasazení mikroslužeb od kanálů infrastruktury, protože často nesdílejí podobný životní cyklus. Váš deklarativní kanál pro infrastrukturu Azure by měl nasadit všechny prostředky kromě prostředků kontejnerové aplikace.

  • Použijte imperativní přístup k vytváření, aktualizaci a odebírání kontejnerových aplikací z prostředí. Je zvlášť důležité, pokud dynamicky upravujete logiku posunu provozu mezi revizemi. V pracovních postupech nasazení použijte akci GitHubu nebo úlohu Azure Pipelines . Tento imperativní přístup může být založený na definicích aplikací YAML . Pro minimalizaci selhání kontroly stavu se vždy ujistěte, že váš pipeline před nasazením aplikace kontejneru naplní registr kontejneru novým obrazem kontejneru.

    Důležitou změnou implementace Kubernetes je přechod ze správy souborů manifestu Kubernetes, například definování Deployment objektů Kubernetes. Kubernetes poskytuje atomický přístup ve smyslu "společně uspět" nebo "společně selhat" pro nasazení mikroslužeb prostřednictvím tohoto objektu manifestu. V Container Apps se každá mikroslužba nasazuje nezávisle. Vaše nasazovací kanály jsou zodpovědné za řízení jakékoli strategie sekvencování a vrácení změn nezbytné pro bezpečné nasazení.

Efektivita výkonu

Efektivita výkonu odkazuje na schopnost vaší úlohy efektivně škálovat tak, aby splňovala požadavky uživatelů. Další informace naleznete v tématu Kontrola návrhu kontrolní seznam pro zvýšení efektivity výkonu.

  • Úloha se distribuuje mezi několik aplikací mikroslužeb.

  • Každá mikroslužba je nezávislá a nesdílí žádný stav s jinými mikroslužbami, což umožňuje nezávislé škálování.

  • Použijte úlohy Container Apps pro jednorázové spuštění procesů, abyste implementovali přechodná runtime prostředí a snížili spotřebu prostředků pro nečinné služby. Vyhodnoťte dopady na výkon při spouštění a ukončování úloh oproti ponechání komponent v připraveném stavu.

  • Automatické škálování je povolené. Pokud je to možné, upřednostněte škálování založené na událostech před škálováním na základě metrik. Například služba pracovního postupu, pokud je navržena tak, aby podporovala škálování, by mohla škálovat na základě hloubky fronty v rámci služby Service Bus. Výchozí automatické škálování je založené na požadavcích HTTP. Během přeformulování je důležité začít se stejným přístupem škálování a později vyhodnotit optimalizace škálování.

  • Požadavky jsou dynamicky rozloženy na dostupné repliky revize.

  • Metriky, včetně využití procesoru, paměti, informací o šířce pásma a úložiště, jsou dostupné prostřednictvím služby Azure Monitor.

Nasazení tohoto scénáře

Postupujte podle kroků v README.md v ukázkovém úložišti scénářů Container Apps.

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Přispěvatelů:

Další kroky