TeamCity 2020.2 ヘルプ

追加のビルドエージェントの設定と実行

プロジェクトのカスタマイズとビルド構成の作成を開始する前に、ビルドエージェントを構成する必要があります。エージェントのインストールに進む前に、エージェントとサーバー間の通信および前提条件セクションを確認してください。

前提条件

必要な OS と環境の権限

インストールの前に、矛盾するソフトウェアセクションを確認してください。問題がある場合は、競合するソフトウェアが使用されていないことを確認してください。

TeamCity ビルドエージェントを実行するには、エージェントの実行に使用される環境とユーザーアカウントが以下の要件を満たす必要があります。

共通

エージェントプロセス(Java)は次のことを行う必要があります。

  • buildAgent.properties ファイルの serverUrl プロパティで設定されたサーバー URL へのアウトバウンド HTTP 接続を開くことができる(通常は TeamCity UI を表示するためにブラウザーで使用するのと同じアドレス)。設定された URL のパスへのリクエスト送信は制限されるべきではありません。推奨リバースプロキシ設定も参照してください。エージェントマシンまたはサーバーマシンにインストールされているファイアウォール、ネットワーク構成、プロキシ(存在する場合)が、これらの要件に準拠していることを確認してください。

  • 次のディレクトリに対する完全な許可(読み取り / 書き込み / 削除)を再帰的に持っている: <agent home> (自動エージェントアップグレードおよびエージェントツールのサポートに必要)、 <agent work> <agent temp> 、エージェントシステムディレクトリ( buildAgent.properties ファイルの workDirtempDirsystemDir パラメーターによって設定)。

  • (ビルドを実行するための)プロセスを起動できるようにします。

  • 次の親プロセス出口でネストされたプロセスを起動できる(これはエージェントのアップグレード中に使用されます)。

Windows

  • サービスとしてログオンします(Windows サービスとして実行します)。

  • サービスの開始 / 停止(Windows サービスとして実行するには、エージェントのアップグレードが機能するために必要です。マイクロソフトサポート技術情報の記事(英語)も参照してください)。

  • プログラムのデバッグ(プロセスダンプの取得機能に必要)。

  • マシンを再起動します(エージェントの再起動機能に必要です)。

  • Windows サービスとして実行されるビルドエージェントのパフォーマンスを監視できるようにするには、エージェントを開始するユーザーが Performance Monitor Users グループのメンバーである必要があります。

Linux

  • ユーザーは、shutdown コマンドを実行できる必要があります(クラウド環境で実行している場合のエージェントマシンの再起動機能とマシンのシャットダウン機能の場合)。

  • systemd を使用している場合は、メインプロセス出口でプロセスを強制終了しないでください( RemainAfterExit=yes (英語) を使用)。Linux で自動エージェント起動を設定する方法も参照してください。

ビルド関連の権限

ビルドプロセスは TeamCity エージェントによって起動され、環境を共有し、TeamCity エージェントによって使用される OS ユーザーで実行されます。TeamCity エージェントがそれに応じて構成されていることを確認してください。関連する Windows サービスの制限については、既知の問題を参照してください。

エージェント - サーバー間データ転送

TeamCity エージェントは、serverUrl エージェントプロパティとして構成された URL を介して TeamCity サーバーに接続します。これは、単方向のエージェント間接続と呼ばれます。

特別に構成されている場合、TeamCity エージェントは、サーバーからエージェントへの接続を確立する必要があるレガシー双方向通信を使用できます。特定のエージェントに対してエージェントとサーバーの通信が単方向か双方向かを確認するには、エージェント | <エージェント名> | エージェント概要タブ、詳細セクション、通信プロトコルに移動します。

単方向のエージェント間通信

エージェントは、ポーリングプロトコルを介した単方向のエージェント対サーバー接続を使用します。エージェントは TeamCity サーバーへの HTTP(S) 接続を確立し、サーバーコマンドについてサーバーを定期的にポーリングします。

エージェント間の通信には HTTPS を使用することをお勧めします(関連するサーバー構成に関する注意事項を確認してください)。エージェントとサーバーが安全な環境にデプロイされている場合、サーバーへの接続にプレーン HTTP URL を使用するようにエージェントを構成できます。これにより、転送のオーバーヘッドが削減されます。エージェントからサーバーに確立された接続を介して移動するデータには、ビルド設定、リポジトリアクセス資格情報とキー、リポジトリソース、ビルドアーティファクト、ビルド進行状況メッセージ、ビルドログが含まれることに注意してください。HTTP プロトコルを使用する場合、そのデータは「中間者」攻撃によって危険にさらされる可能性があります。

