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. Para más información sobre el entorno de automatización de procesos, consulte Ejecución de un runbook en Azure Automation.

Tipo	Descripción
PowerShell	Runbook de texto basado en scripting de Windows PowerShell. Las versiones admitidas actualmente son: PowerShell 7.2 (GA) y PowerShell 5.1 (GA). Dado que PowerShell 7.1 ya no es compatible con el producto primario PowerShell, se recomienda crear runbooks en la versión compatible a largo plazo de PowerShell 7.2.
Flujo de trabajo de PowerShell	Runbook de texto basado en scripting de flujo de trabajo de Windows PowerShell.
Python	Runbook de texto basado en scripting de Python. Las versiones admitidas actualmente son: Python 3.8 (GA) y Python 3.10 (versión preliminar). Dado que Python 2.7 ya no es compatible con el producto primario Python, se recomienda crear runbooks en versiones compatibles a largo plazo.
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.

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 del entorno de ejecución especificada (es decir, 7.2, 7.1 (versión preliminar) o 5.1).

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.

Nota:

• Actualmente, la versión en tiempo de ejecución de PowerShell 7.2 es compatible con trabajos híbridos y en la nube en todas las regiones públicas, excepto India central, centro de Emiratos Árabes Unidos, centro de Israel, norte de Italia y norte de Alemania.
• En el momento de la ejecución del runbook, si selecciona Versión del entorno de ejecución como 7.2, se usan los módulos de PowerShell destinados a la versión del entorno de ejecución 7.2; igualmente, si selecciona Versión del entorno de ejecución como 5.1, se usan los módulos de PowerShell que tienen como destino la versión del entorno de ejecución 5.1. Esto se aplica a los módulos y runbooks de PowerShell 7.1 (versión preliminar).

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ón 7.1 (versión preliminar), importe el módulo en la versión del entorno de ejecución 7.1 (versión preliminar); si por el contrario está ejecutando un runbook para un escenario de automatización de SharePoint en la versión del entorno de ejecución 5.1, importe el módulo en la versión del entorno de ejecución 5.1. En este caso, verá dos entradas para el módulo, una para la versión del entorno de ejecución 7.1 (versión preliminar) y otra para la versión 5.1.

Nota:

Actualmente, se admiten PowerShell 5.1, PowerShell 7.1 (versión preliminar) y PowerShell 7.2.

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:

PowerShell 7.2

Limitaciones

Nota:

Actualmente, la versión en tiempo de ejecución de PowerShell 7.2 es compatible con trabajos híbridos y en la nube en todas las regiones públicas, excepto India central, centro de Emiratos Árabes Unidos, centro de Israel, norte de Italia y norte de Alemania.

• 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. Use la extensión de Azure Automation para código VS para simplificar la experiencia de creación de runbook.
• 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 admite Start-Job con -credential.
• Azure no admite todos los parámetros de entrada de PowerShell. Más información.

Problemas conocidos

• Los runbooks que toman dependencias en rutas de acceso de archivos internas, como C:\modules pueden producir un error debido a cambios en la infraestructura de back-end 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 la ejecución de scripts secundarios mediante .\child-runbook.ps1.
  Solución alternativa: use Start-AutomationRunbook (cmdlet interno) o Start-AzAutomationRunbook (desde el módulo Az.Automation) para iniciar otro runbook desde un runbook primario.

• 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

    # 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 
  

PowerShell 5.1

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 admite Start-Job con -credential.
• Azure no admite todos los parámetros de entrada de PowerShell. Más información.

Problemas conocidos

• Los runbooks que toman dependencias en rutas de acceso de archivos internas, como C:\modules pueden producir un error debido a cambios en la infraestructura de back-end 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.

  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

    # 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 
  

PowerShell 7.1

Limitaciones

• PowerShell 7.1 ya no es compatible con PowerShell primario. Se recomienda crear nuevos runbooks en PowerShell 7.2 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 cmdlets Get-AzAutomationModule.
• 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 admite Start-Job con -credential.
• Azure no admite todos los parámetros de entrada de PowerShell. Más información.

Problemas conocidos

