Tipos de runbooks de Azure Automation

La característica de automatización de procesos de Azure Automation admite varios tipos de runbooks, tal como se define en la tabla siguiente.

Tipo	Descripción
PowerShell (Recomendaciones)	Runbook de texto basado en scripting de Windows PowerShell. Las versiones actualmente soportadas son PowerShell 7.6, PowerShell 7.4 y PowerShell 5.1. Dado que PowerShell 7.1 y PowerShell 7.2 ya no son compatibles con el producto principal PowerShell, crea libros de ejecución con versiones soportadas a largo plazo como PowerShell 7.6 o PowerShell 7.4.
Flujo de trabajo de PowerShell	Runbook de texto basado en scripting de flujo de trabajo de Windows PowerShell.
Pitón (Recomendaciones)	Runbook de texto basado en scripting de Python. La versión admitida actualmente es Python 3.10. Dado que Python 2.7 y Python 3.8 ya no son compatibles con el producto primario Python, se recomienda crear runbooks en Python 3.10.
Gráfico	Runbook gráfico basado en Windows PowerShell, y creado y editado completamente en el editor gráfico de Azure Portal.
Flujo de trabajo gráfico de PowerShell	Runbook gráfico basado en flujo de trabajo de Windows PowerShell, y creado y editado completamente en el editor gráfico de Azure Portal.

Para más información sobre el entorno de automatización de procesos, consulte Ejecución de un runbook en Azure Automation.

Nota:

Azure Automation seguirá el ciclo de vida de soporte técnico de las versiones del lenguaje PowerShell y Python de acuerdo con las escalas de tiempo publicadas por los productos primarios, PowerShell y Python, respectivamente. Se recomienda usar runbooks con versiones de lenguaje compatibles.

Tenga en cuenta las siguientes consideraciones al determinar qué tipo usar para un runbook concreto:

No es posible convertir runbooks de tipo gráfico a texto o viceversa.
Existen limitaciones al utilizar runbooks de diferentes tipos como runbooks secundarios. Para más información, consulte Child runbooks in Azure Automation (Runbooks secundarios en Azure Automation).

Runbooks de PowerShell

Los runbooks de PowerShell están basados en Windows PowerShell. Puede modificar directamente el código del runbook con el editor de texto en el Portal de Azure. También puede usar cualquier editor de texto sin conexión e importar el runbook en Azure Automation.

La versión de PowerShell viene determinada por la versión en tiempo de ejecución especificada.

El mismo espacio aislado de Azure y Hybrid Runbook Worker pueden ejecutar varios runbooks de PowerShell destinados a diferentes versiones en tiempo de ejecución en paralelo. Las versiones de ejecución de PowerShell 7.6 y PowerShell 7.4 son compatibles tanto para trabajos en la nube como para trabajos híbridos en todas las regiones.

Nota:

En el momento de la ejecución del runbook, si selecciona Versión de tiempo de ejecución como 7.4, se utilizan módulos de PowerShell dirigidos a la versión 7.4, y si selecciona Versión de tiempo de ejecución como 5.1, se utilizan módulos de PowerShell dirigidos a la versión 5.1.

Asegúrese de seleccionar la versión del entorno de ejecución adecuada para los módulos.

Por ejemplo: Si está ejecutando un runbook para un escenario de automatización de SharePoint en la versión del entorno de ejecución7.4, importe el módulo en la versión del entorno de ejecución7.4; si está ejecutando un runbook para un escenario de automatización de SharePoint en la versión del entorno de ejecución5.1, importe el módulo en la versión del entorno de ejecución5.1.

Ventajas

Implemente toda la lógica compleja con código de PowerShell sin otras complejidades del flujo de trabajo de PowerShell.
Se inician con más rapidez que los runbooks de flujo de trabajo de PowerShell, ya que no necesitan compilarse antes de la ejecución.
Ejecute en Azure y en Hybrid Runbook Worker para Windows y Linux.

Limitaciones y problemas conocidos

A continuación se describen los problemas conocidos y las limitaciones actuales con los runbooks de PowerShell:

Limitaciones PowerShell 7.6 está disponible en experiencia de entorno de ejecución.

