Azure 仮想マシン スケール セット エージェント

Azure DevOps Services

Azure 仮想マシン スケール セット エージェント (以降はスケール セット エージェントと呼びます) は、必要に応じて自動的にスケールアップできるセルフホステッド エージェントの一種です。 この弾力性により、専用エージェントを常に実行する必要性が減少します。 Microsoft がホストするエージェントとは異なり、エージェントを実行するマシンのサイズとイメージに柔軟性があります。

Microsoft ホステッド エージェントを気に入っていても、その提供内容の制限を受ける場合は、スケール セット エージェントを検討することをお勧めします。 次に例をいくつか示します。

• ネイティブの Microsoft ホステッド エージェントで提供されるものよりも多くのメモリ、プロセッサ、ストレージ、または IO が必要。
• 機械学習のために特定の命令セットを持つ NCv2 VM が必要。
• 受信接続のないプライベート VNet 内のプライベート Azure App Service にデプロイする必要がある。
• Microsoft ホステッド エージェントがサーバーと通信できるように、特定の IP アドレスに対して企業のファイアウォールを開く必要がある。
• エージェント マシンのネットワーク接続を制限し、それらが承認済みサイトのみに到達できるようにする必要がある。
• ニーズを満たすほど十分なエージェントを Microsoft から取得できない。
• ジョブが Microsoft ホステッド エージェントのタイムアウトを超えている。
• Microsoft ホステッド並列ジョブを、組織内の個々のプロジェクトまたはチームにパーティション分割できない。
• ソースとマシンレベルのパッケージ キャッシュの増分を利用するために、エージェント上でいくつかの連続したジョブを実行したい。
• エージェントがジョブの受け入れを始める前に、構成やキャッシュのウォームアップを実行したい。

セルフホステッド エージェントを気に入っていても、できれば管理を簡略化したい場合は、スケール セット エージェントを検討することをお勧めします。 次に例をいくつか示します。

• 24 時間体制で専用エージェントを実行したくない。 ジョブの実行に使っていないエージェント マシンのプロビジョニングを解除したい。
• パイプラインで信頼できないコードを実行しており、各ジョブの後にエージェント マシンを再イメージ化したい。
• エージェントの基本イメージの定期的な更新を簡略化したい。

スケール セットを作成する

スケール セット エージェントを作成する準備として、まず、Azure portal で仮想マシン スケール セットを作成する必要があります。 Azure Pipelines が管理できるように、特定の方法で仮想マシン スケール セットを作成する必要があります。 特に、Azure Pipelines が受信パイプライン ジョブの数に基づいてスケーリングを実行する方法を決定できるように自動スケールを無効にする必要があります。 以下の手順に従ってスケール セットを作成することをお勧めします。

次の例では、UbuntuLTS VM イメージを使って Azure Cloud Shell で新しいリソース グループと仮想マシン スケール セットを作成しています。

1. https://shell.azure.com/ の Azure Cloud Shell にアクセスします。

2. 次のコマンドを実行して、既定の Azure サブスクリプションを確認します。

   az account list -o table
   

   目的のサブスクリプションが既定値として表示されいない場合は、目的のサブスクリプションを選びます。

   az account set -s <your subscription ID>
   

3. 仮想マシン スケール セットのリソース グループを作成します。

   az group create \
   --location westus \
   --name vmssagents
   

