Migración de Hybrid Workers basados en agente existentes a Hybrid Workers basados en extensión

Importante

Azure Automation Hybrid Runbook Worker (Windows y Linux) basado en agente se retirará el 31 de agosto de 2024 y no se admitirá después de esa fecha. Antes del 31 de agosto de 2024, debe completar la migración de usuarios de Hybrid Runbook Workers a Workers basados en extensión. Además, a partir del 1 de noviembre de 2023, no será posible crear nuevas instancias de Hybrid Worker basadas en agente. Más información.

En este artículo se describen las ventajas de Hybrid Runbook Worker basado en extensiones y cómo migrar instancias de Hybrid Runbook Worker basadas en agente existentes a instancias de Hybrid Worker basadas en extensiones.

Hay dos plataformas de instalación de instancias de Hybrid Runbook Worker compatibles con Azure Automation:

  • Hybrid Runbook Worker basado en agente (V1): este trabajo depende del agente de Log Analytics.
  • Hybrid Runbook Worker basado en extensiones (V2): este trabajo proporciona integración nativa del rol Hybrid Runbook Worker mediante el marco de extensión de máquina virtual (VM). 

El proceso de ejecución de runbooks en Hybrid Runbook Worker sigue siendo el mismo para ambos.

Ventajas de Hybrid Runbook Worker basado en extensiones sobre Hybrid Worker basado en agente

El propósito del enfoque basado en extensiones es simplificar la instalación y administración de Hybrid Worker y eliminar la complejidad del trabajo con la versión basada en agente. Estas son algunas ventajas clave:

  • Incorporación fluida: el enfoque basado en agente para la incorporación de Hybrid Runbook Worker depende del agente de Log Analytics, que es un proceso con varios pasos, lento y propenso a errores. El enfoque basado en extensiones ofrece mayor seguridad y ya no depende del agente de Log Analytics.

  • Facilidad de administración: ofrece integración nativa con la identidad de Azure Resource Manager (ARM) para Hybrid Runbook Worker y proporciona flexibilidad para la gobernanza a gran escala mediante directivas y plantillas.

  • Autenticación basada en Microsoft Entra ID: usa identidades administradas asignadas por el sistema de máquina virtual proporcionadas por Microsoft Entra ID. Esto centraliza el control y la administración de identidades y credenciales de recursos.

  • Experiencia unificada: ofrece una experiencia idéntica para administrar máquinas habilitadas para Azure Arc en Azure y fuera de Azure.

  • Varios canales de incorporación: puede optar por incorporar y administrar trabajos basados en extensiones mediante Azure Portal, los cmdlets de PowerShell, Bicep, las plantillas de ARM, la API de REST y la CLI de Azure.

  • Actualización automática predeterminada: ofrece la actualización automática de las versiones secundarias de forma predeterminada, lo que reduce significativamente la capacidad de administración de mantenerse actualizado en la versión más reciente. Se recomienda habilitar las actualizaciones automáticas para aprovechar las ventajas de cualquier actualización de características o seguridad sin la sobrecarga manual. También puede dejar de participar en las actualizaciones automáticas en cualquier momento. Actualmente, no se admiten las actualizaciones de versiones principales y se deben administrar manualmente.

Nota:

Hybrid Runbook Worker basado en extensiones solo admite el tipo de Hybrid Runbook Worker de usuario y no incluye la instancia de Hybrid Runbook Worker del sistema necesaria para la característica Update Management.

Requisitos previos

Requisitos mínimos de la máquina

  • Dos núcleos
  • 4 GB de RAM
  • Las máquinas que no son de Azure deben tener instalado el agente de Azure Connected Machine. Para instalar AzureConnectedMachineAgent, consulte Conexión de máquinas híbridas a Azure desde Azure Portal para servidores habilitados para Arc o Administración de las máquinas virtuales VMware de Azure Arc para habilitar la administración de invitado en las máquinas virtuales de VMware vSphere habilitadas para Arc.
  • La identidad administrada asignada por el sistema debe estar habilitada en la máquina virtual de Azure, en el servidor habilitado para Arc o en la máquina virtual de VMware vSphere habilitada para Arc. Si la identidad administrada asignada por el sistema no está habilitada, se habilitará como parte del proceso de instalación mediante Azure Portal.

Sistemas operativos admitidos