En la versión de ejecución de PowerShell 7.6, las actividades de los módulos no se extraen para los módulos importados.
PowerShell 7.x no admite flujos de trabajo. Para más información, consulte Flujo de trabajo de PowerShell.
PowerShell 7.x no admite actualmente runbooks firmados.
La integración de control de versiones no soporta PowerShell 7.6. Además, los runbooks de PowerShell 7.6 en control de versiones se crean en la cuenta de Automation como Runtime 5.1.
El módulo 15.1.0 de Az está instalado por defecto. La lista completa de módulos de componentes de la versión del módulo Az seleccionada se muestra una vez que la versión de Az se configura de nuevo mediante Azure Portal o la API.
Los módulos importados de PowerShell 7.6 se validan durante la ejecución del trabajo. Asegúrese de que todas las dependencias del módulo seleccionado también se importan para la ejecución correcta del trabajo.
Azure Automation libros de reglas no soportan Start-Job con credencial -.
Azure no admite todos los parámetros de entrada de PowerShell. Más información. Problemas conocidos
Los runbooks que dependen de rutas de archivos internas, como C:\modules, pueden fallar debido a cambios en la infraestructura de fondo del servicio. Cambie el código del runbook para asegurarse de que no haya dependencias en las rutas de acceso de archivo internas y use Get-ChildItem para obtener la información necesaria del módulo.
El cmdlet Get-AzStorageAccount podría producir un error: el comando Get-AzStorageAccount se encontró en el módulo Az.Storage, pero no se pudo cargar el módulo.
No se admite .\child-runbook.ps1 la ejecución de scripts secundarios.
Solución: UtiliceStart-AutomationRunbook (cmdlet interno) o Start-AzAutomationRunbook (del módulo Az.Automation) para iniciar otro libro de ejecución desde el libro de ejecución principal.
Cuando se usa la versión 3.0.0 o posterior del módulo ExchangeOnlineManagement, puede experimentar errores. Para resolver el problema, asegúrese de cargar explícitamente los módulos PowerShellGet y PackageManagement.

Cuando se usa el cmdlet New-AzAutomationVariable dentro del módulo de automatización de Az.Automation para cargar una variable de tipo objeto, la operación no funciona como se esperaba. Solución alternativa: convierta el objeto en una cadena JSON usando el cmdlet ConvertTo-Json y después cargue la variable con la cadena JSON como valor. Esta solución asegura el control adecuado de la variable en el entorno de Azure Automation como cadena JSON.

Ejemplo: Crea un objeto PowerShell que almacene información sobre las máquinas virtuales de Azure

azurepowershell

# Retrieve Azure virtual machines with status information for the 'northeurope' region 
$AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 

$VMstopatch = @($AzVM).Id 

# Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 

# Convert the object to a JSON string 
$jsonString = $VMstopatch | ConvertTo-Json 

# Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString

Limitaciones

Nota:

La versión de ejecución de PowerShell 7.4 soporta tanto trabajos en la nube como híbridos en todas las regiones.

Powershell 7.4 solo está disponible en la experiencia del entorno de ejecución.
Para la versión en tiempo de ejecución de PowerShell 7.4, las actividades del módulo no se extraen para los módulos importados. Utiliza la extensión de Azure Automation para VS Code para simplificar la experiencia de creación de runbooks.
PowerShell 7.x no admite flujos de trabajo. Para saber más, consulte Flujo de trabajo de PowerShell.
PowerShell 7.x no admite actualmente runbooks firmados.
La integración del control de código fuente no admite PowerShell 7.4. Además, los runbooks de PowerShell 7.4 en el control de código fuente se crean en la cuenta de Automation como Runtime 5.1.
Az module 12.3.0 está instalado de forma predeterminada. La lista completa de módulos de componentes de la versión del módulo Az seleccionada se muestra una vez que la versión de Az se configura de nuevo mediante Azure Portal o la API.
El módulo importado de PowerShell 7.4 se validaría durante la ejecución del trabajo. Asegúrese de que todas las dependencias del módulo seleccionado también se importan para la ejecución correcta del trabajo.
El runbook de Azure no es compatible con Start-Job y -credential.
Azure no admite todos los parámetros de entrada de PowerShell. Más información.

