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

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

サービスノード設定GCPAWSAzure
ロードバランサー3 12 vCPU、1.8 GBメモリn1-highcpu-2c5.largeF2s v2
PostgreSQL1 12 vCPU、7.5 GBメモリn1-standard-2m5.largeD2s v3
Redis2 11 vCPU、3.75 GBメモリn1-standard-1m5.largeD2s v3
Gitaly5 14 vCPU、15 GB メモリn1-standard-4m5.xlargeD4s v3
GitLab Rails6 28 vCPU、7.2 GBメモリn1-highcpu-8c5.2xlargeF8s v2
監視ノード12 vCPU、1.8 GBメモリn1-highcpu-2c5.largeF2s v2
オブジェクトストレージ4 -----
  1. オプションで、評判の良いサードパーティの外部PaaS PostgreSQLソリューションで実行することができます。詳しくは、PostgreSQLインスタンスの提供および推奨クラウドプロバイダとサービスを参照してください。
  2. オプションで、評判の高いサードパーティの外部PaaS Redisソリューションで実行できます。詳細については、独自のRedisインスタンスの提供と推奨クラウドプロバイダーおよびサービスを参照してください。
  3. オプションとして、評判の高いサードパーティのロードバランシングサービス（LB PaaS）で実行できます。詳細については、推奨クラウドプロバイダーとサービスを参照してください。
  4. 信頼できるクラウドプロバイダーまたはセルフマネージドソリューションで実行する必要があります。詳細については、オブジェクトストレージの設定を参照してください。
  5. 信頼できるクラウドプロバイダーまたはセルフマネージドソリューションで実行する必要があります。詳細については、オブジェクトストレージの設定のセクションを参照してください。
  6. Gitalyは、ベスト・プラクティスに従った様々な規模のリポジトリで設計され、テストされています。しかし、これらのプラクティスに従わない大規模なリポジトリやモノレポは、Gitalyの要件に大きな影響を与える可能性があります。詳細については、大規模なリポジトリを参照してください。
  7. このコンポーネントはステートフルなデータを保存しないので、Auto Scaling Groups (ASG) に配置することができます。しかし、GitLab Railsではマイグレーションや Mailroomのような特定のプロセスは1つのノードだけで実行する必要があります。
note
インスタンスの設定を伴うすべてのPaaSソリューションでは、必要であれば弾力性のために複数のアベイラビリティゾーンにデプロイすることをお勧めします。

要件

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

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

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

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

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

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

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

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

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

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

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

準備チェック

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

ポート

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

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

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

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

代替SSHポート

組織によっては、SSHポート22を開けないというポリシーを持っている場合があります。このような場合は、別のSSHホスト名を設定して、ユーザーが443番ポートでSSHを使えるようにするとよいでしょう。代替のSSHホスト名を使うには、上記のGitLab HTTPの設定と比べて新しい仮想IPアドレスが必要になります。

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

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

SSL

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

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

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

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

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

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

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

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

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

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

PostgreSQLの設定

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

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

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

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

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

  1. HA LinuxパッケージのPostgreSQLセットアップには、PostgreSQL、PgBouncer、Consulが含まれています。サードパーティの外部サービスを利用する場合、これらのコンポーネントは不要になります。
  2. データベース要件文書に従って PostgreSQL をセットアップします。
  3. gitlab ユーザー名とパスワードを gitlab設定してください。gitlab この gitlabユーザーにはgitlabhq_production データベースを作成する権限が必要です。
  4. GitLabアプリケーションサーバーを適切に設定します。このステップはGitLab Railsアプリケーションの設定で説明します。

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

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

  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アプリケーションサーバーの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クラスターモードは特にGitLabではサポートされていないことに注意してください。詳しくは推奨クラウドプロバイダーとサービスをご覧ください。

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

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

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

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

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

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

  6. RedisノードのIPアドレスまたはホスト名、ポート、Redisパスワードをメモしてください。これらは後でGitLabアプリケーションサーバーを設定するときに必要になります。

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

Gitalyの設定

Gitalyサーバーノードの要件は、データサイズ、特にプロジェクトの数とそれらのプロジェクトのサイズに依存します。

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

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

以下の項目に注意してください：

  • GitLab Rails アプリケーションはリポジトリをリポジトリストレージパスに分割します。
  • Gitalyサーバーは1つ以上のストレージパスをホストすることができます。
  • GitLabサーバーは1つ以上のGitalyサーバーノードを使用することができます。
  • Gitalyアドレスは、すべてのGitalyクライアントが正しく解決できるように指定する必要があります。
  • Gitalyのネットワークトラフィックはデフォルトでは暗号化されていないため、Gitalyサーバは公開インターネットに公開されてはいけません。Gitalyサーバへのアクセスを制限するために、ファイアウォールの使用を強く推奨します。もう一つの方法はTLSを使用することです。
note
Gitalyのドキュメントで言及されているトークンは、管理者によって選択された任意のパスワードです。このトークンはGitLab APIのために作成されたトークンや他の類似のWeb APIトークンとは無関係です。

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

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

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

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

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

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

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

# Gitaly
gitaly['enable'] = true

