複数ノード 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のドキュメントを参照してください。

ポート

基本ポート

LBポートバックエンドポートプロトコル
8080HTTP(1)
443443TCPまたはHTTPS(1)(2)
2222TCP
  • (1):TCP (1):ウェブ端末のサポートには、ロードバランサがウェブソケット接続を正しく扱える必要があります。HTTP や HTTPS プロキシを使う場合、ロードバランサがConnection とUpgrade ホップバイホップヘッダを通過するように設定されている必要があります。詳しくはウェブ端末インテグレーションガイドを参照してください。
  • (2):ポート443にHTTPSプロトコルを使う場合、ロードバランサーにSSL証明書を追加する必要があります。代わりにGitLabアプリケーションサーバーでSSLを終了したい場合は、TCPプロトコルを使用してください。

GitLab Pages Ports

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

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

代替SSHポート

組織によっては、SSHポート22を開けないというポリシーを持っている場合があります。この場合、代替SSHホスト名を設定して、ユーザーが443番ポートでSSHを使えるようにすると便利です。代替SSHホスト名では、上記のGitLab HTTPの設定と比較して新しい仮想IPアドレスが必要になります。

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

LBポートバックエンドポートプロトコル
44322TCP

準備チェック

複数ノードのデプロイでは、ノードにトラフィックをルーティングする前に、ノードがトラフィックを受け入れる準備ができていることを確認するために準備チェックを使用するようにロードバランサを設定することを強くお勧めします。これはPumaを利用する場合に特にインポートが重要になります。

caution
GitLabのバージョン15.4から15.8で、all=1 パラメータを準備チェックと一緒に使用すると、Praefectのメモリ使用量が増加し、メモリエラーになる可能性があります。

トラブルシューティング

健全性チェックがロードバランサー経由で408 HTTP コードを返します

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バージョンに関連するGitタグを選択します（例：15.0.5+ee.0）。ロードバランサーで必要な場合は、NGINXにカスタムSSL暗号を定義することができます。