インストールシステム要件
このページでは、GitLabをインストールして使用するために最低限必要な要件について説明します。
ハードウェア要件
ストレージ
必要なハードドライブの容量は、GitLabに保存したいリポジトリのサイズに大きく依存しますが、目安としては、すべてのリポジトリを合わせた容量と同じだけの空き容量が必要です。
Linuxパッケージのインストールには約2.5GBのストレージ容量が必要です。
将来的にハードドライブの容量を柔軟に増やしたい場合は、論理ボリューム管理(LVM)を使ってマウントすることを検討し、必要なときにハードドライブを追加できるようにしてください。
ローカルのハードドライブとは別に、ネットワークファイルシステム(NFS) プロトコルをサポートするボリュームをマウントすることもできます。このボリュームは、ファイルサーバー、ネットワークアタッチドストレージ(NAS) デバイス、ストレージエリアネットワーク(SAN) または Amazon Web Services(AWS) Elastic Block Store(EBS) ボリュームにあるかもしれません。
十分なRAMと最近のCPUがあれば、GitLabの速度は主にハードドライブのシーク時間によって制限されます。高速ドライブ(7200RPM以上)またはソリッドステートドライブ(SSD) 、GitLabの応答性が向上します。
CPU
CPUの要件は、ユーザーの数と予想される作業負荷に依存します。正確なニーズは、ワークロードによってさらに増える可能性があります。ワークロードは、ユーザーのアクティビティ、自動化の使用量、ミラーリング、リポジトリ/変更サイズなどの要因に影響されます。
以下は、GitLabのユーザー規模の一例に対する推奨最小CPUハードウェアガイダンスです。
- 4コアが 推奨最小コア数で、500ユーザーまでサポートします。
- 8コアは最大1000ユーザーをサポートします。
- それ以上のユーザー?リファレンスアーキテクチャのページをご覧ください。
メモリ
メモリ要件は、ユーザー数と予想される作業負荷に依存します。ワークロードによっては、より多くのメモリが必要になる場合があります。ワークロードは、ユーザーのアクティビティ、自動化の使用量、ミラーリング、リポジトリ/変更サイズなどの要因に影響されます。
以下は、GitLabユーザー規模の一例に対する推奨最小メモリハードウェアガイダンスです。
-
4 GB RAMが必要最小限のメモリサイズで、500 ユーザーまでサポートします。
- 当社のメモリチームは、メモリ要件の削減に取り組んでいます。
- 8 GB RAMは1000ユーザーまでサポートします。
- それ以上のユーザー?リファレンスアーキテクチャのページをご覧ください。
上記に加えて、現在十分なRAMがある場合でも、一般的にはサーバ上に少なくとも2GBのスワップを持つことをお勧めします。スワップがあると、使用可能なメモリが変更された場合にエラーが発生する可能性を減らすことができます。また、カーネルのスワップ設定を10
のような低い値に設定し、RAM を最大限に活用しつつ、必要なときにスワップを利用できるようにすることをお勧めします。
データベース
PostgreSQLはLinuxパッケージにバンドルされている唯一のサポートされているデータベースです。外部のPostgreSQLデータベースを使用することもできます。
PostgreSQLの要件
PostgreSQLを実行するサーバには、ユーザ数によって異なりますが、_少なくとも_5~10GBのストレージが必要です。Ultimateの場合、1GBの脆弱性データをインポートする必要があるため、サーバーには_少なくとも_12GBのストレージが必要です。
PostgreSQLのバージョンは、開発およびテストに使用されたものであるため、(以下の表で指定されている)最小バージョン以上を使用することを強くお勧めします:
GitLabバージョン | PostgreSQLの最小バージョン |
---|---|
13.0 | 11 |
14.0 | 12.7 |
15.0 | 12.10 |
16.0 | 13.6 |
17.0(予定) | 14.8 |
また、以下の拡張機能がすべてのGitLabデータベースにロードされていることを確認する必要があります。この要件とトラブルシューティングの詳細をご覧ください。
エクステンション | GitLab の最小バージョン |
---|---|
pg_trgm | 8.6 |
btree_gist | 13.1 |
plpgsql | 11.7 |
以下のマネージドPostgreSQLサービスは互換性がないことが知られているため、使用しないでください:
GitLabバージョン | マネージドサービス |
---|---|
14.4+ | アマゾンオーロラ(14.4.0参照) |
GitLab Geoの追加要件
GitLab Geo を使用する場合、Linux パッケージを使用してインストールしたインスタンスを実行することを強くお勧めします。私たちは、(Linuxパッケージのインストールによって管理されていない)ほとんどの内部データベース(例えば、AWS Relational Database Service(RDS) )と互換性があるように努めていますが、互換性を保証することはできません。
オペレーションシステムのロケール互換性とサイレントインデックスの破損
glibc
におけるロケールデータの変更は、PostgreSQLデータベースファイルが異なるOSリリース間で完全な互換性がないことを意味します。
インデックスの破損を避けるために、ロケールの互換性を確認してください:
- PostgreSQLのバイナリデータをサーバ間で移動する場合。
- Linuxディストリビューションのアップグレード。
- サードパーティのコンテナイメージの更新や変更。
クラスター・データベース要件
詳しくはGitaly Clusterのドキュメントをご覧ください。
GitLabデータベースの独占使用
GitLab、Geo、Gitaly Cluster、またはその他のコンポーネントのために作成または使用されるデータベースは、GitLab専用でなければなりません。GitLabドキュメントの手順に従うか、GitLabサポートや他のGitLabエンジニアの指示に従う場合を除き、データベース、スキーマ、ユーザー、その他のプロパティに直接変更を加えないでください。
-
メインのGitLabアプリケーションは現在3つのスキーマを使用しています:
- デフォルトの
public
スキーマ -
gitlab_partitions_static
(自動作成) -
gitlab_partitions_dynamic
(自動作成)
他のスキーマを手動で作成する必要はありません。
- デフォルトの
-
GitLabはRailsデータベースのマイグレーションの一環として新しいスキーマを作成することがあります。これはGitLabのアップグレードを行うときに起こります。これを行うにはGitLabデータベースアカウントへのアクセスが必要です。
-
GitLab はアップグレードの過程でテーブルを作成したり変更したりします。また、パーティショニングされたテーブルを管理するための標準的なオペレーションでもテーブルを作成したり変更したりします。
-
GitLabスキーマを変更してはいけません(例えば、トリガーの追加やテーブルの変更など)。データベースのマイグレーションはGitLabコードベースのスキーマ定義に対してテストされます。スキーマが変更された場合、GitLabのバージョンアップに失敗する可能性があります。
Pumaの設定
Pumaの推奨設定は、実行するインフラストラクチャによって決まります。Linuxパッケージのデフォルトは推奨Puma設定です。インストール方法に関係なく、Pumaの設定を調整することができます:
- Linuxパッケージを使用している場合は、Puma設定の変更方法を参照してください。
- GitLab Helmチャートを使っている場合は、
webservice
chartを参照してください。
Puma ワーカー
推奨労働者数は、以下のうち最も多い人数として計算されます:
2
- CPU とメモリリソースの利用可能性の組み合わせ(Linux パッケージで自動的に設定される方法を参照してください)。
例えば、次のようなシナリオです:
-
2コア/8GBメモリのノードに2台のPumaワーカーを設定します。
として計算されます:
The highest number from 2 And [ the lowest number from - number of cores: 2 - memory limit: (8 - 1.5) = 6 ]
つまり、2と2の中で最も高いのは2です。
-
4コア/4GBメモリのノードは、2Pumaワーカーで設定する必要があります。
The highest number from 2 And [ the lowest number from - number of cores: 4 - memory limit: (4 - 1.5) = 2.5 ]
つまり、2と2の中で最も高いのは2です。
-
4 コア / 8 GB メモリのノードは、4 Puma ワーカーで設定する必要があります。
The highest number from 2 And [ the lowest number from - number of cores: 4 - memory limit: (8 - 1.5) = 6.5 ]
つまり、2 と 4 の最大値は 4 です。
十分な CPU とメモリ容量があれば、Puma ワーカーの数を増やすことができます。通常、Puma ワーカーの数を増やすと、アプリケーションの応答時間が短縮され、並列リクエストの処理能力が向上します。インフラストラクチャに最適な設定を確認するには、テストを行う必要があります。
Puma スレッド
推奨スレッド数は、メモリ総量やレガシーRuggedコードの使用など、いくつかの要因に依存します。
- オペレーティング・システムのメモリが最大 2 GB の場合、推奨スレッド数は
1
です。これより大きな値を設定すると、過剰なスワッピングが発生し、パフォーマンスが低下します。 - レガシー Rugged コードが使用されている場合、推奨スレッド数は
1
です。 - それ以外の場合、推奨スレッド数は
4
です。Ruby MRIのマルチスレッドの動作の関係上、これ以上に設定することはお勧めしません。
Puma per worker 最大メモリ
デフォルトでは、各 Puma ワーカーのメモリは 1.2 GB に制限されています。このメモリ設定は調整可能で、Puma ワーカーの数を増やす必要がある場合は調整する必要があります。
Redis
Redisはすべてのユーザーセッションとバックグラウンドタスクキューを保存します。
Redisの要件は以下のとおりです:
- GitLab 16.0以降ではRedis 6.xまたは7.xが必要です。
- Redisクラスターモードはサポートされていません。Redis Standaloneを使用する必要があります。
- Redisのストレージ要件は最小限で、ユーザーあたり平均約25kBです。
Sidekiq
Sidekiqはバックグラウンドジョブをマルチスレッドプロセスで処理します。このプロセスはRailsスタック全体(200 MB以上)で開始しますが、メモリリークにより時間とともに増大する可能性があります。非常にアクティブなサーバー(請求可能なユーザーが10,000人)では、Sidekiqプロセスが1GB以上のメモリを使用することもあります。
Prometheusとそのエクスポートツール
Prometheusとそれに関連するExporterは、GitLabの詳細な監視を可能にするためにデフォルトで有効になっています。デフォルトの設定では、これらのプロセスは約200MBのメモリを消費します。
Prometheusとそのエクスポートを無効にしたい場合、あるいはもっと詳しい情報を読みたい場合は、Prometheusのドキュメントをご覧ください。
GitLab Runner
GitLabをインストールする予定のマシンと同じマシンにGitLab Runnerをインストールしないことを強くお勧めします。GitLab Runnerをどのように設定するか、またCI環境でアプリケーションを実行するためにどのようなツールを使うかによりますが、GitLab Runnerは利用可能なメモリを大量に消費する可能性があります。
GitLab RunnerとGitLab Railsアプリケーションを同じマシンで実行する場合、上記で利用可能なメモリ消費量の計算は有効ではありません。
また、特にGitLab RunnerでShell Executorを使う予定がある場合、セキュリティ上の理由からすべてを1台のマシンにインストールするのは安全ではありません。
CI機能を使用する予定であれば、GitLab Runnerごとに別のマシンを使用することをお勧めします。GitLab Runnerサーバーの要件は以下によって異なります:
- GitLab Runnerで設定したエクゼキューターの種類。
- ビルドジョブの実行に必要なリソース。
- ジョブの同時実行設定。
ジョブの性質はユースケースごとに異なるため、最適な設定を得るためにはジョブの同時実行数を調整しながら実験する必要があります。
参考までに、Linux上のSaaS Runnerは、1つのジョブが 1つのインスタンスで実行されるように設定されています:
- 1 vCPU。
- 3.75GBのRAM
対応ウェブブラウザ
GitLabは以下のウェブブラウザをサポートしています:
GitLabは以下のブラウザに対応しています:
- 現在および以前のメジャーバージョンのブラウザ。
- サポートされているメジャーバージョンの現在のマイナーバージョン。
セキュリティ
インストール後は、GitLabのセキュアなインストールを維持するためのガイダンスを読み、それに従ってください。