4. リソース グループ内に仮想マシン スケール セットを作成します。 この例では、Ubuntu2204 VM イメージが指定されています。

   az vmss create \
   --name vmssagentspool \
   --resource-group vmssagents \
   --image Ubuntu2204 \
   --vm-sku Standard_D2_v4 \
   --storage-sku StandardSSD_LRS \
   --authentication-type SSH \
   --generate-ssh-keys \
   --instance-count 2 \
   --disable-overprovision \
   --upgrade-policy-mode manual \
   --single-placement-group false \
   --platform-fault-domain-count 1 \
   --load-balancer "" \
   --orchestration-mode Uniform
   

   Note

   Azure Pipelines は、スケール セットのオーバープロビジョニングと自動スケールをサポートしていません。 スケール セットに対して両方の機能が無効になっていることを確認します。

   スケール セットは Azure Pipelines によって管理されるので、次の設定が必須であるか、推奨されています。

   • --disable-overprovision - 必須
   • --upgrade-policy-mode manual - 必須
   • --load-balancer "" - Azure Pipelines でスケール セット エージェント プール内のエージェントにジョブをルーティングするためにロード バランサーは必要はありません。ただし、ロード バランサーを構成することは、ファイアウォール規則に使用できるスケール セット エージェントの IP アドレスを取得する方法の 1 つでもあります。 スケール セット エージェントの IP アドレスを取得するもう 1 つの方法は、--public-ip-address オプションを使ってスケール セットを作成することです。 ロード バランサーまたはパブリック IP アドレスを使ったスケール セットの構成の詳細については、「Virtual Machine Scale Sets のドキュメント」と「az vmss create」を参照してください。
   • --instance-count 2 - この設定は必須ではありませんが、エージェント プールを作成する前にスケール セットが完全に機能することを確認する機会が得られます。 2 つの VM を作成するには数分かかることがあります。 その後、エージェント プールを作成すると、Azure Pipelines によってこれら 2 つの VM が削除され、新しい VM が作成されます。

   重要

   Windows 上で Azure CLI を使ってこのスクリプトを実行する場合、次のように --load-balancer "" の "" は一重引用符で囲む必要があります。--load-balancer '""'

   VM サイズがエフェメラル OS ディスクをサポートしている場合、エフェメラル OS ディスクを有効にする次のパラメーターは省略可能ですが、仮想マシンの再イメージ化時間を短縮するためにお勧めします。

   • --ephemeral-os-disk true
   • --os-disk-caching readonly

   重要

   エフェメラル OS ディスクがサポートされていない VM サイズもあります。 サポートされる VM サイズの一覧については、「Azure VM のエフェメラル OS ディスク」を参照してください。

   Azure Marketplace または独自のカスタム イメージのいずれかから任意の Linux または Windows イメージを選び、スケール セットを作成します。 イメージに Azure Pipelines エージェントをプレインストールしないでください。 エージェントは、新しい仮想マシンのプロビジョニング時に Azure Pipelines によって自動的にインストールされます。 上の例では、プレーンな UbuntuLTS イメージを使いました。 カスタム イメージの作成と使用の手順については、「よく寄せられる質問」を参照してください。

   任意の VM SKU とストレージ SKU を選びます。

   注意

   ライセンスの考慮事項があるため、Microsoft ホステッド イメージの配布は制限されます。 お客様のスケール セット エージェントで使用できるこのようなイメージを私たちが提供することはできません。 ただし、このようなイメージを生成するために私たちが使っているスクリプトはオープン ソースです。 無料でこれらのスクリプトを使い、独自のカスタム イメージを作成することができます。

5. スケール セットを作成したら、Azure portal でスケール セットに移動し、次の設定を確認します。

   • アップグレード ポリシー - 手動

     

     また、次の Azure CLI コマンドを実行してこの設定を確認することもできます。

     az vmss show --resource-group vmssagents --name vmssagentspool --output table
     
     Name            ResourceGroup    Location    Zones    Capacity    Overprovision    UpgradePolicy
     --------------  ---------------  ----------  -------  ----------  ---------------  ---------------
     vmssagentspool  vmssagents       westus               0           False            Manual
     

   • スケーリング - 手動スケール

     

オーケストレーション モード

Azure Virtual Machine Scale Sets は、均一とフレキシブルの 2 つのオーケストレーション モードで構成できます。 Azure Pipelines の均一オーケストレーション モードに対するサポートは、すべてのお客様に一般提供されています。

フレキシブル オーケストレーション モードを使用すると、Azure Pipelines では複数のスケール セット操作を並列でキューに登録できます。 Azure Pipelines のフレキシブル オーケストレーションに対するサポートは、要求に応じて利用でき、評価の対象となります。 お客様の使用パターンは、そこから得る大きな利点を示す必要があります。 このようなお客様は、大きなスケール セットを持ち、複数のジョブのエージェントを再利用せず、複数の有効期間の短いジョブを並列で実行し、VM でエフェメラル ディスクのみを使用します。 この機能の利用をお考えの場合は、サポート チームにお問い合わせください。

スケール セット エージェント プールを作成する

1. Azure DevOps の [プロジェクト設定] に移動し、[パイプライン] の [エージェント プール] を選び、[プールの追加] を選んで新しいエージェント プールを作成します。

   

   重要

   スケール セット プールは [プロジェクトの設定] または [組織の設定] で作成できますが、スケール セット プールを削除する場合は、[プロジェクトの設定] ではなく [組織の設定] から削除する必要があります。

2. プールの種類として [Azure 仮想マシン スケール セット] を選びます。 スケール セットを含む Azure サブスクリプションを選び、[承認] を選び、そのサブスクリプションから目的の仮想マシン スケール セットを選びます。 既存のサービス接続がある場合は、サブスクリプションではなく一覧からそれを選択できます。

   重要

   • スケール セット エージェント プールを構成するには、選んだサブスクリプションの所有者またはユーザー アクセス管理者のアクセス許可を持っている必要があります。 これらのアクセス許可を持っていても、[承認] を選ぶとエラーが発生する場合は、トラブルシューティングのページを参照してください。

   • 現在サポートされている唯一のサービス接続は、サービス プリンシパル キーに基づく Azure Resource Manager (ARM) サービス接続です。 証明書資格情報またはマネージド ID に基づく ARM サービス接続は失敗します。 サブスクリプションの既存のスケール セットを一覧表示しようとすると、次のようなエラーが表示されます。

     Invalid Service Endpoint with Id <guid> and Scope <guid>

3. そのサブスクリプションから目的の仮想マシン スケール セットを選びます。

4. エージェント プールの名前を指定します。

