リファレンスアーキテクチャ：最大50,000ユーザー

このページでは、50,000ユーザーまでのGitLabリファレンスアーキテクチャについて説明します。リファレンスアーキテクチャの全リストは、利用可能なリファレンスアーキテクチャをご覧ください。

  • サポートされるユーザー（概算）：50,000
  • 高可用性：はい（HAにはサードパーティのPostgreSQLソリューションが必要です。）
  • 推定コスト コスト表を参照
  • クラウドネイティブハイブリッドの代替 はい
  • 検証およびテスト結果：品質エンジニアリングチームは、定期的にスモークテストとパフォーマンステストを実施し、リファレンスアーキテクチャが準拠していることを確認します。
    • テストリクエスト/秒(RPS) 率：API: 1000 RPS、Web：100RPS、Git（Pull）：100 RPS、Git（プッシュ）：20 RPS
    • 最新の結果
  • どのリファレンス・アーキテクチャを使用するか迷っていますか？詳しくはこちらのガイドをご覧ください。
サービスノード設定GCPAWS
外部負荷分散ノード3 18 vCPU、7.2 GBメモリn1-highcpu-8c5.2xlarge
領事1 32 vCPU、1.8 GBメモリn1-highcpu-2c5.large
PostgreSQL1 332vCPU、120GBメモリn1-standard-32m5.8xlarge
PgBouncer1 32 vCPU、1.8 GBメモリn1-highcpu-2c5.large
内部ロードバランシングノード3 18 vCPU、7.2 GBメモリn1-highcpu-8c5.2xlarge
Redis/Sentinel - キャッシュ2 34 vCPU、15 GB メモリn1-standard-4m5.xlarge
Redis/Sentinel - 永続的2 34 vCPU、15 GB メモリn1-standard-4m5.xlarge
Gitaly5 6 364vCPU、240GBメモリn1-standard-64m5.16xlarge
Praefect5 34 vCPU、3.6 GBメモリn1-highcpu-4c5.xlarge
Praefect PostgreSQL1 1+2 vCPU、1.8 GBメモリn1-highcpu-2c5.large
Sidekiq7 44 vCPU、15 GB メモリn1-standard-4m5.xlarge
GitLab Rails7 1232vCPU、28.8GBメモリn1-highcpu-32c5.9xlarge
監視ノード14 vCPU、3.6 GBメモリn1-highcpu-4c5.xlarge
オブジェクトストレージ4 ----
  1. オプションで、評判の良いサードパーティの外部PaaS PostgreSQLソリューションで実行することができます。詳細はPostgreSQL インスタンスの提供を参照してください。
  2. オプションで、評判の良いサードパーティの外部PaaS Redisソリューションで実行できます。詳細については、Redisインスタンスの提供を参照してください。
    • Redisは主にシングルスレッドです。このスケールで最適なパフォーマンスを得るには、インスタンスをキャッシュと永続データに分けることを強くお勧めします。
  3. オプションとして、評判の高いサードパーティのロードバランシングサービス（LB PaaS）で実行できます。詳細については、推奨クラウドプロバイダーとサービスを参照してください。
  4. 信頼できるクラウドプロバイダーまたはセルフマネージドソリューションで実行する必要があります。詳細については、オブジェクトストレージの設定を参照してください。
  5. Gitaly Clusterはフォールトトレランスの利点を提供しますが、セットアップと管理の複雑さを伴います。Gitaly Clusterをデプロイする前に、既存の技術的な制限と考慮事項をレビューしてください。Gitalyをシャーディングしたい場合は、上記のGitalyと同じ仕様を使用してください。
  6. Gitalyは、ベスト・プラクティスに従った様々な規模のリポジトリで設計され、テストされています。しかし、これらのプラクティスに従わない大規模なリポジトリやモノレポは、Gitalyの要件に大きな影響を与える可能性があります。詳細については、大規模なリポジトリを参照してください。
  7. このコンポーネントはステートフルなデータを保存しないので、Auto Scaling Groups (ASG) に配置することができます。しかし、GitLab Railsではマイグレーションや Mailroomのような特定のプロセスは1つのノードだけで実行する必要があります。
note
インスタンスの設定を伴うすべてのPaaSソリューションでは、レジリエントなクラウド・アーキテクチャのプラクティスに合わせるため、3つの異なるアベイラビリティ・ゾーンに最低3つのノードを実装することを強く推奨します。

要件

開始する前に、リファレンスアーキテクチャの要件を参照してください。

コンポーネントのセットアップ

GitLabとそのコンポーネントを最大50,000ユーザーに対応するようにセットアップします：

  1. GitLab アプリケーションサービスノードのロードバランシングを処理するために、外部ロードバランサーを設定します。
  2. 内部ロードバランサーを設定します。
  3. Consulを設定します。
  4. GitLabのデータベースであるPostgreSQLを設定します。
  5. PgBouncer を設定します。
  6. Redis を設定します。
  7. Gitaly Clusterを設定し、Gitリポジトリへのアクセスを提供します。
  8. Sidekiqを設定します。
  9. メインのGitLab Railsアプリケーションを設定し、Puma、Workhorse、GitLab Shellを実行し、すべてのフロントエンドリクエスト（UI、API、Git over HTTP/SSHを含む）を処理するようにします。
  10. GitLab環境を監視するためにPrometheusを設定します。
  11. 共有データオブジェクトに使用するオブジェクトストレージを設定します。
  12. GitLabインスタンス全体で、より高速で高度なコード検索を行うための高度な検索を設定します（オプション）。

サーバーは同じ10.6.0.0/24の非公開ネットワーク範囲で起動し、これらのアドレスで自由に接続することができます。

以下のリストには、各サーバーと割り当てられたIPの説明が含まれています：

  • 10.6.0.10:外部ロードバランサ
  • 10.6.0.11:領事1
  • 10.6.0.12:領事2
  • 10.6.0.13:領事3
  • 10.6.0.21:PostgreSQL プライマリ
  • 10.6.0.22:PostgreSQL セカンダリ 1
  • 10.6.0.23:PostgreSQL セカンダリ 2
  • 10.6.0.31:PgBouncer 1
  • 10.6.0.32:用心棒2
  • 10.6.0.33:用心棒3
  • 10.6.0.40:内部ロードバランサー
  • 10.6.0.51:Redis - キャッシュプライマリ
  • 10.6.0.52:Redis - キャッシュレプリカ1
  • 10.6.0.53:Redis - キャッシュレプリカ2
  • 10.6.0.61:Redis - 持続的プライマリ
  • 10.6.0.62:Redis - 持続的レプリカ1
  • 10.6.0.63:Redis - 永続レプリカ2
  • 10.6.0.91:Gitaly 1
  • 10.6.0.92:ジタリー2
  • 10.6.0.93:ジタリー3
  • 10.6.0.131:Praefect 1
  • 10.6.0.132:プラフェクト2
  • 10.6.0.133:Praefect 3
  • 10.6.0.141:Praefect PostgreSQL 1 (HA非対応)
  • 10.6.0.101: Sidekiq 1
  • 10.6.0.102: Sidekiq 2
  • 10.6.0.103: Sidekiq 3
  • 10.6.0.104: Sidekiq 4
  • 10.6.0.111:GitLab アプリケーション 1
  • 10.6.0.112:GitLabアプリケーション2
  • 10.6.0.113:GitLabアプリケーション3
  • 10.6.0.114:GitLabアプリケーション4
  • 10.6.0.115:GitLabアプリケーション5
  • 10.6.0.116:GitLabアプリケーション6
  • 10.6.0.117:GitLabアプリケーション 7
  • 10.6.0.118:GitLabアプリケーション 8
  • 10.6.0.119:GitLabアプリケーション 9
  • 10.6.0.120:GitLabアプリケーション 10
  • 10.6.0.121:GitLabアプリケーション11
  • 10.6.0.122:GitLabアプリケーション 12
  • 10.6.0.151: Prometheus

外部ロードバランサーの設定

複数ノードのGitLab設定では、アプリケーションサーバーへのトラフィックをルーティングするためにロードバランサーが必要になります。どのロードバランサを使うか、あるいはその正確な設定については、GitLabのドキュメントの範囲を超えています。GitLabのような複数ノードのシステムを管理しているのであれば、すでにロードバランサーを選択していると想定されます。ロードバランサーの例としては、HAProxy（オープンソース）、F5 Big-IP LTM、Citrix Net Scalerなどがあります。このドキュメントでは、GitLabで使用するために必要なポートとプロトコルの概要を説明します。

