次の方法で共有


Azure Pipelines エージェント

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure Pipelines を使用したコードのビルドまたはソフトウェアのデプロイには、少なくとも 1 つのエージェントが必要です。 コードベースとチームの成長に合わせて、より多くのエージェントが必要になります。

パイプラインを実行すると、システムによって 1 つ以上のジョブが開始されます。 エージェントは、一度に 1 つのジョブを実行するエージェント ソフトウェアがインストールされたコンピューティング インフラストラクチャです。

Azure Pipelines には、さまざまな種類のエージェントが用意されています。

エージェントの種類 説明 可用性
Microsoft によってホストされるエージェント Microsoft によってホストおよび管理されるエージェント Azure DevOps Services
セルフホステッド エージェント 自分の VM でホストされている、自分が構成および管理するエージェント Azure DevOps Services、Azure DevOps Server
Managed DevOps Pools エージェント Managed DevOps Pools は、完全なマネージド サービスで、エージェント駆動の仮想マシンまたはコンテナーが自分の Azure サブスクリプションではなく、Microsoft Azure サブスクリプションに存在します。 Azure DevOps Services
Azure 仮想マシン スケール セット エージェント Azure Virtual Machine Scale Sets を使用するセルフホステッド エージェントの一種で、需要に合わせて自動スケーリングできます。

自動スケーラブルなセルフホステッド エージェント プールの使用を検討している場合は、Managed DevOps プールを確認することをお勧めします。 詳細については、「マネージド DevOps プールと Azure Virtual Machine Scale Set エージェントのマネージド DevOps プールの比較」の概要を参照してください。
Azure DevOps Services

ジョブは、エージェントのホスト マシンで直接実行するか、コンテナーで実行することができます。

Microsoft によってホストされるエージェント

パイプラインが Azure Pipelines にある場合は、Microsoft ホステッド エージェントを使ってジョブを実行する便利なオプションがあります。 Microsoft によってホストされているエージェントを使用すると、メンテナンスとアップグレードが自動的に行われます。 パイプラインで指定した VM イメージの最新バージョンが常に取得されます。 パイプラインを実行するたびに、パイプラインの各ジョブに対して新しい仮想マシンが取得されます。 仮想マシンは 1 つのジョブの後に破棄されます (つまり、コードのチェックアウトなど、ジョブが仮想マシン ファイル システムに加えた変更は、次のジョブで使用できなくなります)。 Microsoft ホステッド エージェントは、VM 上で直接またはコンテナー内でジョブを実行できます。

Azure Pipelines には、Azure Pipelines という名前の事前定義されたエージェント プールと、Microsoft ホステッド エージェントが用意されています。

多くのチームにとって、ジョブを実行するにはこれが最も簡単な方法です。 まず試してみて、ビルドまたはデプロイに対して機能するかどうかを確認できます。 そうされない場合は、スケール セット エージェントまたはセルフホステッド エージェントを使用できます。

ヒント

Microsoft ホステッド エージェントは無料で試すことができます。

詳細については、「Microsoft によってホストされるエージェント」を参照してください

セルフホステッド エージェント

ジョブを実行するために独自に設定および管理するエージェントは、セルフホステッド エージェントです。 Azure Pipelines または Azure DevOps Server でセルフホステッド エージェントを使用できます。 セルフホステッド エージェントを使用すると、ビルドとデプロイに必要な依存ソフトウェアのインストールをより細かく制御できます。 また、マシン レベルのキャッシュと構成は、次回の実行まで保持されるため、起動の速度を向上させることができます。

注意

1 台のマシンに複数のエージェントをインストールできますが、1 台のマシンに 1 つのエージェントのみをインストールすることを強くお勧めします。 複数のエージェントをインストールすると、パフォーマンスやパイプラインの結果に悪影響が及ぶ可能性があります。

ヒント

セルフホステッド エージェントをインストールする前に、Microsoft がホストするエージェント プールが自動的に動作するかどうかを確認できます。 多くの場合、Microsoft がホストするエージェント プールが最も簡単な方法です。 お試しください

エージェントは、Linux、macOS、または Windows マシンにインストールできます。 Docker コンテナーにエージェントをインストールすることもできます。 セルフホステッド エージェントのインストールについては、以下を参照してください。

注意

macOS 上では、./config.sh の実行時に tar ファイル内の各アセンブリに対してゲートキーパー保護が表示されないように、ダウンロード アーカイブの特殊な属性をクリアする必要があります。 次のコマンドを実行すると、ファイルの拡張属性をクリアできます。

xattr -c vsts-agent-osx-x64-V.v.v.tar.gz  ## replace V.v.v with the version in the filename downloaded.

# then unpack the gzip tar file normally:

tar xvfz vsts-agent-osx-x64-V.v.v.tar.gz

マシンにエージェントをインストールした後は、ジョブに必要な他のソフトウェアをそのマシンにインストールできます。

注意

エージェントには広い下位互換性があります。 より新しいバージョンのエージェントが Azure DevOps に要求されていない限り、おそらくすべてのバージョンのエージェントがすべての Azure DevOps バージョンと互換性があります。

最新バージョンのエージェントのみをサポートしているのは、それがすべての最新のパッチとバグ修正が保証されている唯一のバージョンだからです。

