GitLab のストレージ節約チャレンジ その２として、Amazon S3 に続いてのブログです。
GitLabはけっこう大量のデータを保持しています。リモートリポジトリの他、パッケージの登録、アーティファクトの保存、イシューやwikiのデータなど、減ることはなく増える一方です。
そうなるとやっぱり気になる事項として挙がりやすいのが、ストレージの容量ではないでしょうか。今回のブログでは、Self-Managed版のローカルストレージの節約に役立つかもしれない “統合オブジェクト ストレージ構成” を検証してみています。
これからGitLabをSelf-Managed版で使ってみようと思っている方、インフラよりの準備に気になっている方にぜひチェックいただきたい『知識ゼロエンジニアのブログ』第31弾「GitLabのストレージ節約のために統合オブジェクトストレージ構成を試す ～Wasabi 編～」です。ぜひご参考ください！
今回のブログ内容
「GitとCI/CDに関する知識ゼロのSEが、GitLabのストレージ節約のために統合オブジェクトストレージ構成を試す ～Wasabi 編～」
目次
1. 本記事の対象の方
2. 今回のブログのゴール
3. このブログをお読みいただくにあたっての事前ご連絡事項
4. 統合オブジェクトストレージ構成とは？
5. Wasabi Hotクラウドストレージとは？
6. 今回の検証の要点
7. Wasabi Hotクラウドストレージ側の準備 (30日トライアルでOKです！)
ユーザーの作成
バケットの作成
8. GitLab側の設定
設定ファイルgitlab.rbの編集
GitLabの再構成
9. LFSの検証の結果
10.最後に
弊社パートナー様はNetworld Dev Portal アカウント（無料）登録いただくと、GitLabパートナー制度や DevSecOps関連提案資料などのパートナー限定コンテンツがご覧いただけます。
DevSecOps全般、GitLab製品または本サイトについては以下よりお問い合わせ下さい。
