リポジトリ保存タイプ
- GitLab 10.0で導入されました。
- GitLab 12.0でハッシュストレージが新規インストールのデフォルトになりました。
- GitLab 13.0では、新規プロジェクトとリネームプロジェクトでハッシュストレージがデフォルトで有効になっています。
GitLabは、1つまたは複数のリポジトリストレージパス/シャードロケーションを使用するように設定できます：
- ローカルディスクにマウント
- NFS共有ボリュームとして公開
- 独自のマシンでGitaly経由でアクセス。
GitLabでは、これは/etc/gitlab/gitlab.rb 、git_data_dirs({})設定ハッシュによって設定されます。ここで説明するストレージレイアウトは、この中で定義されたどのシャードにも適用されます。
default リポジトリシャードは、カスタマイズしていないインストールで利用可能で、ローカルフォルダを指しています:/var/opt/gitlab/git-data. 以下に説明するものはすべて、そのフォルダの一部であることが期待されます。
ハッシュストレージ
ハッシュストレージは、10.0で導入されたストレージの動作です。プロジェクトのURLとリポジトリがディスクに保存されるフォルダ構造を結合する代わりに、プロジェクトのIDに基づいたハッシュを結合しています。 これにより、フォルダ構造が不変になり、URLからディスク構造への状態の同期が不要になります。 つまり、グループ、ユーザー、プロジェクトの名前を変更すると、データベーストランザクションのみがコストとなり、すぐに反映されます。
ハッシュを使用すると、リポジトリがディスク上に均等に分散されるため、トップレベル・ディレクトリに含まれるフォルダの数は、トップレベル・ネームスペースの総量よりも少なくなります。
ハッシュ形式は、SHA256の16進数表現に基づいています。SHA256(project.id)。トップレベルのフォルダーは最初の2文字を使用し、次の2文字で別のフォルダーが続きます。既存のLegacy Storageプロジェクトと共存できるように、これらは両方とも特別な@hashed フォルダーに保存されます：
# Project's repository:
"@hashed/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"
# Wiki's repository:
"@hashed/#{hash[0..1]}/#{hash[2..3]}/#{hash}.wiki.git"
ハッシュ化されたストレージパスの変換
git リポジトリのトラブルシューティングやフックの追加、その他の作業では、人間が読めるプロジェクト名とハッシュ化されたストレージパスとの翻訳が必要になります。
プロジェクト名からハッシュパスへ
ハッシュ化されたパスは管理エリアのプロジェクトのページに表示されます。
プロジェクトページにアクセスするには、管理エリア > 概要 > プロジェクトと進み、プロジェクトのページを開きます。
例えば「Gitaly相対パス」がそこに表示されています：
"@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"
これは、デフォルトの Omnibus インストールの/var/opt/gitlab/git-data/repositories/ 以下のパスです。
Railsコンソールでは、数値のプロジェクトIDかフルパスを使ってこの情報を取得します：
Project.find(16).disk_path
Project.find_by_full_path('group/project').disk_path
ハッシュ化されたパスからプロジェクト名へ
ハッシュ化されたストレージパスからプロジェクト名に変換する場合：
- Railsコンソールを起動します。
- 以下を実行してください：
ProjectRepository.find_by(disk_path: '@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9').project
このコマンドの引用符で囲まれた文字列は、GitLabサーバー上のディレクトリツリーです。 たとえば、デフォルトのOmnibusインストールでは、ディレクトリ名の末尾から.git を取り除いた/var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.gitとなります。
プロジェクトIDとプロジェクト名が出力されます：
=> #<Project id:16 it/supportteam/ticketsystem>
ハッシュド・オブジェクト・プール
GitLab 12.1で導入されました。
git prune またはgit gc を実行しないでください! これは、問題のプールに依存している「実際の」リポジトリでデータ損失を引き起こす可能性があります。公開プロジェクトのフォークは、ソースプロジェクトのオブジェクトを格納する第三のリポジトリ、オブジェクトプールを作成することで重複排除されます。objects/info/alternates、ソースプロジェクトとフォークはオブジェクトプールを共有オブジェクトに使用します。ハウスキーピングがソースプロジェクトで実行されると、オブジェクトはソースプロジェクトからオブジェクトプールに移動されます。
# object pool paths
"@pools/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"
ハッシュ化ストレージのカバレッジ移行
S3と互換性のあるエンドポイントに保存されたファイルは、#{namespace}/#{project_name}（CI CacheとLFS Objectsに当てはまる）がプレフィックスとして付いていなければ、前述のようなデメリットはありません。
以下の表で、ハッシュ化されたストレージへの移行範囲を確認できます。
| 保存可能なオブジェクト | レガシーストレージ | ハッシュストレージ | S3対応 | GitLab バージョン |
|---|---|---|---|---|
| リポジトリ | はい | はい | - | 10.0 |
| 付属品 | はい | はい | - | 10.2 |
| アバター | はい | いいえ | - | - |
| Pages | はい | いいえ | - | - |
| ドッカーレジストリ | はい | いいえ | - | - |
| CI ビルドログ | いいえ | いいえ | - | - |
| CIアーティファクト | いいえ | いいえ | はい | 9.4 / 10.6 |
| CIキャッシュ | いいえ | いいえ | はい | - |
| LFSオブジェクト | はい | 類似 | はい | 10.0 / 10.7 |
| リポジトリプール | いいえ | はい | - | 11.6 |
アバター
各ファイルはデータベースからid 、フォルダに保存されます。ファイル名はユーザーアバターの場合、常にavatar.png 。アバターが入れ替わると、Upload モデルは破棄され、異なるidで新しいものが作成されます。
CIアーティファクト
CIアーティファクトは9.4（GitLab Premium）からS3に対応し、GitLab Coreでは10.6から利用できます。
LFSオブジェクト
GitLabのLFSオブジェクトは、Git自身の実装に従って、2文字、2レベルのフォルダを使った同様の保存パターンを実装しています：
"shared/lfs-objects/#{oid[0..1}/#{oid[2..3]}/#{oid[4..-1]}"
# Based on object `oid`: `8909029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c`, path will be:
"shared/lfs-objects/89/09/029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c"
LFSオブジェクトはS3にも対応しています。
レガシーストレージ
レガシーストレージはバージョン10.0以前のストレージの動作です。歴史的な理由から、GitLabはプロジェクトのURLから同じマッピング構造を複製していました：
- プロジェクトのリポジトリ：
#{namespace}/#{project_name}.git - プロジェクトのウィキ：
#{namespace}/#{project_name}.wiki.git
この構造により、既存のソリューションからGitLabへの移行が簡単になり、管理者もリポジトリの保存場所を見つけやすくなりました。
一方、これには欠点もあります：
この影響は、複数のストレージ・パスを導入することで軽減できます。
バックアップは同じURLマッピングのスナップショットであるため、非常に古いバックアップを復元しようとする場合、同じURLを共有する古い削除または名前変更されたプロジェクトの代わりに、プロジェクトが使用されているかどうかを確認する必要があります。 つまり、バックアップのmygroup/myproject 、現在同じURLにある元のプロジェクトとは異なる可能性があります。
グループ/ユーザーやプロジェクトの名前が変更された場合）URLの変更はディスクに反映される必要があります。 これは、特にネットワークベースのファイルシステムを使用している場合、大規模なインストールで多くの負荷を追加する可能性があります。
