Compartir a través de


Solución de problemas de grupos de DevOps administrados

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:

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:

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:

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.

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.

  1. Ve a tu pipeline y revisa el historial de ejecución de tu pipeline.

    Captura de pantalla de las ejecuciones de canalización.

  2. 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.

    Captura de pantalla de los detalles sobre la ejecución del pipeline.

  3. Elija Initialize job y recupere la versión de la imagen de la sección Current image version.

    Captura de pantalla de la versión de imagen de ejecución de la canalización.

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.

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.

Consulte también