Händelsebaserad molnautomatisering

Att automatisera arbetsflöden och repetitiva uppgifter i molnet med hjälp av serverlösa tekniker kan avsevärt förbättra produktiviteten för en organisations DevOps-team. En serverlös modell passar bäst för automatiseringsscenarier som passar en händelsedriven metod.

Arkitektur

Scenarier

Den här artikeln illustrerar två viktiga scenarier för molnautomatisering:

1. Taggning av kostnadsställe: Den här implementeringen spårar kostnadsställena för varje Azure-resurs. Azure Policy-tjänsten taggar alla nya resurser i en grupp med ett standardkostnadsställe-ID. Azure Event Grid övervakar händelser för att skapa resurser och anropar sedan en Azure-funktion. Funktionen interagerar med Microsoft Entra-ID och validerar kostnadsställe-ID:t för den nya resursen. Om det är annorlunda uppdateras taggen och ett e-postmeddelande skickas till resursägaren. REST-frågorna för Microsoft Entra-ID:t hånas för enkelhetens skull. Microsoft Entra-ID kan också integreras med hjälp av Microsoft Graph PowerShell-modulen eller Microsoft Authentication Library (MSAL) för Python.

2. Begränsningssvar: I det här exemplet övervakas en Azure Cosmos DB-databas för begränsning. Azure Monitor-aviseringar utlöses när dataåtkomstbegäranden till Azure Cosmos DB överskrider kapaciteten i enheter för programbegäran (eller RU:er). En Azure Monitor-åtgärdsgrupp har konfigurerats för att anropa automationsfunktionen som svar på dessa aviseringar. Funktionen skalar ru:erna till ett högre värde, ökar kapaciteten och stoppar i sin tur aviseringarna.

Referensimplementeringen för scenario ett är tillgänglig på GitHub.

Funktionerna i dessa serverlösa molnautomatiseringsscenarier skrivs ofta i PowerShell och Python, två av de vanligaste skriptspråken som används i systemautomatisering. De distribueras med Azure Functions Core Tools i Azure CLI. Du kan också använda PowerShell-cmdleten Az.Functions för att distribuera och hantera Azure Functions.

Arbetsflöde

Scenarier för händelsebaserad automatisering implementeras bäst med Hjälp av Azure Functions. De följer dessa vanliga mönster:

• Svara på händelser på resurser. Det här är svar på händelser som en Azure-resurs eller resursgrupp som skapas, tas bort, ändras och så vidare. Det här mönstret använder Event Grid för att utlösa funktionen för sådana händelser. Kostnadsställetaggningsscenariot är ett exempel på det här mönstret. Andra vanliga scenarier är:

  • ge DevOps-teamen åtkomst till nyligen skapade resursgrupper,
  • skickar ett meddelande till DevOps när en resurs tas bort och
  • svara på underhållshändelser för resurser som virtuella Azure-datorer (VM).

• Schemalagda aktiviteter. Det här är vanligtvis underhållsaktiviteter som körs med hjälp av timerutlösta funktioner. Exempel på det här mönstret är:

  • stoppa en resurs på natten och börja på morgonen,
  • läsa Blob Storage-innehåll med jämna mellanrum och konvertera till ett Azure Cosmos DB-dokument.
  • regelbundet söka efter resurser som inte längre används och ta bort dem, och
  • automatiserade säkerhetskopieringar.

• Bearbeta Azure-aviseringar. Det här mönstret använder enkel integrering av Azure Monitor-aviseringar och åtgärdsgrupper med Azure Functions. Funktionen vidtar vanligtvis åtgärdsåtgärder som svar på mått, logganalys och aviseringar som kommer från programmen och infrastrukturen. Scenariot med begränsningssvar är ett exempel på det här mönstret. Andra vanliga scenarier är:

  • trunkera tabellen när SQL Database når maximal storlek,
  • starta om en tjänst på en virtuell dator när den felaktigt stoppas och
  • skickar meddelanden om en funktion misslyckas.

• Orkestrera med externa system. Det här mönstret möjliggör integrering med externa system med hjälp av Logic Apps för att orkestrera arbetsflödet. Logic Apps-anslutningsappar kan enkelt integreras med flera tjänster från tredje part samt Microsoft-tjänster till exempel Microsoft 365. Azure Functions kan användas för den faktiska automatiseringen. Kostnadsställetaggningsscenariot visar det här mönstret. Andra vanliga scenarier är:

  • övervaka IT-processer, till exempel ändringsbegäranden eller godkännanden, och
  • skicka e-postavisering när automationsaktiviteten har slutförts.

