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

このGitLabリファレンスアーキテクチャは、GitLabを3,000ユーザーまでデプロイし、それらのユーザーのアップタイムとアクセスをメンテナーするのに役立ちます。また、このアーキテクチャを使って、3,000人未満のユーザーに対してGitLabのアップタイムと可用性を改善することもできます。ユーザーが少ない場合は、必要に応じて規定のノードサイズを小さくしてください。

GitLab環境の高いレベルのアップタイムを維持することが要件でない場合や、この種の環境をメンテナーする専門知識がない場合は、GitLabインストールにHAでない2,000ユーザーのリファレンスアーキテクチャを使用することをお勧めします。HAがまだ必要な場合は、このアーキテクチャにいくつかの調整を加えることで、複雑さを軽減することができます。

リファレンスアーキテクチャの完全なリストについては、利用可能なリファレンスアーキテクチャをご覧ください。

サービスノード設定GCPAWS
外部負荷分散ノード3 12 vCPU、1.8 GBメモリn1-highcpu-2c5.large
Redis2 32 vCPU、7.5 GBメモリn1-standard-2m5.large
Consul1 + Sentinel2 32 vCPU、1.8 GBメモリn1-highcpu-2c5.large
PostgreSQL1 32 vCPU、7.5 GBメモリn1-standard-2m5.large
PgBouncer1 32 vCPU、1.8 GBメモリn1-highcpu-2c5.large
内部ロードバランシングノード3 12 vCPU、1.8 GBメモリn1-highcpu-2c5.large
Gitaly5 6 34 vCPU、15 GB メモリn1-standard-4m5.xlarge
Praefect5 32 vCPU、1.8 GBメモリn1-highcpu-2c5.large
Praefect PostgreSQL1 1+2 vCPU、1.8 GBメモリn1-highcpu-2c5.large
Sidekiq7 42 vCPU、7.5 GBメモリn1-standard-2m5.large
GitLab Rails7 38 vCPU、7.2 GBメモリn1-highcpu-8c5.2xlarge
監視ノード12 vCPU、1.8 GBメモリn1-highcpu-2c5.large
オブジェクトストレージ4 ----
  1. オプションで、評判の良いサードパーティの外部PaaS PostgreSQLソリューションで実行することができます。詳細はPostgreSQL インスタンスの提供を参照してください。
  2. オプションで、評判の良いサードパーティの外部PaaS 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とそのコンポーネントを最大3,000人のユーザーに対応するようにセットアップします：

  1. GitLab アプリケーションサービスノードのロードバランシングを処理するために、外部ロードバランサーを設定します。
  2. GitLab アプリケーション内部接続のロードバランシングを処理するために、内部ロードバランサーを設定します。
  3. Redis を設定します。
  4. ConsulとSentinelの設定。
  5. GitLabのデータベースであるPostgreSQLを設定します。
  6. PgBouncer を設定します。
  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.20:内部ロードバランサー
  • 10.6.0.61:Redis プライマリ
  • 10.6.0.62:Redis レプリカ 1
  • 10.6.0.63:Redisレプリカ2
  • 10.6.0.51:Gitaly 1
  • 10.6.0.52:ジタリー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.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2
  • 10.6.0.73: Sidekiq 3
  • 10.6.0.74: Sidekiq 4
  • 10.6.0.41:GitLab アプリケーション 1
  • 10.6.0.42:GitLabアプリケーション2
  • 10.6.0.43:GitLabアプリケーション3
  • 10.6.0.81: Prometheus

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

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

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

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

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

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

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

準備チェック

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

ポート

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

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

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

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

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

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

Redisの設定

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

note
Redisクラスターはそれぞれ3ノード以上の奇数でデプロイする必要があります。これは、Redis Sentinelがクォーラムの一部として投票できるようにするためです。クラウドプロバイダのサービスなど、Redisを外部で設定する場合はこの限りではありません。

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

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

  • 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ではサポートされていないことに注意してください。詳しくは推奨クラウドプロバイダーとサービスをご覧ください。

