Compartilhar via

Configurar a rede de pools de DevOps gerenciados

Você pode configurar agentes de Pools de DevOps Gerenciados para serem executados em uma rede virtual isolada ou em uma rede virtual existente. Este artigo descreve como configurar seu pool para executar agentes em sua rede virtual.

Escolha seu tipo de rede

Os Pools de DevOps Gerenciados dão suporte a dois tipos de configurações de rede:

  • Rede virtual isolada: cada pool obtém sua própria rede virtual isolada criada e gerenciada pelo serviço DevOps Pools Gerenciado.
  • Agentes injetados na rede virtual existente: você pode trazer sua própria rede virtual e sub-rede. Todas as máquinas virtuais criadas para o pool usarão essa sub-rede e nenhum outro recurso poderá usar a sub-rede. Talvez você queira adicionar agentes de Pools de DevOps Gerenciados à sua própria rede virtual para cenários como:
    • Seus agentes de CI/CD (integração contínua e entrega contínua) precisam acessar recursos que só estão disponíveis na rede da sua empresa por meio de um serviço como o Azure ExpressRoute.
    • Seus agentes de CI/CD precisam acessar recursos que estão isolados em pontos de extremidade privados.
    • Você deseja isolar a infraestrutura de CI/CD na rede trazendo sua própria rede virtual com regras de firewall específicas da empresa.
    • Quaisquer outros casos de uso exclusivos que não podem ser alcançados por recursos de rede padrão de Pools de DevOps Gerenciados.

Rede virtual isolada

Por padrão, todos os pools usam uma rede virtual fornecida pela Microsoft, que restringe todo o tráfego de entrada e tem as seguintes opções de configuração de tráfego de saída.

  1. A conectividade de acesso de saída padrão é o padrão atual, que permite todo o tráfego de saída usando um endereço IP fornecido pela Microsoft. O acesso de saída padrão para VMs no Azure está programado para ser desativado. Quando o acesso de saída padrão for desativado, os pools serão configurados com um endereço IP estático por padrão.
  2. Em vez de usar o acesso de saída padrão, você pode configurar o pool para usar até 16 endereços IP de saída estáticos. Os Pools de DevOps gerenciados criarão um gateway NAT na mesma região que o pool para fornecer os endereços IP. Essa configuração permite que você permita a lista de endereços IP específicos em serviços externos que seus pipelines precisam acessar.
    • O gateway NAT gera custos adicionais no Azure. Você pode modelar quanto custará usando a calculadora de custos do Azure. Para obter mais informações, consulte os preços do Gateway nat do Azure.

Importante

Se você modificar a contagem de endereços IP estáticos após a criação do pool, os endereços IP estarão sujeitos a alterações e você precisará obter os novos endereços IP e atualizar sua lista de permissões em serviços externos após a conclusão da operação de atualização.

Para definir configurações de endereço IP ao criar um pool, vá para a guia Rede. Para atualizar um pool existente, vá para aRede de>.

Escolha Nenhum para Rotear por meio de endereços IP públicos a fim de usar o acesso de saída padrão.

Escolha os IPs fornecidos pela Microsoft para configurar endereços IP de saída estáticos e especifique o número de endereços IP estáticos que você deseja usar. Os Pools de DevOps Gerenciados criam um gateway NAT para você e gerenciam os endereços IP.

Captura de tela das configurações de endereço IP.

Observação

Há um problema conhecido: se o pool estiver configurado com uma identidade gerenciada, as chamadas à API não retornarão a ipAddresses propriedade, a menos que a entidade de serviço DevOpsInfrastructure receba a função operador de identidade gerenciada na identidade gerenciada. Para obter etapas detalhadas, consulte Atribuir funções do Azure usando o portal do Azure.

A concessão dessa função não é necessária para que os endereços IP estáticos sejam funcionais. Sem essa atribuição de função, você ainda pode encontrar os endereços IP atribuídos exibindo-os na página Rede no portal do Azure.

Agentes injetados na rede virtual existente

Você pode configurar os agentes do pool para usar sua rede virtual usando as seguintes etapas:

  1. Crie ou configure sua rede virtual e subrede.
  2. Delegar a subrede para Microsoft.DevOpsInfrastructure/pools.
  3. Associe a sub-rede ao pool.

