Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo fornece soluções para problemas comuns de Pools de DevOps gerenciados.
Erros de criação de pool
| Código de erro | Descrição |
|---|---|
PoolProvisioningFailed |
Falha na criação do pool devido a permissões na organização do Azure DevOps |
UnauthorizedAccessToVirtualNetwork |
Falha na criação do pool devido a permissões de rede virtual |
Falha na criação do pool devido às permissões de organização do Azure DevOps
A criação do pool falha com um erro semelhante a uma das seguintes mensagens de erro.
O utilizador conectado não foi encontrado na organização 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 o problema:
- A sua organização Azure DevOps deve estar ligada ao Microsoft Entra ID e o seu utilizador Azure iniciado deve ser membro (e não convidado) deste tenant. Consulte os pré-requisitos Managed DevOps Pools - Ligue a sua organização de Azure DevOps à Microsoft Entra ID e verifique a filiação.
O utilizador com sessão iniciada não tem permissões de gestão na organização 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 o problema:
- O seu utilizador Azure com sessão deve ter as permissões adequadas do Azure DevOps para criar um pool. Veja Azure DevOps pré-requisitos - Verificar Azure DevOps permissões.
Falha na criação do pool devido a permissões de VNet
A criação do pool falha com um UnauthorizedAccessToVirtualNetwork erro semelhante ao seguinte: 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 resolver este problema:
- Os Pools de DevOps Gerenciados exigem acesso à sua rede virtual. Veja Conceder acesso de Leitor e Colaborador de Rede ao principal de serviço DevOpsInfrastructure.
- A sub-rede virtual precisa de ser delegada a
Microsoft.DevOpsInfrastructure/pools. Consulte Delegar a sub-rede a Microsoft.DevOpsInfrastructure/pools.
Atrasos no arranque do pipeline
Ao usar pools de DevOps gerenciados, você pode encontrar situações em que há um longo atraso antes que um pipeline comece a ser executado depois de ser acionado. Esta seção do guia de solução de problemas descreve itens comuns que podem afetar o desempenho de seus pools. Para obter mais informações, consulte Gerenciar custo e desempenho.
- Verificar se há trabalhos paralelos insuficientes
- Verifique a configuração máxima de agentes
- Considere o pré-provisionamento de agentes usando um cronograma de agentes de reserva
- Considere o uso de pools stateful com um período de carência para manter os agentes online
- Verifique os códigos de erro de timeout
Verificar a insuficiência de trabalhos paralelos
Os agentes de Pools DevOps geridos são considerados agentes auto-hospedados pelo Azure DevOps e requerem trabalhos paralelos auto-hospedados para serem executados. Por exemplo, se a quantidade de processos paralelos auto-hospedados da sua organização for 10, a sua organização poderá executar apenas 10 trabalhos de pipeline auto-hospedados simultaneamente. Se mais de 10 pipelines estiverem na fila, apenas 10 poderão ser executados de cada vez.
Verifique a contagem de trabalhos paralelos auto-hospedados para garantir que você tenha capacidade suficiente para atender às necessidades simultâneas de pipeline de sua carga de trabalho. Para obter mais informações, consulte Configurar e pagar por trabalhos paralelos.
Verifique a configuração relativa ao máximo de agentes
A configuração Máximo de agentes define a contagem máxima de agentes em execução no seu Pool de DevOps Gerenciado. Se a configuração Máximo de agentes for 5, os Pools de DevOps Geridos poderão executar no máximo cinco pipelines em simultâneo. Se mais de cinco pipelines estiverem na fila, os pipelines adicionais não serão iniciados até que um dos cinco agentes disponíveis esteja disponível.
Observação
Máximo de agentes configura o número máximo de agentes que podem ser provisionados simultaneamente, mas o número de trabalhos paralelos autogeridos da sua organização especifica o número de trabalhos que podem ser executados simultaneamente. Certifique-se de ter trabalhos paralelos auto-hospedados suficientes disponíveis em sua organização para permitir que seus agentes executem trabalhos. Para mais informações, consulte preçário de trabalhos paralelos do Azure DevOps.
Considere pré-provisionar agentes usando uma agenda de agente em prontidão
Se o modo de agente em espera estiver desabilitado, os agentes de Pools de DevOps Gerenciados serão iniciados sob demanda quando um pipeline estiver na fila e, embora normalmente um novo agente leve apenas alguns minutos para iniciar, às vezes pode levar até 15 minutos.
Quando o modo de agente em espera está habilitado, você pode especificar uma programação e uma contagem de agentes para se manter pronto para atender às demandas de sua carga de trabalho.
Para obter mais informações, consulte Gerenciar custo e desempenho - Pré-provisionamento com agentes em espera.
Modo de espera automático para novas piscinas
Gestão de pools de DevOps utiliza dados históricos de utilização dos pools para ajudar a fazer as suas previsões de escalonamento automático no modo de espera. Novos pools não têm dados históricos, portanto, os agentes podem ser criados sob demanda. Para melhorar o desempenho, você pode alternar para o modo de espera manual no primeiro mês e alternar para o modo de espera automática assim que os Pools de DevOps Gerenciados tiverem tempo de observar o uso do pool.
Verifique a porcentagem do agente em espera se estiver usando agentes em espera com várias imagens
Se você usa agentes em espera com várias imagens, verifique o histórico de uso por imagem e compare-o com a configuração de porcentagem do agente em espera de suas imagens para garantir que sua taxa de espera corresponda ao seu uso. Por exemplo, se tiver uma imagem Windows e uma imagem Ubuntu, e a sua carga de trabalho usar Windows 75% do tempo, certifique-se de que a sua imagem de Windows está configurada com uma percentagem de agente de espera de 75.
Considere o uso de pools com estado com um período de carência para manter os agentes on-line
Uma opção para melhorar o desempenho do agente sem usar agentes em espera é usar agentes com estado de estado com um curto período de carência. Quando um agente stateful com um período de carência conclui um trabalho, ele permanece online pelo período especificado pelo período de carência e aguarda por trabalhos adicionais. Se a sua carga de trabalho é intermitente, pode-se configurar um período de carência que mantém os agentes online quando os trabalhos estão estáveis e os inicia desde o início durante períodos mais lentos.
Para obter mais informações, consulte Agentes Standby e Pools com Estado.
Verifique os códigos de erro de tempo limite
Se a atribuição do agente expirar, você poderá verificar o código de erro na seção Códigos de erro da página Visão geral .
O pipeline não é concluído com êxito
Verifique se houve uma atualização de imagem
Se os seus pipelines começarem a falhar após uma atualização de imagem, pode configurá-los temporariamente para usar a versão anterior da imagem. Você pode configurar seus pipelines com falhas para usar a versão de imagem anterior para cada pipeline, ou pode configurar a versão de imagem anterior para todos os pipelines no seu Pool de DevOps Gerido que usam essa imagem.
Para ver se os seus pipelines estão falhando devido a uma alteração na versão da imagem, compare a versão da imagem de uma execução de pipeline falhada com a versão da imagem da última execução de pipeline bem-sucedida.
Vá para o seu pipeline e revise o histórico de execução do pipeline para o seu pipeline.
Exiba os detalhes de execução das duas execuções de pipeline que você deseja comparar e escolha o trabalho de pipeline para exibir informações de diagnóstico sobre esse trabalho. Se o seu pipeline tiver várias tarefas, escolha a tarefa que é executada usando o seu Grupo de DevOps Gerenciado.
Escolha Inicializar trabalho e recupera a versão da imagem na secção Versão da imagem atual.
Se as versões da imagem forem diferentes entre a recente execução de pipeline com falha e a execução bem-sucedida anterior, a falha pode ser causada por uma atualização de imagem. Você tem duas opções para reverter temporariamente para a versão anterior da imagem enquanto soluciona a causa raiz.
- Para executar apenas o pipeline com falha usando a versão de imagem anterior, adicione uma
ImageVersionOverridedemanda ao pipeline para especificar a versão anterior. Para obter mais informações, consulte ImageVersionOverride. - Para atualizar as configurações do pool para que todos os pipelines que usam a imagem sejam executados usando a versão anterior, atualize as configurações de imagem e especifique a versão desejada.
- Se estiver a usar imagens Azure Pipelines, deve usar modelos ARM ou CLI do Azure para especificar a versão, uma vez que Azure Pipelines imagens configuradas usando o portal Azure usam sempre a versão mais recente.
- Se estiveres a usar imagens Selected marketplace ou imagens Azure Compute Gallery, podes especificar a versão usando o portal Azure, bem como templates ARM e CLI do Azure.
O Managed DevOps Pools mantém as últimas 20 imagens disponíveis para imagens selecionadas do marketplace e as últimas 10 imagens disponíveis para imagens do Azure Pipelines. Versões anteriores das imagens da Galeria de Computação do Azure são mantidas pelos proprietários dessas Galerias de Computação do Azure.