• Los runbooks que toman dependencias en rutas de acceso de archivos internas, como C:\modules pueden producir un error debido a cambios en la infraestructura de back-end 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.

• 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 módulo Az.Automation) 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, tal como se indica a continuación.

      $VerbosePreference = "Continue"
  
      $ProgressPreference = "Continue"
  

• Evite importar el módulo Az.Accounts a la versión 2.4.0 para el entorno de ejecución de PowerShell 7, ya que puede haber un comportamiento inesperado al usar 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, es posible que el botón Importar esté atenuado incluso cuando esté instalada la versión de PowerShell 7.1 del módulo dependiente. 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.

  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

    # 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 del flujo de trabajo de PowerShell son runbooks de texto basados en el flujo de trabajo de 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.

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 runbooks obsoletos no se pueden actualizar.
• 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 cmdlet Start-AzAutomationRunbook.
• 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 2.7(GA), Python 3.8 (GA) y Python 3.10 (versión preliminar). Puede modificar directamente el código del runbook con el editor de texto en Azure Portal. También puede usar cualquier editor de texto sin conexión e importar el runbook en Azure Automation.

Actualmente, la versión del entorno de ejecución de Python 3.10 (versión preliminar) es compatible con trabajos híbridos y en la nube en todas las regiones públicas, excepto Centro de Australia 2, Sur de Corea del Sur, Sur de Suecia, Jio en Centro de la India, Sudeste de Brasil, Centro de la India, Oeste de la India, Centro de Emiratos Árabes Unidos y nubes gubernamentales.

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.
• En el caso de Python 2.7, las instancias de Hybrid Runbook Worker de Windows son compatibles si Python2.7 está instalado.
• Para los trabajos en la nube de Python 3.8, se admite la versión 3.8 de Python. Los scripts y paquetes de cualquier versión 3.x podrían funcionar si el código es compatible con distintas versiones.
• En el caso de los trabajos híbridos de Python 3.8 en máquinas Windows, puede instalar cualquier versión 3. x que desee usar.
• Para los trabajos híbridos de Python 3.8 para Linux, depende de la versión de Python 3 instalada en el equipo para ejecutar DSC OMSConfig y Hybrid Worker para Linux. 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

A continuación se muestran las limitaciones de los runbooks de Python

Python 3.10 (versión preliminar)

• En el caso de los módulos de Python 3.10 (versión preliminar), 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 (versión preliminar) 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 (versión preliminar) solo se admiten desde Azure Portal. No se admiten las API REST ni PowerShell.

Python 3.8 (GA)

• Debe estar familiarizado con el scripting de Python.
• No se admite la integración del control de código fuente.
• Para los módulos de Python 3.8, use archivos wheel destinados a cp38-amd64.
• Para utilizar bibliotecas de terceros, debe importar los paquetes a la cuenta de Automation.
• Usar el cmdlet Start-AutomationRunbook en PowerShell o en el flujo de trabajo de PowerShell para iniciar un runbook de Python 3.8 no funciona. Puede usar el cmdlet Start-AzAutomationRunbook desde el nódulo Az.Automation o el cmdlet Start-AzureRmAutomationRunbook del módulo AzureRm.Automation para solucionar esta limitación. 
• Azure Automation no admite sys.stderr.
• El paquete automationassets de Python no está disponible en pypi.org, por lo que tampoco se puede importar a una máquina Windows.

Python 2.7

• Python 2.7 ya no es compatible con el producto primario Python. Se recomienda crear nuevos runbooks en las versiones admitidas y actualizar los runbooks obsoletos.
• Debe estar familiarizado con el scripting de Python.
• Para los módulos de Python 2.7.12, use archivos wheel cp27-amd6.
• Para utilizar bibliotecas de terceros, debe importar los paquetes a la cuenta de Automation.
• Azure Automation no admite sys.stderr.
• El paquete automationassets de Python no está disponible en pypi.org, por lo que tampoco se puede importar a una máquina Windows.

Varias versiones de Python

Es aplicable a roles de Hybrid Worker en 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.
• Generan 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 las actividades 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.