双方向通信

双方向通信は、エージェントとサーバー間の従来の接続であり、特に有効にする必要があります(以下の例を参照)。有効にすると、エージェントは HTTP(または HTTPS)経由でサーバーに接続し、サーバーは HTTP 経由でエージェントに接続する必要があります。

サーバーによって確立された接続を介してエージェントに転送されるデータは、セキュリティで保護されていない HTTP チャネルを介して渡されるため、サーバーとエージェント間のトラフィックをリッスンする可能性のあるサードパーティーに公開される可能性があります。さらに、エージェントとサーバーは「コマンド」を送信できるため、互いに、HTTP リクエストを送信してレスポンスをキャプチャーできる攻撃者は、理論的にはエージェントをだまして任意のコマンドを実行させ、セキュリティに影響を与える他のアクションを実行する可能性があります。

TeamCity エージェントが使用する通信プロトコルは、teamcity.agent.communicationProtocols サーバーの内部プロパティの値によって決まります。このプロパティは、コンマで区切られたプロトコルの順序付きリスト(polling および xml-rpc はサポートされているプロトコル名です)を受け入れ、デフォルトで teamcity.agent.communicationProtocols=polling に設定されています。複数のプロトコルが指定されている場合、エージェントはこのリストの最初のプロトコルを使用して接続を試み、失敗した場合はリストの 2 番目のプロトコルを介して接続を試みます。 polling は単方向プロトコル、xml-rpc - より古い双方向通信を意味します。

通信プロトコルの変更

  • すべてのエージェントの通信プロトコルを変更するには、TeamCity サーバーの teamcity.agent.communicationProtocols サーバーの内部プロパティを設定します。新しい設定は、変更後にサーバーに接続するすべてのエージェントによって使用されます。既存の接続のプロトコルを変更するには、TeamCity サーバーを再起動します。

  • デフォルトでは、エージェントのプロパティは設定されていません。エージェントが最初にサーバーに接続するとき、エージェントは TeamCity サーバーからそれを受信します。エージェントの初期設定後に個々のエージェントのプロトコルを変更するには、エージェントの特性teamcity.agent.communicationProtocols プロパティの値を変更します。エージェントのプロパティはサーバープロパティをオーバーライドします。変更後、実行中のビルドがある場合は、終了するとエージェントが自動的に再起動します。

追加のビルドエージェントのインストール

1. 次のオプションのいずれかを使用してビルドエージェントをインストールします。

2. インストール後、 conf/buildAgent.properties ファイルで TeamCity サーバーの名前とアドレスを指定してエージェントを構成します。

3. 開始エージェント。エージェントが正しく実行されていないように思われる場合は、エージェントのログを確認してください。

新しくインストールされたエージェントが初めてサーバーに接続すると、Agents ページに表示されます。Unauthorized agents タブは、それを承認する権限を持つ管理者 / ユーザーに表示されます。エージェントは TeamCity Web UI で承認されるまでビルドを実行しません。サーバーと同じコンピューター上で実行されているエージェントは、デフォルトで許可されています。

許可されたエージェントの数は、サーバー上のエージェントライセンスの数によって制限されます。詳細はライセンスポリシーを参照してください。

Windows インストーラーによるインストール

  1. TeamCity Web UI で、エージェントタブに移動します。

  2. ビルドエージェントをインストールするリンクをクリックし、Windows インストーラーを選択してインストーラをダウンロードしてください。

  3. エージェントで、agentInstaller.exe Windows インストーラーを実行して、インストール手順に従います。

Docker エージェントイメージを介したインストール

  1. TeamCity Web UI で、エージェントタブに移動します。

  2. ビルドエージェントをインストールするリンクをクリックして、Docker エージェントイメージを選択します。

  3. 開いたページ(英語)の指示に従います。

