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

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

独自の仮想ネットワークへのエージェントの追加

次のようなシナリオでは、Managed DevOps プールから独自の仮想ネットワークにエージェントを追加できます。

• CI/CD エージェントは、Express Route などのサービスを介して会社のネットワークでのみ使用できるリソースにアクセスする必要があります
• CI/CD エージェントは、プライベート エンドポイントに分離されているリソースにアクセスする必要があります
• 会社固有のファイアウォール規則を使用して独自の VNet を導入することで、CI/CD インフラストラクチャをネットワークで分離する必要がある
• すぐに使用できる Managed DevOps プールネットワーク関連の機能では実現できないその他の固有のユース ケース

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

1. 仮想ネットワークとサブネットを作成または持ち込む
2. サブネットを Microsoft.DevOpsInfrastructure/pools に委任する
3. サブネットを Managed DevOps プールに関連付ける

前の手順では、プールによる排他的アクセスのためにサブネットを委任します。サブネットは他のプールやリソースでは使用できません。 複数のプールを同じ仮想ネットワークに接続するために、複数のサブネットを使用できます。各サブネットは委任され、独自のプールに関連付けられます。

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

サブネットには、関連付けるプールの最大プール サイズに対応できる十分なアドレス空間が必要です (サブネットに 5 つの IP アドレス Azure 予約を含めます)。 Express Route を使用している場合は、書き込みを許可するようにリソース グループの管理ロックを一時的に削除または変更する必要があります。

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を検索して選択します。

   

3. Reader アクセスを確認します。 Microsoft.Network/virtualNetworks/subnets/join/action、Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action、Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/writeアクセスが割り当てられていることを確認します。 カスタム ロールがここに表示されます。

   

4. DevOpsInfrastructureにこれらのアクセス許可がない場合は、仮想ネットワークの Access control (IAM) を選択して追加し、このリソースへのアクセス許可を付与して追加します。

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

サブネットは、使用する Microsoft.DevOpsInfrastructure/pools に委任する必要があります。 ポータルでサブネットのプロパティを開き、[サブネット委任] セクションで Microsoft.DevOpsInfrastructure/pools を選択し、 保存を選択します。

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

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

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

{
    "name": "MyManagedDevOpsPool",
    "type": "Microsoft.DevOpsInfrastructure/pools",
    "apiVersion": "2024-10-19",
    "location": "eastus",
    "properties": {
        ...
        "networkProfile": {
          "subnetId":"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet",
        }
        ...
    }
}

az mdp pool create \
   --fabric-profile fabric-profile.json
   # other parameters omitted for space

{
  "vmss": {
    "sku": {...},
    "images": [...],
    "osProfile": {...},
    "storageProfile": {...},
    "networkProfile": {
        "subnetId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet"
    }
  }
}

送信接続の制限

送信接続を制限するシステムがネットワーク (NSG、ファイアウォールなど) に配置されている場合は、次のドメインにアクセスできることを確認する必要があります。そうしないと、Managed DevOps プールが機能しなくなります。 特に明記されていない限り、これらはすべて HTTPS です。

• サービスが依存する高度にセキュリティで保護されたエンドポイント:
  • *.prod.manageddevops.microsoft.com - マネージド DevOps プール エンドポイント
  • rmprodbuilds.azureedge.net - ワーカー バイナリ
  • vstsagentpackage.azureedge.net - Azure DevOps エージェントの CDN の場所
  • *.queue.core.windows.net - Managed DevOps Pools サービスと通信するための Worker キュー
  • server.pipe.aria.microsoft.com - 一般的なクライアント側テレメトリ ソリューション (特にエージェント プール検証拡張機能によって使用されます)
  • azure.archive.ubuntu.com - Linux マシンのプロビジョニング - HTTPS ではなく HTTP です
  • www.microsoft.com - Linux マシンのプロビジョニング
  • security.ubuntu.com - Linux マシンのプロビジョニング
• サービスが依存する、安全性が低く、よりオープンなエンドポイント:
  • サービスに必要:
    • packages.microsoft.com - Linux マシンのプロビジョニング
    • ppa.launchpad.net - Ubuntu マシンのプロビジョニング
    • dl.fedoraproject.org - 特定の Linux ディストリビューションのプロビジョニング
  • Azure DevOps エージェントに必要:
    • dev.azure.com
    • *.services.visualstudio.com
    • *.vsblob.visualstudio.com
    • *.vssps.visualstudio.com
    • *.visualstudio.com これらのエントリは、必要な最小ドメインです。 問題がある場合は、 Azure DevOps allowlist で必要なドメインの完全な一覧を参照してください。
• Azure 関連のエンドポイント: Azure VM は、サブネットを介して特定の Azure 機能にトラフィックをルーティングする場合があります。 これらの要求には、Azure 経由で直接要求をルーティングするか、ネットワーク経由でアクセスを有効にするかのオプションがあります。

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

     Azure 経由でトラフィックを直接ルーティングすると、NSG またはファイアウォールへのスループットの追加が回避され、次のオプションに記載されているドメインを許可リストに登録する必要はありません。

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

  2. サービス エンドポイントを介してトラフィックをルーティングしないようにする場合は、特定の機能を許可リストに登録するドメインです。

     • - データ ディスク を 構成するために必要です

コンテナー内で実行するように 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 構成のカスタマイズに関するページで説明されているように、変更は必要ありません。

関連項目

• プールの設定を構成する