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

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

  • 対応ユーザー数（概算）：2,000人
  • 高可用性:False
  • テストリクエスト/秒(RPS) 速度：API: 40 RPS、Web: 4 RPS、Git: 4 RPS
サービス ノード 設定 事業継続計画 エーダブリュエス Azure
ロードバランサー 1 2 vCPU、1.8GBメモリ n1-highcpu-2 c5.large F2s v2
PostgreSQL 1 2 vCPU、7.5GBメモリ n1-standard-2 m5.large D2s v3
Redis 1 1 vCPU、3.75GBメモリ n1-standard-1 m5.large D2s v3
Gitaly 1 4 vCPU、15GBメモリ n1-standard-4 m5.xlarge D4s v3
GitLab Rails 2 8 vCPU、7.2GBメモリ n1-highcpu-8 c5.2xlarge F8s v2
監視ノード 1 2 vCPU、1.8GBメモリ n1-highcpu-2 c5.large F2s v2
オブジェクトストレージ 該当なし 該当なし 該当なし 該当なし 該当なし
NFSサーバー（オプション、推奨なし） 1 4 vCPU、3.6GBメモリ n1-highcpu-4 c5.xlarge F4s v2

Google Cloud Platform(GCP) アーキテクチャは、Intel Xeon E5 v3 (Haswell) CPUプラットフォームを使用して構築され、テストされました。異なるハードウェアでは、CPUまたはノード数に対して、より低いまたはより高い調整が必要な場合があります。 詳細については、SysbenchベースのCPUベンチマークを参照してください。

パフォーマンスと可用性が向上するため、データ・オブジェクト（LFS、アップロード、アーティファクトなど）の場合は、NFSを使用する代わりにオブジェクト・ストレージ・サービスを使用することをお勧めします。 オブジェクト・ストレージ・サービスを使用すると、ノードのプロビジョニングとメンテナーを行う必要もありません。

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

GitLabとそのコンポーネントをセットアップし、最大2,000ユーザーを収容できるようにします：

  1. 2つのGitLabアプリケーションサービスノードのロードバランシングを処理するために、外部ロードバランシングノードを設定します。
  2. GitLabのデータベースであるPostgreSQLを設定します。
  3. Redisを設定します。
  4. Gitリポジトリへのアクセスを提供するGitalyを設定します。
  5. Puma/Unicorn、Workhorse、GitLab Shellを実行し、すべてのフロントエンドリクエスト（HTTP/SSH経由のUI、API、Gitを含む）を処理するように、メインのGitLab Railsアプリケーションを設定します。
  6. GitLab環境を監視するためにPrometheusを設定します。
  7. 共有データ・オブジェクトに使用するオブジェクト・ストレージを設定します。
  8. Gitalyやオブジェクトストレージの代替として共有ディスクストレージサービスを利用するために、NFSを設定します（オプションで、推奨はしません）。 GitLab Pages（NFSを必要とします）を使用していない場合は、この手順をスキップすることができます。

ロードバランサーの設定

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

アクティブ/アクティブなGitLabのコンフィギュレーションでは、アプリケーションサーバーへのトラフィックをルーティングするためにロードバランサーが必要になります。 どのロードバランサーを使うか、あるいはその正確なコンフィギュレーションについての詳細は、GitLabのドキュメントの範囲外です。 マルチノードシステム（GitLabを含む）を管理している場合は、おそらくすでにロードバランサーを選択しているでしょう。 HAProxy（オープンソース）、F5 Big-IP LTM、Citrix Net Scalerなどがその例です。 このドキュメントには、GitLabで使うためのポートとプロトコルが含まれています。

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

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

ロードバランサーを設定し、ポート443の接続をHTTP(S)の代わりにTCP 。 これにより、SSL証明書を持ちポート443をリッスンするアプリケーションノードのNginxサービスに、接続が変更されずに渡されます。

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

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

TCPの代わりにHTTP(S) プロトコルを使うようにロードバランサーを設定します。 ロードバランサーはSSL証明書の管理とSSLの終了の両方を担当します。

ロードバランサーと GitLab の間の通信はセキュアではないため、いくつかの追加設定を行う必要があります。 詳細については、Nginxproxied SSL のドキュメントを参照ください。

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

ロードバランサー（1つしかない場合は1つのバランサー）はTCPではなくHTTP(S) プロトコルを使うように設定します。 ロードバランサーはエンドユーザーのSSL証明書を管理する責任を負います。

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

港湾

基本的なロードバランサーのポートは以下の表の通りです：

