Настройка сети управляемых пулов DevOps

Агенты Управляемых пулов DevOps можно настроить для запуска в изолированной виртуальной сети или в существующей виртуальной сети. В этой статье описывается настройка пула для запуска агентов в виртуальной сети.

Добавление агентов в собственную виртуальную сеть

Возможно, потребуется добавить агенты из управляемых пулов DevOps в собственную виртуальную сеть для таких сценариев, как:

• Агенты непрерывной интеграции и непрерывной доставки (CI/CD) должны получать доступ к ресурсам, доступным только в корпоративной сети через службу, например Azure ExpressRoute.
• Агенты CI/CD должны получить доступ к ресурсам, доступным только через частные конечные точки.
• Вы хотите изолировать инфраструктуру CI/CD, используя свою виртуальную сеть с корпоративными правилами брандмауэра.
• Любые другие уникальные варианты использования, которые невозможно достичь с помощью встроенных сетевых функций управляемых пулов DevOps.

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

1. Создайте или подключите вашу виртуальную сеть и подсеть.
2. Делегировать подсеть в Microsoft.DevOpsInfrastructure/pools.
3. Свяжите подсеть с пулом.

Предыдущие шаги делегируют подсеть для исключительного доступа пула. Другие пулы или ресурсы не могут использовать подсеть.

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

Создание или перенос виртуальной сети и подсети

Подсеть должна иметь достаточно адресного пространства для размещения максимального размера пула, который требуется связать (включая пять IP-адресов, которые Azure резервирует в подсети).

Если вы используете ExpressRoute, необходимо разрешить запись, временно снимая или изменяя блокировку управления в группе ресурсов.

Предоставление доступа читателю и участнику сети к субъекту-службе DevOpsInfrastructure

Убедитесь, что субъект DevOpsInfrastructure имеет Reader и Network Contributor доступ к виртуальной сети.

Вместо использования встроенных ролей можно создать пользовательскую роль, которая имеет следующие разрешения:

