Runbook-körning i Azure Automation

Med processautomatisering Azure Automation kan du skapa och hantera PowerShell, PowerShell Workflow och grafiska runbooks. Mer information finns i Azure Automation runbooks.

Automation kör dina runbooks baserat på den logik som 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 Azure Automation skapas ett jobb, vilket är en instans av en enskild körning 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 resurserna är tillgängliga från det offentliga molnet.

Azure Automation tilldelar en arbetsroll för att köra varje jobb under runbook-körningen. Arbetare delas av många Automation-konton, men jobb från olika Automation-konton isoleras från varandra. Du kan inte styra vilka arbetsroller 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-runbooksoch grafiska runbooks.

Jobbstatusar – PowerShell-arbetsflöde

Anteckning

I Azure-begäranden från registrerad person för GDPR finns det information om att visa eller ta bort personuppgifter. Mer information om GDPR finns i avsnittet GDPR i avsnittet Microsoft säkerhets Center och avsnittet GDPR i service Trust-portalen.

Runbook-körningsmiljö

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

När runbooks är utformade för att autentisera och köras mot resurser i Azure körs de i en Azure-sandbox-miljö. Azure Automation tilldelar en arbetsroll att köra varje jobb under runbook-körningen i sandbox-miljön. Arbetare delas av många Automation-konton, men jobb från olika Automation-konton isoleras 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. Den förhindrar åtkomst till alla out-of-process COM-servrar och stöder inte att göra WMI-anrop till Win32-providern i din runbook. Dessa scenarier stöds endast genom att köra runbooken på en Windows Hybrid Runbook Worker.

Du kan också använda en Hybrid Runbook Worker för att köra runbooks direkt på den dator 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 på Azure Storage , Azure Key Vaulteller Azure SQL blockeras åtkomst från Azure Automationrunbooks 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 är en del av 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.

Anteckning

Om du vill köra Hybrid Runbook Worker Linux-datorer måste skripten signeras och arbetaren konfigureras på motsvarande sätt. Alternativt måste signaturverifiering vara inaktiverat.

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

Uppgift Rekommendation Kommentarer
Integrera med Azure-resurser Sandbox-miljö för Azure Autentisering är enklare i Azure. Om du använder ett konto Hybrid Runbook Worker en virtuell Azure-dator kan du använda runbook-autentisering med hanterade identiteter.
Få optimala prestanda för att hantera Azure-resurser Sandbox-miljö för Azure Skriptet körs i samma miljö, som har kortare svarstid.
Minimera driftskostnader Sandbox-miljö för Azure Det finns inga beräkningskostnader och inget behov av en virtuell dator.
Köra långvariga skript Hybrid Runbook Worker Sandbox-miljöerna i Azure har resursbegränsningar.
Interagera med lokala tjänster Hybrid Runbook Worker Få direkt åtkomst till värddatorn eller resurser i andra molnmiljöer eller i den lokala miljön.
Kräv programvara från tredje part och körbara filer Hybrid Runbook Worker Du hanterar operativsystemet och kan installera programvara.
Övervaka en fil eller mapp med en runbook Hybrid Runbook Worker Använd en Bevakaraktivitet på en Hybrid Runbook Worker.
Köra ett resursintensivt skript Hybrid Runbook Worker Sandbox-miljöerna i Azure har resursbegränsningar.
Använda moduler med specifika krav Hybrid Runbook Worker Några exempel är:
WinSCP – beroende av winscp.exe
IIS-administration – beroende av aktivering eller hantering av IIS
Installera en modul med ett installationsprogram Hybrid Runbook Worker Moduler för sandbox-miljö måste ha stöd för kopiering.
Använd runbooks eller moduler som kräver .NET Framework annan version än 4.7.2 Hybrid Runbook Worker Sandbox-miljöerna i Azure .NET Framework 4.7.2 och uppgradering till en annan version stöds inte.
Köra skript som kräver utökade privilegier Hybrid Runbook Worker Sandbox-miljöerna tillåter inte utökade privilegier. Med en Hybrid Runbook Worker kan du inaktivera UAC och använda Invoke-Command när du kör kommandot som kräver utökade privilegier.
Köra skript som kräver åtkomst till Windows Management Instrumentation (WMI) Hybrid Runbook Worker Jobb som körs i sandbox-miljön i molnet kan inte komma åt WMI-providern.

