GitとCI/CDに関する知識ゼロのSEが、GitLabのストレージ節約のために統合オブジェクトストレージ構成を試す ～Amazon S3編～

皆様こんにちは。SEの小池と申します。

GitLabには、SaaS版であるGitLab.comの他、いわゆるオンプレミス版であるSelf-Managed版というものがあります。会社様によっては「リモートリポジトリは社内に配置することが必須」というご要件がおありのケースも多く、Self-Managed版で検討なさるお客様も多くいらっしゃいます。

そんなSelf-Managed版ですが、オンプレ故に導入前から気になることも少々・・・。
特にGitLabはリモートリポジトリの他、パッケージの登録、アーティファクトの保存、イシューやwikiのデータ等、大量のデータを保持します。
そうなるとやっぱり気になる事項として挙がりやすいのが、ストレージの容量ではないでしょうか。

今回のブログでは、Self-Managed版のローカルストレージの節約に役立つかもしれない "統合オブジェクト ストレージ構成" を検証してみます。
今回も導入が長くてすみません。。。

本記事の対象の方

• Self-Managed版のGitLabで統合オブジェクトストレージ構成 (Consolidated object storage configuration) を検討中の方。
• Self-Managed版のGitLabで、パブリッククラウドのオブジェクトストレージを使ってローカルのストレージ使用量を減らしたい方。
• これから大規模なSelf-Managed版 GitLabの導入を検討していらっしゃる方。

今回のブログのゴール

このブログのゴールはこちらです。

今回のゴール

• Self-Managed版 GitLabでAmazon S3を使って統合オブジェクトストレージ構成を設定する。
• 設定した統合オブジェクトストレージ構成を、一部のオブジェクトタイプで検証する。

このブログをお読みいただくにあたっての事前ご連絡事項

• 本記事はSelf-Managed版 GitLab Community Edition 15.4.1 における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。
• 本記事はSelf-Managed版のGitLabのみを対象としています。SaaS版であるGitLab.comでは統合オブジェクトストレージ構成は設定できません。
• 本記事はSelf-Managed版をOmnibus形式でインストールした場合の手順のみを記載しています。ソースからインストールしたGitLabの場合はこちらのIn installations from source:をご参照ください。
• 本記事はこちらの前提のもと、設定と検証を進めます。前提となるAWSのアクセスキーIDやシークレットアクセスキー、及びAmazon S3バケットの準備方法については本記事の記載範囲外となります。
• 本記事はGitやCI/CDに関する知識ゼロのSEによるなんちゃって記事です。GitLabのディープな使用法についてはGitLabの公式オンラインドキュメント (こちら) をご参照ください。

統合オブジェクトストレージ構成とは？

Self-Managed版のGitLabが内部 (ローカルストレージ等) に保有する特定のタイプのオブジェクトを、指定したオブジェクトストレージに保管できるという機能です。
以下は2022/10/20にGitLab Docsから抜粋した文言です。

GitLab supports using an object storage service for holding numerous types of data. It’s recommended over NFS and in general it’s better in larger setups as object storage is typically much more performant, reliable, and scalable.

出典 : Object storage | GitLab

上記の通り、パフォーマンスや信頼性の優位性を根拠に、GitLabはNFSよりオブジェクトストレージの使用を推奨しています。
また、大規模なSelf-Managed版に向いている構成であることが記載されています。

本機能はインスタンス単位での設定が必要なため、Self-Managed版でのみ設定・利用できる機能です。
Self-Managed版であれば、ティア (free/Premium/Ultimate 等) を問わず設定・利用が可能です。
(GitLabの設定ファイルである gitlab.rbを使って設定する必要があるため、SaaS版では設定することはできません。)

本機能の英語の正式名称は Consolidated object storage configuration です。
ただ、本ブログでは便宜的に本機能を 統合オブジェクトストレージ構成 と記載させていただきます。

2022/10/20時点で GitLab Docs と 実機 (Self-Managed版 GitLab Community Edition 15.4.1) を参照する限り、以下のオブジェクトタイプが本機能の対象となります。
(ただし、対象のオブジェクトについてはバージョンやエディションによって異なる可能性がございます。)

• artifacts
• external_diffs
• lfs
• uploads
• packages
• dependency_proxy
• terraform_state
• pages
• ci_secure_files ※GitLab Docsに詳細の記載なし。実機には存在。

