Seznámení s pracovním postupem PowerShellu pro Azure Automation

  • Článek

Runbooky ve službě Azure Automation se implementují jako pracovní postupy Windows PowerShellu, skripty Windows PowerShellu, které používají Windows Workflow Foundation. Pracovní postup je pořadí naprogramovaných, propojených kroků, které provádějí dlouhodobé úlohy nebo vyžadují koordinaci více kroků v rámci více zařízení nebo spravovaných uzlů.

Pracovní postup je napsaný pomocí syntaxe Windows PowerShellu a spuštěný prostředím Windows PowerShell, ale zpracovává ho Windows Workflow Foundation. Mezi výhody pracovního postupu nad normálním skriptem patří souběžný výkon akce na více zařízeních a automatické obnovení při selhání.

Poznámka:

Tento článek platí pro PowerShell 5.1; PowerShell 7.1 (Preview) a PowerShell 7.2 (Preview) nepodporují pracovní postupy. Skript pracovního postupu PowerShellu je velmi podobný skriptu Windows PowerShellu, ale má některé významné rozdíly, které můžou být pro nového uživatele matoucí. Proto doporučujeme psát runbooky pomocí pracovního postupu PowerShellu jenom v případě, že potřebujete použít kontrolní body.

Úplné podrobnosti o tématech v tomto článku najdete v tématu Začínáme s pracovním postupem Windows PowerShellu.

Použití klíčového slova Pracovního postupu

Prvním krokem při převodu skriptu PowerShellu na pracovní postup PowerShellu je jeho uzavření s klíčovým slovem Workflow . Pracovní postup začíná klíčovým slovem Workflow následovaným textem skriptu uzavřeným ve složených závorkách. Název pracovního postupu se řídí klíčovým slovem Workflow , jak je znázorněno v následující syntaxi:

Workflow Test-Workflow
{
    <Commands>
}

Název pracovního postupu se musí shodovat s názvem runbooku Automation. Pokud se runbook importuje, musí se název souboru shodovat s názvem pracovního postupu a musí končit příponou .ps1.

Pokud chcete do pracovního postupu přidat parametry, použijte Param klíčové slovo stejně jako ve skriptu.

Informace o rozdílech mezi kódem pracovního postupu PowerShellu a kódem skriptu PowerShellu

Kód pracovního postupu PowerShellu vypadá téměř stejně jako kód skriptu PowerShellu s výjimkou několika významných změn. Následující části popisují změny, které je potřeba provést ve skriptu PowerShellu, aby se spustil v pracovním postupu.

Aktivity

Aktivita je konkrétní úkol v pracovním postupu, který se provádí v pořadí. Pracovní postup Windows PowerShellu automaticky převádí mnoho rutin prostředí Windows PowerShell na aktivity při spuštění pracovního postupu. Když v runbooku zadáte jednu z těchto rutin, spustí se odpovídající aktivita službou Windows Workflow Foundation.

Pokud rutina nemá žádnou odpovídající aktivitu, pracovní postup Windows PowerShellu automaticky spustí rutinu v aktivitě InlineScriptu . Některé rutiny jsou vyloučené a nelze je použít v pracovním postupu, pokud je explicitně nezahrnete do bloku InlineScript. Další informace naleznete v tématu Použití aktivit v pracovních postupech skriptů.

Aktivity pracovního postupu sdílejí sadu společných parametrů pro konfiguraci jejich operace. Viz about_WorkflowCommonParameters.

Poziční parametry

V pracovním postupu nemůžete použít poziční parametry s aktivitami a rutinami. Proto je nutné použít názvy parametrů. Vezměte v úvahu následující kód, který získá všechny spuštěné služby:

Get-Service | Where-Object {$_.Status -eq "Running"}

Pokud se pokusíte spustit tento kód v pracovním postupu, zobrazí se zpráva, jako Parameter set cannot be resolved using the specified named parameters. je Třeba opravit pro tento problém, zadejte název parametru, jak je znázorněno v následujícím příkladu:

