- セットアップコンポーネント
- ロードバランサーの設定
- PostgreSQLの設定
- Redisの設定
- Gitalyの設定
- GitLab Railsの設定
- Prometheus の設定
- オブジェクト・ストレージの設定
- NFSの設定(オプション)
- トラブルシューティング
リファレンス・アーキテクチャ:最大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ユーザーを収容できるようにします:
- 2つのGitLabアプリケーションサービスノードのロードバランシングを処理するために、外部ロードバランシングノードを設定します。
- GitLabのデータベースであるPostgreSQLを設定します。
- Redisを設定します。
- Gitリポジトリへのアクセスを提供するGitalyを設定します。
- Puma/Unicorn、Workhorse、GitLab Shellを実行し、すべてのフロントエンドリクエスト(HTTP/SSH経由のUI、API、Gitを含む)を処理するように、メインのGitLab Railsアプリケーションを設定します。
- GitLab環境を監視するためにPrometheusを設定します。
- 共有データ・オブジェクトに使用するオブジェクト・ストレージを設定します。
- Gitalyやオブジェクトストレージの代替として共有ディスクストレージサービスを利用するために、NFSを設定します(オプションで、推奨はしません)。 GitLab Pages(NFSを必要とします)を使用していない場合は、この手順をスキップすることができます。
ロードバランサーの設定
アクティブ/アクティブなGitLabのコンフィギュレーションでは、アプリケーションサーバーへのトラフィックをルーティングするためにロードバランサーが必要になります。 どのロードバランサーを使うか、あるいはその正確なコンフィギュレーションについての詳細は、GitLabのドキュメントの範囲外です。 マルチノードシステム(GitLabを含む)を管理している場合は、おそらくすでにロードバランサーを選択しているでしょう。 HAProxy(オープンソース)、F5 Big-IP LTM、Citrix Net Scalerなどがその例です。 このドキュメントには、GitLabで使うためのポートとプロトコルが含まれています。
次の問題は、あなたの環境でSSLをどのように扱うかです。 いくつかの異なる選択肢があります:
- アプリケーションノードがSSLを終了します。
- ロードバランサーはバックエンドSSLなしでSSLを終了し、ロードバランサーとアプリケーションノード間の通信はセキュリティで保護されません。
- ロードバランサーはバックエンドSSLで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を提供する場合:
- データベース要件文書に従ってPostgreSQLをセットアップします。
-
gitlab
このgitlab
ユーザーには、gitlabhq_production
データベースを作成する権限が必要です。 - GitLabアプリケーションサーバーを適切に設定します。 このステップは、GitLab Railsアプリケーションの設定でカバーされています。
Omnibus GitLab を使ったスタンドアロン PostgreSQL
- PostgreSQLサーバにSSH接続してください。
- GitLabダウンロードページから、ステップ1と2を使用して必要なOmnibus GitLabパッケージをダウンロード/インストールします。
- ダウンロードページの他のステップは完了しないでください。
-
PostgreSQLのパスワード・ハッシュを生成します。このコマンドはデフォルトのユーザ名
gitlab
(推奨)を使用することを想定しています。このコマンドはパスワードと確認を要求します。次のステップでこのコマンドが出力する値をPOSTGRESQL_PASSWORD_HASH
の値として使用してください。sudo gitlab-ctl pg-password-md5 gitlab
-
/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
-
- 変更を有効にするために GitLab を再設定します。
- 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サーバーを設定するために最低限必要なものです:
- RedisサーバーにSSH接続します。
- GitLabダウンロードページから、ステップ1と2を使用して必要なOmnibus GitLabパッケージをダウンロード/インストールします。
- ダウンロードページの他のステップは完了しないでください。
-
/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', }
- 変更を有効にするためにOmnibus GitLab を再設定します。
- 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ドキュメント全体で言及されているトークンは、管理者によって選択された任意のパスワードに過ぎません。 GitLab APIや他の同様のWeb APIトークンのために作成されたトークンとは無関係です。
以下では、1つのGitalyサーバーgitaly1.internal
をシークレットトークンgitalysecret
で設定する方法を説明します。GitLabのインストールには、default
とstorage1
の2つのリポジトリがあると仮定します。
Gitalyサーバーを設定するには:
- GitLabのダウンロードページからステップ1と2を使用して、必要なOmnibus GitLabパッケージをダウンロード/インストールします。ただし、
EXTERNAL_URL
の値は入力しないでください。 -
/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'
-
gitaly1.internal
の/etc/gitlab/gitlab.rb
に以下を追加:git_data_dirs({ 'default' => { 'path' => '/var/opt/gitlab/git-data' }, 'storage1' => { 'path' => '/mnt/gitlab/git-data' }, })
- ファイルを保存し、GitLabを再設定します。
-
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ノードを含む)と、それと通信するすべてのクライアントノードにインストールする必要があります。
listen_addr
と暗号化されたリスニング・アドレスtls_listen_addr
の両方を持つGitalyサーバーを同時に設定することが可能です。 これにより、必要に応じて、暗号化されていないトラフィックから暗号化されたトラフィックへ徐々に移行することができます。GitalyをTLSで設定するには:
-
/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
-
Gitalyが自分自身を呼び出すときに証明書を信頼するように、証明書を
/etc/gitlab/trusted-certs
:sudo cp /etc/gitlab/ssl/cert.pem /etc/gitlab/trusted-certs/
-
/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"
-
gitaly['listen_addr']
を削除して、暗号化された接続のみを許可します。 - ファイルを保存し、GitLabを再設定します。
GitLab Railsの設定
このセクションでは、GitLabアプリケーション(Rails)コンポーネントの設定方法を説明します。 各ノードで以下を実行します:
-
NFSを使用している場合:
-
必要に応じて、以下のコマンドを使用してNFSクライアント・ユーティリティ・パッケージをインストールします:
# Ubuntu/Debian apt-get install nfs-common # CentOS/Red Hat yum install nfs-utils nfs-utils-lib
-
必要なNFSマウントを
/etc/fstab
.NFS/etc/fstab
マウントに指定します。 .NFS/etc/fstab
マウントの正確な内容は/etc/fstab
、NFSサーバーの設定方法によって異なります。 例と各種オプションについては、NFSのドキュメントを参照してください。 -
共有ディレクトリを作成します。 これらは、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
-
- GitLabのダウンロードページのステップ1と2を使用して、Omnibus GitLabをダウンロード/インストールします。 ダウンロードページの他のステップは完了しないでください。
-
/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
-
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' }, })
-
証明書を
/etc/gitlab/trusted-certs
にコピーしてください:sudo cp cert.pem /etc/gitlab/trusted-certs/
-
- ファイルを保存し、GitLabを再設定します。
-
sudo gitlab-rake gitlab:gitaly:check
を実行し、ノードが Gitaly に接続できることを確認します。 -
ログをたどってリクエストを確認してください:
sudo gitlab-ctl tail gitaly
external_url
にhttps
を指定した場合、GitLab は/etc/gitlab/ssl/
に SSL 証明書があるものとみなします。 証明書がない場合、NGINX は起動に失敗します。 詳細はNGINX のドキュメントを参照してください。Prometheus の設定
Omnibus GitLabパッケージを使用すると、PrometheusとGrafanaを実行するスタンドアロンのモニタリングノードを設定できます:
- MonitoringノードにSSH接続します。
- GitLabのダウンロードページから、ステップ1と2を使用して必要なOmnibus GitLabパッケージをダウンロード/インストールします。 ダウンロードページの他のステップは完了しないでください。
-
/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
-
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'], ], }, ]
- ファイルを保存し、GitLabを再設定します。
- GitLab UI で
admin/application_settings/metrics_and_profiling
> Metrics - Grafana を/-/grafana
に設定します。http[s]://<MONITOR NODE>/-/grafana
オブジェクト・ストレージの設定
GitLabは、いくつかのタイプのデータを保持するためにオブジェクトストレージサービスを使うことをサポートしており、NFSよりも推奨されています。 一般的に、オブジェクトストレージの方がパフォーマンス、信頼性、スケーラビリティに優れているため、大規模な環境にはオブジェクトストレージサービスの方が適しています。
GitLabがテストした、または顧客が使用していると認識しているオブジェクトストレージオプションには、以下のものがあります:
- SaaS/クラウドソリューション(Amazon S3やGoogle Cloud Storageなど)。
- さまざまなストレージベンダーが提供するオンプレミスのハードウェアとアプライアンス。
- MinIO(デプロイガイド)。
オブジェクトストレージを使用するようにGitLabを設定するには、使用する機能に応じて以下のガイドを参照してください:
- バックアップ用のオブジェクトストレージ。
- インクリメンタルロギングを含むジョブアーティファクト用のオブジェクトストレージ。
- LFS オブジェクト用のオブジェクトストレージ。
- アップロード用のオブジェクトストレージ。
- マージリクエストの差分のオブジェクトストレージ。
- コンテナレジストリ用のオブジェクトストレージ(オプション機能)。
- Mattermost 用オブジェクトストレージ(オプション機能)。
- パッケージ用のオブジェクトストレージ(オプション機能)。
- 依存プロキシ用のオブジェクトストレージ(オプション機能)。
- Pseudonymizer 用のオブジェクトストレージ(オプション機能)。
- オートスケール Runner キャッシング用オブジェクトストレージ(オプション、パフォーマンス向上用)。
- Terraformステートファイルのオブジェクトストレージ。
GitLabでは、データ型ごとに別々のバケットを使うことが推奨されています。
私たちの構成の限界は、オブジェクトストレージの各使用が個別に設定されていることです。 これを改善するためのイシューがあり、1つのバケットで別々のフォルダを使用できるようになります。
GitLabがHelmチャートでデプロイされているときに単一のバケットを使用すると、バックアップからのリストアが正しく機能しなくなります。 今はHelmデプロイを使用していないかもしれませんが、後でGitLabをHelmデプロイに移行してもGitLabは動作しますが、バックアップが機能するための重要な要件が発生するまで、バックアップが正しく機能していないことに気づかないかもしれません。
NFSの設定(オプション)
パフォーマンスを向上させるために、オブジェクトストレージとGitalyは可能な限りNFSを使うよりも推奨されます。 しかし、GitLab Pagesを使うつもりなら、NFSを使う必要があります。
NFSの設定については、NFSのドキュメントページを参照してください。
トラブルシューティング
トラブルシューティングのドキュメントを参照してください。