Migrar as funções de trabalho híbridas baseadas em agente existentes para funções de trabalho híbridas baseadas em extensão

  • Artigo

Importante

O Runbook Worker Híbrido de Usuário baseado no Azure Automation Agent (Windows e Linux) foi desativado em 31 de agosto de 2024 e não é mais suportado. Siga as diretrizes neste artigo sobre como migrar de um Runbook Workers híbrido de usuário baseado em agente existente para um trabalhador híbrido baseado em extensão.

Este artigo descreve os benefícios do Runbook Worker Híbrido de Usuário baseado em Extensão e como migrar Trabalhadores de Runbook Híbrido de Usuário baseados em Agente existentes para Trabalhadores Híbridos baseados em Extensão.

Há duas plataformas de instalação do Hybrid Runbook Workers suportadas pela Automação do Azure:

  • Trabalhador de runbook híbrido baseado em agente (V1) - O trabalhador de runbook híbrido baseado em agente depende do Agente do Log Analytics.
  • Trabalhador de runbook híbrido baseado em extensão (V2) - O trabalhador de runbook híbrido baseado em extensão fornece integração nativa da função de trabalhador de runbook híbrido por meio da estrutura de extensão de máquina virtual (VM). 

O processo de execução de runbooks em Hybrid Runbook Workers permanece o mesmo para ambos.

Benefícios dos trabalhadores de runbook híbridos de usuário baseados em extensão em relação aos trabalhadores baseados em agente

O objetivo da abordagem baseada em Extensão é simplificar a instalação e a gestão da Função de Trabalho Híbrida e remover a complexidade do funcionamento com a versão baseada em Agente. Aqui estão alguns benefícios importantes:

  • Integração contínua – A abordagem baseada em agente para a integração do Runbook worker híbrido depende do Log Analytics Agent, que é um processo de várias etapas, demorado e propenso a erros. A abordagem baseada em extensão oferece mais segurança e não depende mais do Log Analytics Agent.

  • Facilidade de gerenciamento – Ele oferece integração nativa com a identidade do Azure Resource Manager (ARM) para o Hybrid Runbook Worker e fornece a flexibilidade para governança em escala por meio de políticas e modelos.

  • Autenticação baseada em ID do Microsoft Entra – Usa identidades gerenciadas atribuídas pelo sistema VM fornecidas pelo Microsoft Entra ID. Isso centraliza o controle e o gerenciamento de identidades e credenciais de recursos.

  • Experiência unificada – Oferece uma experiência idêntica para gerenciar máquinas habilitadas para ArcGIS do Azure e fora do Azure.

  • Vários canais de integração – Você pode optar por integrar e gerenciar trabalhadores baseados em Extensão por meio do portal do Azure, cmdlets do PowerShell, Bicep, modelos ARM, API REST e CLI do Azure.

  • Atualização automática padrão – Oferece atualização automática de versões secundárias por padrão, reduzindo significativamente a capacidade de gerenciamento de permanecer atualizado sobre a versão mais recente. Recomendamos ativar as atualizações automáticas para tirar proveito de quaisquer atualizações de segurança ou recursos sem a sobrecarga manual. Você também pode desativar as atualizações automáticas a qualquer momento. Quaisquer atualizações de versão principal não são suportadas no momento e devem ser gerenciadas manualmente.

Nota

O Runbook Worker Híbrido baseado em Extensão suporta apenas o tipo User Hybrid Runbook Worker e não inclui o System Hybrid Runbook Worker necessário para o recurso Gerenciamento de Atualizações.

Pré-requisitos

