次の方法で共有

マネージド DevOps プール ネットワークを構成する

分離された仮想ネットワークまたは既存の仮想ネットワークで実行するように Managed DevOps Pools エージェントを構成できます。 この記事では、仮想ネットワークでエージェントを実行するようにプールを構成する方法について説明します。

ネットワークの種類を選択する

マネージド DevOps プールでは、次の 2 種類のネットワーク構成がサポートされています。

  • 分離仮想ネットワーク: 各プールは、Managed DevOps Pools サービスによって作成および管理される独自の分離された仮想ネットワークを取得します。
  • 既存の仮想ネットワークに挿入されたエージェント: 独自の仮想ネットワークとサブネットを持ち込むことができます。 プール用に作成されたすべての仮想マシンはそのサブネットを使用し、他のリソースではサブネットを使用できません。 次のようなシナリオで、マネージド DevOps プールから独自の仮想ネットワークにエージェントを追加できます。
    • 継続的インテグレーションおよび継続的デリバリー (CI/CD) エージェントは、Azure ExpressRoute などのサービスを介して会社のネットワークでのみ使用できるリソースにアクセスする必要があります。
    • CI/CD エージェントは、プライベート エンドポイントに分離されたリソースにアクセスする必要があります。
    • 会社固有のファイアウォール規則を使用して独自の仮想ネットワークを導入することで、CI/CD インフラストラクチャをネットワークで分離する必要があります。
    • そのまま使える Managed DevOps プールのネットワーク機能では実現できないその他のユニークなユースケース。

分離された仮想ネットワーク

既定では、すべてのプールで Microsoft が提供する仮想ネットワークが使用されます。この仮想ネットワークでは、すべての受信トラフィックが制限され、次の送信トラフィック構成オプションがあります。

  1. 既定の送信アクセス接続は現在の既定値であり、Microsoft が提供する IP アドレスを使用してすべての送信トラフィックを許可します。 Azure 内の VM の既定の送信アクセスは、廃止される予定です。 既定の送信アクセスが廃止されると、プールは既定で 1 つの静的 IP アドレスで構成されます。
  2. 既定の送信アクセスを使用する代わりに、最大 16 個の静的送信 IP アドレスを使用するようにプールを構成できます。 マネージド DevOps プールでは、プールと同じリージョンに NAT ゲートウェイが作成され、IP アドレスが提供されます。 この構成を使用すると、パイプラインがアクセスする必要がある外部サービスの特定の IP アドレスを許可リストに登録できます。
    • NAT ゲートウェイでは、追加の Azure コストが発生します。 Azure コスト計算ツールを使用して、コストをモデル化できます。 詳細については、 Azure NAT Gateway の価格に関するページを参照してください。

重要

プールの作成後に静的 IP アドレス数を変更した場合、IP アドレスは変更される可能性があります。更新操作の完了後に、新しい IP アドレスを取得し、外部サービスの許可リストを更新する必要があります。

プールの作成時に IP アドレス設定を構成するには、[ ネットワーク ] タブに移動します。既存のプールを更新するには、 設定>Networking に移動します。

既定の送信アクセスを使用するには、[パブリック IP アドレス経由のルート] で [なし] を選択します。

[Microsoft 提供 IP] を選択して静的送信 IP アドレスを構成し、使用する静的 IP アドレスの数を指定します。 マネージド DevOps プールでは、NAT ゲートウェイが自動的に作成され、IP アドレスが管理されます。

IP アドレス設定のスクリーンショット。

注

既知の問題があります。プールがマネージド ID で構成されている場合、DevOpsInfrastructure サービス プリンシパルにマネージド ipAddresses ロールが割り当てられない限り、API 呼び出しは プロパティを返しません。 詳細な手順については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。

静的 IP アドレスを機能させるために、このロールを付与する必要はありません。 このロールの割り当てがない場合でも、割り当てられた IP アドレスは、Azure portal の [ネットワーク ] ページで確認できます。

既存の仮想ネットワークに挿入されたエージェント

次の手順を使用して、仮想ネットワークを使用するようにプールのエージェントを構成できます。

  1. 仮想ネットワークとサブネットを作成または使用します。
  2. サブネットをMicrosoft.DevOpsInfrastructure/poolsに委任します。
  3. サブネットをプールに関連付けます。

前の手順では、プールによる排他的アクセスのためにサブネットを委任します。 他のプールまたはリソースではサブネットを使用できません。

プールでは、複数のサブネットを使用して、複数のプールを同じ仮想ネットワークに接続できます。 各サブネットは委任され、独自のプールに関連付けられます。

仮想ネットワークとサブネットを作成または持ち込む