• Exponera som en webbkrok eller ETT API. Automatiseringsuppgifter som använder Azure Functions kan integreras i program från tredje part eller till och med kommandoradsverktyg genom att exponera funktionen som en webbkrok/API med hjälp av en HTTP-utlösare. Flera autentiseringsmetoder är tillgängliga i både PowerShell och Python för att skydda extern åtkomst till funktionen. Automatiseringen sker som svar på appspecifika externa händelser, till exempel integrering med power apps eller GitHub. Vanliga scenarier är:

  • utlöser automatisering för en tjänst som misslyckas och
  • registrera användare till organisationens resurser.

• Skapa ChatOps-gränssnitt. Det här mönstret gör det möjligt för kunder att skapa ett chattbaserat driftsgränssnitt och köra utvecklings- och driftfunktioner och kommandon i linje med mänskligt samarbete. Detta kan integreras med Azure Bot Framework och använda Microsoft Teams- eller Slack-kommandon för distribution, övervakning, vanliga frågor och så vidare. Ett ChatOps-gränssnitt skapar ett realtidssystem för att hantera produktionsincidenter, där varje steg dokumenteras automatiskt i chatten. Läs Hur ChatOps kan hjälpa dig DevOps bättre för mer information.

• Hybridautomatisering. Det här mönstret använder Azure App Service Hybrid Anslut ions för att installera en programvarukomponent på den lokala datorn. Den här komponenten ger säker åtkomst till resurser på den datorn. Möjligheten att hantera hybridmiljöer är för närvarande tillgänglig i Windows-baserade system med hjälp av PowerShell-funktioner. Vanliga scenarier är:

  • hantera dina lokala datorer och
  • hantera andra system bakom brandväggen (till exempel en lokal SQL Server) via en hoppserver.

Komponenter

Arkitekturen består av följande komponenter:

• Azure Functions. Azure Functions tillhandahåller de händelsedrivna, serverlösa beräkningsfunktionerna i den här arkitekturen. En funktion utför automatiseringsuppgifter när den utlöses av händelser eller aviseringar. I två scenarier anropas en funktion med en HTTP-begäran. Kodkomplexitet bör minimeras genom att utveckla funktionen som är tillståndslös och idempotent.

  Flera körningar av en idempotent-funktion skapar samma resultat. För att upprätthålla idempotens hålls funktionsskalningen i begränsningsscenariot förenklad. Se till att skala upp eller ned på rätt sätt i verklig automatisering. Läs Optimera prestanda och tillförlitlighet för Azure Functions för bästa praxis när du skriver dina funktioner.

• Azure Logic Apps. Logic Apps kan användas för att utföra enklare uppgifter som enkelt implementeras med hjälp av de inbyggda anslutningsprogrammen. Dessa uppgifter kan sträcka sig från e-postaviseringar till integrering med externa hanteringsprogram. Om du vill lära dig hur du använder Logic Apps med program från tredje part läser du grundläggande företagsintegrering i Azure.

  Logic Apps tillhandahåller en visuell designer utan kod eller låg kod och kan användas ensam i vissa automatiseringsscenarier. Läs den här jämförelsen mellan Azure Functions och Logic Apps för att se vilken tjänst som passar ditt scenario.

• Event Grid. Event Grid har inbyggt stöd för händelser från andra Azure-tjänster samt anpassade händelser (kallas även anpassade ämnen). Drifthändelser som att skapa resurser kan enkelt spridas till automationsfunktionen med hjälp av Event Grids inbyggda mekanism.

  Event Grid förenklar den händelsebaserade automatiseringen med en publiceringsprenumereringsmodell, vilket möjliggör tillförlitlig automatisering för händelser som levereras via HTTPS.

• Azure Monitor. Azure Monitor-aviseringar kan övervaka kritiska villkor och vidta korrigerande åtgärder med hjälp av Azure Monitor-åtgärdsgrupper. Dessa åtgärdsgrupper är enkelt integrerade med Azure Functions. Det här är användbart för att hålla utkik efter och åtgärda eventuella feltillstånd i infrastrukturen, till exempel databasbegränsning.

