Configuración de redes de grupos de DevOps administrados

2025-06-18

Los agentes de grupos de DevOps administrados se pueden configurar para ejecutarse en una red virtual aislada o en una red virtual existente. En este artículo se describe cómo configurar el grupo de DevOps administrado para ejecutar agentes en la red virtual.

Adición de agentes a su propia red virtual

Es posible que quiera agregar agentes de grupos de DevOps administrados a su propia red virtual para escenarios como:

Los agentes de CI/CD necesitan acceder a los recursos que solo están disponibles en la red de la empresa a través de un servicio como ExpressRoute.
Los agentes de CI/CD deben acceder a los recursos restringidos a puntos de conexión privados.
Quiere aislar en red su infraestructura de CI/CD usando su propia red virtual con reglas de firewall específicas de la empresa.
Cualquier otro caso de uso único que no se pueda lograr mediante características relacionadas con redes de grupos de DevOps gestionados preconfiguradas

Puede agregar los agentes del grupo a la red virtual mediante los pasos siguientes.

Creación o incorporación de la red virtual y la subred
Delegar la subred en Microsoft.DevOpsInfrastructure/pools
Asociación de la subred con el grupo de DevOps administrado

Los pasos anteriores delegan la subred para el acceso exclusivo por parte del grupo y la subred no se puede usar en otros grupos o recursos. Para conectar varios grupos a la misma red virtual, se pueden usar varias subredes, cada delegado y asociado a su propio grupo.

Creación o incorporación de la red virtual y la subred

La subred debe tener suficiente espacio de direcciones para dar cabida al tamaño máximo del grupo que desea asociar (incluya las 5 direcciones IP que Azure reserva en la subred). Si usa ExpressRoute, debe quitar o cambiar temporalmente el bloqueo de administración en el grupo de recursos para permitir escrituras.

Importante

El grupo de DevOps administrado y la red virtual deben estar en la misma región o obtendrá un error similar al siguiente al intentar crear el grupo o actualizar la configuración de red. Virtual network MDPVN is in region eastus, but pool mdpnonprodsub is in region australiaeast. These must be in the same region.

Conceder a Reader y Network Contributor acceso a la entidad de servicio DevOpsInfrastructure

Asegúrese de que el principal DevOpsInfrastructure tiene el siguiente acceso en la red virtual.

Reader y Network Contributor
O bien, agregue el siguiente permiso a un rol personalizado:
- 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

Cree un rol personalizado para el acceso al Vínculo de Asociación de Servicio. Se puede crear un rol de ejemplo en el nivel de grupo de recursos o suscripción en la pestaña Control de acceso, como se muestra en el ejemplo siguiente.

Captura de pantalla de los permisos de rol personalizados.

Para comprobar el acceso del principal de DevOpsInfrastructure

Elija Control de acceso (IAM) para la red virtual y elija Comprobar acceso.
Busque DevOpsInfrastructure y selecciónelo.
Compruebe el acceso del lector . Compruebe que se ha asignado el acceso a Microsoft.Network/virtualNetworks/subnets/join/action, Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action y Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write. El rol personalizado debería aparecer aquí.
Si DevOpsInfrastructure no tiene esos permisos, agréguelos seleccionando Control de acceso (IAM) para la red virtual y elija Conceder acceso a este recurso y agréguelos.

Delegar la subred en Microsoft.DevOpsInfrastructure/pools

La subred necesita ser delegada al Microsoft.DevOpsInfrastructure/pools para que se pueda usar. Abra las propiedades de subred en el portal y seleccione Microsoft.DevOpsInfrastructure/pools en la sección Delegación de subred y elija Guardar.

Captura de pantalla de la configuración de la delegación de subred.

De este modo, se delega la subred para el acceso exclusivo para el grupo y otros grupos o recursos no pueden usar la subred. Para conectar varios grupos a la misma red virtual, se deben usar varias subredes, cada delegado y asociado a su propio grupo. Puede encontrar más información sobre la delegación de subred aquí.