サブネットには、関連付けるプールの最大プール サイズ (Azure がサブネットに予約する 5 つの IP アドレスを含む) に対応できる十分なアドレス空間が必要です。

ExpressRoute を使用している場合は、リソース グループの管理ロックを一時的に削除または変更して、書き込みを許可する必要があります。

重要

プールと仮想ネットワークは、同じリージョンに存在する必要があります。 それ以外の場合、プールを作成またはネットワーク構成を更新しようとすると、次のようなエラーが表示されます。"仮想ネットワーク MDPVN はリージョン東部にありますが、プール mdpnonprodsub はリージョン australiaeast にあります。 これらは同じリージョンに存在する必要があります。

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 のプリンシパル アクセスを確認する

  1. 仮想ネットワークの アクセス制御 (IAM) を選択し、[アクセスの 確認] を選択します。

    サブネット委任の仮想ネットワークのアクセス許可を示すスクリーンショット。

  2. DevOpsInfrastructure を検索して選択します。

    AzureDevOpsInfrastructure プリンシパルを選択する方法を示すスクリーンショット。

  3. 閲覧者レベルのアクセス権があることを確認します。 Microsoft.Network/virtualNetworks/subnets/join/action、Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action、およびMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/writeアクセスが割り当てられていることを確認します。 カスタム ロールがここに表示されます。

    仮想ネットワークのアクセス許可を示すスクリーンショット。

  4. DevOpsInfrastructure プリンシパルにこれらのアクセス許可がない場合は、それらを追加します。 仮想ネットワークの [アクセス制御 (IAM)] を選択し、[ このリソースへのアクセスを許可する] を選択します。

サブネットを Microsoft.DevOpsInfrastructure/pools に委任する

ポータルで[サブネットのプロパティ]を開き、[Microsoft.DevOpsInfrastructure/pools]でを選択します。 保存 を選択します。

サブネット委任を構成する方法を示すスクリーンショット。

このプロセスは、プールの排他的アクセス用にサブネットを委任します。 他のプールまたはリソースではサブネットを使用できません。 複数のプールを同じ仮想ネットワークに接続するには、複数のサブネットを使用する必要があります。 各サブネットは委任され、独自のプールに関連付けられている必要があります。 サブネット委任の詳細については、このサブネット委任 の概要を参照してください。

サブネットを Microsoft.DevOpsInfrastructure/poolsに委任したら、そのサブネットを使用するようにプールを更新できます。

サブネットをプールに関連付ける

  1. 新しいプールを作成するには、[ネットワーク] タブに移動します。既存のプールを更新するには、[>] に移動し、[既存の仮想ネットワークに挿入されたエージェント] を選択します>します。

    構成オプションを示すスクリーンショット。

  2. に委任したサブスクリプション、仮想ネットワーク、Microsoft.DevOpsInfrastructure/poolsの値を選択し、[OK] を選択します。

    サブネットをプールに関連付ける方法を示すスクリーンショット。

    ネットワークの更新が完了すると、プール内に新しく作成されたリソースで、委任されたサブネットが使用されます。

重要

プールを更新するときに、仮想ネットワークに 削除 ロックを設定しないでください。 プールの更新操作中に、マネージド DevOps プールによって、サブネット上に サービス関連付けリンク が作成されます。 更新が失敗した場合、Managed DevOps プールはサービス関連付けリンクのクリーンアップを試みますが、 削除 ロックがある場合は、 InUseSubnetCannotBeDeleted エラーが発生します。 マネージド DevOps プールでは、サービス関連付けリンクを削除できません。このリンクにより、サブネットはロックされた状態になります (削除できません)。 この問題を解決するには、 削除 ロックを削除し、更新操作を再試行します。

詳細については、「 Azure リソースにロックを適用する前に考慮すべき事項」を参照してください。

送信接続を制限する

ネットワーク上に送信接続を制限するシステム (ネットワーク セキュリティ グループやファイアウォールなど) がある場合は、マネージド DevOps プールを完全にサポートするために、特定のエンドポイントを許可リストに追加する必要があります。 これらのエンドポイントは、グローバルに必要なエンドポイント (Managed DevOps プールを使用するすべてのマシンで必要) と、特定のシナリオに必要なエンドポイントに分割されます。 特に明記されていない限り、すべてのエンドポイントは HTTPS です。

Managed DevOps プールを開始するために必要なエンドポイント

これらのエンドポイントを許可リストに追加しない場合、マシンは Managed DevOps Pools サービスの一部としてオンラインに失敗し、プールでパイプラインを実行することはできません。

  • *.prod.manageddevops.microsoft.com: Managed DevOps Pools サービスとの通信に使用されるマネージド DevOps プール エンドポイント。
  • 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 に接続するために必要なエンドポイント