このアーキテクチャはHAProxyをロードバランサーとしてテスト・検証されています。同様の機能を持つ他のロードバランサーを使うこともできますが、それらのロードバランサーは検証されていません。

バランシングアルゴリズム

ノードへのコールの均等な分散と良好なパフォーマンスを確保するために、可能な限り最小接続負荷分散アルゴリズムまたは同等のものを使用する必要があります。

ラウンドロビンアルゴリズムの使用は、実際には接続が均等に広がらないことが知られているため、お勧めしません。

準備チェック

外部のロードバランサが、監視用のエンドポイントが組み込まれているサービスだけにルーティングするようにしてください。準備のチェックでは、チェックするノードに追加の設定が必要です。

ポート

基本的に使用するポートを下表に示します。

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

カスタムドメインをサポートする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

SSL

次の問題は、あなたの環境でSSLをどのように扱うかです。いくつかの選択肢があります：

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

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

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

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

HTTP(S) TCPロードバランサーがSSL証明書を管理し、SSLを終了する責任を負います。

ロードバランサーと GitLab の間の通信はセキュリティで保護されないので、追加の設定が必要です。詳しくはプロキシSSLのドキュメントをご覧ください。

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

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

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

内部ロードバランサーの設定

内部ロードバランサーは、PgBouncerや Praefect（Gitalyクラスタ）への接続など、GitLab環境が必要とする内部接続のバランスを取るために使用します。

外部ロードバランサーとは別のノードで、外部からのアクセスはできません。

例として以下のIPを使用します：

  • 10.6.0.40:内部ロードバランサー

HAProxyを使った方法を紹介します：

global
    log /dev/log local0
    log localhost local1 notice
    log stdout format raw local0

defaults
    log global
    default-server inter 10s fall 3 rise 2
    balance leastconn

frontend internal-pgbouncer-tcp-in
    bind *:6432
    mode tcp
    option tcplog

    default_backend pgbouncer

frontend internal-praefect-tcp-in
    bind *:2305
    mode tcp
    option tcplog
    option clitcpka

    default_backend praefect

backend pgbouncer
    mode tcp
    option tcp-check

    server pgbouncer1 10.6.0.31:6432 check
    server pgbouncer2 10.6.0.32:6432 check
    server pgbouncer3 10.6.0.33:6432 check

backend praefect
    mode tcp
    option tcp-check
    option srvtcpka

    server praefect1 10.6.0.131:2305 check
    server praefect2 10.6.0.132:2305 check
    server praefect3 10.6.0.133:2305 check

ロードバランサのドキュメントを参照してください。

バランシングアルゴリズム

ノードへのコールの均等な分散と良好なパフォーマンスを確保するため、可能な限り最小接続負荷分散アルゴリズムまたは同等のアルゴリズムを使用することをお勧めします。

ラウンドロビンアルゴリズムの使用は、実際には接続が均等に広がらないことが知られているため、お勧めしません。

Consulの設定

次に、Consulサーバーを設定します。

note
Consulは3ノード以上の奇数でデプロイする必要があります。これはノードが定足数の一部として投票できるようにするためです。

例として以下のIPを使用します：

  • 10.6.0.11:領事1
  • 10.6.0.12:領事2
  • 10.6.0.13:領事3

コンシュルの設定

  1. ConsulをホストするサーバーにSSH接続します。
  2. お好みのLinuxパッケージをダウンロードしてインストールしてください。ページのインストールステップ1と_2のみに従い_、現在のインストールと同じバージョンとタイプ（CommunityまたはEnterpriseエディション）の正しいLinuxパッケージを選択してください。

  3. /etc/gitlab/gitlab.rb を編集し、内部を追加します：

    roles(['consul_role'])
   
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   server: true,
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

  4. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  5. 変更を有効にするには、GitLabを再設定してください。

  6. 他のすべての Consul ノードについてもう一度手順を確認し、正しい IP を設定したことを確認してください。

3台目のConsulサーバーのプロビジョニングが完了すると、Consulリーダーが_選出さ_れます。Consul ログの表示sudo gitlab-ctl tail consul は...[INFO] consul: New leader elected: ...を表示します。

現在のConsulメンバー（サーバー、クライアント）を一覧できます：

sudo /opt/gitlab/embedded/bin/consul members

GitLabサービスが稼働していることを確認できます：

sudo gitlab-ctl status

出力は以下のようになるはずです：

run: consul: (pid 30074) 76834s; run: log: (pid 29740) 76844s
run: logrotate: (pid 30925) 3041s; run: log: (pid 29649) 76861s
run: node-exporter: (pid 30093) 76833s; run: log: (pid 29663) 76855s

PostgreSQLの設定

このセクションでは、GitLabで使用する可用性の高いPostgreSQLクラスターの設定について説明します。

独自の PostgreSQL インスタンスを用意します。

オプションで、PostgreSQL用のサードパーティの外部サービスを使用することができます。

これには評判の良いプロバイダやソリューションを使うべきです。Google Cloud SQLと Amazon RDSが動作することが知られています。しかし、Amazon Auroraは14.4.0からデフォルトで有効になったロードバランシングと互換性がありません。詳細は推奨クラウドプロバイダーとサービスを参照してください。

サードパーティの外部サービスを使用する場合

  1. HA LinuxパッケージのPostgreSQLセットアップには、PostgreSQL、PgBouncer、Consulが含まれています。サードパーティの外部サービスを利用する場合、これらのコンポーネントは不要になります。
  2. データベース要件文書に従って PostgreSQL をセットアップします。
  3. gitlab ユーザー名とパスワードを gitlab設定してください。gitlab この gitlabユーザーにはgitlabhq_production データベースを作成する権限が必要です。
  4. GitLabアプリケーションサーバーを適切に設定します。このステップはGitLab Railsアプリケーションの設定で説明します。
  5. HAを実現するために必要なノードの数は、Linuxパッケージと比較してサービスによって異なる可能性があり、それに応じて一致させる必要はありません。
  6. ただし、パフォーマンスをさらに向上させるためにリードレプリカによるデータベース負荷分散が必要な場合は、リファレンスアーキテクチャのノード数に従うことをお勧めします。

Linuxパッケージを使用したスタンドアロンPostgreSQL

レプリケーションとフェイルオーバーを使用したPostgreSQLクラスタに推奨されるLinuxパッケージの設定には以下が必要です：

  • 最低3つのPostgreSQLノード。
  • 最低3台のConsulサーバーノード
  • プライマリデータベースの読み取りと書き込みを追跡し、処理する最低3台のPgBouncerノード。

  • データベースのロードバランシングが有効です。

    各PostgreSQLノードで設定するローカルPgBouncerサービス。これはプライマリを追跡するメインのPgBouncerクラスターとは別であることに注意してください。

例として以下のIPを使用します：

  • 10.6.0.21:PostgreSQL プライマリ
  • 10.6.0.22:PostgreSQL セカンダリ 1
  • 10.6.0.23:PostgreSQL セカンダリ 2

まず、各ノードにLinux GitLabパッケージをインストールしてください。手順に従って、ステップ1から必要な依存関係をインストールし、ステップ2からGitLabパッケージのリポジトリを追加します。ステップ2でGitLabをインストールする際は、EXTERNAL_URL 。

PostgreSQLノード

  1. PostgreSQLノードの1つにSSH接続します。

  2. PostgreSQLのユーザ名とパスワードのペアのパスワードハッシュを生成します。デフォルトのユーザ名gitlab （推奨）を使用することを想定しています。コマンドはパスワードと確認を要求します。次のステップでは、このコマンドで出力された値を<postgresql_password_hash> の値として使用してください：

    sudo gitlab-ctl pg-password-md5 gitlab

  3. PgBouncerのユーザー名/パスワードペアのパスワードハッシュを生成します。これは、デフォルトのユーザー名pgbouncer （推奨）を使用することを想定しています。コマンドはパスワードと確認を要求します。次のステップでこのコマンドによって出力される値を<pgbouncer_password_hash> の値として使用します：

    sudo gitlab-ctl pg-password-md5 pgbouncer

  4. PostgreSQLレプリケーションのユーザ名/パスワードペアのパスワードハッシュを生成します。デフォルトのユーザ名gitlab_replicator （推奨）を使用することを想定しています。コマンドはパスワードと確認を要求します。次のステップでこのコマンドが出力する値を<postgresql_replication_password_hash> の値として使用してください：

    sudo gitlab-ctl pg-password-md5 gitlab_replicator

  5. Consulデータベースのユーザー名とパスワードのペアのパスワードハッシュを生成します。これは、デフォルトのユーザー名gitlab-consul を使用することを想定しています（推奨）。コマンドはパスワードと確認を要求します。次のステップでは、このコマンドで出力された値を<consul_password_hash> の値として使用します：

    sudo gitlab-ctl pg-password-md5 gitlab-consul

  6. すべてのデータベース・ノードで、# START user configuration のセクションで説明した値を置き換えて、/etc/gitlab/gitlab.rb を編集します：

    # Disable all components except Patroni, PgBouncer and Consul
