TeamCity 2020.2 ヘルプ

マルチノード設定

TeamCity では、メインインスタンスに加えて、1 つ以上のセカンダリサーバーインスタンス（ノード）を構成および起動できます。メインノードとセカンダリノードは同じライセンスで動作し、TeamCity データディレクトリとデータベースを共有します。

マルチノードセットアップを使用すると、次のことができます。

  • ほとんどの操作でダウンタイムがゼロになる高可用性 TeamCity インストールをセットアップします。セカンダリノードは、メインサーバーのダウンタイム中（たとえば、マイナーアップグレード中）は通常どおり動作します。

  • セカンダリノードにタスクを委譲することにより、メインサーバーのパフォーマンスを向上させます。セカンダリノードは、新しいコミットを検出し、ビルドの実行によって生成されたデータ（ビルドログ、アーティファクト、統計値）を処理できます。

インストール後、各セカンダリノードはメインサーバーの読み取り専用コピーとして実行されます。その機能を拡張するために、特定の責任に割り当てることができます。この場合、セカンダリノードにより、ユーザーはビルドで最も一般的なアクションを実行できます。

次の図は、1 つのメインノードと 2 つのセカンダリノードを備えた TeamCity インストールの例を示しています。各セカンダリノードには特定の責任があります。

TeamCity setup with two nodes

マルチノードセットアップの前提条件

このセクションでは、複数の TeamCity ノードをセットアップするための構成要件について説明します。

共有データディレクトリ

メイン TeamCity サーバーとセカンダリノードは、共有する必要がある同じ TeamCity データディレクトリと、同じ外部データベースにアクセスする必要があります。

高可用性セットアップでは、TeamCity データディレクトリを別のマシンに保存することをお勧めします。この場合、メインサーバーがダウンしても、セカンダリノードは共有データディレクトリに接続できます。

TeamCity サーバーノードがインストールされるすべてのマシンが、読み取り / 書き込みモードでデータディレクトリにアクセスできることを確認します。パフォーマンスの良い専用ネットワークファイルストレージを使用することをお勧めします。

典型的なデータディレクトリのマウントオプションは SMB と NFS です。TeamCity は通常のファイルシステムとしてデータディレクトリを使用するため、すべての基本的なファイルシステム操作をサポートする必要があります。バッキングストレージとマウント方法は、厳密な I/O 操作カウントまたは I/O ボリューム制限を課すべきではありません。

ストレージとネットワークのパフォーマンスをチューニングすることをお勧めします。ストレージソリューションのパフォーマンスガイドラインを必ず確認してください。例: サーバーとストレージ間のネットワーク接続の MTU を増やすと、通常、アーティファクトの転送速度が上がります。

Windows では、TeamCity がサービスとして実行されている場合、ノードはマップされたネットワークドライブを介して TeamCity データディレクトリにアクセスできない場合があることに注意してください。これは、Windows サービスがマップされたネットワークドライブで機能できず、TeamCity がデータディレクトリパスの UNC 形式（\\host\directory）をサポートしていないために発生します。この問題を回避するには、 mklink (英語) を使用して、ネットワークドライブにシンボリックリンクを作成できます。

mklink /d "C:\<path to mount point>" "\\<host>\<shared directory name>\"

OS でリモートからローカルへのシンボリックリンク評価が有効になっていることを確認します。

fsutil behavior query SymlinkEvaluation

それらを有効にするには、次のコマンドを使用します。

fsutil behavior set SymlinkEvaluation R2L:1

データディレクトリマウントでのネットワーククライアントキャッシュの無効化

すべてのノードを「参照」することが重要です。共有データディレクトリの現在の状態。そうでない場合、さまざまな不安定な動作と頻繁なビルドログの破損が発生する可能性があります。

TeamCity ノードが SMB プロトコルを介して共有されるデータディレクトリを使用して Windows で実行される場合は、関連記事(英語)に記載されているすべてのレジストリキーがすべての TeamCity ノードで 0 に設定されていることを確認してください(英語)。

データディレクトリが NFS を介して共有されている場合は、すべてのノードのマウント設定に lookupcache=positive オプションがあることを確認してください。

メインノードキャッシュディレクトリ

メインノードがネットワークの場所を介してデータディレクトリにアクセスする場合は、system/caches ディレクトリをローカルディスクに移動することを強くお勧めします。

ノード固有のデータディレクトリ

メインサーバーと共有されるデータディレクトリに加えて、セカンダリノードには、いくつかのキャッシュ、解凍された外部プラグイン、およびその他の構成を格納するローカルデータディレクトリが必要です。

ノードの最初の起動時に、ローカルデータディレクトリが <TeamCity Data Directory>/nodes/<node_ID> として自動的に作成されます。これは通常、すべてのノードで使用される共有データディレクトリの場所です。

すべてのノードから共有 TeamCity データディレクトリへの余分な IO リクエストによって引き起こされる負荷を減らし、ノードのデータへのアクセスを高速化するために、ノード固有のデータディレクトリの場所を再定義してノードのローカルディスクを使用することを強くお勧めします。

ローカルディレクトリへの新しいパスを定義するには、TeamCity 起動スクリプトの -Dteamcity.node.data.path プロパティを使用します。詳細はセカンダリノードの設定を参照してください。

プロキシ設定

