hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

個人で作ったツールをなんでもDocker Hubに上げる姿勢に違和感を感じてきた

docker pullしてdocker runするだけで動いて便利じゃん、各言語のセットアップとかも省けるのでどこでも動いてありがたい、と思っていて、個人で作ってるツールもDocker Hubに上げたりしていた。
でも最近は、そういう時代でもないのかな、と思ってきている。

各言語でのライブラリ管理と二重の管理になってしまう

Node.jsで作ったツールのイメージを作ると、awesome-tool2.0っていうdockerイメージの中にawesome-tool2.0がインストールされていて、そのイメージにNode.jsも同梱する形になる。
awesome-tool3.0をリリースするときには、まずはnpmに3.0を公開して、そのあとでDockerHubにもビルドして公開する、という流れになる。
各言語のパッケージマネージャのライフサイクルと別に、DockerHubへの公開、というフローが挟まるのがめんどう、という管理の手間もあれば、利用者からすると、ちょっとしたツール(その実装は100行もなかったりする)をいくつか使いたいだけなのにイメージが続々とダウンロードされてそのなかにいくつもNode.jsが入っていて格好悪い、という利用上の手間もある。

CIではインストール結果をキャッシュできる環境が整ってきている

自作ツールをDockerイメージとして配れば、毎回依存モジュールをインストールしなくても、ツールのイメージをpullするだけで動いて便利じゃん、とくにCIでは毎回多数の依存モジュールのインストールのを待ちたくない、という考えがあった。
GitHub Actionsなどを使うと、CI環境に依存関係をキャッシュするのが簡単になってきていて、毎回ビルドのたびにすべてのライブラリをインストールする、ということは想定しなくてよい形になってきている。
テスト対象のアプリケーションの環境にawesome-toolもインストールしておいて、必要になったら実行する、という形を取れば、DockerHubにツール単体のイメージを置いておく必要はなくなる。
docs.github.com

先日、perltidyをCIで実行したくなって様子を見ていたら、その場でcpanmしてインストールしてしまって、ただちに実行する、というアプローチが取られていた。
github.com

言語のインストールまでが済んだbaseイメージから始める、というアプローチをとれば、最初に書いたような、 1ツール1言語ランタイム、みたいな状況は脱することができる。

Docker Hubが有償化してきている

Docker Hubは有償化してきていて、効率の悪いpullを繰り返していると制限に当たったりする。
OSSプロジェクトなら引き続き無償で使えるはずなのだけど、申請フォームを見ると、そのツールで何名が役に立っていますか?みたいなことを書いてDocker Hubのレビューを受ける、という流れで、大したものは作ってないし、日曜大工的に作ってるだけなのでそこまでやり取りはしたくないな、と腰が重くなって申請するのをやめてしまった。
自作のイメージを配布する難易度が上がってきているので、ツール単体でpullするんじゃなくて、言語ランタイムくらいをpullしておいて、そのイメージの上でいろんなツールを動かしたほうが、イメージのpullの苦労を下げられそうだな、と思い始めてきている。
普通に考えれば、黙って無制限に使わせてほしい、というのは都合の良い話で、これまで無料でイメージをホスティングしてくれているのは気前が良すぎるので感謝しなければならないのだけど、コンテナ化しなければ、GitHubやnpmを使って気前よくなんでも無料でホスティングしてくれてる暮らしができていたので、それに慣れてしまっているのかもしれない…。


どういう単位でイメージを分けるかとかはベストプラクティスがありそう。ここにまとまってるこの方針を参考にすれば良いよ、とあかったら教えてもらいたいです。

追記

GitHub Container Registoryはどうですかって教えてもらった。そういえばあるのは知ってたけど触ったことなかったので試してみたい。
docs.github.com