Requisitos mínimos da máquina

  • Dois núcleos
  • 4 GB de RAM
  • As máquinas que não sejam do Azure devem ter o agente do Azure Connected Machine instalado. Para instalar o AzureConnectedMachineAgent, consulte Conectar máquinas híbridas ao Azure a partir do portal do Azure para servidores habilitados para Arc ou consulte Gerenciar máquinas virtuais VMware Azure Arc para habilitar o gerenciamento de convidados para VMs VMware vSphere habilitadas para Arc.
  • A identidade gerenciada atribuída ao sistema deve ser habilitada na máquina virtual do Azure, no servidor habilitado para Arc ou na VM VMware vSphere habilitada para Arc. Se a identidade gerenciada atribuída ao sistema não estiver habilitada, ela será habilitada como parte do processo de instalação por meio do portal do Azure.

Sistemas operativos suportados

Windows (x64) Linux (x64)
● Windows Server 2022 (incluindo Server Core)
● Windows Server 2019 (incluindo Server Core)
● Windows Server 2016, versão 1709 e 1803 (excluindo Server Core)
● Windows Server 2012, 2012 R2 (excluindo Server Core)
● Windows 10 Enterprise (incluindo várias sessões) e Pro		 ● Debian GNU/Linux 8,9,10 e 11
● Ubuntu 18.04 LTS, 20.04 LTS e 22.04 LTS
● SUSE Linux Enterprise Server 15.2 e 15.3
● Red Hat Enterprise Linux Server 7, 8 e 9
● SUSE Linux Enterprise Server (SLES) 15
● Rocky Linux 9
● Oracle Linux 7 e 8
A extensão do Hybrid Worker seguiria os cronogramas de suporte do fornecedor do sistema operacional. 

Outros Requisitos

Windows (x64) Linux (x64)
Windows PowerShell 5.1 (transferir o WMF 5.1). Não há suporte para o PowerShell Core. O Linux Hardening não deve ser ativado. 
.NET Framework 4.6.2 ou posterior. 

Requisitos de pacote para Linux

Pacote Necessário Description Versão Mínima
Glibc Biblioteca GNU C 2.5-12
Openssl Bibliotecas de OpenSSL 1.0 (são suportados TLS 1.1 e TLS 1.2)
Curl Cliente web cURL 7.15.5
Python-ctypes Biblioteca de funções externas para Python É necessário o Python 2.x ou Python 3.x
PAM Módulos de Autenticação Incorporável
Pacote opcional Description Versão Mínima
PowerShell Core Para executar runbooks do PowerShell, o PowerShell Core tem de estar instalado. Para obter instruções, consulte Instalando o PowerShell Core no Linux 6.0.0

Permissões para credenciais de trabalhador híbrido

Se o Trabalhador Híbrido baseado em extensão estiver usando credenciais de Trabalhador Híbrido personalizadas, certifique-se de que as permissões de pasta a seguir sejam atribuídas ao usuário personalizado para evitar que os trabalhos sejam suspensos.

Tipo de Recurso Permissões de pasta
VM do Azure C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (leitura e execução)
Servidor compatível com o Arc C:\ProgramData\AzureConnectedMachineAgent\Tokens (leitura)
C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (ler e executar).

Nota

  • Quando um sistema tem UAC/LUA em vigor, as permissões devem ser concedidas diretamente e não por meio de qualquer associação de grupo. Mais informações.
  • Para o servidor habilitado para Arc, certifique-se de reatribuir as permissões à medida que elas forem removidas sempre que o agente ARC for atualizado.
  • Atualmente, o Hybrid Runbook Worker não é suportado para VMSS (Virtual Machine Scale Sets).

Migrar um trabalhador híbrido baseado em agente existente para um trabalhador híbrido baseado em extensão

Para utilizar os benefícios dos Trabalhadores Híbridos baseados em extensão, você deve migrar todos os Trabalhadores Híbridos de Usuário baseados em agente existentes para Trabalhadores baseados em extensão. Uma máquina de trabalho híbrida pode coexistir em plataformas baseadas em agente (V1) e baseadas em extensão (V2). A instalação baseada em extensão não afeta a instalação ou o gerenciamento de um Worker baseado em agente.