As etapas anteriores delegam a sub-rede para acesso exclusivo pelo pool. Outros pools ou recursos não podem usar a sub-rede.

Um pool pode usar várias sub-redes para conectar vários pools à mesma rede virtual. Cada sub-rede é delegada e associada ao seu próprio pool.

Criar ou trazer sua rede virtual e sub-rede

A sub-rede deve ter espaço de endereço suficiente para acomodar o tamanho máximo do pool que você deseja associar (incluindo os cinco endereços IP que o Azure reserva na sub-rede).

Caso utilize o ExpressRoute, precisará permitir gravações removendo ou alterando temporariamente o bloqueio de gerenciamento no grupo de recursos.

Importante

O pool e a rede virtual devem estar na mesma região. Caso contrário, você receberá um erro semelhante ao seguinte ao tentar criar o pool ou atualizar a configuração de rede: "A rede virtual MDPVN está na região eastus, mas o pool mdpnonprodsub está na região australiaeast. Elas devem estar na mesma região."

Conceder acesso de Leitor e Colaborador de Rede à entidade de serviço DevOpsInfrastructure

Verifique se o DevOpsInfrastructure principal tem Reader e Network Contributor acesso à rede virtual.

Em vez de usar funções internas, você pode criar uma função personalizada que tenha as seguintes permissões:

  • 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

Crie uma função personalizada para o acesso do Link de Associação de Serviço. Você pode criar uma função de exemplo no nível do grupo de recursos ou da assinatura na guia Controle de Acesso , conforme mostrado no exemplo a seguir.

Captura de tela que mostra permissões de função personalizadas.

Verificar o acesso principal para DevOpsInfrastructure

  1. Selecione controle de acesso (IAM) para a rede virtual e, em seguida, selecione Verificar acesso.

    Captura de tela que mostra as permissões de rede virtual para delegação de sub-rede.

  2. Pesquise e selecione DevOpsInfrastructure.

    Captura de tela que mostra como selecionar o principal AzureDevOpsInfrastructure.

  3. Verifique se você tem acesso ao nível Leitor. Verifique se o acesso de Microsoft.Network/virtualNetworks/subnets/join/action, Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action e Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write está atribuído. Sua função personalizada deve aparecer aqui.

    Captura de tela que mostra as permissões de rede virtual.

  4. Se o principal DevOpsInfrastructure não tiver essas permissões, adicione-as. Selecione O controle de acesso (IAM) para a rede virtual e, em seguida, selecione Conceder acesso a esse recurso.

Delegar a sub-rede a Microsoft.DevOpsInfrastructure/pools

No portal, abra as propriedades da Sub-rede e selecione Microsoft.DevOpsInfrastructure/pools em Delegação de Sub-rede. Clique em Salvar.

Captura de tela que mostra como configurar a delegação de sub-rede.

Esse processo delega a sub-rede para acesso exclusivo do pool. Outros pools ou recursos não podem usar a sub-rede. Para conectar vários pools à mesma rede virtual, você deve usar várias sub-redes. Cada sub-rede deve ser delegada e associada ao seu próprio pool. Você pode encontrar mais informações sobre a delegação de sub-rede nesta visão geral sobre a delegação de sub-rede.

Depois de delegar a sub-rede a Microsoft.DevOpsInfrastructure/pools, você poderá atualizar o pool para usar a sub-rede.

Associe a sub-rede ao seu pool

  1. Para criar um novo pool, vá para a guia Rede. Para atualizar um pool existente, vá para Configurações>Rede, e então selecione Agentes injetados na rede virtual existente>Configurar.

    Captura de tela que mostra a opção configurar.

  2. Selecione os valores de Assinatura, Rede Virtual e Sub-rede que você delegou a Microsoft.DevOpsInfrastructure/pools, e então selecione Ok.

    Captura de tela que mostra como associar a sub-rede ao pool.

    Após a conclusão da atualização de rede, o recurso recém-criado no pool usará a sub-rede delegada.

Importante

