Runbook-körning i Azure Automation

  • Artikel

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-portalen 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.

Job Statuses - PowerShell Workflow

Kommentar

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 Microsoft Trust Center och GDPR-avsnittet i Service Trust-portalen.

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. Det förhindrar åtkomst till alla COM-servrar som inte är processer och stöder inte WMI-anrop till Win32-providern i din runbook.  Dessa scenarier stöds bara 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å 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.

Kommentar

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

Uppgift Rekommendation OBS!
Integrera med Azure-resurser Azure Sandbox Autentiseringen är enklare i Azure. Om du använder en Hybrid Runbook Worker på en virtuell Azure-dator kan du använda runbook-autentisering med hanterade identiteter.
Få optimala prestanda för att hantera Azure-resurser Azure Sandbox Skript körs i samma miljö, som har mindre svarstid.
Minimera driftskostnader Azure Sandbox Det finns inga beräkningskostnader och inget behov av en virtuell dator.
Köra tidskrävande skript Hybrid Runbook Worker Azure-sandbox-miljön har resursgränser.
Interagera med lokala tjänster Hybrid Runbook Worker Få direkt åtkomst till värddatorn eller resurser i andra molnmiljöer eller 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 Watcher-uppgift på en Hybrid Runbook Worker.
Köra ett resursintensivt skript Hybrid Runbook Worker Azure-sandbox-miljön har resursgränser.
Använda moduler med specifika krav Hybrid Runbook Worker Några exempel är:
WinSCP – beroende av winscp.exe
IIS-administration – beroende av att aktivera eller hantera IIS
Installera en modul med ett installationsprogram Hybrid Runbook Worker Moduler för sandbox-miljön måste ha stöd för kopiering.
Använd runbooks eller moduler som kräver en annan .NET Framework-version än 4.7.2 Hybrid Runbook Worker Azure-sandbox-miljön stöder .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ön 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ö 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 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. För Azure Automation är varje prenumeration länkad till ett Azure Automation-konto och du kan skapa flera prenumerationer i kontot.

Autentiseringsuppgifter

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 använder 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 hantera virtuella Windows-datorer och fysiska datorer. Datorerna kan köras antingen i Azure eller i en icke-Azure-miljö, till exempel ett lokalt datacenter.

Kommentar

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ö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.

Kommentar

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 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.

Status Description
Aktivera Jobbet aktiveras.
Slutförda Jobbet har slutförts.
Misslyckades 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-runbooktyper.
Det gick inte att vänta på resurser Jobbet misslyckades eftersom det nådde gränsen för rättvis resurs 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å en Automation-arbetare ska bli tillgängliga så att det kan startas.
Återuppta Systemet återupptar jobbet efter att det pausats.
Körs Jobbet körs.
Körs och väntar på resurser Jobbet har tagits bort eftersom det nådde gränsen för rättvis andel. Den återupptas strax från den sista kontrollpunkten.
Startar Jobbet har tilldelats en arbetare och systemet startar det.
Stoppat Jobbet stoppades av användaren innan det slutfördes.
Stoppas Systemet stoppar jobbet.
Uppehåll Gäller endast för grafiska runbooks och PowerShell-arbetsflödesrunbooks . Jobbet avbröts av användaren, av systemet eller av ett kommando i runbooken. Om en runbook inte har någon kontrollpunkt börjar den från början. Om den har en kontrollpunkt kan den startas igen och återupptas från den senaste kontrollpunkten. Systemet pausar bara runbooken när ett undantag inträffar. Som standard är variabeln ErrorActionPreference inställd på Fortsätt, vilket indikerar att jobbet fortsätter att köras på ett fel. Om inställningsvariabeln är inställd på Stoppa pausas jobbet vid ett fel.
Avbryta Gäller endast för grafiska runbooks och PowerShell-arbetsflödesrunbooks . 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

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. Det spelar dock ingen roll vilket API som används eftersom jobb som körs i molnet inte kan komma åt Microsoft-implementeringen av Web-Based Enterprise Management (WBEM). Den här plattformen bygger på Common Information Model (CIM), som tillhandahåller branschstandarder för att definiera enhets- och programegenskaper.

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