Migrar Hybrid Workers baseados em agente existentes para Hybrid Workers baseados em extensão

  • Artigo

Importante

A Automação do Azure Hybrid Runbook Worker (Windows e Linux) baseado em agente será desativada em 31 de agosto de 2024 e não terá suporte após essa data. Você precisa concluir a migração de trabalhos de runbook híbrido de usuário baseados em agente existentes para trabalhos baseados em extensão antes de 31 de agosto de 2024. Além disso, a partir de 1º de novembro de 2023, não será possível criar Hybrid Workers baseados em agente. Saiba mais.

Este artigo descreve os benefícios do Hybrid Runbook Worker baseado em extensão e como migrar os Hybrid Runbook Workers baseados em agente existentes para hybrid workers baseados em extensão.

Há duas plataformas de instalação do Hybrid Runbook Workers compatíveis com a Automação do Azure:

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

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

Benefícios dos Hybrid Runbook Workers baseados em extensão sobre trabalhadores baseados em agente

A finalidade da abordagem baseada em extensão é simplificar a instalação e o gerenciamento do Hybrid Worker e remover a complexidade de trabalhar com a versão baseada em agente. Confira alguns dos principais benefícios:

  • Integração contínua – a abordagem baseada em agente para integração do Hybrid Runbook Worker depende do agente do Log Analytics, 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 Agente do Log Analytics.

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

  • Autenticação baseada na Microsoft Entra ID – ela usa identidades gerenciadas atribuídas pelo sistema VM fornecidas pela Microsoft Entra ID. Isso centraliza o controle e o gerenciamento de identidades e credenciais de recurso.

  • Experiência unificada – oferece uma experiência idêntica para gerenciar computadores habilitados para Azure e fora do Azure Arc.

  • 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 do ARM, API REST e CLI do Azure.

  • Atualização automática padrão – ela oferece atualização automática de versões secundárias por padrão, reduzindo significativamente a capacidade de gerenciamento de permanecer atualizado na versão mais recente. É recomendável habilitar atualizações automáticas para aproveitar as atualizações de segurança ou de recursos sem a sobrecarga manual. Você também pode recusar as atualizações automáticas a qualquer momento. Atualmente, não há suporte para atualizações de versão principais e devem ser gerenciadas manualmente.

Observação

O Hybrid Runbook Worker baseado em extensão só dá suporte ao tipo de Hybrid Runbook Worker do usuário e não inclui o System Hybrid Runbook Worker necessário para o recurso de Gerenciamento de Atualizações.

Pré-requisitos

Requisitos mínimos do computador

  • Dois núcleos
  • 4 GB de RAM
  • Computadores que não são do Azure precisam ter o agente do Azure Connected Machine instalado. Para instalar o AzureConnectedMachineAgent, confira Conectar computadores híbridos do Azure do portal do Azure para servidores habilitados para Arc ou Gerenciar máquinas virtuais VMware no Azure Arc para habilitar o gerenciamento de convidados para VM do VMware vSphere habilitada para o Arc.
  • A identidade gerenciada atribuída pelo sistema precisa ser habilitada na máquina virtual do Azure, servidor habilitado para Arc ou VM VMware vSphere habilitada para Arc. Se a identidade gerenciada atribuída pelo sistema não estiver habilitada, ela será habilitada como parte do processo de instalação por meio do portal do Azure.

