Configuración de redes de grupos de DevOps administrados

Artículo
11/14/2024

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 aislados a los puntos de conexión privados.
Quiere aislar la infraestructura de CI/CD mediante la incorporación de 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 las redes de grupos de DevOps administrados integradas

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.

Concesión de acceso de lector y colaborador de red a la entidad de servicio DevOpsInfrastructure

Asegúrese de que la entidad de seguridad DevOpsInfrastructure tiene el acceso siguiente 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 de 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 de la entidad de seguridad 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 Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action se ha asignado y Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write el acceso. 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 debe delegarse en el Microsoft.DevOpsInfrastructure/pools objeto que se va a 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 delegada 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 delegue en Microsoft.DevOpsInfrastructure/poolsy elija Aceptar.

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 si aún no existe, 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": {
        ...
        "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 networkProfile sección 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, debe asegurarse de que se puede acceder a los siguientes dominios; de lo contrario, el grupo de DevOps administrado no será funcional. Todos ellos son HTTPS, a menos que se indique lo contrario.

Puntos de conexión muy seguros de los que depende nuestro servicio:
- *.prod.manageddevops.microsoft.com - Punto de conexión de grupos de DevOps administrado
- rmprodbuilds.azureedge.net - Archivos binarios de trabajo
- vstsagentpackage.azureedge.net - Ubicación de cdn del agente de Azure DevOps
- *.queue.core.windows.net - Cola de trabajo para comunicarse con el servicio Grupos de DevOps administrados
- server.pipe.aria.microsoft.com - Solución de telemetría común del lado cliente (y usada por la extensión validación del grupo de agentes entre otros)
- azure.archive.ubuntu.com - Aprovisionamiento de máquinas Linux: es HTTP, no HTTPS
- www.microsoft.com - Aprovisionamiento de máquinas Linux
Menos seguros y más puntos de conexión abiertos de los que depende nuestro servicio:
- Requerido por nuestro servicio:
  - packages.microsoft.com - Aprovisionamiento de máquinas Linux
  - ppa.launchpad.net - Aprovisionamiento de máquinas Ubuntu
  - dl.fedoraproject.org - Aprovisionamiento de determinadas distribuciones de Linux
- Necesario para el agente de Azure DevOps:
  - dev.azure.com
  - *.services.visualstudio.com
  - *.vsblob.visualstudio.com
  - *.vssps.visualstudio.com
  - *.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.

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 la imagen y quiere que las cargas de trabajo que se ejecuten en el grupo de DevOps administrados se ejecuten detrás de este proxy, debe agregar las siguientes variables de entorno en la 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 que se va a 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 estas variables del sistema incorrectamente o sin un servicio proxy configurado en la imagen, el aprovisionamiento de nuevos agentes produce un error en el aprovisionamiento de nuevos agentes con problemas de conectividad de red.

Si va a migrar desde agentes de conjuntos de escalado de máquinas virtuales de Azure y ya usa las variables de entorno de proxy en la imagen, como se describe en Agentes de conjuntos de escalado de máquinas virtuales de Azure: Personalización de la configuración del agente de canalización, no es necesario realizar ningún cambio.

Consulte también

Configuración de los valores del grupo

Compartir vía