Concepts du flux de travail Windows PowerShell

Un type de runbook pour Service Management Automation est basé sur les flux de travail Windows PowerShell. Cet article fournit une brève vue d’ensemble des fonctionnalités critiques des flux de travail communs aux runbooks Automation. Des informations complètes sur les flux de travail sont disponibles dans Présentation du workflow Windows PowerShell.

La structure du runbook est identique entre les runbooks pour Service Management Automation et Microsoft Azure Automation , bien que les deux fonctionnent généralement avec différentes ressources.

Flux de travail Windows PowerShell

Un workflow est une séquence d’étapes programmées et connectées qui effectuent des tâches de longue durée ou requièrent la coordination de plusieurs étapes sur plusieurs appareils ou nœuds gérés. Les avantages d'un workflow par rapport à un script normal incluent la possibilité d'exécuter simultanément une action sur plusieurs appareils et de récupérer automatiquement après une défaillance. Un workflow Windows PowerShell est un script Windows PowerShell qui utilise Windows Workflow Foundation. Pendant que le flux de travail est écrit avec la syntaxe Windows PowerShell et lancé par Windows PowerShell, il est traité par Windows Workflow Foundation.

Structure de base

Un workflow Windows PowerShell commence par le mot clé Workflow suivi du corps du script placé entre accolades. Le nom du workflow suit le mot clé Workflow , comme illustré dans la syntaxe suivante. Le nom du flux de travail correspond au nom du runbook Automation.

Workflow Test-Runbook
{
   <Commands>
}

Pour ajouter des paramètres au flux de travail, utilisez le mot clé Param , comme indiqué dans la syntaxe suivante. Le portail de gestion invite l'utilisateur à fournir des valeurs pour ces paramètres au démarrage du Runbook. Cet exemple utilise l’attribut Paramètre facultatif, qui spécifie si le paramètre est obligatoire ou non.

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

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

Dénomination

Le nom du flux de travail doit être conforme au format Verbe-Substantif qui correspond à la norme avec Windows PowerShell. Pour obtenir la liste des verbes approuvés à utiliser, vous pouvez vous reporter à Approved Verbs for Windows PowerShell Commands (Verbes approuvés pour les commandes Windows PowerShell) . Le nom du workflow doit correspondre au nom du Runbook Automation. Si le Runbook est importé, le nom de fichier doit correspondre au nom du workflow et se terminer par .ps1.

Limites

Pour obtenir la liste complète des limitations et des différences de syntaxe entre Windows PowerShell et les flux de travail Windows PowerShell, consultez la rubrique Différences syntaxiques entre les flux de travail de script et les scripts.

Activités

Une activité est une tâche spécifique dans un workflow. Tout comme un script se compose d’une ou plusieurs commandes, un workflow se compose d’une ou plusieurs activités effectuées en séquence. Le workflow Windows PowerShell convertit automatiquement la plupart des applets de commande Windows PowerShell en activités lors de son exécution. Lorsque vous spécifiez une de ces applets de commande dans votre Runbook, l'activité correspondante est de fait exécutée par Windows Workflow Foundation. Pour les applets de commande sans activité correspondante, le workflow Windows PowerShell exécute automatiquement l’applet de commande dans une activité InlineScript . Un ensemble d’applets de commande sont exclues et ne peuvent pas être utilisées dans un flux de travail, sauf si vous les incluez explicitement dans un bloc InlineScript . Pour plus d’informations sur ces concepts, consultez Utilisation d’activités dans les flux de travail de script.

Les activités de workflow partagent un ensemble de paramètres communs pour configurer leur opération. Pour plus d’informations sur les paramètres communs de flux de travail, consultez about_WorkflowCommonParameters.

Modules d’intégration

Un module d’intégration est un package qui contient un module Windows PowerShell et qui peut être importé dans Automation. Les modules Windows PowerShell contiennent des applets de commande qui peuvent être utilisées dans les runbooks Automation. Les produits et services tels qu'Operations Manager et Azure comprennent des modules qui incluent des applets de commande spécifiques à leur fonctionnement.

Les modules d’intégration importés dans Automation sont automatiquement disponibles pour tous les runbooks. Étant donné que Automation est basé sur Windows PowerShell 4.0, il prend en charge le chargement automatique des modules, ce qui signifie que les applets de commande des modules installés peuvent être utilisées sans les importer dans le script avec Import-Module.