Problemas conocidos

Los runbooks que dependen de rutas de archivos internas, como C:\modules, pueden fallar debido a cambios en la infraestructura de fondo del servicio. Cambie el código del runbook para asegurarse de que no haya dependencias en las rutas de acceso de archivo internas y use Get-ChildItem para obtener la información necesaria del módulo.
El cmdlet Get-AzStorageAccount podría producir un error: el comando Get-AzStorageAccount se encontró en el módulo Az.Storage, pero no se pudo cargar el módulo.
No se admite .\child-runbook.ps1 la ejecución de scripts secundarios.
Solución: UtiliceStart-AutomationRunbook (cmdlet interno) o Start-AzAutomationRunbook (del módulo Az.Automation) para iniciar otro libro de ejecución desde el libro de ejecución principal.
Cuando se usa la versión 3.0.0 o posterior del módulo ExchangeOnlineManagement, puede experimentar errores. Para resolver el problema, asegúrese de cargar explícitamente los módulos PowerShellGet y PackageManagement.

Ejemplo: creación de un objeto de PowerShell que tenga información almacenada en torno a máquinas virtuales de Azure

azurepowershell

# Retrieve Azure virtual machines with status information for the 'northeurope' region 
$AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 

$VMstopatch = @($AzVM).Id 

# Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 

# Convert the object to a JSON string 
$jsonString = $VMstopatch | ConvertTo-Json 

# Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString

Limitaciones

Nota:

La versión de PowerShell 7.2 ya no es compatible con PowerShell primario.

Para la versión del entorno de ejecución de PowerShell 7.2, las actividades del módulo no se extraen para los módulos importados.
PowerShell 7.x no admite flujos de trabajo. Para saber más, consulte Flujo de trabajo de PowerShell.
PowerShell 7.x no admite actualmente runbooks firmados.
La integración del control de código fuente no admite PowerShell 7.2. Además, los runbooks de PowerShell 7.2 en el control de código fuente se crean en la cuenta de Automation como Runtime 5.1.
El módulo Az 8.3.0 está instalado de forma predeterminada. La lista completa de módulos de componentes de la versión del módulo Az seleccionada se muestra una vez que la versión de Az se configura de nuevo mediante Azure Portal o la API.
El módulo importado de PowerShell 7.2 se validaría durante la ejecución del trabajo. Asegúrese de que todas las dependencias del módulo seleccionado también se importan para la ejecución correcta del trabajo.
El runbook de Azure no es compatible con Start-Job y -credential.
Azure no admite todos los parámetros de entrada de PowerShell. Más información.

Problemas conocidos

Los runbooks que dependen de rutas de archivos internas, como C:\modules, pueden fallar debido a cambios en la infraestructura de fondo del servicio. Cambie el código del runbook para asegurarse de que no haya dependencias en las rutas de acceso de archivo internas y use Get-ChildItem para obtener la información necesaria del módulo.
El cmdlet Get-AzStorageAccount podría producir un error: el comando Get-AzStorageAccount se encontró en el módulo Az.Storage, pero no se pudo cargar el módulo.
No se admite .\child-runbook.ps1 la ejecución de scripts secundarios.
Solución: UtiliceStart-AutomationRunbook (cmdlet interno) o Start-AzAutomationRunbook (del módulo Az.Automation) para iniciar otro libro de ejecución desde el libro de ejecución principal.
Cuando se usa la versión 3.0.0 o posterior del módulo ExchangeOnlineManagement, puede experimentar errores. Para resolver el problema, asegúrese de cargar explícitamente los módulos PowerShellGet y PackageManagement.

Cuando se usa el cmdlet New-AzAutomationVariable dentro del módulo de automatización de Az.Automation para cargar una variable de tipo objeto, la operación no funciona como se esperaba.

Solución alternativa: convierta el objeto en una cadena JSON usando el cmdlet ConvertTo-Json y después cargue la variable con la cadena JSON como valor. Esta solución asegura el control adecuado de la variable en el entorno de Azure Automation como cadena JSON.