このブログで紹介する統合オブジェクトストレージ構成 (Consolidated object storage configuration)の他に、もうひとつの実装方法であるオブジェクト個別のオブジェクトストレージ構成 (Storage specific configuration)が存在します。
それぞれの特徴は以下の通りです。

• 統合オブジェクトストレージ構成 (Consolidated object storage configuration)
• 統合可能な全てのタイプのオブジェクトで、同じ資格情報を用いてオブジェクトストレージに接続する。
• 構成を有効にすると、統合可能な全てのタイプのオブジェクトにおいて、オブジェクトストレージ利用が有効になる。
  (無効化したい場合は、明示的に対象のオブジェクトのタイプで無効化する設定をする。)
• サポート対象のオブジェクトストレージが限定的。(主に Amazon S3、Azure Blob Storage、Google Cloud Storage。)
• 直接アップロードモードしか利用できない。(バックグラウンドアップロードモードは非サポート。)
• オブジェクト個別のオブジェクトストレージ構成 (Storage specific configuration)
• 統合可能なタイプのオブジェクトそれぞれで、有効 / 無効・資格情報・パス・バケット名 等を設定する。
• 統合オブジェクトストレージ構成より、サポートするオブジェクトストレージの種類が多い。
• 直接アップロードの他、バックグラウンドアップロードモードもサポートしている。

前提

これからご紹介いたします作業の前提は以下の通りです。

前提

• 必須 : コンソール, CLI, API 等のいずれかからAmazon S3 バケットを作成できる。
• 必須 : 以下を満たす アクセスキーIDとシークレットアクセスキーがある。
• 必須 : アクションs3:PutObjectが許可されている。
• 必須 : アクションs3:GetObjectが許可されている。
• 必須 : アクションs3:DeleteObjectが許可されている。
• 必須 : 設定後の検証でCI/CDパイプラインを実行するためのRunner (種類は問わず) 。
• 任意 : 設定後の検証で使うGitが使用可能なクライアント端末。

設定手順 (Omnibus形式でインストールした場合)

実際に弊社の検証環境 (Self-Managed版 且つ Omnibus形式によるインストール) で、Amazon S3を用いた統合オブジェクトストレージ構成を設定していきます。
本ブログでは、Omnibus形式でインストールした環境での設定方法をご紹介してまいります。
ソースからインストールなさった環境の場合はこちらをご参照ください。

Step1 : Amazon S3のバケット作成

最初に今回GitLabで利用するAmazon S3のバケットを作成します。

このブログでは、Self-Managed版 GitLab Community Edition 15.4.1 の統合オブジェクトストレージ構成で統合可能なタイプのオブジェクトの全てで、Amazon S3との統合を設定していきます。
このブログではオブジェクトタイプでAmazon S3バケットを分けます。したがって、今回の設定で必要になるAmazon S3 バケットは以下の 9個 です。
また、Amazon S3 バケットの暗号化については任意です。暗号化する場合は SSE-S3 か SSE-KMS のどちらかを指定してください。それ以外の暗号化は2022/10/20時点でサポートされていません。
参考：Object storage - Encrypted S3 buckets | GitLab

表1. 統合するオブジェクトタイプと保存先Amazon S3バケット名

オブジェクトタイプ	Amazon S3 バケット名	暗号化	リージョン
artifacts	gitlab-artifacts-networld	無効	ap-northeast-1
external_diffs	gitlab-external-diffs-networld	無効	ap-northeast-1
lfs	gitlab-lfs-networld	無効	ap-northeast-1
uploads	gitlab-uploads-networld	無効	ap-northeast-1
packages	gitlab-packages-networld	無効	ap-northeast-1
dependency_proxy	gitlab-dependency-proxy-networld	無効	ap-northeast-1
terraform_state	gitlab-terraform-state-networld	無効	ap-northeast-1
ci_secure_files	gitlab-ci_secure_files-networld	無効	ap-northeast-1
pages	gitlab-pages-networld	無効	ap-northeast-1

AWSのコンソールやCLI、APIなどを用いてバケットを作成してください。

この際、前提で用意したアクセスキーIDとシークレットアクセスキーが、作成したAmazon S3 バケットに対してs3:PutObject, s3:GetObject, s3:DeleteObjectを持っていることをご確認ください。
参考：Object storage - IAM Permissions | GitLab

Amazon S3のバケット作成は以上です。

Step2 : /etc/gitlab/gitlab.rbの変更