Workflow Get-RunningServices
{
    Get-Service | Where-Object -FilterScript {$_.Status -eq "Running"}
}

Deserializované objekty

Objekty v pracovních postupech jsou deserializovány, což znamená, že jejich vlastnosti jsou stále k dispozici, ale ne jejich metody. Představte si například následující kód PowerShellu, který zastaví službu pomocí Stop metody objektu Service .

$Service = Get-Service -Name MyService
$Service.Stop()

Pokud se to pokusíte spustit v pracovním postupu, zobrazí se chybová zpráva Method invocation is not supported in a Windows PowerShell Workflow.

Jednou z možností je zabalit tyto dva řádky kódu do bloku InlineScript . V tomto případě Service představuje objekt služby v rámci bloku.

Workflow Stop-Service
{
    InlineScript {
        $Service = Get-Service -Name MyService
        $Service.Stop()
    }
}

Další možností je použít jinou rutinu, která má stejné funkce jako metoda, pokud je k dispozici. V našem příkladu Stop-Service poskytuje rutina stejné funkce jako Stop metoda a pro pracovní postup můžete použít následující kód.

Workflow Stop-MyService
{
    $Service = Get-Service -Name MyService
    Stop-Service -Name $Service.Name
}

Použití inlineScriptu

AktivitaInlineScript je užitečná, když potřebujete spustit jeden nebo více příkazů jako tradiční skript PowerShellu místo pracovního postupu PowerShellu. Zatímco příkazy v pracovním postupu se odesílají do windows Workflow Foundation ke zpracování, příkazy v bloku InlineScript se zpracovávají prostředím Windows PowerShell.

InlineScript používá následující syntaxi, která je znázorněna níže.

InlineScript
{
    <Script Block>
} <Common Parameters>

Výstup z inlineScriptu můžete vrátit přiřazením výstupu k proměnné. Následující příklad zastaví službu a pak vypíše název služby.

Workflow Stop-MyService
{
    $Output = InlineScript {
        $Service = Get-Service -Name MyService
        $Service.Stop()
        $Service
    }

    $Output.Name
}

Hodnoty můžete předat do bloku InlineScriptu, ale musíte použít modifikátor oboru $Using . Následující příklad je stejný jako v předchozím příkladu s tím rozdílem, že název služby je poskytován proměnnou.

Workflow Stop-MyService
{
    $ServiceName = "MyService"

    $Output = InlineScript {
        $Service = Get-Service -Name $Using:ServiceName
        $Service.Stop()
        $Service
    }

    $Output.Name
}

I když v určitých pracovních postupech můžou být aktivity inlineScriptu kritické, nepodporují konstruktory pracovního postupu. Měli byste je použít pouze v případě potřeby z následujících důvodů:

Další informace o použití inlineScriptu najdete v tématu Spouštění příkazů prostředí Windows PowerShell v pracovním postupu a about_InlineScript.

Použití paralelního zpracování

Jednou z výhod pracovních postupů Windows PowerShellu je možnost provádět sadu příkazů paralelně, nikoli postupně jako u typického skriptu.

Pomocí klíčového Parallel slova můžete vytvořit blok skriptu s více příkazy, které běží souběžně. Používá se následující syntaxe. V tomto případě se aktivita 1 a aktivita2 spustí současně. Aktivita 3 se spustí až po dokončení aktivity Activity1 i Activity2.

Parallel
{
    <Activity1>
    <Activity2>
}
<Activity3>

Představte si například následující příkazy PowerShellu, které zkopírují více souborů do cílové sítě. Tyto příkazy se spouštějí postupně, aby jeden soubor musel dokončit kopírování před dalším spuštěním.

Copy-Item -Path C:\LocalPath\File1.txt -Destination \\NetworkPath\File1.txt
Copy-Item -Path C:\LocalPath\File2.txt -Destination \\NetworkPath\File2.txt
Copy-Item -Path C:\LocalPath\File3.txt -Destination \\NetworkPath\File3.txt