Ejemplo: creación de un objeto de PowerShell que tenga información almacenada en torno a máquinas virtuales de Azure

  azurepowershell

  # Retrieve Azure virtual machines with status information for the 'northeurope' region 
  $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 

  $VMstopatch = @($AzVM).Id 
  # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
  New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 

  # Convert the object to a JSON string 
  $jsonString = $VMstopatch | ConvertTo-Json 

  # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
  New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString

Limitaciones

Los runbooks no pueden usar el procesamiento paralelo para ejecutar varias acciones en paralelo.
Los runbooks no pueden usar los puntos de control para reanudar un runbook si se produce un error.
Solo puede incluir runbooks gráficos, de PowerShell y de flujo de trabajo de PowerShell como runbooks secundarios mediante el cmdlet Start-AzAutomationRunbook, que crea un trabajo.
Los runbooks no pueden usar la instrucción #Requires de PowerShell, no se admite en el espacio aislado de Azure ni en instancias de Hybrid Runbook Worker y provocarán un error en el trabajo.
El runbook de Azure no es compatible con Start-Job y -credential.
Azure no admite todos los parámetros de entrada de PowerShell. Más información.

Problemas conocidos

Los runbooks que dependen de rutas de archivos internas, como C:\modules, pueden fallar debido a cambios en la infraestructura de fondo del servicio. Cambie el código del runbook para asegurarse de que no haya dependencias en las rutas de acceso de archivo internas y use Get-ChildItem para obtener la información necesaria del módulo.

Script de ejemplo


# Get information about module "Microsoft.Graph.Authentication"
$ModuleName = "Microsoft.Graph.Authentication"

$NewPath = "C:\usr\src\PSModules\$ModuleName"
$OldPath = "C:\Modules\User\$ModuleName"

if (Test-Path -Path $NewPath -PathType Container) {
    Get-ChildItem -Path $NewPath
} elseif (Test-Path -Path $OldPath -PathType Container) {
    Get-ChildItem -Path $OldPath
} else {
    Write-Output "Module $ModuleName not present."
}
# Getting the path to the Temp folder, if needed.
$tmp = $env:TEMP

El cmdlet Get-AzStorageAccount podría producir un error: el comando Get-AzStorageAccount se encontró en el módulo Az.Storage, pero no se pudo cargar el módulo.
Los runbooks de PowerShell no pueden recuperar un recurso de variable sin cifrar con un valor null.
Los runbooks de PowerShell no pueden recuperar un recurso de variable con *~* en el nombre.
Una operación Get-Process en un bucle de un runbook de PowerShell puede bloquearse después de más de 80 iteraciones.
Un runbook de PowerShell puede producir un error si intenta escribir una gran cantidad de datos en el flujo de salida a la vez. Puede evitar este problema si hace que el runbook genere únicamente la información necesaria para trabajar con objetos grandes. Por ejemplo, en lugar de usar Get-Process sin limitaciones, puede hacer que el cmdlet genere solo los parámetros necesarios como en Get-Process | Select ProcessName, CPU.
Cuando se usa la versión 3.0.0 o posterior del módulo ExchangeOnlineManagement, puede experimentar errores. Para resolver el problema, asegúrese de cargar explícitamente los módulos PowerShellGet y PackageManagement.
Si importa el módulo Az.Accounts con la versión 2.12.3 o posterior, asegúrese de importar el módulo Newtonsoft.Json v10 explícitamente si los runbooks de PowerShell 5.1 tienen una dependencia en esta versión del módulo. La solución alternativa para este problema es usar runbooks de PowerShell 7.2.

Cuando se usa el cmdlet New-AzAutomationVariable dentro del módulo de automatización de Az.Automation para cargar una variable de tipo objeto, la operación no funciona como se esperaba.

Ejemplo: creación de un objeto de PowerShell que tenga información almacenada en torno a máquinas virtuales de Azure

  # Retrieve Azure virtual machines with status information for the 'northeurope' region 
  $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 

  $VMstopatch = @($AzVM).Id 
  # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
  New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 

  # Convert the object to a JSON string 
  $jsonString = $VMstopatch | ConvertTo-Json 

  # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
  New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString

Limitaciones