Windows (x64) Linux (x64)
● Windows Server 2022 (incluido Server Core)
● Windows Server 2019 (incluido Server Core)
● Windows Server 2016, versiones 1709 y 1803 (no se incluye Server Core)
● Windows Server 2012, 2012 R2 (excepto Server Core)
● Windows 10 Enterprise (incluida la sesión múltiple) y Pro
● Debian GNU/Linux 8,9,10 y 11
● Ubuntu 18.04 LTS, 20.04 LTS y 22.04 LTS
● SUSE Linux Enterprise Server 15.2 y 15.3
● Red Hat Enterprise Linux Server 7, 8 y 9
● CentOS Linux 7 y 8
● SUSE Linux Enterprise Server (SLES) 15
● Rocky Linux 9
● Oracle Linux 7 y 8
La extensión de Hybrid Worker seguiría las escalas de tiempo de soporte técnico del proveedor del sistema operativo. 

Otros requisitos

Windows (x64) Linux (x64)
Windows PowerShell 5.1 (descargue WMF 5.1). PowerShell Core no se admite. La protección de Linux no debe estar habilitada. 
.NET Framework 4.6.2 o posterior. 

Requisitos de paquetes para Linux

Paquete necesario Descripción Versión mínima
Glibc Biblioteca GNU C 2.5-12
Openssl Bibliotecas OpenSSL 1.0 (se admiten TLS 1.1 y TLS 1.2)
Curl Cliente web de cURL 7.15.5
Python ctypes Biblioteca de funciones externas para Python Se requieren Python 2.x o Python 3.x
PAM Módulos de autenticación conectables
Paquete opcional Descripción Versión mínima
PowerShell Core Para ejecutar runbooks de PowerShell, es necesario instalar PowerShell Core. Para obtener instrucciones, consulte Instalación de PowerShell Core en Linux. 6.0.0

Permisos para credenciales de Hybrid Worker

Si Hybrid Worker basado en agente usa credenciales personalizadas de Hybrid Worker, asegúrese de que los permisos siguientes se asignan al usuario personalizado para evitar que los trabajos se suspendan en Hybrid Worker basado en extensiones.

Tipo de recurso Permisos de carpeta
Azure VM C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (lectura y ejecución)
Servidor habilitado para Arc C:\ProgramData\AzureConnectedMachineAgent\Tokens (lectura)
C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (lectura y ejecución)

Nota:

  • Para el servidor habilitado para Arc, asegúrese de reasignar los permisos a medida que se quitan cada vez que se actualice el agente de ARC.
  • Hybrid Runbook Worker no se admite actualmente para Virtual Machine Scale Sets (VMSS).

Migración de una instancia existente de Hybrid Worker basada en agente a instancias de Hybrid Worker basadas en extensiones

Para usar las ventajas de las instancias de Hybrid Worker basado en una extensión, debe migrar todas las instancias de Hybrid Worker existentes basadas en agente a trabajos basados en extensiones. Una máquina de trabajo puede coexistir con ambas plataformas: basada en agente (V1) y basada en extensión (V2). La instalación basada en la extensión no afecta a la instalación o administración de una instancia de Worker basada en agente.

Para instalar la extensión de Hybrid Worker en una instancia de Hybrid Worker existente basada en agente, siga estos pasos:

  1. En Automatización de procesos, seleccione Grupos de Hybrid Worker y el grupo de Hybrid Worker existente para ir a la página Grupo de Hybrid Worker.

  2. En Grupo de Hybrid Worker, seleccione Hybrid Workers>+ Agregar para ir a la página Agregar máquinas como Hybrid Worker.

  3. Active la casilla junto a la instancia de Hybrid Worker existente basada en agente (V1). Si no ve la instancia de Hybrid Worker basada en agente, asegúrese de que el agente de Connected Machine de Azure Arc está instalado en la máquina. Para instalar AzureConnectedMachineAgent, consulte Conexión de máquinas híbridas a Azure desde Azure Portal para servidores habilitados para Arc; o consulte Administración de las máquinas virtuales VMware de Azure Arc para habilitar la administración de invitado en las máquinas virtuales de VMware vSphere habilitadas para Arc.

    Captura de pantalla de la adición de máquinas como trabajador híbrido.

  4. Seleccione Agregar para agregar la máquina al grupo.

    La columna Plataforma muestra la misma instancia de Hybrid Worker como basada en agente (V1) y basada en extensiones (V2). Una vez que se sienta cómodo con la experiencia y el uso de Hybrid Worker basado en extensiones, puede quitar la instancia de Worker basada en agente.

    Captura de pantalla del campo de plataforma que muestra si el trabajador híbrido está basada en agente o en extensión.