5. 次のオプションを構成します。

   • Automatically tear down virtual machines after every use (使うたびに仮想マシンを自動的に破棄する) - ジョブごとに新しい VM インスタンスが使われます。 VM はジョブの実行後にオフラインになり、別のジョブを選ぶ前に再イメージ化されます。
   • Save an unhealthy agent for investigation (調査のために異常なエージェントを保存する) - 異常なエージェント VM を削除せずに、トラブルシューティングのために保存するかどうかを指定します。
   • Maximum number of virtual machines in the scale set (スケール セットの仮想マシンの最大数) - Azure Pipelines によってエージェント数は自動的にスケールアウトされますが、この制限を超えることはありません。
   • Number of agents to keep on standby (スタンバイ状態にしておくエージェントの数) - Azure Pipelines によってエージェント数は自動的にスケールインされますが、新しいジョブを実行するために常にこの数のエージェントが使用できる状態で確保されます。 たとえばジョブ量が少ない場合にコストを節約する目的などで [Number of agents to keep on standby] (スタンバイ状態にしておくエージェントの数) を「0」に設定した場合、ジョブがあるときにのみ、Azure Pipelines によって VM が開始されます。
   • Delay in minutes before deleting excess idle agents (過剰なアイドル状態のエージェントを削除するまでの待機分数) - 1 日を通してのビルド負荷の変動を考慮するため、Azure Pipelines はここで指定した時間待機してから、過剰なアイドル状態のエージェントを削除します。
   • Configure VMs to run interactive tests (対話型テストを実行するように VM を構成する) (Windows Server OS のみ) - 自動ログオンと対話型 UI を使って管理者特権なしで実行するように Windows エージェントを構成することができます。または、管理者特権のアクセス許可を使って実行するように構成することができます。 対話型 UI で管理者特権なしで実行するには、このボックスをオンにします。 どちらの場合も、エージェント ユーザーは管理者グループのメンバーです。

6. 設定を構成したら、[作成] を選んでエージェント プールを作成します。

スケール セット エージェント プールを使う

スケール セット エージェント プールの使い方は他のエージェント プールと同様です。 クラシック ビルド、リリース、または YAML パイプラインで使用できます。 ユーザー アクセス許可、パイプライン アクセス許可、承認、その他のチェックは、他のエージェント プールと同じように機能します。 詳細については、「エージェント プール」を参照してください。

Azure Pipelines でスケール セットを管理する方法

スケール セット エージェント プールが作成されると、Azure Pipelines によってエージェント マシンが自動的にスケーリングされます。

Azure Pipelines により、プール内のエージェントとスケール セット内の仮想マシンの状態が 5 分ごとにサンプリングされます。 スケールインまたはスケールアウトの決定は、その時点のアイドル状態のエージェント数に基づいて行われます。 エージェントがアイドル状態と見なされるのは、オンラインであり、パイプライン ジョブが実行されていない場合です。 次のいずれかの条件を満たす場合、Azure Pipelines によってスケールアウト操作が実行されます。

• アイドル状態のエージェント数が、指定したスタンバイ エージェント数を下回っている
• キュー内で待機しているパイプライン ジョブにサービスを提供するアイドル状態のエージェントが存在しない

これらの条件のいずれかを満たしている場合、Azure Pipelines は VM 数を増やします。 スケールアウトは、最大プール サイズに対して一定の割合の増分で行われます。 各手順でマシンが作成されるまでに 20 分ほどかかります。

アイドル状態のエージェント数がスタンバイ数を超えて 30 分より長く経過すると、Azure Pipelines によってエージェントがスケールインされます ([Delay in minutes before deleting excess idle agents] (過剰なアイドル状態のエージェントを削除するまでの待機分数) を使って構成できます)。

このすべてを例に取り入れるために、2 つのスタンバイ エージェントと 4 つの最大エージェントで構成されたスケール セット エージェント プールを考えてみましょう。 VM を使うたびに破棄するとします。 また、そのスケール セット内に最初は VM が存在しないとします。

• アイドル状態のエージェント数は 0 であり、2 のスタンバイ数を下回っているため、Azure Pipelines はスケールアウトし、スケール セットに 2 つの VM を追加します。 これらのエージェントがオンラインになると、アイドル状態のエージェントは 2 つになります。

• 1 つのパイプライン ジョブが到着し、エージェントの 1 つに割り当てられたとします。

• この時点でアイドル状態のエージェント数は 1 であり、2 のスタンバイ数を下回っています。 そのため、Azure Pipelines はスケールアウトし、VM を 2 つ (この例で使う増分サイズ) 追加します。 この時点で、プールには 3 つのアイドル状態のエージェントと 1 つのビジー状態のエージェントがあります。

• 最初のエージェントのジョブが完了したとします。 Azure Pipelines は、そのマシンを再イメージ化するために、そのエージェントをオフラインにします。 数分後、新しいイメージでオンラインに戻ります。 この時点で、アイドル状態のエージェントは 4 つあります。