roles(['patroni_role', 'pgbouncer_role'])
   
# PostgreSQL configuration
postgresql['listen_address'] = '0.0.0.0'
   
# Sets `max_replication_slots` to double the number of database nodes.
# Patroni uses one extra slot per node when initiating the replication.
patroni['postgresql']['max_replication_slots'] = 6
   
# Set `max_wal_senders` to one more than the number of replication slots in the cluster.
# This is used to prevent replication from using up all of the
# available database connections.
patroni['postgresql']['max_wal_senders'] = 7
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
   
# Configure the Consul agent
consul['enable'] = true
consul['services'] = %w(postgresql)
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
# START user configuration
# Please set the real values as explained in Required Information section
#
# Replace PGBOUNCER_PASSWORD_HASH with a generated md5 value
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# Replace POSTGRESQL_REPLICATION_PASSWORD_HASH with a generated md5 value
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# Replace POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = '<postgresql_password_hash>'
   
# Set up basic authentication for the Patroni API (use the same username/password in all nodes).
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_password>'
   
# Replace 10.6.0.0/24 with Network Addresses for your other patroni nodes
patroni['allowlist'] = %w(10.6.0.0/24 127.0.0.1/32)
   
# Replace 10.6.0.0/24 with Network Address
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
# Local PgBouncer service for Database Load Balancing
pgbouncer['databases'] = {
   gitlabhq_production: {
      host: "127.0.0.1",
      user: "pgbouncer",
      password: '<pgbouncer_password_hash>'
   }
}
   
# Set the network addresses that the exporters will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

Patroniがフェイルオーバーを管理するPostgreSQLでは、デフォルトでpg_rewind 。Patroniがフェイルオーバーを管理するPostgreSQLでは、デフォルトで。詳細はPatroniのレプリケーション方法を参照してください。

  1. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  2. 変更を有効にするには、GitLabを再設定してください。

高度な設定オプションもサポートされており、必要に応じて追加することができます。

PostgreSQLの後設定

プライマリサイトのPatroniノードにSSHでログインします：

  1. リーダーとクラスターの状態を確認します：

    gitlab-ctl patroni members

    出力は以下のようになるはずです：

    | Cluster       | Member                            |  Host     | Role   | State   | TL  | Lag in MB | Pending restart |
|---------------|-----------------------------------|-----------|--------|---------|-----|-----------|-----------------|
| postgresql-ha | <PostgreSQL primary hostname>     | 10.6.0.21 | Leader | running | 175 |           | *               |
| postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.22 |        | running | 175 | 0         | *               |
| postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.23 |        | running | 175 | 0         | *               |

ノードの’State’列が “running “でない場合は、先に進む前にPostgreSQLのレプリケーションとフェイルオーバーのトラブルシューティングを確認してください。

PgBouncerの設定

PostgreSQLサーバの設定が全て終わったので、プライマリデータベースへの読み込み/書き込みを追跡し処理するためにPgBouncerを設定します。

例として以下のIPを使用します：

  • 10.6.0.31:PgBouncer 1
  • 10.6.0.32:用心棒2
  • 10.6.0.33:用心棒3

  1. 各PgBouncerノードで、/etc/gitlab/gitlab.rb を編集し、<consul_password_hash> と<pgbouncer_password_hash> を以前に設定したパスワードハッシュに置き換えます：

    # Disable all components except Pgbouncer and Consul agent
roles(['pgbouncer_role'])
   
# Configure PgBouncer
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
   'gitlab-consul': {
      password: '<consul_password_hash>'
   },
   'pgbouncer': {
      password: '<pgbouncer_password_hash>'
   }
}
   
# Configure Consul agent
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
# Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
   
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'

  2. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  3. 変更を有効にするには、GitLabを再設定してください。

    エラーexecute[generate databases.ini] が発生した場合、これは既知のイシューによるものです。次のステップの後に二度目のreconfigure を実行すると解決します。

  4. ConsulがPgBouncerをリロードできるように.pgpass 。PgBouncerのパスワードを聞かれたら2回入力します：

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
  5. GitLabを再設定して、前のステップで発生した潜在的なエラーを解決します。

  6. 各ノードが現在のプライマリノードと通信していることを確認します：

    gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD

  7. コンソールプロンプトが利用できるようになったら、以下のクエリを実行します：

    show databases ; show clients ;

    出力は以下のようになるはずです：

            name         |  host       | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
 gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production |            |        20 |            0 |           |               0 |                   0
 pgbouncer           |             | 6432 | pgbouncer           | pgbouncer  |         2 |            0 | statement |               0 |                   0
(2 rows)
   
 type |   user    |      database       |  state  |   addr         | port  | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link | remote_pid | tls
------+-----------+---------------------+---------+----------------+-------+------------+------------+---------------------+---------------------+-----------+------+------------+-----
 C    | pgbouncer | pgbouncer           | active  | 127.0.0.1      | 56846 | 127.0.0.1  |       6432 | 2017-08-21 18:09:59 | 2017-08-21 18:10:48 | 0x22b3880 |      |          0 |
(2 rows)

Redisの設定

スケーラブルな環境でRedis を使用するには、プライマリxレプリカのトポロジーを使用し、Redis Sentinelサービスを使用してフェイルオーバー手順を監視し、自動的に開始します。

note
Redisクラスターはそれぞれ3ノード以上の奇数でデプロイする必要があります。これは、Redis Sentinelがクォーラムの一部として投票できるようにするためです。クラウドプロバイダのサービスなど、Redisを外部で設定する場合はこの限りではありません。
note
Redisは主にシングルスレッドです。このスケールで最適なパフォーマンスを得るには、指定されたインスタンスをキャッシュと永続データに分離することを強くお勧めします。

RedisをSentinelと併用する場合は認証が必要です。詳細はRedisセキュリティのドキュメントを参照してください。Redisサービスのセキュリティを確保するために、Redisパスワードと厳格なファイアウォールルールを組み合わせて使用することをお勧めします。RedisをGitLabで設定する前にRedis Sentinelのドキュメントを読み、トポロジーとアーキテクチャを完全に理解することを強くお勧めします。

Redisのセットアップに必要な要件は以下のとおりです：

  1. すべてのRedisノードが互いに通信でき、Redisポート（6379 ）およびSentinelポート（26379）で着信接続を受け付ける必要があります（デフォルトのポートを変更しない限り）。
  2. GitLabアプリケーションをホストするサーバーはRedisノードにアクセスできなければなりません。
  3. ファイアウォールを使用して、外部ネットワーク（インターネット）からのアクセスからノードを保護します。

このセクションでは、GitLabで使用する2つの外部Redisクラスターの設定について説明します。例として以下のIPを使用します：

  • 10.6.0.51:Redis - キャッシュプライマリ
  • 10.6.0.52:Redis - キャッシュレプリカ1
  • 10.6.0.53:Redis - キャッシュレプリカ2
  • 10.6.0.61:Redis - 持続的プライマリ
  • 10.6.0.62:Redis - 持続的レプリカ1
  • 10.6.0.63:Redis - 永続レプリカ2

独自のRedisインスタンスを用意します。

要件を満たす限り、オプションでサードパーティの Redis 用外部サービスを使用できます。

この場合、評判の良いプロバイダーやソリューションを使用する必要があります。Google Memorystoreや AWS Elasticacheが有名です。ただし、Redisクラスターモードは特にGitLabではサポートされていないことに注意してください。詳しくは推奨クラウドプロバイダーとサービスをご覧ください。

Redis Cacheクラスターの設定

ここでは新しい Redis Cache インスタンスをインストールして設定します。

