Att automatisera arbetsflöden och repetitiva uppgifter i molnet med hjälp av serverlös teknik 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:
Kostnadsställetaggning: Den här implementeringen spårar kostnadsställena för varje Azure-resurs. Azure Policy-tjänstentaggar 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 Azure Active Directory 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 Azure Active Directory hånas för enkelhetens skull. Azure AD kan också integreras med hjälp av Azure AD PowerShell-modulen eller MSAL för Python-biblioteket.
Begränsningssvar: Det här exemplet övervakar 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.
Anteckning
Dessa lösningar är inte de enda som kan utföra dessa uppgifter och visas som illustrerande för hur serverlös teknik kan reagera på miljösignaler (händelser) och påverka förändringar i din miljö. Där det är praktiskt kan du använda plattformsbaserade lösningar framför anpassade lösningar. Azure Cosmos DB stöder till exempel autoskalningsdataflöde som ett internt alternativ till scenariot med begränsningssvar.
Referensimplementeringen för scenario ett är tillgänglig på GitHub.
Funktionerna i dessa serverlösa scenarier för molnautomatisering 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
Händelsebaserade automatiseringsscenarier 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:
- bevilja DevOps-teamen åtkomst till nyligen skapade resursgrupper,
- skicka ett meddelande till DevOps när en resurs tas bort och
- svara på underhållshändelser för resurser som Azure Virtual Machines (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 stoppas felaktigt och
- skicka 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 som 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 automationsuppgiften 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. Här följer exempel på några vanliga scenarier:
- 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 operativt grä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 Så här kan ChatOps hjälpa dig att förbättra DevOps för mer information.
Hybridautomatisering. Det här mönstret använder Azure App Service hybridanslutningar 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. Här följer exempel på några vanliga scenarier:
- 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ålla händelsedrivna, serverlösa beräkningsfunktioner 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. Kodkomplexiteten 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. I verklig automatisering bör du skala upp eller ned på rätt sätt. 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 vara allt 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 händelsebaserad automatisering med en publicera-prenumerera-modell, 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 automatiseringsfunktionen. Till exempel Azure Active Directory för taggvalidering som i det första scenariot, eller en databas som ska etableras som i det andra scenariot.
Överväganden
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.
Återhämtning
Azure Functions
Hantera HTTP-timeouter
För att undvika HTTP-timeouter för en längre automatiseringsaktivitet placerar 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. På så sätt kan feltillstånden felsökas korrekt. Azure Functions har inbyggt stöd för integrering med Application Insights som telemetrisystem.
Samtidighet
Kontrollera samtidighetskravet för din automationsfunktion. 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 status, till exempel att din prenumerationshändelse löses, utlöses, pågår osv., att resursen etableras, skapas korrekt osv. eller till och med skickar falska aviseringar på grund av en felaktig konfiguration. Se till att din funktion endast agerar 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 stor mängd händelser, tillräckligt för att täpp 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. Arbetsflödet för kostnadsställe implementerar inte ytterligare kontroller för detta, eftersom det endast söker efter 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 Automation 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 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, till exempel 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 på Azure-plattformen av andra Azure-tjänster och exponeras inte för Internet. Funktionsauktorisering räcker ibland för funktioner som används som webhooks.
Överväg att lägga till säkerhetslager ovanpå funktionsautentisering, till exempel,
- autentisera med klientcertifikat, eller
- kontrollera 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 som använder Azure Functions.
Om funktionen måste 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 privat länk kan följande dyrare 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 dessa alternativ läser du Azure Functions skala och värdtjänster.
Kontrollera vad funktionen kan komma åt
Hanterade identiteter för Azure-resurser, en Azure Active Directory-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 Azure AD.
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 bara 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 funktionen.
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
- Du behöver förauktorisering för att skydda resurser under etableringen, eller
- Ha resurser som återanvänds ofta, medan behörigheterna 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 rollen Deltagare tilldelas till funktionens identitet.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra driftseffektiviteten. Mer information finns i Översikt över grundpelare för kostnadsoptimering.
Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Följande är några saker att tänka på när du ska sänka kostnaderna.
Azure Logic Apps
Logic Apps har en prismodell där du betalar per användning. Utlösare, åtgärder och anslutningskörningar mäts varje gång en logikapp körs. Alla lyckade och misslyckade åtgärder, inklusive utlösare, betraktas 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 orkestrera 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 webhook/API med hjälp av en HTTP-utlösare. Logikappar utlöses bara 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 Prissättning 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 som är tillgänglig, där du bara betalar för den tid som funktionen körs. Enligt 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äkerhetskopieringar, databasindexering eller generera rapporter.
App Service plan. Hybridautomatiseringsscenarier som använder Azure App Service hybridanslutningar 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 Azure Active Directory eller ändra Azure Cosmos DB-konfigurationen 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 långvariga.
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 programbegäran per sekund (RU/s), som kan användas för vanliga databasåtgärder, till exempel infogningar, läsningar. Lagringen 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 kostnaderna 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.
Distributionsöverväganden
För kritiska automatiseringsarbetsflöden som hanterar beteendet för ditt program måste distributionen utan driftavbrott 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 automations- 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 utvecklare att övervaka prestanda och identifiera problem.
Mer information finns i Avsnittet om 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 interaktion med Azure Resource Manager. Även om det här 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 dina källmallar 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 distribueras rutinmässigt via mallar.
Distribuera det här scenariot
Information om hur du distribuerar kostnadsställescenariot finns i distributionsstegen på GitHub.
Nästa steg
- Utbildning: Introduktion till Azure Functions
- Dokumentation: Introduktion till Azure Functions
- Vad är Azure Event Grid?