Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье приведены решения распространенных проблем с управляемыми пулами DevOps.
Ошибки создания пула
| Код ошибки | Описание |
|---|---|
PoolProvisioningFailed |
Ошибка сбоя создания Pool из-за разрешений в организации Azure DevOps |
UnauthorizedAccessToVirtualNetwork |
Сбой создания пула из-за разрешений виртуальной сети |
Не удалось создать пул из-за разрешений организации Azure DevOps
Создание пула завершается ошибкой, аналогичной одному из следующих сообщений об ошибках.
Пользователь, вошедший в систему, не найден в организации 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>."
Чтобы решить эту проблему, выполните указанные ниже действия.
- Ваша организация Azure DevOps должна быть подключена к Microsoft Entra ID, и ваш пользователь, вошедший в Azure, должен быть членом (а не гостем) этого арендатора. См. предварительные требования Managed DevOps Pools: подключите свою организацию Azure DevOps к Microsoft Entra ID и проверьте членство.
У пользователя, вошедшего в систему, нет разрешений на управление в организации 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>."
Чтобы решить эту проблему, выполните указанные ниже действия.
- У пользователя, вошедшего в систему Azure, должны быть соответствующие разрешения Azure DevOps для создания пула. См. предварительные требования Azure DevOps — проверка разрешений Azure DevOps.
Сбой создания пула из-за разрешений виртуальной сети
Создание пула завершается ошибкой, аналогичной следующей UnauthorizedAccessToVirtualNetwork ошибке: 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.
Для разрешения этой проблемы:
- Для управляемых пулов DevOps требуется доступ к виртуальной сети. См. раздел «Предоставление доступа Читателя и Сетевого участника для субъекта-службы DevOpsInfrastructure».
- Подсеть виртуальной сети должна быть делегирована
Microsoft.DevOpsInfrastructure/pools. См. раздел Делегировать подсеть Microsoft.DevOpsInfrastructure/pools.
Задержки при запуске конвейера
При использовании управляемых пулов DevOps могут возникнуть ситуации, когда существует длинная задержка перед запуском конвейера после его активации. В этом разделе руководства по устранению неполадок описываются распространенные элементы, которые могут повлиять на производительность пулов. Дополнительные сведения см. в разделе "Управление затратами и производительностью".
- Проверка нехватки параллельных заданий
- Проверьте настройку максимального числа агентов
- Рассмотрите возможность предварительной подготовки агентов с помощью расписания резервного агента
- Рассмотрите возможность использования пулов с отслеживанием состояния с льготным периодом, чтобы агенты оставались в сети
- Проверка кодов ошибок времени ожидания
Проверка нехватки параллельных заданий
Агенты управляемых пулов DevOps считаются локальными агентами Azure DevOps и требуют выполнения локальных параллельных заданий. Например, если локальное число параллельных операций вашей организации равно 10, ваша организация может одновременно выполнять только 10 локальных заданий конвейера. Если более 10 потоков данных помещаются в очередь, выполнять одновременно можно только 10.
Проверьте количество локальных параллельных заданий, чтобы убедиться, что у вас достаточно емкости для удовлетворения потребностей параллельного конвейера рабочей нагрузки. Дополнительные сведения см. в разделе "Настройка и оплата параллельных заданий".
Проверьте настройку конфигурации максимального количества агентов
Максимальный параметр агентов настраивает максимальное количество запущенных агентов в управляемом пуле DevOps. Если параметр "Максимальное число агентов " равен 5, управляемые пулы DevOps могут выполнять не более пяти одновременных конвейеров. Если очереди более пяти конвейеров, дополнительные конвейеры не будут запускаться до тех пор, пока не будет доступен один из пяти доступных агентов.
Примечание.
Максимальное число агентов настраивает максимальное количество агентов, которые могут быть подготовлены одновременно, но число самостоятельно размещенных параллельных заданий вашей организации определяет количество заданий, которые могут выполняться одновременно. Убедитесь, что в организации достаточно локальных параллельных заданий, чтобы агенты могли выполнять задания. Дополнительные сведения см. в разделе Цены на параллельные задания в службах Azure DevOps.
Рассмотрите возможность предварительной подготовки агентов с помощью расписания резервного агента
Если режим резервного агента отключен, агенты управляемых пулов DevOps запускаются по запросу при очереди конвейера и, как правило, новый агент занимает всего несколько минут, иногда это может занять до 15 минут.
Если режим резервного агента включен, можно указать расписание и количество агентов, чтобы обеспечить готовность к выполнению требований рабочей нагрузки.
Дополнительные сведения см. в разделе "Управление затратами и производительностью" — предварительная подготовка с помощью резервных агентов.
Автоматический режим ожидания для новых пулов
Управляемые пулы DevOps используют исторические данные об использовании пула для создания прогнозов автоматического масштабирования в режиме ожидания . Новые пулы не имеют исторических данных, поэтому агенты могут создаваться по запросу. Чтобы повысить производительность, вы можете перейти в режим ожидания вручную в течение первого месяца и переключиться на автоматический режим ожидания после того, как управляемые пулы DevOps имели время наблюдать за использованием пула.
Проверьте процент резервного агента при использовании резервных агентов с несколькими образами
Если вы используете резервные агенты с несколькими изображениями, проверьте историю использования для каждого изображения и сравните её с настройкой процента резервного агента в ваших изображениях, чтобы убедиться, что ваш резервный коэффициент соответствует вашему использованию. Например, если у вас есть один образ Windows и один образ Ubuntu, и ваша рабочая нагрузка использует Windows 75% времени, убедитесь, что образ Windows настроен с процентом резерва агента, равным 75.
Рассмотрите возможность использования пулов с отслеживанием состояния с льготным периодом, чтобы удерживать агентов в сети.
Одним из вариантов повышения производительности агента без использования резервных агентов является использование агентов с сохранением состояния с коротким льготным периодом. Когда агент с сохранением состояния с льготным периодом завершает задание, он остается в сети в течение времени, указанного льготным периодом, и ожидает дополнительных работ. Если ваша рабочая нагрузка приходит порциями, вы можете настроить льготный период, который сохраняет агентов в сети, когда задания выполняются стабильно, а перезапускает их с нуля в более медленные периоды.
Дополнительные сведения см. в разделах «Резервные агенты» и состояние отслеживаемые пулы.
Проверьте коды ошибок тайм-аута
Если время выполнения назначения агента истекает, можно проверить код ошибки в разделе Коды ошибок на странице Обзор.
Сбой конвейера
Проверьте, было ли обновление изображения
Если ваши конвейеры обработки данных перестают работать после обновления образа, вы можете временно перенастроить их для использования предыдущей версии образа. Вы можете настроить выходящие из строя конвейеры для использования предыдущей версии образа для каждого конвейера отдельно или настроить предыдущую версию образа для всех конвейеров в управляемом пуле DevOps, использующих этот образ.
Чтобы понять, происходит ли сбой конвейеров из-за изменения версии образа, сравните версию образа сбойного запуска конвейера с версией образа из последнего успешного запуска конвейера.
Перейдите к конвейеру и просмотрите журнал выполнения конвейера для конвейера.
Просмотрите сведения о выполнении для двух запусков конвейера для сравнения и выберите задание конвейера для просмотра диагностической информации об этом задании. Если конвейер имеет несколько заданий, выберите задание, которое выполняется с помощью управляемого пула DevOps.
Выберите задание инициализации и получите версию образа из раздела "Текущая версия образа ".
Если версии образов отличаются между недавним неудачным запуском конвейера и предыдущим успешным запуском, то это может быть вызвано обновлением образа. У вас есть два варианта, чтобы временно вернуться к предыдущей версии образа, пока вы устраняете первопричину.
- Чтобы запустить только ошибочный конвейер с помощью предыдущей версии образа, добавьте условие к вашему конвейеру, чтобы указать предыдущую версию. Дополнительные сведения см. в разделе ImageVersionOverride.
- Чтобы обновить параметры пула так, чтобы все конвейеры, использующие образ, запускались с предыдущей версией, обновите параметры образа и укажите необходимую версию.
- Если вы используете образы Azure Pipelines, вы должны использовать шаблоны ARM или Azure CLI для указания версии, так как образы Azure Pipelines, настроенные с помощью портала Azure, всегда используют последнюю версию.
- Если вы используете образы избранного маркетплейса или образы Azure Compute Gallery, вы можете указать версию с помощью портала Azure, а также шаблонов ARM и Azure CLI.
Управляемые пулы DevOps сохраняют последние 20 образов, доступных для выбранных образов Marketplace и последних 10 образов, доступных для Azure Pipelines изображений. Предыдущие версии образов Галереи вычислительных ресурсов Azure поддерживаются владельцами этих галерей.