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

Azure DevOps Services

Windows、Azure、その他の Visual Studio ソリューションをビルドしてデプロイするには、少なくとも 1 つの Windows エージェントが必要です。 Windows エージェントでは、Java と Android のアプリをビルドすることもできます。

この記事では、Azure DevOps Services と現在のバージョンの Azure DevOps Server で 3.x エージェント ソフトウェアを使用するためのガイダンスを提供します。 3.x エージェントをサポートする Azure DevOps Server バージョンの一覧については、「Azure DevOps Server は 3.x エージェントをサポートしていますか」を参照してください。

Note

この記事では、セルフホステッド エージェントの構成方法について説明します。 Azure DevOps Services を使っていて、Microsoft ホステッド エージェントがニーズを満たしている場合は、セルフホステッド Windows エージェントの設定をスキップできます。

エージェントについて理解する

エージェントの概要としくみが既にわかっている場合は、次のセクションに進んでください。 ただし、その機能としくみの背景について詳しく知りたい場合は、「Azure Pipelines エージェント」を参照してください。

前提条件を確認する

マシンに次の前提条件があることを確認します。

• オペレーティング システムのバージョン
  • クライアント OS
    • Windows 7 SP1 ESU
    • Windows 8.1
    • Windows 10
    • Windows 11
  • サーバー OS
    • Windows Server 2012 以降
• エージェント ソフトウェアではそれ自体のバージョンの .NET がインストールされるため、.NET の前提条件はありません。
• PowerShell 3.0 以降
• Subversion - Subversion リポジトリからビルドする場合は、コンピューターに Subversion クライアントをインストールする必要があります。
• 推奨 - Visual Studio ビルド ツール (2015 以降)

最初に手動でエージェントのセットアップを実行する必要があります。 エージェントの動作を確認した後、または多数のエージェントの設定を自動化する場合は、 無人構成の使用を検討してください。

ハードウェアの仕様

エージェントのハードウェアの仕様は、ニーズやチームの規模などによって異なります。すべてに当てはまる一般的な推奨事項を作成することはできません。 基準として、Azure DevOps チームは、ホステッド エージェントを利用するパイプラインを使って、ホステッド エージェントのコードをビルドしています。 一方、Azure DevOps コードの大部分は、それぞれが 4 つのセルフホステッド エージェントを実行する 24 コア サーバー クラス マシンによってビルドされています。

アクセス許可を準備する

セルフホステッド エージェントの情報セキュリティ

エージェントを構成するユーザーにはプール管理者のアクセス許可が必要ですが、エージェントを実行するユーザーには必要ありません。

エージェントによって制御されるフォルダーは、含まれている機密情報の解読または漏洩を回避するために、できる限り少数のユーザーにアクセスを制限する必要があります。

Azure Pipelines エージェントは、外部ソースからダウンロードしたコードを実行するように設計されたソフトウェア製品です。 本質的には、リモート コード実行 (RCE) 攻撃のターゲットになる可能性があります。

したがって、作業を実行するパイプライン エージェントの個々の使用法に関する脅威モデルを考慮することが重要です。また、エージェントを実行しているユーザー、エージェントが実行されているマシン、パイプライン定義への書き込みアクセス権を持つユーザー、yaml が保存される git リポジトリ、または新しいパイプラインのプールへのアクセスを制御するユーザー グループに、付与できる最小限のアクセス許可を決定することも重要です。

エージェントを実行している ID は、エージェントをプールに接続するためのアクセス許可を持つ ID とは別にすることをお勧めします。 資格情報 (およびその他のエージェント関連ファイル) を生成するユーザーは、資格情報を読み取る必要があるユーザーとは異なります。 そのため、エージェント マシン自体と、ログや成果物などの機密性の高いファイルを含むエージェント フォルダーに付与されるアクセスを慎重に検討する方が安全です。

DevOps 管理者とエージェント プロセスを実行しているユーザー ID に対してのみ、エージェント フォルダーへのアクセス権を付与することが理にかなっています。 管理者は、ビルド エラーを理解するためにファイル システムを調査するか、Azure DevOps のエラーを報告できるようにログ ファイルを取得する必要がある場合があります。

使うユーザーを決定する