Linuxパッケージを使ったスタンドアロンRedis

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

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

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

プライマリノードとレプリカ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' and enable Consul agent
roles(['redis_master_role', 'consul_role'])
   
# 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
   
# Set up password authentication for Redis (use the same password in all nodes).
redis['password'] = 'redis-password-goes-here'
   
## 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.61: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を再設定してください。

sentinelやRedisのように、複数のロールを指定することができます：roles ['redis_sentinel_role', 'redis_master_role'].ロールについてはこちらを参照してください。

現在のRedisのプライマリ、レプリカのステータスは、次のようにして一覧できます：

/opt/gitlab/embedded/bin/redis-cli -h <host> -a 'redis-password-goes-here' info replication

実行中のGitLabサービスを表示します：

gitlab-ctl status

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

run: consul: (pid 30043) 76863s; run: log: (pid 29691) 76892s
run: logrotate: (pid 31152) 3070s; run: log: (pid 29595) 76908s
run: node-exporter: (pid 30064) 76862s; run: log: (pid 29624) 76904s
run: redis: (pid 30070) 76861s; run: log: (pid 29573) 76914s
run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s

レプリカRedisインスタンスの設定

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

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

    # Specify server role as 'redis_replica_role' and enable Consul agent
roles(['redis_replica_role', 'consul_role'])
   
# 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
   
# The same password for Redis authentication you set up for the primary node.
redis['password'] = 'redis-password-goes-here'
   
# The IP of the primary Redis node.
redis['master_ip'] = '10.6.0.61'
   
# Port of primary Redis server, uncomment to change to non default. Defaults
# to `6379`.
#redis['master_port'] = 6379
   
## 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.62: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を再設定してください。
  6. 他のレプリカノードについてももう一度手順を確認し、IPが正しく設定されていることを確認してください。

sentinelやRedisのように、複数のロールを指定することができます：roles(['redis_sentinel_role', 'redis_master_role']).ロールについてはこちらを参照してください。

ノードはSentinelsによって管理され、gitlab-ctl reconfigure、フェイルオーバー後も同じSentinelsによって設定が復元されるため、フェイルオーバー後に/etc/gitlab/gitlab.rb 、これらの値を再度変更する必要はありません。

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

ConsulとSentinelの設定

Redisサーバーがすべて設定できたので、次はConsul + Sentinelサーバーを設定しましょう。

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

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

  • 10.6.0.11:コンスル/センチネル 1
  • 10.6.0.12:領事／歩哨2
  • 10.6.0.13:領事／歩哨3
note
外部のRedis Sentinelインスタンスを使用している場合は、Sentinelの設定からrequirepass パラメータを必ず除外してください。このパラメータはクライアントにNOAUTH Authentication required.を報告させます。Redis Sentinel 3.2.xはパスワード認証をサポートしていません。

Sentinelを設定するには：

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

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

    roles(['redis_sentinel_role', 'consul_role'])
   
# Must be the same in every sentinel node
redis['master_name'] = 'gitlab-redis'
   
# The same password for Redis authentication you set up for the primary node.
redis['master_password'] = 'redis-password-goes-here'
   
# The IP of the primary Redis node.
redis['master_ip'] = '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, uncomment to change to non default. Defaults
# to `6379`.
#redis['master_port'] = 6379
   
## Configure Sentinel
sentinel['bind'] = '10.6.0.11'
   
# Port that Sentinel listens on, uncomment to change to non default. Defaults
# to `26379`.
# sentinel['port'] = 26379
   
## Quorum must reflect the amount of voting sentinels it take to start a failover.
## Value must NOT be greater then the amount of sentinels.
##
## The quorum can be used to tune Sentinel in two ways:
## 1. If a the quorum is set to a value smaller than the majority of Sentinels
##    we deploy, we are basically making Sentinel more sensible to primary failures,
##    triggering a failover as soon as even just a minority of Sentinels is no longer
##    able to talk with the primary.
## 1. If a quorum is set to a value greater than the majority of Sentinels, we are
##    making Sentinel able to failover only when there are a very large number (larger
##    than majority) of well connected Sentinels which agree about the primary being down.s
sentinel['quorum'] = 2
   