GitLabの設定ファイル/etc/gitlab/gitlab.rbを編集し、統合オブジェクトストレージ構成を有効にします。

まず、安全のために既存の/etc/gitlab/gitlab.rbのバックアップを取得します。

# cp -p /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bakup

vi等のコマンドで/etc/gitlab/gitlab.rbを開きます。

# vi /etc/gitlab/gitlab.rb

320行目あたりにgitlab_rails['object_store']['enabled']とgitlab_rails['object_store']['connection']という設定値があります。
この2つの設定値はデフォルトでコメントアウトされているので、#を削除します。
続けてgitlab_rails['object_store']['enabled']はデフォルトでfalseとなっているので、trueに変更します。

～略 (おおよそ320行目あたり) ～

gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {}

～略～

次に、Amazon S3のアクセスキーIDとシークレットアクセスキーを設定します。
前の手順の設定値gitlab_rails['object_store']['connection']を以下の要領で編集していきます。
参考：Object storage - Consolidated object storage configuration | GitLab

～略 (おおよそ320行目あたり) ～

gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
   'provider' => 'AWS',
   'region' => '<Amazon S3 バケットのリージョン>',
   'aws_access_key_id' => '<アクセスキーID>',
   'aws_secret_access_key' => '<シークレットアクセスキー>'
}

～略～

Amazon S3のバケットのリージョンがap-northeast-1、アクセスキーIDがABCDEFGHIJKLMNOPQRST、シークレットアクセスキーがABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcdの場合、以下の通りになります。

～略 (おおよそ320行目あたり) ～

gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
   'provider' => 'AWS',
   'region' => 'ap-northeast-1',
   'aws_access_key_id' => 'ABCDEFGHIJKLMNOPQRST',
   'aws_secret_access_key' => 'ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcd'
}

～略～

なお、もしAmazon S3 バケットの暗号化でSSE-KMSを使っている場合は、すぐ下の行にあるgitlab_rails['object_store']['storage_options']のコメントアウトを外し、以下の要領で編集してください。

～略 ( gitlab_rails['object_store']['connection']のすぐ下 ) ～

gitlab_rails['object_store']['storage_options'] = {
   'server_side_encryption' => '<AES256 or aws:kms>',
   'server_side_encryption_kms_key_id' => '<arn:aws:kms:xxx>'
}

～略～

次に、今編集していた箇所の3, 4行下にgitlab_rails['object_store']['objects']['artifacts']['bucket']という項目がありますので、その行のコメントアウトを外し、以下の要領で編集します。

～略 (おおよそ320行目あたり) ～

gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
   'provider' => 'AWS',
   'region' => 'ap-northeast-1',
   'aws_access_key_id' => 'ABCDEFGHIJKLMNOPQRST',
   'aws_secret_access_key' => 'ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcd'
}

～略 (3, 4行) ～

gitlab_rails['object_store']['objects']['artifacts']['bucket'] = '<オブジェクトタイプ artifacts を保存するAmazon S3バケット名>'

～略～

このブログの場合は、オブジェクトタイプ artifacts を保存するAmazon S3バケット名がgitlab-artifacts-networldなので以下のようになります。

～略 (おおよそ320行目あたり) ～

gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
   'provider' => 'AWS',
   'region' => 'ap-northeast-1',
   'aws_access_key_id' => 'ABCDEFGHIJKLMNOPQRST',
   'aws_secret_access_key' => 'ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcd'
}

～略 (3, 4行) ～

gitlab_rails['object_store']['objects']['artifacts']['bucket'] = 'gitlab-artifacts-networld'

～略～

オブジェクトタイプ artifacts の行と同じ要領で、各オブジェクトタイプの行のコメントアウトを外し、Amazon S3バケット名を設定していきます。
(バージョンやエディションによっては、デフォルトで記載されている設定値がこのブログとは異なる可能性が有ります。)

～略 (おおよそ320行目あたり) ～

gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
   'provider' => 'AWS',
   'region' => 'ap-northeast-1',
   'aws_access_key_id' => 'ABCDEFGHIJKLMNOPQRST',
   'aws_secret_access_key' => 'ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcd'
 }

～略 (3, 4行) ～

