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

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

前回のブログ (こちら) では、GitLabのSelf-Managed版で統合オブジェクトストレージ構成をAmazon S3を使って構成する方法についてご紹介いたしました。

書いた後に弊社のマーケティング部のメンバーから「Amazon S3と互換性が有るオブジェクトストレージも利用可能なら、Wasabiでも同じような構成が可能なんですかね？」と自社取扱製品との連携について可否を問われました。検証しろという無言の圧を感j・・・なんでもないです。やります。はい。

そんなわけで、今回は弊社が取り扱うWasabi Hotクラウドストレージを用いて、GitLabの統合オブジェクトストレージ構成を検証してまいります。

本記事の対象の方
今回のブログのゴール
このブログをお読みいただくにあたっての事前ご連絡事項
統合オブジェクトストレージ構成とは？
Wasabi Hotクラウドストレージとは？
今回の検証の要点
Wasabi Hotクラウドストレージ側の準備 (30日トライアルでOKです！)
- ユーザーの作成
- バケットの作成
GitLab側の設定
- 設定ファイルgitlab.rbの編集
- GitLabの再構成
LFSの検証の結果
最後に

本記事の対象の方

Self-Managed版のGitLabの統合オブジェクトストレージ構成 (Consolidated object storage configuration) で、Wasabi Hotクラウドストレージを使うことを検討中の方。
前回のブログ (こちら) の続きで、Amazon S3と互換性のあるオブジェクトストレージサービスで、統合オブジェクトストレージ構成を検討中の方。

今回のブログのゴール

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

今回のゴール

Wasabi Hotクラウドストレージを使って、統合オブジェクトストレージ構成を設定する。
設定した統合オブジェクトストレージ構成を、オブジェクトタイプ LFS で検証する。

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

本記事はSelf-Managed版 GitLab Community Edition 15.5.0 における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。
本記事はSelf-Managed版のGitLabのみを対象としています。SaaS版であるGitLab.comでは統合オブジェクトストレージ構成は設定できません。
本記事はSelf-Managed版をOmnibus形式でインストールした場合の手順のみを記載しています。ソースからインストールしたGitLabの場合はこちらのIn installations from source:をご参照ください。
本記事はGitLabのタイプ LFS に分類されるオブジェクトが、Wasabi Hotクラウドストレージで作成したバケットに格納されるところまでを検証しています。それ以外の挙動については本ブログの検証の範囲外です。
本記事の検証内容と検証結果は、Wasabi Hotクラウドストレージを用いてGitLabの統合オブジェクトストレージを構成する場合において、その動作を保証するものではありません。

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

Self-Managed版のGitLabが内部 (ローカルストレージ等) に保有する特定のタイプのオブジェクトを、指定したオブジェクトストレージに保管できるという機能です。

統合オブジェクトストレージ構成の概要は、前回のブログに記載しておりますので、恐れ入りますがそちらをご覧ください。
blogs.networld.co.jp

Wasabi Hotクラウドストレージとは？

筆者はWasabi Hotクラウドストレージについて、

たしかAmazon S3と互換性があるクラウドストレージ・・・だったような気がする・・・。

くらいしか知りませんので、弊社の製品ページから抜粋します。

「Wasabi Hotクラウドストレージ」はクラウド型のオブジェクトストレージです。ホットデータ向け高性能ストレージという意味だけではなく、コールドストレージの価格でホットストレージを提供するのが、「 Wasabi Hotクラウドストレージ」です。 Amazon S3と完全互換性があるため、現在Amazon S3でお使いのアプリケーションを変更する必要はありません。

出典：Wasabi Technologies | 取扱製品 | ネットワールド

・・・だそうです！

話が脱線しますが、弊社のストレージ担当SEがWasabi Hotクラウドストレージの別の活用方法について言及しているブログがございますので、よろしければそちらもどうぞ。
blogs.networld.co.jp

今回の検証の要点

このブログでは以下の要領で検証をしてまいります。

Wasabi Hotクラウドストレージを用いて、GitLabの統合オブジェクトストレージを構成する。
オブジェクトタイプ LFS のみオブジェクトストレージの利用を有効にし、他は無効にする。
オブジェクトタイプ LFS が、Wasabi Hotクラウドストレージのバケットに保存されるか確認する。

Wasabi Hotクラウドストレージ側の準備 (30日トライアルでOKです！)

まずはWasabi Hotクラウドストレージの設定をします。
今回は統合オブジェクトストレージ構成がWasabi Hotクラウドストレージで可能かを確認することが目的なので、トライアルを用います。
トライアル申し込みのURLはこちらです (2022/10/24時点) 。

必要事項を入力するだけで、すぐにトライアルを開始できます。
トライアルを利用可能になったら、今回の検証に必要な設定をしていきます。

ユーザーの作成

GitLabの統合オブジェクトストレージ構成では、AWSのアクセスキーIDとシークレットアクセスキーで接続情報を設定するのが一番簡単です。
ですので、最初にそのユーザーを作成します。

Wasabi Hotクラウドストレージのコンソールから、[ユーザー] > [ユーザーを作成] をクリックします。

