自宅サーバの移設に際して docker から nerdctl に移行した

長らく docker で色々ホストして動かしていた自宅鯖だが、スペックの限界を感じてサーバ自体を移設するとともに、せっかくだからと nerdctl + containerd の構成に変更した。
docker を root で動かしていてもマインクラフトのサーバ(=JVM) に脆弱性がなければ大丈夫、などと思っていたのも昔の話で、 log4j の件もあったのでより堅牢な rootless も同時に採用することにした。 → 自宅サーバを rootless に移行した際のトラブル対応

前提知識

nerdctl / containerd とは

まず先に containerd から説明すると、端的に言ってしまえば docker の中身である。
これ自体は汎用的なコンテナ管理プラットフォームであり、そのクライアントとして docker (cli / API) や nerdctl 、 kubernetes などが存在する。
kubernetes は docker API ではなく containerd のインタフェースである CRI を直接利用して動作しているため docker を使わなくなった、というわけである。
nerdctl も同様に内部では CRI を操作するが、 docker と互換性を持つ cli を用意しているのみで、 docker API と同様の API は所有していない。

nerdctl: Docker-compatible CLI for containerd

詳しい話についてはこちらの資料に非常に理解を助けられた。Dockerからcontainerdへの移行 (NTT Tech Conference 2022発表レポート)

docker が古い/非推奨なわけではない

しかし docker 自体が非推奨なのかというとそうではなく、現在においても docker の使用で全く問題ない。
自宅鯖の kubernetes 化を見据えたため docker 非依存にする一貫として nerdctl を採用しただけである。
(nginx-proxy などが docker 依存のようで、それらを混入させてしまうことを防ぐ目的である。)
kubernetes の docker 非推奨化で勘違いして騒がれた際に書かれたこちらの記事が丁寧に説明されている。Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ

nerdctl + containerd の構築

nerdctl + containerd の構築自体はドキュメント通りに進めることで問題なく完了できた。
筆者は Arch Linux を使用しているため pacman でインストールしたが、他のディストロでも問題なく進むだろう。
Arch Linux では nerdctl の依存に containerd が入っているため、インストール後に systemd から containerd を有効化すれば、 root 権限での動作は行えるようになる。

これで root 権限無しでも $ nerdctl run helloworld は動作し、 nerdctl compose コマンドで docker-compose.yml ファイルを使用したコンテナも起動するようになっているはずである。

終わりに

個人開発では docker でも問題ないとはいえ、自宅サーバを kube 化する予定のある方や、 Docker Desktop のライセンス問題の回避のために代替を探している方はこの辺りの知識があるとより本番との互換性を意識して選定ができるのではないかと思う。