• Automatiseringsåtgärd. Det här breda blocket representerar andra tjänster som din funktion kan interagera med för att tillhandahålla automatiseringsfunktionerna. Till exempel Microsoft Entra-ID för taggverifiering som i det första scenariot eller en databas som ska etableras som i det andra scenariot.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Motståndskraft

Azure Functions

Hantera HTTP-timeouter

För att undvika HTTP-timeouter för en längre automatiseringsaktivitet köar du den här händelsen i en Service Bus och hanterar den faktiska automatiseringen i en annan funktion. Scenariot för automatisering av begränsningssvar illustrerar det här mönstret, även om den faktiska RU-etableringen för Azure Cosmos DB är snabb.

Durable Functions, som upprätthåller tillståndet mellan anrop, är ett alternativ till ovanstående metod. Durable Functions stöder endast specifika språk.

Loggfel

Som bästa praxis bör funktionen logga eventuella fel vid utförandet av automatiseringsuppgifter. Detta gör det möjligt att felsöka felvillkoren korrekt. Azure Functions har inbyggt stöd för integrering med Application Insights som telemetrisystem.

Samtidighet

Kontrollera samtidighetskravet för automationsfunktionen. Samtidighet begränsas genom att variabeln maxConcurrentRequests anges i filen host.json. Den här inställningen begränsar antalet samtidiga funktionsinstanser som körs i funktionsappen. Eftersom varje instans förbrukar cpu och minne måste det här värdet justeras för processorintensiva åtgärder. Sänk om maxConcurrentRequests dina funktionsanrop verkar vara för långsamma eller inte kan slutföras. Mer information finns i avsnittet Konfigurera värdbeteenden för att bättre hantera samtidighet .

Idempotens

Kontrollera att automationsfunktionen är idempotent. Både Azure Monitor och Event Grid kan generera aviseringar eller händelser som indikerar att utvecklingen, till exempel att din prenumerationshändelse har lösts, utlösts, pågår osv., att resursen etableras, skapas korrekt osv. eller till och med skickar falska aviseringar på grund av en felkonfiguration. Kontrollera att funktionen endast fungerar på relevanta aviseringar och händelser och ignorerar alla andra, så att falska eller felkonfigurerade händelser inte orsakar oönskade resultat. Mer information finns i Designa Azure Functions för identiska indata.

Event Grid

Om ditt arbetsflöde använder Event Grid kontrollerar du om ditt scenario kan generera en hög mängd händelser, tillräckligt för att täpper till rutnätet. Se Leverans av Event Grid-meddelanden och försök igen för att förstå hur det hanterar händelser när leveransen inte bekräftas och ändra logiken i enlighet med detta. Cost Center-arbetsflödet implementerar inte ytterligare kontroller för detta, eftersom det endast bevakar händelser för att skapa resurser i en resursgrupp. Övervakning av resurser som skapats i en hel prenumeration kan generera ett större antal händelser, vilket kräver en mer motståndskraftig hantering.

Azure Monitor

Om ett tillräckligt stort antal aviseringar genereras och automatiseringen uppdaterar Azure-resurser kan begränsningsgränserna för Azure Resource Manager nås. Detta kan påverka resten av infrastrukturen i prenumerationen negativt. Undvik den här situationen genom att begränsa frekvensen för aviseringar som genereras av Azure Monitor. Du kan också begränsa de aviseringar som genereras för ett visst fel. Mer information finns i dokumentationen om Azure Monitor-aviseringar .

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Kontrollera åtkomsten till funktionen

Begränsa åtkomsten till en HTTP-utlöst funktion genom att ange auktoriseringsnivån. Med anonym autentisering är funktionen lättillgänglig med en URL som http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. Autentisering på funktionsnivå kan dölja http-slutpunkten genom att kräva funktionsnycklar i URL:en. Den här nivån anges i file function.json:

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

För produktionsmiljön kan ytterligare strategier krävas för att skydda funktionen. I dessa scenarier körs funktionerna i Azure-plattformen av andra Azure-tjänster och kommer inte att exponeras för Internet. Funktionsauktorisering räcker ibland för funktioner som används som webbkrokar.

Överväg att lägga till säkerhetslager ovanpå funktionsautentisering, till exempel

• autentisera med klientcertifikat, eller
• se till att anroparen är en del av eller har åtkomst till katalogen som är värd för funktionen genom att aktivera App Service-autentisering.

