Automatizace cloudu na základě událostí

Automatizace pracovních postupů a opakovaných úloh v cloudu pomocí bezserverových technologií může výrazně zvýšit produktivitu týmu DevOps organizace. Bezserverový model je nejvhodnější pro scénáře automatizace, které odpovídají přístupu řízenému událostmi.

Architektura

Scénáře

Tento článek ukazuje dva klíčové scénáře automatizace cloudu:

1. Označování nákladového střediska: Tato implementace sleduje nákladová centra jednotlivých prostředků Azure. Služba Azure Policy označí všechny nové prostředky ve skupině s výchozím ID nákladového střediska. Azure Event Grid monitoruje události vytváření prostředků a pak volá funkci Azure. Funkce komunikuje s ID Microsoft Entra a ověřuje ID nákladového střediska pro nový prostředek. Pokud se liší, aktualizuje značku a odešle e-mail vlastníkovi prostředku. Dotazy REST pro Microsoft Entra ID jsou kvůli jednoduchosti napodobeny. Id Microsoft Entra je také možné integrovat pomocí modulu Microsoft Graph PowerShellu nebo knihovny MSAL (Microsoft Authentication Library) pro Python.

2. Odpověď na omezování: Tento příklad monitoruje databázi Azure Cosmos DB kvůli omezování. Upozornění služby Azure Monitor se aktivují, když žádosti o přístup k datům do služby Azure Cosmos DB překročí kapacitu v jednotkách žádostí (nebo RU). Skupina akcí Služby Azure Monitor je nakonfigurovaná tak, aby v reakci na tato upozornění volala funkci automatizace. Funkce škáluje jednotky RU na vyšší hodnotu, zvyšuje kapacitu a zastavuje výstrahy.

Referenční implementace scénáře je k dispozici na GitHubu.

Funkce v těchto scénářích automatizace bezserverového cloudu jsou často napsané v PowerShellu a Pythonu, dva nejběžnější skriptovací jazyky používané v automatizaci systému. Nasazují se pomocí nástrojů Azure Functions Core Tools v Azure CLI. Alternativně můžete k nasazení a správě Azure Functions použít rutinu Az.Functions PowerShellu.

Workflow

Scénáře automatizace založené na událostech jsou nejlépe implementované pomocí Azure Functions. Používají se k těmto běžným vzorům:

• Reagujte na události na prostředky. Jedná se o odpovědi na události, jako je prostředek Azure nebo skupina prostředků, která se vytváří, odstraňuje, mění atd. Tento model používá Event Grid k aktivaci funkce pro takové události. Příkladem tohoto modelu je scénář označování nákladového střediska. Mezi běžné scénáře patří:

  • udělení přístupu týmům DevOps k nově vytvořeným skupinám prostředků,
  • odesílání oznámení do DevOps při odstranění prostředku a
  • reagování na události údržby pro prostředky, jako jsou virtuální počítače Azure.

• Naplánované úkoly Obvykle se jedná o úlohy údržby spouštěné pomocí funkcí aktivovaných časovačem. Mezi příklady tohoto modelu patří:

  • zastavení prostředku v noci a zahájení ráno,
  • čtení obsahu služby Blob Storage v pravidelných intervalech a převodu na dokument služby Azure Cosmos DB
  • pravidelně prohledávat prostředky, které se už nepoužívají, a odebírat je a
  • automatizované zálohy.

• Zpracování upozornění Azure Tento model využívá snadnou integraci upozornění a skupin akcí služby Azure Monitor se službou Azure Functions. Funkce obvykle provádí nápravné akce v reakci na metriky, log analytics a výstrahy pocházející z aplikací a infrastruktury. Příkladem tohoto modelu je scénář odpovědi na omezování. Mezi běžné scénáře patří:

  • zkrácení tabulky, když sql Database dosáhne maximální velikosti,
  • restartování služby ve virtuálním počítači, když je chybně zastavena, a
  • odesílání oznámení, pokud funkce selhává.

• Orchestrace s externími systémy Tento model umožňuje integraci s externími systémy pomocí Logic Apps k orchestraci pracovního postupu. Konektory Logic Apps se můžou snadno integrovat s několika službami třetích stran a také s služby Microsoft, jako je Microsoft 365. Azure Functions je možné použít pro skutečnou automatizaci. Tento model ukazuje scénář označování nákladového střediska. Mezi běžné scénáře patří:

  • monitorování IT procesů, jako jsou žádosti o změnu nebo schválení, a
  • odesílání e-mailových oznámení po dokončení úlohy automatizace