• 他のジョブが 30 分間到着しない場合 ([Delay in minutes before deleting excess idle agents] (過剰なアイドル状態のエージェントを削除するまでの待機分数) を使って構成できます)、Azure Pipelines はアイドル状態のエージェント数が必要以上にあると判断します。 そのため、プールは 2 つエージェントにスケールインされます。

この操作全体で Azure Pipelines の目標は、待機しているアイドル状態のエージェントを目的の数に抑えることです。 プールのスケールアウトとスケールインが遅い。 1 日の中で、朝は要求がキューに格納されるのでプールはスケールアウトし、夕方には負荷が落ち着くのでスケールインします。 アイドル状態のエージェントが想定よりも多く見えることがよくあるかもしれませんが、Azure Pipelines はユーザーが指定した制約に徐々に収束するので、これは正常な動作です。

最大限の安定性を実現するために、スケール セット操作は順番に実行されます。 たとえば、プールをスケールアウトする必要があり、削除対象の異常なマシンもある場合、Azure Pipelines はまずプールをスケールアウトします。 プールがスケールアウトして、スタンバイしているアイドル状態のエージェントが目的の数に達すると、[Save an unhealthy agent for investigation] (調査のために異常なエージェントを保存する) の設定に応じて、異常なマシンは削除されます。 詳細については、「異常なエージェント」を参照してください。

サンプリング サイズが 5 分であるため、すべてのエージェントが短時間にパイプラインを実行してもスケールアウトが発生しない可能性があります。

パイプライン エージェントの構成のカスタマイズ

スケール セット用のオペレーティング システム カスタム イメージで環境変数を定義することで、Azure Pipelines エージェントの構成をカスタマイズできます。 たとえば、スケール セット エージェントの作業ディレクトリの既定値は、Windows の場合は C:\a、Linux の場合は /agent/_work です。 作業ディレクトリを変更する場合は、VSTS_AGENT_INPUT_WORK という環境変数に目的の作業ディレクトリを設定します。 詳細については、Pipelines エージェントの無人構成に関するドキュメントを参照してください。 次に例をいくつか示します。

• VSTS_AGENT_INPUT_WORK
• VSTS_AGENT_INPUT_PROXYURL
• VSTS_AGENT_INPUT_PROXYUSERNAME
• VSTS_AGENT_INPUT_PROXYPASSWORD

カスタム スクリプト拡張機能を使った仮想マシンのスタートアップのカスタマイズ

ユーザーは、スケールセット エージェント マシン上でスタートアップ スクリプトを実行してから、そのマシンでパイプライン ジョブの実行を開始したい場合があります。 スタートアップ スクリプトの一般的なユース ケースには、ソフトウェアのインストール、キャッシュのウォームアップ、リポジトリのフェッチなどがあります。 Windows 用のカスタム スクリプト拡張機能または Linux 用のカスタム スクリプト拡張機能をインストールすることで、スタートアップ スクリプトを実行できます。

この拡張機能は、スケール セット内のすべての仮想マシンが作成または再イメージ化された直後に実行されます。 カスタム スクリプト拡張機能は、Azure Pipelines エージェント拡張機能が実行される前に実行されます。

Linux 用カスタム スクリプト拡張機能を作成する例を次に示します。

az vmss extension set \
--vmss-name <scaleset name> \
--resource-group <resource group> \
--name CustomScript \
--version 2.0 \
--publisher Microsoft.Azure.Extensions \
--settings '{ \"fileUris\":[\"https://<myGitHubRepoUrl>/myScript.sh\"], \"commandToExecute\": \"bash ./myScript.sh /myArgs \" }'

Windows 用カスタム スクリプト拡張機能を作成する例を次に示します。

az vmss extension set \
--vmss-name <scaleset name> \
--resource-group <resource group> \
--name CustomScriptExtension \
--version 1.9 \
--publisher Microsoft.Compute \
--settings '{ \"FileUris\":[\"https://<myGitHubRepoUrl>/myscript.ps1\"], \"commandToExecute\": \"Powershell.exe -ExecutionPolicy Unrestricted -File myscript.ps1 -myargs 0 \" }'

すべての VM リソースがプロビジョニングされる前に拡張機能が実行されることがあります。このような場合は "failed installing basic prerequisites" (基本的な前提条件のインストールに失敗しました) のようなエラーが表示されます。これを修正するには、スクリプトの先頭に sleep コマンドを追加します (たとえば sleep 30)。

スケール セット エージェントのライフサイクル

Azure Pipelines 仮想マシン スケール セット エージェントの操作の流れは次のとおりです。

1. Azure DevOps スケール セット エージェント プールのサイズ設定ジョブにより、プールのアイドル状態のエージェント数が少なすぎるため、スケールアウトが必要だと判断されます。Azure Pipelines は、Azure スケール セットを呼び出してスケール セット容量を増やします。

2. Azure スケール セットは、新しい仮想マシンの作成を開始します。 仮想マシンが実行されると、Azure スケール セットはインストールされている VM 拡張機能を順番に実行します。