Sistemas operacionais compatíveis

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 o Server Core)
● Windows Server 2012, 2012 R2 (excluindo o 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
● Servidor Red Hat Enterprise Linux 7, 8 e 9
● CentOS Linux 7 e 8
● Servidor SUSE Linux Enterprise (SLES) 15
● Rocky Linux 9
● Oracle Linux 7 e 8
A extensão Hybrid Worker seguiria as linhas de tempo de suporte do fornecedor do sistema operacional. 

Outros requisitos

Windows (x64) Linux (x64)
Windows PowerShell 5.1 ou posterior (baixe o WMF 5.1). Não há suporte para o PowerShell Core. A proteção do Linux não pode estar habilitada. 
.NET Framework 4.6.2 ou posterior. 

Requisitos de pacote para Linux

Pacote necessário Descrição Versão mínima
Glibc Biblioteca GNU C 2.5-12
Openssl Bibliotecas OpenSSL 1.0 (há suporte para TLS 1.1 e TLS 1.2)
Curl cliente Web cURL 7.15.5
Python-ctypes Biblioteca de funções estrangeiras para Python Python 2. x ou Python 3. x são necessários
PAM Módulos de autenticação conectáveis
Pacotes opcionais Descrição Versão mínima
PowerShell Core Para executar runbooks do PowerShell, é necessário ter o PowerShell Core instalado. Para ver as instruções, confira Instalar o PowerShell Core no Linux. 6.0.0

Permissões para credenciais do Hybrid Worker

Se o Hybrid Worker baseado em agente estiver usando credenciais personalizadas do Hybrid Worker, verifique se as permissões a seguir são atribuídas ao usuário personalizado para evitar que os trabalhos sejam suspensos no Hybrid Worker baseado em extensão.

Tipo de recurso Permissões de pasta
VM do Azure C:\Packages\Plugins\Microsoft. Azure.Automation.HybridWorker.HybridWorkerForWindows (leitura e execução)
Servidores habilitados para o Arc C:\ProgramData\AzureConnectedMachineAgent\Tokens (leitura)
C:\Packages\Plugins\Microsoft. Azure.Automation.HybridWorker.HybridWorkerForWindows (leitura e execução)

Observação

  • Para o servidor habilitado para Arc, certifique-se de reatribuir as permissões conforme elas são removidas sempre que o agente ARC for atualizado.
  • Atualmente, não há suporte no Hybrid Runbook Worker para VMSS (Conjuntos de Dimensionamento de Máquinas Virtuais).

Migrar um Hybrid Worker baseado em agente existente para o Hybrid Worker baseado em extensão

Para utilizar os benefícios dos Hybrid Workers baseados em extensão, você deve migrar todos os Hybrid Workers do Usuário baseados em agente existentes para Workers baseados em extensão. Um computador Hybrid Worker pode existir em conjunto nas plataformas Com base em agente (V1) e Com base 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 do Hybrid Worker em um Hybrid Worker baseado em agente existente, siga estas etapas:

  1. Em Automação de Processo, selecione Grupos de Hybrid Workers e selecione o seu grupo de Hybrid Workers existente para acessar a página Grupo de Hybrid Workers.

  2. Em Grupo de Hybrid Workers, selecione Hybrid Workers>+ Adicionar para ir para a página Adicionar computadores como Hybrid Worker.

  3. Marque a caixa de seleção ao lado do Hybrid Worker V1 (baseado em Agente) existente. Se você não vir o Hybrid Worker baseado em agente listado, verifique se o agente do Azure Arc Connected Machine está instalado no computador. Para instalar o AzureConnectedMachineAgent, confira conectar computadores híbridos do Azure do portal do Azure para servidores habilitados para Arc ou Gerenciar máquinas virtuais VMware no Azure Arc para habilitar o gerenciamento de convidados para VM do VMware vSphere habilitada para o Arc.

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

  4. Selecione Adicionar para acrescentar o computador ao grupo.

    A coluna Plataforma mostra o mesmo Hybrid Worker que o V1 (baseado em agente) e V2 (baseado em extensão). Depois de ter certeza da experiência e do uso do Hybrid Worker baseado em extensão, você pode remover o Worker baseado em agente.

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

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

Gerenciar a extensão Hybrid Worker usando modelos Bicep e ARM, API REST, CLI do Azure e PowerShell

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

Siga as etapas mencionadas abaixo como um exemplo:

  1. Criar um grupo do Hybrid Worker.
  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 do Hybrid Worker criado acima.
  4. Gere um novo GUID e passe-o como o nome do Hybrid Worker.
  5. Habilite a identidade gerenciada atribuída pelo sistema na VM.
  6. Instale a Extensão Hybrid Worker na VM.
  7. Para confirmar se a extensão foi instalada com êxito na VM, no portal do Azure, acesse a guia >Extensões da VM e verifique o status da extensão Hybrid Worker 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 o Hybrid Worker 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 Automação de Processo, selecione Grupos de Hybrid Workers e o seu grupo de Hybrid Workers para acessar a página Grupo de Hybrid Workers.

  3. Em Grupo de Hybrid Workers, selecione Hybrid Workers.

  4. Marque a caixa de seleção ao lado dos computadores que você deseja excluir do grupo de Hybrid Workers.

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

    Observação

    • Depois que você desabilitar o Link Privado na sua conta de Automação, poderão ser necessários até 60 minutos para remover o Hybrid Runbook Worker.
    • Depois de remover o Hybrid Worker, o certificado de autenticação dele no computador é válido por 45 minutos.

Próximas etapas