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

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

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

• Target Load（目標負荷）: API: 40 RPS、Web: 4 RPS、Git（プル）: 4 RPS、Git（プッシュ）: 1 RPS
• High Availability（HA）: 不可。HA環境には、変更された3,000または60 RPSのリファレンスアーキテクチャを参照してください。
• Cloud Native Hybrid（クラウドネイティブハイブリッド）: はい
• Unsure which Reference Architecture to use（どのリファレンスアーキテクチャを使用すればよいかわからない場合）: 詳細については、こちらのガイドをご覧ください。

Footnotes（補足説明）:

1. マシンタイプの例は、説明目的で提供されています。これらのタイプは、検証とテストで使用されていますが、推奨されるデフォルトとして意図されたものではありません。リストされている要件を満たす他のマシンタイプへの切り替え（利用可能な場合はARMバリアントを含む）がサポートされています。詳細については、サポートされているマシンタイプを参照してください。
2. 定評のあるサードパーティの外部PaaS PostgreSQLソリューションでオプションで実行できます。詳細については、独自のPostgreSQLインスタンスを提供すると推奨クラウドプロバイダーとサービスを参照してください。
3. 定評のあるサードパーティの外部PaaS Redisソリューションでオプションで実行できます。詳細については、独自のRedisインスタンスを提供すると推奨クラウドプロバイダーとサービスを参照してください。
4. 定評のあるサードパーティのロードバランサーまたはサービス（LB PaaS）で実行することをおすすめします。サイジングは、選択したロードバランサーと、ネットワーク帯域幅などの追加要因によって異なります。詳細については、ロードバランサーを参照してください。
5. 定評のあるクラウドプロバイダーまたはSelf-Managedソリューションで実行する必要があります。詳細については、オブジェクトストレージを設定するを参照してください。
6. Gitalyの仕様は、正常な状態の通常サイズのリポジトリの使用に基づいています。ただし、（数ギガバイトを超える）大規模なモノレポがある場合、GitとGitalyのパフォーマンスにsignificantly（大幅に）影響を与えることがあり、仕様の引き上げが必要になる可能性があります。詳細については、大規模なモノレポを参照してください。
7. コンポーネントはステートフルデータを保存しないため、Auto Scaling Groups（ASG）に配置できます。ただし、クラウドネイティブハイブリッドセットアップが一般的に推奨されます。移行やMailroomなどの特定のコンポーネントは、1つのノードでしか実行できないためであり、これらのコンポーネントは、Kubernetesでより適切に処理されます。

@startuml 2k
skinparam linetype ortho

card "**External Load Balancer**" as elb #6a9be7

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

card "**Prometheus**" as monitor #7FFFD4
card "**Gitaly**" as gitaly #FF8C00
card "**PostgreSQL**" as postgres #4EA7FF
card "**Redis**" as redis #FF6347
cloud "**Object Storage**" as object_storage #white

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