Autentisering på funktionsnivå är det enda alternativet som är tillgängligt för Azure Monitor-åtgärdsgrupper med hjälp av Azure Functions.

Om funktionen behöver anropas från ett program eller en tjänst från tredje part rekommenderar vi att du ger åtkomst till den med ett API Management-lager . Det här lagret bör framtvinga autentisering. API Management har en förbrukningsnivå som är integrerad med Azure Functions, vilket gör att du bara kan betala om API:et körs. Mer information finns i Skapa och exponera dina funktioner med OpenAPI.

Om den anropande tjänsten stöder tjänstslutpunkter eller en privat länk kan följande alternativ övervägas:

• Använd en dedikerad App Service-plan där du kan låsa funktionerna i ett virtuellt nätverk för att begränsa åtkomsten till den. Detta är inte möjligt i en förbrukningsbaserad serverlös modell.
• Använd Azure Functions Premium-planen, som innehåller ett dedikerat virtuellt nätverk som ska användas av dina funktionsappar.

Om du vill jämföra priser och funktioner mellan de här alternativen läser du Skala och hantera Azure Functions.

Kontrollera vad funktionen kan komma åt

Hanterade identiteter för Azure-resurser, en Microsoft Entra-funktion, förenklar hur funktionen autentiserar och får åtkomst till andra Azure-resurser och -tjänster. Koden behöver inte hantera autentiseringsuppgifterna eftersom den hanteras av Microsoft Entra-ID.

Det finns två typer av hanterade identiteter:

• Systemtilldelade hanterade identiteter: Dessa skapas som en del av Azure-resursen och kan inte delas mellan flera resurser. Dessa tas bort när resursen tas bort. Använd dessa för scenarier som omfattar en enskild Azure-resurs eller som behöver oberoende identiteter. Båda scenarierna använder systemtilldelade identiteter eftersom de endast uppdaterar en enda resurs. Hanterade identiteter krävs bara för att uppdatera en annan resurs. En funktion kan till exempel läsa resurstaggar utan en hanterad identitet. Se de här anvisningarna för att lägga till en systemtilldelad identitet i din funktion.

• Användartilldelade hanterade identiteter: Dessa skapas som fristående Azure-resurser. Dessa kan delas mellan flera resurser och måste tas bort uttryckligen när de inte längre behövs. Läs de här anvisningarna om hur du lägger till användartilldelad identitet i din funktion. Använd dessa för scenarier som:

  • Kräv åtkomst till flera resurser som kan dela en enda identitet, eller
  • Behöver förhandsauktorisering för att skydda resurser under etableringen, eller
  • Ha resurser som återanvänds ofta, medan behörigheter måste vara konsekventa.

När identiteten har tilldelats till Azure-funktionen tilldelar du den en roll med hjälp av rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att få åtkomst till resurserna. Om du till exempel vill uppdatera en resurs måste deltagarrollen tilldelas till funktionens identitet.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Följande är några överväganden för att sänka kostnaderna.

Azure Logic Program-program

Logikappar har en prismodell för betala per användning. Utlösare, åtgärder och körning av anslutningsprogram mäts varje gången en logikapp körs. Alla lyckade och misslyckade åtgärder, inklusive utlösare, räknas som körningar.

Logikappar har också en fast prismodell. Om du behöver köra logikappar som kommunicerar med skyddade resurser i ett virtuellt Azure-nätverk kan du skapa dem i en Integration Service Environment (ISE).

Mer information finns i Prismodell för Azure Logic Apps.

I den här arkitekturen används logikappar i kostnadsställetaggningsscenariot för att samordna arbetsflödet.

Inbyggda anslutningsappar används för att ansluta till Azure Functions och skicka e-postaviseringar en när en automatiseringsuppgift har slutförts. Funktionerna exponeras som en webbkrok/API med hjälp av en HTTP-utlösare. Logikappar utlöses endast när en HTTPS-begäran inträffar. Detta är ett kostnadseffektivt sätt jämfört med en design där funktioner kontinuerligt avsöker och söker efter vissa kriterier. Varje avsökningsbegäran mäts som en åtgärd.

Mer information finns i avsnittet med priser för Logic Apps.

Azure Functions

Azure Functions är tillgängliga med följande tre prisplaner.

