Poznaj przepływ pracy programu PowerShell dla Azure Automation

W programie Azure Automation są implementowane jako Windows PowerShell przepływy pracy, Windows PowerShell skrypty, które używają Windows Workflow Foundation. Przepływ pracy to sekwencja zaprogramowanych, połączonych ze sobą czynności służących do wykonywania długotrwałych zadań lub do zapewnienia koordynacji wielu czynności na wielu różnych urządzeniach albo w wielu węzłach zarządzanych.

Przepływ pracy jest napisany przy użyciu Windows PowerShell składni i uruchomiony przez Windows PowerShell, ale jest przetwarzany przez Windows Workflow Foundation. Zalety przepływu pracy w stosunku do normalnego skryptu obejmują jednoczesną wydajność akcji dla wielu urządzeń i automatyczne odzyskiwanie po awarii.

Uwaga

Skrypt przepływu pracy programu PowerShell jest bardzo podobny do skryptu Windows PowerShell, ale ma pewne istotne różnice, które mogą być mylące dla nowego użytkownika. W związku z tym zaleca się pisanie podręczników Runbook przy użyciu przepływu pracy programu PowerShell tylko wtedy, gdy konieczne jest użycie punktów kontrolnych.

Aby uzyskać szczegółowe informacje na temat tematów w tym artykule, zobacz Wprowadzenie with Windows PowerShell Workflow (Zarządzanie przepływem pracy Windows PowerShell).

Używanie słowa kluczowego przepływu pracy

Pierwszym krokiem konwersji skryptu programu PowerShell na przepływ pracy programu PowerShell jest dołączenie go do słowa Workflow kluczowego . Przepływ pracy rozpoczyna się od słowa Workflow kluczowego , po którym następuje treść skryptu ujęta w nawiasy klamrowe. Nazwa przepływu pracy jest zgodna ze słowem Workflow kluczowym , jak pokazano w następującej składni:

Workflow Test-Workflow
{
    <Commands>
}

Nazwa przepływu pracy musi być dopasowana do nazwy runbook usługi Automation. Jeśli importowany jest podręcznik Runbook, nazwa pliku musi być dopasowana do nazwy przepływu pracy i kończyć się na .ps1.

Aby dodać parametry do przepływu pracy, użyj słowa kluczowego , tak jak w Param skrypcie.

Różnice między kodem przepływu pracy programu PowerShell i kodem skryptu programu PowerShell

Kod przepływu pracy programu PowerShell wygląda niemal tak samo jak kod skryptu programu PowerShell z wyjątkiem kilku znaczących zmian. W poniższych sekcjach opisano zmiany, które należy wprowadzić w skrypcie programu PowerShell, aby można było go uruchomić w przepływie pracy.

Działania

Działanie to określone zadanie w przepływie pracy, które jest wykonywane w sekwencji. Podczas wykonywania przepływu pracy program Windows PowerShell Workflow automatycznie konwertuje wiele spośród poleceń cmdlet środowiska Windows PowerShell na działania. Po określeniu jednego z tych cmdlet w programie Runbook odpowiednie działanie jest uruchamiane przez Windows Workflow Foundation.

Jeśli polecenie cmdlet nie ma odpowiadającego mu działania, program Windows PowerShell Workflow automatycznie uruchamia polecenie cmdlet w działaniu InlineScript. Niektóre polecenia cmdlet są wykluczone i nie można ich używać w przepływie pracy, chyba że jawnie dołączysz je do bloku InlineScript. Aby uzyskać więcej informacji, zobacz Using Activities in Script Workflows (Używanie działań w przepływach pracy skryptu).

Działania przepływów pracy dzielą zestaw wspólnych parametrów konfigurujących ich pracę. Zobacz about_WorkflowCommonParameters.

Parametry pozyacyjne

Nie można używać parametrów pozyczkowych z działaniami i poleceniami cmdlet w przepływie pracy. W związku z tym należy użyć nazw parametrów. Rozważmy następujący kod, który pobiera wszystkie uruchomione usługi:

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

Jeśli spróbujesz uruchomić ten kod w przepływie pracy, zostanie wyświetlony komunikat, taki jak Aby rozwiązać ten problem, podaj nazwę parametru, jak w Parameter set cannot be resolved using the specified named parameters. poniższym przykładzie:

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

Deserializowane obiekty

Obiekty w przepływach pracy są deserializowane, co oznacza, że ich właściwości są nadal dostępne, ale nie ich metody. Rozważmy na przykład następujący kod programu PowerShell, który zatrzymuje usługę Stop przy użyciu metody obiektu Service .

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

Jeśli spróbujesz uruchomić to w przepływie pracy, zostanie wyświetlony komunikat o błędzie Method invocation is not supported in a Windows PowerShell Workflow.

