複数ノード GitLab 用ロードバランサ
GitLabの複数ノード構成では、アプリケーションサーバへのトラフィックをルーティングするためにロードバランサが必要になります。 どのロードバランサを使うか、あるいは正確な構成についての詳細は、GitLabのドキュメントの範囲を超えています。 GitLabのようなHAシステムを管理しているのであれば、すでにロードバランサを選択していることを望みます。 HAProxy（オープンソース）、F5 Big-IP LTM、Citrix Net Scalerなどがその例です。 このドキュメントでは、GitLabで使うために必要なポートとプロトコルの概要を説明します。
SSL
マルチノード環境でSSLをどのように扱いますか？ いくつかの異なるオプションがあります：
- 各アプリケーションノードはSSLを終了します。
- ロードバランサーがSSLを終了しており、ロードバランサーとアプリケーションノード間の通信がセキュリティで保護されていない場合。
- ロードバランサーはSSLを終了し、ロードバランサーとアプリケーションノード間の通信はセキュアです。
アプリケーションノードがSSLを終了
ポート443上の接続を「HTTP(S)」プロトコルではなく「TCP」として渡すようにロードバランサーを設定します。 これにより、アプリケーションノードNGINXサービスへの接続はそのまま渡されます。 NGINXはSSL証明書を持ち、ポート443をリッスンします。
SSL証明書の管理およびNGINXの設定の詳細については、NGINX HTTPSドキュメントを参照してください。
ロードバランサーはバックエンドSSLなしでSSLを終了します。
ロードバランサーは「TCP」ではなく「HTTP(S)」プロトコルを使うように設定します。ロードバランサーはSSL証明書の管理とSSLの終了を担当します。
ロードバランサーとGitLabの間の通信はセキュアではないので、追加の設定が必要です。 詳細はNginxProxied SSL documentationをご覧ください。
ロードバランサーはバックエンドSSLでSSLを終了します。
ロードバランサーは「TCP」ではなく「HTTP(S)」プロトコルを使うように設定してください。 ロードバランサーはエンドユーザーが見るSSL証明書を管理する責任があります。
このシナリオでは、ロードバランサーとNGINXの間のトラフィックもセキュアになります。 接続はすべてセキュアになるため、プロキシSSLの設定を追加する必要はありません。 ただし、SSL証明書を設定するためにGitLabに設定を追加する必要があります。 SSL証明書の管理とNGINXの設定の詳細については、NGINX HTTPSのドキュメントを参照してください。
港湾
基本ポート
| LBポート | バックエンドポート | プロトコル |
|---|---|---|
| 80 | 80 | HTTP(1) |
| 443 | 443 | TCP または HTTPS(1)(2) |
| 22 | 22 | 伝送制御プロトコル |
-
(1):Web端末のサポートには、ロードバランサがWebSocket接続を正しく処理する必要があります。 HTTPまたはHTTPSプロキシを使用する場合、ロードバランサが
Connection、Upgradeホップバイホップヘッダを通過するように設定する必要があります。 詳細はWeb端末インテグレーションガイドを参照してください。 - (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を開けないようにしているところもあります。 このような場合は、ポート443でSSHを使えるように代替のSSHホスト名を設定するとよいでしょう。 代替のSSHホスト名を設定する場合は、上記のGitLab HTTPの設定と比べて新しい仮想IPアドレスが必要になります。
altssh.gitlab.example.comのような代替SSHホスト名用にDNSを設定します。
| LBポート | バックエンドポート | プロトコル |
|---|---|---|
| 443 | 22 | 伝送制御プロトコル |
準備チェック
複数ノードのデプロイでは、ノードにトラフィックをルーティングする前に、ノードがトラフィックを受け入れる準備ができていることを確認するために、準備チェックを利用するようにロードバランサを構成することを強くお勧めします。 Pumaを利用する場合は、Pumaがリクエストを受け付けない再起動中の短い期間があるため、これは特に重要です。
高可用性構成の詳細を読む