• Förbrukningsplan. Det här är den mest kostnadseffektiva, serverlösa planen, där du bara betalar för den tid som funktionen körs. I den här planen kan funktioner köras i upp till 10 minuter åt gången.

• Premium-plan. Överväg att använda Azure Functions Premium-plan för automatiseringsscenarier med ytterligare krav, till exempel ett dedikerat virtuellt nätverk, en längre körningstid och så vidare. Dessa funktioner kan köras i upp till en timme och bör väljas för längre automatiseringsuppgifter som att köra säkerhetskopior, databasindexering eller generera rapporter.

• App Service-plan. Hybridautomatiseringsscenarier som använder Azure App Service Hybrid-Anslut ioner måste använda App Service-planen. Funktionerna som skapas under den här planen kan köras under obegränsad varaktighet, ungefär som en webbapp.

I dessa automatiseringsscenarier används Azure Functions för uppgifter som att uppdatera taggar i Microsoft Entra-ID eller ändra Azure Cosmos DB-konfiguration genom att skala upp RU:erna till ett högre värde. Förbrukningsplanen är lämplig för det här användningsfallet eftersom dessa uppgifter är interaktiva och inte tidskrävande.

Azure Cosmos DB

Azure Cosmos DB fakturerar för etablerat dataflöde och förbrukad lagring per timme. Etablerat dataflöde uttrycks i enheter för begäranden per sekund (RU/s), som kan användas för vanliga databasåtgärder, till exempel infogningar, läsningar. Lagring debiteras för varje GB som används för dina lagrade data och index. Mer information finns i Prismodellen för Azure Cosmos DB.

När dataåtkomstbegäranden till Azure Cosmos DB överskrider kapaciteten i enheter för programbegäran (eller RU:er) i den här arkitekturen utlöser Azure Monitor aviseringar. Som svar på dessa aviseringar konfigureras en Azure Monitor-åtgärdsgrupp för att anropa automationsfunktionen. Funktionen skalar ru:erna till ett högre värde. Detta hjälper till att hålla nere kostnaden eftersom du bara betalar för de resurser som dina arbetsbelastningar behöver per timme.

Om du vill få en snabb kostnadsuppskattning av din arbetsbelastning använder du Kapacitetskalkylatorn för Azure Cosmos DB.

Mer information finns i avsnittet Kostnad i Microsoft Azure Well-Architected Framework.

Att tänka på vid distribuering

För kritiska automatiseringsarbetsflöden som hanterar beteendet för ditt program måste noll driftstoppsdistribution uppnås med hjälp av en effektiv DevOps-pipeline. Mer information finns i serverlös serverdelsdistribution.

Om automatiseringen omfattar flera program behåller du de resurser som krävs av automatiseringen i en separat resursgrupp. En enskild resursgrupp kan delas mellan automatiserings- och programresurser om automatiseringen omfattar ett enda program.

Om arbetsflödet omfattar ett antal automatiseringsfunktioner grupperar du funktionerna i ett scenario i en enda funktionsapp. Mer information finns i Hantera funktionsapp .

När du distribuerar ditt program måste du övervaka det. Överväg att använda Application Insights för att göra det möjligt för utvecklarna att övervaka prestanda och identifiera problem.

Mer information finns i avsnittet DevOps i Microsoft Azure Well-Architected Framework.

Imperativa åtgärder för Azure-resurser

I båda scenarierna ovan var slutresultatet en ändring i Azure-resurstillståndet via direkt Azure Resource Manager-interaktion. Även om detta var det avsedda resultatet bör du överväga vilken inverkan det kan ha på din miljö om de ändrade resurserna ursprungligen distribuerades deklarativt, till exempel av Bicep- eller Terraform-mallar. Om inte dessa ändringar replikeras tillbaka till källmallarna kan nästa användning av dessa mallar ångra de ändringar som gjorts av den här automatiseringen. Överväg effekten av att blanda imperativa ändringar i Azure-resurser som rutinmässigt distribueras via mallar.

Distribuera det här scenariot

Information om hur du distribuerar cost center-scenariot finns i distributionsstegen på GitHub.

Nästa steg

• Utbildning: Introduktion till Azure Functions
• Dokumentation: Introduktion till Azure Functions
• Vad är Azure Event Grid?

Relaterade resurser

• Genomgång av kod: Serverlöst program med Functions
• Arkitekturdesign för serverlösa funktioner
• Referensarkitekturer för serverlösa funktioner