Conceptos de flujo de trabajo de Windows PowerShell

Un tipo de runbook para Service Management Automation se basa en flujos de trabajo de Windows PowerShell. En este artículo se proporciona una breve introducción a las características críticas de los flujos de trabajo que son comunes a los runbooks de Automation. Encontrará detalles completos sobre los flujos de trabajo en Introducción al flujo de trabajo de Windows PowerShell.

La estructura del runbook es idéntica entre runbooks para Service Management Automation y para Microsoft Azure Automation , aunque los dos normalmente funcionarán con recursos diferentes.

Flujos de trabajo de Windows PowerShell

Un flujo de trabajo es una secuencia de pasos conectados y programados que realizan tareas de larga duración o requieren de la coordinación de pasos múltiples a través de varios dispositivos o nodos administrados. Las ventajas de un flujo de trabajo en un script normal incluyen la capacidad de realizar una acción en varios dispositivos simultáneamente y la capacidad de recuperarse automáticamente de los errores. Un flujo de trabajo de Windows PowerShell es un script de Windows PowerShell que usa Windows Workflow Foundation. Aunque el flujo de trabajo se escribe con la sintaxis de Windows PowerShell y se inicia mediante Windows PowerShell, Windows Workflow Foundation lo procesa.

Estructura básica

Un flujo de trabajo de Windows PowerShell comienza con la palabra clave Workflow seguida del cuerpo del script entre llaves. El nombre del flujo de trabajo sigue a la palabra clave Workflow , tal como se muestra en la sintaxis siguiente. El nombre del flujo de trabajo coincide con el nombre del runbook de Automation.

Workflow Test-Runbook
{
   <Commands>
}

Para agregar parámetros al flujo de trabajo, use la palabra clave Param como se muestra en la sintaxis siguiente. El Portal de administración pedirá al usuario que proporcione valores para estos parámetros cuando inicie el runbook. En este ejemplo se usa el atributo Parameter opcional, que especifica si el parámetro es obligatorio o no.

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

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

Nomenclatura

El nombre del flujo de trabajo debe ajustarse al formato Verb-Noun que es estándar con Windows PowerShell. Puede consultar Verbos aprobados para comandos de Windows PowerShell para obtener una lista de verbos aprobados que se van a usar. El nombre del flujo de trabajo debe coincidir con el nombre del runbook de Automation. Si se va a importar el runbook, el nombre de archivo debe coincidir con el nombre del flujo de trabajo y debe terminar en .ps1.

Limitaciones

Para obtener una lista completa de las limitaciones y las diferencias de sintaxis entre los flujos de trabajo de Windows PowerShell y Windows PowerShell, consulte Diferencias sintácticas entre flujos de trabajo de script y scripts.

Actividades

Una actividad es una tarea específica de un flujo de trabajo. Del mismo modo que un script se compone de uno o varios comandos, un flujo de trabajo se compone de una o varias actividades que se llevan a cabo en una secuencia. El flujo de trabajo de Windows PowerShell convierte automáticamente muchos de los cmdlets de Windows PowerShell en actividades cuando se ejecuta un flujo de trabajo. Cuando se especifica uno de estos cmdlets en el runbook, Windows Workflow Foundation ejecuta realmente la actividad correspondiente. En el caso de los cmdlets sin una actividad correspondiente, el flujo de trabajo de Windows PowerShell ejecuta automáticamente el cmdlet dentro de una actividad inlineScript . Hay un conjunto de cmdlets que se excluyen y no se pueden usar en un flujo de trabajo a menos que los incluya explícitamente en un bloque InlineScript . Para obtener más información sobre estos conceptos, consulte Uso de actividades en flujos de trabajo de script.

Las actividades de flujo de trabajo comparten un conjunto de parámetros comunes para configurar su funcionamiento. Para más información sobre los parámetros comunes del flujo de trabajo, vea about_WorkflowCommonParameters.

Módulos de integración

Un módulo de integración es un paquete que contiene un módulo de Windows PowerShell y se puede importar a Automation. Los módulos de Windows PowerShell contienen cmdlets que se pueden usar en runbooks de Automation. Los productos y servicios, como Operations Manager y Azure, tienen módulos que incluyen cmdlets específicos de su operación.

Los módulos de integración que se importan en Automation están disponibles automáticamente para todos los runbooks. Dado que Automation se basa en Windows PowerShell 4.0, admite la carga automática de módulos, lo que significa que los cmdlets de los módulos instalados se pueden usar sin importarlos en el script con Import-Module.