Para la migración a gran escala de varias instancias de Hybrid Worker basadas en agente, también puede usar otros canales, como : Bicep, plantillas de ARM, cmdlets de PowerShell, API REST y la CLI de Azure.

Administración de la extensión de Hybrid Worker mediante plantillas de Bicep y ARM, API de REST, CLI de Azure y PowerShell

Puede usar la plantilla de Bicep para crear un nuevo grupo de Hybrid Worker, o crear una nueva máquina virtual Windows de Azure y agregarla a un grupo de Hybrid Worker existente. Obtenga más información sobre Bicep.

Siga los pasos mencionados a continuación como ejemplo:

  1. Cree un grupo de Hybrid Worker.
  2. Cree una máquina virtual de Azure o un servidor habilitado para Arc. Como alternativa, también puede usar una máquina virtual de Azure o un servidor habilitado para Arc existentes.
  3. Conecte la máquina virtual de Azure o el servidor habilitado para Arc al grupo de Hybrid Worker creado anteriormente.
  4. Genere un nuevo GUID y páselo como nombre de la instancia de Hybrid Worker.
  5. Habilite la identidad administrada asignada por el sistema en la máquina virtual.
  6. Instale la extensión de Hybrid Worker en la máquina virtual.
  7. Para confirmar si la extensión se ha instalado correctamente en la máquina virtual, en Azure Portal, vaya a la pestaña >Extensiones de la máquina virtual y compruebe el estado de la extensión de Hybrid Worker instalada en ella.
param automationAccount string
param automationAccountLocation string
param workerGroupName string

@description('Name of the virtual machine.')
param virtualMachineName string

@description('Username for the Virtual Machine.')
param adminUsername string

@description('Password for the Virtual Machine.')
@minLength(12)
@secure()
param adminPassword string

@description('Location for the VM.')
param vmLocation string = 'North Central US'

@description('Size of the virtual machine.')
param vmSize string = 'Standard_DS1_v2'

@description('The Windows version for the VM. This will pick a fully patched image of this given Windows version.')
@allowed([
  '2008-R2-SP1'
  '2012-Datacenter'
  '2012-R2-Datacenter'
  '2016-Nano-Server'
  '2016-Datacenter-with-Containers'
  '2016-Datacenter'
  '2019-Datacenter'
  '2019-Datacenter-Core'
  '2019-Datacenter-Core-smalldisk'
  '2019-Datacenter-Core-with-Containers'
  '2019-Datacenter-Core-with-Containers-smalldisk'
  '2019-Datacenter-smalldisk'
  '2019-Datacenter-with-Containers'
  '2019-Datacenter-with-Containers-smalldisk'
])
param osVersion string = '2019-Datacenter'

@description('DNS name for the public IP')
param dnsNameForPublicIP string

var nicName_var = 'myVMNict'
var addressPrefix = '10.0.0.0/16'
var subnetName = 'Subnet'
var subnetPrefix = '10.0.0.0/24'
var subnetRef = resourceId('Microsoft.Network/virtualNetworks/subnets', virtualNetworkName_var, subnetName)
var vmName_var = virtualMachineName
var virtualNetworkName_var = 'MyVNETt'
var publicIPAddressName_var = 'myPublicIPt'
var networkSecurityGroupName_var = 'default-NSGt'
var UniqueStringBasedOnTimeStamp = uniqueString(resourceGroup().id)

resource publicIPAddressName 'Microsoft.Network/publicIPAddresses@2020-08-01' = {
  name: publicIPAddressName_var
  location: vmLocation
  properties: {
    publicIPAllocationMethod: 'Dynamic'
    dnsSettings: {
      domainNameLabel: dnsNameForPublicIP
    }
  }
}

