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


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

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

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

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

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

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

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

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

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

Подсеть должна иметь достаточно адресного пространства для размещения максимального размера пула, который вы хотите связать, включая 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

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

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

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

    Снимок экрана выбора учетной записи AzureDevOpsInfrastructure.

  3. Проверка доступа читателя . Убедитесь, что назначены права доступа для 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 в разделе "Делегирование подсети" и нажмите кнопку "Сохранить".

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

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

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

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

  1. Если вы создаете новый пул, перейдите на вкладку "Сеть". Чтобы обновить существующий пул, перейдите в раздел "Параметры сети" и выберите агенты>, внедренные в существующую виртуальную сеть, настройте.

    Снимок экрана: параметр настройки.

  2. Выберите Подписку, Виртуальную сеть и Подсеть, которые вы делегировали Microsoft.DevOpsInfrastructure/pools, и нажмите ОК.

    Снимок экрана: связывание подсети с пулом.

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

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

Если у вас есть системы в сети (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. Если вы хотите избежать маршрутизации трафика через конечные точки службы, вот домены, которые необходимо добавить в разрешенный список для определенных функций.

Если вы настроите конвейер 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: Настройка конфигурации агента конвейера", изменения не требуются.

См. также