正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

リファレンスアーキテクチャ: 最大200 RPSまたは10,000ユーザー

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed

このページでは、実際のデータに基づいて、手動および自動化された最大10,000ユーザーの一般的なピーク負荷である、200 RPS（1秒あたりのリクエスト数）のピーク負荷をターゲットとするように設計されたGitLabのリファレンスアーキテクチャについて説明します。

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

このアーキテクチャをデプロイする前に、最初にメインドキュメント 、特に始める前にと使用するアーキテクチャの決定のセクションをお読みになることをお勧めします。

  • Target load（ターゲット負荷）: API: 200 RPS、Web: 20 RPS、Git（プル）: 20 RPS、Git（プッシュ）: 4 RPS
  • High Availability: はい（Praefectには、HAのためにサードパーティのPostgreSQLソリューションが必要です）
  • Cloud Native Hybrid Alternative（クラウドネイティブハイブリッドの代替）: はい
  • Unsure which Reference Architecture to use（どのリファレンスアーキテクチャを使用すればよいかわからない場合）?詳細については、こちらのドキュメントをご覧ください。
サービスノード設定GCPの例1AWSの例1Azureの例1
外部ロードバランサー414 vCPU、3.6 GBメモリn1-highcpu-4c5n.xlargeF4s v2
Consul232 vCPU、1.8 GBメモリn1-highcpu-2c5.largeF2s v2
PostgreSQL238 vCPU、30 GBのメモリn1-standard-8m5.2xlargeD8s v3
PgBouncer232 vCPU、1.8 GBメモリn1-highcpu-2c5.largeF2s v2
内部ロードバランサー414 vCPU、3.6 GBメモリn1-highcpu-4c5n.xlargeF4s v2
Redis/Sentinel - キャッシュ334 vCPU、15 GBメモリn1-standard-4m5.xlargeD4s v3
Redis/Sentinel - 永続334 vCPU、15 GBメモリn1-standard-4m5.xlargeD4s v3
Gitaly67316 vCPU、60 GBのメモリn1-standard-16m5.4xlargeD16s v3
Praefect632 vCPU、1.8 GBメモリn1-highcpu-2c5.largeF2s v2
Praefect PostgreSQL21+2 vCPU、1.8 GBメモリn1-highcpu-2c5.largeF2s v2
Sidekiq844 vCPU、15 GBメモリn1-standard-4m5.xlargeD4s v3
GitLab Rails8332 vCPU、28.8 GBのメモリn1-highcpu-32c5.9xlargeF32s v2
モニタリングノード14 vCPU、3.6 GBメモリn1-highcpu-4c5.xlargeF4s v2
オブジェクトストレージ5–––––

Footnotes（補足説明）:

  1. マシンタイプの例は、説明目的で提供されています。これらのタイプは、検証とテストで使用されていますが、推奨されるデフォルトとして意図されたものではありません。リストされている要件を満たす他のマシンタイプへの切り替え（利用可能な場合はARMバリアントを含む）がサポートされています。詳細については、サポートされているマシンタイプを参照してください。
  2. 定評のあるサードパーティの外部PaaS PostgreSQLソリューションでオプションで実行できます。詳細については、独自のPostgreSQLインスタンスを提供すると推奨クラウドプロバイダーとサービスを参照してください。
  3. 定評のあるサードパーティの外部PaaS Redisソリューションでオプションで実行できます。詳細については、独自のRedisインスタンスを提供すると推奨されるクラウドプロバイダーとサービスを参照してください。
    • Redisは主にシングルスレッドであり、CPUコアを増やしても大きなメリットは得られません。このサイズのアーキテクチャでは、最適なパフォーマンスを実現するために、指定された個別のキャッシュインスタンスと永続インスタンスを構成することを強くお勧めします。
  4. HA機能を提供できる定評のあるサードパーティのロードバランサーまたはサービス（LB PaaS）で実行することをおすすめします。サイジングは、選択したロードバランサーと、ネットワーク帯域幅などの追加要因によって異なります。詳細については、ロードバランサーを参照してください。
  5. 定評のあるクラウドプロバイダーまたはSelf-Managedソリューションで実行する必要があります。詳細については、オブジェクトストレージを設定するを参照してください。
  6. Gitalyクラスター（Praefect）は、耐障害性の利点を提供しますが、セットアップと管理がさらに複雑になります。Gitaly Cluster (Praefect)をデプロイする前に、既存の技術的な制限事項と考慮事項を確認してください。シャーディングされたGitalyが必要な場合は、上記の表にリストされているGitalyと同じ仕様を使用してください。
  7. Gitalyの仕様は、正常に稼働する環境での利用パターンとリポジトリサイズの上位パーセンタイルに基づいています。ただし、（数ギガバイトを超える）大規模なモノレポまたは追加のワークロードがある場合、これらはGitおよびGitalyのパフォーマンスに大幅に影響を与えることがあり、さらなる調整が必要になる場合があります。
  8. コンポーネントはステートフルデータを保存しないため、Auto Scaling Groups（ASG）に配置できます。ただし、クラウドネイティブハイブリッドセットアップが一般的に推奨されます。移行やMailroomなどの特定のコンポーネントは、1つのノードでしか実行できないためであり、これらのコンポーネントは、Kubernetesでより適切に処理されます。

インスタンスの設定を含むすべてのPaaSソリューションについては、回復力のあるクラウドアーキテクチャプラクティスに合わせて、3つの異なる可用性ゾーンに最低3つのノードを実装することをおすすめします。

@startuml 10k
skinparam linetype ortho

card "**External Load Balancer**" as elb #6a9be7
card "**Internal Load Balancer**" as ilb #9370DB

together {
  collections "**GitLab Rails** x3" as gitlab #32CD32
  collections "**Sidekiq** x4" as sidekiq #ff8dd1
}