## Consider unresponsive server down after x amount of ms.
# sentinel['down_after_milliseconds'] = 10000
   
## Specifies the failover timeout in milliseconds. It is used in many ways:
##
## - The time needed to re-start a failover after a previous failover was
##   already tried against the same primary by a given Sentinel, is two
##   times the failover timeout.
##
## - The time needed for a replica replicating to a wrong primary according
##   to a Sentinel current configuration, to be forced to replicate
##   with the right primary, is exactly the failover timeout (counting since
##   the moment a Sentinel detected the misconfiguration).
##
## - The time needed to cancel a failover that is already in progress but
##   did not produced any configuration change (REPLICAOF NO ONE yet not
##   acknowledged by the promoted replica).
##
## - The maximum time a failover in progress waits for all the replica to be
##   reconfigured as replicas of the new primary. However even after this time
##   the replicas will be reconfigured by the Sentinels anyway, but not with
##   the exact parallel-syncs progression as specified.
# sentinel['failover_timeout'] = 60000
   
## 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'
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. 他の全てのConsul/Sentinelノードについてもう一度手順を確認し、正しい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
run: sentinel: (pid 30098) 76832s; run: log: (pid 29704) 76850s

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['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'
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

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

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

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

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul

  5. 各ノードが現在のマスターと会話していることを確認します：

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

    パスワードを入力した後にエラーpsql: ERROR: Auth failed が発生する場合は、以前に正しいフォーマットで MD5 パスワード・ハッシュを生成していることを確認してください。正しいフォーマットは、パスワードとユーザー名を連結したものです：PASSWORDUSERNAME 。たとえば、Sup3rS3cr3tpgbouncer は、pgbouncer ユーザー用の MD5 パスワードハッシュを生成するために必要なテキストです。

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

    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)

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

    sudo gitlab-ctl status

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

    run: consul: (pid 31530) 77150s; run: log: (pid 31106) 77182s
run: logrotate: (pid 32613) 3357s; run: log: (pid 30107) 77500s
run: node-exporter: (pid 31550) 77149s; run: log: (pid 30138) 77493s
run: pgbouncer: (pid 32033) 75593s; run: log: (pid 31117) 77175s
run: pgbouncer-exporter: (pid 31558) 77148s; run: log: (pid 31498) 77156s

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のデフォルトで有効になっているロードバランシングとは互換性がありません。詳細は推奨クラウドプロバイダーとサービスを参照してください。

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

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

# Gitaly
gitaly['enable'] = true

# 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'

# 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',
   # Gitaly Auth Token
   # Should be the same as praefect_internal_token
   auth: {
      # ...
      token: '<praefect_internal_token>',
   },
   # 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
   pack_objects_cache: {
      # ...
      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ではなくオブジェクトストレージを使用することが推奨されているため、以下の例ではオブジェクトストレージの設定を行います。

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

  • 10.6.0.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2
  • 10.6.0.73: Sidekiq 3
  • 10.6.0.74: Sidekiq 4

Sidekiqノードを1台ずつ設定します：

  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['master_name'] = 'gitlab-redis'

## The same password for Redis authentication you set up for the master node.
redis['master_password'] = '<redis_primary_password>'

## A list of sentinels with `host` and `port`
gitlab_rails['redis_sentinels'] = [
   {'host' => '10.6.0.11', 'port' => 26379},
   {'host' => '10.6.0.12', 'port' => 26379},
   {'host' => '10.6.0.13', 'port' => 26379},
]

# Gitaly Cluster
## 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.40' # 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'] = ['*'] * 2

## 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.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'

# 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を再設定してください。

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

    sudo gitlab-ctl status

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

    run: consul: (pid 30114) 77353s; run: log: (pid 29756) 77367s
run: logrotate: (pid 9898) 3561s; run: log: (pid 29653) 77380s
run: node-exporter: (pid 30134) 77353s; run: log: (pid 29706) 77372s
run: sidekiq: (pid 30142) 77351s; run: log: (pid 29638) 77386s
note
環境のSidekiqジョブ処理が長いキューで遅い場合は、必要に応じてノードを追加できます。また、複数のSidekiqプロセスを実行するようにSidekiqノードをチューニングすることもできます。

GitLab Railsの設定

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

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

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

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

  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
## Must be the same in every sentinel node
redis['master_name'] = 'gitlab-redis'
   
## The same password for Redis authentication you set up for the Redis primary node.
redis['master_password'] = '<redis_primary_password>'
   
## A list of sentinels with `host` and `port`
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.6.0.11', 'port' => 26379},
  {'host' => '10.6.0.12', 'port' => 26379},
  {'host' => '10.6.0.13', 'port' => 26379}
]
   