ポート バックエンドポート プロトコル
80 80 HTTP(1)
443 443 TCP または HTTPS(1)(2)
22 22 伝送制御プロトコル
  • (1):Web端末のサポートには、ロードバランサーがWebSocket接続を正しく処理する必要があります。 HTTPまたはHTTPSプロキシを使用する場合、ロードバランサーはConnection 、Upgrade ホップバイホップヘッダーを通過するように設定する必要があります。 詳細は、Web端末インテグレーションガイドを参照してください。
  • (2): ポート443にHTTPSプロトコルを使用する場合、ロードバランサーにSSL証明書を追加する必要があります。 GitLabアプリケーションサーバーでSSLを終了する必要がある場合は、TCPプロトコルを使用してください。

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

ポート バックエンドポート プロトコル
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ポート バックエンドポート プロトコル
443 22 伝送制御プロトコル
セットアップコンポーネントに戻る

PostgreSQLの設定

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

独自のPostgreSQLインスタンスの提供

GitLabをクラウドプロバイダーでホストしている場合、オプションでPostgreSQLのマネージドサービスを使うことができます。 例えば、AWSはPostgreSQLを実行するマネージドリレーショナルデータベースサービス(RDS) 。

クラウドマネージドサービスを使用する場合、または独自のPostgreSQLを提供する場合：

  1. データベース要件文書に従ってPostgreSQLをセットアップします。
  2. gitlab この gitlabユーザーには、gitlabhq_production データベースを作成する権限が必要です。
  3. GitLabアプリケーションサーバーを適切に設定します。 このステップは、GitLab Railsアプリケーションの設定でカバーされています。

Omnibus GitLab を使ったスタンドアロン PostgreSQL

  1. PostgreSQLサーバにSSH接続してください。
  2. GitLabダウンロードページから、ステップ1と2を使用して必要なOmnibus 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アプリケーションサーバーのIPサブネットまたはIPアドレスをスペースで区切ったリスト。 例：%w(123.123.123.123/32 123.123.123.234/32) 
    # Disable all components except PostgreSQL