Não coloque um bloqueio de exclusão na rede virtual ao atualizar seus pools. Durante uma operação de atualização do pool, os Pools de DevOps Gerenciados criam um link de associação de serviço na sub-rede. Se uma atualização falhar, os Pools de DevOps Gerenciados tentarão limpar o link de associação de serviço, mas se houver um bloqueio Delete, receberá um erro InUseSubnetCannotBeDeleted. Os Pools de DevOps Gerenciados não podem excluir o link de associação de serviço, o que deixa a sub-rede em um estado bloqueado (não é possível excluir). Para resolver o problema, remova o bloqueio Delete e repita a operação de atualização.

Para obter mais informações, consulte Itens a serem considerados antes de aplicar bloqueios aos recursos do Azure.

Restringir a conectividade de saída

Se você tiver sistemas em vigor em sua rede (por exemplo, grupos de segurança de rede ou firewalls) que restrinjam a conectividade de saída, será necessário adicionar determinados pontos de extremidade a uma lista de permissão de forma a oferecer suporte total aos Pools de DevOps Gerenciados. Esses pontos de extremidade são divididos em pontos de extremidade globalmente necessários (necessários em qualquer computador usando pools de DevOps gerenciados) e pontos de extremidade necessários para determinados cenários. Todos os endereços de rede são HTTPS, a menos que indicado de outra forma.

Pontos de extremidade necessários para iniciar pools de DevOps gerenciados

Se você não adicionar esses pontos de extremidade a uma lista de permissões, os computadores não poderão ficar online como parte do serviço DevOps Pools Gerenciado e você não poderá executar pipelines no pool:

  • *.prod.manageddevops.microsoft.com: ponto de extremidade de Pools de DevOps gerenciados usado para se comunicar com o serviço de Pools de DevOps Gerenciados.
  • rmprodbuilds.azureedge.net: usado para baixar os binários de trabalho e scripts de inicialização do Managed DevOps Pools. A parte do agente dos binários de trabalho rm-agent.prod.manageddevops.microsoft.com é baixada de rm-agent.prod.manageddevops.microsoft.com (anteriormente baixada de *.prod.manageddevops.microsoft.com), que é coberta pela entrada necessária anterior.
  • *.queue.core.windows.net: fila de trabalho para comunicação com o serviço Managed DevOps Pools.

Endereços de destino necessários para conectar ao Azure DevOps

Se você não adicionar esses pontos de extremidade a uma lista de autorização, as máquinas poderão ficar online e até mesmo entrar em um estado alocado, mas poderão falhar ao se comunicar com o Azure DevOps. Isto ocorre porque o agente de tarefas do Azure DevOps Services ou não consegue se conectar ou não consegue iniciar.

  • download.agent.dev.azure.com: A localização da CDN (rede de distribuição de conteúdo) do agente do Azure DevOps, usada para baixar o agente do Azure DevOps (anteriormente vstsagentpackage.azureedge.net; para mais informações, veja CDN do Edgio para Azure DevOps está sendo desativada).
  • dev.azure.com: necessário para lidar com a comunicação com o Azure DevOps.

Pontos de extremidade necessários para máquinas Linux

Esses endpoints são necessários para iniciar máquinas Ubuntu, mas não são precisos se um pool estiver usando apenas Windows. Quando você configura o agente de tarefas do Azure DevOps, os pacotes necessários são adicionados e um apt-get comando é executado. Esse processo falhará se os pontos de extremidade a seguir não forem adicionados a uma lista de permissões.

  • azure.archive.ubuntu.com: provisionando computadores Linux. Esse ponto de extremidade é HTTP (porta 80), não HTTPS (porta 443).
  • www.microsoft.com: provisionando computadores Linux.
  • security.ubuntu.com: provisionando computadores Linux.
  • packages.microsoft.com: provisionando computadores Linux.
  • ppa.launchpad.net: provisionando algumas distribuições específicas do Linux.
  • dl.fedoraproject.org: provisionando determinadas distribuições de Linux.

Endereços de endpoint necessários para alguns recursos do Azure DevOps

