Udostępnij za pośrednictwem

  • Artykuł

Pojęcia dotyczące elementów Runbook

 

Opublikowano: marzec 2016

Dotyczy: Windows Azure Pack for Windows Server, System Center 2012 R2 Orchestrator

Elementy Runbook automatyzacji są zaimplementowane jako przepływy pracy środowiska Windows PowerShell. Ta sekcja stanowi skrótowy przegląd istotnych funkcji przepływu pracy typowych dla elementów Runbook struktury Automatyzacja. Szczegółowe informacje dotyczące przepływów pracy są dostępne w sekcji Wprowadzenie do programu Windows PowerShell Workflow.

Struktura elementów Runbook dla programu Automatyzacja zarządzania usługami i dla Automatyzacji Microsoft Azure jest taka sama, mimo że te dwa programy zwykle współdziałają z różnymi zasobami.

Przepływy pracy Windows PowerShell

Przepływ pracy to sekwencja zaprogramowanych, połączonych kroków, wykonujących długo trwające zadania lub wymagających koordynacji wielu kroków na wielu urządzeniach lub zarządzanych węzłach. Korzyści ze stosowania przepływu pracy zamiast zwykłego skryptu obejmują możliwość jednoczesnego wykonywania akcji na różnych urządzeniach oraz zdolność usuwania skutków błędów. Przepływ pracy w środowisku Windows PowerShell to skrypt środowiska Windows PowerShell, który korzysta z programu Windows Workflow Foundation. Przepływ pracy ma składnię Windows PowerShell i jest uruchamiany przez środowisko Windows PowerShell, jednak jest przetwarzany przez program Windows Workflow Foundation.

Podstawowa struktura

Przepływ pracy Windows PowerShell jest uruchamiany za pośrednictwem słowa kluczowego Workflow, po którym występuje ujęta w nawiasy treść skryptu. Nazwa przepływu pracy znajduje się po słowie kluczowym Workflow, zgodnie z poniższą składnią. Nazwa przepływu pracy odpowiada nazwie elementu Runbook struktury Automatyzacja.

Workflow Test-Runbook
{
   <Commands>
}

Aby dodać parametry do przepływu pracy, należy użyć słowa kluczowego Param, zgodnie z poniższą składnią. Podczas uruchamiania elementu Runbook przez użytkownika w portalu zarządzania pojawia się monit o podanie wartości tych parametrów. W przykładzie pokazano opcjonalny atrybut Parameter, który określa, czy wystąpienie parametru jest obowiązkowe, czy nie.

Workflow Test-Runbook
{
  Param
  (
   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>,

   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>
  )
  <Commands>
}

Nazewnictwo

Nazwa przepływu pracy powinna być zgodna z formatem czasownik-rzeczownik, który jest standardem w środowisku Windows PowerShell. Lista zatwierdzonych czasowników, z których można skorzystać, znajduje się w dokumencie Czasowniki zatwierdzone do użycia w poleceniach Windows PowerShell. Nazwa przepływu pracy musi odpowiadać nazwie elementu Runbook struktury Automatyzacja. Jeśli element Runbook jest importowany, nazwa pliku musi odpowiadać nazwie przepływu pracy i kończyć się rozszerzeniem .ps1.

Ograniczenia

Aby zapoznać się z pełną listą ograniczeń i różnic składni między przepływami pracy środowiska Windows PowerShell a programem Windows PowerShell, zobacz Różnice składniowe między przepływami pracy skryptów i skryptami.

Działania

Działanie jest konkretnym zadaniem w przepływie pracy. Tak jak skrypt jest złożony z jednego lub większej liczby poleceń, przepływ pracy składa się z jednego lub większej liczby działań, wykonywanych w kolejności. Podczas wykonywania przepływu pracy program Windows PowerShell Workflow automatycznie konwertuje wiele spośród poleceń cmdlet środowiska Windows PowerShell na działania. Po podaniu jednego z tych poleceń cmdlet w elemencie Runbook odpowiadające mu działanie jest uruchamiane przez program Windows Workflow Foundation. W przypadku poleceń cmdlet, które nie mają odpowiadających im działań, przepływ pracy środowiska Windows PowerShell automatycznie uruchamia polecenie cmdlet w ramach działania InlineScript. Istnieje zestaw poleceń cmdlet, które są wykluczone i nie mogą być używane w przepływie pracy, chyba że zostaną jawnie dołączone w bloku InlineScript. Więcej szczegółowych informacji dotyczących tych pojęć można znaleźć w sekcji Używanie działań w skryptowych przepływach pracy.