プライマリノードとレプリカRedisノードの両方に、redis['password'] で定義された同じパスワードが必要です。フェイルオーバー中はいつでも、Sentinelsはノードを再設定し、そのステータスをプライマリノードからレプリカに変更できます（その逆も同様）。

プライマリRedisキャッシュノードの設定

  1. プライマリRedisサーバにSSH接続します。
  2. お好みのLinuxパッケージをダウンロードしてインストールしてください。ページのインストールステップ1と_2のみに従い_、現在インストールされているものと同じバージョンとタイプ（CommunityエディションまたはEnterpriseエディション）の正しいLinuxパッケージを選択してください。

  3. /etc/gitlab/gitlab.rb を編集し、内部を追加します：

    # Specify server role as 'redis_master_role' with Sentinel and enable Consul agent
roles(['redis_sentinel_role', 'redis_master_role', 'consul_role'])
   
# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.51'
   
# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379
   
## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379
   
# Set up password authentication for Redis and replicas (use the same password in all nodes).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
   
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-cache'
   
## The IP of this primary Redis node.
redis['master_ip'] = '10.6.0.51'
   
# Set the Redis Cache instance as an LRU
# 90% of available RAM in MB
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5
   
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.51:6379',
     'redis.password' => 'redis-password-goes-here',
}
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

  4. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  5. 変更を有効にするには、GitLabを再設定してください。

レプリカRedis Cacheノードの設定

  1. レプリカRedisサーバーにSSH接続します。
  2. お好みのLinuxパッケージをダウンロードしてインストールしてください。ページのインストールステップ1と_2のみに従い_、現在インストールされているものと同じバージョンとタイプ（CommunityエディションまたはEnterpriseエディション）の正しいLinuxパッケージを選択してください。

  3. /etc/gitlab/gitlab.rb を編集し、redis_master_node をredis_replica_nodeに置き換えて、前のセクションのプライマリノードと同じ内容を追加します：

    # Specify server role as 'redis_replica_role' with Sentinel and enable Consul agent
roles(['roles_sentinel_role', 'redis_replica_role', 'consul_role'])
   
# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.52'
   
# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379
   
## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379
   
# Set up password authentication for Redis and replicas (use the same password in all nodes).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
   
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-cache'
   
## The IP of the primary Redis node.
redis['master_ip'] = '10.6.0.51'
   
# Set the Redis Cache instance as an LRU
# 90% of available RAM in MB
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5
   
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.52:6379',
     'redis.password' => 'redis-password-goes-here',
}
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

    1. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。この Linux パッケージ・ノードを最初に設定する場合は、この手順を省略できます。

    2. GitLabを再設定して変更を反映させます。

    3. 他のレプリカノードについてももう一度手順を確認し、IPが正しく設定されていることを確認してください。

    高度な設定オプションもサポートされており、必要に応じて追加することができます。

Redis Persistentクラスターの設定

このセクションでは、新しいRedis Queuesインスタンスをインストールして設定します。

プライマリノードとレプリカRedisノードの両方に、redis['password'] で定義された同じパスワードが必要です。フェイルオーバー中はいつでも、Sentinelsはノードを再設定し、そのステータスをプライマリノードからレプリカに変更できます（その逆も同様）。

プライマリRedis永続ノードの設定

  1. プライマリRedisサーバにSSH接続します。
  2. お好みのLinuxパッケージをダウンロードしてインストールしてください。ページのインストールステップ1と_2のみに従い_、現在インストールされているものと同じバージョンとタイプ（CommunityエディションまたはEnterpriseエディション）の正しいLinuxパッケージを選択してください。

  3. /etc/gitlab/gitlab.rb を編集し、内部を追加します：

    # Specify server roles as 'redis_master_role' with Sentinel and enable the Consul agent
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']
   
# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.61'
   
# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379
   
## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379
   
# Set up password authentication for Redis and replicas (use the same password in all nodes).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
   
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-persistent'
   
## The IP of this primary Redis node.
redis['master_ip'] = '10.6.0.61'
   
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

  4. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  5. 変更を有効にするには、GitLabを再設定してください。

レプリカRedis Persistentノードの設定

  1. レプリカRedis PersistentサーバにSSHでログインします。
  2. お好みのLinuxパッケージをダウンロードしてインストールしてください。ページのインストールステップ1と_2のみに従い_、現在インストールされているものと同じバージョンとタイプ（CommunityエディションまたはEnterpriseエディション）の正しいLinuxパッケージを選択してください。

  3. /etc/gitlab/gitlab.rb を編集し、内部を追加します：

    # Specify server roles as 'redis_replica_role' with Sentinel and enable Consul agent
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']
   
# Set IP bind address and Quorum number for Redis Sentinel service
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# IP address pointing to a local IP that the other machines can reach to.
# You can also set bind to '0.0.0.0' which listen in all interfaces.
# If you really need to bind to an external accessible IP, make
# sure you add extra firewall rules to prevent unauthorized access.
redis['bind'] = '10.6.0.62'
   
# Define a port so Redis can listen for TCP requests which will allow other
# machines to connect to it.
redis['port'] = 6379
   
## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
## to `6379`.
#redis['master_port'] = 6379
   
# The same password for Redis authentication you set up for the primary node.
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
   
## Must be the same in every Redis node
redis['master_name'] = 'gitlab-redis-persistent'
   
# The IP of the primary Redis node.
redis['master_ip'] = '10.6.0.61'
   
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

  4. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  5. 変更を有効にするには、GitLabを再設定してください。

  6. 他のレプリカノードについてももう一度手順を確認し、IPが正しく設定されていることを確認してください。

高度な設定オプションもサポートされており、必要に応じて追加することができます。

Gitalyクラスタの設定

Gitaly ClusterはGitLabが提供する、Gitリポジトリを保存するための推奨されるフォールトトレラントソリューションです。この設定では、すべてのGitリポジトリはクラスター内のすべてのGitalyノードに保存され、1つがプライマリノードとして指定され、プライマリノードがダウンした場合は自動的にフェイルオーバーが行われます。

Gitalyクラスタは、フォールトトレランスの利点を提供しますが、セットアップと管理の複雑さを伴います。Gitaly Clusterをデプロイする前に、既存の技術的な制限と考慮事項をレビューしてください。

ガイダンス

note
Gitalyは、ベストプラクティスに従った様々な規模のリポジトリで設計され、テストされています。しかし、これらのプラクティスに従わない大規模なリポジトリやモノレポは、Gitalyのパフォーマンスや要件に大きな影響を与える可能性があります。詳細については、大規模なリポジトリを参照してください。

推奨されるクラスターのセットアップには、以下のコンポーネントが含まれます：

  • 3つのGitalyノード：Gitリポジトリの複製ストレージ。
  • 3つのPraefectノード：Gitalyクラスタのルーターとトランザクションマネージャー。
  • PostgreSQLノード1台：Praefect用データベースサーバー。Praefectデータベース接続を高可用性にするには、サードパーティのソリューションが必要です。
  • ロードバランサー1台：Praefectにはロードバランサーが必要です。内部ロードバランサーを使用します。

このセクションでは、推奨される標準的な設定方法を順に説明します。より高度な設定については、スタンドアロンGitalyクラスタのドキュメントを参照してください。

PostgreSQLの設定

Gitaly Clusterのルーティングおよびトランザクション・マネージャーであるPraefectは、Gitaly Clusterのステータスに関するデータを保存するために独自のデータベース・サーバーを必要とします。

可用性の高いセットアップを行いたい場合、PraefectはサードパーティのPostgreSQLデータベースを必要とします。ビルトインのソリューションは現在開発中です。

Linuxパッケージを使用した非HA PostgreSQLスタンドアロンPraefect

例として以下のIPを使用します：

  • 10.6.0.141:Praefect PostgreSQL

まず、Praefect PostgreSQLノードにLinux GitLabパッケージをインストールします。手順に従って、ステップ1から必要な依存関係をインストールし、ステップ2からGitLabパッケージリポジトリを追加します。ステップ2でGitLabをインストールする際は、EXTERNAL_URL 。

  1. PostgreSQLノードにSSH接続します。
  2. PostgreSQLユーザーに使用する強力なパスワードを作成します。このパスワードは<praefect_postgresql_password> として控えておいてください。

  3. Praefect PostgreSQL ユーザー名/パスワードのペアのパスワードハッシュを生成します。ここでは、デフォルトのユーザー名praefect を使用するものとします（推奨）。このコマンドは、パスワード<praefect_postgresql_password> と確認を要求します。次の手順で、このコマンドが出力する値を<praefect_postgresql_password_hash>の値として使用します：

    sudo gitlab-ctl pg-password-md5 praefect

  4. # START user configuration セクションで説明した値を置き換えて、/etc/gitlab/gitlab.rb を編集します：

    # Disable all components except PostgreSQL and Consul