## Enable service discovery for Prometheus
consul['enable'] = true
consul['monitoring_service_discovery'] =  true
   
# 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'
sidekiq['listen_address'] = "0.0.0.0"
puma['listen'] = '0.0.0.0'
   
## 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),
}
   
# 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.81/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
   
## Uncomment and edit the following options if you have set up NFS
##
## Prevent GitLab from starting if NFS data mounts are not available
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## Ensure UIDs and GIDs match between servers for permissions via NFS
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002
   
# 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. 設定した最初のLinuxパッケージノードからSSHホストキー（すべて名前形式/etc/ssh/ssh_host_*_key* ）をコピーし、このサーバに同じ名前のファイルを追加または置き換えます。こうすることで、ユーザーが負荷分散されたRailsノードにアクセスしたときにホストの不一致エラーが発生しないようになります。これが最初に設定するLinuxパッケージノードである場合は、この手順を省略できます。

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

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

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

  7. 変更を有効にするには、GitLabを再設定してください。
  8. インクリメンタルロギングを有効にします。
  9. sudo gitlab-rake gitlab:gitaly:check を実行し、ノードが Gitaly に接続できることを確認します。

  10. リクエストを確認するためにログを見てください：

    sudo gitlab-ctl tail gitaly

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

    sudo gitlab-ctl status

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

    run: consul: (pid 4890) 8647s; run: log: (pid 29962) 79128s
run: gitlab-exporter: (pid 4902) 8647s; run: log: (pid 29913) 79134s
run: gitlab-workhorse: (pid 4904) 8646s; run: log: (pid 29713) 79155s
run: logrotate: (pid 12425) 1446s; run: log: (pid 29798) 79146s
run: nginx: (pid 4925) 8646s; run: log: (pid 29726) 79152s
run: node-exporter: (pid 4931) 8645s; run: log: (pid 29855) 79140s
run: puma: (pid 4936) 8645s; run: log: (pid 29656) 79161s

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

GitLab Railsの事後設定

  1. すべてのマイグレーションが実行されたことを確認します：

    gitlab-rake gitlab:db:configure

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

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

Prometheus の設定

Linuxパッケージを使用して、Prometheusと Grafanaを実行するスタンドアロンの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に設定します。

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

    sudo gitlab-ctl status

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

    run: consul: (pid 31637) 17337s; run: log: (pid 29748) 78432s
run: grafana: (pid 31644) 17337s; run: log: (pid 29719) 78438s
run: logrotate: (pid 31809) 2936s; run: log: (pid 29581) 78462s
run: nginx: (pid 31665) 17335s; run: log: (pid 29556) 78468s
run: prometheus: (pid 31672) 17335s; run: log: (pid 29633) 78456s

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

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クラスターを設定する方法についての推奨ベストプラクティスについては、最適なクラスター設定の選び方をお読みください。

ユーザー数が少ない場合にサポートされる変更点(HA)

3,000ユーザーのGitLabリファレンスアーキテクチャは、High Availability(HA)を達成するために私たちが推奨する最小のものです。しかし、より少ないユーザー数でHAをメンテナーする必要がある環境では、このアーキテクチャにいくつかの変更を加えることで、複雑さとコストを減らすことができます。