これらのエンドポイントを許可リストに追加しないと、マシンがオンラインになり、 割り当てられた 状態になる可能性がありますが、Azure DevOps サービス タスク エージェントが接続できないか起動できないため、Azure DevOps との通信に失敗する可能性があります。

  • 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 マシンのプロビジョニング。 このエンドポイントは HTTP (ポート 80) であり、HTTPS (ポート 443) ではありません。
  • www.microsoft.com: Linux マシンのプロビジョニング。
  • security.ubuntu.com: Linux マシンのプロビジョニング。
  • packages.microsoft.com: Linux マシンのプロビジョニング。
  • ppa.launchpad.net: 特定の Linux ディストリビューションのプロビジョニング。
  • dl.fedoraproject.org: 特定の Linux ディストリビューションのプロビジョニング。

一部の Azure DevOps 機能に必要なエンドポイント

これらの省略可能なエンドポイントは、特定の Azure DevOps 機能がパイプラインで動作するために必要です。 次のセットでは、ワイルドカードを、パイプラインをホストする特定の Azure DevOps 組織に置き換えることができます。 たとえば、組織が contoso という名前の場合は、contoso.services.visualstudio.comの代わりに*.services.visualstudio.comを使用できます。

  • *.services.visualstudio.com
  • *.vsblob.visualstudio.com: 成果物のアップロードと使用の両方に使用されます。
  • *.vssps.visualstudio.com: 特定の機能に対する Azure DevOps での認証に使用されます。
  • *.visualstudio.com

注

上記のエントリは、必要な最小ドメインです。 問題がある場合は、 Azure DevOps で許可されている IP アドレスとドメイン URL で必要なドメインの完全な一覧を参照してください。

Azure 仮想マシン (VM) は、サブネットを介して特定の Azure 機能にトラフィックをルーティングする場合があります。 これらの要求の場合は、Azure 経由で直接要求をルーティングするか、ネットワーク経由でアクセスを有効にすることができます。

  1. サービス エンドポイントを介して実行するように Azure トラフィックを構成します。

    ネットワーク セキュリティ グループまたはファイアウォールにスループットを追加しないように、Azure 経由でトラフィックを直接ルーティングできます。 次のオプションに記載されているドメインを許可リストに追加する必要はありません。

    たとえば、 データ ディスク 機能を使用して、Azure Storage へのネットワーク呼び出しを行うことができます。 ネットワーク上 で Microsoft.Storage サービス エンドポイントを有効にすると、トラフィックは Azure 経由で直接ルーティングされるため、ネットワーク ルールが回避され、負荷が軽減されます。

  2. サービス エンドポイント経由でトラフィックをルーティングしないようにするには、 md-*.blob.storage.azure.net ドメインを許可リストに追加します。 このドメインは、 データ ディスクを構成するために必要です。

Akamai CDN 配信 IP

2025 年 5 月 1 日、Azure DevOps CDN 資産は、Akamai と Azure Front Door によって提供されるソリューションに移行されました。 ネットワークが Akamai IP 範囲への送信アクセス権を持っていることを確認します。 詳細については、以下を参照してください。

コンテナー内で実行するように Azure DevOps パイプラインを構成する場合は、コンテナー イメージ (Docker または Azure Container Registry) のソースも許可リストに追加する必要があります。

エンドポイントの接続を検証する

そのサブネット上のリソースで次のスクリプトを実行して、Managed DevOps プールでサブネットを使用できることを確認します。 この手順は、使用可能なすべてのエンドポイントと Managed DevOps コントロール プレーンに到達するようにネットワーク フローが構成されていることを検証するのに役立ちます。

重要

このスクリプトは、サブネット内のリソース (VM やコンテナーなど) で実行して、そのサブネットから必要なエンドポイントへのネットワーク パスが開かれていることを検証する必要があります。

PowerShell Core または PowerShell 5 以降でスクリプトを実行するには、次のスクリプトを ValidateMDPEndpoints.ps1として保存します。 次の PowerShell コマンドを実行します: .\ValidateMDPEndpoints.ps1 -organization "<your-organization>"。