# The secret token is used for authentication callbacks from Gitaly to the GitLab internal API.
# This must match the respective value in GitLab Rails application setup.
gitlab_shell['secret_token'] = 'shellsecret'

# 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',
      },
   ],
}

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

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

  3. Gitalyが内部APIへのコールバックを実行できることを確認します：

    • GitLab 15.3以降では、sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml.
    • GitLab 15.2 以前については、sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml を実行してください。

Gitaly TLSのサポート

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

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

note
自己署名証明書は、Gitalyサーバーへのアクセスに使用するアドレスを指定する必要があります。Gitalyサーバーをホスト名でアドレスしている場合は、サブジェクト代替名として追加してください。IPアドレスでGitalyサーバーをアドレスしている場合は、証明書のサブジェクト代替名として追加する必要があります。

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

GitalyをTLSで設定するには：

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

GitLab Railsの設定

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

私たちのアーキテクチャでは、各GitLab RailsノードをPumaウェブサーバを使って実行し、そのワーカー数を利用可能なCPUの90%、4スレッドに設定しています。他のコンポーネントと一緒にRailsを実行しているノードでは、それに応じてワーカーの値を減らす必要があります。Workerの値を50%にするとバランスが取れると判断していますが、これは作業負荷に依存します。

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

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

  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 for authentication callbacks from GitLab-Shell to the GitLab internal API.
# The following two values must be the same as their respective values
# of the Gitaly setup
gitlab_rails['gitaly_token'] = 'gitalysecret'
gitlab_shell['secret_token'] = 'shellsecret'
   
git_data_dirs({
  '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
nginx['enable'] = true
   
## 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'
sidekiq['listen_address'] = "0.0.0.0"
   
# Configure Sidekiq with 2 workers and 20 max concurrency
sidekiq['max_concurrency'] = 20
sidekiq['queue_groups'] = ['*'] * 2
   
# 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>"
   
## 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を使っている場合は、git_data_dirs のエントリーがtcpではなくtls で設定されていることを確認してください：

    git_data_dirs({
  '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. データベースのマイグレーションがアップグレード時に自動的に実行されるのではなく、再設定時にのみ実行されるようにするには、以下を実行します：

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

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

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

  8. sudo gitlab-rake gitlab:gitaly:check を実行し、ノードが Gitaly に接続できることを確認します。

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

    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と Grafanaを実行するスタンドアロンのMonitoringノードを設定できます：

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

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

    roles(['monitoring_role'])
   
external_url 'http://gitlab.example.com'
   
# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false
   
# Grafana
grafana['enable'] = true
grafana['admin_password'] = '<grafana_password>'
grafana['disable_login_form'] = false
   
# Nginx - For Grafana access
nginx['enable'] = true

  4. Exporter を設定した様々なノードから全てのデータを取得するために、Prometheus はいくつかのスクレイプ設定も必要とします。あなたのノードの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

    /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.4:8082', '1.1.1.5:8082'],
     ],
  },
  {
     'job_name': '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'],
     ],
  },
]
  5. ファイルを保存し、GitLabを再設定してください。
  6. GitLab UIで、admin/application_settings/metrics_and_profiling > Metrics - Grafanaを/-/grafana に設定します。http[s]://<MONITOR NODE>/-/grafana

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

note
これは高度なセットアップです。Kubernetesでのサービスの実行は複雑であることがよく知られています。このセットアップは、Kubernetesに関する知識と経験が豊富な場合にのみ推奨されます。このセクションの残りの部分はこれを前提としています。
note
2,000リファレンスアーキテクチャは可用性の高いセットアップではありません。HAを実現するには、修正された3Kリファレンスアーキテクチャに従うことができます。
note
Gitaly ClusterをKubernetesで実行することはサポートされていません。詳細はエピック6127を参照してください。

クラスターのトポロジー

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

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

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

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

サービスノード設定GCPAWS
PostgreSQL1 12 vCPU、7.5 GBメモリn1-standard-2m5.large
Redis2 11 vCPU、3.75 GBメモリn1-standard-1m5.large
Gitaly14 vCPU、15 GB メモリn1-standard-4m5.xlarge
オブジェクトストレージ3 ----
  1. オプションで、評判の良いサードパーティの外部PaaS PostgreSQLソリューションで実行することができます。詳しくは、PostgreSQLインスタンスの提供および推奨クラウドプロバイダとサービスを参照してください。
  2. オプションで、評判の高いサードパーティの外部PaaS Redisソリューションで実行できます。詳細については、独自のRedisインスタンスの提供と推奨クラウドプロバイダーおよびサービスを参照してください。
  3. 信頼できるクラウドプロバイダーまたはセルフマネージドソリューションで実行する必要があります。詳細については、オブジェクトストレージの設定を参照してください。
note
インスタンスの設定を伴うすべてのPaaSソリューションでは、レジリエントなクラウド・アーキテクチャのプラクティスに合わせるため、3つの異なるアベイラビリティ・ゾーンに最低3つのノードを実装することを強く推奨します。

リソース使用設定

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

ウェブサービス

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

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

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

Sidekiq

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

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

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

サポート

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

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

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