GitLab: DinDとDooD

GitLabのDinDとDooDのイメージについてのメモ（想像で書いており、特に検証はしていません。実際にはRunnerが立ち上げるコンテナは他にもあるようですが、省略しています）

DinD (Docker executor with Docker-in-Docker)

DinDではprivileged trueの設定を行い、Job用のコンテナでdocker serviceが実行できるようにする。build jobのコンテナはdocker serviceを実行しているdockerコンテナにtcpで接続を行う。build jobを実行するコンテナはdocker serviceを実行する必要はないが、docker cliは必要になる。

私の場合は、基本的にはこの構成でJobが実行されるように環境を構築している。

build jobのコンテナ自身がdocker serviceを起動する場合、service用のコンテナは必要ない。次のような形式も可能なはずである。

DooD (Docker executor with Docker socket binding)

DooDはHostのdocker serviceをbuild jobから使用する。このため、ホストの/var/run/docker.sockをbuild jobにもマウントする構成を取る。DooDはそのまま放っておくとHostにbuild時に立ち上げたdocker imageが堆積していくと思われるので、片付け(prune)を別途考えておく必要がある。

DooDでもservice用のcontainerを使用する形式をとることが出来る。この構成をとることにメリットはあまりないが、DinDとDooDの違いを意識せずにgitlab-ci.ymlを書いても問題ないはずである。

試していないが、hostのdocker.sockをtcpで接続することも可能なはずである。NW上のHostのIPアドレスを解決する必要があるのとホスト側でnftablesやiptables, firewalldなどによって通信がドロップされないことが必要になる。