1 回限りの手順として、エージェントを登録する必要があります。 エージェント キューを管理するアクセス許可を持つユーザーは、これらの手順を完了する必要があります。 エージェントは、日常的な操作ではこのユーザーの資格情報を使いませんが、登録を完了するために必要です。 エージェントの通信方法の詳細を確認します。

ユーザーにアクセス許可があることを確認する

使うユーザー アカウントに、エージェントを登録するためのアクセス許可があることを確認します。

ユーザーは Azure DevOps 組織所有者、TFS または Azure DevOps Server 管理者ですか? その場合はこれで終了です。既にアクセス許可を持っています。

それ以外の場合:

1. ブラウザーを開き、Azure Pipelines 組織、Azure DevOps Server、または TFS サーバーの [エージェント プール] タブに移動します。

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

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

      

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

      

2. ページの右側にあるプールを選び、[セキュリティ] をクリックします。

3. 使うユーザー アカウントが表示されない場合は、管理者に追加を依頼します。 管理者は、エージェント プール管理者、Azure DevOps 組織所有者、または TFS または Azure DevOps Server 管理者の場合があります。

   配置グループ エージェントの場合、管理者は、配置グループ管理者、Azure DevOps 組織所有者、または TFS または Azure DevOps Server 管理者の場合があります。

   Azure Pipelinesの [配置グループ] ページの [セキュリティ] タブで、配置グループ管理者ロールにユーザーを追加できます。

注意

"申し訳ございません。ID を追加できませんでした。別の ID を試してください。" のようなメッセージが表示された場合、組織所有者、または TFS または Azure DevOps Server 管理者の場合は、上記の手順に従った可能性があります。 何もする必要はありません。エージェント プールを管理するアクセス許可が既にあります。

エージェントのダウンロードと構成

Azure Pipelines

1. 上記で説明したように、アクセス許可を準備したアカウントを使ってマシンにログオンします。

2. Web ブラウザーで Azure Pipelines にサインインし、[エージェント プール] タブに移動します。

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

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

      

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

      

3. [既定] のプールを選び、[エージェント] タブを選び、[新しいエージェント] を選びます。

4. [エージェントの取得] ダイアログ ボックスで、[Windows] を選びます。

5. 左側のペインで、コンピューターにインストールされている Windows OS のバージョンのプロセッサ アーキテクチャを選びます。 x64 エージェント バージョンは 64 ビット Windows を対象としているのに対し、x86 バージョンは 32 ビット Windows 用です。 インストールされている Windows のバージョンがわからない場合は、こちらの手順に従って確認してください。

6. 右側のウィンドウで、 [ダウンロード] ボタンをクリックします。

7. ページの指示に従ってエージェントをダウンロードします。

8. 任意のディレクトリにエージェントを展開します。 ツールとスクリプトでスペースが常に正しくエスケープされるとは限らないので、ディレクトリへのパスにスペースが含まれていないことを確認してください。 推奨されるフォルダーは C:\agents です。 ダウンロード フォルダーまたはその他のユーザー フォルダーに抽出すると、アクセス許可の問題が発生する可能性があります。

重要

管理者特権の PowerShell ウィンドウからエージェントを構成することを強くお勧めします。 サービスとして構成する場合は、これが必要です。

Windows PowerShell ISE を使ってエージェントを構成することはできません。

重要

セキュリティ上の理由から、管理者だけがエージェント フォルダー (C:\agents) を編集できるようにすることを強くお勧めします。

注意

エージェントの構成には、git-bash などの mintty ベースのシェルを使用しないでください。 Mintty にはネイティブの入出力 Windows API との完全な互換性があるわけではなく (こちらを参照してください)、この場合、セットアップ スクリプトが正しく動作することは保証されません。

エージェントをインストールする

1. 管理者特権での (PowerShell) ウィンドウを起動し、エージェントをアンパックした場所に場所を設定します。

   cd C:\agents 
   
   

2. config.cmd を実行します。 これにより、エージェントを構成するための一連の質問が表示されます。

   .\config.cmd
   
   

サーバー URL

セットアップでサーバー URL の指定を求められたら、Azure DevOps Services の場合は「https://dev.azure.com/{your-organization}」と入力します。