3. カスタム スクリプト拡張機能がインストールされている場合、Azure Pipelines エージェント拡張機能の前に実行されます。 カスタム スクリプト拡張機能が 0 以外の終了コードを返した場合、VM 作成プロセスは中止され、削除されます。

4. Azure Pipelines エージェント拡張機能が実行されます。 この拡張機能を使うと、最新バージョンの Azure Pipelines エージェントと最新バージョンの構成スクリプトをダウンロードできます。 構成スクリプトは、次の形式の URL にあります。

   • Linux: https://vstsagenttools.blob.core.windows.net/tools/ElasticPools/Linux/<script_version>/enableagent.sh (バージョン 15 の例)
   • Windows: https://vstsagenttools.blob.core.windows.net/tools/ElasticPools/Windows/<script_version>/enableagent.ps1 (バージョン 17 の例)

5. オペレーティング システムが Windows Server または Linux の場合、構成スクリプトを使って AzDevOps というローカル ユーザーを作成します。 Windows 10 クライアント OS の場合、エージェントは LocalSystem として実行されます。 次に、スクリプトによって、Azure Pipelines エージェントのデプロイ、インストール、構成が行われます。 構成の一環で、エージェントは Azure DevOps エージェント プールに登録され、エージェント プール一覧にオフラインの状態で表示されます。

6. ほとんどのシナリオでは、エージェントは構成スクリプトによってすぐに開始され、ローカル ユーザー AzDevOps として実行されます。 エージェントはオンラインになり、パイプライン ジョブを実行できる状態になります。

   プールが対話型 UI 用に構成されている場合、エージェントの構成後に仮想マシンは再起動します。 再起動後、ローカル ユーザーは自動的にログインし、パイプライン エージェントが起動します。 次にエージェントはオンラインになり、パイプライン ジョブを実行できるようになります。

カスタム イメージ、ソフトウェア、またはディスク サイズを使ってスケール セットを作成する

一般公開されている Azure イメージを使い、単に既定の 128 GB OS ディスクでスケール セットを作成する場合は、このまま手順 10 に進み、パブリック イメージ名 (UbuntuLTS、Win2019DataCenter など) を使ってスケール セットを作成します。 それ以外の場合は、以下の手順に従って VM イメージをカスタマイズします。

1. 目的の OS イメージで VM を作成し、必要に応じて OS ディスク サイズを 128 GB から <myDiskSizeGb> に拡張します。

   • 入手できる Azure イメージから始める場合 (たとえば <myBaseImage> = (Win2019DataCenter、UbuntuLTS)):

     az vm create --resource-group <myResourceGroup> --name <MyVM> --image <myBaseImage> --os-disk-size-gb <myDiskSize>  --admin-username myUserName --admin-password myPassword
     

   • 一般化された VHD から始める場合:

     1. まず目的のサイズのアンマネージド ディスクで VM を作成してから、マネージド ディスクに変換します。

        az vm create --resource-group <myResourceGroup> --name <MyVM> --image <myVhdUrl> --os-type windows --os-disk-size-gb <myDiskSizeGb> --use-unmanaged-disk --admin-username <myUserName> --admin-password <myPassword> --storage-account <myVhdStorageAccount>
        

     2. VM のシャット ダウン

        az vm stop --resource-group <myResourceGroup> --name <MyVM>
        

     3. VM の割り当てを解除する

        az vm deallocate --resource-group <myResourceGroup> --name <MyVM>
        

     4. マネージド ディスクに変換します

        az vm convert --resource-group <myResourceGroup> --name <MyVM>
        

     5. VM を再起動する

        az vm start --resource-group <myResourceGroup> --name <MyVM>
        

2. VM のパブリック IP アドレスにリモート デスクトップ (または SSH) で接続して、イメージをカスタマイズします。 RDP (3389) または SSH (22) ポートのブロックを解除するために、必要に応じてファイアウォールでポートを開く場合があります。

   1. Windows - <MyDiskSizeGb> が 128 GB を超える場合、<MyDiskSizeGb> に指定したディスク サイズを満たすように OS ディスク サイズを拡張します。

      管理者として DiskPart ツールを開き、次の DiskPart コマンドを実行します。

      1. list volume (ボリュームを表示します)
      2. select volume 2 (どのボリュームが OS ドライブかによって変わります)
      3. extend size 72000 (ドライブを 128 GB から 200 GB へと 72 GB 拡張します)

3. 必要な追加ソフトウェアを VM にインストールします。

4. パイプライン エージェント ユーザーのアクセス許可をカスタマイズするには、AzDevOps というユーザーを作成し、そのユーザーに必要なアクセス許可を付与します。 このユーザーがまだ存在しない場合は、スケールセット エージェントのスタートアップ スクリプトによって作成されます。

5. カスタマイズが完了したら VM を再起動します

