Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se proporcionan soluciones a problemas comunes de grupos de DevOps administrados.
Errores de creación de grupos
| Código de error | Descripción |
|---|---|
PoolProvisioningFailed |
Error de creación del grupo debido a los permisos de la organización de Azure DevOps |
UnauthorizedAccessToVirtualNetwork |
Error de creación del grupo debido a permisos de red virtual |
Error de creación del grupo debido a los permisos de la organización de Azure DevOps
La creación del grupo produce un error similar a uno de los siguientes mensajes de error.
No se encontró el usuario que inició sesión en la organización de Azure DevOps.
Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, was not found in the Azure DevOps organization provided, <your Azure DevOps organization>."
Para resolver el problema:
- La organización de Azure DevOps debe estar conectada al identificador de Microsoft Entra y el usuario de Azure que ha iniciado sesión debe ser miembro (y no invitado) de este inquilino. Consulte Requisitos previos de los grupos de DevOps administrados: conexión de la organización de Azure DevOps al identificador de Microsoft Entra y comprobación de la pertenencia.
El usuario que ha iniciado sesión no tiene permisos de administración en la organización de Azure DevOps
Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, does not have Manage permissions in the Azure DevOps organization provided, <your Azure DevOps organization>."
Para resolver el problema:
- El usuario de Azure que ha iniciado sesión debe tener los permisos adecuados de Azure DevOps para crear un grupo. Consulte Requisitos previos de Azure DevOps: comprobación de los permisos de Azure DevOps.
Error de creación del grupo debido a permisos de red virtual
La creación del grupo produce un UnauthorizedAccessToVirtualNetwork error similar al siguiente: Validation failure "UnauthorizedAccessToVirtualNetwork": "DevOpsInfrastructure service principal does not have Read access to virtual network <your VNet> in resource group <your resource group>. Give Reader and Network Contributor access to DevOpsInfrastructure service principal and try again..
Para solucionar este problema:
- Los grupos de DevOps administrados requieren acceso a la red virtual. Consulte Concesión de acceso de lector y colaborador de red a la entidad de servicio DevOpsInfrastructure.
- La subred de red virtual debe delegarse en
Microsoft.DevOpsInfrastructure/pools. Consulte Delegación de la subred a Microsoft.DevOpsInfrastructure/pools.
Retrasos en el inicio de la canalización
Al usar pools administrados de DevOps, es posible que te encuentres con situaciones en las que haya un largo retraso antes de que una canalización empiece a ejecutarse después de que se desencadene. En esta sección de la guía de solución de problemas se describen los elementos comunes que pueden afectar al rendimiento de los grupos. Para obtener más información, consulte Administración del costo y el rendimiento.
- Comprobar si hay trabajos paralelos insuficientes
- Comprobación de la configuración máximo de agentes
- Considere la posibilidad de aprovisionar previamente los agentes mediante una programación de agentes en espera.
- Considere la posibilidad de usar grupos con estado con un período de gracia para mantener los agentes en línea
- Verificar códigos de error de tiempo de espera
Verificar si hay un número insuficiente de trabajos paralelos
Azure DevOps considera que los agentes de grupos de DevOps administrados son agentes autohospedados y requieren que se ejecuten trabajos paralelos autohospedados. Por ejemplo, si el recuento paralelo autohospedado de la organización es 10, la organización solo puede ejecutar 10 tareas de pipeline propias al mismo tiempo. Si hay más de 10 canalizaciones en cola, solo se pueden ejecutar 10 a la vez.
Compruebe el número de trabajos paralelos autohospedados para asegurarse de que tiene suficiente capacidad para satisfacer las necesidades de canalización simultáneas de la carga de trabajo. Para obtener más información, consulte Configuración y pago de trabajos paralelos.
Comprobar la configuración máxima de agentes
La opción Máximo de agentes configura el recuento máximo de agentes en ejecución en el grupo de DevOps administrado. Si el valor Máximo de agentes es 5, los grupos de DevOps administrados pueden ejecutar un máximo de cinco canalizaciones simultáneas. Si se ponen en cola más de cinco canalizaciones, las canalizaciones adicionales no se iniciarán hasta que uno de los cinco agentes disponibles esté disponible.
Nota:
El número máximo de agentes configura el número máximo de agentes que se pueden aprovisionar al mismo tiempo, pero el recuento de trabajos paralelos autohospedados de la organización especifica el número de trabajos que se pueden ejecutar simultáneamente. Asegúrese de que tiene suficientes trabajos paralelos autohospedados disponibles en su organización para permitir que los agentes ejecuten trabajos. Para más información, consulte Precios de trabajos paralelos de Azure DevOps Services.
Considere la posibilidad de aprovisionar previamente los agentes mediante una programación de agentes en espera.
Si el modo de agente en espera está deshabilitado, los agentes de grupos de DevOps administrados se inician a petición cuando se pone en cola una canalización y, aunque normalmente un agente nuevo tarda unos minutos en iniciarse, a veces puede tardar hasta 15 minutos.
Cuando el modo de agente en espera está habilitado, puede especificar una programación y un recuento de agentes para mantenerse listos para satisfacer las demandas de la carga de trabajo.
Para más información, consulte Administración del costo y el rendimiento: aprovisionamiento previo con agentes en espera.
Modo de espera automático para grupos nuevos
La administración de grupos de DevOps usa datos históricos de uso del grupo para ayudar a realizar predicciones de escalado automático del modo de espera . Los nuevos grupos no tienen datos históricos, por lo que es posible que los agentes se creen a petición. Para mejorar el rendimiento, puede cambiar al modo de espera manual durante el primer mes y cambiar al modo de espera automático una vez que los grupos de DevOps administrados han tenido tiempo para observar el uso del grupo.
Compruebe el porcentaje de agentes de reserva si está utilizando agentes de reserva con múltiples imágenes.
Si usa agentes en espera con varias imágenes, compruebe el historial de uso por imagen y compárelo con el porcentaje de agentes en espera de sus imágenes para asegurarse de que la proporción de agentes en espera se corresponde con su uso. Por ejemplo, si tiene una imagen de Windows y una imagen de Ubuntu, y la carga de trabajo usa Windows 75% del tiempo, asegúrese de que la imagen de Windows esté configurada con un porcentaje de agente en espera de 75.
Considere la posibilidad de usar grupos con estado con un período de gracia para mantener los agentes en línea
Una opción para mejorar el rendimiento de los agentes sin usar agentes en espera es emplear agentes con estado activo con un breve período de gracia. Cuando un agente con estado con un período de gracia completa un trabajo, permanece en línea durante el período de gracia especificado por el período de gracia y espera trabajos adicionales. Si la carga de trabajo entra en ráfagas, puede configurar un período de gracia que mantenga los agentes en línea cuando los trabajos estén estables y los inicie desde cero durante períodos más lentos.
Para obtener más información, consulte Agentes en espera y Pools con estado.
Verificar códigos de error de tiempo de espera
Si se agota el tiempo de espera de la asignación del agente, puede comprobar el código de error en la sección Códigos de error de la página Descripción general.
La canalización no se completa correctamente
Compruebe si ha habido una actualización de imagen.
Si las canalizaciones comienzan a fallar después de una actualización de imagen, puede configurar temporalmente las canalizaciones para que usen la versión anterior de la imagen. Puede configurar las canalizaciones con errores para usar la versión de imagen anterior por canalización, o bien puede configurar la versión de imagen anterior para todas las canalizaciones del grupo de DevOps administrado que use esa imagen.
Para ver si se produce un error en las canalizaciones debido a un cambio de versión de imagen, compare la versión de la imagen en una ejecución de canalización fallida con la versión de imagen de la última ejecución de canalización exitosa.
Ve a tu pipeline y revisa el historial de ejecución de tu pipeline.
Vea los detalles de ejecución de las dos ejecuciones de canalización que desea comparar, luego elija el trabajo de canalización para ver la información de diagnóstico acerca de ese trabajo. Si el pipeline tiene varios trabajos, elija el trabajo que se ejecuta mediante su DevOps Pool administrado.
Elija Initialize job y recupere la versión de la imagen de la sección Current image version.
Si las versiones de imagen son diferentes entre la ejecución reciente de la canalización que falló y la ejecución anterior que tuvo éxito, el error puede deberse a una actualización de imagen. Tiene dos opciones para revertir temporalmente a la versión de imagen anterior mientras soluciona la causa principal.
- Para ejecutar solo la canalización que falla mediante la versión de imagen anterior, agregue un
ImageVersionOverriderequisito a la canalización para especificar esta versión anterior. Para obtener más información, consulte ImageVersionOverride. - Para actualizar la configuración del grupo para que todas las canalizaciones que usen la imagen se ejecuten con la versión anterior, actualice la configuración de la imagen y especifique la versión deseada.
- Si usa imágenes de Azure Pipelines, debe usar plantillas de ARM o la CLI de Azure para especificar la versión, ya que las imágenes de Azure Pipelines configuradas mediante Azure Portal siempre usan la versión más reciente.
- Si usa imágenes de Marketplace seleccionadas o imágenes de Azure Compute Gallery, puede especificar la versión mediante Azure Portal, así como plantillas de ARM y la CLI de Azure.
Los grupos de DevOps administrados mantienen las últimas 20 imágenes disponibles para las imágenes de Marketplace seleccionadas y las últimas 10 imágenes disponibles para las imágenes de Azure Pipelines. Las versiones anteriores de las imágenes de Azure Compute Gallery las mantienen los propietarios de esas galerías de Cálculo de Azure.