# ValidateMDPEndpoints.ps1
param (
    [string]$organization
)
$azureDevOpsUris = @(
    "https://dev.azure.com",
    "https://vssps.dev.azure.com",
    "https://vsrm.dev.azure.com",
    "https://management.azure.com",
    "https://login.microsoftonline.com",
    "https://graph.microsoft.com",
    "https://aadcdn.msftauth.net",
    "https://${organization}.visualstudio.com",
    "https://${organization}.vsrm.visualstudio.com",
    "https://${organization}.vstmr.visualstudio.com",
    "https://${organization}.pkgs.visualstudio.com",
    "https://${organization}.vssps.visualstudio.com",
    "https://download.agent.dev.azure.com",
    "download.agent.dev.azure.com"
)
$managedDevOpsPoolsControlPlaneUris = @(
    # List of agent queue endpoints - maps to *.queue.core.windows.net
    "https://rmprodaedefaultcq.queue.core.windows.net",
    "https://rmprodbrsdefaultcq.queue.core.windows.net",
    "https://rmprodcncdefaultcq.queue.core.windows.net",
    "https://rmprodcusdefaultcq.queue.core.windows.net",
    "https://rmprodeus2defaultcq.queue.core.windows.net",
    "https://rmprodgwcdefaultcq.queue.core.windows.net",
    "https://rmprodincdefaultcq.queue.core.windows.net",
    "https://rmprodneudefaultcq.queue.core.windows.net",
    "https://rmprodseadefaultcq.queue.core.windows.net",
    "https://rmprodszndefaultcq.queue.core.windows.net",
    "https://rmproduksdefaultcq.queue.core.windows.net",
    "https://rmprodwus3defaultcq.queue.core.windows.net",
    # CDN for downloading the Managed DevOps Pools agent - maps to *.prod.managedevops.microsoft.com
    "rm-agent.prod.manageddevops.microsoft.com"
    # List of control plane endpoints - maps to *.manageddevops.microsoft.com
    "default.ae.prod.manageddevops.microsoft.com",
    "default.brs.prod.manageddevops.microsoft.com",
    "default.cnc.prod.manageddevops.microsoft.com",
    "default.cus.prod.manageddevops.microsoft.com",
    "default.eus2.prod.manageddevops.microsoft.com",
    "default.gwc.prod.manageddevops.microsoft.com",
    "default.inc.prod.manageddevops.microsoft.com",
    "default.neu.prod.manageddevops.microsoft.com",
    "default.sea.prod.manageddevops.microsoft.com",
    "default.szn.prod.manageddevops.microsoft.com",
    "default.uks.prod.manageddevops.microsoft.com",
    "default.wus3.prod.manageddevops.microsoft.com"
)
$unreachableUris = @()
foreach ($uri in $azureDevOpsUris) {
    try {
        $hostName = ($uri -replace "^https?://", "") -replace "/.*", ""
        $connection = Test-NetConnection -ComputerName $hostName -Port 443 -WarningAction SilentlyContinue
        if (-not $connection.TcpTestSucceeded) {
            $unreachableUris += $uri
        }
    } catch {
        $unreachableUris += $uri
    }
}
if ($unreachableUris.Count -eq 0) {
    Write-Output "All Azure DevOps endpoints are reachable."
} else {
    Write-Output "The following Azure DevOps endpoints could not be reached:"
    $unreachableUris | ForEach-Object { Write-Output $_ }
}
foreach ($uri in $managedDevOpsPoolsControlPlaneUris) {
    try {
        $hostName = ($uri -replace "^https?://", "") -replace "/.*", ""
        $connection = Test-NetConnection -ComputerName $hostName -Port 443 -WarningAction SilentlyContinue

        if (-not $connection.TcpTestSucceeded) {
            $unreachableUris += $uri
        }
    } catch {
        $unreachableUris += $uri
    }
}
if ($unreachableUris.Count -eq 0) {
    Write-Output "All Azure Managed DevOps Pools endpoints are reachable."
} else {
    Write-Output "The following Managed DevOps Pools endpoints could not be reached:"
    $unreachableUris | ForEach-Object { Write-Output $_ }
}

プロキシの背後で実行するように Azure DevOps エージェントを構成する

イメージでプロキシ サービスを構成し、プールで実行されるワークロードをこのプロキシの背後で実行する場合は、イメージに次の環境変数を追加する必要があります。

  • VSTS_AGENT_INPUT_PROXYURL: 後ろで実行するように構成されたプロキシの URL。
  • VSTS_AGENT_INPUT_PROXYUSERNAME: プロキシを使用するために必要なユーザー名。
  • VSTS_AGENT_INPUT_PROXYPASSWORD: プロキシを使用するパスワード。

Windows の場合、これらの環境変数はシステム環境変数である必要があります。 Linux の場合、これらの変数は /etc/environment ファイルに含まれている必要があります。 これらのシステム変数を誤って設定した場合、またはイメージにプロキシ サービスが構成されていない場合、新しいエージェントのプロビジョニングはネットワーク接続の問題で失敗します。

Azure Virtual Machine Scale Sets エージェントから移行していて、イメージでプロキシ環境変数を既に使用している場合は、変更を加える必要はありません。 このプロセスについては、「 Azure Virtual Machine Scale Set エージェント: パイプライン エージェントの構成をカスタマイズする」で説明されています。

関連コンテンツ

  • Last updated on