Runbook-körning i Azure Automation

Med processautomatisering i Azure Automation kan du skapa och hantera PowerShell, PowerShell-arbetsflöden och grafiska runbooks. Mer information finns i Azure Automation-runbooks.

Automation kör dina runbooks utifrån den logik som har definierats i dem. Om en runbook avbryts startas den om i början. Det här beteendet kräver att du skriver runbooks som stöder omstart om tillfälliga problem uppstår.

När du startar en runbook i Azure Automation skapas ett jobb, vilket är en enda körningsinstans av runbooken. Varje jobb får åtkomst till Azure-resurser genom att upprätta en anslutning till din Azure-prenumeration. Jobbet kan bara komma åt resurser i ditt datacenter om dessa resurser är tillgängliga från det offentliga molnet.

Azure Automation tilldelar en arbetare att köra varje jobb under runbook-körningen. Medan arbetare delas av många Automation-konton isoleras jobb från olika Automation-konton från varandra. Du kan inte styra vilka arbetstjänster som dina jobbbegäranden ska ha.

När du visar listan över runbooks i Azure Portal visas status för varje jobb som har startats för varje runbook. Azure Automation lagrar jobbloggar i högst 30 dagar.

Följande diagram visar livscykeln för ett Runbook-jobb för PowerShell-runbooks, PowerShell Workflow-runbooks och grafiska runbooks.

Runbook-körningsmiljö

Runbooks i Azure Automation kan köras på antingen en Azure-sandbox-miljö eller en Hybrid Runbook Worker.

När runbooks är utformade för att autentisera och köra mot resurser i Azure körs de i en Azure-sandbox-miljö. Azure Automation tilldelar en arbetare att köra varje jobb under Runbook-körningen i sandbox-miljön. Medan arbetare delas av många Automation-konton isoleras jobb från olika Automation-konton från varandra. Jobb som använder samma sandbox-miljö är bundna av resursbegränsningarna i sandbox-miljön. Sandbox-miljön i Azure stöder inte interaktiva åtgärder.

Du kan också använda en Hybrid Runbook Worker för att köra runbooks direkt på datorn som är värd för rollen och mot lokala resurser i miljön. Azure Automation lagrar och hanterar runbooks och levererar dem sedan till en eller flera tilldelade datorer.

Om du aktiverar Azure Firewall i Azure Storage, Azure Key Vault eller Azure SQL blockeras åtkomst från Azure Automation-runbooks för dessa tjänster. Åtkomst blockeras även när brandväggsfelet för att tillåta betrodda Microsoft-tjänster är aktiverat, eftersom Automation inte ingår i listan över betrodda tjänster. Med en aktiverad brandvägg kan åtkomst endast göras med hjälp av en Hybrid Runbook Worker och en tjänstslutpunkt för virtuellt nätverk.

I följande tabell visas några runbook-körningsuppgifter med den rekommenderade körningsmiljön som anges för var och en.

Tillfällig lagring i en sandbox-miljö

Om du behöver skapa temporära filer som en del av runbook-logiken kan du använda temp-mappen (dvs $env:TEMP. ) i Azure-sandbox-miljön för runbooks som körs i Azure. Den enda begränsningen är att du inte kan använda mer än 1 GB diskutrymme, vilket är kvoten för varje sandbox-miljö. När du arbetar med PowerShell-arbetsflöden kan det här scenariot orsaka ett problem eftersom PowerShell-arbetsflöden använder kontrollpunkter och skriptet kan göras om i en annan sandbox-miljö.

Med hybridsandboxen kan du använda C:\temp baserat på tillgängligheten för lagring på en Hybrid Runbook Worker. Men enligt rekommendationer för virtuella Azure-datorer bör du inte använda den tillfälliga disken i Windows eller Linux för data som behöver sparas.

Resurser

Dina runbooks måste innehålla logik för att hantera resurser, till exempel virtuella datorer, nätverket och resurser i nätverket. Resurser är knutna till en Azure-prenumeration och runbooks kräver lämpliga autentiseringsuppgifter för att få åtkomst till alla resurser. Ett exempel på hur du hanterar resurser i en runbook finns i Hantera resurser.

Säkerhet

Azure Automation använder Microsoft Defender för molnet för att tillhandahålla säkerhet för dina resurser och identifiera kompromisser i Linux-system. Säkerhet tillhandahålls för dina arbetsbelastningar, oavsett om resurserna finns i Azure eller inte. Se Introduktion till autentisering i Azure Automation.

Defender för molnet begränsar användare som kan köra skript, antingen signerade eller osignerade, på en virtuell dator. Om du är en användare med rotåtkomst till en virtuell dator måste du uttryckligen konfigurera datorn med en digital signatur eller inaktivera den. Annars kan du bara köra ett skript för att tillämpa operativsystemuppdateringar när du har skapat ett Automation-konto och aktiverat rätt funktion.

