TeamCity 2020.2 ヘルプ

セカンダリノードの設定

メインの TeamCity サーバーに加えて、データディレクトリと外部データベースをメインサーバーと共有するセカンダリサーバー(ノード)を起動できます。詳細については、マルチノード設定を参照してください。

このページでは、セカンダリノードの構成方法について説明します。

セカンダリノードのインストール

セカンダリノードをインストールするには、セカンダリノードマシンで次の手順に従います。

  1. インストールし、いつものよう TeamCity ソフトウェアを:ディストリビューションパッケージをダウンロードし、インストールウィザードに従ってください。注意:インストールウィザードを使用してセカンダリノードをインストールする場合、手順 2 と 3 の環境変数が設定されるまで、TeamCity サーバーサービスを開始しないことが重要です。

  2. TEAMCITY_DATA_PATH 環境変数を介して共有データディレクトリへのパスを指定します。

  3. TEAMCITY_SERVER_OPTS 環境変数に引数を追加します。

TEAMCITY_SERVER_OPTS = -Dteamcity.server.nodeId=<nodeID> -Dteamcity.node.data.path=<path_to_node_data_directory> -Dteamcity.server.rootURL=<node url>

where

  • <nodeID> は、管理 | ノード構成ページに表示されるノードの ID です。

  • <path_to_node_data_directory> は、ノードのデータディレクトリへのパスです(ノード固有のデータディレクトリを参照)。

  • <node url> は、セカンダリノードのルート URL です。この URL がメインサーバーとエージェントからアクセス可能であることを確認してください。

セカンダリノードのメモリ設定

セカンダリノードには、メインノードと同じメモリ設定が必要です。メインノードの TEAMCITY_SERVER_MEM_OPTS 環境変数を既に構成している場合は、必ずセカンダリノードにも同じ変数を使用してください。メインノードが 64 ビット JVM を使用する場合、セカンダリノードも 64 ビット JVM を使用する必要があります。

起動とシャットダウン

A secondary node can be started/stopped using regular TeamCity scripts ( teamcity-server.bat , teamcity-server.sh ) or Windows services.

複数のセカンダリノードを起動する前に、すべてのノードからの要求を処理するのに十分な並列接続を受け入れるようにデータベースが構成されていることを確認してください。デフォルトでは、各ノードはデータベースへの 50 接続を必要とします。

セカンダリノードサーバーは、メインサーバーと同じ方法でログに記録します。 <TeamCity_installation_directory>/logs/teamcity-server.log ファイルでスタートアップの状態を確認できます。ブラウザーで <secondary_node_URL> を開き、通常の TeamCity 起動画面を表示します。

ビルドの実行中に、セカンダリサーバーとメインサーバーを停止または再起動できます。エージェントがしばらくセカンダリノードに接続できない場合、データをメインサーバーに再ルーティングします。メインサーバーも利用できない場合、エージェントはデータを保持し、サーバーが再び利用可能になったら再送信します。

責任の割り当て

デフォルトでは、新しく起動されたセカンダリノードは読み取り専用のユーザーインターフェースを提供し、バックグラウンドアクティビティを実行しません。管理 | サーバー管理 | ノード構成の各セカンダリノードに次の追加の責任を割り当てることができます。

  • ビルドによって生成されたデータの処理

  • VCS リポジトリのポーリング

  • ビルドトリガーの処理

  • データを変更するためのユーザーリクエストの処理

Secondary node responsibilities

任意の責任に割り当てられたノードにより、ユーザーはビルドで最も一般的なアクションを実行できます。

ノードの責任をいつでも有効または無効にできます。

セカンダリノードでのビルドによって生成されたデータの処理

1 つ以上のセカンダリノードを使用して、TeamCity エージェントからのトラフィックを処理することができます。これにより、関連する負荷をメイン TeamCity サーバーとは別のマシンに移動することができます。これにより、数百の同時ログビルドを処理する際の TeamCity パフォーマンスが向上します。

一般に、1 つのサーバーに 400 を超えるエージェントが接続されていない限り、ビルドを実行するために個別のノードは必要ありません。セカンダリノードを使用すると、セットアップで処理できるエージェントの数を大幅に増やすことができます。

Once you assign the Processing data produced by builds responsibility to a node, all newly started builds will be routed to this node. The existing running builds will continue being executed on the main server. When you disable the responsibility, only the newly started builds will be switched to the main server. The builds that were already running on the secondary node will continue running there.

セカンダリノードでの VCS リポジトリポーリング