roles(['postgres_role', 'consul_role'])
   
# PostgreSQL configuration
postgresql['listen_address'] = '0.0.0.0'
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
   
# Configure the Consul agent
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
# START user configuration
# Please set the real values as explained in Required Information section
#
# Replace PRAEFECT_POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"
   
# Replace XXX.XXX.XXX.XXX/YY with Network Address
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
# Set the network addresses that the exporters will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

  5. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  6. 変更を有効にするには、GitLabを再設定してください。

  7. 投稿設定に従ってください。

Praefect HA PostgreSQLサードパーティソリューション

前述のとおり、完全な高可用性を目指す場合は、Praefectのデータベース用にサードパーティのPostgreSQLソリューションを使用することをお勧めします。

PostgreSQL HA用のサードパーティ製ソリューションは多数あります。選択したソリューションは、Praefectで動作するために以下を備えている必要があります：

  • フェイルオーバー時に変更されない、すべての接続用の静的IP。
  • LISTEN SQL機能がサポートされていること。
note
サードパーティのセットアップでは、レプリケーションを正しく処理するために別々のデータベースインスタンスが必要なGeoを使用していない限り、利便性としてGitLabのメインデータベースと同じサーバーにPraefectのデータベースを配置することが可能です。このセットアップでは、メインのデータベース・セットアップの仕様を変更する必要はありません。

この場合、評判の良いプロバイダーやソリューションを使用する必要があります。Google Cloud SQLと Amazon RDSは動作することが知られています。ただし、Amazon Auroraは14.4.0のデフォルトで有効になっているロードバランシングとは互換性がありません。詳細は推奨クラウドプロバイダーとサービスを参照してください。

上記の例としては、GoogleのCloud SQLや Amazon RDSなどが考えられます。

データベースの設定が完了したら、ポスト設定に従ってください。

PostgreSQLの後設定

PraefectのPostgreSQLサーバーを設定したら、次にPraefectが使用するユーザーとデータベースを設定する必要があります。

ユーザー名はpraefect 、データベース名はpraefect_production とすることをお勧めします。これらは PostgreSQL の標準設定として行うことができます。ユーザーのパスワードは、先ほど<praefect_postgresql_password>として設定したものと同じです。

LinuxパッケージのPostgreSQLのセットアップではこのようになります：

  1. PostgreSQLノードにSSH接続します。

  2. 管理者権限でPostgreSQLサーバーに接続します。Linux パッケージにデフォルトで追加されているので、gitlab-psql ユーザーを使用します。データベースtemplate1 は、すべてのPostgreSQLサーバーでデフォルトで作成されているため、これを使用します。

    /opt/gitlab/embedded/bin/psql -U gitlab-psql -d template1 -h POSTGRESQL_SERVER_ADDRESS

  3. <praefect_postgresql_password> を置き換えて、新しいユーザーpraefect を作成してください：

    CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD <praefect_postgresql_password>;

  4. PostgreSQLサーバに再接続し、今度はpraefect ：

    /opt/gitlab/embedded/bin/psql -U praefect -d template1 -h POSTGRESQL_SERVER_ADDRESS

  5. 新しいデータベースを作成しますpraefect_production ：

    CREATE DATABASE praefect_production WITH ENCODING=UTF8;

Praefectの設定

PraefectはGitaly Clusterのルーターであり、トランザクションマネージャーです。このセクションでは、その設定方法を詳しく説明します。

note
Praefectは奇数3ノード以降にデプロイする必要があります。これは、ノードが定足数の一部として投票を行えるようにするためです。

Praefectでは、クラスター間の通信をセキュリティで保護するために、いくつかのシークレットトークンが必要です：

  • <praefect_external_token>:クラスター上でホストされているリポジトリに使用され、このトークンを持つGitalyクライアントからのみアクセスできます。
  • <praefect_internal_token>:Gitalyクラスタ内のレプリケーション・トラフィックに使用されます。Gitalyクライアントがクラスター内部ノードに直接アクセスできないようにする必要があるため、praefect_external_token とは異なります。
  • <praefect_postgresql_password>:前のセクションで定義したPostgreSQLパスワードも、この設定の一部として必要です。

Gitalyクラスター・ノードは、Praefectでvirtual storage 。各ストレージには、クラスターを構成する各Gitalyノードの詳細が含まれています。各ストレージには名前も付けられ、この名前は設定のいくつかの領域で使用されます。このガイドでは、ストレージの名前はdefault とします。また、このガイドは新規インストールを対象としています。既存の環境をアップグレードしてGitalyクラスターを使用する場合は、別の名前を使用する必要があるかもしれません。詳細は、Praefect のドキュメントを参照してください。

例として以下のIPを使用します：

  • 10.6.0.131:Praefect 1
  • 10.6.0.132:プラフェクト2
  • 10.6.0.133:Praefect 3

Praefectノードを設定するには、それぞれのノードで行います：

  1. PraefectサーバーにSSH接続します。
  2. お好みのLinuxパッケージをダウンロードしてインストールします。ページのインストール・ステップ1と_2だけに従って_ください。

  3. /etc/gitlab/gitlab.rb ファイルを編集して、Praefect を設定します：

    note
    GitLabが必要とするため、virtual_storages からdefault エントリを削除することはできません。
# Avoid running unnecessary services on the Praefect server
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false

# Praefect Configuration
praefect['enable'] = true

# Prevent database migrations from running on upgrade automatically
praefect['auto_migrate'] = false
gitlab_rails['auto_migrate'] = false

# Configure the Consul agent
consul['enable'] = true
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true

# START user configuration
# Please set the real values as explained in Required Information section
#

praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
     # ...
     #
     # Praefect External Token
     # This is needed by clients outside the cluster (like GitLab Shell) to communicate with the Praefect cluster
     token: '<praefect_external_token>',
   },
   # Praefect Database Settings
   database: {
     # ...
     host: '10.6.0.141',
     port: 5432,
     # `no_proxy` settings must always be a direct connection for caching
     session_pooled: {
        # ...
        host: '10.6.0.141',
        port: 5432,
        dbname: 'praefect_production',
        user: 'praefect',
        password: '<praefect_postgresql_password>',
     },
   },
   # Praefect Virtual Storage config
   # Name of storage hash must match storage name in git_data_dirs on GitLab
   # server ('praefect') and in gitaly['configuration'][:storage] on Gitaly nodes ('gitaly-1')
   virtual_storage: [
      {
         # ...
         name: 'default',
         node: [
            {
               storage: 'gitaly-1',
               address: 'tcp://10.6.0.91:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-2',
               address: 'tcp://10.6.0.92:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-3',
               address: 'tcp://10.6.0.93:8075',
               token: '<praefect_internal_token>'
            },
         ],
      },
   ],
   # Set the network address Praefect will listen on for monitoring
   prometheus_listen_addr: '0.0.0.0:9652',
}

# Set the network address the node exporter will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'

## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

  1. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  2. Praefectでは、メインのGitLabアプリケーションと同様に、いくつかのデータベースマイグレーションを実行する必要があります。このため、マイグレーションを実行するPraefectノードを1つだけ選択する必要があります。このノードは、次のように他のノードより先に設定する必要があります：

    1. /etc/gitlab/gitlab.rb ファイルで、praefect['auto_migrate'] の設定値をfalse から次のように変更します。true

    2. データベースのマイグレーションがアップグレード時に自動的に実行されるのではなく、再設定時にのみ実行されるようにするには、以下を実行します：

    sudo touch /etc/gitlab/skip-auto-reconfigure
    1. GitLab を再設定して変更を有効にし、Praefect データベースのマイグレーションを実行します。

  3. 他のすべての Praefect ノードで、変更を有効にするためにGitLabを再設定します。

Gitalyの設定

クラスターを構成するGitalyサーバーノードは、データと負荷に依存する要件を持っています。

note
リポジトリが非常に大きい場合や、サーバフックなどの ワークロードが追加された場合など、状況によってはGitalyノードのスペックアップが必要になる場合があります。
note
Gitalyは、ベストプラクティスに従った様々な規模のリポジトリで設計され、テストされています。しかし、これらのプラクティスに従わない大規模なリポジトリやモノレポは、Gitalyのパフォーマンスや要件に大きな影響を与える可能性があります。詳細については、大規模なリポジトリを参照してください。