roles ['postgres_role']
repmgr['enable'] = false
consul['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
pgbouncer_exporter['enable'] = false
redis_exporter['enable'] = false
gitlab_exporter['enable'] = false

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

# Disable automatic database migrations
gitlab_rails['auto_migrate'] = false
  5. 変更を有効にするために GitLab を再設定します。
  6. PostgreSQLノードのIPアドレスかホスト名、ポート、プレーンテキストのパスワードをメモしておきます。 これらは後でGitLabアプリケーションサーバーを設定するときに必要になります。

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

セットアップコンポーネントに戻る

Redisの設定

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

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

Redisのバージョンが5.0以上であることが必要です。これはGitLab 13.0以降のOmnibus GitLabパッケージに同梱されているものです。古いバージョンのRedisでは、マージトレインに必要なSPOPへのオプションのcount引数がサポートされていません。

加えて、GitLabはRedis 4でのみ導入されたUNLINK やUSAGE といったコマンドを使用します。

AWS ElastiCacheのようなクラウドプロバイダのマネージドRedisでも動作します。 これらのサービスが高可用性をサポートしている場合は、Redisクラスタタイプでないことを確認してください。

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

Omnibusを使ったスタンドアロンRedis GitLab

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

  1. RedisサーバーにSSH接続します。
  2. GitLabダウンロードページから、ステップ1と2を使用して必要なOmnibus GitLabパッケージをダウンロード/インストールします。
    • ダウンロードページの他のステップは完了しないでください。

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

    ## Enable Redis
redis['enable'] = true

## Disable all other services
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
puma['enable'] = false
unicorn['enable'] = false
postgresql['enable'] = false
nginx['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
pgbouncer_exporter['enable'] = false
gitlab_exporter['enable'] = false
gitaly['enable'] = false
grafana['enable'] = false

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. 変更を有効にするためにOmnibus GitLab を再設定します。
  5. RedisノードのIPアドレスまたはホスト名、ポート、Redisパスワードをメモしておきましょう。 これらは後でGitLabアプリケーションサーバーを設定するときに必要になります。

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

セットアップコンポーネントに戻る

Gitalyの設定

Gitalyを独自のサーバーにデプロイすることで、1台のマシンよりも大規模なGitLabインストールに恩恵をもたらすことができます。 Gitalyノードの要件はデータ、特にプロジェクトの数とそのサイズに依存します。 各Gitalyノードが保存するデータは5TB以下にすることを推奨します。 2Kセットアップでは、リポジトリのストレージ要件に応じて1つ以上のノードが必要になるかもしれません。

GitalyのI/Oは重いため、すべてのGitalyノードは、リードオペレーションで少なくとも8,000 IOPS、ライトオペレーションで2,000 IOPSのスループットを持つSSDディスクでセットアップされることを強くお勧めします。 これらのIOPS値は、時間の経過とともに、環境のワークロードの規模に応じて高くしたり低くしたり調整することができるため、スターターとしてのみ推奨されます。 クラウドプロバイダー上で環境を実行している場合は、IOPSを正しく設定する方法について、プロバイダーのドキュメントを参照する必要があるかもしれません。

いくつか注意すべき点があります：

  • GitLab Railsアプリケーションはリポジトリをリポジトリストレージに分割します。
  • Gitalyサーバーは1つ以上のストレージをホストすることができます。
  • GitLabサーバーは1つ以上のGitalyサーバーを使用することができます。
  • Gitalyアドレスは、全てのGitalyクライアントに対して正しく解決されるように指定されなければなりません。
  • Gitalyのネットワークトラフィックはデフォルトで暗号化されていないため、Gitalyサーバーは公開インターネットに公開されてはいけません。 Gitalyサーバーへのアクセスを制限するために、ファイアウォールの使用を強く推奨します。 もう一つの選択肢はTLSを使用することです。
ヒント:Gitalyの歴史とネットワークアーキテクチャの詳細については、スタンドアロンのGitalyドキュメントを参照してください。

注：Gitalyドキュメント全体で言及されているトークンは、管理者によって選択された任意のパスワードに過ぎません。 GitLab APIや他の同様のWeb APIトークンのために作成されたトークンとは無関係です。

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

Gitalyサーバーを設定するには：

  1. GitLabのダウンロードページからステップ1と2を使用して、必要なOmnibus GitLabパッケージをダウンロード/インストールします。ただし、EXTERNAL_URL の値は入力しないでください。

  2. /etc/gitlab/gitlab.rb を編集して、ストレージパスを構成し、ネットワークリスナーを有効にし、トークンを構成します：

    # /etc/gitlab/gitlab.rb

# 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 GitLab Rails application setup
gitaly['auth_token'] = 'gitlaysecret'
gitlab_shell['secret_token'] = 'shellsecret'

# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
unicorn['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false

# If you run a seperate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false

# Prevent database connections during 'gitlab-ctl reconfigure'
gitlab_rails['rake_cache_clear'] = false
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.
# Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

# 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
gitaly['listen_addr'] = "0.0.0.0:8075"
gitaly['prometheus_listen_addr'] = "0.0.0.0:9236"

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

  3. gitaly1.internalの/etc/gitlab/gitlab.rb に以下を追加： 

    git_data_dirs({
  'default' => {
    'path' => '/var/opt/gitlab/git-data'
  },
  'storage1' => {
    'path' => '/mnt/gitlab/git-data'
  },
})
  4. ファイルを保存し、GitLabを再設定します。

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

    sudo /opt/gitlab/embedded/service/gitlab-shell/bin/check -config /opt/gitlab/embedded/service/gitlab-shell/config.yml

Gitaly TLSサポート

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

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

注意自己署名証明書には、Gitalyサーバーへのアクセスに使用するアドレスを指定する必要があります。 Gitalyサーバーをホスト名でアドレス指定する場合は、Common Nameフィールドを使用するか、サブジェクトの代替名として追加します。 GitalyサーバーをIPアドレスでアドレス指定する場合は、証明書のサブジェクトの代替名として追加する必要があります。
注：暗号化されていないリスニング・アドレス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['tls_listen_addr'] = "0.0.0.0:9999"
gitaly['certificate_path'] = "/etc/gitlab/ssl/cert.pem"
gitaly['key_path'] = "/etc/gitlab/ssl/key.pem"
  4. gitaly['listen_addr'] を削除して、暗号化された接続のみを許可します。
  5. ファイルを保存し、GitLabを再設定します。
セットアップコンポーネントに戻る

GitLab Railsの設定

注:私たちのアーキテクチャでは、GitLabの各RailsノードをPumaウェブサーバを使って実行し、ワーカー数を利用可能なCPUの90%に設定し、4つのスレッドを使用しています。 他のコンポーネントと一緒にRailsを実行しているノードでは、ワーカー数を適宜減らす必要があります。

このセクションでは、GitLabアプリケーション（Rails）コンポーネントの設定方法を説明します。 各ノードで以下を実行します：

  1. NFSを使用している場合：

    1. 必要に応じて、以下のコマンドを使用してNFSクライアント・ユーティリティ・パッケージをインストールします： 

      # Ubuntu/Debian
apt-get install nfs-common

# CentOS/Red Hat
yum install nfs-utils nfs-utils-lib

    2. 必要なNFSマウントを/etc/fstab.NFS /etc/fstabマウントに指定します。 .NFS/etc/fstabマウントの正確な内容は /etc/fstab、NFSサーバーの設定方法によって異なります。 例と各種オプションについては、NFSのドキュメントを参照してください。

    3. 共有ディレクトリを作成します。 これらは、NFSマウントの場所によって異なる場合があります。 

      mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
  2. GitLabのダウンロードページのステップ1と2を使用して、Omnibus GitLabをダウンロード/インストールします。 ダウンロードページの他のステップは完了しないでください。

  3. /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'] = 'gitalyecret'
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'
sidekiq['listen_address'] = "0.0.0.0"
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']

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

  4. 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/
  5. ファイルを保存し、GitLabを再設定します。
  6. sudo gitlab-rake gitlab:gitaly:check を実行し、ノードが Gitaly に接続できることを確認します。

  7. ログをたどってリクエストを確認してください： 

    sudo gitlab-ctl tail gitaly
注意: 上記の例のようにexternal_urlにhttps を指定した場合、GitLab は/etc/gitlab/ssl/に SSL 証明書があるものとみなします。 証明書がない場合、NGINX は起動に失敗します。 詳細はNGINX のドキュメントを参照してください。
セットアップコンポーネントに戻る

Prometheus の設定

Omnibus GitLabパッケージを使用すると、PrometheusとGrafanaを実行するスタンドアロンのモニタリングノードを設定できます：

  1. MonitoringノードにSSH接続します。
  2. GitLabのダウンロードページから、ステップ1と2を使用して必要なOmnibus GitLabパッケージをダウンロード/インストールします。 ダウンロードページの他のステップは完了しないでください。

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

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

# Enable Prometheus
prometheus['enable'] = true
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false

# Enable Login form
grafana['disable_login_form'] = false

# Enable Grafana
grafana['enable'] = true
grafana['admin_password'] = 'toomanysecrets'

# Disable all other services
gitlab_rails['auto_migrate'] = false
alertmanager['enable'] = false
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = true
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
sidekiq['enable'] = false
puma['enable'] = false
unicorn['enable'] = false
node_exporter['enable'] = false
gitlab_exporter['enable'] = false

  4. Prometheusは、exporterを設定した様々なノードから全てのデータを引き出すために、いくつかのscrape設定も必要とします。 ノードの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は、いくつかのタイプのデータを保持するためにオブジェクトストレージサービスを使うことをサポートしており、NFSよりも推奨されています。 一般的に、オブジェクトストレージの方がパフォーマンス、信頼性、スケーラビリティに優れているため、大規模な環境にはオブジェクトストレージサービスの方が適しています。

GitLabがテストした、または顧客が使用していると認識しているオブジェクトストレージオプションには、以下のものがあります：

オブジェクトストレージを使用するようにGitLabを設定するには、使用する機能に応じて以下のガイドを参照してください：

  1. バックアップ用のオブジェクトストレージ。
  2. インクリメンタルロギングを含むジョブアーティファクト用のオブジェクトストレージ。
  3. LFS オブジェクト用のオブジェクトストレージ。
  4. アップロード用のオブジェクトストレージ。
  5. マージリクエストの差分のオブジェクトストレージ。
  6. コンテナレジストリ用のオブジェクトストレージ（オプション機能）。
  7. Mattermost 用オブジェクトストレージ(オプション機能)。
  8. パッケージ用のオブジェクトストレージ（オプション機能）。
  9. 依存プロキシ用のオブジェクトストレージ（オプション機能）。
  10. Pseudonymizer 用のオブジェクトストレージ（オプション機能）。
  11. オートスケール Runner キャッシング用オブジェクトストレージ（オプション、パフォーマンス向上用）。
  12. Terraformステートファイルのオブジェクトストレージ。

GitLabでは、データ型ごとに別々のバケットを使うことが推奨されています。

私たちの構成の限界は、オブジェクトストレージの各使用が個別に設定されていることです。 これを改善するためのイシューがあり、1つのバケットで別々のフォルダを使用できるようになります。

GitLabがHelmチャートでデプロイされているときに単一のバケットを使用すると、バックアップからのリストアが正しく機能しなくなります。 今はHelmデプロイを使用していないかもしれませんが、後でGitLabをHelmデプロイに移行してもGitLabは動作しますが、バックアップが機能するための重要な要件が発生するまで、バックアップが正しく機能していないことに気づかないかもしれません。

セットアップコンポーネントに戻る

NFSの設定（オプション）

パフォーマンスを向上させるために、オブジェクトストレージとGitalyは可能な限りNFSを使うよりも推奨されます。 しかし、GitLab Pagesを使うつもりなら、NFSを使う必要があります。

NFSの設定については、NFSのドキュメントページを参照してください。

セットアップコンポーネントに戻る

トラブルシューティング

トラブルシューティングのドキュメントを参照してください。

セットアップコンポーネントに戻る