• Zveřejnění jako webhooku nebo rozhraní API Úlohy automatizace pomocí Azure Functions je možné integrovat do aplikací třetích stran nebo dokonce do nástrojů příkazového řádku tím, že funkci zpřístupňujete jako webhook nebo rozhraní API pomocí triggeru HTTP. V PowerShellu i Pythonu je k dispozici více metod ověřování pro zabezpečení externího přístupu k této funkci. Automatizace probíhá v reakci na externí události specifické pro aplikaci, například integraci s power apps nebo GitHubem. Mezi běžné scénáře patří:

  • aktivace automatizace pro neúspěšnou službu a
  • onboarding uživatelů k prostředkům organizace.

• Vytvoření rozhraní ChatOps Tento model umožňuje zákazníkům vytvořit chatované provozní rozhraní a spouštět vývojové a provozní funkce a příkazy v souladu s lidskou spolupráci. To se dá integrovat se službou Azure Bot Framework a používat příkazy Microsoft Teams nebo Slack pro nasazení, monitorování, běžné otázky atd. Rozhraní ChatOps vytvoří systém v reálném čase pro správu produkčních incidentů, přičemž každý krok je automaticky zdokumentovaný v chatu. Přečtěte si , jak vám Může ChatOps pomoct lépe DevOps, abyste měli další informace.

• Hybridní automatizace. Tento model používá Aplikace Azure Service Hybrid Připojení ions k instalaci softwarové komponenty na místním počítači. Tato komponenta umožňuje zabezpečený přístup k prostředkům na tomto počítači. Možnost správy hybridních prostředí je v současné době dostupná v systémech Windows pomocí funkcí PowerShellu. Mezi běžné scénáře patří:

  • správa místních počítačů a
  • správa jiných systémů za bránou firewall (například místní SQL Server) přes jump server.

Komponenty

Tato architektura se skládá z následujících součástí:

• Funkce Azure Functions. Azure Functions poskytuje výpočetní funkce řízené událostmi bez serveru v této architektuře. Funkce provádí úlohy automatizace při aktivaci událostmi nebo upozorněními. Ve dvou scénářích se funkce vyvolá s požadavkem HTTP. Složitost kódu by se měla minimalizovat vývojem funkce, která je bezstavová a idempotentní.

  Několik spuštění idempotentní funkce vytvoří stejné výsledky. Aby bylo možné zachovat idempotenci, škálování funkce ve scénáři omezování se udržuje zjednodušeně. V reálné automatizaci nezapomeňte vertikálně navýšit nebo snížit kapacitu odpovídajícím způsobem. Přečtěte si článek Optimalizace výkonu a spolehlivosti služby Azure Functions pro osvědčené postupy při psaní funkcí.

• Azure Logic Apps. Logic Apps je možné použít k provádění jednodušších úloh, snadno implementovaných pomocí integrovaných konektorů. Tyto úlohy můžou být v rozsahu od e-mailových oznámení až po integraci s externími aplikacemi pro správu. Pokud chcete zjistit, jak používat Logic Apps s aplikacemi třetích stran, přečtěte si základní podnikovou integraci v Azure.

  Logic Apps poskytuje žádný vizuální návrhář kódu nebo málo kódu a může být použit samostatně v některých scénářích automatizace. Přečtěte si toto porovnání mezi Službami Azure Functions a Logic Apps a zjistěte, která služba může vyhovovat vašemu scénáři.

• Event Grid. Event Grid má integrovanou podporu událostí z jiných služeb Azure a také vlastních událostí (označovaných také jako vlastní témata). Provozní události, jako je vytváření prostředků, se dají snadno rozšířit do funkce automatizace pomocí integrovaného mechanismu Event Gridu.

  Event Grid zjednodušuje automatizaci založenou na událostech pomocí modelu publikování a odběru, což umožňuje spolehlivou automatizaci událostí doručovaných přes HTTPS.

• Azure Monitor Výstrahy služby Azure Monitor můžou monitorovat kritické podmínky a provádět opravné akce pomocí skupin akcí služby Azure Monitor. Tyto skupiny akcí jsou snadno integrované se službou Azure Functions. To je užitečné, když chcete sledovat a opravovat všechny chybové stavy ve vaší infrastruktuře, jako je omezování databáze.

• Akce automatizace Tento obecný blok představuje další služby, se kterými může vaše funkce pracovat, aby poskytovala funkce automatizace. Například ID Microsoft Entra pro ověření značek jako v prvním scénáři nebo databáze, která se má zřídit jako v druhém scénáři.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Odolnost