Následující pracovní postup spouští tyto stejné příkazy paralelně, aby se všechny spustily kopírování ve stejnou dobu. Až po zkopírování se zobrazí zpráva o dokončení.

Workflow Copy-Files
{
    Parallel
    {
        Copy-Item -Path "C:\LocalPath\File1.txt" -Destination "\\NetworkPath"
        Copy-Item -Path "C:\LocalPath\File2.txt" -Destination "\\NetworkPath"
        Copy-Item -Path "C:\LocalPath\File3.txt" -Destination "\\NetworkPath"
    }

    Write-Output "Files copied."
}

Konstruktor můžete použít ForEach -Parallel ke zpracování příkazů pro každou položku v kolekci současně. Položky v kolekci se zpracovávají paralelně, zatímco příkazy v bloku skriptu se spouštějí postupně. Tento proces používá následující syntaxi, jak je znázorněno níže. V tomto případě se aktivita Activity1 spustí současně pro všechny položky v kolekci. U každé položky se aktivita Activity2 spustí po dokončení aktivity Activity1. Aktivita 3 se spustí až po dokončení aktivity Activity1 i Activity2 pro všechny položky. K omezení paralelismu používáme ThrottleLimit parametr. Příliš vysoká z toho ThrottleLimit může způsobit problémy. Ideální hodnota parametru ThrottleLimit závisí na mnoha faktorech ve vašem prostředí. Začněte s nízkou hodnotou a zkuste různé zvýšení hodnot, dokud nenajdete hodnotu, která bude fungovat pro konkrétní okolnosti.

ForEach -Parallel -ThrottleLimit 10 ($<item> in $<collection>)
{
    <Activity1>
    <Activity2>
}
<Activity3>

Následující příklad je podobný předchozímu příkladu, který paralelně kopíruje soubory. V tomto případě se po zkopírování zobrazí zpráva pro každý soubor. Až po jejich zkopírování se zobrazí konečná zpráva o dokončení.

Workflow Copy-Files
{
    $files = @("C:\LocalPath\File1.txt","C:\LocalPath\File2.txt","C:\LocalPath\File3.txt")

    ForEach -Parallel -ThrottleLimit 10 ($File in $Files)
    {
        Copy-Item -Path $File -Destination \\NetworkPath
        Write-Output "$File copied."
    }

    Write-Output "All files copied."
}

Poznámka:

Nedoporučujeme spouštět podřízené runbooky paralelně, protože se ukázalo, že poskytují nespolehlivé výsledky. Výstup podřízeného runbooku se někdy nezobrazuje a nastavení v jednom podřízené runbooku může ovlivnit ostatní paralelní podřízené runbooky. Proměnné, jako VerbosePreferenceje například , WarningPreferencea jiné se nemusí rozšířit do podřízených runbooků. A pokud podřízený runbook změní tyto hodnoty, nemusí se po vyvolání správně obnovit.

Použití kontrolních bodů v pracovním postupu

Kontrolní bod je snímek aktuálního stavu pracovního postupu, který obsahuje aktuální hodnoty proměnných a veškerý výstup vygenerovaný do tohoto bodu. Pokud pracovní postup skončí chybou nebo je pozastavený, začne od posledního kontrolního bodu při příštím spuštění, místo aby začínal na začátku.

Kontrolní bod můžete nastavit v pracovním postupu s aktivitou Checkpoint-Workflow . Azure Automation má funkci označovanou jako spravedlivé sdílení, pro kterou se všechny runbooky, které běží po dobu tří hodin, uvolní, aby mohly běžet i jiné runbooky. Nakonec se uvolněný runbook znovu načte. Když je, obnoví provádění z posledního kontrolního bodu pořízeného v runbooku.