PowerShell 7.1 ya no es compatible con PowerShell primario. Se recomienda crear nuevos runbooks en PowerShell 7.4 para una compatibilidad a largo plazo y actualizar los runbooks obsoletos.
Los cmdlets internos de PowerShell correspondientes a Azure Automation no se admiten en una instancia de Hybrid Runbook Worker de Linux. Debe importar el módulo automationassets al comienzo de su runbook de PowerShell para acceder a las funciones de recursos compartidos (recursos) de la cuenta de Automation.
Para la versión del entorno de ejecución de PowerShell 7, las actividades del módulo no se extraen para los módulos importados.
El tipo de parámetro de runbook PSCredential no se admite en la versión del entorno de ejecución de PowerShell 7.
PowerShell 7.x no admite flujos de trabajo. Para saber más, consulte Flujo de trabajo de PowerShell.
PowerShell 7.x no admite actualmente runbooks firmados.
La integración del control de código fuente no admite PowerShell 7.1 (versión preliminar). Además, los runbooks de PowerShell 7.1 (versión preliminar) en el control de código fuente se crean en la cuenta de Automation como Runtime 5.1.
La administración de módulos de PowerShell 7.1 no se admite a través de Get-AzAutomationModulecmdlets.
Se produce un error en el runbook sin seguimiento de registro si el valor de entrada contiene el carácter '.
El runbook de Azure no es compatible con Start-Job y -credential.
Azure no admite todos los parámetros de entrada de PowerShell. Más información.

Problemas conocidos

Script de ejemplo


# Get information about module "Microsoft.Graph.Authentication"
$ModuleName = "Microsoft.Graph.Authentication"

$NewPath = "C:\usr\src\PSModules\$ModuleName"
$OldPath = "C:\Modules\User\$ModuleName"

if (Test-Path -Path $NewPath -PathType Container) {
    Get-ChildItem -Path $NewPath
} elseif (Test-Path -Path $OldPath -PathType Container) {
    Get-ChildItem -Path $OldPath
} else {
    Write-Output "Module $ModuleName not present."
}
# Getting the path to the Temp folder, if needed.
$tmp = $env:TEMP

El cmdlet Get-AzStorageAccount podría producir un error: el comando Get-AzStorageAccount se encontró en el módulo Az.Storage, pero no se pudo cargar el módulo.
La ejecución de scripts secundarios mediante .\child-runbook.ps1 no se admite en esta versión preliminar. Solución alternativa: use Start-AutomationRunbook(cmdlet interno) o Start-AzAutomationRunbook (desde el Az.Automation módulo) para iniciar otro runbook desde el runbook primario.
Las propiedades de runbook que definen la preferencia de registro no se admiten en el entorno de ejecución de PowerShell 7. Solución alternativa: establezca explícitamente la preferencia al principio del runbook como se indica a continuación:
```
    $VerbosePreference = "Continue"

    $ProgressPreference = "Continue"
```
Evite importar Az.Accounts el módulo a la versión 2.4.0 para el entorno de ejecución de PowerShell 7, ya que puede haber un comportamiento inesperado mediante esta versión en Azure Automation.
Es posible que encuentre problemas de formato con los flujos de salida de error para el trabajo que se ejecuta en el entorno de ejecución de PowerShell 7.
Al importar un módulo de PowerShell 7.1 que depende de otros módulos, el botón Importar puede aparecer gris incluso cuando ya esté instalada la versión de PowerShell 7.1 del módulo del que depende. Por ejemplo, la versión 4.20.0 de module.Compute de Az PowerShell tiene una dependencia en Az.Accounts que es >= 2.6.0. Este problema se produce cuando un módulo dependiente equivalente en PowerShell 5.1 no cumple los requisitos de versión. Por ejemplo, la versión 5.1 de Az.Accounts era < 2.6.0.
Al iniciar el runbook de PowerShell 7 mediante el webhook, convierte automáticamente el parámetro de entrada del webhook en un JSON no válido.
Se recomienda usar la versión del módulo ExchangeOnlineManagement: 3.0.0 o versiones posteriores, ya que la versión 3.0.0 o posterior puede provocar errores de trabajo.
Si importa el módulo Az.Accounts con la versión 2.12.3 o posterior, asegúrese de importar el módulo Newtonsoft.Json v10 explícitamente si los runbooks de PowerShell 7.1 tienen una dependencia en esta versión del módulo. La solución alternativa para este problema es usar runbooks de PowerShell 7.2.