6. VM を一般化します。

   • Windows - 管理コンソール ウィンドウから:

     C:\Windows\System32\sysprep\sysprep.exe /generalize /oobe /shutdown
     

   • Linux:

     sudo waagent -deprovision+user -force
     

   重要

   VM が一般化を完了とシャットダウンを完了するまで待ちます。 VM が停止するまで先に進まないでください。 60 分ほど待ちます。

7. VM の割り当てを解除する

   az vm deallocate --resource-group <myResourceGroup> --name <MyVM>
   

8. VM を一般化としてマークします

   az vm generalize --resource-group <myResourceGroup> --name <MyVM>
   

9. 一般化されたイメージに基づいて VM イメージを作成します。 既存のスケール セット イメージを更新するためにこれらの手順を実行する場合は、出力に表示されたイメージ ID の URL をメモしておきます。

   az image create  --resource-group <myResourceGroup> --name <MyImage> --source <MyVM>
   

10. カスタム VM イメージに基づいてスケール セットを作成します

    az vmss create --resource-group <myResourceGroup> --name <myScaleSet> --image <MyImage> --admin-username <myUsername> --admin-password <myPassword> --instance-count 2 --disable-overprovision --upgrade-policy-mode manual --load-balancer '""'
    

11. スケール セットで作成された両方の VM がオンラインになり、名前が異なり、成功状態に達していることを確認します。

これで、このスケール セットを使ってエージェント プールを作成できるようになりました。

新しいカスタム イメージを使って既存のスケール セットを更新する

既存のスケール セットのイメージを更新するには、前の「カスタム イメージ、ソフトウェア、またはディスク サイズを使ってスケール セットを作成する」セクションの手順に従って az image create の手順を実行し、カスタム OS イメージを生成します。 az image create コマンドから出力される ID プロパティ URL をメモします。 次に、次の例に示すように、新しいイメージを使ってスケールセットを更新します。 スケール セット イメージが更新されると、スケール セット内の今後のすべての VM は新しいイメージで作成されます。

az vmss update --resource-group <myResourceGroup> --name <myScaleSet> --set virtualMachineProfile.storageProfile.imageReference.id=<id url>

サポートされているオペレーティング システム

現在、スケール セット エージェントは Ubuntu Linux、Windows Server/DataCenter 2016/2019、Windows 10 クライアントをサポートしています。

既知の問題

• Debian または RedHat の Linux ディストリビューションはサポートされていません。 Ubuntu のみです。
• Windows 10 クライアントは、ローカル ユーザーとしてパイプライン エージェントを実行することをサポートしていないため、エージェントは UI と対話できません。 代わりに、エージェントはローカル サービスとして実行されます。

問題のトラブルシューティング

Azure DevOps の [プロジェクト設定] に移動し、[パイプライン] の [エージェント プール] を選び、エージェント プールを選びます。 [診断] というタブを選びます。

[診断] タブには、Azure スケール セット内の VM を作成、削除、または再イメージ化するために Azure DevOps が実行したすべてのアクションが表示されます。 診断には、これらのアクションを実行しようとして発生したエラーもログされます。 エラーを確認して、スケールアウトできるだけの十分なリソースがスケールセットにあることを確認します。Azure サブスクリプションが VM、CPU コア、ディスク、または IP アドレスのリソース制限に達している場合は、そのようなエラーがここに表示されます。

異常なエージェント

エージェントまたは仮想マシンが起動に失敗した、Azure DevOps に接続できない、または予期せずオフラインになった場合、Azure DevOps はエージェント プールの [診断] タブにエラーをログし、関連付けられた仮想マシンの削除を試みます。 ネットワーク構成、イメージのカスタマイズ、保留中の再起動により、これらの問題が発生する可能性があります。 VM に接続してデバッグし、ログを収集すると、調査に役立ちます。

Azure DevOps で異常な状態を検出したときに、自動的に削除せず、調査のために異常なエージェント VM を保存する場合は、Azure DevOps の [プロジェクトの設定] に移動し、[パイプライン] の [エージェント プール] を選び、エージェント プールを選びます。 [設定] を選び、オプション [Save an unhealthy agent for investigation] (調査のために異常なエージェントを保存する) をオンにし、[保存] を選びます。

これで、スケール セットで異常なエージェントが検出されると、そのエージェントと関連付けられた仮想マシンが Azure DevOps で保存されるようになりました。 保存されたエージェントは、エージェント プール UI の [診断] タブに表示されます。 Azure DevOps の [プロジェクトの設定] に移動し、[パイプライン] の [エージェント プール] を選んでエージェント プールを選び、[診断] を選んで、エージェント名をメモします。

Azure portal で、Azure 仮想マシン スケール セットの [インスタンス] 一覧内の関連付けられた仮想マシンを探します。

インスタンスを選び、[接続] を選び、調査を行います。

調査が終わった後に保存したエージェントを削除するには、Azure DevOps の [プロジェクトの設定] に移動し、[パイプライン] の [エージェント プール] を選び、エージェント プールを選びます。 [診断] というタブを選びます。 [Agents saved for investigation] (調査対象として保存したエージェント) カードでエージェントを探し、[削除] を選びます。 これでエージェントはプールから削除され、関連付けられた仮想マシンが削除されます。