Tout module Windows PowerShell peut être importé dans Automation tant que toutes ses dépendances peuvent se trouver dans un seul dossier. Si le module dépend des paramètres du Registre ou des fichiers qui ne se trouvent pas dans le chemin d’accès par défaut, il peut être importé, mais il ne fonctionnera probablement pas, car Automation ne pourra pas localiser ses dépendances. Vous pouvez utiliser dans un Runbook des modules ayant des dépendances externes en les installant sur un autre hôte à l'aide d'un bloc de script InlineScript , puis en y accédant avec ce même bloc de script.

Avec Service Management Automation, vous pouvez utiliser des modules avec des dépendances externes en les installant sur chaque serveur Worker. Bien que les applets de commande de ces modules puissent être utilisées dans des runbooks, elles ne seront pas découvertes par Automation pour prendre en charge des fonctionnalités telles que l’Assistant Insertion d’activité. Pour utiliser cette fonctionnalité, vous pouvez créer un module Portable à l'aide de l'applet de commande New-SmaPortableModule . Cette applet de commande crée un module qui inclut un stub pour chacune de ses applets de commande et peut être importé dans Automation. Lorsqu'un Runbook utilise l'une de ces applets de commande, le stub redirige l'appel vers l'applet de commande réelle dans le module externe. Ce module doit être installé sur chaque serveur Worker sans quoi l'appel échoue.

Exécution en parallèle

L'un des avantages des workflows Windows PowerShell est la possibilité d'exécuter un ensemble de commandes en parallèle, et non séquentiellement comme avec un script classique. Ceci s'avère particulièrement utile dans les Runbook dans la mesure où ils peuvent effectuer plusieurs actions qui prennent un temps considérable. Par exemple, un Runbook peut approvisionner un ensemble d'ordinateurs virtuels. Au lieu d’effectuer chaque processus d’approvisionnement en séquence avec l’autre, les actions peuvent être effectuées simultanément, ce qui augmente l’efficacité globale. C'est seulement une fois que toutes les actions sont terminées que le Runbook se poursuit.

Vous pouvez utiliser le mot clé Parallel pour créer un bloc de script avec plusieurs commandes qui s'exécutent simultanément. Le script utilise la syntaxe ci-dessous. Dans ce cas, Activity1 et Activity2 démarrent en même temps. Activity3 démarre uniquement quand Activity1 et Activity2 sont toutes deux terminées.

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

Vous pouvez utiliser la construction ForEach-Parallel pour traiter simultanément les commandes de chaque élément d'une collection. Les éléments de la collection sont traités en parallèle, tandis que les commandes du bloc de script sont exécutées séquentiellement. Le script utilise la syntaxe ci-dessous. Dans ce cas, Activity1 démarre en même temps pour tous les éléments de la collection. Pour chaque élément, Activity2 démarre une fois Activity1 terminée. Activity3 démarre uniquement une fois l’activité1 et l’activité2 terminées pour tous les éléments.

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

Le mot clé Sequence est utilisé pour exécuter des commandes dans une séquence dans un bloc de script parallèle . Le bloc de script séquence s’exécute en parallèle avec d’autres commandes, mais les commandes au sein du bloc s’exécutent de manière séquentielle. Le script utilise la syntaxe ci-dessous. Dans cet exemple, Activity1, Activity2 et Activity3 démarrent en même temps. Activity4 démarre uniquement une fois que l'exécution d'Activity3 est terminée. Activity5 démarre une fois toutes les autres activités terminées

