この記事では、マネージド DevOps プールに関する一般的な問題の解決策について説明します。
プールの作成エラー
| エラー コード | 説明 |
|---|---|
PoolProvisioningFailed |
Azure DevOps 組織のアクセス許可によるプールの作成エラー |
UnauthorizedAccessToVirtualNetwork |
VNet のアクセス許可によるプールの作成エラー |
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 ユーザーはこのテナントのメンバー (ゲストではない) である必要があります。 管理された DevOps プールの前提条件 - 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 のアクセス許可の確認を参照してください。
VNet のアクセス許可によるプールの作成エラー
プールの作成が失敗し、次のような 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 サービス プリンシパルへの Grant Reader および Network Contributor アクセスを参照してください。
- 仮想ネットワーク サブネットを
Microsoft.DevOpsInfrastructure/poolsに委任する必要があります。 「 サブネットを Microsoft.DevOpsInfrastructure/pools に委任するを参照してください。
パイプラインの起動の遅延
Managed DevOps プールを使用すると、パイプラインがトリガーされた後にパイプラインの実行が開始されるまでに長い遅延が発生する場合があります。 トラブルシューティング ガイドのこのセクションでは、プールのパフォーマンスに影響を与える可能性がある一般的な項目について説明します。 詳細については、「コストとパフォーマンスのの管理」を参照してください。
- 十分でない並列ジョブがあるかを確認する
- エージェントの最大構成 を確認する
-
スタンバイ エージェント スケジュールを使用してエージェントを事前プロビジョニングすることを検討
- 新規プール向けの自動スタンバイモード
- 複数のイメージ でスタンバイエージェントを使用している場合は、スタンバイエージェントの割合を確認します
- エージェントをオンライン状態に保つために、猶予期間があるステートフル プールの使用を検討
- タイムアウト エラー コードを確認する
並列ジョブが不足していることを確認する
マネージド DevOps プール エージェントは、Azure DevOps によってセルフホステッド エージェントと見なされ、実行するにはセルフホステッド並列ジョブが必要です。 たとえば、組織のセルフホステッド並列数が 10 の場合、組織は 10 個のセルフホステッド パイプライン ジョブのみを同時に実行できます。 キューに登録されているパイプラインが 10 個を超える場合、一度に実行できるパイプラインは 10 個のみです。
セルフホステッド並列ジョブ数を確認して、ワークロードの同時実行パイプラインのニーズを満たすのに十分な容量があることを確認します。 詳細については、「並列ジョブの構成と支払い」を参照してください。
エージェントの最大構成を確認する
最大エージェント の設定は、Managed DevOps プールで実行中のエージェント数の上限を構成します。 最大エージェント 設定が 5 の場合、Managed DevOps プールは最大 5 つの同時実行パイプラインを実行できます。 5 つ以上のパイプラインがキューに登録されている場合、使用可能な 5 つのエージェントのいずれかが使用可能になるまで、追加のパイプラインは開始されません。
手記
最大エージェント は、同時にプロビジョニングできるエージェントの最大数を構成しますが、組織のセルフホステッド並列ジョブ数は、同時に実行できるジョブの数を指定します。 エージェントがジョブを実行できるように、組織で十分な自己ホスト型の並列ジョブを持っていることを確認します。 詳細については、Azure DevOps Services 並列ジョブの価格に関するページを参照してください。
エージェントの事前の設定を、スタンバイエージェントのスケジュールを利用して検討する
スタンバイ エージェント モード 無効にすると、パイプラインがキューに登録されたときにマネージド DevOps プール エージェントがオンデマンドで開始されます。通常、新しいエージェントの起動には数分しかかかりませんが、最大で 15 分かかる場合があります。
スタンバイ エージェント モード が有効になっている場合は、スケジュールとエージェントの数を指定して、ワークロードの要求を満たす準備を整えることができます。
詳細については、「コストとパフォーマンスの管理 - スタンバイ エージェントを使用した事前プロビジョニング」を参照してください。
新しいプールの自動スタンバイ モード
DevOps プールの管理では、プールの使用状況の履歴データを使用して、自動スタンバイ モード スケーリング予測を行うのに役立ちます。 新しいプールには履歴データがないため、エージェントはオンデマンドで作成される可能性があります。 パフォーマンスを向上させるために、最初の 1 か月間は手動スタンバイ モードに切り替え、マネージド DevOps プールでプールの使用状況を監視する時間が経過したら、自動スタンバイ モードに切り替えることができます。
複数のイメージを持つスタンバイ エージェントを使用している場合は、スタンバイ エージェントのパーセンテージを確認してください。
複数のイメージでスタンバイ エージェントを使用する場合は、イメージごとの使用状況の履歴を確認し、イメージの スタンバイ エージェントの割合 設定と比較して、スタンバイ率が使用状況と一致していることを確認します。 たとえば、1 つの Windows イメージと 1 つの Ubuntu イメージがあり、ワークロードで Windows 75% を使用している場合は、Windows イメージがスタンバイ エージェントの割合 75 で構成されていることを確認します。
エージェントをオンラインに保つために、猶予期間のあるステートフル プールの使用を検討する
スタンバイ エージェントを使用せずにエージェントのパフォーマンスを向上させるオプションの 1 つは、短い猶予期間でステートフル エージェントを使用することです。 猶予期間を持つステートフル エージェントがジョブを完了すると、猶予期間で指定された期間はオンラインのままになり、追加のジョブを待機します。 ワークロードが急増する場合は、ジョブが安定しているときにエージェントをオンラインに保ち、閑散期にはエージェントを再起動するように猶予期間を構成できます。
詳細については、スタンバイ エージェント および ステートフル プールを参照してください。
タイムアウト エラー コードを確認する
エージェントの割り当てがタイムアウトした場合は、「の概要」ページの「エラー コード」セクションでエラー コードを確認できます。
パイプラインが正常に完了しない
イメージの更新が行われたかどうかを確認する
イメージの更新後にパイプラインが失敗し始める場合は、以前のイメージ バージョンを使用するようにパイプラインを一時的に構成できます。 失敗したパイプラインをパイプラインごとに以前のイメージ バージョンを使用するように構成することも、そのイメージを使用する Managed DevOps プール内のすべてのパイプラインに対して以前のイメージ バージョンを構成することもできます。
イメージ バージョンの変更によってパイプラインが失敗しているかどうかを確認するには、失敗したパイプライン実行のイメージ バージョンと、最後に成功したパイプライン実行のイメージ バージョンを比較します。
パイプラインに移動 し、パイプラインの パイプラインの実行履歴 を確認します。
比較する 2 つのパイプライン実行の詳細を表示し、そのジョブに関する診断情報を表示するためにパイプライン ジョブを選択します。 パイプラインに複数のジョブがある場合は、Managed DevOps プールを使用して実行するジョブを選択します。
[ ジョブの初期化] を選択し、[現在のイメージ バージョン] セクションから イメージ バージョン を取得します。
最近失敗したパイプラインの実行と前回の正常な実行の間でイメージのバージョンが異なる場合は、イメージの更新によってエラーが発生する可能性があります。 根本原因のトラブルシューティングを行う際に、以前のイメージ バージョンに一時的に戻すには、2 つの選択肢があります。
- 以前のイメージ バージョンを使用して失敗したパイプラインのみを実行するには、パイプラインに
ImageVersionOverride要求を追加して、以前のバージョンを指定します。 詳細については、「 ImageVersionOverride」を参照してください。 - 以前のバージョンを使用してイメージを使用するすべてのパイプラインが実行されるようにプール設定を更新するには、 イメージ設定 を更新し、目的のバージョンを指定します。
- Azure Pipelines イメージを使用している場合は、ARM テンプレートまたは Azure CLI を使用してバージョンを指定する必要があります。Azure portal を使用して構成された Azure Pipelines イメージでは常に最新バージョンが使用されるためです。
- 選択したマーケットプレース イメージまたは Azure Compute Gallery イメージを使用している場合は、Azure portal と ARM テンプレートと Azure CLI を使用してバージョンを指定できます。
マネージド DevOps プールでは、選択したマーケットプレース イメージで使用できる過去 20 個のイメージと、Azure Pipelines イメージで使用できる過去 10 個のイメージが保持されます。 Azure コンピューティング ギャラリー イメージの過去のバージョンは、それらの Azure コンピューティング ギャラリーの所有者によって管理されます。