次の方法で共有

マネージド 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 を使用している場合は、書き込みを許可するようにリソース グループの管理ロックを一時的に削除または変更する必要があります。

重要

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

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

    サブネット委任の VNet アクセス許可のスクリーンショット。

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

    AzureDevOpsInfrastructure プリンシパルの選択のスクリーンショット。

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

    VNet のアクセス許可のスクリーンショット。

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

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

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

サブネット委任の構成のスクリーンショット。

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

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

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

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

    構成オプションのスクリーンショット。

  2. Microsoft.DevOpsInfrastructure/poolsに委任した Subscription、Virtual Network、Subnet を選択し、 Okを選択します。

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

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

送信接続の制限

送信接続を制限するシステムがネットワーク (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 マシンのプロビジョニング
  • サービスが依存する、安全性が低く、よりオープンなエンドポイント:
    • サービスに必要:
      • 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 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 構成のカスタマイズに関するページで説明されているように、変更は必要ありません。

関連項目