Gitalyには顕著な入出力要件があるため、すべてのGitalyノードでソリッド・ステート・ドライブ(SSD)を使用することを強く推奨します。これらのSSDは、読み取りオペレーションで少なくとも毎秒8,000の入出力オペレーション(IOPS) 、書き込みオペレーションで2,000 IOPSのスループットを持つ必要があります。クラウドプロバイダー上で環境を実行している場合は、IOPSを正しく設定する方法について、プロバイダーのドキュメントを参照してください。

Gitalyのネットワークトラフィックはデフォルトでは暗号化されていないため、Gitalyサーバは公開インターネットに公開されてはいけません。Gitalyサーバへのアクセスを制限するために、ファイアウォールの使用を強く推奨します。もう一つの方法はTLSを使用することです。

Gitalyの設定については、以下の点にご注意ください：

  • gitaly['configuration'][:storage] 特定のGitalyノードのストレージパスを反映するように設定する必要があります。
  • auth_token と同じでなければなりません。praefect_internal_token

例として以下のIPを使用します：

  • 10.6.0.91:Gitaly 1
  • 10.6.0.92:ジタリー2
  • 10.6.0.93:ジタリー3

各ノードに

  1. お好みのLinuxパッケージをダウンロードしてインストールします。ページのインストール・ステップ1と_2のみに従い_、EXTERNAL_URL の値は指定_しないで_ください。
  2. Gitalyサーバーノードの/etc/gitlab/gitlab.rb ファイルを編集し、ストレージパスの設定、ネットワークリスナーの有効化、トークンの設定を行います：
# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

# Gitaly
gitaly['enable'] = true

# Configure the Consul agent
consul['enable'] = true
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true

# START user configuration
# Please set the real values as explained in Required Information section
#
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# Set the network address that the node exporter will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'

gitaly['configuration'] = {
   # Make Gitaly accept connections on all network interfaces. You must use
   # firewalls to restrict access to this address/port.
   # Comment out following line if you only want to support TLS connections
   listen_addr: '0.0.0.0:8075',
   # Set the network address that Gitaly will listen on for monitoring
   prometheus_listen_addr: '0.0.0.0:9236',
   auth: {
      # Gitaly Auth Token
      # Should be the same as praefect_internal_token
      token: '<praefect_internal_token>',
   },
   pack_objects_cache: {
      # Gitaly Pack-objects cache
      # Recommended to be enabled for improved performance but can notably increase disk I/O
      # Refer to https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache for more info
      enabled: true,
   },
}

#
# END user configuration
  1. 各サーバーの/etc/gitlab/gitlab.rb ：

    • Gitaly ノード 1：

       gitaly['configuration'] = {
    # ...
    storage: [
       {
          name: 'gitaly-1',
          path: '/var/opt/gitlab/git-data',
       },
    ],
 }

    • Gitalyノード2：

       gitaly['configuration'] = {
    # ...
    storage: [
       {
          name: 'gitaly-2',
          path: '/var/opt/gitlab/git-data',
       },
    ],
 }

    • Gitalyノード3で：

       gitaly['configuration'] = {
    # ...
    storage: [
       {
          name: 'gitaly-3',
          path: '/var/opt/gitlab/git-data',
       },
    ],
 }

  2. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  3. ファイルを保存し、GitLabを再設定します。

GitalyクラスタTLSサポート

PraefectはTLS暗号化をサポートしています。セキュアな接続をリッスンするPraefectインスタンスと通信するには、以下が必要です：

  • GitLab 設定の対応するストレージエントリーのgitaly_address でtls:// URL スキームを使用します。
  • 証明書は自動的には提供されないため、各自でご用意ください。各 Praefect サーバーに対応する証明書をインストールする必要があります。

さらに、証明書、またはその作成者は、GitLabカスタム証明書設定で説明されている手順に従って、すべてのGitalyサーバーとそれと通信するすべてのPraefectクライアントにインストールする必要があります（以下も同様）。

以下に注意してください。

  • 証明書には、Praefect サーバーへのアクセスに使用するアドレスを指定する必要があります。ホスト名または IP アドレスを証明書のサブジェクト代替名として追加する必要があります。
  • 暗号化されていないリスニングアドレスlisten_addr と暗号化されたリスニングアドレスtls_listen_addr の両方を持つ Praefect サーバーを同時に設定できます。これにより、必要に応じて、暗号化されていないトラフィックから暗号化されたトラフィックに徐々に移行することができます。暗号化されていないリスナーを無効にするには、praefect['configuration'][:listen_addr] = nil を設定します。
  • 内部ロードバランサーも証明書にアクセスし、TLS パススルーを許可するように設定する必要があります。設定方法についてはロードバランサのドキュメントを参照してください。

TLSでPraefectを設定するには、次の手順に従います：

  1. Praefectサーバー用の証明書を作成します。

  2. Praefect サーバーで、/etc/gitlab/ssl ディレクトリを作成し、そこに鍵と証明書をコピーします：

    sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp key.pem cert.pem /etc/gitlab/ssl/
sudo chmod 644 key.pem cert.pem

  3. /etc/gitlab/gitlab.rb を編集し、追加してください：

    praefect['configuration'] = {
   # ...
   tls_listen_addr: '0.0.0.0:3305',
   tls: {
      # ...
      certificate_path: '/etc/gitlab/ssl/cert.pem',
      key_path: '/etc/gitlab/ssl/key.pem',
   },
}

  4. ファイルを保存して再設定してください。

  5. Praefectクライアント（各Gitalyサーバーを含む）で、証明書またはその作成者を/etc/gitlab/trusted-certs にコピーします：

    sudo cp cert.pem /etc/gitlab/trusted-certs/

  6. Praefectクライアント（Gitalyサーバーを除く）で、/etc/gitlab/gitlab.rb のgit_data_dirs を以下のように編集します：

    git_data_dirs({
  "default" => {
    "gitaly_address" => 'tls://LOAD_BALANCER_SERVER_ADDRESS:3305',
    "gitaly_token" => 'PRAEFECT_EXTERNAL_TOKEN'
  }
})

  7. ファイルを保存し、GitLabを再設定してください。

Sidekiqの設定

SidekiqはRedis、PostgreSQL、Gitalyインスタンスへの接続を必要とします。また、推奨されるようにオブジェクトストレージへの接続も必要です。

note
データオブジェクトにはNFSではなくオブジェクトストレージを使用することが推奨されているため、以下の例ではオブジェクトストレージの設定を行います。
  • 10.6.0.101: Sidekiq 1
  • 10.6.0.102: Sidekiq 2
  • 10.6.0.103: Sidekiq 3
  • 10.6.0.104: Sidekiq 4

Sidekiqノードを設定するには、それぞれのノードで行います：

  1. SidekiqサーバーにSSH接続します。
  2. お好みのLinuxパッケージをダウンロードしてインストールします。ページのインストール・ステップ1と_2だけに従って_ください。
  3. /etc/gitlab/gitlab.rb を作成または編集し、以下の設定を使用します：
roles ["sidekiq_role"]

# External URL
## This should match the URL of the external load balancer
external_url 'https://gitlab.example.com'

# Redis
## Redis connection details
## First cluster that will host the cache data
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'

gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]

## Second cluster that hosts all other persistent data
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'

gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', port: 26379},
]

# Gitaly
# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs

## Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"

## Set number of Sidekiq queue processes to the same number as available CPUs
sidekiq['queue_groups'] = ['*'] * 4

## Set number of Sidekiq threads per queue process to the recommend number of 20
sidekiq['max_concurrency'] = 20

# Monitoring
consul['enable'] = true
consul['monitoring_service_discovery'] =  true

consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'

## Add the monitoring node's IP address to the monitoring whitelist
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']

# Object storage
## This is an example for configuring Object Storage on GCP
## Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"

  1. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  2. データベースのマイグレーションがアップグレード時に自動的に実行されるのではなく、再設定時にのみ実行されるようにするには、以下を実行します：

    sudo touch /etc/gitlab/skip-auto-reconfigure

    GitLab Railsの設定後のセクションで詳しく説明されているように、単一の指定ノードのみがマイグレーションを処理する必要があります。

  3. 変更を有効にするには、GitLabを再設定してください。