Parallel
{
  <Activity1>
  <Activity2>

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

Points de contrôle

Un point de contrôle est un instantané de l'état actuel du workflow qui inclut la valeur actuelle des variables et toute sortie générée à ce stade. Le dernier point de contrôle à terminer dans un runbook est enregistré dans la base de données Automation afin que le flux de travail puisse reprendre même en cas de panne. Les données du point de contrôle sont supprimées une fois le travail du Runbook terminé.

Vous pouvez définir un point de contrôle dans un workflow avec l'activité Checkpoint-Workflow . Lorsque vous incluez cette activité dans un Runbook, un point de contrôle est immédiatement créé. Si le Runbook est interrompu par une erreur, lors de la reprise du travail, il reprend à partir du dernier point de contrôle défini.

Dans l’exemple de code suivant, une erreur se produit après Activity2, ce qui entraîne l’interruption du runbook. À la reprise du travail, il commence par exécuter Activity2 puisqu'elle se trouvait juste après le dernier point de contrôle défini.

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

Vous devez définir des points de contrôle dans un runbook après les activités susceptibles d’être sujettes à une erreur et ne doivent pas être répétés si le runbook est repris. Par exemple, votre Runbook peut créer un ordinateur virtuel. Vous pouvez définir un point de contrôle avant et après les commandes de création de la machine virtuelle. En cas d'échec de la création, les commandes sont répétées lors de la reprise du Runbook. Si la création réussit, mais que le runbook échoue ultérieurement, la machine virtuelle ne sera pas recréée lorsque le runbook est repris.

Pour plus d'informations sur les points de contrôle, consultez Ajout de points de contrôle à un workflow de script.

Suspendre un Runbook

Vous pouvez forcer l’interruption d’un runbook avec l’activité Suspend-Workflow . Cette activité entraîne la définition d'un point de contrôle et entraîne la suspension immédiate du flux de travail. La suspension d'un flux de travail s'avère utile pour les Runbook pouvant requérir une étape manuelle avant l'exécution d'un autre ensemble d'activités.

Pour plus d'informations sur la suspension d'un flux de travail, voir Making a Workflow Suspend Itself (Suspension volontaire d'un flux de travail).

InlineScript

L’activité InlineScript exécute un bloc de commandes dans une session distincte, non-workflow et retourne sa sortie au flux de travail. Alors que les commandes d'un workflow sont envoyées à Windows Workflow Foundation pour être traitées, les commandes d'un bloc InlineScript sont traitées par Windows PowerShell. L’activité utilise les paramètres courants de flux de travail standard, notamment PSComputerName et PSCredential, qui vous permettent de spécifier que le bloc de code doit être exécuté sur un autre ordinateur ou à l’aide d’autres informations d’identification.

InlineScript utilise la syntaxe ci-dessous.

InlineScript
{
  <Script Block>
} <Common Parameters>

L’utilisation la plus courante pour InlineScript dans un runbook consiste à exécuter un bloc de code sur un autre ordinateur. Cela est nécessaire lorsque les applets de commande de votre runbook ne sont pas installées dans Automation ou si l’action dispose uniquement des autorisations à effectuer localement sur l’ordinateur cible. Ce concept est illustré dans le diagramme suivant.

Pour exécuter le bloc de code sur un autre ordinateur, les paramètres PSComputer et PSCredential sont utilisés avec l’activité InlineScript . Une ressource globale telle que des Credential ou une Connection est généralement utilisée dans un Runbook pour fournir des valeurs à ces paramètres. L'exemple de code suivant exécute un ensemble de commandes sur un ordinateur représenté par une connexion appelée 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

Bien que les activités InlineScript soient critiques dans certains runbooks, elles ne doivent être utilisées que si nécessaire pour les raisons suivantes :

• Vous ne pouvez pas utiliser de points de contrôle à partir d’un bloc InlineScript . En cas de défaillance au sein du bloc, celui-ci doit reprendre depuis le début.

• InlineScript affecte l’extensibilité du runbook, car il contient la session Windows PowerShell pour toute la longueur du bloc InlineScript.

• Les activités telles que Get-AutomationVariable et Get-AutomationPSCredential ne sont pas disponibles dans un bloc InlineScript.

Si vous avez besoin d’utiliser un inlineScript, vous devez réduire son étendue. Par exemple, si votre runbook itère sur une collection lors de l’application de la même opération à chaque élément, la boucle doit se produire en dehors de l’inlineScript. Les avantages sont alors les suivants :

• Vous pouvez effectuer un point de contrôle sur le flux de travail après chaque itération. Si la tâche est suspendue ou interrompue et reprise, la boucle peut reprendre.

• Vous pouvez utiliser ForEach « Parallel pour gérer simultanément les éléments de collection.

Gardez à l’esprit les recommandations suivantes si vous utilisez un inlineScript dans votre runbook :

• Toutefois, vous pouvez passer des valeurs dans le script avec le modificateur d'étendue $Using . Par exemple, une variable appelée $abc qui a été définie en dehors de InlineScript devient $using :abc à l’intérieur d’un inlineScript.

• Pour renvoyer la sortie d’un inlineScript, affectez la sortie à une variable et affichez toutes les données à retourner au flux de sortie. L’exemple suivant affecte la chaîne hi à une variable appelée $output.

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

• Évitez de définir des flux de travail dans l’étendue InlineScript . Même si certains flux de travail semblent fonctionner correctement, ce n’est pas un scénario testé. Par conséquent, vous pouvez être confronté à des messages d'erreur déroutants ou un comportement inattendu.

Pour plus d’informations sur l’utilisation d’InlineScript, consultez Exécuter des commandes Windows PowerShell dans un flux de travail et about_InlineScript.

Étapes suivantes

• Créer des runbooks Automation.