Node ランナーのバージョン

エージェントには、異なる Node ハンドラーを使用するターゲット タスクをサポートするために、複数のバージョンの NodeJS ライブラリが付属しています。

すべての公式 Azure DevOps タスクでは、ユニバーサル ハンドラーとして Node 20が使用されますが、お客様は、サポートが終了した Node 6、Node 10、または Node 16 ライブラリを使用するカスタム タスクを引き続き使用できます。 有効期間が終了した Node との下位互換性をサポートするために、指定された Node ランナーを手動でインストールするための次のセルフサービス方法を提供します。

  • Node 6 ランナーを手動でインストールします。 詳細については、ノード 6 のサポート を参照してください。

  • 古い Node 6 ライブラリを必要とするパイプラインで NodeTaskRunnerInstaller@0 タスクを使用します。

  • Node 6 を含むエージェント パッケージをインストールします。

    Azure Pipelines には、2 つのバージョンのエージェント パッケージが用意されています。

    • vsts-agent-* パッケージは Node 6 をサポートします。
    • pipelines-agent-* パッケージは Node 6 をサポートしていません。 このバージョンのパッケージは、今後既定のエージェント パッケージになります。

    サポートが終了した Node バージョンに依存するタスクを使用していない場合、および、サポートが終了した Node バージョンをエージェントのマシンにインストールしない場合は、https://github.com/microsoft/azure-pipelines-agent/releases セクションからエージェントをインストールできます。

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

Azure Virtual Machine Scale Set エージェントは、ニーズに合わせて自動スケールできるセルフホステッド エージェントの一種です。 この弾力性により、専用エージェントを常に実行する必要性が減少します。 Microsoft がホストするエージェントとは異なり、エージェントを実行するマシンのサイズとイメージに柔軟性があります。

Virtual Machine Scale Set、スタンバイ状態を維持するエージェントの数、スケール セット内の仮想マシンの最大数を指定し、Azure Pipelines がエージェントのスケーリングを管理します。

詳細については、「Azure 仮想マシン スケール セット エージェント」を参照してください。

ヒント

マネージド DevOps プールは、Azure DevOps Virtual Machine Scale Set エージェント プールを進化させる新しいサービスであり、カスタム プールのスケーラビリティと信頼性を向上させることで、カスタム プールの作成をさらに簡素化します。 Managed DevOps Pools は、完全なマネージド サービスで、Azure DevOps Virtual Machine Scale Set エージェント プールを使用する際は、エージェント駆動の仮想マシンがコンテナーが独自の Azure サブスクリプションではなく、Microsoft Azure サブスクリプションにあります。

自動スケーラブルなセルフホステッド エージェント プールの使用を検討している場合は、Managed DevOps プールを確認することをお勧めします。 詳細については、「マネージド DevOps プールと Azure Virtual Machine Scale Set エージェントのマネージド DevOps プールの比較」の概要を参照してください。

Managed DevOps Pools エージェント

Managed DevOps Pools を使用すると、開発チームは、チーム固有のニーズに合わせて調整された迅速かつ簡単に Azure DevOps エージェント プールを起動できます。

マネージド DevOps プール:

  • セキュリティのベスト プラクティスを実装する
  • は、コストとパフォーマンスのバランスを取るノブを提供します
  • は、最も一般的なシナリオのパスを提供します
  • カスタム プールの作成と保守に費やす時間が大幅に短縮されます。

マネージド DevOps プールは、Azure DevOps Virtual Machine Scale Set エージェント プールの進化であり、カスタム プールのスケーラビリティと信頼性を向上させることで、カスタム プールの作成をさらに簡略化します。 Managed DevOps Pools は、完全なマネージド サービスで、Azure DevOps Virtual Machine Scale Set エージェント プールを使用する際は、エージェント駆動の仮想マシンがコンテナーが独自の Azure サブスクリプションではなく、Microsoft Azure サブスクリプションにあります。 詳細については、「Managed DevOps Pools」のドキュメントを参照してください。

並列ジョブ

並列ジョブは、組織内で同時に実行できるジョブ数を表します。 組織の並列ジョブが 1 つの場合、組織内ではジョブを一度に 1 つずつ実行できます。追加の並列ジョブは、最初のジョブが完了するまでキューに格納されます。 同時に 2 つのジョブを実行するには、2 つの並列ジョブが必要です。 Azure Pipelines では、Microsoft ホステッド インフラストラクチャまたは独自の (セルフホステッド) インフラストラクチャ上で並列ジョブを実行できます。

Microsoft は、少なくとも 1 つの並列ジョブを含む Free レベルのサービスを既定ですべての組織に提供しています。 同時に実行する必要があるパイプライン数によっては、複数の Microsoft ホステッドまたはセルフホステッド エージェントを同時に使うには、さらに多くの並列ジョブが必要になる場合があります。 並列ジョブとさまざまな Free レベルのサービスの詳細については、Azure Pipelines の並列ジョブに関する記事を参照してください。

複数のエージェントを同時に使うには、さらに多くの並列ジョブが必要になる場合があります。

重要