ZIP ファイルによるインストール

  1. JDK(JRE)1.8.0_161 以降(Java 8-11 はサポートされていますが、1.8.0_161 + を推奨)がエージェントコンピューターに正しくインストールされていることを確認してください。

  2. エージェントコンピューターで、JRE_HOME または JAVA_HOME 環境変数が設定されていることを確認します(それぞれ、インストール済みの JRE または JDK ディレクトリを指している)。

  3. TeamCity Web UI で、エージェントタブに移動します。

  4. ビルドエージェントをインストールするリンクをクリックし、2 つのオプションのいずれかを選択してアーカイブをダウンロードします。
    • 最小限の ZIP ファイルディストリビューション : プラグインのない通常のビルドエージェント

    • (TeamCity 2020.1 以降)完全な ZIP ファイルのディストリビューション *: サーバーで現在有効になっているすべてのプラグインがプリパックされたフルビルドエージェント

  5. ダウンロードしたファイルを目的のディレクトリに抽出します。

  6. <installation path>\conf ディレクトリに移動し、buildAgent.dist.properties というファイルを見つけて、buildAgent.properties に名前を変更します。

  7. buildAgent.properties ファイルを編集して、TeamCity サーバーの URL(HTTPS を推奨。を参照)とエージェントの名前を指定します。エージェント構成の詳細については、エージェント構成の構築ページを参照してください。

  8. Linux では、bin/agent.sh シェルスクリプトに実行権限を与える必要があるかもしれません。

Windows では、エージェントの手動起動を使用する代わりに、ビルドエージェント Windows サービスをインストールすることもできます。

エージェントプッシュによるインストール

TeamCity は、リモートホストにビルドエージェントをインストールできるエージェントプッシュ機能を提供します。現在、サーバーホストプラットフォームとビルドエージェントのターゲットのサポートされている組み合わせは次のとおりです。

  • Unix ベースの TeamCity サーバーから、ビルドエージェントは Unix ホストにのみインストールできます (SSH 経由)

  • Windows ベースの TeamCity サーバーから、ビルドエージェントを Unix(SSH 経由)または Windows(psexec 経由)ホストにインストールできます。

リモートホスト要件

リモートホストにはいくつかの要件があります。

プラットフォーム

前提条件

Linux

  • インストールされた JDK(JRE)8-11(1.8.0_161 以降を推奨)。JVM は、JAVA_HOMEJRE_HOME)グローバル環境変数を介して到達可能であるか、グローバルパス内にある必要があります (たとえば、ユーザーの .bashrc ファイルで指定される代わりに)

  • unzip ユーティリティ。

  • wget または curl のいずれか。

Windows

  • インストールされた JDK/JRE 8-11(1.8.0_161 以降を推奨)。

  • Sysinternals psexec.exe は TeamCity サーバーにインストールされ、パスでアクセス可能である必要があります。管理 | ツールページにインストールできます。
    PsExec(英語) は、リモート Windows ホストに追加の要件を適用することに注意してください。次の前提条件が満たされていることを確認してください。
    • リモートホスト上の管理シェア(英語)が有効化され、アクセス可能です。

    • リモートサービスは機能します(MMC スナップインはマシンに接続できます)。

    • リモートレジストリは機能します(regeditservices.msc を介してマシンに接続できます)。

    • サーバーとワークステーションのサービスが実行されています( services.msc で確認してください)。

    • 従来のネットワーク認証(英語)が有効になります。

次のコマンドで接続をテストできます。

net use \\target\Admin$ /user:Administrator dir \\target\Admin$

インストール

  1. TeamCity サーバーの WebUI で、エージェント | エージェントプッシュタブに移動し、エージェントをインストールをクリックします。
    複数のターゲットホストに同じ設定を使用する場合は、これらの設定でプリセット作成し、エージェントを別のリモートホストにインストールするたびに使用できます。

  2. エージェントのインストールダイアログで、保存されたプリセットを選択するか、カスタム設定を使用するを選択し、ターゲットホストプラットフォームを指定して、対応する設定を構成します。SSH を介した Linux システムへのエージェントプッシュは、SSH ポートパラメーターとして指定されたカスタムポート(デフォルトは 22)をサポートします。プリセットで指定されたポートは、実際のエージェントのインストール中に、ホスト名(たとえば、hostname.domain:2222 )でオーバーライドできます。

  3. Sysinternals psexec.exe をダウンロードする必要があるかもしれません。その場合は、対応する警告と、それをダウンロードできる管理 | ツールページへのリンクが表示されます。

