GitLabのインストール要件
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
GitLabには、固有のインストール要件があります。
ストレージ
必要とされるストレージ容量は、主にGitLabに格納するリポジトリのサイズによって異なります。ガイドラインとして、最低でも、すべてのリポジトリの合計と同じくらいの空き容量が必要です。
Linuxパッケージのインストールには、約2.5 GBのストレージ容量が必要です。ストレージの柔軟性を高めるには、論理ボリューム管理を通じてハードドライブをマウントすることを検討してください。応答時間を短縮するために、7,200 RPM以上のハードドライブ、またはソリッドステートドライブが必要です。
ファイルシステムのパフォーマンスはGitLabの全体的なパフォーマンスに影響を与える可能性があるため、ストレージにクラウドベースのファイルシステムを使用することは避けてください。
CPU
CPU要件は、ユーザー数と予想されるワークロードによって異なります。ワークロードには、ユーザーのアクティビティー、自動化とミラーリングの使用、リポジトリのサイズが含まれます。
最大で1秒あたり20リクエストまたは1,000ユーザーの場合、8 vCPUが必要です。それ以上のユーザー数またはワークロードについては、リファレンスアーキテクチャを参照してください。
メモリ
メモリ要件は、ユーザー数と予想されるワークロードによって異なります。ワークロードには、ユーザーのアクティビティー、自動化とミラーリングの使用、リポジトリのサイズが含まれます。
最大で1秒あたり20リクエストまたは1,000ユーザーの場合、16 GBのメモリが必要です。それ以上のユーザー数またはワークロードについては、リファレンスアーキテクチャを参照してください。
場合によっては、GitLabは最低8 GBのメモリで実行できます。詳細については、メモリ制約のある環境でGitLabを実行するを参照してください。
PostgreSQL
PostgreSQLは、サポートされている唯一のデータベースであり、Linuxパッケージにバンドルされています。外部のPostgreSQLデータベースも使用できますが、その場合は正しく設定する必要があります。
ユーザー数に応じて、PostgreSQLサーバーには以下が必要です:
- ほとんどのGitLabインスタンスでは、最低5～10 GBのストレージ
- GitLab Ultimateの場合、最低12 GBのストレージ（1 GBの脆弱性データをインポートする必要があります）
次のバージョンのGitLabでは、対応するPostgreSQLバージョンを使用してください:
| GitLabバージョン | Helmチャートバージョン | PostgreSQLの最小バージョン | PostgreSQLの最大バージョン |
|---|---|---|---|
| 18.x | 9.x | 16.5 | 17.x（GitLab 17.10以降に対してテスト済み） |
| 17.x | 8.x | 14.14 | 16.x（GitLab 16.10以降に対してテスト済み） |
| 16.x | 7.x | 13.6 | 15.x（GitLab 16.1以降に対してテスト済み） |
| 15.x | 6.x | 12.10 | 14.x（GitLab 15.11に対してのみテスト済み）、13.x |
PostgreSQLのマイナーリリースには、バグとセキュリティの修正のみが含まれます。PostgreSQLで既知のイシューを回避するため、常に最新のマイナーバージョンを使用してください。詳細については、イシュー364763を参照してください。
指定されているバージョンよりも新しいPostgreSQLのメジャーバージョンを使用するには、新しいバージョンがLinuxパッケージにバンドルされているかどうかを確認してください。
また、一部の拡張機能をすべてのGitLabデータベースに読み込む必要があります。詳細については、PostgreSQL拡張機能を管理するを参照してください。
GitLab Geo
GitLab Geoは、Linuxパッケージまたは検証済みのクラウドプロバイダーを使用してGitLabをインストールする必要があります。他の外部データベースとの互換性は保証されていません。
詳細については、Geoの実行要件を参照してください。
ロケールの互換性
glibcでロケールデータを変更すると、PostgreSQLデータベースファイルは、異なるオペレーティングシステム間では完全な互換性がなくなります。インデックスの破損を回避するには、以下の場合にロケールの互換性を確認してください:
- サーバー間でバイナリPostgreSQLデータを移動する。
- Linuxディストリビューションをアップグレードする。
- サードパーティのコンテナイメージを更新または変更する。
詳細については、PostgreSQLのオペレーティングシステムのアップグレードを参照してください。
GitLabスキーマ
GitLab、Geo 、Gitaly Cluster (Praefect)、またはその他のコンポーネント専用のデータベースを作成または使用する必要があります。以下に従う場合を除き、データベース、スキーマ、ユーザー、またはその他のプロパティを作成または変更しないでください:
- GitLabドキュメントの手順
- GitLabサポートまたはエンジニアの指示
主なGitLabアプリケーションは、3つのスキーマを使用します:
- デフォルトの
publicスキーマ gitlab_partitions_static（自動作成）gitlab_partitions_dynamic（自動作成）
Railsデータベースの移行中に、GitLabはスキーマまたはテーブルを作成または変更する場合があります。データベースの移行は、GitLabコードベースのスキーマ定義に対してテストされます。スキーマを変更すると、GitLabのアップグレードが失敗する可能性があります。
PostgreSQLの設定
外部で管理されるPostgreSQLインスタンスに必要な設定を次に示します。
| 調整可能な設定 | 必要な値 | 詳細情報 |
|---|---|---|
work_mem | 最小8 MB | この値は、Linuxパッケージのデフォルトです。大規模なデプロイメントで、クエリが一時ファイルを作成する場合は、この設定を増やす必要があります。 |
maintenance_work_mem | 最小64 MB | 大規模なデータベースサーバーの場合は、より多くの容量が必要です。 |
max_connections | 最小400 | お使いのGitLabコンポーネントに基づいて計算します。詳細なガイダンスについては、Tune PostgreSQLページを参照してください。 |
shared_buffers | 最小2 GB | 大規模なデータベースサーバーの場合は、より多くの容量が必要です。Linuxパッケージのデフォルトは、サーバーRAMの25%に設定されています。 |
statement_timeout | 15000～60000 | ステートメントのタイムアウトにより、ロックによる制御不能イシューや、データベースが新しいクライアントを拒否するのを回避できます。15～60秒（15000～60000ミリ秒）の範囲の値を使用してください。1分はPumaラックのタイムアウト設定と一致します。 |
hot_standby_feedback | on | 複数のノードでデータベースロードバランシングが構成されている構成では、すべてのレプリカノードでhot_standby_feedbackを有効にして、ラグの発生を防ぐようにしてください。 |
サーバー上のすべてのデータベースではなく、特定のデータベースに対して一部のPostgreSQL設定を設定できます。
- 同じサーバー上で複数のデータベースをホスティングする場合、特定のデータベースに設定を制限できます。
- 設定の適用場所に関するガイダンスについては、データベース管理者またはベンダーにお問い合わせください。
- GCP Cloud SQLの場合、特定のデータベースまたはユーザーに対して
statement_timeoutを設定できますが、as a database flag（データベースフラグとして）は設定できません。例:ALTER DATABASE gitlab SET statement_timeout = '60s';。
Puma
推奨されるPuma設定は、インストールによって異なります。デフォルトでは、Linuxパッケージは推奨設定を使用します。
Pumaの設定を調整するには:
- Linuxパッケージについては、Puma設定を参照してください。
- GitLab Helmチャートについては、
webserviceチャートを参照してください。
ワーカー
推奨されるPumaワーカーの数は、主にCPUとメモリの容量によって異なります。デフォルトでは、Linuxパッケージは推奨される数のワーカーを使用します。この数の計算方法について詳しくは、puma.rbを参照してください。
ノードのPumaワーカー数は2つ以上でなければなりません。たとえば、ノードには以下が必要です:
- 2 CPUコアと8 GBのメモリに対して2個のワーカー
- 4 CPUコアと4 GBのメモリに対して2個のワーカー
- 4 CPUコアと8 GBのメモリに対して4個のワーカー
- 8 CPUコアと8 GBのメモリに対して6個のワーカー
- 8 CPUコアと16 GBのメモリに対して8個のワーカー
デフォルトでは、各Pumaワーカーは1.2 GBのメモリに制限されています。/etc/gitlab/gitlab.rbでこの設定を調整できます。
十分なCPUおよびメモリ容量がある場合は、Pumaワーカーの数を増やすこともできます。ワーカー数を増やすと、応答時間が短縮され、並列リクエストを処理する能力が向上します。テストを実行して、インストールに最適なワーカーの数を確認します。
スレッド
推奨されるPumaスレッド数は、システムメモリの合計によって異なります。ノードは以下を使用する必要があります:
- 最大2 GBのメモリを持つオペレーティングシステムの場合は1つのスレッド
- 2 GBを超えるメモリを持つオペレーティングシステムの場合は4つのスレッド
スレッドをそれ以上増やすと、過度のスワップが発生し、パフォーマンスが低下します。
Redis
Redisは、すべてのユーザーセッションとバックグラウンドタスクを保存し、平均してユーザーあたり約25 kBを必要とします。
GitLab 16.0以降では、Redis 6.xまたは7.xが必要です。サポート終了日について詳しくは、Redisドキュメントを参照してください。
Redisでは:
- スタンドアロンインスタンスを使用します（高可用性の有無にかかわらず）。Redisクラスターはサポートされていません。
- 必要に応じて削除ポリシーを設定します。
Sidekiq
Sidekiqは、バックグラウンドジョブにマルチスレッドプロセスを使用します。このプロセスでは、最初は200 MB以上のメモリを消費し、メモリリークが原因で時間とともに増加する可能性があります。
請求対象ユーザーが10,000人を超える非常にアクティブなサーバーでは、Sidekiqプロセスで1 GB以上のメモリを消費する可能性があります。
Prometheus
デフォルトでは、Prometheusとその関連exporterはGitLabをモニタリングするために有効になっています。これらのプロセスは、約200 MBのメモリを消費します。
詳細については、Prometheusを使用したGitLabのモニタリングを参照してください。
サポートされているWebブラウザ
GitLabは、次のWebブラウザをサポートしています:
GitLabがサポートするもの:
- これらのブラウザの最新の2つのメジャーバージョン
- サポートされているメジャーバージョンの現在のマイナーバージョン
これらのブラウザでJavaScriptを無効にしてGitLabを実行することはサポートされていません。