Geoデータ型のサポート
Geoデータ型は、関連情報を格納するために1つ以上のGitLab機能で必要とされるデータの特定のクラスです。
これらの機能によって生成されたデータをGeoで再現するために、私たちはいくつかの戦略を使ってアクセス、転送、検証を行っています。
データタイプ
現在、私たちは3つの異なるデータタイプを区別しています:
レプリケートする各機能やコンポーネント、対応するデータタイプ、レプリケーション、検証方法については、以下のリストをご覧ください:
タイプ | 機能/コンポーネント | 複製方法 | 検証方法 |
---|---|---|---|
データベース | PostgreSQLのアプリケーションデータ | ネイティブ | ネイティブ |
データベース | Redis | 該当なし(1) | 該当なし |
データベース | Elasticsearch | ネイティブ | ネイティブ |
データベース | 個人的なスニペット | PostgreSQLレプリケーション | PostgreSQLレプリケーション |
データベース | プロジェクトのスニペット | PostgreSQLレプリケーション | PostgreSQLレプリケーション |
データベース | SSH公開キー | PostgreSQLレプリケーション | PostgreSQLレプリケーション |
Git | プロジェクトリポジトリ | Geo with Gitaly | Gitalyチェックサム |
Git | プロジェクトwikiリポジトリ | Geo with Gitaly | Gitalyチェックサム |
Git | プロジェクトデザインリポジトリ | Geo with Gitaly | Gitalyチェックサム |
Git | フォークされたプロジェクトの重複排除のためのオブジェクトプール | Geo with Gitaly | 未実施 |
ブロブ | ユーザーのアップロード_(ファイルシステム)_ | GeoとAPI | 未実施 |
ブロブ | ユーザーのアップロード_(オブジェクトストレージ)_ | Geo with API/Managed(2) | 未実施 |
ブロブ | LFSオブジェクト_(ファイルシステム)_ | GeoとAPI | 未実施 |
ブロブ | LFSオブジェクト_(オブジェクトストレージ)_ | Geo with API/Managed(2) | 未実施 |
ブロブ | CIジョブのアーティファクト_(ファイルシステム)_ | GeoとAPI | 未実施 |
ブロブ | CIジョブのアーティファクト_(オブジェクトストレージ)_ | Geo with API/Managed(2) | 未実施 |
ブロブ | CIビルドトレースのアーカイブ_(ファイルシステム)_ | GeoとAPI | 未実施 |
ブロブ | CIビルドトレースのアーカイブ_(オブジェクトストレージ)_ | Geo with API/Managed(2) | 未実施 |
ブロブ | コンテナレジストリ_(ファイルシステム)_ | API/ドッカーAPIを使用したGeo | 未実施 |
ブロブ | コンテナレジストリ_(オブジェクトストレージ)_ | API/Managed/Docker APIを使用したGeo(2) | 未実施 |
ブロブ | パッケージレジストリ_(ファイルシステム)_ | GeoとAPI | 未実施 |
ブロブ | パッケージレジストリ_(オブジェクトストレージ)_ | Geo with API/Managed(2) | 未実施 |
- (1): RedisレプリケーションはRedisセンチネルとHAの一部として使用できます。 Geoノード間では使用されません。
- (2): オブジェクト ストレージのレプリケーションは、Geo またはオブジェクト ストレージ プロバイダ/アプライアンスのネイティブ レプリケーション機能によって実行できます。
Gitリポジトリ
GitLabインスタンスは1つ以上のリポジトリシャードを持つことができます。 各シャードにはGitalyインスタンスがあり、ローカルに保存されたGitリポジトリへのアクセスとオペレーションを担当します。 シングルディスク、複数のディスクを(RAIDアレイのように)単一のマウントポイントとしてマウントしたマシン、あるいはLVMを使って実行することができます。
特別なファイルシステムを必要とせず、NFSまたはマウントされたストレージアプライアンスで動作します(リモートファイルシステムを使用する場合、パフォーマンスに制限がある場合があります)。
通信はGitaly独自のgRPC APIを介して行われます。 同期には3つの方法があります:
- あるGeoノードから別のGeoノードへの通常のGit clone/fetchを使用します(特別な認証が必要です)。
- リポジトリスナップショットの使用(最初の方法が失敗した場合、またはリポジトリが破損した場合)。
- 管理者UIからの手動トリガー(上記の両方の組み合わせ)。
各プロジェクトは最大3つの異なるリポジトリを持つことができます:
- プロジェクトのリポジトリで、ソースコードが保存されています。
- wikiリポジトリ、wikiコンテンツが保存される場所。
- 設計リポジトリ。設計アーティファクトがインデックス化されています(アセットは実際にはLFSにあります)。
これらはすべて同じシャード内に存在し、Wikiとデザインリポジトリの場合は-wiki
と-design
のサフィックスを持つ同じベース名を共有します。
ブロブ
GitLabはファイルやイシューの添付ファイルやLFSオブジェクトのようなブロブをどちらかに保存します:
- 特定の場所のファイルシステム。
-
オブジェクト・ストレージ・ソリューションオブジェクト・ストレージ・ソリューションには、次のようなものがあります:
- Amazon S3 Google Cloud Storageのようなクラウドベース。
- (MinIOのように)あなたによってホストされます。
- Object Storage互換のAPIを公開するストレージ・アプライアンス。
Object Storageの代わりにファイルシステムストアを使用する場合、複数のサーバーを使用してGitLabを実行するには、ネットワークマウントされたファイルシステムを使用する必要があります。
複製と検証に関して
- 内部APIリクエストを使ってファイルやブロブを転送します。
- オブジェクト・ストレージでは、以下のことが可能です:
- クラウドプロバイダのレプリケーション機能を使用します。
- GitLabに複製してもらいましょう。
データベース
PostgreSQLは、イシューの内容やコメント、権限や認証情報のような、Webインターフェイスでユーザーが作成したコンテンツのための単一の真実のポイントです。
PostgreSQLは、HTMLレンダリングされたMarkdown、キャッシュされたマージリクエストの差分(これはオブジェクトストレージにオフロードされるように設定することもできます)のような、ある程度のレベルのキャッシュデータを保持することもできます。
PostgreSQL独自のレプリケーション機能を使用して、プライマリノードから セカンダリノードへデータを複製します。
私たちはRedisをキャッシュストアとして、またバックグラウンドジョブシステム用の永続的なデータを保持するために使用しています。 どちらの用途でも同じGeoノード専用のデータがあるため、ノード間でデータを複製することはありません。
Elasticsearch はオプションのデータベースで、ソースコードレベルと、イシュー/マージリクエストやディスカッションのユーザー生成コンテンツの両方で、改善されたグローバル検索のような高度な検索機能を有効にすることができます。 現在、Geo ではサポートされていません。
複製・検証の制限
次の表は、GitLabの機能とセカンダリノードでのレプリケーションと検証のステータスの一覧です。
これらのエピック/イシューに欠けている項目を実装するための進捗状況を把握することができます:
機能 | 複製(GitLabバージョンで追加) | 検証済み (GitLabバージョンで追加) | 備考 | |
---|---|---|---|---|
PostgreSQLのアプリケーションデータ | はい(10.2) | はい(10.2) | ||
プロジェクトリポジトリ | はい(10.2) | はい(10.7) | ||
プロジェクトwikiリポジトリ | はい(10.2) | はい(10.7) | ||
プロジェクトデザインリポジトリ | はい(12.7) | いいえ | ||
アップロードファイル | はい(10.2) | いいえ | 転送時のみ、または手動で確認(1) | |
LFSオブジェクト | はい(10.2) | いいえ | 11.11.xおよび12.0.xの新しいLFSオブジェクトでは使用できません(2**)。 | |
CIジョブのアーティファクト(トレース以外) | はい(10.4) | いいえ | 手動でのみ検証(1) | |
アーカイブされた痕跡 | はい(10.4) | いいえ | 転送時のみ、または手動で確認(1) | |
個人的なスニペット | はい(10.2) | はい(10.2) | ||
バージョン管理されたスニペット | いいえ | いいえ | ||
プロジェクトのスニペット | はい(10.2) | はい(10.2) | ||
フォークされたプロジェクトの重複排除のためのオブジェクトプール | はい | いいえ | ||
サーバーサイドの Git フック | いいえ | いいえ | ||
Elasticsearchインテグレーション | いいえ | いいえ | ||
GitLab Pages | いいえ | いいえ | ||
コンテナレジストリ | はい(12.3) | いいえ | ||
npmレジストリ | はい(13.2) | いいえ | ||
Mavenリポジトリ | はい(13.2) | いいえ | ||
コナン・リポジトリ | はい(13.2) | いいえ | ||
NuGetリポジトリ | はい(13.2) | いいえ | ||
PyPiリポジトリ | はい(13.2) | いいえ | ||
Composer リポジトリ | はい(13.2) | いいえ | ||
外部マージリクエストの差分 | いいえ | いいえ | ||
テラフォームの状態 | いいえ(3) | いいえ | ||
脆弱性輸出 | いいえ(3) | いいえ | ||
オブジェクトストレージ内のコンテンツ | はい(12.4) | いいえ |
- (1):インテグリティ・チェック・タスク(Integrity Check Rake Task)を両ノードに適用し、両ノードの出力を比較することで、手動でインテグリティを検証できます。
- (2): GitLabのバージョン11.11.xと12.0.xには、新しいLFSオブジェクトのレプリケーションを妨げるバグがあります。
- (3): Object Storage を使用している場合、サポートされていれば、Object Storage プロバイダーがレプリケーションを実行できます。 Geowith Object Storageを参照してください。