よく寄せられる質問

• Azure 仮想マシン スケール セット エージェント
  • スケール セットを作成する
    • オーケストレーション モード
  • スケール セット エージェント プールを作成する
  • スケール セット エージェント プールを使う
  • Azure Pipelines でスケール セットを管理する方法
  • パイプライン エージェントの構成のカスタマイズ
  • カスタム スクリプト拡張機能を使った仮想マシンのスタートアップのカスタマイズ
  • スケール セット エージェントのライフサイクル
  • カスタム イメージ、ソフトウェア、またはディスク サイズを使ってスケール セットを作成する
  • 新しいカスタム イメージを使って既存のスケール セットを更新する
  • サポート対象のオペレーティング システム
    • 既知の問題
  • 問題のトラブルシューティング
    • 異常なエージェント
  • よく寄せられる質問
    • 一般的な問題とその解決策を教えてください。
      • アイドル状態のエージェントが想定よりも多く見えることがよくあります
      • Virtual Machine Scale Sets スケール アップが、想定されている 5 分間隔で実行されない
      • Azure DevOps Linux VM Scale Set がパイプラインの開始によく失敗します
      • エージェント プールのオプション [Automatically tear down virtual machines after every use] (仮想マシンの使用後に毎回自動的に破棄する) をオンにしましたが、想定どおりに VM の再イメージ化が行われず、キューへの格納時に新しいジョブを取得するだけであることがわかりました
      • VM の再起動時、Virtual Machine Scale Sets がエージェントをオフラインとして表示する
      • コスト管理で Virtual Machine Scale Sets の複数のタグ (_AzureDevOpsElasticPoolTimeStamp など) が表示されます
      • 新しいスケール セット エージェント プールを作成できず、同じ名前のプールが既に存在するというエラー メッセージが表示されます
      • Virtual Machine Scale Sets メンテナンス ジョブがエージェントで実行されないまたはログを取得しない
      • Virtual Machine Scale Sets のスクリプトで AzDevOps をプライマリ管理者に指定すると、スケール セット インスタンスのエージェント構成に問題が発生することがあります
      • ネットワーク セキュリティとファイアウォールの構成が原因で、スケール セット インスタンスへのエージェント拡張機能のインストールが失敗します
      • スケール セット エージェント構成スクリプトが Add-MpPreference を呼び出し、エージェントで Windows Defender を構成する理由
      • プール サイズを大きくしたいと考えています。 どのような点を考慮すればよいですか?

一般的な問題とその解決策を教えてください。

アイドル状態のエージェントが想定よりも多く見えることがよくあります

この原因の詳細については、「Azure Pipelines がスケール セットを管理する方法」を参照してください。 スケーリング操作全体で Azure Pipelines の目標は、待機しているアイドル状態のエージェントを目的の数に抑えることです。 プールのスケールアウトとスケールインが遅い。 1 日の中で、朝は要求がキューに格納されるのでプールはスケールアウトし、夕方には負荷が落ち着くのでスケールインします。 指定した制約に合わせて Azure Pipelines は徐々に収束するため、これは想定される動作です。

Virtual Machine Scale Sets スケール アップが、想定されている 5 分間隔で実行されない

スケーリング ジョブは 5 分間隔で実行されますが、1 つの操作しか処理されない場合、5 分以内にスケールアップが行われないことがあります。現在、これは仕様です。

Azure DevOps Linux VM Scale Set がパイプラインの開始によく失敗します

スケール セット エージェントで問題が発生したときに最初に確認すべき場所は、エージェント プールの [診断] タブです。

また、デバッグのために異常な VM を保存することを検討してください。 詳細については、「異常なエージェント」を参照してください。

保存されたエージェントは、削除しない限り、そこに残ります。 エージェントが 10 分以内にオンラインにならない場合は、異常とマークされ、可能であれば保存されます。 保存された状態で保持される VM は 1 つだけです。 (VM の再起動やイメージに何かが起こったために) エージェントが予期せずオフラインになった場合、調査のために保存されることはありません。

エージェントの起動に失敗した VM のみが保存されます。 VM が作成時に失敗状態になった場合は、保存されません。 この場合、[診断] タブのメッセージは "起動できませんでした" ではなく、"deleting unhealthy machine" (異常なマシンを削除中です) になります。

エージェント プールのオプション [Automatically tear down virtual machines after every use] (仮想マシンの使用後に毎回自動的に破棄する) をオンにしましたが、想定どおりに VM の再イメージ化が行われず、キューへの格納時に新しいジョブを取得するだけであることがわかりました

毎回のビルド後に VM を破棄するオプションは、Windows Server とサポートされる Linux イメージの場合にのみ機能します。 Windows クライアント イメージの場合はサポートされていません。

VM の再起動時、Virtual Machine Scale Sets がエージェントをオフラインとして表示する

