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 información general breve de las características críticas de los flujos de trabajo que son comunes a los runbooks de Automation. Encontrarás 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 funcionarán normalmente 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 está escrito con sintaxis de Windows PowerShell y se inicia mediante Windows PowerShell, se procesa mediante Windows Workflow Foundation.
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 debe coincidir con el nombre del runbook de Automation.
Workflow Test-Runbook
{
<Commands>
}
Para agregar parámetros al flujo de trabajo, usa 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 cumplir el formato Verbo-Sustantivo que es estándar con Windows PowerShell. Puedes 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, consulta 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. Para los cmdlets sin 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 están excluidos y no se pueden usar en un flujo de trabajo a menos que se incluyan explícitamente en un bloque InlineScript. Para más información sobre estos conceptos, consulta 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 para usarlos y, después, acceder a ellos con un bloque de script InlineScript.
Con Service Management Automation, puedes 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, puedes 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 procesamiento en segundo plano 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 aumentaría la eficacia general. Solo cuando se completen todos los procesos, continuaría el runbook.
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á únicamente 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 en secuencia dentro de un bloque de script Parallel. El bloque de script Sequence se ejecuta en paralelo con otros comandos, pero los comandos que están dentro 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á después de que se haya completado Activity3. 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 incluyes 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 control.
En el código de ejemplo siguiente, se produce un error después de Activity2 que provoca la suspensión del runbook. Cuando se reanuda el trabajo, se inicia ejecutando Activity2, ya que estaba justo después del último punto de control establecido.
<Activity1>
Checkpoint-Workflow
<Activity2>
<Error>
<Activity3>
Debes establecer los puntos de control en un runbook después de las actividades que puedan ser propensas a errores y que no deben repetirse si se reanuda el runbook. Por ejemplo, tu 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 el runbook produce un error después de que se haya realizado la creación correctamente, 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.
Suspensión de un runbook
Puedes forzar la suspensión de un runbook 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 más información sobre cómo suspender un flujo de trabajo, consulta Hacer que un flujo de trabajo se suspenda.
InlineScript
La actividad InlineScript ejecuta un bloque de comandos en una sesión independiente que no es de flujo de trabajo y devuelve su resultado 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 te 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 ilustra 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 InlineScript pueden ser críticas en ciertos runbooks, solo se deben usar cuando sea necesario por las razones siguientes:
No puedes usar puntos de control desde dentro de un bloque InlineScript. Si se produce un error dentro del bloque, este debe reanudarse desde el principio.
InlineScript afecta a la escalabilidad del flujo de trabajo, ya que retiene la sesión de Windows PowerShell toda la duración del bloque de InlineScript.
Las actividades como Get-AutomationVariable y Get-AutomationPSCredential no están disponibles en un bloque InlineScript.
Si necesitas usar una actividad InlineScript, debes minimizar su ámbito. Por ejemplo, si tu runbook recorre en iteración una colección al aplicar la misma operación a cada elemento, el bucle debe producirse fuera de la actividad InlineScript. Esto proporciona las siguientes ventajas:
Puedes controlar el flujo de trabajo después de cada iteración. Si el trabajo se suspende o interrumpe para luego reanudarse, el bucle podrá reanudarse.
Puedes usar ForEach "Parallel para controlar los elementos de colección simultáneamente.
Ten en cuenta las siguientes recomendaciones si usas una actividad InlineScript en tu runbook:
No obstante, puedes pasar valores al script con el modificador de ámbito $Using. Por ejemplo, una variable denominada $abc que se ha establecido fuera de la actividad InlineScript se convertirá en $using:abc dentro de una actividad InlineScript.
Para devolver la salida desde una actividad InlineScript, asigna la salida a una variable y extrae cualquier dato que se vaya 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" }Evita 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 encuentres mensajes de error confusos o un comportamiento inesperado.
Para más información sobre el uso de InlineScript, consulta Ejecutar comandos de Windows PowerShell en un flujo de trabajo y about_InlineScript.