通常、メイン TeamCity サーバーは、VCS リポジトリに変更がないかポーリングして、新しいコミットを検出します。VCS ポーリングをセカンダリノードに委譲して、メインサーバーのパフォーマンスを向上させることができます。この責任に割り当てることができるセカンダリノードは 1 つだけです。

Once you assign the VCS repositories polling responsibility to a node, it may take some time for the main server to finish the polling activities in progress, and then the secondary node will pick up this task. When you disable the responsibility, the main server will start polling VCS repositories.

メインサーバーでコミットフックを構成している場合、フックの変更は不要です。VCS ポーリングがセカンダリノードに委譲されている場合、フックは引き続き動作します。

セカンダリノードでのトリガーの処理

In setups with many build agents, a significant amount of the main server's CPU is allocated to constant processing of build triggers. By enabling the Processing build trigger responsibility for one or more secondary nodes, you can distribute the trigger processing tasks and CPU load between the main node and the responsible secondary ones. TeamCity distributes the triggers automatically but you can see what triggers are currently assigned to each node.

セカンダリノードでデータを変更するためのユーザーリクエストの処理

この責任は、セカンダリノードでのユーザーアクションを許可する責任があります。これは、メインサーバーがダウンしている場合やメンテナンスが行われている場合に特に役立ちます。

セカンダリノードでのユーザーレベルのアクション

If the "Processing user requests to modify data" responsibility is enabled on a secondary node, it will allow performing the most common user-level actions:

  • カスタムまたは個人のビルドを含むビルドのトリガー

  • ビルドの停止 / 削除および固定 / タグ付け / コメント作成

  • 調査の割り当てとミュートのビルドの問題とテスト

  • ビルドを成功 / 失敗としてマークする

  • ビルド変更の説明の編集

  • ソースのマージとソースアクションのラベル付け

  • お気に入りにビルドを追加する

  • 一般設定、グループとロール、アクセストークン、VCS ユーザー名、通知ルールなど、ユーザープロファイルの設定を変更する

  • プロジェクトとビルド構成の並べ替えと非表示

  • 保留中の変更を確認する

  • エージェント関連のアクション (see the list of actions(英語))

  • プロジェクトの編集と構成の構築

利用可能なアクションの完全なリストについては、課題トラッカーの関連タスクを参照してください:TW-62749(英語)TW-63346(英語)

管理者レベルのアクションは、セカンダリノードではまだ使用できません。サーバー構成を変更する必要がある場合は、メインサーバーを使用します。

アップグレードとダウングレード

メインサーバーとすべてのセカンダリノードを同じバージョンの TeamCity で実行することをお勧めします。詳細については、マルチノード設定を参照してください。

認証とライセンス

メインノードとセカンダリノードは同じライセンスで動作します。

セカンダリノードは、メインサーバーと同じ認証設定を使用します。

グローバル設定

セカンダリノートは、メインサーバーと同じグローバル設定(アーティファクトへのパス、バージョン管理設定など)を使用します。

内部プロパティ

すべてのセカンダリノードは、共有データディレクトリに保存されている共通の内部プロパティと、ノードごとに個別に構成されている特定のプロパティの両方に依存しています。ノード固有のプロパティの優先度が高く、競合が発生した場合は共通の値が上書きされます。

特定のセカンダリノードの共通プロパティを無効にするには、次の構文を使用してプロパティを渡します: -<property_name>

プロジェクトインポート

通常どおり、プロジェクトをメインサーバーにインポートできます。セカンダリノードは、再起動せずに、インポートされたデータをランタイムで検出します。

プロジェクトをセカンダリサーバーにインポートすることはできません。

プラグインを使用する

セカンダリノードは、メインサーバーで有効になっているすべてのプラグインにアクセスできます。メインサーバーでプラグインを有効にした場合、セカンダリノードがこのプラグインを使用できるようにセカンダリノードを再ロードする必要があります。

現在、次のバンドルプラグインはセカンダリノードで無効になっています。

  • 調査自動割り当て

  • Jira クラウド統合

  • Kubernetes のサポート

  • リモートホストにエージェントをインストールします (エージェントプッシュ)

  • WebHooks のサポート

掃除

TeamCity clean-up タスクは、メイン TeamCity サーバーでのみ実行されます。マルチノード構成およびシングルノード構成では、セカンダリサーバーが操作を処理している間にタスクを実行できます。

復元する

TeamCity Web インターフェースを介したバックアップは、メイン TeamCity サーバーでのみ実行できます。コマンドラインからのバックアップは、メインサーバーとセカンダリノードの両方で実行できます。

いずれかのノードで復元操作を実行できますが、TeamCity データベースとデータディレクトリを使用しているすべてのサーバーが停止している場合のみです。