任意のユーザー名を入力し、[プログラム (APIキーを作成) ]にチェックを入れ、[次] をクリックします。

グループに所属させることも可能ですが、今回の検証では不要です。[次] をクリックします。

ユーザーにアタッチするポリシーを指定します。
検索ボックスに "S3" と入力すると、"AmazonS3FullAccess" が候補に出るので、これをクリックします。

必要最低限な権限
本ブログでは記事の長さの都合上、既存のポリシー "AmazonS3FullAccess" を使用しておりますが、必要最低限な権限はs3:PutObject, s3:GetObject, s3:DeleteObjectです。
恒久的にWasabi Hotクラウドストレージとの統合を検討している場合は、これらの操作が可能なポリシーを自作していただき、ユーザーやグループにアタッチいただくことをお勧めいたします。
参考：Object storage - IAM Permissions | GitLab

画面を下までスクロールし、[添付される方針：] に "AmazonS3FullAccess" があることを確認し、[次] をクリックします。

[ユーザーを作成] をクリックします。

以下のような画面が自動表示されるので、そのままお待ちください。
表示されたら、[CSVのダウンロード] をクリックして、アクセスキーIDとシークレットアクセスキーをダウンロードしておきます。

CSVのダウンロードが終わったら、右上の [x] をクリックします。

ユーザーの作成は以上です。

バケットの作成

Wasabi Hotクラウドストレージのコンソールから、GitLabの統合オブジェクトストレージ構成で使うバケットを作成します。
なお今回の検証では、今回の検証の要点に記載致しました通り、オブジェクトタイプ LFS のみオブジェクトストレージの利用を有効にし、他のオブジェクトタイプでは無効にします。
よって、今回の検証ではオブジェクトタイプ LFS 用のバケットのみを作成します。

Wasabi Hotクラウドストレージのコンソールから、[バケット] > [バケットを作成] をクリックします。

バケット名を任意に指定し、このバケットのリージョンを指定します。
このブログでは例として、バケット名をnetworld-gitlab-integrations-lfs、リージョンをap-northeast-1にします。

ここで、リージョンを指定すると、その欄の右上にコピーアイコンが表示されます。
これはWasabi Hotクラウドストレージ独自のエンドポイントURLです！
このブログではWasabi Hotクラウドストレージの詳細については割愛致しますが、通常のAmazon S3のエンドポイントとは異なり、このURLを利用します。
このコピーアイコンをクリックし、エンドポイントURLをどこかにメモしておいてください。(後ほどGitLabの設定ファイル内でこれを使います。)

エンドポイントURLをメモし終わったら、[次] をクリックします。

バージョニング等の詳細設計の画面が表示されます。
今回の検証ではこれらの設定は不要なので、全てデフォルトのまま [次] をクリックします。

[バケットを作成] をクリックします。

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

GitLab側の設定

ここからはSelf-Managed版のGitLabの設定ファイルgitlab.rbを編集し、GitLabを再構成していきます。
なお、このブログではSelf-Managed版をOmnibus形式でインストールした場合の手順のみを記載しています。
ソースからインストールしたGitLabの場合はこちらのIn installations from source:をご参照いただきながら設定をお願い致します。

また、編集をする前に設定ファイルgitlab.rbのバックアップを取得しておくことをお勧めいたします。
(Omnibus形式のインストールの場合、ファイルパスは/etc/gitlab/gitlab.rbです。)

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

設定ファイル`gitlab.rb`の編集

Self-Managed版 GitLabの設定ファイルgitlab.rbを編集していきます。
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'] = {}

～略～

次に、先ほどWasabi Hotクラウドストレージのコンソールで作成した、ユーザーのアクセスキー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' => '<Wasabi Hotクラウドストレージで作成したバケットのリージョン>',
   'aws_access_key_id' => '<Wasabi Hotクラウドストレージで作成したユーザーのアクセスキーID>',
   'aws_secret_access_key' => '<Wasabi Hotクラウドストレージで作成したユーザーのシークレットアクセスキー>'
}

～略～

バケットのリージョンが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'
}

～略～

前の手順でメモしておいたWasabi Hotクラウドストレージ独自のエンドポイントURLを指定します。
シークレットアクセスキーを設定した行の末尾にカンマ,を記載し、すぐ下の行に設定項目endpointを追記します。
参考：Object storage - S3-compatible connection settings | GitLab

～略 (おおよそ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',
   'endpoint' => 'https://<クラウドストレージ独自のエンドポイントURL>/'

}

～略～

もし、この時点でバケットを作成したリージョンの、Wasabi HotクラウドストレージのエンドポイントURLが分からない場合はこちらからご確認ください (2022/10/24時点の情報です) 。
東京リージョン (ap-northeast-1) の場合はs3.ap-northeast-1.wasabisys.comなので、このブログでは以下のような設定になります。

～略 (おおよそ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',
   'endpoint' => 'https://s3.ap-northeast-1.wasabisys.com/'
}

～略～