GitLabでHAを実現するためには、3,000ユーザーアーキテクチャの構成が最終的に必要であることに留意すべきです。各コンポーネントには様々な考慮事項や従うべきルールがあり、3,000ユーザーアーキテクチャはこれら全てを満たしています。このアーキテクチャの小規模なバージョンも基本的には同じですが、パフォーマンス要件が小さいため、以下のようないくつかの変更が考えられます：

  • ノードのスペックを下げるノード仕様の引き下げ：ユーザー数に応じて、提案されているすべてのノード仕様を希望に応じて引き下げることができます。ただし、一般的な要件より低くしないことをお勧めします。
  • 選択したノードの組み合わせ：一部のノードを組み合わせることで、パフォーマンスを犠牲にしながらも複雑さを軽減できます：
    • GitLab RailsとSidekiqです：Sidekiqノードを削除し、代わりにGitLab Railsノードでコンポーネントを有効にすることができます。
    • PostgreSQLとPgBouncer：PgBouncerノードを削除し、代わりに内部ロードバランサが指すPostgreSQLノードで有効にすることができます。しかし、データベースのロードバランシングを有効にするには、別のPgBouncer配列が必要です。
  • ノード数の削減：ノードの種類によってはコンセンサスを必要とせず、より少ないノード数（ただし冗長性のために1つ以上）で動作させることができます。これはパフォーマンスの低下にもつながります。
    • GitLab RailsとSidekiq：ステートレスサービスには最小ノード数はありません。冗長性のためには2つあれば十分です。
    • PostgreSQLとPgBouncer：クォーラムは厳密には必要ありません。2つのPostgreSQLノードと2つのPgBouncerノードで冗長性は十分です。
  • 評判の良いCloud PaaSソリューションで一部のコンポーネントを実行：GitLabセットアップの一部のコンポーネントは、代わりにクラウドプロバイダーのPaaSソリューションで実行することができます。こうすることで、追加の依存コンポーネントを削除することもできます：
    • PostgreSQL：PostgreSQL: Google Cloud SQLやAmazon RDSのような評判の良いクラウドPaaSソリューション上で実行することができます。このセットアップでは、PgBouncerとConsulノードは必要ありません：
      • Prometheusの自動検出が必要な場合はConsulが必要ですが、そうでない場合は手動で全てのノードにスクレイプ設定を追加する必要があります。
        • このアーキテクチャではRedis SentinelはConsulと同じボックスで実行されるため、RedisがLinuxパッケージを使用して実行されている場合は別のボックスで実行する必要があるかもしれません。
    • Redis：Google MemorystoreやAWS ElastiCacheなどの評判の良いクラウドPaaSソリューションで実行できます。このセットアップでは、Redis Sentinelはもはや必要ありません。

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とメモリ
ウェブサービス216 vCPU、14.4 GBメモリn1-highcpu-16c5.4xlarge31.8 vCPU、24.8 GBメモリ
Sidekiq34 vCPU、15 GB メモリn1-standard-4m5.xlarge11.8 vCPU、38.9 GBメモリ
サポートサービス22 vCPU、7.5 GBメモリn1-standard-2m5.large3.9 vCPU、11.8 GBメモリ
  • このセットアップでは、Google Kubernetes Engine(GKE)とAmazon Elastic Kubernetes Service(EKS)を推奨し、定期的にテストしています。他のKubernetesサービスでも動作する可能性がありますが、お客様のご判断によります。
  • ポッドvCPU/メモリ比率を確保し、パフォーマンステスト中のスケーリングを回避するため、ポッドの設定を示しています。
    • 本番デプロイでは、ポッドを特定のノードに割り当てる必要はありません。レジリエントなクラウドアーキテクチャのプラクティスに合わせるため、3つの異なるアベイラビリティゾーンにノードグループごとに最低3つのノードを配置することを強く推奨します。

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

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

リソース使用設定

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

ウェブサービス

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

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

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

Sidekiq

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

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

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

サポート

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

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

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