• 要件
• 設定
  • Omnibus インストールの設定
  • ソースからのインストールの設定
• リモート・オブジェクト・ストレージへのLFSオブジェクトの格納
  • オブジェクトストレージへの手動アップロード
  • オムニバス用S3
  • ソースからのインストール用S3
  • ローカルストレージへの移行
• ストレージ統計
• トラブルシューティングGoogle::Apis::TransmissionError: execution expired
• 既知の制限

GitLab Git ラージファイルストレージ(LFS) 管理

Git LFS の使い方のドキュメントは、Managing large binary files with Git LFS docにあります。

要件

• Git LFSはバージョン8.2からGitLabでサポートされています。
• AWS S3などのオブジェクトストレージのサポートは10.0で導入されました。
• gitLFSクライアントのバージョン1.0.1以降をインストールする必要があります。

設定

Git LFSオブジェクトはサイズが大きくなる可能性があります。 デフォルトでは、GitLabがインストールされているサーバーに保存されます。

GitLabサーバー管理者に役立つ様々な設定オプションがあります：

• Git LFS サポートの有効化/無効化
• LFSオブジェクト・ストレージの場所の変更
• Fogがサポートするオブジェクトストレージの設定

Omnibus インストールの設定

/etc/gitlab/gitlab.rb：

# Change to true to enable lfs - enabled by default if not defined
gitlab_rails['lfs_enabled'] = false

# Optionally, change the storage path location. Defaults to
# `#{gitlab_rails['shared_path']}/lfs-objects`. Which evaluates to
# `/var/opt/gitlab/gitlab-rails/shared/lfs-objects` by default.
gitlab_rails['lfs_storage_path'] = "/mnt/storage/lfs-objects"

ソースからのインストールの設定

config/gitlab.yml：

# Change to true to enable lfs
  lfs:
    enabled: false
    storage_path: /mnt/storage/lfs-objects

リモート・オブジェクト・ストレージへのLFSオブジェクトの格納

GitLab Premium10.0で導入され、10.7でGitLab Coreに導入されました。

LFSオブジェクトをリモートオブジェクトストレージに保存することが可能で、ローカルのハードディスクのR/Wオペレーションをオフロードし、ディスクスペースを大幅に解放することができます。 GitLabはFogと密接にインテグレーションされているため、そのドキュメントを参照して、どのストレージサービスがGitLabとインテグレーションできるかを確認することができます。 また、非公開ローカルネットワークで外部のオブジェクトストレージを使用することもできます。 例えば、MinIOはスタンドアロンのオブジェクトストレージサービスで、セットアップが簡単で、GitLabインスタンスとうまく機能します。

GitLabはアップロードの仕組みに “Direct upload “と “Background upload “の2つの異なるオプションを提供しています。

GitLabでのオブジェクトストレージの使用についてはこちらをご覧ください。

オプション1.直接アップロード

1. ユーザはlfs ファイルを GitLab インスタンスにプッシュします。
2. GitLab-workhorseはファイルを外部オブジェクトストレージに直接アップロードします。
3. GitLab-workhorse は GitLab-rails にアップロードが完了したことを通知します。

オプション2.バックグラウンドアップロード

1. ユーザはlfs ファイルを GitLab インスタンスにプッシュします。
2. GitLab-railsはローカルファイルストレージにファイルを保存します。
3. GitLab-railsは次にファイルを外部オブジェクトストレージに非同期にアップロードします。

以下の一般的な設定がサポートされています。

connection の設定はフォグが提供する設定と同じです。

S3を使った設定例です。

以下はGCSを使った設定例です。

以下は、Rackspace Cloud Filesを使用した設定例です。

オブジェクトストレージへの手動アップロード

自動アップロード（上述）と同じことを手動で行うには、2つの方法があります。

オプション1：レーキ作業

gitlab-rake gitlab:lfs:migrate

オプション 2: Rails コンソール

Railsコンソールにログインします：

sudo gitlab-rails console

LFSファイルを手動でアップロード

LfsObject.where(file_store: [nil, 1]).find_each do |lfs_object|
  lfs_object.file.migrate!(ObjectStorage::Store::REMOTE) if lfs_object.file.file.exists?
end

オムニバス用S3

Omnibus のインストールでは、設定の前にlfs_object_store_が付きます：