• Microsoft.Network/virtualNetworks/*/read
• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action
• Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write
• Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/delete

Создайте настраиваемую роль для доступа к каналу связи службы. Вы можете создать пример роли на уровне группы ресурсов или подписки на вкладке "Управление доступом ", как показано в следующем примере.

Проверка доступа субъекта для DevOpsInfrastructure

1. Выберите элемент управления доступом (IAM) для виртуальной сети, а затем нажмите кнопку "Проверить доступ".

   

2. Найдите и выберите DevOpsInfrastructure.

   

3. Убедитесь, что у вас есть доступ на уровне Reader. Убедитесь, что доступ к Microsoft.Network/virtualNetworks/subnets/join/action, Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action и Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write назначен. Ваша настраиваемая роль должна появиться здесь.

   

4. Если у принципала DevOpsInfrastructure нет этих разрешений, добавьте их. Выберите элемент управления доступом (IAM) для виртуальной сети, а затем выберите "Предоставить доступ к этому ресурсу".

Делегировать подсеть в Microsoft.DevOpsInfrastructure/pools

На портале откройте свойства подсети и выберите Microsoft.DevOpsInfrastructure/pools пункт "Делегирование подсети". Нажмите кнопку "Сохранить".

Этот процесс делегирует подсеть для монопольного доступа к пулу. Другие пулы или ресурсы не могут использовать подсеть. Чтобы подключить несколько пулов к одной виртуальной сети, необходимо использовать несколько подсетей. Каждая подсеть должна быть делегирована и связана с собственным пулом. Дополнительные сведения о делегировании подсети см. в этом обзоре делегирования подсети.

После делегирования подсети Microsoft.DevOpsInfrastructure/poolsможно обновить пул, чтобы использовать подсеть.

Связывание подсети с пулом

{
    "name": "MyManagedDevOpsPool",
    "type": "Microsoft.DevOpsInfrastructure/pools",
    "apiVersion": "2025-01-21",
    "location": "eastus",
    "properties": {
        ...
        "fabricProfile": {
            "networkProfile": {
              "subnetId":"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet",
            }
        }
    }
}

az mdp pool create \
   --fabric-profile fabric-profile.json
   # other parameters omitted for space

{
  "vmss": {
    "sku": {...},
    "images": [...],
    "osProfile": {...},
    "storageProfile": {...},
    "networkProfile": {
        "subnetId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet"
    }
  }
}

resource managedDevOpsPools 'Microsoft.DevOpsInfrastructure/pools@2025-01-21' = {
  name: 'MyManagedDevOpsPool'
  location: 'eastus'
  properties: {
    ...
    fabricProfile: {
      networkProfile: {
        subnetId: '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet'
      }
  }
}

Ограничение исходящего подключения

Если у вас есть системы в сети (например, группы безопасности сети или брандмауэры), ограничивающие исходящее подключение, необходимо добавить определенные конечные точки в список разрешений для полной поддержки управляемых пулов DevOps. Эти конечные точки делятся на глобальные обязательные конечные точки (необходимые для любого компьютера с помощью управляемых пулов DevOps) и конечных точек, необходимых для определенных сценариев. Все конечные точки — HTTPS, если иное не указано.

Обязательные конечные точки для запуска управляемых пулов DevOps

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

• *.prod.manageddevops.microsoft.com: конечная точка управляемых пулов DevOps, используемая для взаимодействия со службой управляемых пулов DevOps.
• rmprodbuilds.azureedge.net: используется для скачивания двоичных файлов рабочих управляемых пулов средств DevOps и скриптов запуска. Часть двоичных файлов агента рабочего процесса загружается из rm-agent.prod.manageddevops.microsoft.com (ранее загружалась из agent.prod.manageddevops.microsoft.com), что охвачено предыдущей обязательной записью *.prod.manageddevops.microsoft.com.
• *.queue.core.windows.net: рабочая очередь для взаимодействия со службой управляемых пулов DevOps.

Необходимые конечные точки для подключения к Azure DevOps

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

• download.agent.dev.azure.com: расположение сети доставки содержимого агента Azure DevOps (CDN), используемое для скачивания агента Azure DevOps (ранее назывался vstsagentpackage.azureedge.net, подробнее см. в статье Edgio CDN для Azure DevOps).
• dev.azure.com: требуется для обработки взаимодействия с Azure DevOps.

Обязательные конечные точки для компьютеров Linux

Эти конечные точки требуются для запуска машин Ubuntu, но не нужны, если пул использует только Windows. При настройке агента задач Azure DevOps добавляются необходимые пакеты и команда apt-get выполняется. Этот процесс завершается ошибкой, если следующие конечные точки не добавляются в список разрешений.

• azure.archive.ubuntu.com: конфигурирование машин Linux. Эта конечная точка — HTTP (порт 80), а не HTTPS (порт 443).
• www.microsoft.com: развертывание систем Linux.
• security.ubuntu.com: подготовка и настройка машин Linux.
• packages.microsoft.com: развертывание компьютеров Linux.
• ppa.launchpad.net: подготовка некоторых конкретных дистрибутивов Linux.
• dl.fedoraproject.org: поставление определенных дистрибутивов Linux.

Обязательные конечные точки для некоторых функций Azure DevOps

Эти необязательные конечные точки необходимы для конкретных функций Azure DevOps для работы с конвейерами. В следующем наборе подстановочный знак можно заменить конкретной организацией Azure DevOps, в которой размещен ваш конвейер. Например, если ваша организация называется contoso, вы можете использовать contoso.services.visualstudio.com вместо *.services.visualstudio.com.

• *.services.visualstudio.com
• *.vsblob.visualstudio.com: используется для отправки и использования артефактов.
• *.vssps.visualstudio.com: используется для проверки подлинности с помощью Azure DevOps для определенных функций.
• *.visualstudio.com

Конечные точки, связанные с Azure

Виртуальные машины Azure могут направлять трафик к определенным функциям Azure через подсеть. Для этих запросов можно направлять запросы непосредственно через Azure или включить доступ через сеть.

1. Настройте трафик Azure для выполнения через конечные точки службы:

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

   Например, можно использовать функцию диска данных для привлечения сетевых вызовов к службе хранилища Azure. Если вы включите конечную точку службы Microsoft.Storage в сети, трафик направляется непосредственно через Azure, что позволяет избежать правил сети и снижает нагрузку.

2. Чтобы избежать маршрутизации трафика через конечные точки службы, добавьте md-*.blob.storage.azure.net домен в список разрешений. Этот домен необходим для настройки диска данных.

IP-адреса доставки akamai CDN

1 мая 2025 г. ресурсы Azure DevOps CDN перешли на решение, обслуживаемое Akamai и Azure Front Door. Убедитесь, что сеть имеет исходящий доступ к диапазонам IP-адресов Akamai. Дополнительные сведения можно найти здесь

• Изменение URL-адреса домена CDN для агентов в конвейерах
• Часто задаваемые вопросы о выводе из эксплуатации Azure CDN от Edgio
• Akamai TechDocs: список управления доступом к IP-адресам источника

Если вы настроите конвейер Azure DevOps для запуска внутри контейнера, необходимо также добавить источник образа контейнера (Docker или Реестра контейнеров Azure) в список разрешений.

Проверка подключения конечной точки

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

Чтобы запустить скрипт с помощью PowerShell Core или PowerShell 5 или более поздней версии, сохраните следующий сценарий как ValidateMDPEndpoints.ps1. Выполните следующую команду PowerShell: .\ValidateMDPEndpoints.ps1 -organization "<your-organization>"

# ValidateMDPEndpoints.ps1
param (
    [string]$organization
)
$azureDevOpsUris = @(
    "https://dev.azure.com",
    "https://vssps.dev.azure.com",
    "https://vsrm.dev.azure.com",
    "https://management.azure.com",
    "https://login.microsoftonline.com",
    "https://graph.microsoft.com",
    "https://aadcdn.msftauth.net",
    "https://${organization}.visualstudio.com",
    "https://${organization}.vsrm.visualstudio.com",
    "https://${organization}.vstmr.visualstudio.com",
    "https://${organization}.pkgs.visualstudio.com",
    "https://${organization}.vssps.visualstudio.com",
    "https://download.agent.dev.azure.com",
    "download.agent.dev.azure.com"
)
$managedDevOpsPoolsControlPlaneUris = @(
    # List of agent queue endpoints - maps to *.queue.core.windows.net
    "https://rmprodaedefaultcq.queue.core.windows.net",
    "https://rmprodbrsdefaultcq.queue.core.windows.net",
    "https://rmprodcncdefaultcq.queue.core.windows.net",
    "https://rmprodcusdefaultcq.queue.core.windows.net",
    "https://rmprodeus2defaultcq.queue.core.windows.net",
    "https://rmprodgwcdefaultcq.queue.core.windows.net",
    "https://rmprodincdefaultcq.queue.core.windows.net",
    "https://rmprodneudefaultcq.queue.core.windows.net",
    "https://rmprodseadefaultcq.queue.core.windows.net",
    "https://rmprodszndefaultcq.queue.core.windows.net",
    "https://rmproduksdefaultcq.queue.core.windows.net",
    "https://rmprodwus3defaultcq.queue.core.windows.net",
    # CDN for downloading the Managed DevOps Pools agent - maps to *.prod.managedevops.microsoft.com
    "rm-agent.prod.manageddevops.microsoft.com"
    # List of control plane endpoints - maps to *.manageddevops.microsoft.com
    "default.ae.prod.manageddevops.microsoft.com",
    "default.brs.prod.manageddevops.microsoft.com",
    "default.cnc.prod.manageddevops.microsoft.com",
    "default.cus.prod.manageddevops.microsoft.com",
    "default.eus2.prod.manageddevops.microsoft.com",
    "default.gwc.prod.manageddevops.microsoft.com",
    "default.inc.prod.manageddevops.microsoft.com",
    "default.neu.prod.manageddevops.microsoft.com",
    "default.sea.prod.manageddevops.microsoft.com",
    "default.szn.prod.manageddevops.microsoft.com",
    "default.uks.prod.manageddevops.microsoft.com",
    "default.wus3.prod.manageddevops.microsoft.com"
)
$unreachableUris = @()
foreach ($uri in $azureDevOpsUris) {
    try {
        $hostName = ($uri -replace "^https?://", "") -replace "/.*", ""
        $connection = Test-NetConnection -ComputerName $hostName -Port 443 -WarningAction SilentlyContinue
        if (-not $connection.TcpTestSucceeded) {
            $unreachableUris += $uri
        }
    } catch {
        $unreachableUris += $uri
    }
}
if ($unreachableUris.Count -eq 0) {
    Write-Output "All Azure DevOps endpoints are reachable."
} else {
    Write-Output "The following Azure DevOps endpoints could not be reached:"
    $unreachableUris | ForEach-Object { Write-Output $_ }
}
foreach ($uri in $managedDevOpsPoolsControlPlaneUris) {
    try {
        $hostName = ($uri -replace "^https?://", "") -replace "/.*", ""
        $connection = Test-NetConnection -ComputerName $hostName -Port 443 -WarningAction SilentlyContinue

        if (-not $connection.TcpTestSucceeded) {
            $unreachableUris += $uri
        }
    } catch {
        $unreachableUris += $uri
    }
}
if ($unreachableUris.Count -eq 0) {
    Write-Output "All Azure Managed DevOps Pools endpoints are reachable."
} else {
    Write-Output "The following Managed DevOps Pools endpoints could not be reached:"
    $unreachableUris | ForEach-Object { Write-Output $_ }
}

Настройка агента Azure DevOps для запуска за прокси-сервером

Если вы настроили прокси-службу на образе и хотите, чтобы рабочие нагрузки, выполняемые в пуле, выполнялись за этим прокси-сервером, необходимо добавить в образ следующие переменные среды:

• VSTS_AGENT_INPUT_PROXYURL: URL настроенного прокси-сервера для работы за ним.
• VSTS_AGENT_INPUT_PROXYUSERNAME: имя пользователя, необходимое для использования прокси-сервера.
• VSTS_AGENT_INPUT_PROXYPASSWORD: пароль для использования прокси-сервера.

Для Windows эти переменные среды должны быть системными переменными среды. Для Linux эти переменные должны находиться в /etc/environment файле. Если эти системные переменные заданы неправильно или без настроенной прокси-службы в системном образе, подготовка новых агентов завершается неудачей из-за проблем с сетевым подключением.

Если вы переносите агенты масштабируемых наборов виртуальных машин Azure и уже используете переменные среды прокси-сервера на образе, вам не нужно вносить никаких изменений. Этот процесс описан в агентах масштабируемого набора виртуальных машин Azure: настройка конфигурации агента конвейера.

Связанный контент

• Настройка параметров пула
• Разрешенные IP-адреса и URL-адреса домена Azure DevOps