プロキシサーバーの構成
この記事では、次のプロキシタイプの構成に関する一般的な推奨事項を示します。
プロキシの背後に TeamCity サーバーをセットアップする
例を考えてみましょう:
TeamCity サーバーはローカル URL http://teamcity.local:8111/tc (英語) にインストールされます。
パブリック URL http://teamcity.public:400/tc (英語) として外部から閲覧可能です。
クライアントがリソースにアクセスするために使用する実際の絶対 URL を TeamCity が「認識」していることを確認するには、次の操作を行う必要があります。
以下の説明に従って、リバースプロキシを設定します。
TeamCity にバンドルされている Tomcat サーバーを構成します。
これらの URL は、クライアントのリダイレクトやその他の応答で絶対 URL を生成するために使用されます。
プロキシを設定した後、TeamCity グローバル設定のサーバー URL 値をプロキシ URL に変更する必要もあります。
メモ: 内部 TeamCity サーバーは、外部アドレスによって外部から見えるのと同じコンテキスト (ホスト名の後の URL の一部) で動作する必要があります。TeamCity サーバーのコンテキスト変更手順も参照してください。
異なるコンテキストでサーバーを実行する必要がある場合は、コンテキスト変更プロキシがこの事実を TeamCity から隠す必要があることに注意してください。たとえば、サーバーのリダイレクト URL と Cookie 設定パスを元の (外部) コンテキストにマップする必要があります。
プロキシは、一般的な Web セキュリティを念頭に置いて構成する必要があります。Referer や Origin などのヘッダー、およびすべての不明なヘッダーは、変更されていない形式で TeamCity Web アプリケーションに渡す必要があります。例: TeamCity は、クライアントによって追加された X-TC-CSRF-Token ヘッダーに依存しています。
Apache
バージョン 2.4.5 以降を推奨します。以前のバージョンは WebSocket プロトコルをサポートしていません。
Apache を使用する場合は、TeamCity サーバーを構成するために専用の「コネクター」ノードアプローチを必ず使用してください。
ProxyPass のルール(英語)の順序に注意してください。競合する ProxyPass ルールは、最も長い URL から順に並べ替える必要があります。
デフォルトでは、Apache は限られた数の並列接続のみを許可しますが、WebSocket プロトコルを使用する場合は不十分な場合があります。たとえば、多くのクライアントが Web UI を開いたときに、TeamCity サーバーが応答しなくなる可能性があります。これを修正するには、Apache 構成を微調整する必要がある場合があります。
例: Unix では、mpm_worker(英語) に切り替えて、同時接続の最大数を構成する必要(英語)があります。
Windows では、Apache ドキュメント(英語)に従って、ThreadsPerChild(英語) 値を増やす必要がある場合があります。
NGINX
バージョン 1.3 以降を推奨します。以前のバージョンは WebSocket プロトコルをサポートしていません。
IIS
IIS リバースプロキシの背後に TeamCity サーバーを構成するには、次の手順を実行します。
TeamCity サーバーの正規名 (CNAME) レコードを作成します。
TeamCity サーバーと外部ユーザー間の安全な接続を保証する証明書を発行します。証明書が有名な認証局によって発行されたものではない場合は、TeamCity に接続するすべてのマシン上の Java 証明書ストアに証明書を手動で追加する必要がある場合があります。
keytool -importcert -file <cert file> -keystore <path to JRE installation>/lib/security/cacertsサーバー URL をプロキシ URL に変更します。
TeamCity Tomcat の設定セクションに従って、<TeamCity_ ホームディレクトリ>/conf/server.xml ファイルを編集して、必要な TeamCity Tomcat サーバープロパティを設定します。
手順 5 ~ 8 は Powershell で実行します。Get-IISConfigSection および Set-IISConfigAttributeValue コマンドレットを使用して、SSL フラグを有効にします。
$ConfigSectionTC = Get-IISConfigSection -SectionPath "system.webServer/security/access" -Location "<IIS Website name>"; Set-IISConfigAttributeValue -AttributeName sslFlags -AttributeValue Ssl -ConfigElement $ConfigSectionTC;Set-WebConfigurationProperty コマンドレットを使用して、HTTP 転送された IP が Web 要求から渡されるようにするサーバー変数を追加します。
Set-WebConfigurationProperty -pspath "IIS:/" -Location "<IIS Website name>" -filter "system.webServer/rewrite/allowedServerVariables" -name "." -value @{name="HTTP_FORWARDED"} -FORCEプロキシ設定を有効にする:
Set-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST" -filter "system.webServer/proxy" -name "." -value @{ enabled="true" } -FORCETeamCity アーティファクトに外部ストレージを使用している場合は、
reverseRewriteHostInResponseHeadersパラメーターを無効にします。Set-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST" -filter "system.webServer/proxy" -name "." -value @{ reverseRewriteHostInResponseHeaders="false" } -FORCEIIS web.config ファイルを次のように変更します。
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.web> <httpRuntime requestPathInvalidCharacters="" /> </system.web> <system.webServer> <rewrite> <rules useOriginalURLEncoding="true"> <rule name="teamcity" enabled="true" patternSyntax="Wildcard" stopProcessing="true"> <match url="*" /> <action type="Rewrite" url="http://localhost:80/{R:0}" /> <serverVariables> <set name="HTTP_FORWARDED" value="for={REMOTE_ADDR};by={LOCAL_ADDR};host="{HTTP_HOST}";proto="https"" /> </serverVariables> </rule> </rules> </rewrite> <security> <requestFiltering allowDoubleEscaping="true"> <fileExtensions> <remove fileExtension=".config" /> </fileExtensions> <hiddenSegments> <remove segment="bin" /> </hiddenSegments> </requestFiltering> </security> </system.webServer> </configuration>
その他のサーバー
リクエスト(アップロード)およびレスポンス(ダウンロード)のサイズとタイムアウト(コードベースとアーティファクトのサイズに応じて少なくとも数十分とギガバイト)に対して適切な(高い)制限を設定して、パフォーマンスの高いプロキシを必ず使用してください。
UI をすばやくリフレッシュするのに役立つため、WebSocket プロトコルで動作できるプロキシを使用することをお勧めします。
一般的に、クライアントが使用する元の URL を「認識」し、クライアントがアクセスできる正しい絶対 URL を生成できるように、TeamCity サーバーを構成する必要があります。これを実現するには、元の Host ヘッダーを TeamCity に渡すのが望ましい方法です。別の方法としては、X-Forwarded-Host ヘッダーを元の Host ヘッダーの値に設定する方法があります。
Host ヘッダーの値がプロキシによって変更され(元の Host ヘッダー値を保持することをお勧めします)、元の Host 値を持つ X-Forwarded-Host ヘッダーが提供されない場合は常に、Origin ヘッダーと Referer ヘッダーの値をマップする必要があることに注意してください。対応して、元の Host ヘッダー値が含まれている場合(含まれていない場合は、TeamCity CSRF の保護を回避しないように設定しないでください)。
以下のセクションから適切な方法を選択し、それに応じてプロキシを設定してください。
一般的な設定ミス
リバースプロキシ(または同様のツール)が以下の要件に準拠していることを確認してください。
ドットで始まるパス(
.)を持つ URL がサポートされています(非表示のアーティファクトへのパスには.teamcityディレクトリが含まれています)。コロン (
:) を含む URL がサポートされています (多くの TeamCity リソースはコロンを使用します)。関連する IIS の設定。症状: アーティファクトがあっても、ビルドに「このビルドにはユーザー定義のアーティファクトはありません」テキストを含むアーティファクトがありません。最大リクエスト名、応答長、応答時間を制限する設定は、それほど制限的ではありません。詳細については、この記事を参照してください: IIS 関連の問題。
gzip コンテンツエンコーディングは完全にサポートされています。例: 特定の IIS 構成では、UI に「データを読み込んでいます ...」と表示され、500 HTTP 応答が返されることがあります (関連する問題(英語)を参照)。
IIS 関連の問題:
「PKIX パスの構築に失敗しました: sun.security.provider.certpath.SunCertPathBuilderException: 要求されたターゲットへの有効な証明書パスが見つかりません」というエラーが発生した場合は、TeamCity が使用しているのと同じ Java キーストアに証明書を追加します。
HTTP 404 または 50x エラーで間違ったサーバー名が返された場合は、リダイレクトルールと転送されたヘッダーを確認してください。
TeamCity Tomcat の設定
TeamCity Tomcat 構成の場合、サーバー構成で専用の「コネクター」ノードを使用し、パブリック URL の詳細をハードコードし、コネクターで構成されたポートが、構成されたパブリック URL への要求によってのみ使用されるようにします。
設定されたポートが設定されたパブリック URL にのみ要求を受信している場合、このアプローチは任意のプロキシ設定で使用できます。
<TeamCity Home> /conf/server.xml ファイル内の「コネクター」ノードを以下のように変更する必要があります。
パブリックサーバーアドレスが HTTPS の場合は、secure="true" 属性と scheme="https" 属性を使用します。これらの属性が欠落している場合、TeamCity はそれぞれのヘルスレポートを表示します。
TeamCity サーバーが IIS リバースプロキシの背後に構成されている場合:
発信 TeamCity サーバー接続にプロキシを使用する
This section describes configuring TeamCity to use a proxy server for outgoing HTTP connections.
TeamCity サーバーは、問題トラッカーなどの他のサービスへの特定の発信 HTTP 接続にプロキシサーバーを使用できます。
TeamCity をプロキシサーバーにポイントするには、次の内部プロパティを設定します。
送信ビルドエージェント接続にプロキシを使用する
通常、ビルドエージェントは、TeamCity サーバー、S3 アーティファクトストレージ、VCS ホストなどへのさまざまなアウトバウンド接続を確立する必要があります。このセクションでは、ビルドエージェントがプロキシの背後にデプロイされた後も送信接続が機能し続けるように、ビルドエージェントを構成する方法について説明します。
TeamCity エージェント側で、 buildAgent.properties ファイルの次のプロパティを使用して TeamCity サーバーに接続するプロキシを指定します。
HTTPS エンドポイント (GitHub でホストされるリポジトリなど) にアクセスするには、teamcity.https.* プロパティも構成します。
マルチノードセットアップ用のプロキシサーバー
TeamCity サーバーは、高可用性と柔軟な負荷分散のために複数のノード (またはサーバー) を使用するように構成できます。NGINX および HAProxy 構成の例については、この記事 ( 高可用性のためのマルチノードセットアップ ) を参照してください。
関連ページ:
TeamCity サーバーへの HTTPS アクセスの構成
HTTPS プロトコルは、コンピューターネットワーク上でサーバーとクライアントの安全な通信を行うために暗号化を使用します。TeamCity サーバーがパブリックインターネットアドレスで利用できる場合は、セキュリティを大幅に強化するために HTTPS 接続を構成することを強くお勧めします。安全な HTTPS アクセスを構成するには、証明書が必要です。手動で取得してロードすることも、TeamCity に暗号化しましょう経由で有効な証明書を自動的に発行させることもできます。Let's Encrypt...
サーバーのインストールを構成する
サーバーポートの変更:別のアプリケーションが TeamCity サーバーと同じポートを使用している場合、サーバーは起動できません。その結果、サーバーログまたはサーバーコンソールに「すでに使用されている住所」エラーが表示されます。からサーバーをインストールする場合は、インストールウィザードでポートをカスタマイズできます。インストール / 解凍されたサーバーのポートを変更するには、ファイルを開き、コメントされていない XML ノードに別の番号を設定します。<Connector port=...
Amazon EC2 用の TeamCity のセットアップ
TeamCity Amazon EC2 統合により、TeamCity は、現在のビルドキューのワークロードに応じて、クラウドでホストされているエージェントをオンデマンドで自動的に開始および停止することで、ビルドリソースを自動スケールできます。共通情報:TeamCity では、さまざまなタイプの EC2 統合をセットアップできます。使用する設定とソースに応じて、クラウド AWS ホスト型エージェントは以下で実行できます。同じ Amazon マシンイメージ (AMI) から複製された複数の同一のイ...
接続を構成
TeamCity 接続は、外部サービスへのアクセスに必要な資格情報を保存します。このサードパーティサービスの種類に基づいて、2 つの主要な接続カテゴリがあります。VCS 接続これらの接続は、GitHub、GitLab、Bitbucket クラウドなどの VCS プロバイダーへのアクセスに必要な情報を保存します。これらの接続は、プロジェクト、ビルド構成、パイプラインを最も速く作成する方法を提供します。認証は自動的に処理されるため、リポジトリを選択するだけでビルドステップの設定を開始できます。接続が...
Git
TeamCity は、Git をすぐにサポートします。Azure DevOps Services を使用した Git ソース管理がサポートされています (以下の認証に関する注意事項を参照)。このページには、VCS ルート設定の Git 固有のフィールドの説明が含まれています。一般的な VCS ルートプロパティについては、このセクションを参照してください。注意事項: リモート実行とテスト済みのコミットは IntelliJ IDEA プラグインでサポートされています。Visual Studio アドインで...
アーティファクトストレージの構成
プロジェクト設定 | アーティファクトストレージタブには、このプロジェクトで構成されたアーティファクトストレージと、親から継承されたストレージが表示されます。デフォルトでは、組み込み TeamCity アーティファクトストレージが表示され、アクティブとしてマークされています。対応するリンクを使用して別のストレージを有効化することができます。組み込みアーティファクトストレージ:TeamCity は、ビルドによって生成されたアーティファクトを、TeamCity サーバーがアクセスできるファイルシステ...