VM の再起動時にエージェントがオフラインと表示されるのは、正常な動作です。 エージェント サービスは、systemd コンテキストでのみ動作します。 ただし、何らかの理由でマシンが再起動した場合、異常な VM と見なされ、削除されます。 詳細については、「異常なエージェント」を参照してください。

エージェントまたは仮想マシンが起動に失敗した、Azure DevOps に接続できない、または予期せずオフラインになった場合、Azure DevOps はエージェント プールの [診断] タブにエラーをログし、関連付けられた仮想マシンの削除を試みます。 ネットワーク構成、イメージのカスタマイズ、保留中の再起動により、これらの問題が発生する可能性があります。 この問題を回避するには、イメージのソフトウェア更新プログラムを無効にします。 また、デバッグ対象の VM に接続し、ログを収集することで、問題の調査に役立てることもできます。

コスト管理で Virtual Machine Scale Sets の複数のタグ (_AzureDevOpsElasticPoolTimeStamp など) が表示されます

プールが作成されると、スケール セットが使用中とマークするタグがスケール セットに追加されます (2 つのプールが同じスケール セットを使うことを避けるため)。また、構成ジョブが実行されるたびに (2 時間ごとに) 更新されるタイムスタンプに別のタグが追加されます。

新しいスケール セット エージェント プールを作成できず、同じ名前のプールが既に存在するというエラー メッセージが表示されます

スケール セットを削除してもタグは残るので、This virtual machine scale set is already in use by pool <pool name> のようなエラー メッセージを受け取ることがあります。 エージェント プールが削除された後に、ユーザーがスケール セットからタグを削除しようとしても、これはベストエフォート型の試行なので、ユーザーは 3 回再試行してあきらめます。 また、どのエージェント プールにも使われていない仮想マシン スケール セットを新しいものに割り当てることができない期間は最長 2 時間生じることがあります。 これを修正するには、その時間間隔が経過するまで待つか、Azure portal からスケール セットのタグを手動で削除します。 Azure portal でスケール セットを表示するときに、左側の [タグ] リンクを選び、 _AzureDevOpsElasticPool というラベルのタグを削除します。

Virtual Machine Scale Sets メンテナンス ジョブがエージェントで実行されないまたはログを取得しない

メンテナンス ジョブは 24 時間ごとに 1 回実行されます。 この時間より前に VM がいっぱいになる可能性があります。 VM のディスク サイズを大きくし、パイプラインにコンテンツを削除するスクリプトを追加することを検討してください。

Virtual Machine Scale Sets のスクリプトで AzDevOps をプライマリ管理者に指定すると、スケール セット インスタンスのエージェント構成に問題が発生することがあります

仮想マシン スケール セットのスクリプトで AzDevOps をプライマリ管理者に指定した場合、スケール セット インスタンスでのエージェント構成に問題が発生することがあります (ユーザーのパスワードが既に存在する場合に変更されます)。

この問題は、エージェント拡張機能スクリプトがユーザー AzDevOps を作成し、そのパスワードを変更しようとするために発生します。

ネットワーク セキュリティとファイアウォールの構成が原因で、スケール セット インスタンスへのエージェント拡張機能のインストールが失敗します

拡張機能は、 https://vstsagentpackage.azureedge.net/agent からビルド エージェント ファイルをダウンロードできる必要があります。また、ビルド エージェントは Azure DevOps Services に登録できる必要があります。 このインスタンスでこの URL と Azure DevOps Services 関連の IP と URL を開けることを確認してください。 ファイアウォールでブロックを解除する必要がある IP と URL については、「許可される IP アドレスとドメイン URL」を参照してください。

スケール セット エージェント構成スクリプトが Add-MpPreference を呼び出し、エージェントで Windows Defender を構成する理由

パフォーマンスと信頼性を向上させるために、構成スクリプトは C:\ と D:\ を含む Add-MpPreference を ExclusionPath と指定して呼び出します。これにより、エージェント上にあるこれらのフォルダー内のファイルに対する Windows Defender のスケジュールされたリアルタイム スキャンが無効になります。 既定の動作を変更するには、ELASTIC_POOLS_SKIP_DEFENDER_EXCLUSION という名前の環境変数をtrue に設定します。

プール サイズを大きくしたいと考えています。 どのような点を考慮すればよいですか?

プールのサイズを増やす前に、Virtual Machine Scale Sets プールに構成された Azure 仮想ネットワークに、すべての新しいエージェントを収容できる十分な "アドレス空間" の範囲があることを確認します。 そうでない場合、"Failed to increase capacity. Subnet azure-devops-agent-pool-fabrikam-fiber with address prefix 12.123.45.224/28 does not have enough capacity for 5 IP addresses" (容量を増やすことができませんでした。アドレス プレフィックスが 12.123.45.224/28 のサブネット azure-devops-agent-pool-fabrikam-fiber には 5 個の IP アドレスを収容できる容量がありません) のようなエラーを受け取ることがあります。