【マルチノード】GitLab用のロードバランサー

マルチノード構成のGitLabでは、ロードバランサーを使用して、トラフィックをアプリケーションサーバーにルーティングする必要があります。どのロードバランサーを使用するか、またはその正確な設定に関する詳細は、GitLabドキュメントのスコープ外です。GitLabのようなHAシステムを管理している場合は、すでに使用するロードバランサーを選択していることを期待します。HAProxy（オープンソース）、F5 Big-IP LTM、Citrix NetScalerなどの例があります。このドキュメントでは、GitLabで使用するポートとプロトコルについて説明します。

SSL

マルチノード環境でSSLをどのように処理しますか？次のようないくつかの選択肢があります:

• 各アプリケーションノードがSSLを終端します。
• ロードバランサーはSSLを終端し、ロードバランサーとアプリケーションノード間の通信は安全ではありません
• ロードバランサーはSSLを終端し、ロードバランサーとアプリケーションノード間の通信は安全です

アプリケーションノードはSSLを終端します

ロードバランサーがポート443の接続を「HTTP(S)」プロトコルではなく「TCP」として渡すように設定します。これにより、接続はアプリケーションノードのNGINXサービスにそのまま渡されます。NGINXにはSSL証明書があり、ポート443をリッスンします。

SSL証明書の管理とNGINXの設定の詳細については、HTTPSのドキュメントを参照してください。

ロードバランサーはバックエンドSSLなしでSSLを終端します

TCPではなく、HTTP(S)プロトコルを使用するようにロードバランサーを設定します。ロードバランサーは、SSL証明書の管理とSSLの終端処理を担当します。

ロードバランサーとGitLab間の通信が安全ではなくなるため、追加の設定が必要となります。詳細については、プロキシSSLのドキュメントを参照してください。

ロードバランサーはバックエンドSSLありでSSLを終端します

TCPではなく、HTTP(S)プロトコルを使用するようにロードバランサーを設定します。ロードバランサーは、エンドユーザーに表示されるSSL証明書の管理を担当します。

このシナリオでは、ロードバランサーとNGINX間のトラフィックも安全になります。接続は常に安全であるため、プロキシーSSLの設定を追加する必要はありません。ただし、SSL証明書を設定するには、GitLabに設定を追加する必要があります。SSL証明書の管理とNGINXの設定の詳細については、HTTPSのドキュメントを参照してください。

ポート

基本ポート

• （1）: Web端末のサポートでは、ロードバランサーがWebSocket接続を正しく処理する必要があります。HTTPまたはHTTPSプロキシを使用する場合、これは、ConnectionおよびUpgradeのホップバイホップヘッダーを通過するようにロードバランサーを設定する必要があることを意味します。詳細については、Web端末インテグレーションガイドを参照してください。
• （2）: ポート443にHTTPSプロトコルを使用する場合は、ロードバランサーにSSL証明書を追加する必要があります。代わりにGitLabアプリケーションサーバーでSSLを終了する場合は、TCPプロトコルを使用します。

GitLab Pagesのポート

カスタムドメインサポートでGitLab Pagesを使用している場合は、いくつかの追加ポート設定が必要になります。GitLabページには、個別の仮想IPアドレスが必要です。新しい仮想IPアドレスで、/etc/gitlab/gitlab.rbからpages_external_urlを指すようにDNSを設定します。詳細については、GitLab Pagesのドキュメントを参照してください。

• （1）: GitLab Pagesのバックエンドポートは、gitlab_pages['external_http']およびgitlab_pages['external_https']の設定によって異なります。詳細については、GitLab Pagesのドキュメントを参照してください。
• （2）: GitLab Pagesのポート443では、常にTCPプロトコルを使用する必要があります。ユーザーはカスタムSSLでカスタムドメインを設定できますが、SSLがロードバランサーで終了した場合、この設定は不可能です。

代替SSHポート

一部の組織には、SSHポート22を開くことについてポリシーがあります。この場合、ユーザーがポート443でSSHを使用できるようにする代替SSHホスト名を設定すると役立つ場合があります。前述の他のGitLab HTTP設定と比較した場合、代替SSHホスト名には、新しい仮想IPアドレスが必要になります。

altssh.gitlab.example.comなどの代替SSHホスト名のDNSを設定します。

準備完了チェック

マルチノードデプロイでは、ロードバランサーがヘルスチェックを使用して、トラフィックをルーティングする前に、ノードがトラフィックを受け入れる準備ができていることを確認することを強くお勧めします。これは、Pumaを使用している場合に特に重要です。Pumaは再起動中にリクエストを受け入れない期間があるためです。

トラブルシューティング

ヘルスチェックがロードバランサー経由で408 HTTP code>コードを返しています

GitLab 15.0以降にAWS Classic Load Balancerを使用している場合は、NGINXでAES256-GCM-SHA384暗号化を有効にする必要があります。詳細については、NGINXでAES256-GCM-SHA384 SSL暗号がデフォルトで許可されなくなったを参照してください。

GitLabバージョンのデフォルトの暗号は、files/gitlab-cookbooks/gitlab/attributes/default.rbファイルで確認でき、ターゲットGitLabバージョン（例：15.0.5+ee.0）に対応するGitタグ付けを選択します。ロードバランサーで必要な場合は、NGINXのカスタムSSL暗号を定義できます。

一部のページとリンクがブラウザでレンダリングされずにダウンロードされる

一部のGitLab機能では、WebSocketsの使用が必要です。ロードバランサーでWebSocketsサポートが有効になっていないシナリオでは、一部のリンクまたはページがブラウザでレンダリングされずにダウンロードされることがあります。ダウンロードされたファイルには、次のようなコンテンツが含まれている場合があります:

One or more reserved bits are on: reserved1 = 1, reserved2 = 0, reserved3 = 0

ロードバランサーは、HTTP WebSocketリクエストをサポートできる必要があります。リンクがこのようにダウンロードされる場合は、ロードバランサーの設定をチェックインし、HTTP WebSocketリクエストが有効になっていることを確認してください。