together {
  card "**Prometheus**" as monitor #7FFFD4
  collections "**Consul** x3" as consul #e76a9b
}

card "Gitaly Cluster" as gitaly_cluster {
  collections "**Praefect** x3" as praefect #FF8C00
  collections "**Gitaly** x3" as gitaly #FF8C00
  card "**Praefect PostgreSQL***\n//Non fault-tolerant//" as praefect_postgres #FF8C00

  praefect -[#FF8C00]-> gitaly
  praefect -[#FF8C00]> praefect_postgres
}

card "Database" as database {
  collections "**PGBouncer** x3" as pgbouncer #4EA7FF
  card "**PostgreSQL** //Primary//" as postgres_primary #4EA7FF
  collections "**PostgreSQL** //Secondary// x2" as postgres_secondary #4EA7FF

  pgbouncer -[#4EA7FF]-> postgres_primary
  postgres_primary .[#4EA7FF]> postgres_secondary
}

card "redis" as redis {
  collections "**Redis Persistent** x3" as redis_persistent #FF6347
  collections "**Redis Cache** x3" as redis_cache #FF6347

  redis_cache -[hidden]-> redis_persistent
}

cloud "**Object Storage**" as object_storage #white

elb -[#6a9be7]-> gitlab
elb -[#6a9be7,norank]--> monitor

gitlab -[#32CD32,norank]--> ilb
gitlab -[#32CD32]r-> object_storage
gitlab -[#32CD32]----> redis
gitlab .[#32CD32]----> database
gitlab -[hidden]-> monitor
gitlab -[hidden]-> consul

sidekiq -[#ff8dd1,norank]--> ilb
sidekiq -[#ff8dd1]r-> object_storage
sidekiq -[#ff8dd1]----> redis
sidekiq .[#ff8dd1]----> database
sidekiq -[hidden]-> monitor
sidekiq -[hidden]-> consul

ilb -[#9370DB]--> gitaly_cluster
ilb -[#9370DB]--> database
ilb -[hidden]--> redis
ilb -[hidden]u-> consul
ilb -[hidden]u-> monitor

consul .[#e76a9b]u-> gitlab
consul .[#e76a9b]u-> sidekiq
consul .[#e76a9b]r-> monitor
consul .[#e76a9b]-> database
consul .[#e76a9b]-> gitaly_cluster
consul .[#e76a9b,norank]--> redis

monitor .[#7FFFD4]u-> gitlab
monitor .[#7FFFD4]u-> sidekiq
monitor .[#7FFFD4]> consul
monitor .[#7FFFD4]-> database
monitor .[#7FFFD4]-> gitaly_cluster
monitor .[#7FFFD4,norank]--> redis
monitor .[#7FFFD4]> ilb
monitor .[#7FFFD4,norank]u--> elb

@enduml

要件

続行する前に、リファレンスアーキテクチャの要件を確認してください。

テスト手法

200 RPS / 10,000ユーザーのリファレンスアーキテクチャは、もっとも一般的なワークフローに対応するように設計されています。GitLabは、次のエンドポイントスループットの目標に対して、定期的にスモークテストとパフォーマンステストを実施しています:

エンドポイントの種類目標スループット
API200 RPS
Web20 RPS
Git（プル）20 RPS
Git（プッシュ）4 RPS

これらの目標は、CIパイプラインやその他のワークロードを含む、指定されたユーザー数に対する環境負荷の合計を反映した、実際の顧客データに基づいています。

テスト手法の詳細については、検証とテストの結果セクションを参照してください。

パフォーマンスに関する考慮事項

環境に次の要素がある場合、追加の調整が必要になるかもしれません:

これらの場合は、詳細について環境をスケーリングするを参照してください。これらの考慮事項がお客様にあてはまると思われる場合は、必要に応じて追加のガイダンスについてお問い合わせください。

ロードバランサーの設定

当社のテスト環境では、以下を使用します:

  • Linuxパッケージ環境用のHAProxy
  • クラウドネイティブハイブリッド用のNGINX Ingressと同等のクラウドプロバイダー

コンポーネントをセットアップする

GitLabとそのコンポーネントをセットアップして、最大200 RPSまたは10,000ユーザーに対応するには、次の手順に従います:

  1. GitLabアプリケーションサービスノードのロードバランシングを処理するために、外部ロードバランサーを設定します。
  2. GitLabアプリケーション内部接続のロードバランシングを処理するために、内部ロードバランサーを設定します。
  3. サービスディスカバリとヘルスチェックのためにConsulを設定します。
  4. GitLabのデータベースであるPostgreSQLを設定します。
  5. データベース接続プーリングと管理のためにPgBouncerを設定します。
  6. セッションデータ、一時キャッシュ情報、バックグラウンドジョブキューを保存するRedisを設定します。
  7. Gitリポジトリへのアクセスを提供するGitalyクラスター（Praefec）を設定します。
  8. バックグラウンドジョブの処理のためにSidekiqを設定します。
  9. Puma、Workhorse、GitLab Shellを実行して、すべてのフロントエンドリクエスト（UI、API、およびHTTP/SSH経由のGitを含む）を処理するために、メインのGitLab Railsアプリケーションを設定します。
  10. GitLab環境をモニタリングするために、Prometheusを設定します。
  11. 共有データオブジェクトに使用されるオブジェクトストレージを設定します。
  12. GitLabインスタンス全体でより高速かつ高度なコード検索を行うために、高度な検索を設定します。

サーバーは同じ10.6.0.0/24プライベートネットワーク範囲で起動し、これらのアドレスで自由に相互接続できます。

次のリストには、各サーバーとその割り当て済みIPの詳細が含まれています:

  • 10.6.0.10: 外部ロードバランサー
  • 10.6.0.11: Consul 1
  • 10.6.0.12: Consul 2
  • 10.6.0.13: Consul 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: PgBouncer 2
  • 10.6.0.33: PgBouncer 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: Gitaly 2
  • 10.6.0.93: Gitaly 3
  • 10.6.0.131: Praefect 1
  • 10.6.0.132: Praefect 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.151: Prometheus

外部ロードバランサーを設定する

マルチノード設定のGitLabでは、外部ロードバランサーを使用して、トラフィックをアプリケーションサーバーにルーティングする必要があります。

どのロードバランサーを使用するか、またはその正確な設定の詳細はGitLabドキュメントのスコープ外ですが、一般的な要件に関する詳細については、ロードバランサーを参照してください。このセクションでは、選択したロードバランサーに対して設定する内容の詳細について説明します。

準備完了チェック

外部ロードバランサーが、組み込みのモニタリングエンドポイントを使用して、動作中のサービスにのみルーティングするようにします。すべての準備完了チェックには、チェックされるノードに追加の設定が必要です。そうしないと、外部ロードバランサーは接続できません。

ポート

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

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

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

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

代替SSHポート

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

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

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

SSL

次の課題は、ご使用の環境でSSLをどのように処理するかです。次のようないくつかの選択肢があります:

アプリケーションノードがSSLを終了する

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

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

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

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

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

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

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

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

内部ロードバランサーを設定する

マルチノード設定のGitLabでは、PgBouncerやGitaly Cluster (Praefect)への接続など、選択した内部コンポーネントへのトラフィックをルーティングするための内部ロードバランサーが必要になります。

どのロードバランサーを使用するか、またはその正確な設定の詳細は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サーバーをセットアップします。

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

次のIPを例として使用します:

  • 10.6.0.11: Consul 1
  • 10.6.0.12: Consul 2
  • 10.6.0.13: Consul 3

Consulを設定するには、次の手順に従います:

  1. ConsulをホスティングするサーバーにSSHで接続します。

  2. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。現在のインストールと同じバージョンとタイプ（Community EditionまたはEnterprise Edition）を選択します。

  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からデフォルトで有効になっているロードバランシングとincompatible（互換性がありません）。

詳細については、推奨されるクラウドプロバイダーとサービスを参照してください。

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

  1. HA LinuxパッケージPostgreSQLのセットアップには、PostgreSQL、PgBouncer、およびConsulが含まれます。サードパーティの外部サービスを使用する場合、これらのコンポーネントは不要になります。
  2. データベース要件に関するドキュメントに従ってPostgreSQLをセットアップします。
  3. 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

まず、on each node（各ノードに）Linux GitLabパッケージをインストールしてください。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。ただし、EXTERNAL_URL値はnot（指定しないでください）。

PostgreSQLノード

  1. いずれかのPostgreSQLノードに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. すべてのデータベースノードで、/etc/gitlab/gitlab.rbを編集し、# START user configurationセクションに記載されている値を置き換えます:

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

PostgreSQLでは、Patroniがフェイルオーバーを管理している場合、pg_rewindを使用してデフォルトで競合を処理します。ほとんどのフェイルオーバー処理方法と同様に、これによりデータ損失が発生する可能性がわずかにあります。詳細については、さまざまなPatroniレプリケーション方法を参照してください。

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

  2. 変更を有効にするには、GitLabを再設定します。

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

PostgreSQLの設定後の手順

primary site（プライマリサイト）のいずれかの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         | *               |

ノードの「状態」列に「実行中」と表示されない場合は、続行する前にPostgreSQLレプリケーションとフェイルオーバーのトラブルシューティングセクションを確認してください。

PgBouncerを設定する

PostgreSQLサーバーのセットアップが完了したので、プライマリデータベースの読み取り/書き込みを追跡および処理するPgBouncerを設定しましょう。

PgBouncerはシングルスレッドであり、CPUコアを増やしても大きなメリットは得られません。詳細については、スケーリングに関するドキュメントを参照してください。

次のIPを例として使用します:

  • 10.6.0.31: PgBouncer 1
  • 10.6.0.32: PgBouncer 2
  • 10.6.0.33: PgBouncer 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]が発生した場合、これは既存の既知の問題が原因です。これは、次の手順の後に2回目のreconfigureを実行すると解決されます。

  4. .pgpassファイルを作成して、ConsulがPgBouncerを再読み込みできるようにします。求められたら、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をスケーラブルな環境で使用するには、Redis SentinelサービスでプライマリxReplica（レプリカ）トポロジーを使用して、フェイルオーバーを監視し、フェイルオーバー手順を自動的に開始します。

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

Redisは主にシングルスレッドであり、CPUコアを増やしても大きなメリットは得られません。このサイズのアーキテクチャでは、最適なパフォーマンスを実現するために、指定された個別のキャッシュインスタンスと永続インスタンスを構成することを強くお勧めします。詳細については、スケーリングに関するドキュメントを参照してください。

Sentinelと併用する場合、Redisは認証を必要とします。詳細については、Redisのセキュリティドキュメントを参照してください。Redisサービスを保護するには、Redisパスワードと厳格なファイアウォールルールの組み合わせを使用することをおすすめします。トポロジーとアーキテクチャを十分に理解するために、GitLabでRedisを設定する前に、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クラスターモードは特にサポートされていませんが、HAのRedisスタンドアロンはサポートされています。
  • セットアップに従って、Redis削除モードを設定する必要があります。

詳細については、推奨されるクラウドプロバイダーとサービスを参照してください。

Redisキャッシュクラスターを構成します

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

プライマリRedisおよびレプリカRedisノードの両方には、redis['password']で定義した同じパスワードが必要です。フェイルオーバー中、Sentinelはノードを再設定し、その状態をプライマリからレプリカ（またはその逆）に変更できます。

プライマリRedisキャッシュノードを構成します

  1. プライマリRedisサーバーにSSHで接続します。

  2. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。現在のインストールと同じバージョンとタイプ（Community EditionまたはEnterprise Edition）を選択します。

  3. /etc/gitlab/gitlab.rbを編集し、次の内容を追加します:

    # Specify server roles as 'redis_master_role' with sentinel and 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 must 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キャッシュノードを構成します

  1. replica（レプリカ）RedisサーバーにSSHで接続します。

  2. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。現在のインストールと同じバージョンとタイプ（Community EditionまたはEnterprise Edition）を選択します。

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

    # Specify server roles as 'redis_sentinel_role' and 'redis_replica_role'
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 must 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

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

  5. 変更を有効にするには、GitLabを再設定します。

  6. 他のすべてのレプリカノードに対して手順を繰り返し、IPアドレスが正しく設定されていることを確認してください。

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

Redis永続クラスターを構成します

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

プライマリRedisおよびレプリカRedisノードの両方には、redis['password']で定義した同じパスワードが必要です。フェイルオーバー中、Sentinelはノードを再設定し、その状態をプライマリからレプリカ（またはその逆）に変更できます。

プライマリRedis永続ノードを構成します

  1. プライマリRedisサーバーにSSHで接続します。

  2. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。現在のインストールと同じバージョンとタイプ（Community EditionまたはEnterprise Edition）を選択します。

  3. /etc/gitlab/gitlab.rbを編集し、次の内容を追加します:

    # Specify server roles as 'redis_master_role' with Sentinel and 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 must 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永続ノードを構成します

  1. replica（レプリカ）Redis永続サーバーにSSH接続します。

  2. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。現在のインストールと同じバージョンとタイプ（Community EditionまたはEnterprise Edition）を選択します。

  3. /etc/gitlab/gitlab.rbを編集し、次の内容を追加します:

    # Specify server roles as 'redis_sentinel_role' and 'redis_replica_role'
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 must 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 Cluster (Praefect)を設定する

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

Gitalyの仕様は、正常に稼働する環境での利用パターンとリポジトリサイズの上位パーセンタイルに基づいています。ただし、（数ギガバイトを超える）大規模なモノレポまたはワークロードの追加がある場合、これらは環境のパフォーマンスに大きく影響することがあり、さらなる調整が必要になる場合があります。これがあてはまると思われる場合は、必要に応じて追加のガイダンスについてお問い合わせください。

Gitalyクラスター（Praefect）は、耐障害性の利点を提供しますが、セットアップと管理がさらに複雑になります。Gitaly Cluster (Praefect)をデプロイする前に、既存の技術的な制限事項と考慮事項を確認してください。

各ガイダンス:

  • シャーディングされたGitalyを実装する場合は、このセクションではなく、個別のGitalyドキュメントに従ってください。同じGitaly仕様を使用します。
  • Gitaly Cluster (Praefect)で管理されていない既存のリポジトリを移行する場合は、Gitaly Cluster (Praefect)に移行するを参照してください。

推奨されるクラスターのセットアップには、次のコンポーネントが含まれています:

  • 3つのGitalyノード: Gitリポジトリのレプリケートされるストレージ。
  • 3つのPraefectノード: Gitaly Cluster (Praefect)のルーターおよびトランザクションマネージャー。
  • 1つのPraefect PostgreSQLノード: Praefectのデータベースサーバー。Praefectデータベース接続をHAにするには、サードパーティ製のソリューションが必要です。
  • 1つのロードバランサー: Praefectにはロードバランサーが必要です。内部ロードバランサーが使用されます。

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

Praefect PostgreSQLを設定する

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

HAセットアップが必要な場合、PraefectにはサードパーティのPostgreSQLデータベースが必要です。組み込みソリューションの開発が進行中です。

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

次のIPを例として使用します:

  • 10.6.0.141: Praefect PostgreSQL

まず、Praefect PostgreSQLノードにLinuxパッケージをインストールしてください。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。ただし、EXTERNAL_URL値はnot（指定しないでください）。

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

  2. Praefect PostgreSQLのユーザーに対して使用する強力なパスワードを作成します。このパスワードを<praefect_postgresql_password>として書き留めてください。

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

    sudo gitlab-ctl pg-password-md5 praefect

  4. /etc/gitlab/gitlab.rbを編集し、# START user configurationセクションに記載されている値を置き換えます:

    # 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機能がサポートされている必要があります。

サードパーティのセットアップでは、Geoを使用している場合を除き、メインのGitLabデータベースと同じサーバー上にPraefectのデータベースを配置できます。Geoでは、レプリケーションを正しく処理するために個別のデータベースインスタンスが必要です。このセットアップでは、影響は最小限であるため、メインデータベースのセットアップの仕様を変更する必要はありません。

そのためには、信頼できるプロバイダーまたはソリューションを使用する必要があります。Google Cloud SQLとAmazon RDSは動作が確認されています。ただし、Amazon Auroraは、14.4.0からデフォルトで有効になっているロードバランシングとincompatible（互換性がありません）。

詳細については、推奨されるクラウドプロバイダーとサービスを参照してください。

データベースを設定したら、設定後の手順に従ってください。

Praefect PostgreSQLの設定後の手順

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

ユーザー名をpraefectに、データベース名をpraefect_productionにすることをおすすめします。これらはPostgreSQLで標準として設定できます。ユーザーのパスワードは、以前に<praefect_postgresql_password>として設定したパスワードと同じです。

これをLinuxパッケージPostgreSQLセットアップで実行する方法は次のとおりです:

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

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

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

  3. 新しいユーザーpraefectを作成し、<praefect_postgresql_password>を置き換えます:

    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クラスター（Praefect）のルーターおよびトランザクションマネージャーであり、Gitalyへのすべての接続はPraefectを通過します。このセクションでは、その設定方法について詳しく説明します。

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

Praefectでは、クラスター全体で接続を保護するために、いくつかのシークレットトークンが必要です:

  • <praefect_external_token>: Gitalyクラスター（Praefect）でホスティングされているリポジトリに使用され、このトークンを持つGitalyクライアントのみがアクセスできます。
  • <praefect_internal_token>: Gitaly Cluster (Praefect)内のレプリケーションのトラフィックに使用されます。GitalyクライアントがGitaly Cluster (Praefect)の内部ノードに直接アクセスできないようにする必要があるため、praefect_external_tokenとは異なるものを使用します。そうしないと、データが失われる可能性があります。
  • <praefect_postgresql_password>: このセットアップの一部として、前のセクションで定義したPraefect PostgreSQLのパスワードも必要です。

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

次のIPを例として使用します:

  • 10.6.0.131: Praefect 1
  • 10.6.0.132: Praefect 2
  • 10.6.0.133: Praefect 3

Praefectノードを設定するには、各ノードで次の手順を実行します:

  1. PraefectサーバーにSSHで接続します。

  2. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。

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

    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
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,
      dbname: 'praefect_production',
      user: 'praefect',
      password: '<praefect_postgresql_password>',
   },
   # Praefect Virtual Storage config
   # Name of storage hash must match storage name in gitlab_rails['repositories_storages'] 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

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

  5. Praefectでは、メインのGitLabアプリケーションと同様に、いくつかのデータベース移行を実行する必要があります。そのためには、one Praefect node only to run the migrations（移行を実行するPraefectノードを1つだけ）選択する必要があります。これは、_デプロイノード_とも呼ばれます。このノードは、次の手順に従って、他のノードよりも先に設定する必要があります:

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

    2. データベースの移行が再設定中にのみ実行され、アップグレード時に自動的に実行されないようにするには、以下を実行します:

    sudo touch /etc/gitlab/skip-auto-reconfigure
    1. 変更を有効にし、Praefectデータベースの移行を実行するために、GitLabを再設定します。

  6. 他のすべてのPraefectノードで、変更を反映させるために、GitLabを再設定します。

Gitalyを設定する

クラスターを構成するGitalyサーバーノードには、データと負荷に応じた要件があります。

Gitalyの仕様は、正常に稼働する環境での利用パターンとリポジトリサイズの上位パーセンタイルに基づいています。ただし、（数ギガバイトを超える）大規模なモノレポまたはワークロードの追加がある場合、これらは環境のパフォーマンスに大きく影響することがあり、さらなる調整が必要になる場合があります。これがあてはまると思われる場合は、必要に応じて追加のガイダンスについてお問い合わせください。

Gitalyには、Gitalyストレージに関する特定のディスク要件があります。

Gitalyのネットワークトラフィックはデフォルトで暗号化されていないため、Gitalyサーバーをパブリックインターネットに公開しないでください。ファイアウォールを使用してGitalyサーバーへのアクセスを制限することを強くおすすめします。別のオプションは、TLSを使用することです。

Gitalyを設定する際には、次の点に注意してください:

  • 特定のGitalyノードのストレージパスを反映するようにgitaly['configuration'][:storage]を設定する必要がある
  • auth_tokenはpraefect_internal_tokenと同じである必要がある

次のIPを例として使用します:

  • 10.6.0.91: Gitaly 1
  • 10.6.0.92: Gitaly 2
  • 10.6.0.93: Gitaly 3

各ノードで、次のようにします:

  1. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。ただし、EXTERNAL_URL値はnot（指定しないでください）。

  2. Gitalyサーバーノードの/etc/gitlab/gitlab.rbファイルを編集して、ストレージパスを設定し、ネットワークリスナーを有効にして、トークンを設定します:

    # https://docs.gitlab.com/omnibus/roles/#gitaly-roles
roles(["gitaly_role"])

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

# 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

  3. それぞれのサーバーについて、次の内容を/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',
      },
   ],
}

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

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

Gitaly Cluster (Praefect)のTLSサポート

PraefectはTLS暗号化をサポートしています。セキュアな接続をリッスンするPraefectインスタンスと通信するには、次のことを行う必要があります:

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

さらに、証明書またはその認証局は、GitLabカスタム証明書の設定で説明されている手順に従って、すべてのGitalyサーバー、およびこのサーバーと通信するすべてのPraefectクライアントにインストールする必要があります。

次の点に注意してください:

  • 証明書は、Praefectサーバーへのアクセスに使用するアドレスを指定する必要があります。ホスト名またはIPアドレスをサブジェクトの別名（SAN）として証明書に追加する必要があります。
  • Praefectサーバーは、暗号化されていないリスニングアドレスlisten_addrと暗号化されたリスニングアドレスtls_listen_addrの両方で同時に設定できます。これにより、必要に応じて、暗号化されていないトラフィックから暗号化されたトラフィックへの段階的な移行を行うことができます。暗号化されていないリスナーを無効にするには、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のgitlab_rails['repositories_storages']を次のように編集します:

    gitlab_rails['repositories_storages'] = {
  "default" => {
    "gitaly_address" => 'tls://LOAD_BALANCER_SERVER_ADDRESS:3305',
    "gitaly_token" => 'PRAEFECT_EXTERNAL_TOKEN'
  }
}

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

Sidekiqを設定する

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

データオブジェクトに対しては、NFSの代わりに、オブジェクトストレージを使用することが推奨されるため、次の例にはオブジェクトストレージの設定が含まれています。

環境のSidekiqジョブの処理に時間がかかり、キューが長い場合は、それに応じてスケールできます。詳細については、スケーリングに関するドキュメントを参照してください。

コンテナレジストリ、SAML、LDAPなどの追加のGitLab機能を設定する場合は、Rails設定に加えて、Sidekiq設定も更新します。詳細については、外部Sidekiqのドキュメントを参照してください。

  • 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. PostgreSQL、Gitaly、およびRedisポートにアクセスできることを確認します:

    telnet <GitLab host> 5432 # PostgreSQL
telnet <GitLab host> 8075 # Gitaly
telnet <GitLab host> 6379 # Redis

  3. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。

  4. /etc/gitlab/gitlab.rbを作成または編集し、次の設定を使用します:

    # https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
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 Cluster
## gitlab_rails['repositories_storages'] gets configured for the Praefect virtual storage
## Address is the Internal Load Balancer for Praefect
## Token is the praefect_external_token
gitlab_rails['repositories_storages'] = {
  "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['listen_address'] = "0.0.0.0"

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

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

gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "<gcp-ci_secure_files-bucket-name>"

gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

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

  6. データベースの移行が再設定中にのみ実行され、アップグレード時に自動的に実行されないようにするには、以下を実行します:

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

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

  7. 変更を有効にするには、GitLabを再設定します。

GitLab Railsを設定する

このセクションでは、GitLabアプリケーション（Rails）コンポーネントを設定する方法について説明します。

Railsには、Redis 、PostgreSQL 、およびGitalyインスタンスへの接続が必要です。また、推奨されているように、オブジェクトストレージへの接続も必要です。

データオブジェクトに対しては、NFSの代わりに、オブジェクトストレージを使用することが推奨されるため、次の例にはオブジェクトストレージの設定が含まれています。

次のIPを例として使用します:

  • 10.6.0.111: GitLabアプリケーション1
  • 10.6.0.112: GitLabアプリケーション2
  • 10.6.0.113: GitLabアプリケーション3

各ノードで、次の手順を実行します:

  1. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。

  2. /etc/gitlab/gitlab.rbを作成または編集し、次の設定を使用します。ノード間のリンクの一貫性を維持するため、アプリケーションサーバーのexternal_urlは、ユーザーがGitLabへのアクセスに使用する外部URLを指す必要があります。これは、GitLabアプリケーションサーバーへのトラフィックをルーティングする外部ロードバランサーのURLになります:

    external_url 'https://gitlab.example.com'

# gitlab_rails['repositories_storages'] gets configured for the Praefect virtual storage
# Address is the Internal Load Balancer for Praefect
# Token is the praefect_external_token
gitlab_rails['repositories_storages'] = {
  "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
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>"
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "<gcp-ci_secure_files-bucket-name>"

gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

  3. TLSサポートでGitalyを使用している場合は、gitlab_rails['repositories_storages']エントリが、tcpではなく、tlsで設定されていることを確認してください:

    gitlab_rails['repositories_storages'] = {
  "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. 最初に設定したRailsノードからSSHホストキー（すべて/etc/ssh/ssh_host_*_key*という名前形式）をコピーして、このサーバーに追加するか、サーバー上の同じ名前のファイルを置換します。これにより、ユーザーがロードバランシングされたRailsノードにアクセスしたときに、ホストの不一致エラーが発生しなくなります。これが最初に設定するLinuxパッケージノードである場合は、この手順をスキップできます。

  6. データベースの移行が再設定中にのみ実行され、アップグレード時に自動的に実行されないようにするには、以下を実行します:

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

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

  7. 変更を有効にするには、GitLabを再設定します。

  8. 増分ログの生成を有効にします。

  9. を実行して、ノードがGitalyに接続できることを確認します:

    sudo gitlab-rake gitlab:gitaly:check

    ログを追跡してリクエストを確認します:

    sudo gitlab-ctl tail gitaly

  10. オプションで、Gitalyサーバーから、Gitalyが内部APIへのコールバックを実行できることを確認します:

    • GitLab 15.3以降の場合は、sudo -u git -- /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.tomlを実行します。
    • GitLab 15.2以前の場合は、sudo -u git -- /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を実行するスタンドアロンモニタリングノードを設定できます。

次のIPを例として使用します:

  • 10.6.0.151: Prometheus

モニタリングノードを構成するには、次のようにします:

  1. モニタリングノードにSSHで接続します。

  2. 利用したいLinuxパッケージをダウンロードしてインストールします。必ずGitLabパッケージリポジトリのみを追加し、選択したオペレーティングシステム用にGitLabをインストールしてください。

  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

# 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['enable'] = false

  4. 変更を有効にするには、GitLabを再設定します。

オブジェクトストレージを設定する

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

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

可能な場合、次の例では統合された形式を使用します。

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コンポーネントをKubernetesで実行できます。次のサービスがサポートされています:

  • GitLab Rails
  • Sidekiq
  • NGINX
  • Toolbox
  • Migrations
  • Prometheus

ハイブリッドインストールは、クラウドネイティブと従来のコンピューティングデプロイの両方の利点を活用します。これにより、ステートレスコンポーネントはクラウドネイティブワークロード管理の利点を活用でき、ステートフルコンポーネントは、より永続性の高いLinuxパッケージインストールを備えたコンピューティング仮想マシンにデプロイされます。

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

これはadvanced（高度な）設定です。Kubernetesでサービスを実行することは、複雑であることがよく知られています。Kubernetesに関する十分な実務知識と経験がある場合にのみ、This setup is only recommended（この設定が推奨）されます。このセクションの残りの部分では、このことを前提としています。

Kubernetes上のGitalyの可用性、制限事項、デプロイに関する考慮事項については、Kubernetes上のGitalyを参照してください。

クラスタートポロジー

以下の表と図は、前述の通常の環境と同じ形式を使用して、ハイブリッド環境の詳細を示しています。

最初はKubernetesで実行されるコンポーネントです。これらはいくつかのノードグループにわたって実行されますが、最小CPUおよびメモリ要件が満たされている限り、必要に応じて全体的な構成を変更できます。

コンポーネントノードグループターゲットノードプールの合計GCPの例AWSの例
Webservice80 vCPU
100 GBのメモリ（リクエスト）
140 GBのメモリ（制限）		3 x n1-standard-323 x c5.9xlarge
Sidekiq12.6 vCPU
28 GBのメモリ（リクエスト）
56 GBのメモリ（制限）		4 x n1-standard-44 x m5.xlarge
サポートサービス8 vCPU
30 GBのメモリ		2 x n1-standard-42 x m5.xlarge
  • このセットアップでは、定期的なテストを行うほか、Google Kubernetes Engine（GKE）およびAmazon Elastic Kubernetes Service（EKS）を推奨しています。他のKubernetesサービスも機能する可能性がありますが、結果は異なる場合があります。
  • マシンタイプの例は、説明目的で提供されています。これらのタイプは、検証とテストで使用されていますが、推奨されるデフォルトとして意図されたものではありません。リストされている要件を満たす他のマシンタイプへの切り替えがサポートされています。詳細については、サポートされているマシンタイプを参照してください。
  • WebserviceおよびSidekiqのターゲットノードプールの合計は、GitLabコンポーネントに対してのみ提供されます。選択したKubernetesプロバイダーのシステムプロセスには、追加のリソースが必要です。例では、これを考慮に入れています。
  • サポート用ターゲットノードプールの合計は、通常、GitLabデプロイのサポートに必要ないくつかのリソースに加えて、要件に応じて実施する場合がある追加デプロイに対応するために提供されています。他のノードプールと同様に、選択したKubernetesプロバイダーのシステムプロセスにもリソースが必要です。例では、これを考慮に入れています。
  • 本番環境デプロイでは、ポッドを特定のノードに割り当てる必要はありません。ただし、回復力のあるクラウドアーキテクチャプラクティスに従って、異なる可用性ゾーンに分散された各プールにいくつかのノードを配置することをおすすめします。
  • 効率を高めるためにCluster Autoscalerなどのオートスケールを有効にすることをおすすめしますが、継続的なパフォーマンスを確保するために、WebserviceおよびSidekiqポッドの下限を75％程度にすることが推奨されています。

次は、Linuxパッケージ（または該当する場合は外部PaaSサービス）を使用して、静的コンピューティング仮想マシンで実行するバックエンドコンポーネントです:

サービスノード設定GCPの例1AWSの例1
Consul232 vCPU、1.8 GBメモリn1-highcpu-2c5.large
PostgreSQL238 vCPU、30 GBのメモリn1-standard-8m5.2xlarge
PgBouncer232 vCPU、1.8 GBメモリn1-highcpu-2c5.large
内部ロードバランサー414 vCPU、3.6 GBメモリn1-highcpu-4c5n.xlarge
Redis/Sentinel - キャッシュ334 vCPU、15 GBメモリn1-standard-4m5.xlarge
Redis/Sentinel - 永続334 vCPU、15 GBメモリn1-standard-4m5.xlarge
Gitaly67316 vCPU、60 GBのメモリn1-standard-16m5.4xlarge
Praefect632 vCPU、1.8 GBメモリn1-highcpu-2c5.large
Praefect PostgreSQL21+2 vCPU、1.8 GBメモリn1-highcpu-2c5.large
オブジェクトストレージ5––––

Footnotes（補足説明）:

  1. マシンタイプの例は、説明目的で提供されています。これらのタイプは、検証とテストで使用されていますが、推奨されるデフォルトとして意図されたものではありません。リストされている要件を満たす他のマシンタイプへの切り替え（利用可能な場合はARMバリアントを含む）がサポートされています。詳細については、サポートされているマシンタイプを参照してください。
  2. 定評のあるサードパーティの外部PaaS PostgreSQLソリューションでオプションで実行できます。詳細については、独自のPostgreSQLインスタンスを提供すると推奨クラウドプロバイダーとサービスを参照してください。
  3. 定評のあるサードパーティの外部PaaS Redisソリューションでオプションで実行できます。詳細については、独自のRedisインスタンスを提供すると推奨されるクラウドプロバイダーとサービスを参照してください。
    • Redisは主にシングルスレッドであり、CPUコアを増やしても大きなメリットは得られません。このサイズのアーキテクチャでは、最適なパフォーマンスを実現するために、指定された個別のキャッシュインスタンスと永続インスタンスを構成することを強くお勧めします。
  4. HA機能を提供できる定評のあるサードパーティのロードバランサーまたはサービス（LB PaaS）で実行することをおすすめします。サイジングは、選択したロードバランサーと、ネットワーク帯域幅などの追加要因によって異なります。詳細については、ロードバランサーを参照してください。
  5. 定評のあるクラウドプロバイダーまたはSelf-Managedソリューションで実行する必要があります。詳細については、オブジェクトストレージを設定するを参照してください。
  6. Gitalyクラスター（Praefect）は、耐障害性の利点を提供しますが、セットアップと管理がさらに複雑になります。Gitaly Cluster (Praefect)をデプロイする前に、既存の技術的な制限事項と考慮事項を確認してください。シャーディングされたGitalyが必要な場合は、上記の表にリストされているGitalyと同じ仕様を使用してください。
  7. Gitalyの仕様は、正常に稼働する環境での利用パターンとリポジトリサイズの上位パーセンタイルに基づいています。ただし、（数ギガバイトを超える）大規模なモノレポまたは追加のワークロードがある場合、これらはGitおよびGitalyのパフォーマンスに大幅に影響を与えることがあり、さらなる調整が必要になる場合があります。

インスタンスの設定を含むすべてのPaaSソリューションについては、回復力のあるクラウドアーキテクチャプラクティスに合わせて、3つの異なる可用性ゾーンに最低3つのノードを実装することをおすすめします。

@startuml 10k
skinparam linetype ortho

card "Kubernetes via Helm Charts" as kubernetes {
  card "**External Load Balancer**" as elb #6a9be7

  together {
    collections "**Webservice**" as gitlab #32CD32
    collections "**Sidekiq**" as sidekiq #ff8dd1
  }

  card "**Supporting Services**" as support
}

card "**Internal Load Balancer**" as ilb #9370DB
collections "**Consul** x3" as consul #e76a9b

card "Gitaly Cluster" as gitaly_cluster {
  collections "**Praefect** x3" as praefect #FF8C00
  collections "**Gitaly** x3" as gitaly #FF8C00
  card "**Praefect PostgreSQL***\n//Non fault-tolerant//" as praefect_postgres #FF8C00

  praefect -[#FF8C00]-> gitaly
  praefect -[#FF8C00]> praefect_postgres
}

card "Database" as database {
  collections "**PGBouncer** x3" as pgbouncer #4EA7FF
  card "**PostgreSQL** (Primary)" as postgres_primary #4EA7FF
  collections "**PostgreSQL** (Secondary) x2" as postgres_secondary #4EA7FF

  pgbouncer -[#4EA7FF]-> postgres_primary
  postgres_primary .[#4EA7FF]> postgres_secondary
}

card "redis" as redis {
  collections "**Redis Persistent** x3" as redis_persistent #FF6347
  collections "**Redis Cache** x3" as redis_cache #FF6347

  redis_cache -[hidden]-> redis_persistent
}

cloud "**Object Storage**" as object_storage #white

elb -[#6a9be7]-> gitlab
elb -[hidden]-> sidekiq
elb -[hidden]-> support

gitlab -[#32CD32]--> ilb
gitlab -[#32CD32]r--> object_storage
gitlab -[#32CD32,norank]----> redis
gitlab -[#32CD32]----> database

sidekiq -[#ff8dd1]--> ilb
sidekiq -[#ff8dd1]r--> object_storage
sidekiq -[#ff8dd1,norank]----> redis
sidekiq .[#ff8dd1]----> database

ilb -[#9370DB]--> gitaly_cluster
ilb -[#9370DB]--> database
ilb -[hidden,norank]--> redis

consul .[#e76a9b]--> database
consul .[#e76a9b,norank]--> gitaly_cluster
consul .[#e76a9b]--> redis

@enduml

Kubernetesコンポーネントのターゲット

次のセクションでは、KubernetesにデプロイされたGitLabコンポーネントに使用されるターゲットについて詳しく説明します。

Webservice

各Webserviceポッド（PumaおよびWorkhorse）は、次の設定で実行することをおすすめします:

  • 4 Pumaワーカー
  • 4 vCPU
  • 5 GBメモリ（リクエスト）
  • 7 GBメモリ（制限）

200 RPSまたは10,000ユーザーの場合、合計Pumaワーカー数を約80にすることをおすすめしているので、少なくとも20のWebserviceポッドを実行することを推奨します。

Webserviceリソースの使用状況の詳細については、Webserviceリソースに関するチャートドキュメントを参照してください。

NGINX

NGINXコントローラーポッドをWebserviceノード全体にDaemonSetとしてデプロイすることも推奨されます。これにより、コントローラーはサービスを提供するWebserviceポッドとともに動的にスケールでき、大きなマシンタイプが通常備えている、より大きなネットワーク帯域幅を利用できます。

これは厳密な要件ではありません。Webトラフィックを処理するのに十分なリソースがある限り、NGINXコントローラーポッドは必要に応じてデプロイできます。

Sidekiq

各Sidekiqポッドは、次の設定で実行することをおすすめします:

  • 1 Sidekiqワーカー
  • 900m vCPU
  • 2 GBメモリ（リクエスト）
  • 4 GBメモリ（制限）

前述の標準デプロイと同様に、ここでは14のSidekiqワーカーの初期ターゲットが使用されています。特定のワークフローによっては、追加のワーカーが必要になる場合があります。

Sidekiqリソースの使用状況について詳しくは、Sidekiqリソースに関するチャートドキュメントをご覧ください。

サポート用ノードプール

サポート用ノードプールは、WebserviceおよびSidekiqプールに配置する必要のない、すべてのサポートデプロイを格納するように設計されています。

これには、クラウドプロバイダーの実装に関連するさまざまなデプロイや、GitLab ShellなどのGitLabサポート用デプロイが含まれます。

コンテナレジストリ、Pages、モニタリングなどを追加でデプロイする場合、可能であればこれらをサポート用ノードプールにデプロイし、WebserviceまたはSidekiqプールにはデプロイしないでください。サポート用ノードプールは、さまざまな追加のデプロイに対応するように設計されています。ただし、デプロイが指定されたプールに適合しない場合は、必要に応じてノードプールを増やすことができます。逆に、ユースケースのプールが過剰にプロビジョニングされている場合は、それに応じて減らすことができます。

設定ファイルの例

上記の200 RPSまたは10,000ユーザーリファレンスアーキテクチャの設定のGitLab Helmチャートの例は、クラスタープロジェクトにあります。

次の手順

このガイドに従うことで、コア機能が適切に設定された、新しいGitLab環境が用意されたはずです。

要件に応じて、GitLabの追加のオプション機能を設定することもできます。詳細については、GitLabのインストール後の手順を参照してください。

環境と要件によっては、必要に応じて追加機能のセットアップに必要なハードウェア要件や調整が必要になる場合があります。詳細については、個別のページを参照してください。