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

Статья
11/13/2024

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

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

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

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

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

Создание или перенос виртуальной сети и подсети
Делегировать подсеть в Microsoft.DevOpsInfrastructure/pools
Связывание подсети с управляемым пулом DevOps

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

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

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

Внимание

Управляемый пул DevOps и виртуальная сеть должны находиться в одном регионе, или при попытке создания пула или обновления конфигурации сети возникает ошибка. Virtual network MDPVN is in region eastus, but pool mdpnonprodsub is in region australiaeast. These must be in the same region.

Предоставление доступа читателю и участнику сети к субъекту-службе 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

Выберите элемент управления доступом (IAM) для виртуальной сети и нажмите кнопку "Проверить доступ".
Найдите DevOpsInfrastructure и выберите его.
Проверка доступа читателя . Убедитесь, что Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action назначены права доступа и Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write доступ. Ваша настраиваемая роль должна появиться здесь.
Если у DevOpsInfrastructure нет этих разрешений, добавьте их, выбрав элемент управления доступом (IAM) для виртуальной сети, и выберите "Предоставить доступ к этому ресурсу" и добавьте их.

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

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

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

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

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

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

Если вы создаете новый пул, перейдите на вкладку "Сеть". Чтобы обновить существующий пул, перейдите в раздел "Параметры сети" и выберите агенты>, внедренные в существующую виртуальную сеть, настройте.
Выберите подписку, виртуальная сеть и подсеть, в которые вы делегировались, и нажмите кнопку "ОК".Microsoft.DevOpsInfrastructure/pools

После завершения обновления сети созданный ресурс в пуле будет использовать делегированную подсеть.

Если вы используете шаблоны ARM, добавьте свойство, если оно еще не существует, а затем добавьте networkProfilesubnetId свойство под networkProfile идентификатор ресурса подсети.

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

Сеть настраивается с помощью networkProfile свойства в fabricProfile разделе при создании или обновлении пула. Для изолированной сети не упустите networkProfile свойство при создании пула.

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

В следующем примере показан networkProfile раздел файла fabric-profile.json .

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

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

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

Высокозащищенные конечные точки, от которые зависит наша служба:
- *.prod.manageddevops.microsoft.com — конечная точка управляемых пулов DevOps
- rmprodbuilds.azureedge.net — двоичные файлы рабочей роли
- vstsagentpackage.azureedge.net — расположение CDN агента Azure DevOps
- *.queue.core.windows.net — Рабочая очередь для взаимодействия со службой управляемых пулов DevOps
- server.pipe.aria.microsoft.com — общее решение телеметрии на стороне клиента (и используется расширением проверки пула агентов среди других)
- azure.archive.ubuntu.com — Подготовка компьютеров Linux — это HTTP, а не HTTPS
- www.microsoft.com — Подготовка компьютеров Linux
- security.ubuntu.com — Подготовка компьютеров Linux
Менее безопасные, более открытые конечные точки, от которые зависит наша служба:
- Требуется для нашей службы:
  - packages.microsoft.com — Подготовка компьютеров Linux
  - ppa.launchpad.net — подготовка компьютеров Ubuntu
  - dl.fedoraproject.org — подготовка определенных дистрибутивов Linux
- Требуется агенту Azure DevOps:
  - dev.azure.com
  - *.services.visualstudio.com
  - *.vsblob.visualstudio.com
  - *.vssps.visualstudio.com
  - *.visualstudio.com Эти записи являются минимальными обязательными доменами. Если у вас возникли проблемы, ознакомьтесь со списком разрешений Azure DevOps для полного списка необходимых доменов.
Связанные с Azure конечные точки: виртуальные машины Azure могут направлять трафик в определенные функции Azure через подсеть. Для этих запросов у вас есть возможность маршрутизации запросов через Azure напрямую или включить доступ через сеть.
1. Настройка трафика Azure для выполнения через конечные точки службы
  
  Маршрутизация трафика через Azure напрямую позволяет избежать дополнительной нагрузки на группы безопасности сети или брандмауэры и не требует добавления перечисленных далее доменов в список разрешенных.
  
  Например, использование функции диска данных будет предусматривать сетевые вызовы в Azure Storage. Включение конечной точки службы Microsoft.Storage в вашей сети будет направлять трафик непосредственно через Azure, избегая ваших сетевых правил и снижая нагрузку.
2. Если вы хотите избежать маршрутизации трафика через конечные точки службы, это домены, которые будут разрешены для определенных функций.
  - md-*.blob.storage.azure.net - Требуется настроить диск данных

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

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

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

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

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

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

См. также

Настройка параметров пула

Поделиться через