Conceptos de Runbook

Un flujo de trabajo es una secuencia de pasos programados y conectados que realizan tareas de larga duración o que requieren la coordinación de varios pasos en varios dispositivos o nodos administrados. Las ventajas que ofrece un flujo de trabajo con respecto a un script normal son la capacidad de realizar una acción simultáneamente en varios dispositivos y la capacidad de recuperarse automáticamente de los errores. Un flujo de trabajo de Windows PowerShell es un script de Windows PowerShell que aprovecha Windows Workflow Foundation. Aunque el flujo de trabajo está escrito con la sintaxis de Windows PowerShell y se inicia mediante Windows PowerShell, se procesa mediante Windows Workflow Foundation.

Una actividad es una tarea específica en 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 realizan 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 especifica uno de estos cmdlets en el Runbook, en realidad la actividad correspondiente se ejecuta mediante Windows Workflow Foundation. En los cmdlets sin una actividad correspondiente, el flujo de trabajo de Windows PowerShell los ejecuta automáticamente en una actividad de InlineScript. Hay un conjunto de cmdlets excluidos que no se pueden usar en un flujo de trabajo a menos que los incluya explícitamente en un bloque de InlineScript. Para obtener más detalles sobre estos conceptos, vea Using Activities in Script Workflows (Uso de actividades en flujos de trabajo de scripts).

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

Un módulo de integración es un paquete que contiene un módulo de Windows PowerShell y se puede importar en Automatización. Los módulos de Windows PowerShell contienen cmdlets que se pueden usar en runbooks de Automatización. Algunos productos y servicios, como Operations Manager y Azure, cuentan con módulos que incluyen cmdlets específicos para su funcionamiento.

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

Cualquier módulo de Windows PowerShell se puede importar en Automatización siempre que todas sus dependencias puedan encontrarse en una única carpeta. Si el módulo depende de la configuración del Registro o de archivos que no se encuentran en la ruta de acceso predeterminada, podrá importarse, pero lo más probable es que no funcione porque Automatización no podrá encontrar sus dependencias. Los módulos con dependencias externas se pueden utilizar en un runbook instalándolos en otro host y accediendo a ellos con un bloque de scripts de a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_InlineScript.

Con Automatización de administración de servicios, puede usar módulos con dependencias externas instalándolos en cada servidor Worker. Aunque los cmdlets de estos módulos pueden usarse en Runbooks, Automatización no los detectará para que admitan características como el asistente para insertar actividades. Para poder usar esta característica, puede crear un módulo portátil 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 a Automatización. Cuando un Runbook usa uno de estos cmdlets, el código auxiliar redirige la llamada al propio cmdlet en el módulo externo. Ese módulo debe estar instalado en cada servidor Worker o se producirá un error en la llamada.

Una ventaja que presentan los flujos de trabajo de Windows PowerShell es la capacidad de ejecutar un conjunto de comandos en paralelo en lugar de hacerlo secuencialmente como con un script típico. Esto resulta particularmente útil en los Runbooks, ya que es posible que ejecuten varias acciones que tardan mucho tiempo en completarse. Por ejemplo, supongamos que usa un Runbook para aprovisionar un conjunto de máquinas virtuales. En lugar de realizar cada proceso de aprovisionamiento de manera secuencial, las acciones se pueden realizar simultáneamente, lo que mejora la eficiencia general. El Runbook continuará únicamente cuando todas las acciones se hayan completado.

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

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

Puede usar el constructo ForEach -Parallel para procesar simultáneamente comandos para cada elemento de una colección. Los elementos de la colección se procesan en paralelo, mientras que los comandos del bloque de script se ejecutan secuencialmente. Para ello se 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 que se haya completado Activity1. Solo se iniciará Activity3 después de que se hayan completado Activity1 y Activity2 para todos los elementos.

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

La palabra clave Sequence se usa para ejecutar comandos de manera secuencial dentro de un bloque de script Parallel. El bloque de script Sequence se ejecuta en paralelo con otros comandos, pero los comandos dentro del bloque se ejecutan secuencialmente. Para ello se usa la sintaxis que se muestra a continuación. En este caso, Activity1, Activity2 y Activity3 se iniciarán al mismo tiempo. Activity4 solo se iniciará 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>