Wasabi Hotクラウドストレージのコンソールで作成したバケット名を、オブジェクトタイプ lfs で使うバケット名に指定します。
先ほど編集していた行の4, 5行下にgitlab_rails['object_store']['objects']['lfs']['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',
   'endpoint' => 'https://s3.ap-northeast-1.wasabisys.com/'
}

～略 (4,5 行) ～

gitlab_rails['object_store']['objects']['lfs']['bucket'] = '<Wasabi Hotクラウドストレージで作ったLFS用バケット名>'

～略～

このブログの場合、Wasabi Hotクラウドストレージのコンソールで作成したバケット (LFS用) の名前はnetworld-gitlab-integrations-lfsなので、以下の通りとなります。

～略 (おおよそ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',
   'endpoint' => 'https://s3.ap-northeast-1.wasabisys.com/'
}

～略 (4,5 行) ～

gitlab_rails['object_store']['objects']['lfs']['bucket'] = 'networld-gitlab-integrations-lfs'

～略～

GitLabの統合オブジェクトストレージ構成 (Consolidated object storage configuration) を有効にした場合、オブジェクトストレージを利用可能なオブジェクトタイプは全てデフォルトで設定が有効 (オブジェクトストレージを利用する設定) になります。今回の検証の場合、オブジェクトストレージを利用するオブジェクトタイプは LFS のみなので、それ以外のオブジェクトタイプについては明示的に無効 (オブジェクトストレージを利用しない設定) にする必要があります。

無効にするオブジェクトの目安は、設定ファイルgitlab.rbのGitLabの統合オブジェクトストレージ構成 (Consolidated object storage configuration) の周辺にある設定値で、

gitlab_rails['object_store']['objects']['<無効にしたいオブジェクトタイプ>']['bucket']

という行です。
上の書式の行があるオブジェクトで、オブジェクトストレージの利用を無効化したい場合、この行をうまく編集して無効化の設定をしていきます。

弊社の検証環境の設定ファイルgitlab.rbを用いて説明してまいります。
以下の画面の赤枠部分が、「オブジェクトストレージの利用を無効化したいオブジェクトタイプ」の行です。

これらすべての行のコメントアウトを外します。

設定値の末尾にある[ 'bucket' ]を、[ 'enabled' ]に変更します。
オブジェクトタイプ artifacts を例にすると、以下のように変更します。

【変更前】

gitlab_rails['object_store']['objects']['artifacts']['bucket'] = nli

【変更後】

gitlab_rails['object_store']['objects']['artifacts']['enabled'] = nli

最後に、設定値falseを指定します。
オブジェクトタイプ artifacts を例にすると、以下のように変更します。

【変更前】

gitlab_rails['object_store']['objects']['artifacts']['enabled'] = nli

【変更後】

gitlab_rails['object_store']['objects']['artifacts']['enabled'] = false

これで、LFS以外のオブジェクトタイプでオブジェクトストレージを使わせない設定が完了しました。
設定が終わったら、gitlab.rbを保存します。

設定ファイルgitlab.rbの編集は以上です。

GitLabの再構成

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

# gitlab-ctl reconfigure

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

gitlab Reconfigured!

GitLabの再構成は以上です。

LFSの検証の結果

オブジェクトタイプ LFS について、Wasabi Hotクラウドストレージで作成したバケットに格納されることを確認します。検証方法は前回のブログ (こちら) に記載しているので、具体的な検証手順についてはこちらでは割愛させていただきます。

こちらが今回用意したテスト用のファイルです。今回はUbuntuのイメージファイルを使いました。

これをGitLabの任意のプロジェクトにPushします。

GitLabのGuiから、先ほどファイルをPushしたプロジェクトを確認します。
先ほどPushしたUbuntuのイメージファイルが存在し、且つ、ファイル名の右側にLFSと表示されています。

Wasabi Hotクラウドストレージのコンソールから、今回作成したバケットの中を確認します。
リポジトリに格納しているファイル名と異なりますが、こちらが今回PushしたLFS管理対象のファイルです。(ファイル名が異なるのはgitの仕様です。)

一応Wasabi Hotクラウドストレージのバケットからこのオブジェクトをダウンロードし、拡張子を.isoに変換して確認したところ、間違いなくUbuntuのイメージファイルであることが確認できました。

以上、GitLabの統合オブジェクトストレージ構成をWasabi Hotクラウドストレージを使って実装する手順と検証結果でした。

最後に

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

今回のゴール

Wasabi Hotクラウドストレージを使って、統合オブジェクトストレージ構成を設定する。
設定した統合オブジェクトストレージ構成を、オブジェクトタイプ LFS で検証する。

今回の検証は弊社取り扱い製品である、Wasabi Hotクラウドストレージとのコラボでした。
この検証をマーケティング部から依頼された時点では、

え、Wasabi？ストレージ製品でしょ？？？無理無理無理無理、違う人に頼んで！！！

と本気で思った筆者でしたが、意外と簡単に連携させることができました！
LFSしか確認してないですが…。

GitLab Docsに明示的にサポートしていると書いているストレージベンダーには限りがありますが、基本的にはAmazon S3との互換性が有れば構成できる可能性が有るので、Wasabi Hotクラウドストレージ以外でもご検討いただければと存じます。

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

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

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

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