Миграция с существующих гибридных рабочих ролей на основе агента на гибридные рабочие роли на основе расширений

  • Статья

Внимание

31 августа 2024 г. служба автоматизации Azure гибридная рабочая роль Runbook на основе агента (Windows и Linux) не поддерживается. Следуйте инструкциям из этой статьи о переходе с существующих гибридных рабочих ролей Runbook на основе агента в гибридные рабочие роли на основе расширений.

В этой статье описываются преимущества гибридной рабочей роли Runbook на основе расширений и перенос существующих рабочих ролей Runbook на основе агента в гибридные рабочие роли на основе расширений.

Существует две платформы установки гибридных рабочих ролей Runbook, поддерживаемые служба автоматизации Azure:

  • Гибридная рабочая роль Runbook на основе агента (V1) — гибридная рабочая роль Runbook на основе агента зависит от агента Log Analytics.
  • Гибридная рабочая роль runbook на основе расширений (версия 2) на основе расширений — гибридная рабочая роль Runbook на основе расширений модуля runbook на основе расширений модуля runbook на основе расширений на основе расширений модуля runbook на основе расширений модуля runbook на основе расширений на основе расширений на основе расширени 

Процесс выполнения модулей Runbook на гибридных рабочих ролях Runbook остается одинаковым для обоих.

Преимущества гибридных рабочих ролей Runbook на основе расширений над рабочими ролей на основе агента

Цель подхода на основе расширений — упростить установку и администрирование гибридной рабочей роли, а также упростить работу с версией на основе агента. Ниже приведены некоторые ключевые преимущества:

  • Простая адаптация — подход на основе агента для подключения гибридной рабочей роли Runbook зависит от агента Log Analytics, который является многоэтапным, трудоемким и подверженным ошибкам процессу. Подход на основе расширений обеспечивает большую безопасность и больше не зависит от агента Log Analytics.

  • Простота управления . Она обеспечивает встроенную интеграцию с удостоверением Azure Resource Manager (ARM) для гибридной рабочей роли Runbook и обеспечивает гибкость управления в масштабе с помощью политик и шаблонов.

  • Проверка подлинности на основе идентификатора Microsoft Entra — использует управляемые удостоверения, назначаемые системой виртуальной машины, предоставляемые идентификатором Microsoft Entra. Это централизованно управляет удостоверениями и учетными данными ресурсов.

  • Унифицированный интерфейс . Он предлагает идентичный интерфейс для управления компьютерами с поддержкой Azure и вне Azure Arc.

  • Несколько каналов подключения. Вы можете подключить и управлять рабочими ролей на основе расширений с помощью портал Azure, командлетов PowerShell, Bicep, шаблонов ARM, REST API и Azure CLI.

  • Автоматическое обновление по умолчанию — оно предлагает автоматическое обновление дополнительных версий по умолчанию, что значительно снижает управляемость при обновлении последней версии. Рекомендуется включить автоматическое обновление, чтобы воспользоваться преимуществами любых обновлений безопасности или компонентов без ручной нагрузки. Вы также можете отказаться от автоматического обновления в любое время. Обновления основных версий в настоящее время не поддерживаются и должны управляться вручную.

Примечание.

Гибридная рабочая роль Runbook на основе расширений поддерживает только тип гибридной рабочей роли Runbook пользователя и не включает в себя системную гибридную рабочую роль Runbook, необходимую для функции управления обновлениями.

Необходимые компоненты

Минимальные требования к компьютеру

Поддерживаемые операционные системы

Windows (x64) Linux (x64)
● Windows Server 2022 (включая серверную ядро)
● Windows Server 2019 (включая серверную ядро)
● Windows Server 2016, версия 1709 и 1803 (за исключением server Core)
● Windows Server 2012, 2012 R2 (за исключением основных серверных компонентов)
● Windows 10 Корпоративная (включая несколько сеансов) и Pro		 ● Debian GNU/Linux 8,9,10 и 11
• Ubuntu 18.04 LTS, 20.04 LTS и 22.04 LTS
• SUSE Linux Enterprise Server 15.2 и 15.3
● Red Hat Enterprise Linux Server 7, 8 и 9
● SUSE Linux Enterprise Server (SLES) 15
● Rocky Linux 9
● Oracle Linux 7 и 8
Расширение гибридной рабочей роли будет следовать временной шкале поддержки поставщика ОС. 

Прочие требования

Windows (x64) Linux (x64)
Windows PowerShell 5.1 (загрузка WMF 5.1). PowerShell Core не поддерживается. Не требуется включать усиление защиты Linux. 
.NET Framework 4.6.2 или более поздней версии. 

Требования к пакету для Linux

Требуемый пакет Description Минимальная версия
Glibc Библиотека C GNU 2.5-12
Openssl Библиотеки OpenSSL 1.0 (поддерживается TLS 1.1 и TLS 1.2)
Curl Веб-клиент cURL 7.15.5
Python-ctypes Библиотека внешних функций для Python Требуется Python 2.x или Python 3.x
PAM Подключаемые модули аутентификации
Дополнительный пакет Description Минимальная версия
PowerShell Core Для выполнения модулей runbook PowerShell требуется установить PowerShell Core. Инструкции см. в разделе "Установка PowerShell Core в Linux" 6.0.0

Разрешения для учетных данных гибридной рабочей роли

