Funktionen Azure Automation Process Automation stöder flera typer av runbooks enligt definitionen i följande tabell.
Typ |
Beskrivning |
PowerShell (rekommenderas) |
Textuell runbook baserat på Windows PowerShell-skript. De versioner som stöds för närvarande är PowerShell 7.4 och PowerShell 5.1. Eftersom PowerShell 7.1 och PowerShell 7.2 inte längre stöds av den överordnade produkten PowerShell rekommenderar vi att du skapar runbooks i den långsiktiga versionen PowerShell 7.4. |
PowerShell-arbetsflöde |
Textbaserad runbook baserad på Windows PowerShell arbetsflödesskript. |
Pytonorm (rekommenderas) |
Textuell runbook baserad på Python-skripter. Den version som stöds för närvarande är Python 3.10. Eftersom Python 2.7 och Python 3.8 inte längre stöds av den överordnade produkten Python rekommenderar vi att du skapar runbooks i Python 3.10. |
Grafisk |
Grafisk runbook baserad på Windows PowerShell och skapad och redigerad helt i den grafiska redigeraren i Azure Portal. |
Grafiskt PowerShell-arbetsflöde |
Grafisk runbook baserad på Windows PowerShell-arbetsflöde och skapad och redigerad helt i den grafiska redigeraren i Azure Portal. |
Mer information om processautomatiseringsmiljön finns i Runbook-körning i Azure Automation.
Kommentar
Azure Automation följer supportlivscykeln för PowerShell- och Python-språkversioner i enlighet med tidslinjerna som publicerats av överordnade produkter, PowerShell respektive Python. Vi rekommenderar att du använder runbooks med språkversioner som stöds.
Ta hänsyn till följande när du avgör vilken typ som ska användas för en viss runbook:
- Du kan inte konvertera runbooks från grafiskt gränssnitt till textformat eller tvärtom.
- Det finns begränsningar när du använder runbooks av olika typer som underordnade runbooks. För mer information, se Underordnade runbooks i Azure Automation.
PowerShell-runbooks
PowerShell-runbooks baseras på Windows PowerShell. Du redigerar runbookens kod direkt med hjälp av textredigeraren i Azure Portal. Du kan också använda valfri offlinetextredigerare och importera runbooken till Azure Automation.
PowerShell-versionen bestäms av den Runtime Version som anges.
Samma Sandbox-miljö i Azure och Hybrid Runbook Worker kan köra flera PowerShell-runbooks för olika körningsversioner sida vid sida.
Kommentar
- För närvarande stöds PowerShell 7.4-körningsversionen för både moln- och hybridjobb i alla offentliga regioner utom Brasilien, sydöstra och Gov-moln.
- Om du väljer Körningsversion som 7.4 används PowerShell-moduler som är inriktade på 7.4-körningsversion, och om du väljer Körningsversion som 5.1 används PowerShell-moduler som är avsedda för 5.1-körningsversion.
Se till att du väljer rätt Körningsversion för moduler.
Exempel: Om du kör en runbook för ett SharePoint-automatiseringsscenario i Körningsversion7.4 importerar du modulen i Körningsversion7.4. Om du kör en runbook för ett SharePoint-automatiseringsscenario i Runtime Version5.1 importerar du modulen i Runtime Version5.1.
Fördelar
- Implementera all komplex logik med PowerShell-kod utan andra komplexiteter i PowerShell-arbetsflödet.
- Starta snabbare än PowerShell-arbetsflödesrunbooks eftersom de inte behöver kompileras innan de körs.
- Kör i Azure och på Hybrid Runbook Workers för både Windows och Linux.
Begränsningar och kända problem
Följande är de aktuella begränsningarna och kända problem med PowerShell-runbooks:
Begränsningar
Kommentar
För närvarande stöds PowerShell 7.4-körningsversionen för både moln- och hybridjobb i alla offentliga regioner utom Brasilien, sydöstra och Gov-moln.
- För PowerShell 7.4-körningsversionen extraheras inte modulaktiviteterna för de importerade modulerna. Använd Azure Automation-tillägget för VS Code för att förenkla upplevelsen av att skapa runbooks.
- PowerShell 7.x stöder inte arbetsflöden. För mer information, se PowerShell-arbetsflödet.
- PowerShell 7.x stöder för närvarande inte signerade runbooks.
- Källkontrollintegrering stöder inte PowerShell 7.4. Dessutom skapas PowerShell 7.4-runbooks i källkontrollen i Automation-kontot som Runtime 5.1.
- Az-modulen 12.3.0 installeras som standard. Den fullständiga listan över komponentmoduler i den valda Az-modulversionen visas när Az-versionen har konfigurerats igen med hjälp av Azure Portal eller API.
- Den importerade PowerShell 7.4-modulen valideras under jobbkörningen. Kontrollera att alla beroenden för den valda modulen också importeras för lyckad jobbkörning.
- Azure Runbook stöder inte
Start-Job
med -credential
.
- Azure stöder inte alla PowerShell-indataparametrar.
Läs mer.
Kända problem
Runbooks som är beroende av interna filsökvägar, till exempel C:\modules
kan misslyckas på grund av ändringar i tjänstens serverdelsinfrastruktur. Ändra runbook-kod för att säkerställa att det inte finns några beroenden för interna filsökvägar och använd Get-ChildItem för att hämta nödvändig modulinformation.
Get-AzStorageAccount
cmdleten kan misslyckas med ett fel: Kommandot Get-AzStorageAccount
hittades i modulen Az.Storage
, men modulen kunde inte läsas in.
Det går inte att köra underordnade skript med hjälp av.\child-runbook.ps1
.
Lösning: Använd Start-AutomationRunbook
(intern cmdlet) eller Start-AzAutomationRunbook
(från Az.Automation-modulen) för att starta en annan runbook från den överordnade runbooken.
När du använder ExchangeOnlineManagement-modulversion : 3.0.0 eller senare kan det uppstå fel. Lös problemet genom att se till att du uttryckligen laddar upp PowerShellGet - och PackageManagement-moduler .
När du använder cmdleten New-AzAutomationVariable
i Az.Automation-modulen för att ladda upp en variabel av typen objekt fungerar inte åtgärden som förväntat.
Lösning: Konvertera objektet till en JSON-sträng med hjälp av cmdleten ConvertTo-Json och ladda sedan upp variabeln med JSON-strängen som dess värde. Den här lösningen säkerställer korrekt hantering av variabeln i Azure Automation-miljön som en JSON-sträng.
Exempel – Skapa ett PowerShell-objekt som har lagrad information runt virtuella Azure-datorer
azurepowershell
# Retrieve Azure virtual machines with status information for the 'northeurope' region
$AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"}
$VMstopatch = @($AzVM).Id
# Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch
# Convert the object to a JSON string
$jsonString = $VMstopatch | ConvertTo-Json
# Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString
Begränsningar
Kommentar
PowerShell 7.2-versionen stöds inte längre av den överordnade produkten PowerShell.
- För PowerShell 7.2-körningsversionen extraheras inte modulaktiviteterna för de importerade modulerna.
- PowerShell 7.x stöder inte arbetsflöden. För mer information, se PowerShell-arbetsflödet.
- PowerShell 7.x stöder för närvarande inte signerade runbooks.
- Källkontrollintegrering stöder inte PowerShell 7.2. Dessutom skapas PowerShell 7.2-runbooks i källkontrollen i Automation-kontot som Runtime 5.1.
- Az-modulen 8.3.0 är installerad som standard. Den fullständiga listan över komponentmoduler i den valda Az-modulversionen visas när Az-versionen har konfigurerats igen med hjälp av Azure Portal eller API.
- Den importerade PowerShell 7.2-modulen valideras under körningen av jobbet. Kontrollera att alla beroenden för den valda modulen också importeras för lyckad jobbkörning.
- Azure Runbook stöder inte
Start-Job
med -credential
.
- Azure stöder inte alla PowerShell-indataparametrar.
Läs mer.
Kända problem
Runbooks som är beroende av interna filsökvägar, till exempel C:\modules
kan misslyckas på grund av ändringar i tjänstens serverdelsinfrastruktur. Ändra runbook-kod för att säkerställa att det inte finns några beroenden för interna filsökvägar och använd Get-ChildItem för att hämta nödvändig modulinformation.
Get-AzStorageAccount
cmdleten kan misslyckas med ett fel: Kommandot Get-AzStorageAccount
hittades i modulen Az.Storage
, men modulen kunde inte läsas in.
Det går inte att köra underordnade skript med hjälp av.\child-runbook.ps1
.
Lösning: Använd Start-AutomationRunbook
(intern cmdlet) eller Start-AzAutomationRunbook
(från Az.Automation-modulen) för att starta en annan runbook från den överordnade runbooken.
När du använder ExchangeOnlineManagement-modulversion : 3.0.0 eller senare kan det uppstå fel. Lös problemet genom att se till att du uttryckligen laddar upp PowerShellGet - och PackageManagement-moduler .
När du använder cmdleten New-AzAutomationVariable
i Az.Automation-modulen för att ladda upp en variabel av typen objekt fungerar inte åtgärden som förväntat.
Lösning: Konvertera objektet till en JSON-sträng med hjälp av cmdleten ConvertTo-Json och ladda sedan upp variabeln med JSON-strängen som dess värde. Den här lösningen säkerställer korrekt hantering av variabeln i Azure Automation-miljön som en JSON-sträng.
Exempel – Skapa ett PowerShell-objekt som har lagrad information runt virtuella Azure-datorer
azurepowershell
# Retrieve Azure virtual machines with status information for the 'northeurope' region
$AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"}
$VMstopatch = @($AzVM).Id
# Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch
# Convert the object to a JSON string
$jsonString = $VMstopatch | ConvertTo-Json
# Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString
Begränsningar
- Runbooks kan inte använda parallell bearbetning för att köra flera åtgärder parallellt.
- Runbooks kan inte använda kontrollpunkter för att återuppta runbooken om det uppstår ett fel.
- Du kan bara inkludera PowerShell, PowerShell Workflow-runbooks och grafiska runbooks som underordnade runbooks med hjälp av cmdleten Start-AzAutomationRunbook , som skapar ett nytt jobb.
- Runbooks kan inte använda PowerShell -#Requires-instruktionen , den stöds inte i Azure-sandbox-miljön eller i Hybrid Runbook Workers och kan leda till att jobbet misslyckas.
- Azure Runbook stöder inte
Start-Job
med -credential
.
- Azure stöder inte alla PowerShell-indataparametrar.
Läs mer.
Kända problem
Runbooks som är beroende av interna filsökvägar, till exempel C:\modules
kan misslyckas på grund av ändringar i tjänstens serverdelsinfrastruktur. Ändra runbook-kod för att säkerställa att det inte finns några beroenden för interna filsökvägar och använd Get-ChildItem för att hämta nödvändig modulinformation.
Exempelskript
# Get information about module "Microsoft.Graph.Authentication"
$ModuleName = "Microsoft.Graph.Authentication"
$NewPath = "C:\usr\src\PSModules\$ModuleName"
$OldPath = "C:\Modules\User\$ModuleName"
if (Test-Path -Path $NewPath -PathType Container) {
Get-ChildItem -Path $NewPath
} elseif (Test-Path -Path $OldPath -PathType Container) {
Get-ChildItem -Path $OldPath
} else {
Write-Output "Module $ModuleName not present."
}
# Getting the path to the Temp folder, if needed.
$tmp = $env:TEMP
Get-AzStorageAccount
cmdleten kan misslyckas med ett fel: Kommandot Get-AzStorageAccount
hittades i modulen Az.Storage
, men modulen kunde inte läsas in.
PowerShell-runbooks kan inte hämta en okrypterad variabeltillgång med ett null-värde.
PowerShell-runbooks kan inte hämta en variabeltillgång med *~*
i namnet.
En Get-Process-åtgärd i en loop i en PowerShell-runbook kan krascha efter cirka 80 iterationer.
En PowerShell-runbook kan misslyckas om den försöker skriva en stor mängd data till utdataströmmen samtidigt. Du kan vanligtvis kringgå det här problemet genom att se till att din runbook bara matar ut data för den information som behövs för att arbeta med stora objekt. I stället för att använda Get-Process
utan begränsningar kan du till exempel ha cmdlet-utdata bara de obligatoriska parametrarna som i Get-Process | Select ProcessName, CPU
.
När du använder ExchangeOnlineManagement-modulversion : 3.0.0 eller senare kan det uppstå fel. Lös problemet genom att se till att du uttryckligen laddar upp PowerShellGet - och PackageManagement-moduler .
Om du importerar modulen Az.Accounts med version 2.12.3 eller senare, ska du säkerställa att du importerar modulen Newtonsoft.Json v10 explicit om PowerShell 5.1-runbooks har ett beroende av den här versionen av modulen. Lösningen på det här problemet är att använda PowerShell 7.2-runbooks.
När du använder cmdleten New-AzAutomationVariable
i Az.Automation-modulen för att ladda upp en variabel av typen objekt fungerar inte åtgärden som förväntat.
Lösning: Konvertera objektet till en JSON-sträng med hjälp av cmdleten ConvertTo-Json och ladda sedan upp variabeln med JSON-strängen som dess värde. Den här lösningen säkerställer korrekt hantering av variabeln i Azure Automation-miljön som en JSON-sträng.
Exempel – Skapa ett PowerShell-objekt som har lagrad information runt virtuella Azure-datorer
# Retrieve Azure virtual machines with status information for the 'northeurope' region
$AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"}
$VMstopatch = @($AzVM).Id
# Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch
# Convert the object to a JSON string
$jsonString = $VMstopatch | ConvertTo-Json
# Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString
Begränsningar
-
PowerShell 7.1 stöds inte längre av den överordnade produkten PowerShell. Vi rekommenderar att du skapar nya runbooks i PowerShell 7.4 för långsiktig support och uppdaterar inaktuella runbooks.
- De interna PowerShell-cmdletarna i Azure Automation stöds inte i en Linux Hybrid Runbook Worker. Du måste importera modulen
automationassets
i början av PowerShell-runbooken för att få åtkomst till funktionerna för delade resurser (tillgångar) för Automation-kontot.
- För PowerShell 7-körningsversionen extraheras inte modulaktiviteterna för de importerade modulerna.
-
Parametertypen PSCredential runbook stöds inte i PowerShell 7-körningsversionen.
- PowerShell 7.x stöder inte arbetsflöden. För mer information, se PowerShell-arbetsflöde.
- PowerShell 7.x stöder för närvarande inte signerade runbooks.
- Källkontrollintegrering stöder inte PowerShell 7.1 (förhandsversion). Dessutom skapas PowerShell 7.1-runbooks (förhandsversion) i källkontrollen i ett Automation-konto som Runtime 5.1.
- PowerShell 7.1-modulhantering stöds inte via
Get-AzAutomationModule
-cmdletar.
- Runbook misslyckas utan loggspårning om indatavärdet innehåller tecknet .
- Azure Runbook stöder inte
Start-Job
med -credential
.
- Azure stöder inte alla PowerShell-indataparametrar.
Läs mer.
Kända problem
Runbooks som är beroende av interna filsökvägar, till exempel C:\modules
kan misslyckas på grund av ändringar i tjänstens serverdelsinfrastruktur. Ändra runbook-kod för att säkerställa att det inte finns några beroenden för interna filsökvägar och använd Get-ChildItem för att hämta nödvändig modulinformation.
Exempelskript
# Get information about module "Microsoft.Graph.Authentication"
$ModuleName = "Microsoft.Graph.Authentication"
$NewPath = "C:\usr\src\PSModules\$ModuleName"
$OldPath = "C:\Modules\User\$ModuleName"
if (Test-Path -Path $NewPath -PathType Container) {
Get-ChildItem -Path $NewPath
} elseif (Test-Path -Path $OldPath -PathType Container) {
Get-ChildItem -Path $OldPath
} else {
Write-Output "Module $ModuleName not present."
}
# Getting the path to the Temp folder, if needed.
$tmp = $env:TEMP
Get-AzStorageAccount
cmdleten kan misslyckas med ett fel: Kommandot Get-AzStorageAccount
hittades i modulen Az.Storage
, men modulen kunde inte läsas in.
Körning av underordnade skript med hjälp av .\child-runbook.ps1
stöds inte i den här förhandsversionen.
Lösning: Använd Start-AutomationRunbook
(intern cmdlet) eller Start-AzAutomationRunbook
(från Az.Automation
modulen) för att starta en annan runbook från den överordnade runbooken.
Runbook-egenskaper som definierar loggningsinställningar stöds inte i PowerShell 7-körningsversionen.
Arbetslösning: Ställ in uttryckligen inställningen i början av runbooken på följande sätt:
$VerbosePreference = "Continue"
$ProgressPreference = "Continue"
Undvik att Az.Accounts
importera modulen till version 2.4.0 för PowerShell 7-körning eftersom det kan uppstå ett oväntat beteende med den här versionen i Azure Automation.
Du kan stöta på formateringsproblem med felutdataströmmar för jobbet som körs i PowerShell 7-körning.
När du importerar en PowerShell 7.1-modul som är beroende av andra moduler kan det hända att importknappen är grå även när PowerShell 7.1-versionen av den beroende modulen är installerad. Till exempel Az PowerShell-modulen. Beräkningsversion 4.20.0 är beroende av att Az.Accounts är >= 2.6.0. Det här problemet uppstår när en motsvarande beroende modul i PowerShell 5.1 inte uppfyller versionskraven. Till exempel var < 5.1-versionen av Az.Accounts 2.6.0.
När du startar PowerShell 7-runbooken med webhooken konverterar den automatiskt indataparametern webhook till en ogiltig JSON.
Vi rekommenderar att du använder ExchangeOnlineManagement-modulversion : 3.0.0 eller lägre eftersom version: 3.0.0 eller senare kan leda till jobbfel.
Om du importerar modulen Az.Accounts med version 2.12.3 eller senare kontrollerar du att du importerar Modulen Newtonsoft.Json v10 explicit om PowerShell 7.1-runbooks har ett beroende av den här versionen av modulen. Lösningen på det här problemet är att använda PowerShell 7.2-runbooks.
När du använder cmdleten New-AzAutomationVariable
i Az.Automation-modulen för att ladda upp en variabel av typen objekt fungerar inte åtgärden som förväntat.
Lösning: Konvertera objektet till en JSON-sträng med hjälp av cmdleten ConvertTo-Json och ladda sedan upp variabeln med JSON-strängen som dess värde. Den här lösningen säkerställer korrekt hantering av variabeln i Azure Automation-miljön som en JSON-sträng.
Exempel – Skapa ett PowerShell-objekt som har lagrad information runt virtuella Azure-datorer
# Retrieve Azure virtual machines with status information for the 'northeurope' region
$AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"}
$VMstopatch = @($AzVM).Id
# Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch
# Convert the object to a JSON string
$jsonString = $VMstopatch | ConvertTo-Json
# Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString
PowerShell-arbetsflödeshandböcker
PowerShell-arbetsflödesrunbooks är läroböcker baserade på Windows PowerShell-arbetsflöde. Du redigerar runbookens kod direkt med hjälp av textredigeraren i Azure Portal. Du kan också använda valfri offlinetextredigerare och importera runbooken till Azure Automation.
Kommentar
PowerShell 7.1 (förhandsversion) och PowerShell 7.2 stöder inte arbetsflödesrunbooks.
Fördelar
- Implementera all komplex logik med PowerShell-arbetsflödeskod.
- Använd kontrollpunkter för att återuppta åtgärden om det finns ett fel.
- Använd parallell bearbetning för att utföra flera åtgärder parallellt.
- Kan innehålla andra grafiska runbooks och PowerShell-arbetsflödesrunbooks som underordnade runbooks för att skapa arbetsflöden på hög nivå.
Begränsningar
- PowerShell-arbetsflödet stöds inte i PowerShell 7+-versioner. Därför kan inte inaktuella runbooks uppgraderas.
- Ineffektiv hantering av parallell körning jämfört med nyare PowerShell 7+-versioner.
- PowerShell-arbetsflödet fungerar internt med flera processer. Därför kanske moduler som är tillgängliga i en process inte är tillgängliga i en annan och orsakar undantag som att kommandot inte hittades.
- Runbooks måste hantera den ytterligare komplexiteten i PowerShell-arbetsflödet, till exempel deserialiserade objekt.
- Runbooks tar längre tid att starta än PowerShell-runbooks eftersom de måste kompileras innan de körs.
- Du kan bara inkludera PowerShell-runbooks som barn-runbooks genom att använda cmdleten
Start-AzAutomationRunbook
.
- Runbooks kan inte köras på en Linux Hybrid Runbook Worker.
Python-runböcker
Python-runbooks kompileras under Python 3.10. Du kan redigera koden i runbooken direkt med textredigeraren i Azure-portalen. Du kan också använda en offline-textredigerare och importera runbooken till Azure Automation. Python 2.7 och Python 3.8 stöds inte längre av den överordnade produkten och vi rekommenderar att du skapar runbooks i Python 3.10-körningsversionen.
För närvarande stöds Python 3.10-körningsversionen för både moln- och hybridjobb i alla offentliga regioner utom Brasilien, sydöstra och Gov-moln.
Fördelar
Kommentar
Det kan ta flera minuter att importera ett Python-paket.
- Använder robusta Python-bibliotek.
- Kan köras i Azure eller på Hybrid Runbook Workers.
- Skript och paket från valfri 3.x-version kan fungera om koden är kompatibel mellan olika versioner.
- För Python 3.10 Hybrid-jobb på Windows-datorer kan du välja att installera valfri 3.x-version som du kanske vill använda.
- För Python 3.10 Hybrid-jobb på Linux-datorer är vi beroende av python 3-versionen som är installerad på datorn för att köra DSC OMSConfig och Linux Hybrid Worker. Olika versioner bör fungera om det inte finns några inkompatibla ändringar i metodsignaturer eller kontrakt mellan versioner av Python 3.
Begränsningar
Begränsningarna för Python-runbooks är:
- För Python 3.10-moduler stöds för närvarande endast hjulfilerna som riktar sig mot cp310 Linux OS.
Läs mer
- Källkontrollintegrering stöds inte.
- Anpassade paket för Python 3.10 verifieras endast under jobbkörningen. Jobbet förväntas misslyckas om paketet inte är kompatibelt under körningen eller om nödvändiga beroenden för paket inte importeras till automationskontot.
- För närvarande stöds endast Python 3.10-runbooks från Azure-portalen och REST API.
- Python 3.8 stöds inte längre av den överordnade produkten Python. Vi rekommenderar att du skapar nya runbooks i de versioner som stöds och uppdaterar de inaktuella runbooksna.
- Du måste känna till Python-skript.
- Källkontrollintegrering stöds inte.
- För Python 3.8-moduler använder du hjulfiler som riktar sig till cp38-amd64.
- Om du vill använda bibliotek från tredje part måste du importera paketen till Automation-kontot.
- Att använda Start-AutomationRunbook-cmdlet i PowerShell/PowerShell-arbetsflödet för att starta en Python 3.8-runbook fungerar inte. Du kan använda cmdleten Start-AzAutomationRunbook från Az.Automation-modulen eller cmdleten Start-AzureRmAutomationRunbook från AzureRm.Automation för att kringgå den här begränsningen.
- Azure Automation stöder inte sys.stderr.
- Python automationassets-paketet är inte tillgängligt på pypi.org, så det är inte tillgängligt för import till en Windows-dator.
-
Python 2.7 stöds inte längre av den överordnade produkten Python. Vi rekommenderar att du skapar nya runbooks i de versioner som stöds och uppdaterar de inaktuella runbooks.
- Du måste känna till Python-skript.
- För Python 2.7.12-moduler använder du hjulfilerna cp27-amd6.
- Om du vill använda bibliotek från tredje part måste du importera paketen till Automation-kontot.
- Azure Automation stöder inte sys.stderr.
- Python automationassets-paketet är inte tillgängligt på pypi.org, så det är inte tillgängligt för import till en Windows-dator.
Flera Python-versioner
Det gäller för Windows Hybrid-arbetare. För en Windows Runbook Worker letar den först efter miljövariabeln PYTHON_2_PATH
när du kör en Python 2-runbook och kontrollerar om den pekar på en giltig körbar fil. Om installationsmappen till exempel är C:\Python2
kontrollerar den om C:\Python2\python.exe
det är en giltig sökväg. Om det inte hittas, letar den efter PATH
-miljövariabeln för att göra en liknande kontroll.
För Python 3 letar den först efter PYTHON_3_PATH
miljövariabeln och återgår sedan till PATH
miljövariabeln.
När du bara använder en version av Python kan du lägga till installationssökvägen i variabeln PATH
. Om du vill använda båda versionerna i Runbook Worker anger du PYTHON_2_PATH
och PYTHON_3_PATH
till platsen för modulen för dessa versioner.
Kända problem
För molnjobb misslyckas Python 3.8-jobb ibland med ett undantagsmeddelande invalid interpreter executable path
. Du kan se det här undantaget om jobbet är försenat, har pågått i mer än 10 minuter eller om Start-AutomationRunbook används för att starta Python 3.8 runbooks. Om jobbet fördröjs bör det vara tillräckligt att starta om runbooken.
Grafiska körböcker
Du kan skapa och redigera grafiska och grafiska PowerShell-arbetsflödesrunbooks med hjälp av den grafiska redigeraren i Azure Portal. Du kan dock inte skapa eller redigera den här typen av runbook med ett annat verktyg. Huvudfunktioner i grafiska runbooks:
- Exporterades till filer i ditt Automation-konto och importerades sedan till ett annat Automation-konto.
- Generera PowerShell-kod.
- Konverteras till eller från grafiska PowerShell Workflow-runböcker vid import.
Fördelar
- Använd den visuella författarmodellen för insättning, länkning och konfigurering.
- Fokusera på hur data flödar genom processen.
- Representerar hanteringsprocesser visuellt.
- Inkludera andra runbooks som underordnade runbooks för att skapa arbetsflöden på hög nivå.
- Uppmuntra modulär programmering.
Begränsningar
- Det går inte att skapa eller redigera utanför Azure Portal.
- Kan kräva en kodaktivitet som innehåller PowerShell-kod för att köra komplex logik.
- Det går inte att konvertera till något av textformaten, och du kan inte heller konvertera en texthandbok till grafiskt format.
- Det går inte att visa eller redigera PowerShell-kod direkt som det grafiska arbetsflödet skapar. Du kan visa koden som du skapar i alla kodaktiviteter.
- Det går inte att köra runbooks på en Linux Hybrid Runbook Worker. Se Automatisera resurser i ditt datacenter eller moln med hjälp av Hybrid Runbook Worker.
- Grafiska runbooks kan inte signeras digitalt.
Nästa steg