Una vez que se delega la subred en Microsoft.DevOpsInfrastructure/pools, el grupo se puede actualizar para usar la subred.

Asociación de la subred con el grupo de DevOps administrado

Si va a crear un grupo, vaya a la pestaña Redes . Para actualizar un grupo existente, vaya a Configuración>Redes y elija Agentes insertados en la red virtual existente, Configurar.
Elija la suscripción, la red virtual y la subred que delegó en Microsoft.DevOpsInfrastructure/pools, y elija Ok.

Una vez completada la actualización de red, el recurso recién creado en el grupo usará la subred delegada.

Si usa plantillas de ARM, agregue una networkProfile propiedad en la fabricProfile sección y, a continuación, agregue una subnetId propiedad en networkProfile con el identificador de recurso de la subred.

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

Las redes se configuran mediante la networkProfile propiedad de la fabricProfile sección al crear o actualizar un grupo. Para una red aislada, omita la networkProfile propiedad al crear un grupo.

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

En el ejemplo siguiente se muestra la sección networkProfile del archivo 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"
    }
  }
}

Restricción de la conectividad saliente

Si tiene sistemas en su red (NSG, Firewall, etc.) que restringen la conectividad saliente, es necesario incluir determinados puntos de conexión en la lista para admitir completamente los grupos de DevOps administrados. Estos puntos de conexión se dividen en puntos de conexión necesarios globalmente (necesarios en cualquier máquina de grupos de DevOps administrados) y puntos de conexión necesarios para determinados escenarios. Todos los puntos de conexión son HTTPS, a menos que se indique lo contrario.

Puntos de conexión necesarios para el inicio del grupo de DevOps administrado: sin permitir incluir estos puntos de conexión, las máquinas no se conectarán como parte de nuestro servicio y no podrá ejecutar canalizaciones en el grupo de DevOps administrado.
- *.prod.manageddevops.microsoft.com - Punto de conexión de grupos de DevOps administrado, que se usa para comunicarse con el servicio Grupos de DevOps administrados.
- rmprodbuilds.azureedge.net : se usa para descargar los archivos binarios de trabajo y los scripts de inicio de los grupos de DevOps administrados. (La parte del agente de los binarios de trabajo se descarga desde rm-agent.prod.manageddevops.microsoft.com (anteriormente se descargaba de agent.prod.manageddevops.microsoft.com), lo cual está cubierto por la entrada requerida *.prod.manageddevops.microsoft.com anterior).
- *.queue.core.windows.net - Cola de trabajo para la comunicación con el servicio de Grupos Administrados de DevOps.
Puntos de conexión necesarios para conectarse a Azure DevOps: sin permitir incluir estos puntos de conexión, las máquinas pueden estar en línea e incluso ir a un estado "asignado", pero no podrán comunicarse con ADO, ya que el agente de tareas de VSTS no se puede conectar o no se puede iniciar.
- download.agent.dev.azure.com - Ubicación de CDN del agente de Azure DevOps, utilizada para descargar el agente de Azure DevOps (conocido anteriormente como vstsagentpackage.azureedge.net). Para más información, consulte El CDN de Edgio para Azure DevOps está siendo retirado.
- dev.azure.com - Necesario para controlar la comunicación con Azure DevOps
- Preparación de máquinas Linux: estos puntos de conexión son necesarios para poner en marcha máquinas Ubuntu, pero no son necesarias si un grupo solo usa Windows. Como parte de la configuración del agente de tareas de Azure DevOps, se agregan algunos paquetes necesarios y se ejecuta un comando de apt-get, lo cual producirá un error sin que estén incluidos en la lista blanca de permitidos.
  - azure.archive.ubuntu.com - Aprovisionamiento de máquinas Linux: este es HTTP (puerto 80), no HTTPS (puerto 443)
  - www.microsoft.com - Aprovisionamiento de máquinas Linux
  - security.ubuntu.com - Aprovisionamiento de máquinas Linux
  - packages.microsoft.com - Aprovisionamiento de máquinas Linux
  - ppa.launchpad.net - Aprovisionamiento de algunas distribuciones específicas de Linux
  - dl.fedoraproject.org - Aprovisionamiento de determinadas distribuciones de Linux
