サムネイル画像

NOTE: 今回は私の試行錯誤のプロセスに焦点するので実際にAnsibleのコードの掲載は省略する

Kamalでデプロイができるようになったので、開発をしようと思ったらまたこうしてGitLab側の設定を見ようとしている。

以前まではこのあたりの設定を特に考えることはなかったし、それで間に合っていた。

今後は以前よりは少しばかり堅牢な構成について考えてみようと思う。

現状の問題点

ChatGPTのおすすめ設定に従ってGitLab Runnersは/srv/runnerに本体とは別のストレージを確保している:

$ ssh gitlab-runner sudo df -h | grep /sd | grep -v /efi
/dev/sda2        12G  6.5G  4.2G  61% /
/dev/sdb1        20G  5.5G   14G  30% /srv/runner

対するGitLabは確保した100GBのストレージが宙ぶらりんになっている:

$ ssh root@gitlab df -h | grep 103
/dev/mapper/pve-vm--103--disk--0   32G  8.2G   22G  28% /
hdd3t/subvol-103-disk-0           100G  128K  100G   1% /srv/gitlab

現状の問題を洗い出してもらった:

  • GitLab LXC (CT103) の rootfs は 32GB、/srv/gitlab に 100GB をマウント済み。
  • しかし GitLab Omnibus のデータは /var/opt/gitlab 配下に書き込まれており、現在は rootfs 側に溜まっている。
  • /srv/gitlab は空のままなので活用できていない。

今回はこの問題を解決する。

修正の方針について

GitLab のデータ格納先は以下:

  • /var/opt/gitlab/git-data/ … リポジトリ本体 (Gitaly)
  • /var/opt/gitlab/gitlab-rails/shared/registry/ … コンテナレジストリ
  • /var/opt/gitlab/backups/ … バックアップ出力先
  • /etc/gitlab/ … 設定ファイルと secrets.json

これらをまるごと /srv/gitlab に置いてしまえば rootfs の消費を最小限にできるのでシンプルなのだそうだ。

せっかくGitLabのインストールはAnsibleで管理しているので、今回この設定をすべてAnsibleのPlaybookで実現しようと思う。

考えうる選択肢としては3つ:

  1. 予めインストールする前の状態にシンボリックリンクを作成しておけばgitlabのインストーラーが上書きしてくれることを期待する
  2. 対象のシンボリックリンクが存在していなければ個別にPlaybookをインポートして対応する。すでに対応済みのときは無視する
  3. Ansibleで一括でのプロビジョニングを避け、個別にPlaybookを作成する。あるいはbashやpythonなどで専用のタスクを書く

この中で②が最も安全らしいので、その方法を進めることにする。

対応してみた

若干の書き方の揺れなどでトラブルは起こったものの、最終的にGitLabが起動するところまでは確認できた:

$ ssh root@192.168.8.12 df -h | grep 103
/dev/mapper/pve-vm--103--disk--0   32G  6.1G   24G  21% /
hdd3t/subvol-103-disk-0           100G  1.4G   99G   2% /srv/gitlab

dfコマンドで確認しても2GB弱のファイルを退避させることができた。

GitLabが作成するバックアップファイルはまた別に保存しようかと考えているが、少なくともこれまでで100GB使い切ることはなかったので一旦はステイでいようと思う。

今回動かしているリソースは十分に余裕があるものではなく、特にRAMが4GBだと挙動がかなり不安定なので6GBに切り替えた。

セルフホスティングのGitLabそのものを使い続けてもうかなり長いこと経つけれども、今後の運用は長期的にインスタンスを保持できるようにしていきたい。

余談ではあるが今回の投稿の骨子から画像の生成まで、最近はどっぷりとChatGPTに依存している。