Tillfällig lagring i en sandbox-miljö

Om du behöver skapa temporära filer som en del av din runbook-logik kan du använda Temp-mappen (det vill säga ) i $env:TEMP 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 problem eftersom PowerShell-arbetsflöden använder kontrollpunkter och skriptet kan göras om i en annan sandbox-miljö.

Med sandbox-miljön för hybrider kan C:\temp du använda baserat på tillgängligheten för lagring på en Hybrid Runbook Worker. Enligt rekommendationerna för virtuella Azure-datorer bör du dock inte använda den tillfälliga disken på Windows eller Linux för data som behöver bevaras.

Resurser

Dina runbooks måste innehålla logik för att hanteraresurser, 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 for Cloud för att tillhandahålla säkerhet för dina resurser och identifiera komprometter i Linux-system. Säkerhet tillhandahålls i dina arbetsbelastningar, oavsett om resurserna finns i Azure eller inte. Se Introduktion till autentisering i Azure Automation.

Defender for Cloud sätter begränsningar på användare som kan köra alla 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 uppdateringar av operativsystemet när du har skapat ett Automation-konto och aktiverar lämplig 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. För Azure Automation länkas varje prenumeration till ett Azure Automation-konto och du kan skapa flera prenumerationer i kontot.

Autentiseringsuppgifter

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

Azure Monitor

Azure Automation använder sig av Azure Monitor för att övervaka sina datoråtgärder. Åtgärderna kräver en Log Analytics-arbetsyta och en Log Analytics-agent.

Log Analytics-agent för Windows

Log Analytics-agenten för Windows fungerar med Azure Monitor för att Windows virtuella datorer och fysiska datorer. Datorerna kan köras antingen i Azure eller i en icke-Azure-miljö, till exempel ett lokalt datacenter.

Anteckning

Log Analytics-agenten för Windows kallades tidigare Microsoft Monitoring Agent (MMA).

Log Analytics-agent för Linux

Log Analytics-agenten för Linux fungerar på samma sätt som agenten för Windows, men ansluter Linux-datorer till Azure Monitor. Agenten installeras med vissa tjänstkonton som kör kommandon som kräver rotbehörigheter. Mer information finns i Tjänstkonton.

Log Analytics-agentloggen finns på /var/opt/microsoft/omsagent/log/omsagent.log .

Runbook-behörigheter

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

Moduler

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

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

Moduler som kan installeras stöds också, baserat på de cmdlets 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 till Azure eller lägger till dem i Azure eller resurser från tredje part. Certifikaten lagras på ett säkert sätt för åtkomst av runbooks och DSC-konfigurationer.

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

Jobb

Azure Automation har stöd för 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ö.

Jobb som körs i samma sandbox-process kan påverka varandra. Ett exempel är att köra cmdleten Disconnect-AzAccount. Körningen av denna cmdlet 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.

Anteckning

PowerShell-jobb som startats från en runbook som körs i en Azure-sandbox-miljö kanske inte körs i fullständigt PowerShell-språkläge.

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 visa detaljerad information om ett specifikt runbook-jobb i Azure Portal. 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 jobbstatusoch jobbströmmar från Automation till Azure Monitor loggar . Se även Hämta jobbstatus för ett exempel på hur du arbetar med statusar i en runbook.