エージェント セットアップの認証の種類

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

• 個人用アクセス トークン
• デバイス コード フロー
• サービス プリンシパル

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

対話型モードまたはサービス モードの選択

エージェントを対話型モードで実行するか、サービスとして実行するかのガイダンスについては、「エージェント: 対話型とサービス」を参照してください。

サービスとして実行することを選んだ場合は (推奨)、実行するユーザー名を 20 文字以下にする必要があります。

エージェントの実行

対話的な実行

対話形式で実行できるようにエージェントを構成した場合は、次のコマンドを実行してエージェントを起動します。

.\run.cmd

エージェントを再起動するには、Ctrl + C キーを押してエージェントを停止し、run.cmd を実行して再起動します。

Note

PowerShell Core からエージェントを実行して Windows PowerShell タスクを実行している場合、パイプラインが失敗し、Error in TypeData "System.Security.AccessControl.ObjectSecurity": The member is already present などのエラーが発生する可能性があります。 これは、Windows PowerShell が、PowerShell Core モジュールの場所を含む PSModulePath 環境変数を親プロセスから継承するためです。

回避策として、パイプラインでエージェントのノブ AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL を true に設定することもできます。 これにより、エージェントはタスクを実行する前に PSModulePath をリセットできます。

variables:
 AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL: "true"

この回避策で問題が解決しない場合、またはモジュール用にカスタムの場所を使用する必要がある場合は、エージェントを実行する前に、PowerShell Core ウィンドウで必要に応じて $Env:PSModulePath 変数を設定できます。

1 回実行する

エージェントが 1 つのジョブのみを受け入れて終了するように選択することもできます。 この構成を実行するには、次のコマンドを使用します。

.\run.cmd --once

このモードのエージェントは、1 つのジョブのみを受け入れ、正常にスピン ダウンします (Azure Container Instances などのサービスで Docker で実行する場合に便利です)。

サービスとして実行

サービスとして実行するようにエージェントを構成した場合は、自動的に開始されます。 サービス スナップインからエージェントの実行状態を表示および制御できます。 services.msc を実行して、次のいずれかを探します。

• "Azure Pipelines Agent (エージェントの名前)"
• "VSTS Agent (エージェントの名前)"
• "vstsagent.(組織名).(エージェントの名前)"

Note

サービスとして実行されているエージェントのアクセス制御をより柔軟に行うために、対話型構成フロー中にフラグまたはプロンプトを介してエージェント サービスの SID タイプを [SERVICE_SID_TYPE_UNRESTRICTED] として設定できます。 デフォルトでは、エージェント サービスは SERVICE_SID_TYPE_NONE で構成されます。

SID タイプの詳細については、この ドキュメント を確認してください。

エージェントを再起動するには、エントリを右クリックして [再起動] を選びます。

注意

エージェントのログオン アカウントの変更が必要な場合、[サービス] スナップインからは行わないでください。 代わりに、以下の情報を参照してエージェントを再構成します。

エージェントを使うには、エージェントのプールを使ってジョブを実行します。 別のプールを選ばなかった場合、エージェントは既定のプールに配置されます。

エージェントを置き換える

エージェントを置き換えるには、「エージェントのダウンロードと構成」の手順をもう一度実行します。

既に存在するエージェントと同じ名前を使用してエージェントを構成すると、既存のエージェントを置き換えるかどうかを確認するメッセージが表示されます。 Y と答えた場合、置き換えるエージェント (下記参照) を必ず削除してください。 そうしないと、数分間の競合の後、エージェントの 1 つがシャットダウンされます。

エージェントの削除と再構成

エージェントを削除するには:

.\config remove

エージェントを削除したら、もう一度構成できます。

無人構成

エージェントは、人間の介入なしでスクリプトから設定できます。 --unattended と、すべての質問への回答を渡す必要があります。

エージェントを構成するには、組織への URL、またはエージェントの設定を承認されたユーザーのコレクションと資格情報を把握している必要があります。 その他の応答はすべて省略可能です。 任意のコマンドライン パラメーターは、代わりに環境変数を使用して指定できます。その名前を大文字にし、先頭に VSTS_AGENT_INPUT_ を付けます。 たとえば、 --passwordを指定する代わりに、 VSTS_AGENT_INPUT_PASSWORD とします。