Jedną z opcji jest zawijanie tych dwóch wierszy kodu w bloku InlineScript. W tym przypadku Service reprezentuje obiekt usługi w bloku.

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

Inną opcją jest użycie innego polecenia cmdlet, które ma taką samą funkcjonalność jak metoda , jeśli jest dostępne. W naszym przykładzie polecenie cmdlet zapewnia taką samą funkcjonalność jak metoda i można użyć następującego Stop-Service Stop kodu dla przepływu pracy.

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

Korzystanie z inlineScript

To działanie jest przydatne, gdy trzeba uruchomić co najmniej jedno polecenie jako tradycyjny InlineScript skrypt programu PowerShell zamiast przepływu pracy programu PowerShell. Podczas gdy polecenia zawarte w przepływie pracy są wysyłane do przetwarzania w programie Windows Workflow Foundation, polecenia umieszczone w bloku InlineScript są przetwarzane w środowisku Windows PowerShell.

W języku InlineScript jest używana następująca składnia pokazana poniżej.

InlineScript
{
    <Script Block>
} <Common Parameters>

Dane wyjściowe z inlineScript można zwrócić, przypisując dane wyjściowe do zmiennej. Poniższy przykład zatrzymuje usługę, a następnie wyprowadza nazwę usługi.

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

    $Output.Name
}

Wartości można przekazać do bloku InlineScript, ale należy użyć $Using zakresu. Poniższy przykład jest identyczny z poprzednim przykładem, z tą różnicą, że nazwa usługi jest dostarczana przez zmienną.

Workflow Stop-MyService
{
    $ServiceName = "MyService"

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

    $Output.Name
}

Działania InlineScript mogą być krytyczne w niektórych przepływach pracy, ale nie obsługują konstrukcji przepływu pracy. Należy ich używać tylko w razie potrzeby z następujących powodów:

  • Punktów kontrolnych nie można używać wewnątrz bloku InlineScript. Jeśli w bloku wystąpi awaria, musi zostać wznowiona od początku bloku.
  • Nie można używać wykonywania równoległego wewnątrz bloku InlineScript.
  • Skrypt InlineScript wpływa na skalowalność przepływu pracy, ponieważ Windows PowerShell sesję przez całą długość bloku InlineScript.

Aby uzyskać więcej informacji na temat korzystania z języka InlineScript, zobacz Uruchamianie poleceń Windows PowerShell w przepływie pracy i about_InlineScript.

Korzystanie z przetwarzania równoległego

Jedną z korzyści wynikających z używania przepływów pracy w środowisku Windows PowerShell jest możliwość wykonywania zestawów poleceń równolegle, w przeciwieństwie do wykonywania sekwencyjnego, jak w typowym skrypcie.

Możesz użyć słowa Parallel kluczowego , aby utworzyć blok skryptu z wieloma poleceniami uruchamianymi jednocześnie. W tym celu jest używana następująca składnia pokazana poniżej. W takim przypadku działania Activity1 i Activity2 są rozpoczynane w tym samym czasie. Działanie Activity3 jest uruchamiane dopiero po zakończeniu działań Activity1 i Activity2.

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

Rozważmy na przykład następujące polecenia programu PowerShell, które kopiują wiele plików do lokalizacji docelowej sieci. Te polecenia są uruchamiane sekwencyjnie, tak aby jeden plik musiał zakończyć kopiowanie przed następnym uruchomieniem.

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

W poniższym przepływie pracy te same polecenia są uruchamiane równolegle, tak aby wszystkie one rozpoczynały kopiowanie w tym samym czasie. Dopiero po ich skopiowaniu zostanie wyświetlony komunikat o ukończeniu.

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

Za pomocą konstrukcji ForEach -Parallel można przetwarzać polecenia dla każdego elementu w kolekcji jednocześnie. Elementy w kolekcji są przetwarzane współbieżnie, podczas gdy polecenia w bloku skryptu są wykonywane sekwencyjnie. W tym procesie jest używana następująca składnia pokazana poniżej. W takim przypadku działanie Activity1 rozpoczyna się w tym samym czasie dla wszystkich elementów w kolekcji. Dla każdego elementu działanie Activity2 rozpoczyna się po zakończeniu działania Activity1. Działanie Activity3 jest uruchamiane dopiero po zakończeniu działań Activity1 i Activity2 dla wszystkich elementów. Używamy ThrottleLimit parametru , aby ograniczyć równoległość. Zbyt wysoki poziom może ThrottleLimit powodować problemy. Idealna wartość parametru ThrottleLimit zależy od wielu czynników w środowisku. Zacznij od niskiej wartości i wypróbuj różne wartości rosnące, aż znajdziesz taką, która będzie sprawdzać się w konkretnym przypadku.

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

Poniższy przykład jest podobny do poprzedniego przykładu równoległego kopiowania plików. W takim przypadku dla każdego pliku po jego skopiowaniu jest wyświetlany komunikat. Dopiero po ich skopiowaniu zostanie wyświetlony końcowy komunikat o ukończeniu.

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