Prenumerationer

En Azure-prenumeration är ett avtal med Microsoft om att använda en eller flera molnbaserade tjänster som du debiteras för. Du kan hantera flera prenumerationer från samma Automation-konto om de autentiseringsuppgifter du använder har åtkomst till flera prenumerationer.

Merit

En runbook kräver lämpliga autentiseringsuppgifter för att få åtkomst till alla resurser, oavsett om det gäller Azure- eller tredjepartssystem. Dessa autentiseringsuppgifter lagras i Azure Automation, Key Vault osv.

Azure Monitor

Azure Automation kan använda Azure Monitor för att övervaka sina datoråtgärder.

Runbook-behörigheter

En runbook behöver behörigheter för autentisering till Azure via autentiseringsuppgifter. Se Översikt över Azure Automation-autentisering.

Moduler

Azure Automation innehåller följande PowerShell-moduler:

• Orchestrator.AssetManagement.Cmdlets – innehåller flera interna cmdletar som bara är tillgängliga när du kör runbooks i Azure-sandbox-miljön eller på en Windows Hybrid Runbook Worker. Dessa cmdletar är utformade för att användas i stället för Azure PowerShell cmdletar för att interagera med dina kontoresurser för Automation.
• Az.Automation – den rekommenderade PowerShell-modulen för interaktion med Azure Automation som ersätter AzureRM Automation-modulen. Modulen Az.Automation ingår inte automatiskt när du skapar ett Automation-konto och du behöver importera dem manuellt.
• AzureRM.Automation – installeras som standard när du skapar ett Automation-konto.

Det stöds också installerbara moduler, baserat på de cmdletar som dina runbooks och DSC-konfigurationer kräver. Mer information om de moduler som är tillgängliga för dina runbooks och DSC-konfigurationer finns i Hantera moduler i Azure Automation.

Certifikat

Azure Automation använder certifikat för autentisering i Azure eller lägger till dem i Azure- eller tredjepartsresurser. Certifikaten lagras på ett säkert sätt för åtkomst via runbooks och DSC-konfigurationer.

Dina runbooks kan använda självsignerade certifikat, som inte är signerade av en certifikatutfärdare (CA). Läs mer i Skapa ett nytt certifikat.

Projekt

Azure Automation stöder en miljö för att köra jobb från samma Automation-konto. En enda runbook kan ha många jobb som körs samtidigt. Ju fler jobb du kör samtidigt, desto oftare kan de skickas till samma sandbox-miljö. Högst 10 jobb kan köras i en sandbox-miljö. En sandbox-miljö tas bort när inga jobb körs i den. Därför bör den inte användas för att spara filer.

Jobb som körs i samma sandbox-process kan påverka varandra. Ett exempel är att köra cmdleten Disconnect-AzAccount . Körningen av den här cmdleten kopplar från varje runbook-jobb i den delade sandbox-processen. Ett exempel på hur du arbetar med det här scenariot finns i Förhindra samtidiga jobb.

Jobbstatusar

I följande tabell beskrivs de statusar som är möjliga för ett jobb. Du kan visa en statussammanfattning för alla runbook-jobb eller granska information om ett visst runbook-jobb i Azure-portalen. Du kan också konfigurera integrering med Log Analytics-arbetsytan för att vidarebefordra runbook-jobbstatus och jobbströmmar. Mer information om integrering med Azure Monitor-loggar finns i Vidarebefordra jobbstatus och jobbströmmar från Automation till Azure Monitor-loggar. Se även Hämta jobbstatusar för ett exempel på hur du arbetar med statusar i en runbook.

Aktivitetsloggning

Vid körning av runbooks i Azure Automation skrivs information till en aktivitetslogg för Automation-kontot. Mer information om hur du använder loggen finns i Hämta information från aktivitetsloggen.

Undantag

I det här avsnittet beskrivs några sätt att hantera undantag eller tillfälliga problem i dina runbooks. Ett exempel är ett WebSocket-undantag. Korrekt undantagshantering förhindrar att tillfälliga nätverksfel gör att dina runbooks misslyckas.

ErrorActionPreference

Variabeln ErrorActionPreference avgör hur PowerShell svarar på ett fel som inte avslutas. Avslutande fel avslutas alltid och påverkas inte av ErrorActionPreference.

När runbooken använder ErrorActionPreferencehindrar ett normalt icke-avslutande fel, till exempel PathNotFound från cmdleten Get-ChildItem , runbooken från att slutföras. I följande exempel visas användningen av ErrorActionPreference. Det slutliga kommandot Write-Output körs aldrig när skriptet stoppas.

$ErrorActionPreference = 'Stop'
Get-ChildItem -path nofile.txt
Write-Output "This message will not show"

Prova att fånga äntligen