必須オプション

• --unattended - エージェントのセットアップでは情報の入力を求められるのではなく、すべての設定をコマンド ラインで指定する必要があります
• --url <url> - サーバーの URL。 例: https://dev.azure.com/myorganization または http://my-azure-devops-server:8080/tfs
• --auth <type> - 認証の種類。 次の値を指定できます。
  • pat (個人用アクセス トークン)
  • SP (サービス プリンシパル) (エージェント バージョン 3.227.1 以降が必要)
  • negotiate (Kerberos または NTLM)
  • alt (基本認証)
  • integrated (Windows の既定の資格情報)

認証オプション

• --auth pat を選択した場合:
  • --token <token> - 個人用アクセス トークンを指定します
  • --token パラメーターとして OAuth 2.0 トークンを渡すこともできます。
• --auth negotiate または --auth alt を選択した場合:
  • --userName <userName> - Windows ユーザー名を domain\userName 形式または userName@domain.com 形式で指定します
  • --password <password> - パスワードを指定します
• --auth SP を選択した場合:
  • --clientID <clientID> - 登録エージェントへのアクセス権を持つサービス プリンシパルのクライアント ID を指定します
  • --tenantId <tenantID> - サービス プリンシパルが登録されているテナント ID を指定します。
  • --clientSecret <clientSecret> - サービス プリンシパルのクライアント シークレットを指定します
  • 詳細については、サービス プリンシパルを使用してエージェントを登録する方法に関する記述を参照してください。

プール名とエージェント名

• --pool <pool> - 参加するエージェントのプール名
• --agent <agent> - エージェント名
• --replace - プール内のエージェントを置き換えます。 別のエージェントが同じ名前でリッスンしている場合、競合で失敗し始めます

エージェントの設定

• --work <workDirectory> - ジョブ データが格納されている作業ディレクトリ。 既定では、エージェント ディレクトリのルートの下の _work です。 作業ディレクトリは特定のエージェントによって所有されています。複数のエージェント間で共有しないでください。
• --acceptTeeEula- Team Explorer Everywhere エンド ユーザー使用許諾契約書に同意します (macOS および Linux のみ)
• --disableloguploads - コンソール ログ出力をサーバーにストリーミングしたり送信したりしないでください。 代わりに、ジョブの完了後にエージェント ホストのファイルシステムからそれらを取得できます。

Windows のみのスタートアップ

• --runAsService - Windows サービスとして実行するようにエージェントを構成します (管理者権限が必要)
• --runAsAutoLogon - 自動ログオンを構成し、起動時にエージェントを実行します (管理者権限が必要)
• --windowsLogonAccount <account> - domain\userName または userName@domain.com の形式で --runAsService または --runAsAutoLogon と共に使用し、Windows ユーザー名を指定します
• --windowsLogonPassword <password> - --runAsService または --runAsAutoLogon と共に使用し、Windows ログオン パスワードを指定します (グループ管理サービス アカウントと Windows 組み込みアカウント ('NT AUTHORITY\NETWORK SERVICE' など) には必要ありません)
• --enableservicesidtypeunrestricted - --runAsService とともに使用して、サービス SID タイプを SERVICE_SID_TYPE_UNRESTRICTED としてエージェントを構成します (管理者の許可が必要です)
• --overwriteAutoLogon - --runAsAutoLogon と共に使用し、マシン上の既存の自動ログオンを上書きします
• --noRestart - --runAsAutoLogon と共に使用し、エージェント構成の完了後にホストの再起動を停止します

runAsAutoLogon オプションを使用したエージェントの構成のトラブルシューティング

runAsAutoLogon オプションを使用してエージェントを構成すると、マシンを再起動するたびにエージェントが実行されます。 マシンの再起動後にエージェントが実行されない場合は、次の手順を実行します。

エージェントがマシンで既に構成されている場合

エージェントを再構成する前に、古いエージェント構成を削除する必要があるため、エージェント フォルダーから次のコマンドを実行してみてください:

.\config.cmd remove --auth 'PAT' --token '<token>'

