Runbooks secundarios en Service Management Automation
Un procedimiento recomendado en Service Management Automation (SMA) es escribir runbooks que sean reutilizables y modulares con una función discreta que puedan usar otros runbooks. Con frecuencia, un runbook primario llamará a uno o varios runbooks secundarios para realizar la funcionalidad necesaria. Existen dos maneras de llamar a un runbook secundario y cada una tiene varias diferencias que deberías conocer para poder determinar cuál de ellas es mejor para los diferentes escenarios.
Invocación de un runbook secundario mediante la ejecución insertada
Para invocar un runbook en línea desde otro runbook, use el nombre del runbook y proporcione valores para sus parámetros, exactamente igual a como usaría una actividad o un cmdlet. Todos los runbooks del mismo entorno de SMA están disponibles para que todos los demás los usen de esta manera. El runbook principal esperará a que el runbook secundario se complete antes de pasar a la siguiente línea, y cualquier resultado se devolverá directamente al elemento primario.
Al invocar un runbook en línea, este se ejecuta en el mismo trabajo que el runbook primario. No habrá ninguna indicación en el historial de trabajos del runbook secundario que se haya ejecutado. Cualquier excepción y salida de flujo pertenecientes al runbook secundario, se asociarán al primario. Como resultado, hay menos trabajos y se facilita el seguimiento y la solución de problemas, ya que las excepciones producidas por el runbook secundario y las salidas de flujo se asocian al trabajo del runbook primario.
Cuando se publica un runbook, cualquier runbook secundario al que llame deberá tener ya una versión publicada. Esto es así porque Automation crea una asociación con los runbooks secundarios cuando se compila un runbook. Si no, parecerá que el runbook primario se publica correctamente, pero generará una excepción cuando se inicie. Si esto sucediera, puede volver a publicar el runbook primario para que haga referencia correctamente a los runbooks secundarios. No es necesario que vuelvas a publicar el runbook primario si cambia alguno de los runbooks secundarios, porque ya se habrá creado la asociación.
Los parámetros de un runbook secundario al que se llama insertado pueden ser de cualquier tipo de datos (incluidos objetos complejos), y no hay ninguna serialización JSON como sucede cuando se inicia el runbook mediante el Portal de administración o mediante el cmdlet Start-SmaRunbook.
Tipos de runbook
Un runbook solo puede usar otro runbook del mismo tipo que un runbook secundario mediante ejecución insertada. Esto significa que un runbook de flujo de trabajo de PowerShell no puede usar un runbook de PowerShell como elemento secundario mediante ejecución insertada, y un runbook de PowerShell no puede usar un runbook de flujo de trabajo de PowerShell.
Cuando se llama a un runbook secundario de flujo de trabajo de PowerShell con la ejecución insertada, solo tienes que usar el nombre del runbook. Cuando se llama a un runbook secundario de PowerShell, se debe anteponer .\ a su nombre para especificar que el script se encuentra en el directorio local.
Ejemplo
En el ejemplo siguiente se invoca un runbook secundario de prueba que acepta tres parámetros: un objeto complejo, un entero y un valor booleano. Los resultados del runbook secundario se asignan a una variable. En este caso, el runbook secundario es un runbook de flujo de trabajo de PowerShell.
$vm = Get-VM -Name "MyVM" -ComputerName "MyServer"
$output = Test-ChildRunbook -VM $vm -RepeatCount 2 -Restart $true
A continuación, se muestra el mismo ejemplo con un runbook de script de PowerShell como elemento secundario.
$vm = Get-VM -Name "MyVM" -ComputerName "MyServer"
$output = .\Test-ChildRunbook.ps1 -VM $vm -RepeatCount 2 -Restart $true
Inicio de un runbook secundario mediante cmdlet
Puedes utilizar el cmdlet Start-SMARunbook para iniciar un runbook con Windows PowerShell. Al iniciar un runbook secundario desde un cmdlet, el runbook primario pasará a la siguiente línea en cuanto se cree el trabajo para el runbook secundario. Si necesitas recuperar cualquier salida del runbook, debes tener acceso al trabajo mediante Get-SMAJobOutput.
Si inició el trabajo de un runbook secundario con un cmdlet, este se ejecutará en un trabajo independiente al runbook primario. Esto da como resultado más trabajos que invocar el flujo de trabajo insertado, lo que aumenta la sobrecarga en el servidor de trabajo y hace que sea más difícil realizar su seguimiento. Sin embargo, el elemento primario puede iniciar varios runbooks secundarios sin esperar a que se complete cada uno. Para realizar este mismo tipo de ejecución en paralelo, al llamar a los runbooks secundarios en línea, el runbook primario necesitará usar la palabra clave parallel.
Los parámetros de un runbook secundario iniciado con un cmdlet se proporcionan como una tabla hash, tal y como se describe en Parámetros de runbook. Solo se pueden usar tipos de datos simples, aunque puedes proporcionar el nombre de un recurso de credencial, tal como se describe en Credenciales. Si el runbook tiene un parámetro con un tipo de datos complejo, debe llamarse en línea.
En el ejemplo siguiente se inicia un runbook secundario con parámetros y se espera a que finalice. Una vez completado, el runbook primario recopila la salida.
$webServer = 'https://MyServer'
$port = 9090
$runbookName = "Test-Runbook"
$params = @{"VMName"="MyVM";"RepeatCount"=2;"Restart"=$true}
$job = Start-SmaRunbook -WebServiceEndpoint $webServer -Port $port -Name $runbookName -Parameters $params
$doLoop = $true
While ($doLoop) {
$job = Get-SmaJob -WebServiceEndpoint $webServer -Port $port -Id $job.Id
$status = $job.Status
$doLoop = (($status -ne "Completed") -and ($status -ne "Failed") -and ($status -ne "Suspended") -and ($status -ne "Stopped")
}
Get-SmaJobOutput -WebServiceEndpoint $webServer -Port $port -Id $job.Id -Stream Output
Comparación de métodos para llamar a un runbook secundario
En la siguiente tabla se resumen las diferencias entre los dos métodos para llamar a un runbook desde otro runbook.
Insertado | Cmdlet | |
---|---|---|
Trabajo | Los runbooks secundarios se ejecutan en el mismo trabajo que el primario. | Se crea un trabajo independiente para el runbook secundario. |
Ejecución | El runbook primario espera a que el runbook secundario se complete antes de continuar. | El runbook primario continúa inmediatamente después de iniciar el runbook secundario. |
Salida | El runbook primario puede obtener los resultados directamente del runbook secundario. | El runbook primario debe recuperar la salida del trabajo del runbook secundario. |
Parámetros | Los valores de los parámetros del runbook secundario se especifican por separado y pueden usar cualquier tipo de datos. | Los valores de los parámetros del runbook secundario deben combinarse en una sola tabla hash y solo pueden incluir tipos de datos simples, de matriz y de objeto que utilicen la serialización JSON. |
Publicación | El runbook secundario debe publicarse antes de publicar el runbook primario. | El runbook secundario debe publicarse en cualquier momento antes de iniciar el runbook primario. |
Pasos siguientes
- Obtén información sobre la automatización de runbooks.