Działania przepływów pracy dzielą zestaw wspólnych parametrów konfigurujących ich pracę. Szczegółowe informacje dotyczące wspólnych parametrów przepływów pracy można znaleźć w sekcji about_WorkflowCommonParameters.

Moduły integracji

Moduł integracji to pakiet zawierający moduł programu Windows PowerShell, który może zostać zaimportowany do struktury Automatyzacja. Moduły programu Windows PowerShell zawierają polecenia cmdlet, których można używać w elementach Runbook programu Automatyzacja. Produkty i usługi, takie jak program Operations Manager i systemem Azure, obejmują moduły zawierające specyficzne dla ich działania polecenia cmdlet.

Moduły integracji zaimportowane do programu Automatyzacja są automatycznie dostępne dla wszystkich elementów Runbook. Ponieważ rozwiązanie Automatyzacja jest oparte na Windows PowerShell 4.0, obsługuje automatyczne ładowanie modułów, co oznacza, że polecenia cmdlet z zainstalowanych modułów mogą być używane bez potrzeby importowania ich do skryptu za pomocą polecenia Import-Module.

Do struktury Automatyzacja można zaimportować każdy moduł Windows PowerShell, jeśli tylko wszystkie jego zależności można umieścić w pojedynczym folderze. Jeśli moduł jest uzależniony od ustawień rejestru lub plików umieszczonych poza domyślną ścieżką, można go zaimportować, ale najprawdopodobniej nie będzie działał, ponieważ rozwiązanie Automatyzacja nie będzie mogło zlokalizować jego zależności. Modułów z zależnościami zewnętrznymi można używać w elemencie Runbook przez zainstalowanie ich na innym hoście używającym ich i uzyskującym do nich dostęp za pomocą bloku skryptu a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_InlineScript.

W przypadku programu Automatyzacja zarządzania usługami można używać modułów z zależnościami zewnętrznymi, instalując je na każdym serwerze procesu roboczego. Choć polecenia cmdlet w tych modułach mogą być używane w elementach Runbook, nie są one wykrywane przez rozwiązanie Automatyzacja do obsługi takich funkcji, jak kreator wstawiania działań. Aby użyć tej funkcji, można utworzyć moduł przenośny za pomocą polecenia cmdlet New-SmaPortableModule. To polecenie cmdlet tworzy moduł zawierający szkielet każdego z jego poleceń cmdlet, gotowy do zaimportowania do struktury Automatyzacja. Gdy element Runbook używa jednego z tych poleceń cmdlet, szkielet przekierowuje wywołanie do właściwego polecenia cmdlet w module zewnętrznym. Tamten moduł musi być zainstalowany na każdym serwerze Worker lub wywołanie zakończy się niepowodzeniem.

Wykonywanie równoległe

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. Jest to szczególnie przydatne w elementach Runbook, ponieważ mogą one wykonywać wiele akcji, których ukończenie wymaga długiego czasu. Przykładowo element Runbook może zainicjować obsługę administracyjną zestawu maszyn wirtualnych. Zamiast kolejno jeden po drugim wykonywać procesy inicjujące obsługę administracyjną, można wykonać akcje równocześnie, poprawiając ogólną wydajność. Dopiero po ukończeniu wszystkich procesów element Runbook będzie kontynuował pracę.

Do utworzenia bloku skryptu z wieloma poleceniami, które będą działały współbieżnie, można użyć słowa kluczowego Parallel. Ta metoda korzysta z pokazanej poniżej składni. W tym przypadku działania Activity1 i Activity2 zostaną uruchomione w tym samym czasie. Działanie Activity3 zostanie uruchomione dopiero po zakończeniu obu poprzednich działań.

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