コマンドの実行後にエージェントがエージェント プールから削除されたかどうかを確認します。

<Azure DevOps organization> / <Project> / Settings / Agent pools / <Agent Pool> / Agents

エージェントがコマンドを実行して削除されなかった場合は、エージェント プールから手動で削除します。

次に、エージェント フォルダーから次のコマンドを実行して、エージェントを再構成してみてください:

.\config.cmd --unattended --agent '<agent-name>' --pool '<agent-pool-name>' --url '<azure-dev-ops-organization-url>' --auth 'PAT' --token '<token>' --runAsAutoLogon --windowsLogonAccount '<domain\user-name>' --windowsLogonPassword '<windows-password>'

エージェント名 (特定の一意の名前) を指定し、再構成後、エージェント プールにこのエージェントが表示されたかどうかチェックします。

エージェント アーカイブ (ここでダウンロードできます) をアンパックし、新しいアンパックされたエージェント フォルダーからこのコマンドを実行することをお勧めします。

Windows レジストリ キーが記録され、正しく保存されているかどうかを確認する

whoami /user コマンドを実行して、<sid> を取得します。 Registry Editor を開き、パスに従います。

Computer\HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

VSTSAgent キーがあるかどうかを確認します。 このキーが存在する場合は削除し、Registry Editor を閉じ、エージェント フォルダーから .\config.cmd コマンド (引数なし) を実行してエージェント構成します。 Enter Restart the machine at a later time? の質問に答える前に、もう一度 Registry Editor を開き、VSTSAgent キーが表示されたかどうかをチェックします。 Enter を押して質問に答え、マシンの再起動後も VSTSAgent キーがその場所に残っているかどうかチェックします。

Windows レジストリ キーがコンピューターで正常に動作するかどうかを確認する

次の行が含まれている autorun.cmd ファイルを作成します: echo "Hello from AutoRun!" Registry Editor を開き、上記のパスにキー AutoRun と値を持つ新しいキーと値のペアを作成します

C:\windows\system32\cmd.exe /D /S /C start "AutoRun" "D:\path\to\autorun.cmd"

マシンを再起動します。 Hello from AutoRun! メッセージが表示されたコンソール ウィンドウが表示されない場合は、Windows レジストリ キーに問題があります。

配置グループのみ

• --deploymentGroup - エージェントを配置グループ エージェントとして構成します
• --deploymentGroupName <name> - --deploymentGroup と共に使用し、エージェントが参加する配置グループを指定します
• --projectName <name> - --deploymentGroup と共に使用し、プロジェクト名を設定します
• --addDeploymentGroupTags - --deploymentGroup と共に使用して、配置グループ タグを追加する必要があることを示します
• --deploymentGroupTags <tags> - --addDeploymentGroupTags と共に使用し、配置グループ エージェントのタグのコンマ区切りリストを指定します (例: "web, db")

環境のみ

• --addvirtualmachineresourcetags - 環境リソース タグを追加する必要があることを示すために使用されます
• --virtualmachineresourcetags <tags> - --addvirtualmachineresourcetags と共に使用し、環境リソース エージェントのタグのコンマ区切りリストを指定します (例: "web, db")

.\config --help 常に、最新の必須応答と省略可能な応答を一覧表示します。

診断

セルフホステッド エージェントで問題が発生した場合は、診断の実行を試すことができます。 エージェントの構成後:

.\run --diagnostics

これは、問題のトラブルシューティングに役立つ可能性のある診断スイートを介して実行されます。 診断機能は、エージェント バージョン 2.165.0 以降で使用できます。

セルフホステッド エージェントのネットワーク 診断

Agent.Diagnostic の値を true に設定して、セルフホステッド エージェントのネットワークの問題のトラブルシューティングに使用できる追加のログを収集します。 詳細については、「セルフホステッド エージェントのネットワーク診断」を参照してください

その他のオプションに関するヘルプ

その他のオプションについては、次の手順を実行します。

.\config --help

ヘルプには、認証の代替方法と無人構成に関する情報が記載されています。

機能

エージェントの機能は、プール内でカタログ化およびアドバタイズされるため、それが処理できるビルドとリリースのみが割り当てられます。 ビルド エージェントとリリース エージェントの機能に関する記事を参照してください。

