Compartilhar via


Configurar a rede de pools de DevOps gerenciados

Os agentes gerenciados do DevOps Pools podem ser configurados para serem executados em uma rede virtual isolada ou em uma rede virtual existente. Este artigo descreve como configurar seu Pool de DevOps Gerenciado para executar agentes em sua rede virtual.

Adicionando agentes à sua própria rede virtual

Talvez você queira adicionar agentes de Pools de DevOps Gerenciados à sua própria rede virtual para cenários como:

  • Seus agentes de CI/CD precisam acessar recursos que estão disponíveis apenas na rede da sua empresa por meio de um serviço como o Express Route
  • Seus agentes de CI/CD precisam acessar recursos isolados em pontos de extremidade privados
  • Você deseja isolar sua infraestrutura de CI/CD trazendo sua própria VNet com regras de firewall específicas da empresa
  • Quaisquer outros casos de uso exclusivos que não possam ser alcançados por recursos relacionados à rede do Pools de DevOps gerenciados prontos para uso

Você pode adicionar os agentes do pool à sua rede virtual usando as etapas a seguir.

  1. Criar ou trazer sua rede virtual e sub-rede
  2. Delegar a sub-rede a Microsoft.DevOpsInfrastructure/pools
  3. Associar a sub-rede ao seu Pool de DevOps Gerenciado

As etapas anteriores delegam a sub-rede para acesso exclusivo pelo pool e a sub-rede não pode ser usada por outros pools ou recursos. Para conectar vários pools à mesma rede virtual, várias sub-redes podem ser usadas, cada uma 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 do pool que você deseja associar (inclua as 5 reservas de endereço IP do Azure na sub-rede). Se você estiver usando o Express Route, precisará descartar ou alterar temporariamente o bloqueio de gerenciamento no grupo de recursos para permitir gravações.

Importante

O Pool de DevOps Gerenciado e a rede virtual devem estar na mesma região ou você receberá um erro semelhante ao seguinte ao tentar criar o pool ou atualizar a configuração de rede. Virtual network MDPVN is in region eastus, but pool mdpnonprodsub is in region australiaeast. These must be in the same region.

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

Verifique se a entidade de segurança DevOpsInfrastructure tem o seguinte acesso na rede virtual:

  • Reader e Network Contributor
  • Ou adicione a seguinte permissão a uma função personalizada:
    • 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 ao Link de Associação de Serviço. Uma função de exemplo pode ser criada no nível do grupo de recursos ou da assinatura na guia Controle de Acesso, conforme mostrado no exemplo a seguir.

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

Para verificar o acesso da entidade de segurança do DevOpsInfrastructure

  1. Escolha Access control (IAM) (Controle de acesso) para a rede virtual e escolha Check access (Verificar acesso).

    Captura de tela das permissões de VNet para delegação de SubNet.

  2. Pesquise DevOpsInfrastructure e selecione-o.

    Captura de tela da seleção da entidade de segurança AzureDevOpsInfrastructure.

  3. Verifique o acesso do Leitor . Verifique se o e Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write o Microsoft.Network/virtualNetworks/subnets/join/actionacesso está atribuído. Sua função personalizada deve aparecer aqui.

    Captura de tela das permissões de VNet.

  4. Se o DevOpsInfrastructure não tiver essas permissões, adicione-as escolhendo Controle de acesso (IAM) para a rede virtual e escolha Conceder acesso a esse recurso e adicione-as.

Delegar a sub-rede a Microsoft.DevOpsInfrastructure/pools

A sub-rede precisa ser delegada Microsoft.DevOpsInfrastructure/pools ao a ser usado. Abra as propriedades da sub-rede no Portal e selecione Microsoft.DevOpsInfrastructure/pools na seção Delegação de Sub-rede e escolha Salvar.

Captura de tela da configuração da delegação de sub-rede.

Isso delega a sub-rede para acesso exclusivo ao pool e a sub-rede não pode ser usada por outros pools ou recursos. Para conectar vários pools à mesma rede virtual, várias sub-redes devem ser usadas, cada uma delegada e associada ao seu próprio pool. Mais informações sobre delegação de sub-rede podem ser encontradas aqui.