Do współbieżnego przetwarzania poleceń dla każdego elementu w kolekcji można zastosować konstrukcję ForEach -Parallel. Elementy w kolekcji są przetwarzane współbieżnie, podczas gdy polecenia w bloku skryptu są wykonywane sekwencyjnie. Ta metoda korzysta z pokazanej poniżej składni. W tym przypadku działanie Activity1 zostanie uruchomione w tym samym czasie dla wszystkich elementów w kolekcji. Dla każdego elementu działanie Activity2 zostanie uruchomione po zakończeniu działania Activity1. Działanie Activity3 zostanie uruchomione dopiero po zakończeniu obu poprzednich działań dla wszystkich elementów.

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

Do sekwencyjnego uruchamiania poleceń w bloku skryptu Sequence służy słowo kluczowe Parallel. Blok skryptu Sequence jest wykonywany współbieżnie z innymi poleceniami, ale polecenia wewnątrz bloku są wykonywane sekwencyjnie. Ta metoda korzysta z pokazanej poniżej składni. W tym przypadku działania Activity1, Activity2 i Activity3 zostaną uruchomione w tym samym czasie. Działanie Activity4 zostanie uruchomione dopiero po zakończeniu działania Activity3. Działanie Activity5 zostanie uruchomione po zakończeniu wszystkich innych działań.

Parallel
{
  <Activity1>
  <Activity2>

  Sequence 
  {
   <Activity3>
   <Activity4>
  }
}
<Activity5>

Punkty kontrolne

Punkt kontrolny to migawka bieżącego stanu przepływu pracy, która zawiera bieżące wartości zmiennych i wszystkie wartości wyjściowe wygenerowane do tego momentu. Ostatni punkt kontrolny do wykonania w elemencie Runbook jest zapisywany w bazie danych programu Automatyzacja, co pozwala wznowić przepływ pracy nawet w przypadku awarii. Dane punktu kontrolnego są usuwane po zakończeniu zadania elementu Runbook.

Punkt kontrolny w przepływie pracy można ustawić za pomocą działania Checkpoint-Workflow. Po umieszczeniu tego działania w elemencie Runbook natychmiast ustanawiany jest punkt kontrolny. Jeśli element Runbook zostanie wstrzymany z powodu błędu, zadanie zostanie wznowione od miejsca ustawienia ostatniego punktu kontrolnego.

W poniższym przykładowym kodzie błąd wystąpi po działaniu Activity2 i spowoduje wstrzymanie elementu Runbook. Po wznowieniu zadania rozpoczyna się ono od wykonania działania Activity2, ponieważ przypadało ono zaraz po ostatnim ustawionym punkcie kontrolnym.

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

Punkty kontrolne w elemencie Runbook należy umieszczać po działaniach, które mogą być podatne na błędy i nie powinny być powtarzane po wznowieniu elementu Runbook. Przykładowo element Runbook może tworzyć maszynę wirtualną. Punkt kontrolny można ustawić przed poleceniami tworzącymi maszynę wirtualną i po nich. Jeśli tworzenie zakończy się niepowodzeniem, polecenia zostaną powtórzone po wznowieniu elementu Runbook. Jeśli tworzenie zakończy się sukcesem, ale błąd wystąpi w dalszej części elementu Runbook, maszyna wirtualna nie zostanie ponownie utworzona po wznowieniu elementu Runbook.

Więcej informacji na temat punktów kontrolnych można znaleźć w sekcji Dodawanie punktów kontrolnych do skryptowego przepływu pracy.

Wstrzymanie elementu Runbook

Za pomocą działania Suspend-Workflow można spowodować wstrzymanie elementu Runbook. To działanie wstawia punkt kontrolny i powoduje natychmiastowe wstrzymanie przepływu pracy. Wstrzymanie przepływu pracy jest przydatne w przypadku elementów Runbook mogących wymagać ręcznego wykonania kroku przed uruchomieniem innego zestawu działań.

Więcej informacji na temat wstrzymywania przepływu pracy można znaleźć w sekcji Samodzielne wstrzymywanie przepływów pracy.

InlineScript