多くの場合、エージェントの配置後には、ソフトウェアまたはユーティリティのインストールが必要になります。 通常、開発用マシンで使用するソフトウェアやツールは、エージェントにインストールする必要があります。

たとえば、ビルドに npm タスクが含まれている場合、そのビルドは、プール内に npm がインストールされているビルド エージェントが存在していないと実行されません。

重要

[機能] には、すべての環境変数と、エージェントの実行時に設定される値が含まれています。 これらの値のいずれかがエージェントの実行中に変更された場合は、エージェントを再起動して新しい値が採用されるようにする必要があります。 エージェントに新しいソフトウェアをインストールしたら、新しい機能がプールに表示されるようにエージェントを再起動して、ビルドを実行できるようにする必要があります。

機能としての環境変数を除外する場合は、無視する変数のコンマ区切りのリストによって環境変数 VSO_AGENT_IGNORE を設定すると、該当する環境変数を指定できます。

よく寄せられる質問

エージェントで実行される Git のバージョンは何ですか?

既定では、エージェント ソフトウェアにバンドルされている Git のバージョンが Windows エージェントで使われます。 Microsoft は、エージェントにバンドルされている Git のバージョンを使うことをお勧めしますが、この既定の動作をオーバーライドし、エージェント コンピューターのパスにインストールされている Git のバージョンを使うためのオプションがいくつかあります。

• パイプラインで System.PreferGitFromPath という名前のパイプライン変数を true に設定します。
• セルフホステッド エージェントでは、エージェントのルート ディレクトリに .env という名前のファイルを作成し、そのファイルに System.PreferGitFromPath=true という行を追加できます。 詳しくは、「エージェントごとに異なる環境変数を設定するにはどうすればよいですか?」をご覧ください。

パイプラインで使われている Git のバージョンは、次の例で示すように、パイプラインのログの checkout ステップで確認できます。

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

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

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

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

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

      

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

      

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

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

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

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

      

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

      

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

      

      注意

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

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

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

ファイアウォールを実行し、自分のコードが Azure Repos。 エージェントは、どのような URL と通信する必要がありますか?

ファイアウォールの背後にある安全なネットワークでエージェントを実行している場合、次の URL と IP アドレスにエージェントが通信を開始できるようにしてください。

ドメイン URL	説明
https://{organization_name}.pkgs.visualstudio.com	{organization_name}.visualstudio.com ドメインを使用している組織向けの Azure DevOps Packaging API
https://{organization_name}.visualstudio.com	{organization_name}.visualstudio.com ドメインを使用している組織向け
https://{organization_name}.vsblob.visualstudio.com	{organization_name}.visualstudio.com ドメインを使用している組織向けの Azure DevOps テレメトリ
https://{organization_name}.vsrm.visualstudio.com	{organization_name}.visualstudio.com ドメインを使用している組織向けの Release Management サービス
https://{organization_name}.vssps.visualstudio.com	{organization_name}.visualstudio.com ドメインを使用している組織向けの Azure DevOps プラットフォーム サービス
https://{organization_name}.vstmr.visualstudio.com	{organization_name}.visualstudio.com ドメインを使用している組織向けの Azure DevOps テスト管理サービス
https://*.blob.core.windows.net	Azure Artifacts
https://*.dev.azure.com	dev.azure.com ドメインを使用している組織向け
https://*.vsassets.io	CDN を使用した Azure Artifacts
https://*.vsblob.visualstudio.com	dev.azure.com ドメインを使用している組織向けの Azure DevOps テレメトリ
https://*.vssps.visualstudio.com	dev.azure.com ドメインを使用している組織向けの Azure DevOps プラットフォーム サービス
https://*.vstmr.visualstudio.com	dev.azure.com ドメインを使用している組織向けの Azure DevOps テスト管理サービス
https://app.vssps.visualstudio.com	{organization_name}.visualstudio.com ドメインを使用している組織向け
https://dev.azure.com	dev.azure.com ドメインを使用している組織向け
https://login.microsoftonline.com	Microsoft Entra サインイン
https://management.core.windows.net	Azure Management API
https://vstsagentpackage.azureedge.net	エージェント パッケージ