Cualquier módulo de Windows PowerShell se puede importar en Automation siempre que todas sus dependencias se puedan ubicar en una sola carpeta. Si el módulo depende de la configuración del Registro o de los archivos que no están en la ruta de acceso predeterminada, se puede importar, pero probablemente no funcionará porque Automation no podrá localizar sus dependencias. Los módulos con dependencias externas se pueden usar en un runbook instalándolos en otro host mediante y, a continuación, accediéndolos con un bloque de script InlineScript .

Con Service Management Automation, puede usar módulos con dependencias externas mediante su instalación en cada servidor de trabajo. Aunque los cmdlets de estos módulos se pueden usar en runbooks, Automation no los detectará para admitir características como el Asistente para insertar actividad. Para usar esta característica, puede crear un módulo portable mediante el cmdlet New-SmaPortableModule . Este cmdlet crea un módulo que incluye un código auxiliar para cada uno de sus cmdlets y se puede importar en Automation. Cuando un runbook usa uno de esos cmdlets, el código auxiliar redirige la llamada al cmdlet real del módulo externo. Ese módulo debe instalarse en cada servidor de trabajo o se producirá un error en la llamada.

Ejecución paralela

Una ventaja de los flujos de trabajo de Windows PowerShell es la capacidad para realizar un conjunto de comandos en paralelo en lugar de hacerlo secuencialmente como con un script típico. Esto es especialmente útil en los runbooks, ya que pueden realizar varias acciones que tardan mucho tiempo en completarse. Por ejemplo, un runbook podría aprovisionar un conjunto de máquinas virtuales. En lugar de realizar cada proceso de aprovisionamiento en secuencia entre sí, las acciones se podrían realizar simultáneamente, lo que aumenta la eficacia general. Solo cuando se completen todos los runbook continuaría.

Puede utilizar la palabra clave Parallel para crear un bloque de scripts con varios comandos que se ejecutarán simultáneamente. Usa la sintaxis que se muestra a continuación. En este caso, Activity1 y Activity2 se iniciarán al mismo tiempo. Activity3 se iniciará después de que se hayan completado Activity1 y Activity2.

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

Puede utilizar la construcción ForEach-Parallel para procesar comandos para cada elemento de una colección simultáneamente. Los elementos de la colección se procesan en paralelo mientras que los comandos del bloque de scripts se ejecutan secuencialmente. Usa la sintaxis que se muestra a continuación. En este caso, Activity1 se iniciará al mismo tiempo para todos los elementos de la colección. Para cada elemento, Activity2 se iniciará una vez completada Activity1. Activity3 se iniciará solo después de que activity1 y Activity2 se hayan completado para todos los elementos.

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

La palabra clave Sequence se usa para ejecutar comandos en secuencia dentro de un bloque de script paralelo . El bloque Secuencia de script se ejecuta en paralelo con otros comandos, pero los comandos del bloque se ejecutan secuencialmente. Usa la sintaxis que se muestra a continuación. En este caso, Activity1, Activity2 y Activity3 se iniciarán al mismo tiempo. Activity4 se iniciará solo después de que Activity3 se haya completado. Activity5 se iniciará después de que se hayan completado todas las demás actividades