gitlab_rails['object_store']['objects']['artifacts']['bucket'] = 'gitlab-artifacts-networld'
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = 'gitlab-external_diffs-networld'
gitlab_rails['object_store']['objects']['lfs']['bucket'] = 'gitlab-lfs-networld'
gitlab_rails['object_store']['objects']['uploads']['bucket'] = 'gitlab-uploads-networld'
gitlab_rails['object_store']['objects']['packages']['bucket'] = 'gitlab-packages-networld'
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = 'gitlab-dependency_proxy-networld'
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = 'gitlab-terraform_state-networld'
gitlab_rails['object_store']['objects']['ci_secure_files']['bucket'] = 'gitlab-ci_secure_files-networld'
gitlab_rails['object_store']['objects']['pages']['bucket'] = 'gitlab-pages-networld'

～略～

編集が終わったら、保存して閉じます。
ファイル/etc/gitlab/gitlab.rbの編集は以上です。

Step3 : GitLab再構成

前の手順で変更した設定をGitLabに反映させるために、GitLabを再構成します。
以下のコマンドを実行します。

# gitlab-ctl reconfigure

出力が以下の通りであれば、正常に再構成が完了しています。

gitlab Reconfigured!

GitLabの再構成は以上です。

検証

前の手順で設定した統合オブジェクトストレージ構成が、正常に機能しているかどうかを確認します。
このブログでは、オブジェクトストレージ利用を有効にしたオブジェクトタイプのうち、lfs, uploads, artifactsをピックアップして確認します。

検証1 : オブジェクトタイプ lfs の検証

オブジェクトタイプ lfs が、Amazon S3 バケットを使用するかを確認します。

前提に記載されている、Gitコマンドが使用可能なクライアントを用います。
検証は既存のプロジェクトか、検証用のプロジェクトで実施なさってください。
既存のプロジェクトを用いる際は、[設定] > [一般] を開き、セクション [可視性、プロジェクトの機能、権限] を展開し、Git Large File Storage (LFS)が有効になっていることを確認してください。

最初に以下のコマンドを実行してGit LFSをインストールします。
参考：Git Large File Storage

git lfs install

続けて、Git LFSの対象となるファイルの拡張子を設定します。
ここでは例として、*.isoを対象として設定します。

git lfs track "*.iso"

前の手順でGit LFSの管理対象とした拡張子を持つ、サイズの大きなファイルを用意します。
このブログでは例として、CentOS 8 のISOファイル (ファイルサイズ4GB超) を用意しました。

このファイルを、検証に使うプロジェクトの任意のブランチにプッシュします。
LFSのトラッキング対象のファイルのプッシュに失敗してしまう場合は、下の参考URLをご参照ください。
参考：「LFS objects are missing」でpushできない時の回避策 | GitLab.JP

プッシュ後、GitLabのGUIに任意のユーザーでログインし、検証に使うプロジェクトのリポジトリを確認してください。正常にLFSの対象として認識されている場合、下図のように先ほどプッシュしたファイル名の横にLFSと表示されています。

AWSコンソールにAmazon S3のバケットと中身を参照できるユーザーでサインインし、オブジェクト lfs 用に作成したAmazon S3バケットの中にオブジェクトが入っているか確認してください。
LFSの場合、リポジトリに格納したファイル名とは異なる名称で保管されていますが、下図赤枠内のファイルが先ほどプッシュしたファイルになります。

オブジェクトタイプ lfs の検証は以上となります。

検証2 : オブジェクトタイプ uploads の検証

オブジェクトタイプ uploads が、Amazon S3 バケットを使用するかを確認します。
そもそもオブジェクト uploads に分類されるオブジェクトとは何なのかについて、GitLab Docsには以下の通りあります。

Uploads represent all user data that may be sent to GitLab as a single file. As an example, avatars and notes’ attachments are uploads. Uploads are integral to GitLab functionality, and therefore cannot be disabled.

出典：Uploads administration | GitLab

上記を参考にここでは以下の2つを実施し、これらのオブジェクトがAmazon S3バケットに格納されることを確認します。

1. アバターの画像に、好きな画像を設定する。
2. イシューのコメント欄に動画を添付する。

では、さっそく1点目のアバターの画像変更をします。
任意のユーザーでGitLabにサインインし、左上のユーザーアイコンから [Edit profile] をクリックします。

Public avatarの [ファイルを選択] をクリックし、任意の画像を指定します。

サイズを調整し、[新しいプロフィール画像を設定する] をクリックします。

画面を下までスクロールして、[プロファイル設定を更新] をクリックします。

アバター画像の変更は以上です。

次に、任意のイシューのコメント欄に動画を添付します。
検証対象のプロジェクトに移動し、[イシュー] > [リスト] を開きます。