Azure DevOps Server 2019 以降では、リリースでセルフホステッド同時実行ジョブの料金を支払う必要はありません。 使用しているエージェントの数によってのみ制限されます。

機能

すべてのセルフホステッド エージェントには、何ができるかを示す一連の機能があります。 ケーパビリティは、エージェント・ソフトウェアによって自動的にディスカバーされる名前と値のペア (システム機能と呼ばれる システム機能、またはユーザーが定義する機能 (ユーザー機能) のいずれかです。

エージェント ソフトウェアによって、さまざまなシステム機能が自動的に判断されます。たとえば、マシンの名前、オペレーティング システムの種類、マシンにインストールされている特定のソフトウェアのバージョンなどです。 また、マシンで定義された環境変数もシステム機能の一覧に自動的に表示されます。

注意

環境変数を機能として格納することは、エージェントの実行時に、格納された機能の値が環境変数の設定に使われることを意味します。 また、エージェントの実行中に行われた環境変数に対する変更は、どのタスクでも取得および使用されません。 変更する環境変数の機密性が高く、機能として格納したくない場合、それらが無視されるようにするには、無視する変数のコンマ区切り一覧を使って VSO_AGENT_IGNORE 環境変数を設定します。 たとえば、PATH は重要な変数であり、ソフトウェアをインストールする場合に無視することがあります。

パイプラインを作成するときに、エージェントに特定の要求を指定します。 システムからジョブが送信される対象は、パイプラインに指定された要求と一致する機能を持つエージェントのみです。 そのため、エージェント機能を使って、特定のエージェントにジョブを指示することができます。

注意

要求と機能はセルフホステッド エージェントで使うように設計されているので、ジョブをジョブの要件を満たすエージェントと対応付けることができます。 Microsoft でホストされるエージェントを使用する場合は、ジョブの要件に一致するエージェントのイメージを選択します。 Microsoft でホストされるエージェントに機能を追加することはできますが、Microsoft がホストするエージェントで機能を使用する必要はありません。

要求を構成する

YAML ビルド パイプラインに 1 つの要求を追加するには、demands: セクションに pool 行を追加します。

pool:
  name: Default
  demands: SpecialSoftware # exists check for SpecialSoftware

機能の存在をチェックすることも、機能の値と比較することもできます。 詳細については、「YAML スキーマ - Demands」を参照してください。

エージェント機能を構成する

バージョンとシステム機能を含むエージェントの詳細を表示し、ユーザー機能を管理するには、[エージェント プール] に移動し、目的のエージェントの [機能] タブを選びます。

  1. Web ブラウザーでエージェント プールに移動します。

    1. 組織にサインインします (https://dev.azure.com/{yourorganization})。

    2. [Azure DevOps][組織の設定] の順に選びます。

      [組織の設定] を選びます。

    3. [エージェント プール] を選択します。

      [エージェント プール] タブを選びます。

    1. プロジェクト コレクション (http://your-server/DefaultCollection) にサインインします。

    2. [Azure DevOps][コレクションの設定]の順に選択します。

      [コレクションの設定] を選びます。

    3. [エージェント プール] を選択します。

      [エージェント プール] を選びます。

    1. [Azure DevOps][コレクションの設定]の順に選択します。

      コレクションの設定 (2019)。

    2. [エージェント プール] を選択します。

      [エージェント プール] を選びます (2019)。

  2. [機能] タブに移動します。

    1. [エージェント プール] タブから、目的のエージェント プールを選びます。

      [エージェント プール] で、目的のエージェント プールを選びます。

    2. [エージェント] を選択し、目的のエージェントを選択します。

      [エージェント] を選んで、エージェントを選びます。

    3. [機能] タブを選択します。

      [機能] タブを選びます。

      注意

      Microsoft ホステッド エージェントでは、システム機能は表示されません。 Microsoft ホステッド エージェントにインストールされるソフトウェアの一覧については、「Microsoft ホステッド エージェントを使用する」をご覧ください。

    1. [エージェント プール] タブから、目的のプールを選択します。

      目的のプールを選びます。

    2. [エージェント] を選択し、目的のエージェントを選択します。

      [エージェント] を選んで、目的のエージェントを選びます。

    3. [機能] タブを選択します。

      エージェントの [機能] タブ。

    1. [エージェント プール] タブから、目的のプールを選択します。

      目的のタブを選びます (2019)。

    2. [エージェント] を選択し、目的のエージェントを選択します。

      目的のエージェントを選びます (2019)。

    3. [機能] タブを選択します。

      [機能] タブを選びます (2019)。

  3. エージェントに新しい機能を登録するには、[新しい機能を追加する] を選びます。

ヒント

セルフホステッド エージェントに新しいソフトウェアをインストールした後、新しい機能を表示するにはエージェントを再起動する必要があります。 詳細については、Windows エージェントの再起動Linux エージェントの再起動Mac エージェントの再起動に関する記事を参照してください。

通信

Azure Pipelines との通信

Azure DevOps Server との通信

エージェントは、どのジョブを実行する必要があるかを判定したり、ログやジョブの状態を報告したりするために Azure Pipelines または Azure DevOps Server と通信します。 エージェントは、常にこの通信を開始します。 エージェントから Azure Pipelines または Azure DevOps Server への HTTP または HTTPS を経由したすべてのメッセージが、そのエージェントをどのように構成しているかに依存します。 このプル モデルでは、次の例に示すように、エージェントを異なるトポロジで構成できます。

オンプレミス インストールのエージェントのトポロジ。

Azure DevOps Services のエージェントのトポロジ。

エージェントと Azure Pipelines またはAzure DevOps Server の間の一般的な通信パターンを次に示します。

  1. ユーザーは、エージェントをエージェント プールに追加することによってエージェントを Azure Pipelines または Azure DevOps Server に登録します。 エージェントをエージェント プールに登録するには、そのエージェント プールの管理者である必要があります。 エージェント プール管理者の ID は登録時にのみ必要であり、エージェントには保存されません。 エージェントと Azure Pipelines または Azure DevOps Server 間の以降の通信には使用されません。 登録が完了すると、エージェントは "リスナー OAuth トークン" をダウンロードし、それを使用してジョブ キューをリッスンします。

  2. エージェントは、HTTP の長いポーリングを使用して、Azure Pipelines/Azure DevOps Server のジョブ キューに新しいジョブ要求がポストされているかどうかをリッスンします。 ジョブが使用可能なとき、エージェントは、そのジョブとジョブ固有の OAuth トークンをダウンロードします。 Azure Pipelines/Azure DevOps Server は、パイプラインで指定されているスコープ指定された ID 用に有効期間の短いトークンを生成します。 トークンは、エージェントがそのジョブ内で Azure Pipelines または Azure DevOps Server 上のリソースにアクセスしたり、リソースを変更したりするために使用されます。 たとえば、ソース コードにアクセスしたり、テスト結果をアップロードしたりします。

  3. そのジョブが完了した後に、エージェントはジョブ固有の OAuth トークンを破棄して元に戻り、リスナー OAuth トークンを使用して新しいジョブ要求が存在するかどうかを確認します。

エージェントと Azure Pipelines/Azure DevOps Server の間で交換されるメッセージのペイロードは、非対称暗号化を使用してセキュリティで保護されます。 各エージェントには公開キーと秘密キーのペアがあり、公開キーは登録中にサーバーと交換されます。 サーバーは、その公開キーを使用してジョブのペイロードを暗号化してから、それをエージェントに送信します。 エージェントは、秘密キーを使用してジョブの内容の暗号化を解除します。 この方法は、エージェントと交換するときに、パイプラインまたは変数グループに保存されているシークレットを保護します。

注意

エージェントは、UTF-8 クライアント エンコード出力をサポートします。 ただし、システムのエンコードが UTF-8 とは異なる場合は、ログの出力に問題が発生する可能性があります。 たとえば、ログにはシステムのエンコードで認識されない文字が含まれている可能性があるため、文字化けした記号や欠落している記号として表示される可能性があります。

ターゲット サーバーにデプロイするための通信

エージェントを使用して成果物を一連のサーバーにデプロイする場合、そのエージェントには、これらのサーバーへの "見通し線" 接続が必要です。 Microsoft ホステッド エージェント プールは、既定で Azure Web サイトや Azure で実行されているサーバーに接続されています。

注意

Azure リソースが Azure 仮想ネットワークで実行されている場合、Microsoft ホステッド エージェントが配置されているエージェント IP の範囲を取得できるので、Azure VNet に対してエージェントによるアクセスを許可するファイアウォール規則を構成できます。

オンプレミス環境に Microsoft でホストされるエージェント プールへの接続がない場合 (通常は中間にファイアウォールがあることが理由になっているケースです)、オンプレミス コンピューターでセルフホステッド エージェントを手動で構成する必要があります。 次の概略図に示すように、Azure Pipelines または Team Foundation Server に接続するには、これらのエージェントにターゲットのオンプレミス環境への接続とインターネットへのアクセスが必要です。

オンプレミス環境のエージェント接続

認証

エージェントを登録するには、エージェント プール内の管理者ロールのメンバーである必要があります。 エージェント プール管理者の ID は登録時にのみ必要であり、エージェントには保存されません。 エージェントと Azure Pipelines または Azure DevOps Server 間の以降の通信には使用されません。 さらに、エージェントを構成するために、サーバー上のローカル管理者であることも必要です。

エージェントを登録するときに次の認証の種類から選択すると、エージェントのセットアップから、各認証の種類に必要な特定の追加情報の入力を求められます。 詳細については、「セルフホステッド エージェントの認証オプション」を参照してください。

Azure DevOps Server の Windows エージェントには、次の 2 つの追加認証オプションがあります。

  • [ネゴシエート]: New Technology LAN Manager (NTLM) や Kerberos などの Windows 認証スキームを使用して、サインインしているユーザー以外のユーザーとして、TFS または Azure DevOps Server に接続します。 [交渉] を選択すると、資格情報の入力を求められます。
  • [統合]: (既定) NTLM や Kerberos などの Windows 認証スキームを介してサインインしているユーザーの資格情報を使って、Windows エージェントを Azure DevOps Server に接続します。 この方法を選んだ後で、資格情報の入力を求められることはありません。

重要

代替、ネゴシエート、または統合認証を使用するための認証方法をサポートするようにサーバーを構成する必要があります。

エージェントの登録に使用される認証方法は、エージェントの登録時にのみ使用されます。 登録後にエージェントがどのように Azure Pipelines と通信するかの詳細については、「Azure Pipelines または Azure DevOps Server との通信」を参照してください。

対話型とサービス

セルフホステッド エージェントは、サービスまたは対話型プロセスのどちらかとして実行できます。

エージェントを構成したら、それが動作することを確認するために、まず対話モードで試してみることをお勧めします。 次に、運用環境で使用する場合、稼働状態を確実に維持するために、エージェントを次のいずれかのモードで実行することをお勧めします。 また、これらのモードによって、マシンが再起動された場合にエージェントが自動的に起動されることも確認されます。

  1. サービスとして。 オペレーティング システムのサービス マネージャーを使用して、エージェントのライフサイクルを管理できます。 さらに、エージェントの自動アップグレードのエクスペリエンスは、サービスとして実行されているときの方が優れています。

  2. 自動ログオンが有効になっている対話型プロセスとして。 場合によっては、運用環境での使用のためにエージェントの対話的な実行が必要になることがあります (UI テストを実行するためなど)。 エージェントがこのモードで実行するように構成されている場合は、スクリーン セーバーも無効になります。 一部のドメイン ポリシーでは、自動ログオンを有効にしたり、スクリーン セーバーを無効にしたりできないことがあります。 このような場合は、ドメイン ポリシーからの除外を求めるか、ドメイン ポリシーが適用されないワークグループ コンピューターでエージェントを実行する必要があります。

    注意

    自動ログオンを有効にした場合、またはスクリーン セーバーを無効にした場合にはセキュリティ リスクがあります。なぜなら、他のユーザーがコンピューターに近づいて、自動的にログオンするアカウントを使用できるからです。 エージェントをこのように構成する場合は、そのコンピューターが物理的に保護されている (たとえば、セキュリティで保護された施設に配置されている) ことを確認する必要があります。 リモート デスクトップを使用して、エージェントが自動ログオンで実行されているコンピューターにアクセスする場合、リモート デスクトップを閉じると、コンピューターがロックされ、このエージェントで実行されるすべての UI テストが失敗する可能性があります。 この問題を回避するには、tscon コマンドを使用してリモート デスクトップから切断します。 次に例を示します。

    %windir%\System32\tscon.exe 1 /dest:console

エージェント アカウント

エージェントをサービスとして実行するか、対話的に実行するかに関わらず、エージェントの実行に使うコンピューター アカウントを選択できます エージェント アカウントの選択は、ビルドおよびデプロイ ジョブで実行されるタスクのニーズにのみ依存します。

たとえば、Windows 認証を使用して外部サービスにアクセスするタスクを実行するには、そのサービスにアクセスできるアカウントを使用してエージェントを実行する必要があります。 ただし、ブラウザーを必要とする Selenium またはコード化された UI テストなどの UI テストを実行している場合は、そのエージェント アカウントのコンテキストでブラウザーが起動されます。

Windows では、ネットワーク サービスやローカル サービスなどのサービス アカウントの使用を検討する必要があります。 これらのアカウントはアクセス許可が制限されており、パスワードの有効期限が切れないため、時間の経過と共に必要なエージェントの管理が少なくなります。

これらの資格情報は、エージェントを Azure Pipelines または Azure DevOps Server に登録するときに使用する資格情報とは異なります。

エージェントのバージョンとアップグレード

Azure Pipelines のエージェント ソフトウェアは数週間に 1 回更新されます。 エージェントのバージョンは {major}.{minor} という形式です。 たとえば、エージェントのバージョンが 2.1 である場合、メジャー バージョンは 2 であり、マイナー バージョンは 1 です。

Microsoft ホステッド エージェントは常に最新の状態に保たれます。 新しいバージョンのエージェントが マイナー バージョンでのみ異なる場合、Azure Pipelines はセルフホステッド エージェントを自動的に更新できます。 この設定は、エージェント プールで構成できます。エージェントを選択し、[設定] では既定値が有効になっています。 プラットフォームの機能またはパイプラインで使われているタスクのいずれかに新しいバージョンのエージェントが必要な場合は、アップグレードが必要です。

セルフホステッド エージェントを対話形式で実行する場合、または新しいメジャー バージョンのエージェントを使用できる場合、状況に応じてエージェントを手動でアップグレードする必要があります。 組織の [エージェント プール] タブから、エージェントを簡単にアップグレードすることができます。 互換性のあるエージェントがないとパイプラインを実行できない

セルフホステッド エージェントを更新するには

  1. [プロジェクトの設定][エージェント プール] に移動します。

    [プロジェクトの設定]、[エージェント プール]

  2. エージェント プールを選び、[すべてのエージェントの更新] を選びます。

    すべてのエージェントの更新

    また、エージェントを個別に更新するには、[...] メニューから [エージェントの更新] を選びます。

    エージェントの更新

  3. [更新] を選んで更新を確認します。

    [すべてのエージェントの更新] の確認

  4. 更新要求は、プール内のエージェントごとにキューに格納され、現在実行中のジョブが完了すると実行されます。 通常、アップグレードにかかる時間はわずかです。エージェント ソフトウェアの最新バージョン (約 200 MB) をダウンロードし、それを展開し、新しいバージョンを使ってエージェントを再起動するだけの時間です。 エージェントの状態は、[エージェント] タブで監視できます。

エージェント ソフトウェアは、Azure DevOps Server の更新ごとに更新されます。 エージェントのバージョンは {major}.{minor} という形式です。 たとえば、エージェントのバージョンが 2.1 である場合、メジャー バージョンは 2 であり、マイナー バージョンは 1 です。

Azure DevOps Server に新しいバージョンのエージェントがあり、その新しいエージェントのマイナー バージョンのみが異なる場合は、通常、自動的にアップグレードできます。 プラットフォームの機能またはパイプラインで使われているタスクのいずれかに新しいバージョンのエージェントが必要な場合は、アップグレードが必要です。 Azure DevOps Server 2019 以降では、新しいサーバーのリリースを待つ必要はありません。 新しいバージョンのエージェントをアプリケーション層にアップロードできます。また、そのバージョンはアップグレードとして提供されます。

エージェントを対話形式で実行する場合、または新しいメジャー バージョンのエージェントを使用できる場合、状況に応じてエージェントを手動でアップグレードする必要があります。 プロジェクト コレクションで [エージェント プール] タブから、エージェントと簡単にアップグレードできます。 互換性のあるエージェントがないとパイプラインは実行できません。

エージェントのバージョンを確認するには、「エージェント機能を構成する」で説明されているように、[エージェント プール] に移動し、目的のエージェントの [機能] タブを選びます。

プログラムでエージェントの更新をトリガーするには、セクション「特定のエージェント プールに対してプログラムでエージェントの更新をトリガーするにはどうすればよいですか?」で説明されているように、エージェントの更新 API を使用できます。

注意

インターネットにアクセスできないサーバーの場合、ローカル ファイルとして使うために、エージェントの zip ファイルを手動で次のフォルダーにコピーします。 Agents フォルダーが存在しない場合は作成します。

  • Windows: %ProgramData%\Microsoft\Azure DevOps\Agents
  • Linux: usr/share/Microsoft/Azure DevOps/Agents
  • macOS: usr/share/Microsoft/Azure DevOps/Agents

Agents フォルダーが存在しない場合は作成します。

エージェントディレクトリ構造

パイプライン ジョブがエージェントで実行されると、ソース コード、バイナリ、成果物を格納するディレクトリ構造が作成されます。

エージェントのホーム ディレクトリは、エージェントがインストールされているディレクトリです。 通常、ディレクトリは次の場所にあります。

  • Microsoft がホストするエージェント: Windows でのC:\agents\<agent version>、macOS での /Users/runner/runners/<agent version>、Linux での /home/vsts/agents/<agent version>
  • セルフホステッド エージェント: Windows でのC:\agent、macOS での Users/<username>/agent (~/agent)、Linux での /home/vsts/agent

エージェントの作業ディレクトリには、ソースとジョブの出力が格納されているワークスペースが含まれています。 通常、作業ディレクトリは次の場所にあります。

  • Microsoft がホストするエージェント: Windows でのC:\a、macOS での /Users/runner/work、Linux での/home/vsts/work
  • セルフホステッド エージェント: Windows でのC:\agent\_work、macOS での ~/agent/work、Linux での /home/agent/_work

作業ディレクトリ構造は次のとおりです。


    - /work directory
        - /1 build directory/pipeline workspace
            - /s source/working directory
            - /b binaries directory
            - /a artifacts staging directory
            - /TestResults Test results directory
ディレクトリ 説明 使用例 定義済みの変数
エージェントのホーム ディレクトリ エージェントがインストールされている場所 Microsoft でホストされるエージェント:
   Windows: C:\agents\3.248.0
   Linux: /home/vsts/agents/3.248.0
   macOS: /Users/runner/runners/3.248.0
自己ホスト エージェント:
   Windows: C:\agent
   Linux: home/agent
   macOS: ~/agent
Agent.HomeDirectory
作業ディレクトリ エージェントがソース コード、バイナリ、成果物を格納する場所 Microsoft でホストされるエージェント:
   Windows: C:\a
   Linux: /home/vsts/work
   macOS: /Users/runner/work
自己ホスト エージェント:
   Windows: C:\agent\_work
   Linux: /home/agent/_work
   macOS: ~/agent/work
Agent.WorkFolder
Agent.RootDirectory
System.WorkFolder
ディレクトリ/ワークスペースをビルドする パイプライン ジョブが実行される場所 Microsoft でホストされるエージェント:
   Windows: C:\a\1
   Linux: /home/vsts/work/1
   macOS: /Users/runner/work/1
自己ホスト エージェント:
   Windows: C:\agent\_work\1
   Linux: /home/agent/_work/1
   macOS: ~/agent/work/1
Agent.BuildDirectory
Pipeline.Workspace
s - ソース/作業ディレクトリ リポジトリからチェックアウトされたソース コードが含まれています。 ジョブに複数の checkout ステップがある場合、ソース コードはリポジトリの名前の付いたディレクトリに sのサブフォルダーとしてチェックアウトされます。 Microsoft でホストされるエージェント:
   Windows: C:\a\1\s
   Linux: /home/vsts/work/1/s
   macOS: /Users/runner/work/1/s
自己ホスト エージェント:
   Windows: C:\agent\_work\1\s
   Linux: /home/agent/_work/1/s
   macOS: ~/agent/work/1/s
Build.SourcesDirectory
Build.RepositoryLocalPath
System.DefaultWorkingDirectory
b - バイナリ ディレクトリ ビルド出力を格納します。 Microsoft でホストされるエージェント:
   Windows: C:\a\1\b
   Linux: /home/vsts/work/1/b
   macOS: /Users/runner/work/1/b
自己ホスト エージェント:
   Windows: C:\agent\_work\1\b
   Linux: /home/agent/_work/1/b
   macOS: ~/agent/work/1/b
Build.BinariesDirectory
a - アーティファクトステージングディレクトリ ビルド成果物を格納します。 自己ホスト エージェントでの実行の間にクリーンアップされます。 Microsoft でホストされるエージェント:
   Windows: C:\a\1\a
   Linux: /home/vsts/work/1/a
   macOS: /Users/runner/work/1/a
自己ホスト エージェント:
   Windows: C:\agent\_work\1\a
   Linux: /home/agent/_work/1/a
   macOS: ~/agent/work/1/a
Build.StagingDirectory
Build.ArtifactStagingDirectory
System.ArtifactsDirectory
TestResults ディレクトリ テスト結果を格納します。 自己ホスト エージェントでの実行の間にクリーンアップされます。 Microsoft でホストされるエージェント:
   Windows: C:\a\1\TestResults
   Linux: /home/vsts/work/1/TestResults
   macOS: /Users/runner/work/1/TestResults
自己ホスト エージェント:
   Windows: C:\agent\_work\1\TestResults
   Linux: /home/agent/_work/1/TestResults
   macOS: ~/agent/work/1/TestResults
Common.TestResultsDirectory

Microsoft がホストするエージェントでは、実行ごとに異なるエージェントが使用されるため、実行間で作業ディレクトリは保持されません。 セルフホステッド エージェントでは、成果物のステージング ディレクトリとテスト結果のディレクトリのみが、実行の間に既定でクリーンアップされます。 ワークスペースのクリーン オプションの詳細については、ワークスペースを参照してください。

定義済み変数の詳細については、「定義済み変数 」を参照してください。

よく寄せられる質問

最新のエージェント バージョンを使っていることを確認するにはどうすればよいですか?

  1. [エージェント プール] タブに移動します。

    1. 組織にサインインします (https://dev.azure.com/{yourorganization})。

    2. [Azure DevOps][組織の設定] の順に選びます。

      [組織の設定] を選びます。

    3. [エージェント プール] を選択します。

      [エージェント プール] タブを選びます。

    1. プロジェクト コレクション (http://your-server/DefaultCollection) にサインインします。

    2. [Azure DevOps][コレクションの設定]の順に選択します。

      [コレクションの設定] を選びます。

    3. [エージェント プール] を選択します。

      [エージェント プール] を選びます。

    1. [Azure DevOps][コレクションの設定]の順に選択します。

      コレクションの設定 (2019)。

    2. [エージェント プール] を選択します。

      [エージェント プール] を選びます (2019)。

  2. エージェントを含むプールをクリックします。

  3. エージェントが有効になっていることを確認します。

  4. [機能] タブに移動します。

    1. [エージェント プール] タブから、目的のエージェント プールを選びます。

      [エージェント プール] で、目的のエージェント プールを選びます。

    2. [エージェント] を選択し、目的のエージェントを選択します。

      [エージェント] を選んで、エージェントを選びます。

    3. [機能] タブを選択します。

      [機能] タブを選びます。

      注意

      Microsoft ホステッド エージェントでは、システム機能は表示されません。 Microsoft ホステッド エージェントにインストールされるソフトウェアの一覧については、「Microsoft ホステッド エージェントを使用する」をご覧ください。

    1. [エージェント プール] タブから、目的のプールを選択します。

      目的のプールを選びます。

    2. [エージェント] を選択し、目的のエージェントを選択します。

      [エージェント] を選んで、目的のエージェントを選びます。

    3. [機能] タブを選択します。

      エージェントの [機能] タブ。

    1. [エージェント プール] タブから、目的のプールを選択します。

      目的のタブを選びます (2019)。

    2. [エージェント] を選択し、目的のエージェントを選択します。

      目的のエージェントを選びます (2019)。

    3. [機能] タブを選択します。

      [機能] タブを選びます (2019)。

  5. Agent.Version 機能を探します。 この値は、公開されている最新のエージェント バージョンに対してチェックできます。 一覧表示されている最も高いバージョン番号については、Azure Pipelines エージェントに関するページを参照し、確認します。

  6. 各エージェントは、新しいバージョンのエージェントを必要とするタスクを実行すると、自動的に更新されます。 一部のエージェントを手動で更新する場合は、プールを右クリックし、[すべてのエージェントの更新] を選びます。

Azure DevOps Server プールの一部であるエージェントを更新できますか?

はい。 Azure DevOps Server 2019 以降では、ローカル ディスク上のエージェント パッケージ ファイルを検索するようにサーバーを構成できます。 この構成により、リリース時にサーバーに付属した既定のバージョンがオーバーライドされます。 このシナリオは、サーバーがインターネットにアクセスできない場合にも適用されます。

  1. インターネットにアクセスできるコンピューターから、Azure Pipelines Agent GitHub リリース ページの最新バージョンのエージェント パッケージ ファイル (.zip または .tar.gz 形式) をダウンロードします。

  2. 任意の方法 (USB ドライブ、ネットワーク転送など) を使って、ダウンロードしたパッケージ ファイルを各 Azure DevOps Server アプリケーション層に転送します。 エージェント ファイルを %ProgramData%\Microsoft\Azure DevOps\Agents フォルダーの下に配置します。 Agents フォルダーが存在しない場合は作成します。

  3. すべての設定が完了しました。 Azure DevOps Server では、エージェントが更新されるたびにローカル ファイルが使われるようになります。 各エージェントは、新しいバージョンのエージェントを必要とするタスクを実行すると、自動的に更新されます。 ただし、一部のエージェントを手動で更新する場合は、プールを右クリックし、[すべてのエージェントを更新] を選びます。

セルフホステッド エージェントには Microsoft ホステッド エージェントを超えるパフォーマンス上の利点がありますか?

多くの場合、あります。 具体的な内容は次のとおりです。

  • セルフホステッド エージェントを使用する場合は、インクリメンタル ビルドを実行できます。 たとえば、リポジトリをクリーンせず、クリーン ビルドを実行しないパイプラインを定義した場合、通常、ビルドの実行速度は速くなります。 キャッシュなどの機能を使用しない限り、ビルドまたはリリース パイプラインが完了した後にエージェントが破棄されるため、Microsoft ホステッド エージェントの利点はありません。

  • Microsoft ホステッド エージェントは、ビルドの開始により長い時間がかかることがあります。 多くの場合は、Microsoft ホステッド エージェントにジョブが割り当てられるまでに数秒しかかかりませんが、システムの負荷によっては、エージェントが割り当てられるまでに数分かかる場合があります。

同じマシンに複数のセルフホステッド エージェントをインストールできますか?

はい。 このアプローチは、多くの共有リソースを消費しないジョブを実行するエージェントに対しては適切に機能します。 たとえば、作業の大部分がデプロイの調整であり、エージェント自体では多くの作業を行わないリリースを実行するエージェントには試してみることができます。

それ以外の場合は、同じマシンで複数のエージェントを実行しても、あまり効率が上がらないことがわかるかもしれません。 たとえば、大量のディスクや I/O リソースを消費するビルドを実行するエージェントでは、それだけの価値がない可能性があります。

並列ビルド ジョブで同じシングルトン ツール デプロイ (npm パッケージなど) を使う場合も問題が発生する可能性があります。 たとえば、あるビルドが依存関係を更新しているときに、別のビルドがそれを使用している最中である場合は、信頼できない結果やエラーが発生する可能性があります。

パイプライン ジョブが取り消されたときのエージェントの動作はどうなりますか?

Microsoft ホステッド エージェントの場合、エージェントは切断され、Azure Pipelines プールに戻されます。

セルフホステッド エージェントの場合:

パイプラインが取り消されると、エージェントは、現在の手順を実行しているプロセスに一連のコマンドを送信します。

  • 最初のコマンドは、7.5 秒のタイムアウトで送信されます。
  • プロセスが終了しない場合は、2.5 秒のタイムアウトで 2 番目のコマンドが送信されます。
  • プロセスが終了しない場合、エージェントは強制終了をコマンドします。
  • プロセスが最初の 2 つの終了要求を無視すると、強制的に終了されます。

最初の要求から終了までにかかる時間は約 10 秒です。

パイプラインを取り消すためにプロセスに発行されるコマンドは、エージェントのオペレーティング システムによって異なります。

  • macOS と Linux - 送信されるコマンドは、SIGINT、SIGTERM、SIGKILL の順です。
  • Windows - プロセスに送信されるコマンドは、Ctrl+C、Ctrl+Break、Process.Kill の順です。

特定のエージェント プールに対してプログラムでエージェントの更新をトリガーするにはどうすればよいですか?

次の API を使うことで、プールのエージェント更新をトリガーできます。

POST https://dev.azure.com/{organization}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0
POST https://{server url}/tfs/{collection}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0

注意

API と Azure DevOps Server のバージョン マッピングの詳細については、「API と Azure DevOps Server のバージョン マッピング」を参照してください

URI パラメーター

Name / 必須 タイプ 説明
agentId query False string 更新するエージェント。 指定しない場合、すべてのエージェントに対して更新がトリガーされます。
organization path True string Azure DevOps 組織の名前です。
poolId path True integer int32 使うエージェント プール
api-version query False string 使う API のバージョン。 このバージョンの API を使うには、値を '6.0' に設定する必要があります。

エージェントの更新をトリガーするには、要求本文を空にする必要があります。

注意

Azure Pipelines エージェントは GitHub 上のオープン ソースです。

詳細情報

エージェントの詳細については、「Azure DevOps を使用してアプリケーションをビルドする」ラーニング パスの次のモジュールを参照してください。