インストールシステム要件

このページでは、GitLabをインストールして使用するために最低限必要な要件について説明します。

ハードウェア要件

ストレージ

必要なハードドライブの容量は、GitLabに保存したいリポジトリのサイズに大きく依存しますが、目安としては、すべてのリポジトリを合わせた容量と同じだけの空き容量が必要です。

Linuxパッケージのインストールには約2.5GBのストレージ容量が必要です。

将来的にハードドライブの容量を柔軟に増やしたい場合は、論理ボリューム管理(LVM)を使ってマウントすることを検討し、必要なときにハードドライブを追加できるようにしてください。

ローカルのハードドライブとは別に、ネットワークファイルシステム(NFS) プロトコルをサポートするボリュームをマウントすることもできます。このボリュームは、ファイルサーバー、ネットワークアタッチドストレージ(NAS) デバイス、ストレージエリアネットワーク(SAN) または Amazon Web Services(AWS) Elastic Block Store(EBS) ボリュームにあるかもしれません。

十分なRAMと最近のCPUがあれば、GitLabの速度は主にハードドライブのシーク時間によって制限されます。高速ドライブ(7200RPM以上)またはソリッドステートドライブ(SSD) 、GitLabの応答性が向上します。

note
ファイルシステムのパフォーマンスはGitLabの全体的なパフォーマンスに影響を与える可能性があるため、クラウドベースのファイルシステムをストレージに使用することはお勧めしません。
note
Git リポジトリストレージ用の NFS は非推奨です。詳しくは公式のサポート声明をご覧ください。

CPU

CPUの要件は、ユーザーの数と予想される作業負荷に依存します。正確なニーズは、ワークロードによってさらに増える可能性があります。ワークロードは、ユーザーのアクティビティ、自動化の使用量、ミラーリング、リポジトリ/変更サイズなどの要因に影響されます。

以下は、GitLabのユーザー規模の一例に対する推奨最小CPUハードウェアガイダンスです。

メモリ

メモリ要件は、ユーザー数と予想される作業負荷に依存します。ワークロードによっては、より多くのメモリが必要になる場合があります。ワークロードは、ユーザーのアクティビティ、自動化の使用量、ミラーリング、リポジトリ/変更サイズなどの要因に影響されます。

以下は、GitLabユーザー規模の一例に対する推奨最小メモリハードウェアガイダンスです。

上記に加えて、現在十分なRAMがある場合でも、一般的にはサーバ上に少なくとも2GBのスワップを持つことをお勧めします。スワップがあると、使用可能なメモリが変更された場合にエラーが発生する可能性を減らすことができます。また、カーネルのスワップ設定を10 のような低い値に設定し、RAM を最大限に活用しつつ、必要なときにスワップを利用できるようにすることをお勧めします。

note
過剰なスワップは望ましくなく、パフォーマンスを低下させますが、メモリ不足の状態に対する非常に重要な最後の手段です。OSのアップデートや同じホスト上の他のサービスなど、予期せぬシステム負荷が発生した場合、メモリ負荷のピークが平均よりはるかに高くなる可能性があります。十分なスワップを持つことは、LinuxのOOMキラーがPostgreSQLのような潜在的に重要なプロセスを安全に終了させることを回避するのに役立ちます。

データベース

PostgreSQLはLinuxパッケージにバンドルされている唯一のサポートされているデータベースです。外部のPostgreSQLデータベースを使用することもできます。

PostgreSQLの要件

PostgreSQLを実行するサーバには、ユーザ数によって異なりますが、_少なくとも_5~10GBのストレージが必要です。Ultimateの場合、1GBの脆弱性データをインポートする必要があるため、サーバーには_少なくとも_12GBのストレージが必要です。

PostgreSQLのバージョンは、開発およびテストに使用されたものであるため、(以下の表で指定されている)最小バージョン以上を使用することを強くお勧めします:

GitLabバージョンPostgreSQLの最小バージョン
13.011
14.012.7
15.012.10
16.013.6
17.0(予定)14.8

また、以下の拡張機能がすべてのGitLabデータベースにロードされていることを確認する必要があります。この要件とトラブルシューティングの詳細をご覧ください。

エクステンションGitLab の最小バージョン
pg_trgm8.6
btree_gist13.1
plpgsql11.7

以下のマネージドPostgreSQLサービスは互換性がないことが知られているため、使用しないでください:

GitLabバージョンマネージドサービス
14.4+アマゾンオーロラ(14.4.0参照)
note
GitLab 13.0ではPostgreSQL 9.6と10のサポートが削除され、GitLabはパーティショニングなどのPostgreSQL 11の改良を利用できるようになりました。

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

対応ウェブブラウザ

caution
GitLab 13.0(2020年5月)より、Internet Explorer 11の公式サポートを終了しました。

GitLabは以下のウェブブラウザをサポートしています:

GitLabは以下のブラウザに対応しています:

  • 現在および以前のメジャーバージョンのブラウザ。
  • サポートされているメジャーバージョンの現在のマイナーバージョン。
note
GitLabではブラウザのJavaScriptを無効にして動作させることはサポートしていませんし、将来的にサポートする予定もありません。

セキュリティ

インストール後は、GitLabのセキュアなインストールを維持するためのガイダンスを読み、それに従ってください。