TeamCity 2020.1ヘルプ

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

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

前提条件

必要なOSと環境の権限

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

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

Common

The agent process (Java) must:

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

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

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

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

Windows

Linux

  • The user must be able to run the shutdown command (for the agent machine reboot functionality and the machine shutdown functionality when running in a cloud environment)

  • If you are using systemd, it should not kill the processes on the main process exit (use RemainAfterExit=yes(英語))

ビルド関連の権限

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

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

A TeamCity agent connects to the TeamCity server via the URL configured as the serverUrl agent property. This is called unidirectional agent-to-server connection. If specifically configured, TeamCity agent can use legacy bidirectional communication which also requires establishing a connection from the server to the agents. To view whether the agent-server communication is unidirectional or bidirectional for a particular agent, navigate to Agents | <Agent Name> | Agent Summary tab, the Details section, Communication Protocol.

Unidirectional Agent-to-Server Communication

Agents use unidirectional agent-to-server connection via the polling protocol: the agent establishes an HTTP(S) connection to the TeamCity Server, and polls the server periodically for server commands.

It is recommended to use HTTPS for agent to server communications (check related server configuration notes). If the agents and the server are deployed into a secure environment, agents can be configured to use plain HTTP URL for connections to the server as this reduces transfer overhead. Note that the data travelling through the connection established from an agent to the server includes build settings, repository access credentials and keys, repository sources, build artifacts, build progress messages and build log. In case of using the HTTP protocol that data can be compromised via the "man in the middle" attack.

Bidirectional Communication

The bidirectional communication is a legacy connection between the agent and the server and it needs to be specifically enabled (see the example below). When enabled, it requires the agent to connect to the server via HTTP (or HTTPS) and the server to connect to the agent via HTTP.

The data that is transferred via the connections established by the server to agents is passed via an unsecured HTTP channel and thus is potentially exposed to any third party that may listen to the traffic between the server and the agents. Moreover, since the agent and server can send "commands" to each other, an attacker that can send HTTP requests and capture responses may in theory trick the agent into executing an arbitrary command and perform other actions with a security impact.

The communication protocol used by TeamCity agents is determined by the value of the teamcity.agent.communicationProtocols server internal property. The property accepts a comma-separated ordered list of protocols (polling and xml-rpc are supported protocol names) and is set to teamcity.agent.communicationProtocols=polling by default. If several protocols are specified, the agent tries to connect using the first protocol from this list and if it fails, it will try to connect via the second protocol in the list. polling means unidirectional protocol, xml-rpc - older, bidirectional communication.

Changing Communication Protocol

  • To change the communication protocol for all agents, set the TeamCity server teamcity.agent.communicationProtocols server internal property. The new setting will be used by all agents which will connect to the server after the change. To change the protocol for the existing connections, restart the TeamCity server.

  • By default, the agent's property is not configured; when the agent first connects to the server, it receives it from the TeamCity server. To change the protocol for an individual agent after the initial agent configuration, change the value of the teamcity.agent.communicationProtocols property in the agent's properties. The agent's property overrides the server property. After the change the agent will restart automatically upon finishing a running build, if any.

  • When connecting TeamCity agents of version 2018.1+ to TeamCity server of version before 9.1 (e.g. after roll back following an upgrade), the agents will need to be updated to use xml-rpc protocol (or they can be reinstalled) to be able to connect to an older server to perform the self-update procedure.

Installing Additional Build Agents

1. Install a build agent using any of the following options:

2. After installation, configure the agent specifying its name and the address of the TeamCity server in the conf/buildAgent.properties ファイル。

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 6-10はサポートされていますが、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）6-10（1.8.0_161以降を推奨）。JVMは、JAVA_HOME （JRE_HOME）グローバル環境変数を介して到達可能であるか、グローバルパス内にある必要があります (たとえば、ユーザーの .bashrc ファイルで指定される代わりに)

  • unzip ユーティリティ。

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

Windows

  • インストールされたJDK / JRE 6-10（1.8.0_161以降を推奨）。

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

    • リモートホスト上の管理シェア(英語)が有効化され、アクセス可能です。

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

    • リモートレジストリは機能します（regedit は services.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番目以降のインストールの場合） <agent>\launcher\conf\wrapper.conf ファイルを変更して、wrapper.console.title , wrapper.ntservice.name , wrapper.ntservice.displaynameおよび wrapper.ntservice.description プロパティがコンピューター内で固有の値を持つようにします。

  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を押してエージェントを停止することもできます（ビルドが実行中の場合はキャンセルされます）。

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

ビルドエージェントが 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 Corretto 8がバンドルされています。
以前のバージョンのTeamCityエージェントを実行している場合は、JVMを更新するためにエージェントのインストールを繰り返す必要があります。

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

For the .zip agent installation you need to install the appropriate Java version. Make it available via PATH or available in one of the following places:

Upgrading Java on Agents

If you are trying to launch an agent, and it is not able to find the required Java version (currently Java 6) in any of the default locations, the agent will report an error on starting, the process will not launch, and the agent will be shown as disconnected in the TeamCity UI.

If a build agent uses a Java version older than Java 8, you will see the corresponding warning on the agent's page and a health item in the web UI.

It is recommended to use latest Java 8, 64-bit version. OpenJDK 8 (for example, bundled Amazon Corretto(英語)) 1.8.0_161 or later. Oracle Java 8(英語) is also supported.

To update Java on agents, do one of the following:

  • If the agent details page in the TeamCity UI displays a Java version note with the corresponding action, you can switch to using newer Java: if the appropriate Java version of the same bitness as the current one is detected on the agent, the agent page provides an action to switch to using that Java automatically. Upon the action invocation, the agent process is restarted (once the agent becomes idle, i.e. finishes the current build if there is one) using the new Java.

  • (Windows) Since the build agent Windows installer comes bundled with the required Java, you can just manually reinstall the agent using the Windows installer (.exe) obtained from the TeamCity server Agents page. See installation instructions. It is important to uninstall the previous version of the agent before installing the updated agent: invoke Uninstall.exe in the agent home directory, clear all the "Remove..." checkboxes, and click Uninstall.

  • Install a required Java on the agent into one of the standard locations, and restart the agent - the agent should then detect it and provide an action to use a newer Java in the web UI (see above).

  • Install a required Java on the agent and configure the agent to use it.

Installing Several Build Agents on the Same Machine

You can install several TeamCity agents on the same machine if the machine is capable of running several builds at the same time. However, we recommend running a single agent per (virtual) machine to minimize builds cross-influence and making builds more predictable. When installing several agents, it is recommended to install them under different OS users so that user-level resources (like Maven/Gradle/NuGet local artifact caches) do not conflict.

TeamCity treats all agents equally regardless of whether they are installed on the same or on different machines.

When installing several TeamCity build agents on the same machine, consider the following:

  • The builds running on such agents should not conflict by any resource (common disk directories, OS processes, OS temp directories).

  • Depending on the hardware and the builds' specifics, you may experience degraded building performance. Ensure there are no disk, memory, or CPU bottlenecks when several builds are run at the same time.

  • Preferably, agents should run under different OS users.

After having one agent installed, you can install additional agents by following the regular installation procedure (see an exception for the Windows service below), but make sure that:

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

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番目のエージェントの新しいサービスを登録します。

最終更新日: 2020年8月26日
AWSでTeamCityスタックを実行するエージェント構成の構築