gitlab -[#32CD32]--> gitaly
gitlab -[#32CD32]--> postgres
gitlab -[#32CD32]> object_storage
gitlab -[#32CD32]--> redis

sidekiq -[#ff8dd1]> object_storage
sidekiq -[#ff8dd1]--> redis
sidekiq .[#ff8dd1]--> postgres
sidekiq -[hidden]-> monitor

monitor .[#7FFFD4]u-> gitlab
monitor .[#7FFFD4]-> gitaly
monitor .[#7FFFD4]-> postgres
monitor .[#7FFFD4,norank]--> redis
monitor .[#7FFFD4,norank]u--> elb
monitor .[#7FFFD4]u-> sidekiq

@enduml

要件

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

テスト手法

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

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

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

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

環境に次の要素がある場合、追加の調整が必要になる場合があります:

• リスト上の目標よりも一貫して高いスループット
• 大規模なモノレポ
• 大幅な追加のワークロード

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

ロードバランサーの設定

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

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

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

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

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

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

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

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

準備完了チェック

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

ポート

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

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

• （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を設定します。

SSL

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

• アプリケーションノードがSSLを終了する。
• ロードバランサーがバックエンドSSLなしでSSLを終了し、ロードバランサーとアプリケーションノード間の通信が安全ではなくなる。
• ロードバランサーがバックエンドSSLでSSLを終了し、ロードバランサーとアプリケーションノード間の通信が安全になる。

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

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

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

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

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

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

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

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

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

PostgreSQLを設定する

このセクションでは、GitLabで使用できる外部PostgreSQLデータベースを設定する方法について説明します。

独自のPostgreSQLインスタンスを提供する

LinuxパッケージにバンドルされているPostgreSQL、PgBouncer、Consulサービスディスカバリコンポーネントの代わりに、PostgreSQL用のサードパーティの外部サービスを使用できます。

サポートされているPostgreSQLバージョンを実行する信頼できるプロバイダーを使用してください。これらのサービスは正常に動作することがわかっています:

• Google Cloud SQL。
• Amazon RDS。

高可用性とデータベースのロードバランシングに関するガイダンスを含む詳細については、以下を参照してください:

• 推奨されるクラウドプロバイダーとサービス。
• データベースサービスのベストプラクティス。

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

1. データベース要件に関するドキュメントに従ってPostgreSQLをセットアップします。
2. 必要なユーザーとデータベースを構成します。
3. GitLab Railsの構成に従って、適切な接続詳細でGitLabアプリケーションサーバーを構成します。

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

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

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

3. PostgreSQLのパスワードハッシュを生成します。これは、gitlabのデフォルトのユーザー名を使用することを前提としています（推奨）。コマンドは、パスワードと確認を要求します。次の手順で、このコマンドによって出力された値をPOSTGRESQL_PASSWORD_HASHの値として使用します。

   sudo gitlab-ctl pg-password-md5 gitlab

4. /etc/gitlab/gitlab.rbを編集し、以下の内容を追加して、プレースホルダーの値を適切に更新します。

   • POSTGRESQL_PASSWORD_HASH - 前の手順からの出力値
   • APPLICATION_SERVER_IP_BLOCKS - データベースに接続するGitLab RailsおよびSidekiqサーバーのIPサブネットまたはIPアドレス（スペース区切り）のリスト。例: %w(123.123.123.123/32 123.123.123.234/32)
   # Disable all components except PostgreSQL related ones
   roles(['postgres_role'])
   
   # Set the network addresses that the exporters used for monitoring will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   postgres_exporter['listen_address'] = '0.0.0.0:9187'
   postgres_exporter['dbname'] = 'gitlabhq_production'
   postgres_exporter['password'] = 'POSTGRESQL_PASSWORD_HASH'
   
   # Set the PostgreSQL address and port
   postgresql['listen_address'] = '0.0.0.0'
   postgresql['port'] = 5432
   
   # Replace POSTGRESQL_PASSWORD_HASH with a generated md5 value
   postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
   
   # Replace APPLICATION_SERVER_IP_BLOCK with the CIDR address of the application node
   postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 APPLICATION_SERVER_IP_BLOCK)
   
   # Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false

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

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

7. PostgreSQLノードのIPアドレスまたはホスト名、ポート、およびプレーンテキストパスワードをメモしておきます。これらの詳細は、後でGitLabアプリケーションサーバーを設定する際に必要になります。

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

Redisを設定する

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

独自のRedisインスタンスを提供する

オプションで、次のガイダンスに従って、サードパーティの外部サービスをRedisインスタンスに使用できます:

• そのためには、信頼できるプロバイダーまたはソリューションを使用する必要があります。Google MemorystoreとAWS ElastiCacheは動作が確認されています。
• Redisクラスターモードは特にサポートされていませんが、HAのRedisスタンドアロンはサポートされています。
• セットアップに従って、Redis削除モードを設定する必要があります。

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

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

Linuxパッケージを使用して、スタンドアロンRedisサーバーを設定できます。LinuxパッケージでRedisサーバーを設定するには、以下の手順が最低限必要です:

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

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

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

   ## Enable Redis
   roles(["redis_master_role"])
   
   redis['bind'] = '0.0.0.0'
   redis['port'] = 6379
   redis['password'] = 'SECRET_PASSWORD_HERE'
   
   # Set the network addresses that the exporters used for monitoring 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://0.0.0.0:6379',
         'redis.password' => 'SECRET_PASSWORD_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. RedisノードのIPアドレスまたはホスト名、ポート、およびRedisパスワードをメモしておきます。これらは、後でGitLabアプリケーションサーバーを設定する際に必要になります。

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

Gitalyを設定する

Gitalyサーバーノードの要件は、データサイズ、特にプロジェクト数とそれらのプロジェクトのサイズによって異なります。

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

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

• GitLab Railsアプリケーションは、リポジトリをリポジトリストレージパスにシャードします。
• Gitalyサーバーは、1つ以上のストレージパスをホストできます。
• GitLabサーバーは、1つ以上のGitalyサーバーノードを使用できます。
• Gitalyアドレスは、すべてのGitalyクライアントで正しく解決できるように指定する必要があります。
• Gitalyのネットワークトラフィックはデフォルトで暗号化されていないため、Gitalyサーバーをパブリックインターネットに公開しないでください。ファイアウォールを使用してGitalyサーバーへのアクセスを制限することを強くおすすめします。別のオプションは、TLSを使用することです。

次の手順では、シークレットトークンgitalysecretを持つgitaly1.internalという名前の単一のGitalyサーバーを設定する方法について説明します。GitLabインストールには、defaultとstorage1の2つのリポジトリストレージがあると想定しています。

Gitalyサーバーを設定するには、Gitalyに使用するサーバーノードで、次の手順を実行します:

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

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

   GitLabで必要になるため、gitaly['configuration'][:storage]からdefaultエントリを削除することはできません。

   # 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'
   
   # Set the network addresses that the exporters used for monitoring will listen on
   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',
      prometheus_listen_addr: '0.0.0.0:9236',
      # Gitaly Auth Token
      # Should be the same as praefect_internal_token
      auth: {
         # ...
         #
         # Gitaly's authentication token is used to authenticate gRPC requests to Gitaly. This must match
         # the respective value in GitLab Rails application setup.
         token: 'gitalysecret',
      },
      # 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,
      },
      storage: [
         {
            name: 'default',
            path: '/var/opt/gitlab/git-data',
         },
         {
            name: 'storage1',
            path: '/mnt/gitlab/git-data',
         },
      ],
   }

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

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

5. 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を実行します。

Gitaly TLSのサポート

GitalyはTLS暗号化をサポートしています。セキュアな接続をリッスンするGitalyインスタンスと通信するには、GitLab設定で、対応するストレージエントリのgitaly_addressでtls:// URLスキームを使用する必要があります。

これは自動的には提供されないため、独自の証明書を用意する必要があります。証明書、またはその認証局は、GitLabカスタム証明書の設定で説明されている手順に従って、すべてのGitalyノード（証明書を使用するGitalyノードを含む）と、それと通信するすべてのクライアントノードにインストールする必要があります。

Gitalyサーバーは、暗号化されていないリスニングアドレス（listen_addr）と暗号化されたリスニングアドレス（tls_listen_addr）の両方で同時に設定できます。これにより、必要に応じて、暗号化されていないトラフィックから暗号化されたトラフィックへの段階的な移行を行うことができます。

TLSを使用してGitalyを設定するには、次の手順に従います:

1. /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

2. Gitalyがそれ自体を呼び出すときに証明書を信頼するように、証明書を/etc/gitlab/trusted-certsにコピーします:

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

3. /etc/gitlab/gitlab.rbを編集して、以下を追加します:

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

4. 暗号化された接続のみを許可するには、gitaly['listen_addr']を削除します。

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

Sidekiqを設定する

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

Sidekiqサーバーを設定するには、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
   external_url 'https://gitlab.example.com'
   
   ## Redis connection details
   gitlab_rails['redis_port'] = '6379'
   gitlab_rails['redis_host'] = '10.1.0.6' # IP/hostname of Redis server
   gitlab_rails['redis_password'] = 'Redis Password'
   
   # Gitaly and GitLab use two shared secrets for authentication, one to authenticate gRPC requests
   # to Gitaly, and a second stored in /etc/gitlab/gitlab-secrets.json for authentication callbacks from GitLab-Shell to the GitLab internal API.
   # The following must be the same as their respective values
   # of the Gitaly setup
   gitlab_rails['gitaly_token'] = 'gitalysecret'
   
   gitlab_rails['repositories_storages'] = {
     'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
   }
   
   ## PostgreSQL connection details
   gitlab_rails['db_adapter'] = 'postgresql'
   gitlab_rails['db_encoding'] = 'unicode'
   gitlab_rails['db_host'] = '10.1.0.5' # IP/hostname of database server
   gitlab_rails['db_password'] = 'DB password'
   
   ## 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
   
   ## Set the network addresses that the exporters will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   
   # 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を再設定します。

8. GitLabサービスが実行されていることを確認します:

   sudo gitlab-ctl status

   出力は次のようになります:

   run: logrotate: (pid 192292) 2990s; run: log: (pid 26374) 93048s
   run: node-exporter: (pid 26864) 92997s; run: log: (pid 26446) 93036s
   run: sidekiq: (pid 26870) 92996s; run: log: (pid 26391) 93042s

GitLab Railsを設定する

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

このアーキテクチャでは、各GitLab RailsノードをPuma Webサーバーを使用して実行し、ワーカーの数を利用可能なCPUの90%に設定し、スレッド数を4に設定します。他のコンポーネントとともにRailsを実行するノードの場合、ワーカーの値をそれに応じて減らす必要があります。ワーカーの値が50%でバランスが取れていることを確認しましたが、これはワークロードによって異なります。

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

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

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

   external_url 'https://gitlab.example.com'
   
   # Gitaly and GitLab use two shared secrets for authentication, one to authenticate gRPC requests
   # to Gitaly, and a second stored in /etc/gitlab/gitlab-secrets.json for authentication callbacks from GitLab-Shell to the GitLab internal API.
   # The following must be the same as their respective values
   # of the Gitaly setup
   gitlab_rails['gitaly_token'] = 'gitalysecret'
   
   gitlab_rails['repositories_storages'] = {
     'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
   }
   
   ## Disable components that will not be on the GitLab application server
   roles(['application_role'])
   gitaly['enable'] = false
   sidekiq['enable'] = false
   
   ## PostgreSQL connection details
   gitlab_rails['db_adapter'] = 'postgresql'
   gitlab_rails['db_encoding'] = 'unicode'
   gitlab_rails['db_host'] = '10.1.0.5' # IP/hostname of database server
   gitlab_rails['db_password'] = 'DB password'
   
   ## Redis connection details
   gitlab_rails['redis_port'] = '6379'
   gitlab_rails['redis_host'] = '10.1.0.6' # IP/hostname of Redis server
   gitlab_rails['redis_password'] = 'Redis Password'
   
   # 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. Replace placeholder `monitoring.gitlab.example.com` with
   # the address and/or subnets gathered from the monitoring node
   gitlab_rails['monitoring_whitelist'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
   nginx['status']['options']['allow'] = ['<MONITOR NODE IP>/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>'
   }
   
   ## 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

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

   gitlab_rails['repositories_storages'] = {
     'default' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
     'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
     'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' },
   }

   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. sudo gitlab-rake gitlab:gitaly:checkを実行して、ノードがGitalyに接続できることを確認します。

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

    sudo gitlab-ctl tail gitaly

前の例のように、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を実行するスタンドアロンのモニタリングノードを設定できます:

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

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

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

   roles(['monitoring_role'])
   nginx['enable'] = false
   
   external_url 'http://gitlab.example.com'
   
   # Prometheus
   prometheus['listen_address'] = '0.0.0.0:9090'
   prometheus['monitor_kubernetes'] = false

4. Prometheusには、exporterを設定したさまざまなノードからすべてのデータをプルするためのスクレイプ設定も必要です。ノードのIPが以下であると仮定します:

   1.1.1.1: postgres
   1.1.1.2: redis
   1.1.1.3: gitaly1
   1.1.1.4: rails1
   1.1.1.5: rails2
   1.1.1.6: sidekiq

   次の内容を/etc/gitlab/gitlab.rbに追加します:

   prometheus['scrape_configs'] = [
     {
        'job_name': 'postgres',
        'static_configs' => [
        'targets' => ['1.1.1.1:9187'],
        ],
     },
     {
        'job_name': 'redis',
        'static_configs' => [
        'targets' => ['1.1.1.2:9121'],
        ],
     },
     {
        'job_name': 'gitaly',
        'static_configs' => [
        'targets' => ['1.1.1.3:9236'],
        ],
     },
     {
        'job_name': 'gitlab-nginx',
        'static_configs' => [
        'targets' => ['1.1.1.4:8060', '1.1.1.5:8060'],
        ],
     },
     {
        'job_name': 'gitlab-workhorse',
        'static_configs' => [
        'targets' => ['1.1.1.4:9229', '1.1.1.5:9229'],
        ],
     },
     {
        'job_name': 'gitlab-rails',
        'metrics_path': '/-/metrics',
        'static_configs' => [
        'targets' => ['1.1.1.4:8080', '1.1.1.5:8080'],
        ],
     },
     {
        'job_name': 'gitlab-sidekiq',
        'static_configs' => [
        'targets' => ['1.1.1.6:8082'],
        ],
     },
     {
        'job_name': 'static-node',
        'static_configs' => [
        'targets' => ['1.1.1.1:9100', '1.1.1.2:9100', '1.1.1.3:9100', '1.1.1.4:9100', '1.1.1.5:9100', '1.1.1.6:9100'],
        ],
     },
   ]

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

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

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

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

• 統合された形式: サポートされているすべてのオブジェクトタイプで1つの認証情報が共有されます。
• ストレージ固有の形式: オブジェクトごとに、個別のオブジェクトストレージの接続と設定を定義します。

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

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チャートの高度な設定ドキュメントを参照してください。

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

クラスタートポロジー

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

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

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

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

Footnotes（補足説明）:

1. マシンタイプの例は、説明目的で提供されています。これらのタイプは、検証とテストで使用されていますが、推奨されるデフォルトとして意図されたものではありません。リストされている要件を満たす他のマシンタイプへの切り替え（利用可能な場合はARMバリアントを含む）がサポートされています。詳細については、サポートされているマシンタイプを参照してください。
2. 定評のあるサードパーティの外部PaaS PostgreSQLソリューションでオプションで実行できます。詳細については、独自のPostgreSQLインスタンスを提供すると推奨クラウドプロバイダーとサービスを参照してください。
3. 定評のあるサードパーティの外部PaaS Redisソリューションでオプションで実行できます。詳細については、独自のRedisインスタンスを提供すると推奨クラウドプロバイダーとサービスを参照してください。
4. 定評のあるクラウドプロバイダーまたはSelf-Managedソリューションで実行する必要があります。詳細については、オブジェクトストレージを設定するを参照してください。
5. Gitalyの仕様は、正常な状態の通常サイズのリポジトリの使用に基づいています。ただし、（数ギガバイトを超える）大規模なモノレポがある場合、GitとGitalyのパフォーマンスにsignificantly（大幅に）影響を与えることがあり、仕様の引き上げが必要になる可能性があります。詳細については、大規模なモノレポを参照してください。

@startuml 2k
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
  }

  collections "**Supporting Services**" as support
}

card "**Gitaly**" as gitaly #FF8C00
card "**PostgreSQL**" as postgres #4EA7FF
card "**Redis**" as redis #FF6347
cloud "**Object Storage**" as object_storage #white

elb -[#6a9be7]-> gitlab

gitlab -[#32CD32]--> gitaly
gitlab -[#32CD32]--> postgres
gitlab -[#32CD32]-> object_storage
gitlab -[#32CD32]--> redis

sidekiq -[#ff8dd1]--> gitaly
sidekiq -[#ff8dd1]-> object_storage
sidekiq -[#ff8dd1]--> postgres
sidekiq -[#ff8dd1]--> redis

@enduml

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

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

Webservice

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

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

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

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

NGINX

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

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

Sidekiq

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

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

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

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

サポート用ノードプール

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

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

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

設定ファイルの例

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

次の手順

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

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