ビルドエージェントを起動する

TeamCity ビルドエージェントは手動で起動することも、自動的に起動するように設定することもできます。

手動スタート

エージェントを手動で起動する、次のスクリプトを実行します。

  • Windows 用: <installation path>\bin\agent.bat start

  • Linux および macOS 用: <installation path>\bin\agent.sh start

自動スタート

エージェントが自動的開始されるように構成するには、対応するセクションを参照してください。

  • Windows
  • Linux: デーモンプロセスを開始するには agent.sh start コマンドを使用し、停止するには agent.sh stop コマンドを使用してデーモンプロセスを構成します。

  • macOS

Windows での自動エージェント起動

Windows のマシンブートでエージェントを自動的に実行するには、エージェントを Windows サービスとして実行するように設定するか、別の方法で自動プロセスを開始します。
Windows サービスアプローチを使用するのが最も簡単な方法ですが、Windows はこの方法で実行されるプロセスにいくつかの制約を適用します。
TeamCity エージェントは、すべての要件が満たされていれば、Windows サービスで確実に機能しますが、エージェントで実行するように構成されたビルドプロセスには当てはまらないことがよくあります。

そのため、すべてのビルドスクリプトがこれをサポートしている場合にのみ、TeamCity エージェントを Windows サービスとして実行することをお勧めします。それ以外の場合は、別の OS 固有の方法を使用して TeamCity エージェントを自動的に起動することをお勧めします。
1 つの方法は、Windows の起動時にユーザー(英語)自動ログオン(英語)を構成してから、ユーザーのログオン(たとえば、Windows タスクスケジューラ(英語)を介して)で TeamCity エージェントの開始を( agent.bat start を介して)構成することです。

Windows サービスとしてのエージェントの構築

Windows では、ユーザーがログオンしていなくても TeamCity エージェントを実行できるように、Windows サービスとして実行することをお勧めします。Windows エージェントインストーラーを使用する場合は、インストールウィザードでサービスをインストールするオプションがあります。

以下の手順を使用して、Windows サービスを手動でインストールすることができます(たとえば、.zip エージェントのインストール後)。この手順は、同じマシン上で 2 番目以降のエージェント用の Windows サービスを作成するためにも実行する必要があります。