Para instalar a extensão de trabalho híbrido em um trabalhador híbrido baseado em agente existente, verifique se os pré-requisitos foram atendidos antes de seguir estas etapas:

  1. Em Automação de Processos, selecione Grupos de trabalhadores híbridos e, em seguida, selecione seu grupo de trabalhadores híbridos existente para ir para a página Grupo de trabalhadores híbridos.

  2. Em Grupo de trabalhadores híbridos, selecione Trabalhadores híbridos>+ Adicionar para ir para a página Adicionar máquinas como trabalhador híbrido.

  3. Marque a caixa de seleção ao lado do trabalhador híbrido baseado em agente (V1) existente. Se você não vir seu Trabalhador Híbrido baseado em agente listado, verifique se o agente Azure Arc Connected Machine está instalado no computador. Para instalar o AzureConnectedMachineAgent, consulte Conectar máquinas híbridas ao Azure a partir do portal do Azure para servidores habilitados para Arc ou consulte Gerenciar máquinas virtuais VMware Azure Arc para habilitar o gerenciamento de convidados para VMs VMware vSphere habilitadas para Arc.

    Captura de tela da adição de máquinas como trabalhador híbrido.

  4. Selecione Adicionar para anexar a máquina ao grupo.

    A coluna Plataforma mostra o mesmo trabalhador híbrido baseado em agente (V1) e baseado em extensão (V2). Depois de ter certeza da experiência e do uso do Trabalhador Híbrido baseado em extensão, você poderá remover o Trabalhador baseado em agente.

    Captura de tela do campo da plataforma mostrando o trabalhador híbrido baseado em agente ou extensão.

Para migração em escala de vários Trabalhadores Híbridos baseados em Agente, você também pode usar outros canais , como - Bicep, modelos ARM, cmdlets do PowerShell, API REST e CLI do Azure.

Gerenciar a extensão de trabalho híbrido usando modelos Bicep & ARM, API REST, CLI do Azure e PowerShell

Você pode usar o modelo Bicep para criar um novo grupo de Trabalhadores Híbridos, criar uma nova VM do Windows do Azure e adicioná-la a um Grupo de Trabalhadores Híbridos existente. Saiba mais sobre o Bicep.

Siga os passos mencionados abaixo como exemplo:

  1. Crie um grupo de trabalhadores híbrido.
  2. Crie uma VM do Azure ou um servidor habilitado para Arc. Como alternativa, você também pode usar uma VM do Azure existente ou um servidor habilitado para Arc.
  3. Conecte a VM do Azure ou o servidor habilitado para Arc ao Grupo de Trabalho Híbrido criado acima.
  4. Gere um novo GUID e passe-o como o nome do Trabalhador Híbrido.
  5. Habilite a identidade gerenciada atribuída ao sistema na VM.
  6. Instale a Extensão de Trabalho Híbrido na VM.
  7. Para confirmar se a extensão foi instalada com êxito na VM, no portal do Azure, vá para a guia Extensões de VM >e verifique o status da extensão de Trabalho Híbrido instalada na VM.
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

Remover trabalhador híbrido baseado em agente

  1. Abra a sessão do PowerShell no modo Administrador e execute o seguinte comando:

     Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\HybridRunbookWorker\<AutomationAccountID>\<HybridWorkerGroupName>" -Force -Verbose

  2. Em Automatização de Processos, selecione Grupos de funções de trabalho híbridas e, em seguida, o grupo de funções de trabalho híbridas para aceder à página Grupo de Funções de Trabalho Híbridas.

  3. Em Grupo de funções de trabalho híbridas, selecione Funções de Trabalho Híbridas.

  4. Selecione a caixa de verificação junto aos computadores que quer eliminar do grupo de funções de trabalho híbridas.

  5. Selecione Excluir para remover o Windows Hybrid Worker baseado em agente.

    Nota

    • Depois de desativar o Link privado em sua conta de automação, pode levar até 60 minutos para remover o trabalhador Runbook híbrido.
    • Depois de remover o Trabalhador Híbrido, o certificado de autenticação do Trabalhador Híbrido na máquina é válido por 45 minutos.

Próximos passos