Działanie InlineScript uruchamia blok poleceń w oddzielnej sesji bez przepływu pracy i zwraca jego wyjście do przepływu pracy. 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. Działanie wykorzystuje standardowe wspólne parametry przepływu pracy, w tym PSComputerName i PSCredential, co pozwala użytkownikowi na określenie, że blok kodu ma zostać uruchomiony na innym komputerze lub przy użyciu innych poświadczeń.

Blok InlineScript wykorzystuje podaną niżej składnię.

InlineScript
{
  <Script Block>
} <Common Parameters>

Najbardziej popularnym zastosowaniem bloku InlineScript w elemencie Runbook jest uruchomienie bloku kodu na innym komputerze. Jest to wymagane, gdy polecenia cmdlet w elemencie Runbook nie są zainstalowane w programie Automatyzacja lub gdy uprawnienia akcji pozwalają na jej wykonanie tylko lokalnie na komputerze docelowym. Zostało to zilustrowane na poniższym diagramie.

InlineScript

Aby uruchomić blok kodu na innym komputerze, działanie PSComputer jest używane z parametrami PSCredential i InlineScript. W celu przekazania wartości do tych parametrów w elemencie Runbook jest zwykle używany zasób globalny, taki jak a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_Credentials lub a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_Connections. Przedstawiony niżej przykładowy kod uruchamia zestaw poleceń na komputerze reprezentowanym przez połączenie o nazwie MyConnection.

$con = Get-AutomationConnection -Name 'MyConnection'
$securepassword = ConvertTo-SecureString -AsPlainText -String $con.Password -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $con.Username, $securepassword
InlineScript
{
  <Commands>
} –PSComputer $con.ComputerName –PSCredential $cred

Chociaż działania InlineScript mogą okazać się niezbędne w niektórych elementach Runbook, z następujących powodów powinny być używane tylko w razie konieczności:

  • Nie można korzystać z punktów kontrolnych wewnątrz bloku InlineScript. Jeśli wewnątrz bloku wystąpi błąd, blok musi zostać wznowiony od początku.

  • Blok InlineScript wpływa na skalowalność elementu Runbook, ponieważ obsługuje sesję programu Windows PowerShell na całej długości tego bloku.

  • Takie działania, jak Get-AutomationVariable i Get-AutomationPSCredential nie są dostępne w bloku InlineScript.

Jeśli potrzebny jest blok InlineScript, należy zminimalizować jego zakres. Na przykład, jeśli element Runbook przechodzi przez kolekcję, stosując tę samą operację do każdego elementu, pętla powinna znajdować się poza blokiem InlineScript. Takie postępowanie przyniesie następujące korzyści:

  • Po każdej iteracji można zastosować punkt kontrolny przepływu pracy. Jeśli zadanie zostało wstrzymane lub przerwane, a potem wznowione, pętla będzie mogła zostać wznowiona.

  • Można użyć konstrukcji ForEach –Parallel do współbieżnej obsługi elementów kolekcji.

Jeśli używasz bloku InlineScript w elemencie Runbook, pamiętaj o poniższych zaleceniach:

  • Można jednak przekazać wartości do skryptu za pomocą modyfikatora zakresu $Using. Na przykład zmienna o nazwie $abc ustawiona poza blokiem InlineScript w bloku InlineScript staje się zmienną $using:abc.

  • Aby zwrócić dane wyjściowe z bloku InlineScript, przypisz je do zmiennej i zwróć wszelkie potrzebne dane wyjściowe do strumienia wyjściowego. W poniższym przykładzie przypisano ciąg „hi” do zmiennej o nazwie $output.

    $output = InlineScript { Write-Output "hi" }

  • Unikaj definiowania przepływów pracy w ramach bloku InlineScript. Mimo że niektóre przepływy pracy mogą działać poprawnie, nie jest to przetestowany scenariusz. W rezultacie mogą występować niezrozumiałe komunikaty o błędach lub nieoczekiwane zachowanie.

Aby uzyskać więcej szczegółowych informacji dotyczących używania bloku InlineScript, zobacz Uruchamianie poleceń programu Windows PowerShell w przepływie pracy i about_InlineScript.