note
環境のSidekiqジョブ処理が長いキューで遅い場合は、必要に応じてノードを追加できます。また、複数のSidekiqプロセスを実行するようにSidekiqノードをチューニングすることもできます。

GitLab Railsの設定

GitLabアプリケーション（Rails）コンポーネントの設定方法を説明します。

RailsはRedis、PostgreSQL、Gitalyインスタンスへの接続を必要とします。また、推奨されるオブジェクトストレージへの接続も必要です。

note
データオブジェクトにはNFSではなくオブジェクトストレージを使用することが推奨されているため、以下の例ではオブジェクトストレージの設定を行います。

例として以下のIPを使用します：

  • 10.6.0.111:GitLab アプリケーション 1
  • 10.6.0.112:GitLabアプリケーション2
  • 10.6.0.113:GitLabアプリケーション3
  • 10.6.0.114:GitLabアプリケーション4
  • 10.6.0.115:GitLabアプリケーション5
  • 10.6.0.116:GitLabアプリケーション6
  • 10.6.0.117:GitLabアプリケーション 7
  • 10.6.0.118:GitLabアプリケーション 8
  • 10.6.0.119:GitLabアプリケーション 9
  • 10.6.0.120:GitLabアプリケーション 10
  • 10.6.0.121:GitLabアプリケーション11
  • 10.6.0.122:GitLabアプリケーション 12

各ノードで以下を実行します：

  1. お好みのLinuxパッケージをダウンロードしてインストールします。ページのインストール・ステップ1と_2だけに従って_ください。

  2. /etc/gitlab/gitlab.rb を編集し、以下の設定を使用します。ノード間のリンクの統一性を保つために、アプリケーションサーバーのexternal_url はユーザーが GitLab にアクセスするために使う外部 URL を指すようにします。これは、GitLabアプリケーションサーバーにトラフィックをルーティングする外部のロードバランサーのURLになります：

    external_url 'https://gitlab.example.com'
   
# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
    "gitaly_token" => '<praefect_external_token>'
  }
})
   
## Disable components that will not be on the GitLab application server
roles(['application_role'])
gitaly['enable'] = false
nginx['enable'] = true
sidekiq['enable'] = false
   
## PostgreSQL connection details
# Disable PostgreSQL on the application node
postgresql['enable'] = false
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
   
## Redis connection details
## First cluster that will host the cache data
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
   
gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]
   
## Second cluster that hosts all other persistent data
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'
   
gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', port: 26379},
]
   
# Set the network addresses that the exporters used for monitoring will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
puma['listen'] = '0.0.0.0'
   
# Add the monitoring node's IP address to the monitoring whitelist and allow it to
# scrape the NGINX metrics
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.151/32', '127.0.0.0/8']
   