Parallel
{
  <Activity1>
  <Activity2>

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

Puntos de control

Un punto de control es una instantánea del estado actual del flujo de trabajo que incluye el valor actual de las variables y cualquier salida generada en ese punto. El último punto de control que se va a completar en un runbook se guarda en la base de datos de Automation para que el flujo de trabajo pueda reanudarse incluso en caso de interrupción. Los datos del punto de control se quitan una vez completado el trabajo del runbook.

Puede establecer un punto de control en un flujo de trabajo con la actividad Checkpoint-Workflow . Cuando se incluye esta actividad en un runbook, se toma inmediatamente un punto de control. Si el runbook se suspende por un error, cuando se reanuda el trabajo, se reanudará desde el punto del último conjunto de puntos de comprobación.

En el código de ejemplo siguiente, se produce un error después de Activity2, lo que hace que el runbook se suspenda. Cuando se reanuda el trabajo, se inicia ejecutando Activity2, ya que esto era justo después del último conjunto de puntos de comprobación.

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

Debe establecer puntos de control en un runbook después de las actividades que pueden ser propensas a errores y no debe repetirse si se reanuda el runbook. Por ejemplo, el runbook puede crear una máquina virtual. Puede establecer un punto de control antes y después de los comandos para crear la máquina virtual. Si se produce un error en la creación, los comandos se repiten cuando se reanuda el runbook. Si la creación se realiza correctamente, pero se produce un error en el runbook más adelante, la máquina virtual no se volverá a crear cuando se reanude el runbook.

Para obtener más información acerca de los puntos de control, consulte Adición de puntos de control a un flujo de trabajo de scripts.

Suspender un runbook

Puede forzar que un runbook se suspenda automáticamente con la actividad Suspend-Workflow . Esta actividad establecerá un punto de control y hará que el flujo de trabajo se suspenda inmediatamente. Suspender un flujo de trabajo es útil para runbooks que pueden requerir que se realice un paso manual antes de ejecutar otro conjunto de actividades.

Para obtener más información sobre cómo suspender un flujo de trabajo, consulte Hacer que un flujo de trabajo se suspenda por sí mismo.

InlineScript

La actividad InlineScript ejecuta un bloque de comandos en una sesión independiente que no es de flujo de trabajo y devuelve su salida al flujo de trabajo. Mientras que los comandos de un flujo de trabajo se envían a Windows Workflow Foundation para su procesamiento, los comandos de un bloque de InlineScript se procesan mediante Windows PowerShell. La actividad usa los parámetros comunes de flujo de trabajo estándar, como PSComputerName y PSCredential, que permiten especificar que el bloque de código se ejecute en otro equipo o que use credenciales alternativas.

InlineScript usa la sintaxis que se muestra a continuación.

InlineScript
{
  <Script Block>
} <Common Parameters>

El uso más común de InlineScript en un runbook es ejecutar un bloque de código en otro equipo. Esto es necesario cuando los cmdlets del runbook no están instalados en Automation o si la acción solo tiene permisos para realizarse localmente en el equipo de destino. Esto se muestra en el diagrama siguiente.

Para ejecutar el bloque de código en otro equipo, los parámetros PSComputer y PSCredential se usan con la actividad InlineScript . Un recurso global, como una credencial o una conexión , se usa normalmente en un runbook para proporcionar valores para estos parámetros. El código de ejemplo siguiente ejecuta un conjunto de comandos en un equipo representado por una conexión denominada 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

Aunque las actividades de InlineScript pueden ser críticas en determinados runbooks, solo deben usarse cuando sea necesario por los siguientes motivos:

• No puede usar puntos de control desde un bloque InlineScript . Si se produce un error dentro del bloque, se debe reanudar desde el principio.

• InlineScript afecta a la escalabilidad del runbook, ya que contiene la sesión de Windows PowerShell durante toda la longitud del bloque InlineScript.

• Las actividades como Get-AutomationVariable y Get-AutomationPSCredential no están disponibles en un bloque InlineScript.

Si necesita usar inlineScript, debe minimizar su ámbito. Por ejemplo, si el runbook recorre en iteración una colección al aplicar la misma operación a cada elemento, el bucle debe producirse fuera de InlineScript. Esto proporcionará las siguientes ventajas:

• Puede controlar el flujo de trabajo después de cada iteración. Si el trabajo se suspende o interrumpe y reanuda, el bucle podrá reanudarse.

• Puede usar ForEach "Parallel para controlar los elementos de colección simultáneamente.

Tenga en cuenta las siguientes recomendaciones si usa inlineScript en el runbook:

• Aunque puede pasar valores al script con el modificador de ámbito $Using . Por ejemplo, una variable denominada $abc que se ha establecido fuera de InlineScript se convertirá en $using:abc dentro de un InlineScript.

• Para devolver la salida de inlineScript, asigne la salida a una variable y devuelva los datos que se van a devolver al flujo de salida. En el ejemplo siguiente se asigna la cadena hi a una variable denominada $output.

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

• Evite definir flujos de trabajo en el ámbito de InlineScript . Aunque algunos flujos de trabajo pueden parecer funcionar correctamente, esto no es un escenario probado. Como resultado, es posible que encuentre mensajes de error confusos o un comportamiento inesperado.

Para obtener más información sobre el uso de InlineScript, vea Ejecutar comandos de Windows PowerShell en un flujo de trabajo y about_InlineScript.

Pasos siguientes

• Creación de runbooks de automatización.