Un punto de control es una instantánea del estado actual del flujo de trabajo que incluye el valor actual de las variables y todos los resultados generados para ese punto. El último punto de comprobación que se debe llevar a cabo en un runbook es guardarlo en la base de datos de Automatización para que el flujo de trabajo puede reanudarse incluso en caso de una interrupción del servicio. Los datos del punto de control se eliminan una vez finalizado el trabajo del Runbook.

Puede establecer un punto de control en un flujo de trabajo con la actividad Checkpoint-Workflow. Al incluir esta actividad en un Runbook, inmediatamente se toma un punto de control. Si el Runbook se suspende debido a un error, cuando se reanude el trabajo, se reanudará desde el punto del último punto de control establecido.

En el ejemplo de código siguiente, se produce un error después de Activity2 que provoca que se suspenda el Runbook. Cuando se reanuda el trabajo, se inicia ejecutando Activity2, ya que se encontraba justo detrás del último punto de control establecido.

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

Se recomienda establecer los puntos de control en un Runbook justo después de actividades que puedan ser propensas a error y que no deban repetirse si se reanuda el Runbook. Por ejemplo, supongamos que usa un Runbook para crear una máquina virtual. Podría establecer un punto de control antes y después de los comandos que crean 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 más adelante se produce un error en el Runbook, entonces la máquina virtual no se creará de nuevo cuando se reanude el Runbook.

Para obtener más información sobre los puntos de control, vea Adding Checkpoints to a Script Workflow (Agregar puntos de control a un flujo de trabajo de script).

Puede forzar que un Runbook se suspenda a sí mismo con la actividad Suspend-Workflow. Esta actividad establecerá un punto de control y hará que el flujo de trabajo se suspenda inmediatamente. Suspender el flujo de trabajo resulta útil para los runbooks que pueden requerir realizar un paso manualmente antes de ejecutar otro conjunto de actividades.

Para obtener más información sobre la suspensión de un flujo de trabajo, vea Making a Workflow Suspend Itself (Hacer que un flujo de trabajo se suspenda a sí mismo).

La actividad InlineScript ejecuta un bloque de comandos en una sesión independiente y sin flujo de trabajo, y devuelve los resultados 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, incluidos PSComputerName y PSCredential, que le permiten especificar que el bloque de código se ejecute en otro equipo o usando otras credenciales.

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 el de ejecutar un bloque de código en otro equipo. Este proceso es necesario cuando los cmdlets del runbook no están instalados en Automatización o si la acción solo tiene permisos para llevarse a cabo localmente en el equipo de destino. Esto se ilustra en el diagrama siguiente.

Para ejecutar el bloque de código en otro equipo, se usan los parámetros PSComputer y PSCredential con la actividad InlineScript. Se suele usar un recurso global, como una a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_Credentials o una a8b7e82f-e3fc-4286-8570-8d5ded944b27#bkmk_Connections en el runbook para proporcionar valores para estos parámetros. El siguiente código de ejemplo 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 es posible que las actividades de InlineScript resulten críticas en algunos Runbooks, solo deberían usarse cuando sea necesario por los siguientes motivos:

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

• InlineScript afecta a la escalabilidad del runbook, ya que retiene la sesión de Windows PowerShell para el bloque InlineScript en su totalidad.

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

Si necesita usar un InlineScript, debe minimizar su alcance. Por ejemplo, si el Runbook itera en una colección mientras aplica la misma operación a cada elemento, el bucle debería producirse fuera de InlineScript. Esto ofrecerá las siguientes ventajas:

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

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

Tenga en cuenta las siguientes recomendaciones si usa un InlineScript en su runbook:

• No obstante, puede pasar valores al script mediante el modificador de ámbito $Using. Por ejemplo, una variable denominada $abc que se ha establecido fuera del InlineScript, pasaría a ser $using:abc dentro de un InlineScript.

• Para devolver una salida de un InlineScript, asigne la salida a una variable y genere datos para que vuelvan al flujo de salida. En el siguiente ejemplo se asigna la cadena "hola" a una variable denominada $output.

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

• Evite definir flujos de trabajo en el ámbito del InlineScript. Aunque puede parecer que algunos flujos de trabajo funcionan, no se ha probado. Como resultado, puede que encuentre mensajes de error confusos o un funcionamiento inesperado.

Para obtener información más detallada sobre cómo usar InlineScript, consulte Ejecutar comandos de Windows PowerShell en un flujo de trabajo y about_InlineScript.