Pokud chcete zaručit, že se runbook nakonec dokončí, musíte přidat kontrolní body v intervalech, které běží po dobu kratší než tři hodiny. Pokud se během každého spuštění přidá nový kontrolní bod a pokud se sada Runbook vyřadí po třech hodinách kvůli chybě, runbook se trvale obnoví.

V následujícím příkladu dojde k výjimce po aktivitě Activity2, což způsobí ukončení pracovního postupu. Když se pracovní postup spustí znovu, spustí se aktivita Activity2, protože tato aktivita byla těsně po poslední sadě kontrolních bodů.

<Activity1>
Checkpoint-Workflow
<Activity2>
<Exception>
<Activity3>

Nastavte kontrolní body v pracovním postupu po aktivitách, které mohou být náchylné k výjimce a neměly by se opakovat, pokud je pracovní postup obnoven. Váš pracovní postup může například vytvořit virtuální počítač. Kontrolní bod můžete nastavit před i po příkazech pro vytvoření virtuálního počítače. Pokud se vytvoření nezdaří, příkazy se opakují, pokud se pracovní postup spustí znovu. Pokud se pracovní postup po úspěšném vytvoření nezdaří, po obnovení pracovního postupu se virtuální počítač znovu nevytvoří.

Následující příklad zkopíruje více souborů do síťového umístění a nastaví kontrolní bod za každým souborem. Pokud dojde ke ztrátě síťového umístění, pracovní postup skončí chybou. Po opětovném spuštění se obnoví na posledním kontrolním bodu. Přeskočí se jenom soubory, které už byly zkopírovány.

Workflow Copy-Files
{
    $files = @("C:\LocalPath\File1.txt","C:\LocalPath\File2.txt","C:\LocalPath\File3.txt")

    ForEach ($File in $Files)
    {
        Copy-Item -Path $File -Destination \\NetworkPath
        Write-Output "$File copied."
        Checkpoint-Workflow
    }

    Write-Output "All files copied."
}

Vzhledem k tomu, že přihlašovací údaje uživatelského jména se neuchovávají po volání aktivity Pozastavení pracovního postupu nebo po posledním kontrolním bodu, musíte nastavit přihlašovací údaje na hodnotu null a potom je znovu načíst z úložiště prostředků po Suspend-Workflow volání nebo kontrolního bodu. V opačném případě se může zobrazit následující chybová zpráva: The workflow job cannot be resumed, either because persistence data could not be saved completely, or saved persistence data has been corrupted. You must restart the workflow.

Následující stejný kód ukazuje, jak tuto situaci zvládnout v runbookech pracovního postupu PowerShellu.

workflow CreateTestVms
{
    $Cred = Get-AzAutomationCredential -Name "MyCredential"
    $null = Connect-AzAccount -Credential $Cred

    $VmsToCreate = Get-AzAutomationVariable -Name "VmsToCreate"

    foreach ($VmName in $VmsToCreate)
        {
        # Do work first to create the VM (code not shown)

        # Now add the VM
        New-AzVM -VM $Vm -Location "WestUs" -ResourceGroupName "ResourceGroup01"

        # Checkpoint so that VM creation is not repeated if workflow suspends
        $Cred = $null
        Checkpoint-Workflow
        $Cred = Get-AzAutomationCredential -Name "MyCredential"
        $null = Connect-AzAccount -Credential $Cred
        }
}

Poznámka:

Pro jiné než grafické runbooky Add-AzAccount PowerShellu a Add-AzureRMAccount jsou aliasy pro Připojení-AzAccount. Tyto rutiny můžete použít nebo můžete moduly v účtu Automation aktualizovat na nejnovější verze. Možná budete muset aktualizovat moduly, i když jste právě vytvořili nový účet Automation.

Další informace o kontrolních bodech naleznete v tématu Přidání kontrolních bodů do pracovního postupu skriptu.

Další kroky

  • Další informace o runbookech pracovních postupů PowerShellu najdete v tématu Kurz: Vytvoření runbooku pracovního postupu PowerShellu.