resource networkSecurityGroupName 'Microsoft.Network/networkSecurityGroups@2020-08-01' = {
  name: networkSecurityGroupName_var
  location: vmLocation
  properties: {
    securityRules: [
      {
        name: 'default-allow-3389'
        properties: {
          priority: 1000
          access: 'Allow'
          direction: 'Inbound'
          destinationPortRange: '3389'
          protocol: 'Tcp'
          sourceAddressPrefix: '*'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}

resource virtualNetworkName 'Microsoft.Network/virtualNetworks@2020-08-01' = {
  name: virtualNetworkName_var
  location: vmLocation
  properties: {
    addressSpace: {
      addressPrefixes: [
        addressPrefix
      ]
    }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: subnetPrefix
          networkSecurityGroup: {
            id: networkSecurityGroupName.id
          }
        }
      }
    ]
  }
}

resource nicName 'Microsoft.Network/networkInterfaces@2020-08-01' = {
  name: nicName_var
  location: vmLocation
  properties: {
    ipConfigurations: [
      {
        name: 'ipconfig1'
        properties: {
          privateIPAllocationMethod: 'Dynamic'
          publicIPAddress: {
            id: publicIPAddressName.id
          }
          subnet: {
            id: subnetRef
          }
        }
      }
    ]
  }
  dependsOn: [

    virtualNetworkName
  ]
}

resource vmName 'Microsoft.Compute/virtualMachines@2020-12-01' = {
  name: vmName_var
  location: vmLocation
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    hardwareProfile: {
      vmSize: vmSize
    }
    osProfile: {
      computerName: vmName_var
      adminUsername: adminUsername
      adminPassword: adminPassword
    }
    storageProfile: {
      imageReference: {
        publisher: 'MicrosoftWindowsServer'
        offer: 'WindowsServer'
        sku: osVersion
        version: 'latest'
      }
      osDisk: {
        createOption: 'FromImage'
      }
    }
    networkProfile: {
      networkInterfaces: [
        {
          id: nicName.id
        }
      ]
    }
  }
}

resource automationAccount_resource 'Microsoft.Automation/automationAccounts@2021-06-22' = {
  name: automationAccount
  location: automationAccountLocation
  properties: {
    sku: {
      name: 'Basic'
    }
  }
}

resource automationAccount_workerGroupName 'Microsoft.Automation/automationAccounts/hybridRunbookWorkerGroups@2022-02-22' = {
  parent: automationAccount_resource
  name: workerGroupName
  dependsOn: [

    vmName
  ]
}

resource automationAccount_workerGroupName_testhw_UniqueStringBasedOnTimeStamp 'Microsoft.Automation/automationAccounts/hybridRunbookWorkerGroups/hybridRunbookWorkers@2021-06-22' = {
  parent: automationAccount_workerGroupName
  name: guid('testhw', UniqueStringBasedOnTimeStamp)
  properties: {
    vmResourceId: resourceId('Microsoft.Compute/virtualMachines', virtualMachineName)
  }
  dependsOn: [
    vmName
  ]
}

resource virtualMachineName_HybridWorkerExtension 'Microsoft.Compute/virtualMachines/extensions@2022-03-01' = {
  name: '${virtualMachineName}/HybridWorkerExtension'
  location: vmLocation
  properties: {
    publisher: 'Microsoft.Azure.Automation.HybridWorker'
    type: 'HybridWorkerForWindows'
    typeHandlerVersion: '1.1'
    autoUpgradeMinorVersion: true
    enableAutomaticUpgrade: true
    settings: {
      AutomationAccountURL: automationAccount_resource.properties.automationHybridServiceUrl
    }
  }
  dependsOn: [
    vmName
  ]
}

output output1 string = automationAccount_resource.properties.automationHybridServiceUrl

Eliminación de Hybrid Worker basado en agente

  1. Abra una sesión de PowerShell en modo Administrador y ejecute el siguiente comando:

     Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\HybridRunbookWorker\<AutomationAccountID>\<HybridWorkerGroupName>" -Force -Verbose
    
  2. En Automatización de procesos, seleccione Grupos de Hybrid Worker y, a continuación, el grupo de Hybrid Worker para ir a la página Grupo de Hybrid Worker.

  3. En Grupo de Hybrid Worker, seleccione Hybrid Workers.

  4. Active la casilla situada junto a las máquinas que desea eliminar del grupo de Hybrid Worker.

  5. Seleccione Eliminar para quitar Hybrid Worker de Windows basado en agente.

    Nota:

    • Después de deshabilitar Private Link en la cuenta de Automation, podría tardar hasta 60 minutos en quitar el trabajo de runbook híbrido.
    • Después de quitar el rol Hybrid Worker, el certificado de autenticación de Hybrid Worker en la máquina es válido durante 45 minutos.

Pasos siguientes