Azure Functions

Zpracování časových limitů HTTP

Pokud se chcete vyhnout vypršení časového limitu PROTOKOLU HTTP pro delší úlohu automatizace, zařadíte tuto událost do fronty ve službě Service Bus a zpracujete skutečnou automatizaci v jiné funkci. Tento model znázorňuje scénář automatizace odezvy omezování, i když je skutečné zřizování RU služby Azure Cosmos DB rychlé.

Durable Functions, které udržují stav mezi vyvoláním, poskytují alternativu k výše uvedenému přístupu. Durable Functions podporuje pouze konkrétní jazyky.

Selhání protokolu

Osvědčeným postupem je, že by funkce měla protokolovat všechna selhání při provádění úloh automatizace. To umožňuje správné řešení potíží s chybovými stavy. Azure Functions nativně podporuje integraci s application Přehledy jako systémem telemetrie.

Souběžnost

Ověřte požadavek na souběžnost pro vaši funkci automatizace. Souběžnost je omezená nastavením proměnné maxConcurrentRequests v souboru host.json. Toto nastavení omezuje počet souběžných instancí funkcí spuštěných v aplikaci funkcí. Vzhledem k tomu, že každá instance spotřebovává procesor a paměť, je potřeba tuto hodnotu upravit pro operace náročné na procesor. maxConcurrentRequests Pokud se zdá, že volání funkce jsou příliš pomalá nebo nejsou schopná dokončit, snižte. Další podrobnosti najdete v části Konfigurace chování hostitele pro lepší zpracování souběžnosti .

Idempotence

Ujistěte se, že je vaše automatizační funkce idempotentní. Azure Monitor i Event Grid můžou generovat výstrahy nebo události, které indikují průběh, jako je vaše předplacená událost, vyřešena, spuštěna, probíhá atd., váš prostředek se zřizuje, úspěšně se vytváří, atd., nebo dokonce odesílá falešná upozornění kvůli chybné konfiguraci. Ujistěte se, že vaše funkce funguje jenom na relevantních výstrahách a událostech a ignoruje všechny ostatní, aby nepravdivé nebo chybně nakonfigurované události nezpůsobily nežádoucí výsledky. Další informace najdete v tématu Návrh služby Azure Functions pro stejný vstup.

Event Grid

Pokud váš pracovní postup používá Event Grid, zkontrolujte, jestli váš scénář může vygenerovat velký objem událostí, a to dostatečně pro zalogování mřížky. Podívejte se na doručování zpráv Event Gridu a pokuste se zjistit, jak zpracovává události, když se doručení nepotvrdí, a odpovídajícím způsobem upravte logiku. Pracovní postup nákladového střediska neimplementuje další kontroly, protože sleduje pouze události vytváření prostředků ve skupině prostředků. Monitorování prostředků vytvořených v celém předplatném může generovat větší počet událostí, což vyžaduje odolnější zpracování.

Azure Monitor

Pokud se vygeneruje dostatečně velký počet upozornění a automatizace aktualizuje prostředky Azure, můžou být dosaženy limity omezování Azure Resource Manageru . To může negativně ovlivnit zbytek infrastruktury v tomto předplatném. Vyhněte se této situaci omezením četnosti upozornění generovaných službou Azure Monitor. Upozornění, která se generují pro konkrétní chybu, můžete také omezit. Další informace najdete v dokumentaci k upozorněním služby Azure Monitor.

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 najdete v tématu Přehled pilíře zabezpečení.

Řízení přístupu k funkci

Nastavením úrovně autorizace omezte přístup k funkci aktivované protokolem HTTP. Pomocí anonymního ověřování je funkce snadno přístupná pomocí adresy URL, například http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. Ověřování na úrovni funkce může obfusovat koncový bod HTTP vyžadováním klíčů funkcí v adrese URL. Tato úroveň je nastavena v souboru function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

V produkčním prostředí může být k zabezpečení funkce potřeba další strategie. V těchto scénářích se funkce spouští v rámci platformy Azure jinými službami Azure a nebudou vystaveny internetu. Autorizace funkcí je někdy dostatečná pro funkce, které jsou přístupné jako webhooky.

Zvažte přidání vrstev zabezpečení nad ověřováním funkcí, například

• ověřování pomocí klientských certifikátů nebo
• ujistěte se, že je volající součástí nebo má přístup k adresáři, který je hostitelem funkce, povolením ověřování služby App Service.

Ověřování na úrovni funkce je jedinou možností dostupnou pro skupiny akcí azure Monitoru pomocí Azure Functions.