Status Beskrivning
Aktivera Jobbet aktiveras.
Slutförd Jobbet har slutförts.
Misslyckad Det gick inte att kompilera en grafisk runbook eller PowerShell Workflow-runbook. Det gick inte att starta en PowerShell-runbook eller så hade jobbet ett undantag. Se Azure Automation runbook-typer.
Misslyckades, väntar på resurser Jobbet misslyckades eftersom det nådde gränsen för tidsbegränsade resursen tre gånger och startade från samma kontrollpunkt eller från början av runbooken varje gång.
I kö Jobbet väntar på att resurser på ett Automation-arbete ska bli tillgängligt så att det kan startas.
Återupptar Systemet återupptar jobbet efter att det pausas.
Körs Jobbet körs
Körs, väntar på resurser Jobbet har tagits bort eftersom det har nått gränsen för tidsbegränsad resurs. Den återupptas strax från den senaste kontrollpunkten.
Startar Jobbet har tilldelats till en arbetsroll och systemet startar det.
Stoppad Jobbet stoppades av användaren innan det slutfördes.
Stoppas Systemet stoppar jobbet.
Inaktiverad Gäller endast för grafiska runbooks och PowerShell Workflow-runbooks. Jobbet pausades av användaren, av systemet, eller av ett kommando i runbook. Om en runbook inte har någon kontrollpunkt startar den från början. Om den har en kontrollpunkt kan den starta igen och återuppta från den senaste kontrollpunkten. Systemet pausar endast runbooken när ett undantag inträffar. Som standard är ErrorActionPreference variabeln inställd på Fortsätt, vilket anger att jobbet fortsätter att köras på ett fel. Om inställningsvariabeln är inställd på Stoppa pausas jobbet vid ett fel.
Pausar Gäller endast för grafiska runbooks och PowerShell Workflow-runbooks. Systemet försöker pausa jobbet på begäran av användaren. Runbooken måste nå nästa kontrollpunkt innan den kan pausas. Om den redan har passerat sin sista kontrollpunkt slutförs den innan den kan pausas.

Aktivitetsloggning

Körning av runbooks i Azure Automation skriver information i 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. Rätt undantagshantering förhindrar att tillfälliga nätverksfel gör att dina runbooks misslyckas.

ErrorActionPreference

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

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

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

Prova Catch Finally

Try 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 upp specifika undantag eller allmänna undantag. catch-instruktionen ska användas för att spåra eller försöka hantera fel. I följande exempel försöker ladda ned en fil som inte finns. Den fångar upp System.Net.WebException undantaget 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 throw -instruktionen 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.

Om du avslutar fel stoppas runbook-körningen när de inträffar. Runbooken stoppas 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 med en Get-ChildItem sökväg som inte finns. PowerShell ser att sökvägen inte finns, kastar ett fel och fortsätter till nästa mapp. Felet i det här fallet anger inte statusen för runbook-jobbet till Misslyckades och jobbet kan till och med slutföras. Om du vill tvinga en runbook att stoppa vid ett icke-avslutande fel kan du ErrorAction Stop använda på cmdleten .

Anropa processer

Runbooks som körs i Azure-sandbox-miljöerna stöder inte anropsprocesser, till exempel körbara filer (.exefiler) eller delprocesser. Anledningen till detta är att en Sandbox-miljö i Azure ä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öerna har inte åtkomst till några enhets- eller programegenskaper. Det vanligaste API:et som används för att köra frågor mot prestandamått på Windows är WMI, där några av de vanligaste måtten är minnes- och CPU-användning. Det spelar dock ingen roll vilket API som används eftersom jobb som körs i molnet inte kan komma åt Microsofts implementering av Web-Based Enterprise Management (WBEM). Den här plattformen bygger på Common Information Model (CIM), som tillhandahåller branschstandarder för att definiera egenskaper för enheter och program.

Webhooks

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. Användning av en webhook gör att runbooks kan 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 begrepp som kallas tidsfördelningsfördelning. Med hjälp av tids delning tar Azure tillfälligt bort eller stoppar 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 blir Stoppad.

För långvariga Azure Automation rekommenderar vi att du använder en Hybrid Runbook Worker. Hybrid Runbook Workers begränsas inte av tidsbegränsade resurser och har ingen begränsning för hur länge en runbook kan köras. De andra jobbbegränsningarna gäller för både Azure-sandbox-miljö och Hybrid Runbook Workers. Även om Hybrid Runbook Workers inte begränsas av den tre timmar långa gränsen för tidsbegränsade resurser bör du utveckla runbooks som körs på de arbetare som stöder omstarter från oväntade lokala infrastrukturproblem.

Ett annat alternativ är att optimera en runbook med hjälp av underordnade runbooks. Din runbook kan till exempel loopa genom 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 få din runbook att anropa den med hjälp av Start-AzAutomationRunbook. Underordnade runbooks körs parallellt i separata processer.

Om du använder underordnade runbooks minskar den totala tiden som den överordnade runbooken kan slutföra. 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 har slutförts.

Nästa steg