Depois que a sub-rede é delegada ao Microsoft.DevOpsInfrastructure/pools, o pool pode ser atualizado para usar a sub-rede.

Associar a sub-rede ao seu Pool de DevOps Gerenciado

  1. Se você estiver criando um novo pool, vá para a guia Rede. Para atualizar um pool existente, acesse Configurações>Rede e escolha Agentes injetados na rede virtual existente, Configurar.

    Captura de tela da opção de configuração.

  2. Escolha a Assinatura, a Rede Virtual e a Sub-rede que você delegou e Microsoft.DevOpsInfrastructure/poolsescolha Ok.

    Captura de tela da associação da sub-rede ao pool.

Depois que a atualização de rede for concluída, o recurso recém-criado no pool usará a sub-rede delegada.

Restringindo a conectividade de saída

Se você tiver sistemas em vigor em sua rede (NSG, Firewall etc.) que restringem a conectividade de saída, será necessário garantir que os seguintes domínios possam ser acessados, caso contrário, seu Pool de DevOps Gerenciado não funcionará. Todos eles são HTTPS, salvo indicação em contrário.

  • Endpoints altamente seguros dos quais nosso serviço depende:
    • *.prod.manageddevops.microsoft.com - Endpoint de DevOps Pools gerenciados
    • rmprodbuilds.azureedge.net - Binários de trabalho
    • vstsagentpackage.azureedge.net - Local da CDN do agente do Azure DevOps
    • *.queue.core.windows.net - Fila de trabalho para comunicação com o serviço Managed DevOps Pools
    • server.pipe.aria.microsoft.com - Solução de telemetria comum do lado do cliente (e usada pela extensão de validação do pool de agentes, entre outras)
    • azure.archive.ubuntu.com - Provisionamento de máquinas Linux - isso é HTTP, não HTTPS
    • www.microsoft.com - Provisionamento de máquinas Linux
  • Endpoints menos seguros e mais abertos dos quais nosso serviço depende:
    • Necessário para o nosso serviço:
      • packages.microsoft.com - Provisionamento de máquinas Linux
      • ppa.launchpad.net - Provisionamento de máquinas Ubuntu
      • dl.fedoraproject.org - Provisionamento de certas distribuições Linux
    • Necessário para o agente do Azure DevOps:
      • dev.azure.com
      • *.services.visualstudio.com
      • *.vsblob.visualstudio.com
      • *.vssps.visualstudio.com
      • *.visualstudio.com Essas entradas são os domínios mínimos necessários. Se você tiver problemas, consulte Lista de permissões do Azure DevOps para obter a lista completa de domínios necessários.

Se você configurar o Azure DevOps Pipeline para ser executado dentro de um contêiner, também precisará colocar na lista de permissões a origem da imagem de contêiner (Docker ou ACR).

Configurar o Azure DevOps Agent para ser executado por trás de um proxy

Se você configurou um serviço de proxy em sua imagem e deseja que suas cargas de trabalho em execução no pool de DevOps gerenciado sejam executadas por trás desse proxy, você deve adicionar as seguintes variáveis de ambiente em sua imagem.

  • VSTS_AGENT_INPUT_PROXYURL - A URL do proxy configurado para ser executado atrá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 Windows, essas variáveis de ambiente devem ser variáveis de ambiente do sistema e, para Linux, essas variáveis devem estar no arquivo /etc/environment . Definir essas variáveis do sistema incorretamente ou sem um serviço de proxy configurado na imagem faz com que o provisionamento de novos agentes falhe com problemas de conectividade de rede.

Se você estiver migrando de agentes do Conjunto de Dimensionamento de Máquinas Virtuais do Azure e já estiver usando as variáveis de ambiente de proxy em sua imagem, conforme descrito em Agentes do Conjunto de Dimensionamento de Máquinas Virtuais do Azure – Personalizando a configuração do agente de pipeline, nenhuma alteração deverá ser necessária.

Confira também