追加のビルドエージェントの設定と実行
プロジェクトのカスタマイズとビルド構成の作成を開始する前に、ビルドエージェントを構成する必要があります。エージェントのインストールに進む前に、エージェントとサーバー間の通信および前提条件セクションを確認してください。
前提条件
必要な OS と環境の権限
インストールの前に、矛盾するソフトウェアセクションを確認してください。問題がある場合は、競合するソフトウェアが使用されていないことを確認してください。
TeamCity ビルドエージェントを実行するには、エージェントの実行に使用される環境とユーザーアカウントが以下の要件を満たす必要があります。
共通
エージェントプロセス(Java)は次のことを行う必要があります。
buildAgent.properties
ファイルのserverUrl
プロパティで設定されたサーバー URL へのアウトバウンド HTTP 接続を開くことができる(通常は TeamCity UI を表示するためにブラウザーで使用するのと同じアドレス)。設定された URL のパスへのリクエスト送信は制限されるべきではありません。推奨リバースプロキシ設定も参照してください。エージェントマシンまたはサーバーマシンにインストールされているファイアウォール、ネットワーク構成、プロキシ(存在する場合)が、これらの要件に準拠していることを確認してください。次のディレクトリに対する完全な許可(読み取り / 書き込み / 削除)を再帰的に持っている:
<agent home>
(自動エージェントアップグレードおよびエージェントツールのサポートに必要)、<agent work>
、<agent temp>
、エージェントシステムディレクトリ(buildAgent.properties
ファイルのworkDir
、tempDir
、systemDir
パラメーターによって設定)。(ビルドを実行するための)プロセスを起動できるようにします。
次の親プロセス出口でネストされたプロセスを起動できる(これはエージェントのアップグレード中に使用されます)。
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. 次のオプションのいずれかを使用してビルドエージェントをインストールします。
ZIP ファイルをダウンロードして手動でインストールする(任意のプラットフォーム): 最小およびフルパックの ZIP アーカイブが利用可能
Docker エージェントイメージオプションを使用して、公式の TeamCity エージェントイメージ(英語)に基づいて Docker コンテナーを準備する
2. インストール後、 conf/buildAgent.properties
ファイルで TeamCity サーバーの名前とアドレスを指定してエージェントを構成します。
3. 開始エージェント。エージェントが正しく実行されていないように思われる場合は、エージェントのログを確認してください。
新しくインストールされたエージェントが初めてサーバーに接続すると、Agents
ページに表示されます。Unauthorized agents
タブは、それを承認する権限を持つ管理者 / ユーザーに表示されます。エージェントは TeamCity Web UI で承認されるまでビルドを実行しません。サーバーと同じコンピューター上で実行されているエージェントは、デフォルトで許可されています。
許可されたエージェントの数は、サーバー上のエージェントライセンスの数によって制限されます。詳細はライセンスポリシーを参照してください。
Windows インストーラーによるインストール
TeamCity Web UI で、エージェントタブに移動します。
ビルドエージェントをインストールするリンクをクリックし、Windows インストーラーを選択してインストーラをダウンロードしてください。
エージェントで、
agentInstaller.exe
Windows インストーラーを実行して、インストール手順に従います。
Docker エージェントイメージを介したインストール
TeamCity Web UI で、エージェントタブに移動します。
ビルドエージェントをインストールするリンクをクリックして、Docker エージェントイメージを選択します。
開いたページ(英語)の指示に従います。
ZIP ファイルによるインストール
JDK(JRE)1.8.0_161 以降(Java 8-11 はサポートされていますが、1.8.0_161 + を推奨)がエージェントコンピューターに正しくインストールされていることを確認してください。
エージェントコンピューターで、
JRE_HOME
またはJAVA_HOME
環境変数が設定されていることを確認します(それぞれ、インストール済みの JRE または JDK ディレクトリを指している)。TeamCity Web UI で、エージェントタブに移動します。
- ビルドエージェントをインストールするリンクをクリックし、2 つのオプションのいずれかを選択してアーカイブをダウンロードします。
最小限の ZIP ファイルディストリビューション : プラグインのない通常のビルドエージェント
(TeamCity 2020.1 以降)完全な ZIP ファイルのディストリビューション *: サーバーで現在有効になっているすべてのプラグインがプリパックされたフルビルドエージェント
ダウンロードしたファイルを目的のディレクトリに抽出します。
<installation path>\conf
ディレクトリに移動し、buildAgent.dist.properties
というファイルを見つけて、buildAgent.properties
に名前を変更します。buildAgent.properties
ファイルを編集して、TeamCity サーバーの URL(HTTPS を推奨。注を参照)とエージェントの名前を指定します。エージェント構成の詳細については、エージェント構成の構築ページを参照してください。Linux では、
bin/agent.sh
シェルスクリプトに実行権限を与える必要があるかもしれません。
Windows では、エージェントの手動起動を使用する代わりに、ビルドエージェント Windows サービスをインストールすることもできます。
エージェントプッシュによるインストール
TeamCity は、リモートホストにビルドエージェントをインストールできるエージェントプッシュ機能を提供します。現在、サーバーホストプラットフォームとビルドエージェントのターゲットのサポートされている組み合わせは次のとおりです。
Unix ベースの TeamCity サーバーから、ビルドエージェントは Unix ホストにのみインストールできます (SSH 経由)
Windows ベースの TeamCity サーバーから、ビルドエージェントを Unix(SSH 経由)または Windows(psexec 経由)ホストにインストールできます。
リモートホスト要件
リモートホストにはいくつかの要件があります。
プラットフォーム | 前提条件 |
---|---|
Linux |
|
Windows |
次のコマンドで接続をテストできます。 net use \\target\Admin$ /user:Administrator
dir \\target\Admin$
|
インストール
TeamCity サーバーの WebUI で、エージェント | エージェントプッシュタブに移動し、エージェントをインストールをクリックします。
複数のターゲットホストに同じ設定を使用する場合は、これらの設定でプリセットを作成し、エージェントを別のリモートホストにインストールするたびに使用できます。エージェントのインストールダイアログで、保存されたプリセットを選択するか、カスタム設定を使用するを選択し、ターゲットホストプラットフォームを指定して、対応する設定を構成します。SSH を介した Linux システムへのエージェントプッシュは、SSH ポートパラメーターとして指定されたカスタムポート(デフォルトは 22)をサポートします。プリセットで指定されたポートは、実際のエージェントのインストール中に、ホスト名(たとえば、
hostname.domain:2222
)でオーバーライドできます。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 サービスを作成するためにも実行する必要があります。
サービスをインストールするには:
必要な名前と ID を持つサービス(下記の #4 を参照、サービス名はデフォルトで
TeamCity Build Agent
です)が存在しないか確認してください。インストールされている場合は取り外します。<agent home>\launcher\conf\wrapper.conf
ファイルのwrapper.java.command
プロパティに、JDK インストールディレクトリの Java 実行可能ファイルへの有効なパスが含まれていることを確認してください。Windows ディストリビューションとともにインストールされたエージェントにはwrapper.java.command=../jre/bin/java
を使用できます。引用符なしで java.exe ファイルのパスを指定してください。"System" ではなく、ユーザーアカウント(推奨)でエージェントを実行する場合は、適切な資格情報を使用して
wrapper.ntservice.account
プロパティとwrapper.ntservice.password
プロパティを<agent home>\launcher\conf\wrapper.conf
ファイルに追加します。(2 回目以降のインストールの場合)
wrapper.console.title
、wrapper.ntservice.name
、wrapper.ntservice.displayname
、wrapper.ntservice.description
プロパティがコンピューター内で一意の値を持つように、<agent>\launcher\conf\wrapper.conf
ファイルを変更します。新しいエージェントサービスを登録するのに十分な特権を持つユーザーで
<agent home>\bin\service.install.bat
スクリプトを実行します。説明されているように構成された後にのみ、初めてエージェントを開始するようにしてください。
サービスを開始するには
実行
<agent home>/bin/service.start.bat
(または標準の Windows サービスアプレットを使用する)
サービスを停止するには
実行
<agent home>/bin/service.stop.bat
(または標準の Windows サービスアプレットを使用する)
インストール後、標準の Windows net.exe
ユーティリティを使用してサービスを管理することもできます。
例(デフォルトのサービス名を想定):
<agent home>\launcher\conf\wrapper.conf
ファイルを使用して、エージェントの JVM パラメーターを変更することもできます。
ビルドエージェントサービスを実行するために使用されるユーザーアカウントには、前述のように、エージェントサービスを開始または停止するのに十分な権限が必要です。
Linux での自動エージェント起動
Linux のマシンブートでエージェントを自動的に実行するには、デーモンプロセスを構成して agent.sh start
コマンドで開始し、agent.sh stop
コマンドで停止します。
systemd については、teamcityagent.service
設定ファイルの例を参照してください。
init.d
の場合は、手順例を参照してください。
1. サービスの開始 / 停止サービススクリプトディレクトリに移動します。
2. ビルドエージェントサービススクリプトを開きます。
3. 以下をファイルに貼り付けます。
4. ファイルを実行する権限を設定します。
5. 適切なツールを使用して、マシンの起動時および再起動時にエージェントサービスを開始するリンクを作成します。
Debian/Ubuntu の場合:
Red Hat/CentOS の場合:
macOS での自動エージェント開始
macOS の場合、TeamCity はビルドユーザーがログインしたときに自動的にビルドエージェントをロードする機能を提供します。
LaunchAgent
アプローチ:
LaunchAgent
を介して自動ビルドエージェント起動を設定するには、次の手順に従います。
1. buildAgent.zip
を介して Mac にビルドエージェントをインストールします。
2. conf/buildAgent.properties
ファイルを準備します(少なくともそこにエージェント名を設定します)。
3. 適切なエージェントアップグレードプロセスを確保するために、buildAgent
ディレクトリのすべてのファイルが your_build_user
によって所有されていることを確認してください。
4. 次のコマンドでビルドエージェントをロードします。
your_build_user
アカウントでこれらのコマンドを実行します。
ビルドエージェントが TeamCity サーバーから自動アップグレードするための数分待つ。ログでプロセスを見ることができます:
5. ビルドエージェントがアップグレードされ、TeamCity サーバーに正常に接続したら、エージェントを停止します。
6. ビルドエージェントを TeamCity サーバーからアップグレードした後、buildAgent/bin/jetbrains.teamcity.BuildAgent.plist
ファイルを $HOME/Library/LaunchAgents/
ディレクトリにコピーします。ルート権限で TeamCity を起動したくない場合は、.plist
ファイルで UserName キーを指定します。例:
7. ここで説明するように、ビルドユーザーとして自動的にログインするように Mac システムを構成します。
8. リブート。
システムの起動時に、ビルドユーザーは自動的にログインし、ビルドエージェントが起動します。
ビルドエージェントが実行されていることをすばやく確認するには、次のコマンドを使用します。
ビルドエージェントの停止
エージェントを手動で停止する、stop
パラメーターを指定して <Agent home>\agent
スクリプトを実行します。
stop
を使用して、現在のビルドが終了した後に停止を要求します。
stop force
を使用して、即時停止を要求します(ビルドがエージェントで実行されている場合、ビルドは突然停止(キャンセル)されます)。
Linux では、stop kill
を使用してエージェントプロセスを強制終了するオプションがもう 1 つあります。
コンソールを接続した状態でエージェントを実行している場合は、コンソールで Ctrl+C を押してエージェントを停止することもできます(ビルドが実行中の場合はキャンセルされます)。
macOS でのエージェントサービスの停止
ビルドエージェントが LaunchAgent
サービスとして起動されている場合は、launchctl
ユーティリティを使用して停止できます。
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_JRE
、JAVA_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
プロパティの値は一意です。ビルド構成では、チェックアウトディレクトリへの絶対パスを指定していません(または、必要に応じて、「クリーンチェックアウト」オプションを有効にして、それらが並行して実行されないようにすることができます)。
通常、新しいエージェントのインストールでは、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 番目のエージェントを開始します。
両方のビルドエージェントが実行されていることを確認するには、次のコマンドを使用します。
Windows での 2 番目のビルドエージェントの構成
Windows インストーラーを使用して追加のエージェントをインストールし、エージェントをサービスとして実行する場合は、同じマシンに 2 番目のエージェントをサービスとしてインストールすることはインストーラーでサポートされていないため、手動の手順を実行する必要があります。既存のサービスは上書きされます(機能リクエスト(英語)も参照してください)。
2 番目のエージェントをインストールするには、2 番目のエージェントを手動でインストールすることをお勧めします( .zip
エージェントディストリビューションを使用)。Windows エージェントインストーラーを使用してサービスのインストールを選択することはできませんが、この方法で最初にインストールされたエージェントのアンインストールオプションは失われます。
2 番目のエージェントをインストールしたら、上記のセクションで説明したように、2 番目のエージェントの新しいサービスを登録します。
関連ページ:

ビルドエージェント | TeamCity
TeamCity ビルドエージェントは、TeamCity サーバーからのコマンドをリッスンし、実際のビルドプロセスを開始するソフトウェアです。TeamCity サーバーとは別にインストールおよび構成されます。エージェントは、サーバーと同じコンピューターまたは別のマシンにインストールできます(サーバーのパフォーマンス上の理由から、後者が推奨されるセットアップです)。エージェントは、TeamCity サーバーと同じオペレーティングシステム(OS)または別の OS を実行できます。TeamCity ビル...

Amazon EC2 用の TeamCity のセットアップ | TeamCity
TeamCity Amazon EC2 統合により、Amazon アカウントで TeamCity を構成し、キューに入れられたビルドに基づいて TeamCity エージェントでオンデマンドでイメージを開始および停止できます。他のクラウドソリューションとの統合が可能です。概要:マシンイメージは、起動時に TeamCity エージェントを起動するように事前構成されていることを前提としています(以下の詳細を参照)。TeamCity で 1 つまたは複数のイメージを使用してクラウドプロファイルを構成す...