組織が既存のファイアウォールまたは IP 制限で動作することを確認するには、 dev.azure.com と *dev.azure.com が開かれていることを確認し、許可リストの IP を更新して、IP バージョンに基づいて次の IP アドレスを含むようにします。 現在、13.107.6.183 と 13.107.9.183 の IP アドレスを許可している場合は、それらを削除する必要はないため、そのままにしておきます。

IPv4 の範囲

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

IPv6 の範囲

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

注意

許可されるアドレスの詳細については、「許可されたアドレス リストとネットワーク接続」を参照してください。

自己署名証明書を使用してエージェントを実行するにはどうすればよいですか?

Note

自己署名証明書を使用したエージェントの実行は、Azure DevOps Server にのみ適用されます。

自己署名証明書を使用してエージェントを実行する

Web プロキシの背後でエージェントを実行するにはどうすればよいですか?

Web プロキシの背後でエージェントを実行する

エージェントを再起動する方法

エージェントを対話形式で実行している場合は、「対話形式で実行する」の再起動手順を参照してください。 エージェントをサービスとして実行している場合は、「サービスとして実行する」の手順に従ってエージェントを再起動します。

エージェントごとに異なる環境変数を設定するにはどうすればよいですか?

エージェントのルート ディレクトリの下に .env ファイルを作成し、設定する環境変数を次の形式でファイルに追加してから、エージェントを再起動します。

MyEnv0=MyEnvValue0
MyEnv1=MyEnvValue1
MyEnv2=MyEnvValue2
MyEnv3=MyEnvValue3
MyEnv4=MyEnvValue4

Web プロキシをバイパスして Azure Pipelines に接続するようにエージェントを構成するにはどうすればよいですか?

エージェントでプロキシをバイパスして Azure Pipelines に直接接続する場合は、エージェントが次の URL にアクセスできるように Web プロキシを構成する必要があります。

*.visualstudio.com ドメインを使用している組織の場合:

https://login.microsoftonline.com
https://app.vssps.visualstudio.com 
https://{organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com
https://{organization_name}.pkgs.visualstudio.com
https://{organization_name}.vssps.visualstudio.com

dev.azure.com ドメインを使用している組織の場合:

https://dev.azure.com
https://*.dev.azure.com
https://login.microsoftonline.com
https://management.core.windows.net
https://vstsagentpackage.azureedge.net
https://vssps.dev.azure.com

組織が既存のファイアウォールまたは IP 制限で動作することを確認するには、 dev.azure.com と *dev.azure.com が開かれていることを確認し、許可リストの IP を更新して、IP バージョンに基づいて次の IP アドレスを含むようにします。 現在、13.107.6.183 と 13.107.9.183 の IP アドレスを許可している場合は、それらを削除する必要はないため、そのままにしておきます。

IPv4 の範囲

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

IPv6 の範囲

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

注意

この手順により、エージェントは Web プロキシをバイパスできるようになります。 ビルド パイプラインとスクリプトでは、ビルドで実行するタスクとツールごとに Web プロキシのバイパスを引き続き処理する必要があります。

たとえば、NuGet タスクを使用している場合は、使用している NuGet フィードをホストするサーバーの URL のバイパスをサポートするように Web プロキシを構成する必要があります。

TFS を使用しており、上記のセクションの URL は機能しません。 情報はどこで入手できますか?

Web サイトの設定とセキュリティ

エージェント サービスの SERVICE_SID_TYPE_UNRESTRICTED を有効にするにはどうすればよいですか?

Windows Server でエージェント ソフトウェアを構成するときに、次のプロンプトからサービス セキュリティ識別子を指定できます。

Enter enable SERVICE_SID_TYPE_UNRESTRICTED for agent service (Y/N) (press enter for N)

以前のバージョンのエージェント ソフトウェアでは、サービス セキュリティ識別子の種類が SERVICE_SID_TYPE_NONE に設定されています。これは、現在のエージェント バージョンの既定値です。 セキュリティ サービス識別子の種類を SERVICE_SID_TYPE_UNRESTRICTED に構成するには、Y キーを押します。

詳しくは、「SERVICE_SID_INFO 構造体」と「セキュリティ識別子」をご覧ください。