Если гибридная рабочая роль на основе расширений использует пользовательские учетные данные гибридной рабочей роли, убедитесь, что следующие разрешения папки назначаются пользовательскому пользователю, чтобы избежать приостановки заданий.

Тип ресурса Разрешения папки
Azure C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (чтение и выполнение)
Сервер с поддержкой Arc C:\ProgramData\AzureConnectedMachineAgent\Token (read)
C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (чтение и выполнение).

Примечание.

  • Если в системе есть UAC/LUA, разрешения должны предоставляться напрямую, а не через членство в группах. Подробнее.
  • Для сервера с поддержкой Arc убедитесь, что необходимо переназначить разрешения по мере их удаления при обновлении агента ARC.
  • Гибридная рабочая роль Runbook в настоящее время не поддерживается для Масштабируемые наборы виртуальных машин (VMSS).

Перенос существующей гибридной рабочей роли на основе агента в гибридную рабочую роль на основе расширения

Чтобы использовать преимущества гибридных рабочих ролей на основе расширений, необходимо перенести все существующие гибридные рабочие роли на основе агента в рабочие роли на основе расширений. Гибридный рабочий компьютер может совместно существовать на платформах агента (версии 1) и на основе расширений (V2). Установка на основе расширения не влияет на установку или управление рабочей ролью на основе агента.

Чтобы установить расширение гибридной рабочей роли на существующей гибридной рабочей роли на основе агента, убедитесь, что предварительные требования выполняются перед выполнением следующих действий.

  1. В разделе "Автоматизация процессов" выберите группы гибридных рабочих ролей, а затем выберите существующую гибридную рабочую группу, чтобы перейти на страницу "Гибридная рабочая группа ".

  2. В группе гибридных рабочих ролей выберите "Гибридные рабочие рабочие роли>+ Добавить", чтобы перейти на страницу "Добавить компьютеры в качестве гибридной рабочей роли".

  3. Установите флажок рядом с существующей рабочей ролью на основе агента (V1). Если вы не видите гибридную рабочую роль на основе агента, убедитесь, что на компьютере установлен агент подключенного компьютера Azure Arc. Чтобы установить AzureConnectedMachineAgentвиртуальные машины с поддержкой Arc, см. статью "Подключение гибридных компьютеров к Azure" с портал Azure серверов с поддержкой Arc или управление виртуальными машинами VMware vSphere с поддержкой VMware.

    Снимок экрана: добавление компьютеров в качестве гибридной рабочей роли.

  4. Нажмите кнопку "Добавить ", чтобы добавить компьютер в группу.

    В столбце "Платформа" показана одна и та же гибридная рабочая роль, что и агент на основе версии 1, и на основе расширений (версия 2). После того как вы уверены в использовании гибридной рабочей роли на основе расширения, вы можете удалить рабочую роль на основе агента.

    Снимок экрана: поле платформы с агентом или гибридным рабочим рабочая роль на основе расширений.

Для масштабируемой миграции нескольких гибридных рабочих ролей на основе агента можно также использовать другие каналы , такие как Bicep, шаблоны ARM, командлеты PowerShell, REST API и Azure CLI.

Управление расширением гибридной рабочей роли с помощью шаблонов Bicep и ARM, REST API, Azure CLI и PowerShell

Шаблон Bicep можно использовать для создания новой группы гибридных рабочих ролей, создания виртуальной машины Windows Azure и добавления ее в существующую гибридную рабочую группу. Дополнительные сведения о Bicep см. в этой статье.

Выполните указанные ниже действия в качестве примера:

  1. Создайте гибридную рабочую группу.
  2. Создайте виртуальную машину Azure или сервер с поддержкой Arc. Кроме того, можно использовать существующий сервер виртуальной машины Azure или сервера с поддержкой Arc.
  3. Подключите виртуальную машину Azure или сервер с поддержкой Arc к созданной выше гибридной рабочей группе.
  4. Создайте новый GUID и передайте его в качестве имени гибридной рабочей роли.
  5. Включите управляемое удостоверение, назначаемое системой, на виртуальной машине.
  6. Установите расширение гибридной рабочей роли на виртуальной машине.
  7. Чтобы убедиться, что расширение успешно установлено на виртуальной машине, в портал Azure перейдите на вкладку "Расширения виртуальной >машины" и проверьте состояние расширения гибридной рабочей роли, установленного на виртуальной машине.
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

Удаление гибридной рабочей роли на основе агента

  1. Откройте сеанс PowerShell в режиме администратора и выполните следующую команду:

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

  2. В разделе Автоматизация процессов выберите Группы гибридных рабочих ролей, а затем соответствующую группу, чтобы перейти на страницу Группа гибридных рабочих ролей.

  3. На странице Группа гибридных рабочих ролей выберите Гибридные рабочие роли.

  4. Установите флажок рядом с компьютерами, которые нужно удалить из группы гибридных рабочих ролей.

  5. Выберите "Удалить", чтобы удалить гибридную рабочую роль Windows на основе агента.

    Примечание.

    • После отключения Приватный канал в учетной записи службы автоматизации может потребоваться до 60 минут, чтобы удалить гибридную рабочую роль Runbook.
    • После удаления гибридной рабочей роли сертификат проверки подлинности гибридной рабочей роли на компьютере действителен в течение 45 минут.

Следующие шаги