みなさん、自宅サーバー活してますか？
僕は自宅サーバ（というかオンプレ）大好きです！！！
なぜならめちゃくちゃランニングコストが安いからです。これにつきます。
とはいえ、クラウドに比べると可用性や火事などリスクはつきもの。それでもなんとかこの茨の道を突き進んでいきたいのが技術者の性とでもいうべきか・・・。
普段は技術的な話はQiitaに書きがちなのですが、今回はブログで。
今回の話題はSynology DSM（自宅サーバ）で、GitLabでDevOps（今回はCI/CD）したい！という要望を叶える＋１な記事です。
TL;DR
RSシリーズなどでCPUリソースが潤沢にあればVirtual Machine Managerのインスタンスで立てた方がよい。
PlusシリーズなどでCPU/RAMに余裕がないのであれば SSH 接続して docker コマンドを直に叩きDooDせよ。
そもそも別に物理マシンを準備できるのであれば、DSM環境下よりもその方が都合が良い場合が多いので検討されたい。
Synology Plus シリーズ以上ではDocker Package が使える
Synology のサーバのうち、一般家庭用のJシリーズを除くPlusシリーズ以上のモデルでは、Docker Packageが利用できます。
そのため、GitLabも簡単に構築できるのですが・・・。残念ながらGitLab Runner は簡単には動作しません。その原因はGitLab Runnerの Executor にあります。
GitLab Runnerの executor にはいろいろ種類があり、一番ベーシックなもので shell, よく使われがちなものでいけば docker でしょうか。shell モードはDocker Packageで単純にレジストリからImageをpullしてコンテナを起動するだけで使うことができます。一方で、docker モードはそう簡単にはいきません・・・。
docker executor で daemon がみつからない
察しの良い方であればすぐ気付くでしょうが、ハイパーバイザで動いていないdockerコンテナなGitLab Runnerでは、DinD or DooD のどちらかを用いて docker を利用する必要があります。 DinDはDSMでも割と簡単に実現ができ、実行時に high previledge にチェックボックスをつけておけばそれだけで実現できます。しかしながら、自宅サーバ愛好家の皆様であれば他に動かしている大事な大事な docker コンテナたちがいるはずです。万が一CIなどで変なコードを実行してしまってホスト側の環境を破壊した時は目も当てられません。また、DinDには脆弱性も報告されており、そもそも使うべき？みたいなところもあります。
そこで、DooDを実現したい！となるわけです。
しかしながらDooDを実現するには、dockerコンテナを起動するときに、あらかじめ docker volume or mount で ホスト側の docker socket をマウントする必要があります。
じゃあマウントしよう・・・・あっ・・・・
このAdd File, Add FolderボタンはDSM Shared Folders（共有フォルダ）へのパス追加しかUIを提供してくれないのです・・・。
もうダメなのかな、と思っていたところでふと思いつきます。設定ファイルを書き出して、マウントをよしなに記述してまた戻せばいいのでは！？と。
{
# 前略
"volume_bindings" : [
{
"host_volume_file" : "/var/run/docker.sock",
"mount_point" : "/var/run/docker.sock",
"type" : "rw"
}
]
}しめしめ・・・・。絶対できるぞ！！！とおもってImportしても・・・残念ながら設定は反映されませんでした。どうやら docker package が提供するUIやAPIでは shared folder 以下のパスしかマウントできないようです。
反則技 console から docker client
もう諦めようかと思ったとき、もう一つ方法を思いつきました。
DSMではご法度技とも言えますが、直接 console で接続しsuperuser として docker command を実行してみることとしました。ホストから ssh で接続する方法は公式docをご覧ください。
$ sudo su
$ docker run -d --name gitlab-runner-docker -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latestなんなくコマンドは成功、コンテナハッシュが返ってきます。 docker packageのUIをみると・・・。
きちんと実行されていそうに見えます！
詳細を開いてみても、Volumeは空になっていますが・・・。実は unix socket がバインドされて実行されています。つまり、DooDで実現したいことが叶った状態になっているわけです。
この状態でGitLab側で docker image を指定した .gitlab-ci.yml を記述します。そしてJobをトリガーさせると・・・。
スクリーンショットの例はRailsプロジェクトですが、きちんと 期待された docker image がpullされ、 bundle install が開始されているのがわかります。
やった後に気づいたこと
docker package でなんとか GitLab Runner を起動させ、連携させるということをやってみましたが、やった後に気づいたことがあります。
「Virtual Machine Manager package 使えば良くね！？」
Synology Plus シリーズ以上のDSMには docker package の他にハイパーバイザ型の仮装基盤である Virtual Machine Manager package が利用できます。あたかもEC2やGCEのように仮想マシンを作ることができるわけです。つまりその上でLinuxを動かせば dockerは当然普通に使えるわけで・・・。
もちろん、 Virtual Machine Manager packageを用いた手法と、今回のDooD手法ではフットプリントが明らかに後者の方が小さいのでまったく無意味というわけではないのですが、CPU・RAMリソースが潤沢にあるラックマウント型のSynologyマシンを使っているのであればあまり今回手法に意味はないのかもしれません。
逆に、デスクトップ型でCPUリソースがカツカツという自宅サーバ愛好者のみなさんには参考になるかと思います。
また、Raspberry Piなどをお持ちの方であれば、低コストで物理マシンを１台準備できるわけですから、そもそもそちらの方がより良いかもしれません。
ただ、限定的な環境でやりたいことを実現する・・・ここにロマンを感じるのは僕だけでしょうか。
この記事がみなさんのロマンを実現する一助になれば幸いです。