Cuando se usa el cmdlet New-AzAutomationVariable dentro del módulo de automatización de Az.Automation para cargar una variable de tipo objeto, la operación no funciona como se esperaba.

Ejemplo: creación de un objeto de PowerShell que tenga información almacenada en torno a máquinas virtuales de Azure

  # Retrieve Azure virtual machines with status information for the 'northeurope' region 
  $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 

  $VMstopatch = @($AzVM).Id 
  # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
  New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 

  # Convert the object to a JSON string 
  $jsonString = $VMstopatch | ConvertTo-Json 

  # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
  New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString

Runbooks del flujo de trabajo de PowerShell

Los runbooks de PowerShell Workflow son runbooks de texto basados en Windows PowerShell Workflow. Puede modificar directamente el código del runbook con el editor de texto en el Portal de Azure. También puede usar cualquier editor de texto sin conexión e importar el runbook en Azure Automation.

Nota:

PowerShell 7.1 (versión preliminar) y PowerShell 7.2 no admiten runbooks de flujo de trabajo.

Ventajas

Implemente toda la lógica compleja con código del flujo de trabajo de PowerShell.
Use los puntos de control para reanudar la operación si se produce un error.
Utilice el procesamiento paralelo para realizar varias acciones en paralelo.
Se pueden incluir otros runbooks gráficos o de flujo de trabajo de PowerShell como runbooks secundarios para crear flujos de trabajo de alto nivel.

Limitaciones

El flujo de trabajo de PowerShell no se admite en versiones posteriores de PowerShell 7+. Por lo tanto, los manuales operativos obsoletos no pueden ser mejorados.
Control ineficaz de la ejecución en paralelo en comparación con las versiones más recientes de PowerShell 7+.
El flujo de trabajo de PowerShell funciona internamente con varios procesos. Por lo tanto, es posible que los módulos disponibles en un proceso no estén disponibles en otro y provoquen excepciones como comando no encontrado.
Los runbooks deben tratar la complejidad adicional del flujo de trabajo de PowerShell como objetos deserializados.
Los runbooks tardan más en iniciarse que los runbooks de PowerShell, ya que deben compilarse antes de su ejecución.
Solo puede incluir runbooks de PowerShell como runbooks secundarios mediante el Start-AzAutomationRunbookcmdlet.
Los runbooks no se pueden ejecutar en una instancia de Hybrid Runbook Worker de Linux.

Runbooks de Python

Los runbooks de Python se compilan en Python 3.10. Puede modificar directamente el código del runbook usando el editor de texto en el portal de Azure. También puede usar cualquier editor de texto sin conexión e importar el runbook en Azure Automation. El producto primario ya no admite Python 2.7 y Python 3.8 y se recomienda crear runbooks en la versión en tiempo de ejecución de Python 3.10.

La versión de ejecución de Python 3.10 es compatible tanto para trabajos en la nube como para trabajos híbridos en todas las regiones.

Ventajas

Nota:

La importación de un paquete de Python puede tardar varios minutos.

Usa las sólidas bibliotecas de Python.
Se pueden ejecutar en Azure o en instancias de Hybrid Runbook Worker.
Los scripts y paquetes de cualquier versión 3.x podrían funcionar si el código es compatible con distintas versiones.
Para trabajos híbridos de Python 3.10 en máquinas Windows, puede optar por instalar cualquier versión 3.x que quiera usar.
Para trabajos híbridos de Python 3.10 en máquinas Linux, dependemos de la versión de Python 3 instalada en la máquina para ejecutar DSC OMSConfig y Linux Hybrid Worker. Las distintas versiones deberían funcionar si no hay cambios importantes en los contratos o firmas de método entre las versiones de Python 3.

Limitaciones

Las limitaciones de los runbooks de Python son:

En el caso de los módulos de Python 3.10, actualmente solo se admiten los archivos wheel destinados al sistema operativo Linux cp310. Más información
No se admite la integración del control de código fuente.
Los paquetes personalizados para Python 3.10 solo se validan durante el tiempo de ejecución del trabajo. Se espera que se produzca un error en el trabajo si el paquete no es compatible en el runtime o si las dependencias necesarias de los paquetes no se importan en la cuenta de Automation.
Actualmente, los runbooks de Python 3.10 solo se admiten desde Azure Portal y la API rest.