高可用性 TeamCity インストールをセットアップするには、メインサーバーとセカンダリノードの両方をリバースプロキシの背後にインストールし、メインサーバーが利用可能な場合はリクエストをメインサーバーにルーティングし、その他の場合はセカンダリサーバーにリクエストをルーティングするように構成する必要があります。TeamCity サーバーをリバースプロキシの背後に初めてセットアップする場合は、このトピックに関するメモを確認してください。

次の NGINX(英語) 構成は、メインサーバーが使用できない場合、またはメインサーバーが 503 ステータスコードで応答する場合（起動時またはアップグレード時）にのみ、セカンダリノードに要求をルーティングします。

http { upstream backend { server teamcity-main.local:8111 max_fails=0; # full internal address of the main server; server teamcity-ro.local:8111 backup; # full internal address of the secondary node; } server { location / { proxy_pass http://backend; proxy_next_upstream error timeout http_503 non_idempotent; } } }

NGINX オープンソース(英語)はアクティブヘルスチェック(英語)（高可用性インストールを構成するためのより良い方法）をサポートしておらず、DNS 解決の問題が発生する可能性があることに注意してください。NGINX Plus(英語) または HA プロキシ(英語)の使用を検討してください。

HA プロキシの構成例:

resolvers dns nameserver dns %IP%:%PORT% resolve_retries 3 timeout resolve 1s timeout retry 1s defaults mode http frontend http-in bind *:80 default_backend tc-ha backend tc-ha option httpchk GET /login.html default-server inter 2s fall 2 rise 2 server tc_main_node %TC_MAIN_NODE_URL:8111% check resolvers dns server tc_ro_node %TC_RO_NODE_URL:8111% backup check resolvers dns

ドメイン分離プロキシ構成

ドメイン分離モードでは、アーティファクトを提供するための専用ドメインを構成する必要があります。このドメインからプロキシアドレスを指す DNS に新しいレコードを必ず追加してください。たとえば、プロキシ URL を指す CNAME レコード(英語)の場合があります。

ファイアウォール設定

ファイアウォール設定では、エージェントとメイン TeamCity サーバーからセカンダリノードにアクセスできるようにする必要があります（メインサーバーも HTTP でノードと通信します）。

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

メイン TeamCity サーバーとすべてのセカンダリノードのバージョンを同じにすることをお勧めします。場合によっては、メインサーバーとセカンダリノードが、たとえばメインサーバーのマイナーアップグレード中など、短期間異なるバージョンを実行していることがあります。セカンダリノードとメインサーバーのバージョンが異なる場合、対応するヘルスレポートが両方のノードに表示されます。

マイナーバージョン（バグ修正リリース）にアップグレードする場合、TeamCity データは同じ形式であるため、メインノードとセカンダリノードは問題なく実行されているはずです。メイン TeamCity サーバーをアップグレードしてから、セカンダリサーバーを手動で、または自動更新を使用してアップグレードできます。

メインサーバーをメジャーバージョンにアップグレードすると、その TeamCity データ形式が変更されます。データ形式エラーの可能性を回避するために、メインサーバーのアップグレードを開始する前にすべてのセカンダリノードを停止することをお勧めします。
タスクを処理できるようにするには、メインサーバーのメジャーアップグレード後にすべてのセカンダリノードをアップグレードする必要があります。

TeamCity のメジャーバージョンへのマルチノードセットアップ内のノードをアップグレードするには、次の手順を実行します。

  1. すべてのセカンダリノードを停止します。

  2. 通常どおり、メイン TeamCity サーバーでアップグレードを開始します。

  3. アップグレードを続行します。

  4. すべてが正しく機能し、エージェントが接続していることを確認します（エージェントは、セカンダリノードにルーティングされるはずだったデータをメインサーバーに再ルーティングします）。

  5. セカンダリノードの TeamCity インストールを同じバージョンにアップグレードします。

  6. セカンダリノードを起動し、メインサーバーの管理 | サーバー管理 | ノード構成ページで接続されていることを確認します。

マルチノード設定でノードをダウングレードするには、次の手順に従います。

  1. メインサーバーとセカンダリノードをシャットダウンします。

  2. バックアップからのデータを復元する（アップグレード中にデータ形式が変更された場合のみ）。

  3. メインサーバー上の TeamCity ソフトウェアをダウングレードします。

  4. メイン TeamCity サーバーを起動し、すべてが正しく動作することを確認します。

  5. セカンダリノードの TeamCity ソフトウェアをメインサーバーと同じバージョンにダウングレードします。

  6. セカンダリノードを起動します。

TeamCity エージェントは、アップグレード / ダウングレードを自動的に実行します。

セカンダリノードの制限

セカンダリサーバーには、メインサーバーと比較していくつかの制限があります。

  • セカンダリノードでは、サーバーの構成と状態を変更できません。責任のないノードは読み取り専用モードで提供されます。責任を持つノードはユーザーレベルのアクションを提供します。どちらの場合も、すべての管理ページとアクションが利用できるわけではありません。

  • 現在、バンドルされたプラグインと一部の他のプラグインの限られたセットのみがセカンダリサーバーによってロードできます。外部プラグインが提供する機能の一部が欠落している場合があります。詳細はセカンダリノードの設定を参照してください。

  • 自分を記憶オプションを選択しなかった場合、ユーザーはセカンダリノードにルーティングされるときに再ログインする必要がある場合があります。

セキュリティに関する注意事項 セカンダリノードの設定