Esses endereços de endpoints opcionais são necessários para que recursos específicos do Azure DevOps funcionem em seus pipelines. No conjunto a seguir, o curinga pode ser substituído pela organização específica do Azure DevOps que hospeda seu pipeline. Por exemplo, se sua organização for nomeada contoso, você poderá usar contoso.services.visualstudio.com em vez de *.services.visualstudio.com.

  • *.services.visualstudio.com
  • *.vsblob.visualstudio.com: usado para carregar e consumir artefatos.
  • *.vssps.visualstudio.com: usado para autenticação com o Azure DevOps para determinados recursos.
  • *.visualstudio.com

Observação

As entradas anteriores são os domínios mínimos necessários. Se você tiver problemas, consulte a lista completa de domínios necessários em endereços IP permitidos e URLs de domínio do Azure DevOps.

As VMs (máquinas virtuais) do Azure podem rotear o tráfego para determinados recursos do Azure por meio de sua sub-rede. Para essas solicitações, você pode rotear solicitações diretamente por meio do Azure ou habilitar o acesso por meio de sua rede.

  1. Configurar o tráfego através dos endpoints de serviço do Azure:

    Você pode rotear o tráfego diretamente por meio do Azure para evitar adicionar taxa de transferência aos seus grupos de segurança de rede ou firewalls. Você não precisa adicionar os domínios listados na opção a seguir a uma lista de permissões.

    Por exemplo, você pode usar o recurso de disco de dados para envolver chamadas de rede para o Armazenamento do Azure. Quando você habilita o ponto de extremidade do serviço Microsoft.Storage em sua rede, o tráfego é roteado diretamente pelo Azure, o que evita suas regras de rede e reduz a carga.

  2. Para evitar o roteamento de tráfego por meio de pontos de extremidade de serviço, adicione o md-*.blob.storage.azure.net domínio à sua lista de permissões. Esse domínio é necessário para configurar um disco de dados.

IPs de entrega da CDN do Akamai

Em 1º de maio de 2025, os ativos da CDN do Azure DevOps passaram para uma solução atendida pelo Akamai e pelo Azure Front Door. Verifique se sua rede tem acesso de saída aos intervalos de IP do Akamai. Para obter mais informações, consulte:

Se você configurar o pipeline do Azure DevOps para ser executado dentro de um contêiner, também precisará adicionar a origem da imagem de contêiner (Docker ou Registro de Contêiner do Azure) a uma lista de permissões.

Validar a conexão do endpoint

Confirme se você pode usar uma sub-rede com Pools de DevOps Gerenciados executando o script a seguir em um recurso nessa sub-rede. Esta etapa ajudará você a validar que o fluxo de rede está configurado para alcançar todos esses endpoints disponíveis e o plano de controle do DevOps Gerenciado.

Importante

Você deve executar esse script em um recurso em sua sub-rede (como uma VM ou contêiner) para validar se o caminho de rede está aberto dessa sub-rede para os pontos de extremidade necessários.

Para executar o script com o PowerShell Core ou o PowerShell 5 ou posterior, salve o script a seguir como ValidateMDPEndpoints.ps1. Execute o seguinte comando do 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 $_ }
}

Configurar o agente do Azure DevOps para executar atrás de um proxy

Se você configurou um serviço proxy em sua imagem e deseja que as cargas de trabalho executadas no pool executem por trás desse proxy, adicione as seguintes variáveis de ambiente à sua imagem:

  • VSTS_AGENT_INPUT_PROXYURL: A URL do proxy configurado para operar por trás.
  • VSTS_AGENT_INPUT_PROXYUSERNAME: o nome de usuário necessário para usar o proxy.
  • VSTS_AGENT_INPUT_PROXYPASSWORD: a senha para usar o proxy.

Para o Windows, essas variáveis de ambiente devem ser variáveis de ambiente do sistema. Para Linux, essas variáveis devem estar no /etc/environment arquivo. Se você definir essas variáveis de sistema incorretamente ou sem um serviço proxy configurado na imagem, o provisionamento de novos agentes falhará com problemas de conectividade de rede.

Se você estiver migrando de agentes de Conjuntos de Dimensionamento de Máquinas Virtuais do Azure e já estiver usando as variáveis de ambiente proxy em sua imagem, não precisará fazer nenhuma alteração. Esse processo é descrito nos agentes do Conjunto de Dimensionamento de Máquinas Virtuais do Azure: Personalizar a configuração do agente de pipeline.

Conteúdo relacionado

  • Last updated on