オブジェクトストレージ

GitLabは多くの種類のデータを保持するためにオブジェクトストレージサービスを使うことをサポートしています。 NFSよりもオブジェクトストレージの方が一般的にパフォーマンスが高く、信頼性が高く、スケーラブルなので、一般的に大規模なセットアップではオブジェクトストレージを使うことが推奨されています。

オプション

GitLabがテストした、または顧客が使用していると認識しているオブジェクトストレージオプションには以下のものがあります：

Amazon S3、GoogleクラウドストレージなどのSaaS/クラウドソリューション。
様々なストレージベンダーのオンプレミスハードウェアとアプライアンス。
MinIOをデプロイする方法はHelm Chartのドキュメントにあります。

設定ガイド

GitLabがObject Storageを使うように設定するには、以下のガイドを参照してください：

バックアップ用にオブジェクトストレージを設定します。
インクリメンタルロギングを含むジョブアーティファクト用のオブジェクトストレージを設定します。
LFSオブジェクトのオブジェクト・ストレージを設定します。
アップロード用のオブジェクトストレージを設定します。
マージリクエスト差分のオブジェクトストレージを設定します。
コンテナレジストリ用のオブジェクトストレージを設定します（オプション機能）。
Mattermost のオブジェクトストレージを設定します (オプション機能)。
パッケージのオブジェクトストレージを設定します（オプション機能）。
依存関係プロキシ（オプション機能）用にオブジェクトストレージを構成します。
Pseudonymizer 用のオブジェクトストレージを設定します（オプション機能）。
オートスケールランナーキャッシング用にオブジェクトストレージを設定します（オプション - パフォーマンス向上のため）。
Terraformステートファイルのオブジェクトストレージの設定

ファイルシステム・ストレージの他の選択肢

GitLabの実装をスケールアウトしたり、フォールトトレランスや冗長性を追加したりする場合は、ブロックファイルシステムやネットワークファイルシステムへの依存を取り除くことを検討しているかもしれません。以下のガイドを参照し、Pagesにはディスクストレージが必要であることに注意してください：

git ユーザーのホームディレクトリが内部ディスクにあることを確認してください。
SSHキーのデータベース検索を設定し、共有authorized_keys ファイルを不要にします。

警告、制限、既知のイシュー

別々のバケツを使用

GitLabでは、データ型ごとに別々のバケットを使うことが推奨されています。

私たちの構成の限界は、オブジェクトストレージの各使用が個別に設定されていることです。私たちはこれを改善するためのイシューを持っており、簡単に1つのバケットを別々のフォルダで使用することは、これがもたらすかもしれない1つの改善です。

GitLabをHelmチャートでデプロイした場合、別々のバケットを使わないとバックアップからのリストアが正しく機能しません。

単一のバケットを使用するリスクの1つは、組織が将来的にGitLabをHelmデプロイに移行することを決定した場合です。 GitLabは実行されますが、バックアップの状況は、組織がバックアップを動作させるための重要な要件が発生するまで気付かないかもしれません。

S3 API互換性のイシュー

すべてのS3プロバイダーがGitLabが使用するFogライブラリーと完全に互換性があるわけではありません。症状は以下の通りです：

411 Length Required

GitLab Pages には NFS が必要です。

もしあなたがスケーリングやフォールトトレランスのためにGitLabサーバーを追加しようとしていて、その要件の一つがGitLabPagesである場合、これは現在NFSを必要とします。この依存関係を取り除く作業が進行中です。将来、GitLab Pagesはオブジェクトストレージを使うかもしれません。

ディスクストレージに依存しているため、GitLab Helmチャートを使ってPagesをデプロイすることもできません。

オブジェクトストレージを使用するCIにはインクリメンタルロギングが必要です。

CIログやアーティファクトにオブジェクトストレージを使うようにGitLabを設定する場合は、インクリメンタルロギングも有効にする必要があります。

プロキシダウンロード

GitクライアントがLFS経由で大きなファイルを要求するときや、CIのアーティファクトやログをダウンロードするときのように、オブジェクトストレージのユースケースの多くでは、クライアントのトラフィックをオブジェクトストレージのバックエンドにリダイレクトすることができます。

ファイルがローカルのブロックストレージやNFSに保存されている場合、GitLabはプロキシとして動作しなければなりません。これはオブジェクトストレージのデフォルトの動作ではありません。

proxy_download 設定はこの動作を制御します。デフォルトは一般的にfalseです。各使用例のドキュメントで確認してください。GitLabがファイルをプロキシするように、true に設定します。

ファイルをプロキシしていない場合、GitLabはHTTP 302リダイレクトを返し、事前に署名された期限付きのオブジェクトストレージURLを返します。その結果、以下のような問題が発生する可能性があります：