1. /etc/gitlab/gitlab.rb を編集し、以下の行を必要な値に置き換えて追加します：

   gitlab_rails['lfs_object_store_enabled'] = true
   gitlab_rails['lfs_object_store_remote_directory'] = "lfs-objects"
   gitlab_rails['lfs_object_store_connection'] = {
     'provider' => 'AWS',
     'region' => 'eu-central-1',
     'aws_access_key_id' => '1ABCD2EFGHI34JKLM567N',
     'aws_secret_access_key' => 'abcdefhijklmnopQRSTUVwxyz0123456789ABCDE',
     # The below options configure an S3 compatible host instead of AWS
     'host' => 'localhost',
     'endpoint' => 'http://127.0.0.1:9000',
     'path_style' => true
   }
   

2. ファイルを保存し、変更を有効にするために GitLab を再設定します。

3. 既存のローカルLFSオブジェクトをオブジェクト・ストレージに移行します：

   gitlab-rake gitlab:lfs:migrate
   

   これは、既存の LFS オブジェクトをオブジェクト・ストレージに移行します。新しい LFS オブジェクトは、gitlab_rails['lfs_object_store_background_upload'] が false に設定されていない限り、オブジェクト・ストレージに転送されます。

ソースからのインストール用S3

ソース・インストールの場合、設定はlfs: の下にネストされ、次にobject_store:の下にネストされます：

1. /home/git/gitlab/config/gitlab.yml を編集し、以下の行を追加または修正してください：

   lfs:
   enabled: true
   object_store:
     enabled: false
     remote_directory: lfs-objects # Bucket name
     connection:
       provider: AWS
       aws_access_key_id: 1ABCD2EFGHI34JKLM567N
       aws_secret_access_key: abcdefhijklmnopQRSTUVwxyz0123456789ABCDE
       region: eu-central-1
       # Use the following options to configure an AWS compatible host such as Minio
       host: 'localhost'
       endpoint: 'http://127.0.0.1:9000'
       path_style: true
   

2. ファイルを保存し、GitLabを再起動して変更を有効にします。

3. 既存のローカルLFSオブジェクトをオブジェクト・ストレージに移行します：

   sudo -u git -H bundle exec rake gitlab:lfs:migrate RAILS_ENV=production
   

   これは、既存の LFS オブジェクトをオブジェクト・ストレージに移行します。新しい LFS オブジェクトは、background_upload が false に設定されていない限り、オブジェクト・ストレージに転送されます。

ローカルストレージへの移行

ローカルストレージに戻すには

1. LFSオブジェクトストレージの設定で、direct_upload とbackground_upload の両方をfalseに設定します。 GitLabを再起動することを忘れないでください。
2. コンソールでrake gitlab:lfs:migrate_to_local を実行してください。
3. gitlab.rbの LFS オブジェクトのobject_storage を無効にします。 その後、GitLab を再起動することを忘れないでください。

ストレージ統計

グループやプロジェクトで LFS オブジェクトに使用されているストレージの合計は、管理領域やグループ、プロジェクトの APIで確認できます。

トラブルシューティングGoogle::Apis::TransmissionError: execution expired

LFSインテグレーションがGoogle Cloud Storageとバックグラウンドアップロード(background_upload: true とdirect_upload: false)で設定されている場合、Sidekiqワーカーはこのエラーに遭遇する可能性があります。 これは、非常に大きなファイルでアップロードがタイムアウトするためです。 6GbまでのLFSファイルは余分なステップなしでアップロードできますが、そうでない場合は以下の回避策を使用する必要があります。

Railsコンソールにログインします：

sudo gitlab-rails console

タイムアウトの設定

• 例えば、Sidekiqワーカーには有効ではありません。
• 30GBのLFSファイルをアップロードするには、20分（1200秒）で十分です：

::Google::Apis::ClientOptions.default.open_timeout_sec = 1200
::Google::Apis::ClientOptions.default.read_timeout_sec = 1200
::Google::Apis::ClientOptions.default.send_timeout_sec = 1200

LFSファイルを手動でアップロードします（このプロセスではSidekiqは一切使用しません）：

LfsObject.where(file_store: [nil, 1]).find_each do |lfs_object|
  lfs_object.file.migrate!(ObjectStorage::Store::REMOTE) if lfs_object.file.file.exists?
end

19581の詳細を見る

既知の制限

• 参照されていないLFSオブジェクトの削除のサポートが8.14以降で追加されました。
• SSH経由のLFS認証がGitLab 8.12で追加されました。
• Git LFS クライアントのバージョン 1.1.0 以降、または 1.0.2 とのみ互換性があります。
• ストレージ統計は現在、各LFSオブジェクトを、そのオブジェクトにリンクしているプロジェクトごとに複数回カウントしています。