#############################
###     Object storage    ###
#############################
   
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"

  3. TLSをサポートしているGitalyを使っている場合は、git_data_dirs のエントリーがtcpではなくtls で設定されていることを確認してください：

    git_data_dirs({
  "default" => {
    "gitaly_address" => "tls://10.6.0.40:2305", # internal load balancer IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

    1. 証明書を/etc/gitlab/trusted-certs にコピーしてください：

      sudo cp cert.pem /etc/gitlab/trusted-certs/
  4. 最初に設定した Linux パッケージ・ノードから/etc/gitlab/gitlab-secrets.json ファイルをコピーし、このサーバに同名のファイルを追加または置き換えます。これが最初に設定する Linux パッケージ・ノードである場合は、この手順を省略できます。

  5. データベースのマイグレーションがアップグレード時に自動的に実行されるのではなく、再設定時にのみ実行されるようにするには、以下を実行します：

    sudo touch /etc/gitlab/skip-auto-reconfigure

    GitLab Railsの設定後のセクションで詳しく説明されているように、単一の指定ノードのみがマイグレーションを処理する必要があります。

  6. 変更を有効にするには、GitLabを再設定してください。
  7. インクリメンタルロギングを有効にします。

  8. ノードがGitalyに接続できることを確認します：

    sudo gitlab-rake gitlab:gitaly:check

    次に、リクエストを見るためにログを尾行します：

    sudo gitlab-ctl tail gitaly
  9. オプションとして、Gitalyサーバーから、Gitalyが内部APIへのコールバックを実行できることを確認します：
    • GitLab 15.3以降では、sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml.
    • GitLab 15.2 以前については、sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml を実行してください。

前の例のようにexternal_url でhttps を指定すると、GitLab は SSL 証明書が/etc/gitlab/ssl/ にあることを期待します。証明書がない場合、NGINX は起動に失敗します。詳しくはHTTPS のドキュメントをご覧ください。

GitLab Railsの事後設定

  1. インストールとアップデートの間、データベースのマイグレーションを実行するアプリケーションノードを1つ指定します。GitLab データベースを初期化し、すべてのマイグレーションが実行されたことを確認します：

    sudo gitlab-rake gitlab:db:configure

    これには、プライマリデータベースに直接接続するようにRailsノードを設定し、PgBouncerをバイパスする必要があることに注意してください。マイグレーションが完了したら、再びPgBouncerを通過するようにノードを設定する必要があります。

  2. データベース内の作成者SSHキーの高速検索を設定します。

Prometheus の設定

Linuxパッケージを使用して、Prometheusと Grafanaを実行するスタンドアロンのMonitoringノードを設定できます。

例として以下のIPを使用します：

  • 10.6.0.151: Prometheus

Monitoringノードを設定します：

  1. MonitoringノードにSSHでログインします。

  2. お好みのLinuxパッケージをダウンロードしてインストールします。ページのインストール・ステップ1と_2だけに従って_ください。

  3. /etc/gitlab/gitlab.rb を編集し、内部を追加します：

    roles(['monitoring_role', 'consul_role'])
   
external_url 'http://gitlab.example.com'
   
# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false
   
# Grafana
grafana['admin_password'] = '<grafana_password>'
grafana['disable_login_form'] = false
   
# Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
# Configure Prometheus to scrape services not covered by discovery
prometheus['scrape_configs'] = [
   {
      'job_name': 'pgbouncer',
      'static_configs' => [
         'targets' => [
         "10.6.0.31:9188",
         "10.6.0.32:9188",
         "10.6.0.33:9188",
         ],
      ],
   },
   {
      'job_name': 'praefect',
      'static_configs' => [
         'targets' => [
         "10.6.0.131:9652",
         "10.6.0.132:9652",
         "10.6.0.133:9652",
         ],
      ],
   },
]
   
# Nginx - For Grafana access
nginx['enable'] = true
  4. ファイルを保存し、GitLabを再設定してください。
  5. GitLab UIで、admin/application_settings/metrics_and_profiling > Metrics - Grafanaを/-/grafana に設定します。http[s]://<MONITOR NODE>/-/grafana

オブジェクトストレージの設定

GitLabは多くの種類のデータを保持するためにオブジェクトストレージサービスを使うことをサポートしています。一般的にオブジェクトストレージの方がパフォーマンス、信頼性、スケーラビリティが高いため、大規模なセットアップには適しています。詳細については、推奨クラウド・プロバイダーとサービスを参照してください。

GitLabでオブジェクトストレージの設定を指定する方法は2つあります：

  • 統合形式：一つのクレデンシャルが全てのサポートされているオブジェクトタイプで共有されます。
  • ストレージ固有の形式：各オブジェクトは、独自のオブジェクトストレージ接続と設定を定義します。

以下の例では、利用可能な場合は連結形式を使用しています。

note
GitLab 14.x以前のバージョンでストレージ固有のフォームを使う場合は、ダイレクトアップロードモードを有効にしてください。14.9で非推奨となった以前のバックグラウンドアップロードモードでは、NFSのような共有ストレージが必要です。

データ型ごとに別々のバケットを使うのが、GitLabの推奨するアプローチです。これにより、GitLabが保存する様々な種類のデータ間で衝突が起こらないようになります。将来的には単一のバケットを使えるようにする予定です。

インクリメンタルロギングの有効化

GitLab Runnerは、統合オブジェクトストレージを使用している場合でも、デフォルトではLinuxパッケージが/var/opt/gitlab/gitlab-ci/builds 、ディスク上に一時的にキャッシュするチャンクでジョブログを返します。デフォルト設定では、このディレクトリはGitLab RailsとSidekiqノード上でNFSを通して共有する必要があります。

NFSによるジョブログの共有はサポートされていますが、インクリメンタルロギングを有効にしてNFSを使用する必要性を回避することをお勧めします（NFSノードがデプロイされていない場合に必要です）。インクリメンタルロギングは、ジョブログの一時的なキャッシュにディスクスペースの代わりに Redis を使用します。

Elasticsearchを活用し、高度な検索を有効にすることで、GitLabインスタンス全体でより速く、より高度なコード検索を行うことができます。

Elasticsearch クラスタの設計と要件は、お客様の特定のデータに依存します。インスタンスと一緒にElasticsearchクラスターを設定する方法についての推奨ベストプラクティスについては、最適なクラスター設定の選び方をお読みください。

Helmチャートによるクラウドネイティブハイブリッドのリファレンスアーキテクチャ（代替案）

別のアプローチとして、GitLabの一部のコンポーネントを、公式のHelm Chartsを経由してKubernetesでCloud Nativeとして実行することもできます。このセットアップでは、KubernetesクラスターでGitLab RailsとSidekiqノードに相当するものを、それぞれWebserviceとSidekiqという名前で実行することをサポートしています。さらに、以下の他のサポートサービスもサポートしています：NGINX、Task Runner、マイグレーション、Prometheus、Grafanaです。

ハイブリッドインストールは、クラウドネイティブと従来のコンピュートデプロイの両方の利点を活用します。これにより、_ステートレスコンポーネントは_クラウドネイティブのワークロード管理のメリットを享受でき、_ステートフルコンポーネントは_LinuxパッケージインストールでコンピュートVMにデプロイされるため、永続性が向上します。

Kubernetesとバックエンドコンポーネント間で同期するGitLabシークレットのガイダンスを含む設定手順については、Helm chartsAdvanced設定ドキュメントを参照してください。

note
これは高度なセットアップです。Kubernetesでのサービスの実行は複雑であることがよく知られています。このセットアップは、Kubernetesに関する知識と経験が豊富な場合にのみ推奨されます。このセクションの残りの部分はこれを前提としています。
note
Gitaly ClusterをKubernetesで実行することはサポートされていません。詳細はエピック6127を参照してください。

クラスターのトポロジー

以下の表と図は、上記の典型的な環境と同じフォーマットを使用したハイブリッド環境の詳細です。

まず、Kubernetesで実行されるコンポーネントです。これらは複数のノードグループにまたがって実行されますが、CPUとメモリの最小要件が守られている限り、全体の構成は自由に変更できます。

サービスノードグループノード設定GCPAWS最小割り当てCPUとメモリ
ウェブサービス1632vCPU、28.8GBメモリn1-highcpu-32c5.9xlarge510 vCPU、472 GBメモリ
Sidekiq44 vCPU、15 GB メモリn1-standard-4m5.xlarge15.5 vCPU、50 GBメモリ
サポートサービス24 vCPU、15 GB メモリn1-standard-4m5.xlarge7.75 vCPU、25 GBメモリ
  • このセットアップでは、Google Kubernetes Engine(GKE)とAmazon Elastic Kubernetes Service(EKS)を推奨し、定期的にテストしています。他のKubernetesサービスでも動作する可能性がありますが、お客様のご判断によります。
  • ポッドvCPU/メモリ比率を確保し、パフォーマンステスト中のスケーリングを回避するため、ポッドの設定を示しています。
    • 本番デプロイでは、ポッドを特定のノードに割り当てる必要はありません。レジリエントなクラウドアーキテクチャのプラクティスに合わせるため、3つの異なるアベイラビリティゾーンにノードグループごとに最低3つのノードを配置することを強く推奨します。

次に、Linuxパッケージ（または該当する場合は外部PaaSサービス）を使用して静的コンピュートVM上で実行されるバックエンドコンポーネントです：

サービスノード設定GCPAWS
領事1 32 vCPU、1.8 GBメモリn1-highcpu-2c5.large
PostgreSQL1 332vCPU、120GBメモリn1-standard-32m5.8xlarge
PgBouncer1 32 vCPU、1.8 GBメモリn1-highcpu-2c5.large
内部ロードバランシングノード3 18 vCPU、7.2 GBメモリn1-highcpu-8c5.2xlarge
Redis/Sentinel - キャッシュ2 34 vCPU、15 GB メモリn1-standard-4m5.xlarge
Redis/Sentinel - 永続的2 34 vCPU、15 GB メモリn1-standard-4m5.xlarge
Gitaly5 6 364vCPU、240GBメモリn1-standard-64m5.16xlarge
Praefect5 34 vCPU、3.6 GBメモリn1-highcpu-4c5.xlarge
Praefect PostgreSQL1 1+2 vCPU、1.8 GBメモリn1-highcpu-2c5.large
オブジェクトストレージ4 ----
  1. オプションで、評判の良いサードパーティの外部PaaS PostgreSQLソリューションで実行することができます。詳細はPostgreSQL インスタンスの提供を参照してください。
  2. オプションで、評判の良いサードパーティの外部PaaS Redisソリューションで実行できます。詳細については、Redisインスタンスの提供を参照してください。
    • Redisは主にシングルスレッドです。このスケールで最適なパフォーマンスを得るには、インスタンスをキャッシュと永続データに分けることを強くお勧めします。
  3. オプションとして、評判の高いサードパーティのロードバランシングサービス（LB PaaS）で実行できます。詳細については、推奨クラウドプロバイダーとサービスを参照してください。
  4. 信頼できるクラウドプロバイダーまたはセルフマネージドソリューションで実行する必要があります。詳細については、オブジェクトストレージの設定を参照してください。
  5. Gitaly Clusterはフォールトトレランスの利点を提供しますが、セットアップと管理の複雑さを伴います。Gitaly Clusterをデプロイする前に、既存の技術的な制限と考慮事項をレビューしてください。Gitalyをシャーディングしたい場合は、上記のGitalyと同じ仕様を使用してください。
  6. Gitalyは、ベスト・プラクティスに従った様々な規模のリポジトリで設計され、テストされています。しかし、これらのプラクティスに従わない大規模なリポジトリやモノレポは、Gitalyの要件に大きな影響を与える可能性があります。詳細については、大規模なリポジトリを参照してください。
note
インスタンスの設定を伴うすべてのPaaSソリューションでは、レジリエントなクラウド・アーキテクチャのプラクティスに合わせるため、3つの異なるアベイラビリティ・ゾーンに最低3つのノードを実装することを強く推奨します。

リソース使用設定

リソース制約の範囲内でデプロイ可能なポッドの数を計算する場合、次の計算式が役立ちます。50kリファレンスアーキテクチャのサンプル値ファイルは、計算された設定をHelm Chartに適用する方法を文書化しています。

ウェブサービス

Webservice ポッドは通常、_ワーカーあたり_約 1 CPU と 1.25 GB のメモリを必要とします。デフォルトで 4 つのワーカープロセスが作成され、各ポッドで他の小さなプロセスが実行されるため、推奨トポロジーを使用した場合、各 Webservice ポッドはおよそ 4 CPU と 5 GB のメモリを消費します。

50,000 ユーザーの場合、Puma のワーカー総数は約 320 を推奨します。この推奨値では、1 ポッドあたり 4 ワーカー、1 ノードあたり 5 ポッドで、最大 80 の Webservice ポッドをデプロイできます。追加の Webservice ポッドごとに、_各ワーカー・プロセスごとに_1 CPU と 1.25 GB のメモリの比率を使用して、利用可能なリソースを拡張します。

リソースの使用に関する詳細は、Webservice リソースを参照してください。

Sidekiq

Sidekiqポッドには通常、0.9 CPUと2 GBのメモリが必要です。

提供されている開始ポイントでは、最大14個のSidekiqポッドをデプロイできます。ポッドを追加するごとに、0.9 CPUと2 GBメモリの比率を使用して利用可能なリソースを拡張します。

リソース使用の詳細については、Sidekiqリソースを参照してください。

サポート

Supporting Node Poolは、WebserviceおよびSidekiqプール上にある必要のないすべてのサポートデプロイを収容するように設計されています。

これには、クラウドプロバイダの実装に関連する様々なデプロイや、NGINXやGitLab ShellのようなGitLabデプロイのサポートが含まれます。

Monitoringなどのデプロイを追加したい場合は、WebserviceプールやSidekiqプールではなく、可能な限りこのプールにデプロイすることをお勧めします。ただし、デプロイが指定されたプールに収まらない場合は、それに応じてノード・プールを増やすことができます。