Nota:

No se admite el uso de un webhook para iniciar un runbook de Python.

Varias versiones de Python

Es aplicable para trabajadores híbridos de Windows. En el caso de Runbook Worker de Windows, al ejecutar un runbook de Python 2, este busca primero la variable de entorno PYTHON_2_PATH y valida si apunta a un archivo ejecutable válido. Por ejemplo, si la carpeta de instalación es C:\Python2, comprobaría si C:\Python2\python.exe es una ruta de acceso válida. Si no se encuentra, busca la variable de entorno PATH para realizar una comprobación similar.

Para Python 3, primero busca la variable env PYTHON_3_PATH y, a continuación, recurre a la variable de entorno PATH.

Cuando se usa solo una versión de Python, puede agregar la ruta de instalación a la variable PATH. Si quiere usar ambas versiones en Runbook Worker, establezca PYTHON_2_PATH y PYTHON_3_PATH en la ubicación del módulo para esas versiones.

Problemas conocidos

En el caso de los trabajos en la nube, a veces se produce un error en los trabajos de Python 3.8 con un mensaje de excepción invalid interpreter executable path. Podría ver esta excepción si el trabajo se retrasa y empieza más de 10 minutos tarde o usa Start-AutomationRunbook para iniciar runbooks de Python 3.8. Si el trabajo se retrasa, reiniciar el runbook debería ser suficiente.

Runbooks gráficos

Puede crear y editar runbooks gráficos y runbooks gráficos de flujo de trabajo de PowerShell mediante el editor gráfico de Azure Portal. Sin embargo, no puede crear o editar este tipo de runbooks con otra herramienta. Principales características de los runbooks gráficos:

Se exportan a archivos de la cuenta de Automation y se importan a otra cuenta de Automation.
Generar código de PowerShell.
Se pueden convertir a y desde runbooks gráficos de flujo de trabajo de PowerShell durante la importación.

Ventajas

Utilice modelos de creación visual para insertar, vincular y configurar.
Céntrese en cómo fluyen los datos por el proceso.
Represente visualmente los procesos de administración.
Incluya otros runbooks como runbooks secundarios para crear flujos de trabajo de nivel alto.
Anime a usar la programación modular.

Limitaciones

No puede crear o editar fuera de Azure Portal.
Puede requerir una actividad de código que contenga código de PowerShell para ejecutar una lógica compleja.
No puede convertir a uno de los formatos de texto, ni puede convertir un runbook de texto a un formato gráfico.
No puede ver ni modificar directamente el código de PowerShell que el flujo de trabajo gráfico crea. Puede ver el código que crea en cualquier actividad de código.
No puede ejecutar runbooks en Linux Runbook Worker. Consulte Automatización de recursos en los centros de datos o nube con Hybrid Runbook Worker.
Los runbooks gráficos no se pueden firmar digitalmente.

Pasos siguientes

Para aprender sobre los runbooks de PowerShell, consulte Tutorial: Creación de un runbook de PowerShell.
Para aprender sobre los runbooks de flujo de trabajo de PowerShell, consulte Tutorial: Creación de un runbook de flujo de trabajo de PowerShell.
Para aprender sobre los runbooks gráficos, consulte Tutorial: Creación de un runbook gráfico.
Para aprender sobre los runbooks de Python, consulte Tutorial: Creación de un runbook de Python.
Para obtener información sobre la compatibilidad en tiempo de ejecución y la retirada al trabajar con runbooks, consulta Política de compatibilidad y retirada de entornos de ejecución de lenguajes para Azure Automation.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-08-13

Tipos de runbooks de Azure Automation

Runbooks de PowerShell

Ventajas

Limitaciones y problemas conocidos

Runbooks del flujo de trabajo de PowerShell

Ventajas

Limitaciones

Runbooks de Python

Ventajas

Limitaciones

Varias versiones de Python

Problemas conocidos

Runbooks gráficos

Ventajas

Limitaciones

Pasos siguientes

Comentarios

Recursos adicionales