Uwaga

Nie zalecamy równoległego uruchamiania podrzędnych runbook, ponieważ pokazano, że daje to zawodne wyniki. Dane wyjściowe podrzędnego podręcznika Runbook czasami nie są wyświetlane, a ustawienia w jednym podrzędnym runbook mogą mieć wpływ na inne równoległe podrzędne podręczniki Runbook. Zmienne, takie VerbosePreference jak , i WarningPreference inne, mogą nie być propagowane do podrzędnych podręczników Runbook. Jeśli podrzędny podręcznik Runbook zmieni te wartości, mogą one nie zostać prawidłowo przywrócone po wywołaniach.

Używanie punktów kontrolnych w przepływie pracy

Punkt kontrolny to migawka bieżącego stanu przepływu pracy, która zawiera bieżące wartości zmiennych i wszystkie wygenerowane do tego momentu dane wyjściowe. Jeśli przepływ pracy kończy się błędem lub został zawieszony, rozpoczyna się od ostatniego punktu kontrolnego przy następnym uruchomieniu, zamiast rozpoczynać się od początku.

Możesz ustawić punkt kontrolny w przepływie pracy za pomocą Checkpoint-Workflow działania . Azure Automation ma funkcję o nazwie fair share, dla której każdy element Runbook uruchamiany przez trzy godziny jest zwalniany w celu umożliwienia uruchamiania innych elementach Runbook. Po pewnym czasie niezaładowany runbook zostanie ponownie załadowany. Gdy tak jest, wznawia wykonywanie od ostatniego punktu kontrolnego w tym runbook.

Aby zagwarantować, że ten runbook zostanie ukończony, należy dodać punkty kontrolne w odstępach czasu, które będą działać mniej niż trzy godziny. Jeśli podczas każdego uruchomienia zostanie dodany nowy punkt kontrolny, a element Runbook zostanie eksmitowany po trzech godzinach z powodu błędu, element Runbook zostanie wznowiony na czas nieokreślony.

W poniższym przykładzie po działaniu Activity2 występuje wyjątek, co powoduje zakończenie przepływu pracy. Gdy przepływ pracy zostanie uruchomiony ponownie, rozpocznie się od uruchomienia działania Activity2, ponieważ to działanie było tuż po ostatnim zestawie punktów kontrolnych.

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

Ustaw punkty kontrolne w przepływie pracy po działaniach, które mogą być podatne na wyjątek i nie powinny być powtarzane, jeśli przepływ pracy zostanie wznowiony. Na przykład przepływ pracy może utworzyć maszynę wirtualną. Punkt kontrolny można ustawić zarówno przed, jak i po poleceniach, aby utworzyć maszynę wirtualną. Jeśli tworzenie nie powiedzie się, polecenia zostaną powtórzone, jeśli przepływ pracy zostanie ponownie uruchomiony. Jeśli przepływ pracy zakończy się niepowodzeniem po zakończeniu tworzenia, maszyna wirtualna nie zostanie utworzona ponownie po wznowieniu przepływu pracy.

Poniższy przykład kopiuje wiele plików do lokalizacji sieciowej i ustawia punkt kontrolny po każdym pliku. Jeśli lokalizacja sieciowa zostanie utracona, przepływ pracy zakończy się błędem. Po jego wznowieniu w ostatnim punkcie kontrolnym. Pomijane są tylko pliki, które zostały już skopiowane.

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

Ponieważ poświadczenia nazwy użytkownika nie są utrwalane po wywołaniu działania Suspend-Workflow lub po ostatnim punkcie kontrolnym, należy ustawić poświadczenia na wartość null, a następnie pobrać je ponownie z magazynu zasobów po wywołaniu punktu kontrolnego lub Suspend-Workflow . W przeciwnym razie może zostać wyświetlony następujący komunikat o błędzie: 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.

Poniższy kod przedstawia sposób obsługi tej sytuacji w elementy Runbook przepływu pracy programu PowerShell.

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

Uwaga

W przypadku niegraficznych elementów Runbook programu PowerShell Add-AzAccount i Add-AzureRMAccount są aliasami polecenia Connect-AzAccount. Możesz użyć tych polecenia cmdlet lub zaktualizować moduły na koncie usługi Automation do najnowszych wersji. Może być konieczne zaktualizowanie modułów, nawet jeśli właśnie utworzono nowe konto usługi Automation. Korzystanie z tych polecenia cmdlet nie jest wymagane w przypadku uwierzytelniania przy użyciu konta Uruchom jako skonfigurowanego przy użyciu jednostki usługi.

Aby uzyskać więcej informacji na temat punktów kontrolnych, zobacz Dodawanie punktów kontrolnych do przepływu pracy skryptu.

Następne kroki