Prova Catch Finally används i PowerShell-skript för att hantera avslutande fel. Skriptet kan använda den här mekanismen för att fånga specifika undantag eller allmänna undantag. -instruktionen catch ska användas för att spåra eller försöka hantera fel. I följande exempel försöker du ladda ned en fil som inte finns. Det fångar undantaget System.Net.WebException och returnerar det sista värdet för andra undantag.

try
{
   $wc = new-object System.Net.WebClient
   $wc.DownloadFile("http://www.contoso.com/MyDoc.doc")
}
catch [System.Net.WebException]
{
    "Unable to download MyDoc.doc from http://www.contoso.com."
}
catch
{
    "An error occurred that could not be resolved."
}

Kasta

Throw kan användas för att generera ett avslutande fel. Den här mekanismen kan vara användbar när du definierar din egen logik i en runbook. Om skriptet uppfyller ett villkor som ska stoppa det kan det använda -instruktionen throw för att stoppa. I följande exempel används den här instruktionen för att visa en obligatorisk funktionsparameter.

function Get-ContosoFiles
{
  param ($path = $(throw "The Path parameter is required."))
  Get-ChildItem -Path $path\*.txt -recurse
}

Fel

Dina runbooks måste hantera fel. Azure Automation stöder två typer av PowerShell-fel, avslutande och icke-avslutande.

Avslutande fel stoppar Runbook-körningen när de inträffar. Runbooken slutar med jobbstatusen Misslyckades.

Icke-avslutande fel gör att ett skript kan fortsätta även efter att de har inträffat. Ett exempel på ett icke-avslutande fel är ett som inträffar när en runbook använder cmdleten Get-ChildItem med en sökväg som inte finns. PowerShell ser att sökvägen inte finns, utlöser ett fel och fortsätter till nästa mapp. Felet i det här fallet anger inte runbook-jobbstatusen till Misslyckades och jobbet kan till och med slutföras. Om du vill tvinga en runbook att stoppa ett fel som inte avslutas kan du använda ErrorAction Stop på cmdleten.

Samtalsprocesser

Runbooks som körs i Azure-sandbox-miljöer stöder inte samtalsprocesser, till exempel körbara filer (.exe filer) eller underprocesser. Anledningen till detta är att en Azure-sandbox-miljö är en delad process som körs i en container som kanske inte kan komma åt alla underliggande API:er. För scenarier som kräver programvara från tredje part eller anrop till underprocesser bör du köra en runbook på en Hybrid Runbook Worker.

Enhets- och programegenskaper

Runbook-jobb i Azure-sandbox-miljö kan inte komma åt några enhets- eller programegenskaper. Det vanligaste API:et som används för att fråga efter prestandamått i Windows är WMI, där några av de vanliga måtten är minnes- och CPU-användning.

Webhook

Externa tjänster, till exempel Azure DevOps Services och GitHub, kan starta en runbook i Azure Automation. För att göra den här typen av start använder tjänsten en webhook via en enda HTTP-begäran. Med en webhook kan runbooks startas utan implementering av en fullständig Azure Automation-funktion.

Delade resurser

För att dela resurser mellan alla runbooks i molnet använder Azure ett koncept som kallas rättvis resurs. Med rättvis resurs tar Azure tillfälligt bort eller stoppar alla jobb som har körts i mer än tre timmar. Jobb för PowerShell-runbooks och Python-runbooks stoppas och startas inte om och jobbstatusen stoppas.

För långvariga Azure Automation-uppgifter rekommenderar vi att du använder en Hybrid Runbook Worker. Hybrid Runbook Workers begränsas inte av en rättvis resurs och har ingen begränsning för hur länge en runbook kan köras. De andra jobbgränserna gäller för både Azure-sandbox-miljö och Hybrid Runbook Workers. Även om Hybrid Runbook Workers inte begränsas av gränsen på tre timmars rättvis resurs bör du utveckla runbooks för att köras på de arbetare som stöder omstarter från oväntade problem med lokal infrastruktur.

Ett annat alternativ är att optimera en runbook med hjälp av underordnade runbooks. Din runbook kan till exempel gå igenom samma funktion på flera resurser, till exempel med en databasåtgärd på flera databaser. Du kan flytta den här funktionen till en underordnad runbook och låta din runbook anropa den med Start-AzAutomationRunbook. Underordnade runbooks körs parallellt i separata processer.

Om du använder underordnade runbooks minskar den totala tiden för den överordnade runbooken att slutföras. Din runbook kan använda cmdleten Get-AzAutomationJob för att kontrollera jobbstatusen för en underordnad runbook om den fortfarande har fler åtgärder när det underordnade objektet har slutförts.

Nästa steg

• Information om hur du kommer igång med en PowerShell-runbook finns i Självstudie: Skapa en PowerShell-runbook.
• Information om hur du arbetar med runbooks finns i Hantera runbooks i Azure Automation.
• Mer information om PowerShell finns i PowerShell Docs.
• En PowerShell-cmdlet-referens finns i Az.Automation.