GitLabがオブジェクトストレージへのアクセスに非セキュアなHTTPを使用している場合、クライアントがhttps->http ダウングレードエラーを生成し、リダイレクトの処理を拒否することがあります。この解決策は、GitLabがHTTPSを使用することです。例えば、LFSはこのエラーを生成します：
```
 LFS: lfsapi/client: refusing insecure redirect, https->http
```
クライアントは、オブジェクトストレージ証明書を発行した認証局を信頼する必要があります：
```
 x509: certificate signed by unknown authority
```
クライアントは、オブジェクト・ストレージへのネットワーク・アクセスが必要です。このアクセスが適切に行われていない場合に発生する可能性のあるエラーには、以下のようなものがあります：
```
 Received status code 403 from server: Forbidden
```

403 Forbidden レスポンスを得ることは、ビルドツールの動作の副作用として、パッケージリポジトリのドキュメントに明記されています。

ETagの不一致

デフォルトのGitLab設定を使用すると、MinIOや Alibabaなどのオブジェクトストレージバックエンドによっては、ETag mismatch エラーが発生する場合があります。

Amazon Web Services S3 で ETag mismatch エラーが発生する場合、バケットの暗号化設定が原因である可能性があります。このイシューを修正する方法については、Amazonインスタンスプロファイルの使用に関するセクションを参照してください。

GitLabダイレクトアップロードを使用する場合、MinIOの回避策はサーバー上で--compat パラメータを使用することです。

GitLab Workhorseコンポーネントの修正に取り組んでいます。

Amazonインスタンスプロファイルの使用

オブジェクトストレージの設定でAWSのアクセスキーやシークレットキーを提供する代わりに、GitLabはIAMロールを使用してAmazonインスタンスプロファイルを設定することができます。これを使用すると、GitLabはS3バケットにアクセスするたびに一時的な認証情報を取得するので、設定でハードコードされた値は必要ありません。

暗号化されたS3バケット

GitLab 13.1でインスタンスプロファイルのみに導入されました。

インスタンスプロファイルを使用するように設定すると、GitLab WorkhorseはデフォルトでSSE-S3またはSSE-KMS暗号化が有効になっているS3バケットに適切にファイルをアップロードします。 GitLabの設定にキーを供給する必要があるため、カスタマーマスターキー（CMK）とSSE-C暗号化はまだサポートされていないことに注意してください。

インスタンスプロファイルを有効にしていない場合（またはGitLab 13.1以前）、GitLab WorkhorseはContent-MD5 HTTPヘッダが計算されていない署名済みのURLを使ってファイルをS3にアップロードします。データが破損していないことを確認するために、Workhorseは送信されたデータのMD5ハッシュがS3サーバから返されたETagヘッダと等しいことをチェックします。暗号化が有効になっている場合、これは当てはまらず、アップロード中にWorkhorseがETag mismatch エラーを報告する原因となります。

インスタンスプロファイルを有効にすると、GitLab WorkhorseはContent-MD5 ヘッダを適切に計算してサーバに送信するAWS S3クライアントを使用するため、ETagヘッダを比較する必要がなくなります。転送中にデータが破損した場合、S3サーバはファイルを拒否します。

機能の無効化

Workhorse S3 クライアントは、use_iam_profile 設定オプションをtrueに設定すると、デフォルトで有効になります。

:use_workhorse_s3_client この機能を無効にするには、RailsコンソールにアクセスできるGitLab管理者に以下のコマンドを実行してもらいます：

Feature.disable(:use_workhorse_s3_client)

IAM権限

インスタンス・プロファイルを設定するには

必要な権限を持つ Amazon Identity Access and Management(IAM) ロールを作成します。次の例は、test-bucketという名前の S3 バケット用のロールです：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:AbortMultipartUpload",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::test-bucket/*"
        }
    ]
}

GitLabインスタンスをホストしているEC2インスタンスにこのロールをアタッチします。
use_iam_profile 、GitLabがそれを使うように設定してください。例えば、アップロードがオブジェクトストレージを使うように設定する場合は、S3互換接続設定のAWS IAM profiles 。

クリエーションラインについて

私たちクリエーションラインは、日本で最も古く2017年にGitLabサービスの提供を開始し、2022年には「Asia-Pacific Partner of the Year」も獲得。GitLabのサブスクリプション販売やテクニカルサポートだけでなく、GitLab Enterpriseの導入支援やGitLabトレーニングなど多様なサービスを提供し、エンタープライズを中心に豊富な実績を誇ります。GitLabに関するお悩みがありましたら、ぜひお気軽にお問い合わせください。日本で唯一、3度にわたるMVPを獲得したGitLabエバンジェリストをはじめとしたエキスパートチームが、あなたの課題解決をご支援します。