マネージド DevOps プール エージェントは、分離された仮想ネットワークまたは既存の仮想ネットワークで実行するように構成できます。 この記事では、仮想ネットワークでエージェントを実行するように Managed DevOps プールを構成する方法について説明します。
独自の仮想ネットワークへのエージェントの追加
次のようなシナリオでは、Managed DevOps プールから独自の仮想ネットワークにエージェントを追加できます。
- CI/CD エージェントは、Express Route などのサービスを介して会社のネットワークでのみ使用できるリソースにアクセスする必要があります
- CI/CD エージェントは、プライベート エンドポイントに分離されているリソースにアクセスする必要があります
- 会社固有のファイアウォール規則を使用して独自の VNet を導入することで、CI/CD インフラストラクチャをネットワークで分離する必要がある
- すぐに使用できる Managed DevOps プールネットワーク関連の機能では実現できないその他の固有のユース ケース
次の手順を使用して、プールのエージェントを仮想ネットワークに追加できます。
- 仮想ネットワークとサブネットを作成または持ち込む
- サブネットを Microsoft.DevOpsInfrastructure/pools に委任する
- サブネットを Managed DevOps プールに関連付ける
前の手順では、プールによる排他的アクセスのためにサブネットを委任します。サブネットは他のプールやリソースでは使用できません。 複数のプールを同じ仮想ネットワークに接続するために、複数のサブネットを使用できます。各サブネットは委任され、独自のプールに関連付けられます。
仮想ネットワークとサブネットを作成または持ち込む
サブネットには、関連付けるプールの最大プール サイズに対応できる十分なアドレス空間が必要です (サブネットに 5 つの IP アドレス Azure 予約を含めます)。 Express Route を使用している場合は、書き込みを許可するようにリソース グループの管理ロックを一時的に削除または変更する必要があります。
重要
Managed DevOps プールと仮想ネットワークは同じリージョンに存在する必要があります。プールの作成またはネットワーク構成の更新を試みると、次のようなエラーが表示されます。 Virtual network MDPVN is in region eastus, but pool mdpnonprodsub is in region australiaeast. These must be in the same region.
DevOpsInfrastructure サービス プリンシパルへの閲覧者とネットワーク共同作成者のアクセス権を付与する
DevOpsInfrastructure プリンシパルが仮想ネットワーク上で次のアクセス権を持っていることを確認します。
-
Reader
およびNetwork Contributor
- または、カスタム ロールに次のアクセス許可を追加します。
Microsoft.Network/virtualNetworks/*/read
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action
Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write
Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/delete
Service Association Link アクセスのカスタム ロールを作成します。 ロールの例は、次の例に示すように、[アクセス制御] タブのリソース グループまたはサブスクリプション レベルで作成できます。
DevOpsInfrastructure プリンシパル アクセスを確認するには
仮想ネットワーク アクセス制御 (IAM) を選択し、 アクセスの確認を選択します。
DevOpsInfrastructureを検索して選択します。
Reader アクセスを確認します。
Microsoft.Network/virtualNetworks/subnets/join/action
、Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action
、Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write
アクセスが割り当てられていることを確認します。 カスタム ロールがここに表示されます。DevOpsInfrastructureにこれらのアクセス許可がない場合は、仮想ネットワークの Access control (IAM) を選択して追加し、このリソースへのアクセス許可を付与して追加します。
サブネットを Microsoft.DevOpsInfrastructure/pools に委任する
サブネットは、使用する Microsoft.DevOpsInfrastructure/pools
に委任する必要があります。
ポータルでサブネットのプロパティを開き、[サブネット委任] セクションで Microsoft.DevOpsInfrastructure/pools
を選択し、 保存を選択します。
これにより、プールの排他アクセス用のサブネットが委任され、そのサブネットを他のプールまたはリソースで使用することはできません。 複数のプールを同じ仮想ネットワークに接続するには、複数のサブネットを使用し、それぞれが委任され、独自のプールに関連付けられている必要があります。 サブネットの委任の詳細については、 こちらを参照してください。
サブネットが Microsoft.DevOpsInfrastructure/pools
に委任されると、そのサブネットを使用するようにプールを更新できます。
サブネットを Managed DevOps プールに関連付ける
新しいプールを作成する場合は、Networking タブに移動します。既存のプールを更新するには、Settings>Networking に移動し、既存の仮想ネットワーク構成に挿入されたエージェント選択します。
に委任した Subscription、Virtual Network、
Microsoft.DevOpsInfrastructure/pools
を選択し、 Okを選択します。
ネットワーク更新が完了すると、プール内に新しく作成されたリソースで委任されたサブネットが使用されます。
送信接続の制限
ネットワーク上に送信接続を制限するシステム (NSG、ファイアウォールなど) がある場合、マネージド DevOps プールを完全にサポートするには、特定のエンドポイントを許可リストに登録する必要があります。 これらのエンドポイントは、グローバルに必要なエンドポイント (任意のマネージド DevOps プール マシンで必要) と、特定のシナリオに必要なエンドポイントに分割されます。 特に明記されていない限り、すべてのエンドポイントは HTTPS です。
- マネージド DevOps プールの起動に必要なエンドポイント - これらのエンドポイントを許可リストに登録しないと、マシンはサービスの一部としてオンラインにならず、Managed DevOps プールでパイプラインを実行できなくなります
-
*.prod.manageddevops.microsoft.com
- Managed DevOps Pools エンドポイント。Managed DevOps Pools サービスとの通信に使用されます。 -
rmprodbuilds.azureedge.net
- Managed DevOps Pools ワーカー バイナリとスタートアップ スクリプトをダウンロードするために使用します。 (ワーカー バイナリのエージェント部分は、rm-agent.prod.manageddevops.microsoft.com
からダウンロードされます。(以前はagent.prod.manageddevops.microsoft.com
からダウンロードされました)これは、前の必須の*.prod.manageddevops.microsoft.com
エントリでカバーされています。 -
*.queue.core.windows.net
- Managed DevOps Pools サービスと通信するためのワーカー キュー。
-
- Azure DevOps に接続するために必要なエンドポイント - これらのエンドポイントを許可リストに登録しないと、マシンがオンラインになり、"割り当て済み" 状態になる場合もありますが、VSTS タスク エージェントが接続できないか起動できないため、ADO との通信に失敗します。
-
download.agent.dev.azure.com
- Azure DevOps エージェントの CDN の場所。Azure DevOps エージェントのダウンロードに使用されます (以前のvstsagentpackage.azureedge.net
- 詳細については、「 Edgio CDN for Azure DevOps が廃止される」を参照してください)。 -
dev.azure.com
- Azure DevOps との通信を処理するために必要 - Linux マシンの準備 - これらのエンドポイントは Ubuntu マシンを起動するために必要ですが、プールが Windows のみを使用している場合は必要ありません。 Azure DevOps タスク エージェントの設定の一環として、必要なパッケージがいくつか追加され、apt-get が実行されます。このパッケージは許可リストに登録されずに失敗します。
-
azure.archive.ubuntu.com
- Linux マシンのプロビジョニング - HTTPS (ポート 443) ではなく HTTP (ポート 80) です -
www.microsoft.com
- Linux マシンのプロビジョニング -
security.ubuntu.com
- Linux マシンのプロビジョニング -
packages.microsoft.com
- Linux マシンのプロビジョニング -
ppa.launchpad.net
- 特定の Linux ディストリビューションのプロビジョニング -
dl.fedoraproject.org
- 特定の Linux ディストリビューションのプロビジョニング
-
-
- 省略可能ですが、特定の Azure DevOps 機能がパイプラインで動作するために必要です。 次のセットでは、ワイルドカードを、パイプラインをホストしている特定の Azure DevOps 組織に置き換えることができます。 たとえば、組織が
contoso
という名前の場合は、contoso.services.visualstudio.com
の代わりに*.services.visualstudio.com
を使用できます。 これらのエントリは、必要な最小ドメインです。 問題がある場合は、 Azure DevOps allowlist で必要なドメインの完全な一覧を参照してください。*.services.visualstudio.com
-
*.vsblob.visualstudio.com
- アーティファクトのアップロードおよび利用に使用されます -
*.vssps.visualstudio.com
- 特定の機能に対する Azure DevOps での認証に使用されます *.visualstudio.com
- Azure 関連のエンドポイント: Azure VM は、サブネットを介して特定の Azure 機能にトラフィックをルーティングする場合があります。 これらの要求には、Azure 経由で直接要求をルーティングするか、ネットワーク経由でアクセスを有効にするかのオプションがあります。
サービス エンドポイントを介して実行するように Azure トラフィックを構成する
Azure 経由でトラフィックを直接ルーティングすると、NSG またはファイアウォールへのスループットの追加が回避され、次のオプションに記載されているドメインを許可リストに登録する必要はありません。
たとえば、データ ディスク 機能を使用すると、Azure Storage へのネットワーク呼び出しが必要になります。 ネットワーク上 Microsoft.Storage サービス エンドポイントを有効にすると、トラフィックが Azure 経由で直接ルーティングされるため、ネットワーク ルールが回避され、負荷が軽減されます。
サービス エンドポイントを介してトラフィックをルーティングしないようにする場合は、特定の機能を許可リストに登録するドメインです。
- データ ディスク を 構成するために必要です
- Akamai CDN 配信 IP: 2025 年 5 月 1 日より、Azure DevOps CDN 資産は Akamai と Azure Front Door によって提供されるソリューションに移行しています。 ネットワークが Akamai IP 範囲への送信アクセス権を持っていることを確認します。 詳細については、以下を参照してください。
コンテナー内で実行するように Azure DevOps パイプラインを構成する場合は、コンテナー イメージのソース (Docker または ACR) も許可リストする必要があります。
プロキシの背後で実行するように Azure DevOps エージェントを構成する
イメージでプロキシ サービスを構成し、マネージド DevOps プールで実行されているワークロードをこのプロキシの背後で実行する場合は、イメージに次の環境変数を追加する必要があります。
-
VSTS_AGENT_INPUT_PROXYURL
- 背後で実行するように構成されたプロキシの URL -
VSTS_AGENT_INPUT_PROXYUSERNAME
- プロキシを使用するために必要なユーザー名 -
VSTS_AGENT_INPUT_PROXYPASSWORD
- プロキシを使用するパスワード。
Windows の場合、これらの環境変数はシステム環境変数である必要があり、Linux の場合、これらの変数は /etc/environment ファイルに含まれている必要があります。 これらのシステム変数を誤って設定するか、イメージにプロキシ サービスを構成しないと、新しいエージェントのプロビジョニングがネットワーク接続の問題で失敗します。
Azure Virtual Machine Scale Set エージェントから移行していて、既にイメージでプロキシ環境変数を使用している場合は、「 Azure Virtual Machine Scale Set エージェント - Pipeline Agent 構成のカスタマイズ」で説明されているように、変更は必要ありません。