サービスをインストールするには:

  1. 必要な名前と ID を持つサービス(下記の #4 を参照、サービス名はデフォルトで TeamCity Build Agent です)が存在しないか確認してください。インストールされている場合は取り外します。

  2. <agent home>\launcher\conf\wrapper.conf ファイルの wrapper.java.command プロパティに、JDK インストールディレクトリの Java 実行可能ファイルへの有効なパスが含まれていることを確認してください。Windows ディストリビューションとともにインストールされたエージェントには wrapper.java.command=../jre/bin/java を使用できます。引用符なしで java.exe ファイルのパスを指定してください。

  3. "System" ではなく、ユーザーアカウント(推奨)でエージェントを実行する場合は、適切な資格情報を使用して wrapper.ntservice.account プロパティと wrapper.ntservice.password プロパティを <agent home>\launcher\conf\wrapper.conf ファイルに追加します。

  4. (2 回目以降のインストールの場合) wrapper.console.titlewrapper.ntservice.namewrapper.ntservice.displaynamewrapper.ntservice.description プロパティがコンピューター内で一意の値を持つように、<agent>\launcher\conf\wrapper.conf ファイルを変更します。

  5. 新しいエージェントサービスを登録するのに十分な特権を持つユーザーで <agent home>\bin\service.install.bat スクリプトを実行します。説明されているように構成された後にのみ、初めてエージェントを開始するようにしてください。

サービスを開始するには

  • 実行 <agent home>/bin/service.start.bat (または標準の Windows サービスアプレットを使用する)

サービスを停止するには

  • 実行 <agent home>/bin/service.stop.bat (または標準の Windows サービスアプレットを使用する)

インストール後、標準の Windows net.exe ユーティリティを使用してサービスを管理することもできます。
例(デフォルトのサービス名を想定):

net start TCBuildAgent

<agent home>\launcher\conf\wrapper.conf ファイルを使用して、エージェントの JVM パラメーターを変更することもできます。

ビルドエージェントサービスを実行するために使用されるユーザーアカウントには、前述のように、エージェントサービスを開始または停止するのに十分な権限が必要です。

Linux での自動エージェント起動

Linux のマシンブートでエージェントを自動的に実行するには、デーモンプロセスを構成して agent.sh start コマンドで開始し、agent.sh stop コマンドで停止します。

systemd については、teamcityagent.service 設定ファイルの例を参照してください。

[Unit] Description=TeamCity Build Agent After=network.target [Service] Type=oneshot User=teamcityagent Group=teamcityagent ExecStart=/home/teamcityagent/agent/bin/agent.sh start ExecStop=-/home/teamcityagent/agent/bin/agent.sh stop # Support agent upgrade as the main process starts a child and exits then RemainAfterExit=yes # Support agent upgrade as the main process gets SIGTERM during upgrade and that maps to exit code 143 SuccessExitStatus=0 143 [Install] WantedBy=default.target

init.d の場合は、手順例を参照してください。

1. サービスの開始 / 停止サービススクリプトディレクトリに移動します。

cd /etc/init.d/

2. ビルドエージェントサービススクリプトを開きます。

sudo vim buildAgent

3. 以下をファイルに貼り付けます。

#!/bin/sh ### BEGIN INIT INFO # Provides: TeamCity Build Agent # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start build agent daemon at boot time # Description: Enable service provided by daemon. ### END INIT INFO #Provide the correct user name: USER="agentuser" case "$1" in start) su - $USER -c "cd BuildAgent/bin ; ./agent.sh start" ;; stop) su - $USER -c "cd BuildAgent/bin ; ./agent.sh stop" ;; *) echo "usage start/stop" exit 1 ;; esac exit 0

4. ファイルを実行する権限を設定します。

sudo chmod 755 buildAgent

5. 適切なツールを使用して、マシンの起動時および再起動時にエージェントサービスを開始するリンクを作成します。

  • Debian/Ubuntu の場合:

sudo update-rc.d buildAgent defaults
  • Red Hat/CentOS の場合:

sudo chkconfig buildAgent on

macOS での自動エージェント開始

macOS の場合、TeamCity はビルドユーザーがログインしたときに自動的にビルドエージェントをロードする機能を提供します。

LaunchAgent アプローチ:

LaunchAgent を介して自動ビルドエージェント起動を設定するには、次の手順に従います。

1. buildAgent.zip を介して Mac にビルドエージェントをインストールします。

2. conf/buildAgent.properties ファイルを準備します(少なくともそこにエージェント名を設定します)。

3. 適切なエージェントアップグレードプロセスを確保するために、buildAgent ディレクトリのすべてのファイルが your_build_user によって所有されていることを確認してください。

4. 次のコマンドでビルドエージェントをロードします。

mkdir buildAgent/logs  # Directory should be created under your_build_user user sh buildAgent/bin/mac.launchd.sh load

your_build_user アカウントでこれらのコマンドを実行します。

ビルドエージェントが TeamCity サーバーから自動アップグレードするための数分待つ。ログでプロセスを見ることができます:

tail -f buildAgent/logs/teamcity-agent.log

5. ビルドエージェントがアップグレードされ、TeamCity サーバーに正常に接続したら、エージェントを停止します。

sh buildAgent/bin/mac.launchd.sh unload

6. ビルドエージェントを TeamCity サーバーからアップグレードした後、buildAgent/bin/jetbrains.teamcity.BuildAgent.plist ファイルを $HOME/Library/LaunchAgents/ ディレクトリにコピーします。ルート権限で TeamCity を起動したくない場合は、.plist ファイルで UserName キーを指定します。例:

<key>UserName</key> <string>teamcity_user</string>

7. ここで説明するように、ビルドユーザーとして自動的にログインするように Mac システムを構成します。

8. リブート。

システムの起動時に、ビルドユーザーは自動的にログインし、ビルドエージェントが起動します。

ビルドエージェントが実行されていることをすばやく確認するには、次のコマンドを使用します。

launchctl list | grep BuildAgent 69722 0 jetbrains.teamcity.BuildAgent

ビルドエージェントの停止

エージェントを手動で停止するstop パラメーターを指定して <Agent home>\agent スクリプトを実行します。

stop を使用して、現在のビルドが終了した後に停止を要求します。
stop force を使用して、即時停止を要求します(ビルドがエージェントで実行されている場合、ビルドは突然停止(キャンセル)されます)。
Linux では、stop kill を使用してエージェントプロセスを強制終了するオプションがもう 1 つあります。

コンソールを接続した状態でエージェントを実行している場合は、コンソールで Ctrl+C を押してエージェントを停止することもできます(ビルドが実行中の場合はキャンセルされます)。

macOS でのエージェントサービスの停止

ビルドエージェントが LaunchAgent サービスとして起動されている場合は、launchctl ユーティリティを使用して停止できます。

launchctl unload $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent.plist # or launchctl remove jetbrains.teamcity.BuildAgent

Java の設定

TeamCity ビルドエージェントは Java アプリケーションです(サポートされている Java バージョン)。

ビルドエージェントには 2 つのプロセスがあります。

  • Agent Launcher - エージェントプロセスを起動する Java プロセス

  • エージェント - ビルドエージェントのメインプロセス。エージェントランチャーの子プロセスとして実行されます

(Windows) .exe TeamCity ディストリビューションには、64 ビット Amazon Corretto8 がバンドルされています。
以前のバージョンの TeamCity エージェントを実行している場合は、エージェントのインストールを繰り返して JVM を更新する必要があります。

64 ビット JDK(JRE ではない)の使用をお勧めします。JDK は、IntelliJ IDEA プロジェクト、Java インスペクション重複などの一部のビルドランナーに必要です。Java ビルドがない場合は、JDK の代わりに JRE をインストールできます。
x64 ビット Java の使用は可能ですが、メインエージェントプロセスの -Xmx メモリ値を 2 倍にする必要がある場合があります(サーバーについては、ビルドエージェント起動プロパティの設定などのセクションを参照してください)。

.zip エージェントをインストールするには、適切な Java バージョンをインストールする必要があります。 PATH で利用できるようにするか、次のいずれかの場所で利用できるようにします。

  • <Agent home>/jre ディレクトリ

  • TEAMCITY_JREJAVA_HOME、または JRE_HOME 環境変数が指すディレクトリ内(変数の 1 つだけが定義されていることを確認してください)。

  • Windows サービスを介してエージェントを実行する予定の場合は、<agent home>\launcher\conf\wrapper.conf ファイルの wrapper.java.command プロパティを必ず Java 実行可能ファイルへの有効なパスに設定してください。

エージェントでの Java のアップグレード

エージェントを起動しようとしていて、デフォルトの場所のいずれかで必要な Java バージョン(現在 Java 8)が見つからない場合、エージェントは起動時にエラーを報告し、プロセスは起動せず、エージェントは TeamCity UI では切断されていると表示されます。

ビルドエージェントが Java 8 より古い Java バージョンを使用している場合、エージェントのページと Web UI のヘルスアイテムに対応する警告が表示されます。

最新の Java 8、64 ビットバージョンを使用することをお勧めします。OpenJDK 8(たとえば、バンドルされた Amazon Corretto(英語))1.8.0_161 以降。Oracle Java 8(英語) もサポートされています。

エージェント上の Java を更新するには、以下のいずれかを実行します。

  • TeamCity UI のエージェントの詳細ページに対応するアクションを含む Java バージョンのメモが表示される場合、新しい Java の使用に切り替えることができます。現在のビットと同じビット数の適切な Java バージョンがエージェントで検出されると、エージェントページが提供します。その Java を自動的に使用するように切り替えるアクション。アクションの呼び出し時に、新しい Java を使用して、エージェントプロセスが再起動されます(エージェントがアイドル状態になると、つまり現在のビルドがあれば終了します)。

  • (Windows)ビルドエージェントの Windows インストーラーは必要な Java にバンドルされているため、TeamCity サーバーのエージェントページから取得した Windows インストーラー(.exe)を使用してエージェントを手動で再インストールできます。インストール手順を参照してください。更新されたエージェントをインストールする前に、以前のバージョンのエージェントをアンインストールすることが重要です。エージェントのホームディレクトリで Uninstall.exe を呼び出し、削除チェックボックスをすべてオフにして、アンインストールをクリックします。

  • 必要な Java をエージェントの標準的な場所の 1 つにインストールし、エージェントを再起動します。エージェントはそれを検出し、Web UI で新しい Java を使用するアクションを提供する必要があります(上記を参照)。

  • 必要な Java をエージェントにインストールし、それを使用するようにエージェントを構成します

同じマシンに複数のビルドエージェントをインストールする

マシンが複数のビルドを同時に実行できる場合は、同じマシンに複数の TeamCity エージェントをインストールできます。ただし、ビルドの相互影響を最小限に抑え、ビルドをより予測可能にする(仮想)マシンごとに 1 つのエージェントを実行することをお勧めします。複数のエージェントをインストールする場合は、ユーザーレベルのリソース(Maven/Gradle/NuGet ローカルアーティファクトキャッシュなど)が競合しないように、異なる OS ユーザーにエージェントをインストールすることをお勧めします。

TeamCity は、エージェントが同じマシンにインストールされているか、異なるマシンにインストールされているかに関係なく、すべてのエージェントを同等に扱います。

同じマシンに複数の TeamCity ビルドエージェントをインストールする場合は、次の点を考慮してください。

  • そのようなエージェント上で実行されているビルドは、どのリソース(共通のディスクディレクトリ、OS プロセス、OS 一時ディレクトリ)によっても競合してはいけません。

  • ハードウェアとビルドの詳細によっては、ビルドのパフォーマンスが低下する場合があります。複数のビルドを同時に実行する場合は、ディスク、メモリ、または CPU のボトルネックがないことを確認してください。

  • できれば、エージェントは異なる OS ユーザーで実行する必要があります。

1 つのエージェントをインストールした後は、通常のインストール手順に従って追加のエージェントをインストールできます(下記の Windows サービスの例外を参照)。ただし、以下のことを確認してください。

  • エージェントは別々のディレクトリにインストールされます。

  • エージェントは、 buildAgent.properties ファイル内に独自の workDir および tempDir ディレクトリを持っています。

  • buildAgent.properties name および ownPort プロパティの値は一意です。

  • ビルド構成では、チェックアウトディレクトリへの絶対パスを指定していません(または、必要に応じて、「クリーンチェックアウト」オプションを有効にして、それらが並行して実行されないようにすることができます)。

通常、新しいエージェントのインストールでは、tempworklogssystem ディレクトリを除く既存のエージェントのディレクトリを新しい場所にコピーするだけです。次に、conf/buildAgent.properties を新しい name および ownPort 値で変更します。 authorizationToken プロパティをクリア(値を削除または削除)し、workDirtempDir が相対的であること / 他のエージェントと衝突しないことを確認します。

macOS での 2 番目のビルドエージェントの構成

macOS でいくつかのビルドエージェントを起動する場合は、ビルドエージェントのインストールと起動の手順を繰り返し、次の変更を加えます。

  • 2 番目のビルドエージェントを別のディレクトリにインストールします。

  • conf/buildAgent.properties で、別のエージェント名を指定します。

  • buildAgent/bin/mac.launchd.sh を実行しないでください。代わりに
    • $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent.plist ファイルのコピーを $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent2.plist として作成します。

    • $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent2.plist ファイルを編集して、以下のパラメーターを設定します。
      • Label パラメーターを jetbrains.teamcity.BuildAgent2 に設定

      • 2 番目のビルドエージェントホームへの正しいパスへの WorkingDirectory パラメーター

    • コマンド launchctl load $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent2.plist を使用して 2 番目のエージェントを開始します。

両方のビルドエージェントが実行されていることを確認するには、次のコマンドを使用します。

launchctl list | grep BuildAgent 70599 0 jetbrains.teamcity.BuildAgent2 69722 0 jetbrains.teamcity.BuildAgent

Windows での 2 番目のビルドエージェントの構成

Windows インストーラーを使用して追加のエージェントをインストールし、エージェントをサービスとして実行する場合は、同じマシンに 2 番目のエージェントをサービスとしてインストールすることはインストーラーでサポートされていないため、手動の手順を実行する必要があります。既存のサービスは上書きされます(機能リクエスト(英語)も参照してください)。

2 番目のエージェントをインストールするには、2 番目のエージェントを手動でインストールすることをお勧めします( .zip エージェントディストリビューションを使用)。Windows エージェントインストーラーを使用してサービスのインストールを選択することはできませんが、この方法で最初にインストールされたエージェントのアンインストールオプションは失われます。

2 番目のエージェントをインストールしたら、上記のセクションで説明したように、2 番目のエージェントの新しいサービスを登録します。