Opcional, pero necesario para que las características específicas de Azure DevOps funcionen en las canalizaciones. En el siguiente conjunto, el carácter comodín se puede reemplazar por la organización específica de Azure DevOps que hospeda la canalización. Por ejemplo, si su organización se denomina contoso, puede usar contoso.services.visualstudio.com en lugar de *.services.visualstudio.com. Estas entradas son los dominios mínimos necesarios. Si tiene algún problema, consulte Lista de permitidos de Azure DevOps para obtener la lista completa de dominios necesarios.
- *.services.visualstudio.com
- *.vsblob.visualstudio.com - Se usa para artefactos, tanto para subir como para el consumo de.
- *.vssps.visualstudio.com : se usa para la autenticación con Azure DevOps para determinadas características.
- *.visualstudio.com
Puntos de conexión relacionados con Azure: las máquinas virtuales de Azure pueden enrutar el tráfico a determinadas características de Azure a través de la subred. Para estas solicitudes, tiene la opción de enrutar las solicitudes a través de Azure directamente o habilitar el acceso a través de la red.
1. Configuración del tráfico de Azure para funcionar a través de puntos de conexión de servicio
  
  El enrutamiento del tráfico a través de Azure evita agregar carga a los NSG o firewalls y no requiere que incluya en la lista blanca los dominios mencionados en la opción siguiente.
  
  Por ejemplo, el uso de la característica disco de datos implicará llamadas de red a Azure Storage. Habilitar el punto de conexión de servicio de Microsoft.Storage en la red enrutará el tráfico directamente a través de Azure, evitando las reglas de red y reduciendo la carga.
2. Si desea evitar el enrutamiento del tráfico a través de puntos de conexión de servicio, estos son los dominios que incluir en la lista de permitidos para funcionalidades específicas.
  - md-*.blob.storage.azure.net: necesario para configurar un disco de datos
Direcciones IP de entrega de Akamai CDN: A partir del 1 de mayo de 2025, los recursos de Azure DevOps CDN volverán a una solución atendida por Akamai y Azure Front Door. Asegúrese de que la red tiene acceso saliente a los intervalos IP de Akamai. Para obtener más información, consulte:

Si configura la canalización de Azure DevOps para que se ejecute dentro de un contenedor, también debe permitir la lista del origen de la imagen de contenedor (Docker o ACR).

Configuración del agente de Azure DevOps para que se ejecute detrás de un proxy

Si configuró un servicio de proxy en su imagen y quiere que las cargas de trabajo que se estén ejecutando en su grupo de DevOps gestionado se ejecuten detrás de este proxy, debe agregar las siguientes variables de entorno a su imagen.

VSTS_AGENT_INPUT_PROXYURL : la dirección URL del proxy configurado que se va a ejecutar detrás.
VSTS_AGENT_INPUT_PROXYUSERNAME : el nombre de usuario necesario para usar el proxy.
VSTS_AGENT_INPUT_PROXYPASSWORD - La contraseña para usar el proxy.

Para Windows, estas variables de entorno deben ser variables de entorno del sistema y, para Linux, estas variables deben estar en el archivo /etc/environment . Al establecer incorrectamente estas variables del sistema o sin tener un servicio proxy configurado en la imagen, se produce un fallo en el aprovisionamiento de nuevos agentes debido a problemas de conectividad de red.

Si está migrando desde Azure Virtual Machine Scale Set Agents y ya utiliza las variables de entorno de proxy en su imagen, como se describe en Azure Virtual Machine Scale Set Agents - Personalización de la configuración del agente de canalización, no se debería requerir ningún cambio.

Consulte también

Configurar la configuración del grupo