Pokud je potřeba volat funkci z aplikace nebo služby třetí strany, doporučuje se k ní poskytnout přístup pomocí vrstvy SLUŽBY API Management . Tato vrstva by měla vynutit ověřování. Služba API Management má integrovanou úroveň consumption se službou Azure Functions, která umožňuje platit pouze v případě, že se rozhraní API spustí. Další informace najdete v tématu Vytvoření a zveřejnění funkcí pomocí OpenAPI.

Pokud volající služba podporuje koncové body služby nebo privátní propojení, je možné zvážit následující nákladné možnosti:

• Použijte vyhrazený plán služby App Service, ve kterém můžete funkce ve virtuální síti uzamknout, abyste k němu omezili přístup. To není možné v bezserverovém modelu založeném na spotřebě.
• Použijte plán Azure Functions Premium, který zahrnuje vyhrazenou virtuální síť, kterou budou vaše aplikace funkcí používat.

Pokud chcete porovnat ceny a funkce mezi těmito možnostmi, přečtěte si škálování a hostování Azure Functions.

Řízení přístupu k funkcím

Spravované identity pro prostředky Azure, funkce Microsoft Entra, zjednodušuje ověřování a přístup k dalším prostředkům a službám Azure. Kód nemusí spravovat přihlašovací údaje pro ověřování, protože ho spravuje ID Microsoft Entra.

Existují dva typy spravovaných identit:

• Spravované identity přiřazené systémem: Tyto identity se vytvářejí jako součást prostředku Azure a nedají se sdílet mezi více prostředky. Tyto položky se odstraní při odstranění prostředku. Použijte je pro scénáře, které zahrnují jeden prostředek Azure nebo které potřebují nezávislé identity. Oba scénáře používají identity přiřazené systémem, protože aktualizují pouze jeden prostředek. Spravované identity se vyžadují jenom k aktualizaci jiného prostředku. Funkce může například číst značky prostředků bez spravované identity. Podle těchto pokynů přidejte do funkce identitu přiřazenou systémem.

• Spravované identity přiřazené uživatelem: Tyto identity se vytvářejí jako samostatné prostředky Azure. Ty se dají sdílet napříč několika prostředky a je potřeba je explicitně odstranit, pokud už je nepotřebujete. Přečtěte si tyto pokyny k přidání identity přiřazené uživatelem do funkce. Použijte je pro scénáře, které:

  • Vyžadovat přístup k více prostředkům, které můžou sdílet jednu identitu, nebo
  • Potřebujete předběžnou autorizaci k zabezpečení prostředků během zřizování nebo
  • Mít prostředky, které se často recyklují, zatímco oprávnění musí být konzistentní.

Jakmile je identita přiřazená k funkci Azure, přiřaďte ji k přístupu k prostředkům pomocí řízení přístupu na základě role v Azure (Azure RBAC ). Pokud například chcete aktualizovat prostředek, musí být role Přispěvatel přiřazená identitě funkce.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

K odhadu nákladů použijte cenovou kalkulačku Azure. Tady jsou některé aspekty snížení nákladů.

Azure Logic Apps

Aplikace logiky mají cenový model průběžných plateb. Při každém spuštění aplikace logiky se měří triggery, akce a spuštění konektorů. Všechny úspěšné a neúspěšné akce, včetně triggerů, se považují za spuštění.

Aplikace logiky mají také pevný cenový model. Pokud potřebujete spouštět aplikace logiky, které komunikují se zabezpečenými prostředky ve virtuální síti Azure, můžete je vytvořit v prostředí integrační služby (ISE).

Podrobnosti najdete v tématu Cenový model pro Azure Logic Apps.

V této architektuře se aplikace logiky používají ve scénáři označování nákladového střediska k orchestraci pracovního postupu.

Integrované konektory se používají k připojení ke službě Azure Functions a odesílání e-mailových oznámení o dokončení úlohy automatizace. Funkce se zveřejňují jako webhook nebo rozhraní API pomocí triggeru HTTP. Aplikace logiky se aktivují jenom v případě, že dojde k požadavku HTTPS. To je nákladově efektivní způsob ve srovnání s návrhem, ve kterém se funkce průběžně dotazují a kontrolují určitá kritéria. Každý požadavek na dotazování se měří jako akce.

Další informace najdete na stránce s cenami služby Logic Apps.

Azure Functions

Azure Functions jsou k dispozici s následujícími třemi cenovými plány.