[新規のイシュー] をクリックします。

イシュー名だけ指定して [作成 イシュー] をクリックします。

作成されたイシューのコメント欄に、適当な動画ファイルをドラッグアンドドロップして添付します。
添付出来たら [コメント] をクリックします。

イシューに動画を添付できたことを確認します。

AWSコンソールにAmazon S3のバケットと中身を参照できるユーザーでサインインし、オブジェクト uploads 用に作成したAmazon S3バケットの中にオブジェクトが入っているか確認してください。
uploads の場合、少なくともアバターの画像ファイルや、イシューに張り付けた動画ファイルはそのままのファイル名で格納されていました。

オブジェクトタイプ lfs の検証は以上となります。

検証3 : オブジェクトタイプ artfacts の検証

オブジェクトタイプ artifacts が、Amazon S3 バケットを使用するかを確認します。
このブログでは検証用プロジェクトで、簡易的なCI/CDパイプラインを作成し、そのアーティファクトがAmazon S3のバケットに保存されるかを確認します。
既存のプロジェクトのCI/CDパイプラインでアーティファクトを生成するものがあれば、それを実行することで検証が可能です。
どちらでもやりやすい方で検証なさってください。

GitLabにサインインし、検証用プロジェクトのページから [CI/CD] > [Editor] を開きます。

[Configure pipeline] をクリックします。

自動的にCi/CDパイプラインのサンプル文言が入力されますが、それらを削除します。

以下の内容をコピーアンドペーストします。

artifacts-test-job:
    script: echo "これはartifactsを作成する簡易CI/CDパイプラインです" >> test.txt
    artifacts: 
        paths:
            - test.txt

[Commit changes] をクリックします。
このボタンをクリックできない場合は、任意ブランチにコミットするか、もしくは、マージリクエストを開始ししてください。
(CI/CDパイプラインを実行してアーティファクトを得ることが目的なので、マージする必要はありません。)

[CI/CD] > [パイプライン] を開きます。

先ほどのコミットにより自動実行されたパイプラインが [成功] で終了していることを確認します。
パイプラインの右側にあるアイコンをクリックし、そこからアーティファクトをダウンロードします。

ダウンロードしたアーティファクトの内容を確認します。
今回のブログの例ではこんな感じです。

AWSコンソールにAmazon S3のバケットと中身を参照できるユーザーでサインインし、オブジェクト artifatcs 用に作成したAmazon S3バケットの中にオブジェクトが入っているか確認してください。
artifacts の場合、GitLabのGUIからダウンロードする際と同様にartifacts.zipで格納されていました。

また、上記アーティファクト以外にも、 artifacts 用に用意したAmazon S3バケットにはメタデータやジョブのログなど、アーティファクト以外のオブジェクトも格納されていました。

オブジェクトタイプ artifacts の検証は以上となります。
これでAmazon S3を用いたGitLab 統合オブジェクトストレージ構成の設定方法と検証は完了です。

最後に

この度はGitもCI/CDもよくわかっていないど素人SEによるGitLab検証ブログをお読みいただき、誠にありがとうございます。
このブログの目標は以下のとおりでしたが、皆さまはいかがでしたでしょうか。

今回のゴール

• Self-Managed版 GitLabでAmazon S3を使って統合オブジェクトストレージ構成を設定する。
• 設定した統合オブジェクトストレージ構成を、一部のオブジェクトタイプで検証する。

Self-Managed版はインスタンスレベルの設定の変更が可能であることが、メリットの1つです。
今回検証致しました統合オブジェクトストレージ構成 (Consolidated object storage configuration) は、GitLabインスタンスの設定ファイルを変更し再構成するだけで、対象のオブジェクトタイプの保存先を指定したパブリッククラウドのオブジェクトストレージになるという便利な機能です。
ローカルのディスク容量の節約に貢献できるので、もしよろしければご検討いただければと存じます。

この記事がGitLabを触り始めた方の一助となれば幸いにございます。

---

GitLabに関するお問い合わせは、以下のフォームからお願い致します。
GitLab製品 お問い合わせ

今までのGitLabの検証ブログはこちらです。

GitLab操作デモ動画 (基本編) を作ってみました。(音声の録音は自宅でiPhoneのボイスメモ使うという超低クオリティですが…。)
つたない内容ではありますが、ご興味がおありでしたら是非ご視聴いただければと存じます。

www.youtube.com