• Plán Consumption Jedná se o cenově nejvýhodnější bezserverový plán, který je k dispozici, kde platíte jenom za čas spuštění funkce. V rámci tohoto plánu můžou funkce běžet až 10 minut najednou.

• Plán Premium. Zvažte použití plánu Azure Functions Premium pro scénáře automatizace s dalšími požadavky, jako je vyhrazená virtuální síť, delší doba provádění atd. Tyto funkce můžou běžet až hodinu a měly by být zvoleny pro delší úlohy automatizace, jako jsou spouštění záloh, indexování databází nebo generování sestav.

• Plán služby App Service. Scénáře hybridní automatizace, které používají hybridní Připojení služby Aplikace Azure service, budou muset použít plán služby App Service. Funkce vytvořené v rámci tohoto plánu můžou běžet po neomezenou dobu, podobně jako u webové aplikace.

V těchto scénářích automatizace se Azure Functions používají pro úlohy, jako jsou aktualizace značek v ID Microsoft Entra nebo změna konfigurace služby Azure Cosmos DB vertikálním navýšením kapacity RU na vyšší hodnotu. Plán Consumption je vhodný pro tento případ použití, protože tyto úlohy jsou interaktivní a nejsou dlouhotrvající.

Azure Cosmos DB

Azure Cosmos DB účtuje zřízenou propustnost a spotřebované úložiště po hodinách. Zřízená propustnost se vyjadřuje v jednotkách žádostí za sekundu (RU/s), které se dají použít pro typické databázové operace, jako jsou vložení, čtení. Úložiště se účtuje za každou GB použitou pro uložená data a index. Další informace najdete v cenovém modelu služby Azure Cosmos DB.

Když v této architektuře požadavky na přístup k datům do služby Azure Cosmos DB překročí kapacitu v jednotkách žádostí (nebo RU), Azure Monitor aktivuje výstrahy. V reakci na tato upozornění je skupina akcí služby Azure Monitor nakonfigurovaná tak, aby volala funkci automatizace. Funkce škáluje jednotky RU na vyšší hodnotu. To pomáhá udržet náklady mimo provoz, protože platíte jenom za prostředky, které vaše úlohy potřebují po hodinách.

Pokud chcete získat rychlý odhad nákladů na vaši úlohu, použijte kalkulačku kapacity služby Azure Cosmos DB.

Další informace najdete v části Náklady v architektuře Microsoft Azure Well-Architected Framework.

Aspekty nasazení

U důležitých pracovních postupů automatizace, které spravují chování vaší aplikace, je potřeba dosáhnout nulového výpadku nasazení pomocí efektivního kanálu DevOps. Další informace najdete v tématu nasazení bezserverového back-endu.

Pokud automatizace pokrývá více aplikací, ponechte prostředky vyžadované automatizací v samostatné skupině prostředků. Jednu skupinu prostředků je možné sdílet mezi automatizací a prostředky aplikace, pokud automatizace pokrývá jednu aplikaci.

Pokud pracovní postup zahrnuje řadu automatizačních funkcí, seskupte funkce, které se týkají jednoho scénáře v jedné aplikaci funkcí. Další informace najdete v článku Správa aplikace funkcí.

Při nasazování aplikace ji budete muset monitorovat. Zvažte použití Přehledy aplikací, abyste vývojářům umožnili monitorovat výkon a zjišťovat problémy.

Další informace najdete v části DevOps v architektuře Microsoft Azure Well-Architected Framework.

Imperativní akce u prostředků Azure

V obou výše uvedených scénářích byl konečným výsledkem změna stavu prostředků Azure prostřednictvím přímé interakce Azure Resource Manageru. I když to byl zamýšlený výsledek, zvažte, jaký dopad to má na vaše prostředí, pokud se upravené prostředky původně nasadily deklarativním způsobem, jako jsou šablony Bicep nebo Terraformu. Pokud se tyto změny nereplikují zpět do zdrojových šablon, může další použití těchto šablon vrátit změny provedené touto automatizací zpět. Zvažte dopad kombinování imperativních změn prostředků Azure, které se běžně nasazují prostřednictvím šablon.

Nasazení tohoto scénáře

Pokud chcete nasadit scénář nákladového centra, přečtěte si postup nasazení na GitHubu.

Další kroky

• Školení: Úvod do Azure Functions
• Dokumentace: Úvod do Azure Functions
• Co je Azure Event Grid?

Související prostředky

• Návod k kódu: Bezserverová aplikace se službou Functions
• Návrh architektury bezserverových funkcí
• Referenční architektury bezserverových funkcí