apt-get installでのversion pinの是非

Dockerfileにも当然ベストプラクティスが存在し、それをチェックするLinterも存在します。

• Best practices | Docker Docs
• GitHub - hadolint/hadolint: Dockerfile linter, validate inline bash, written in Haskell

そのベストプラクティスと呼ばれる1つに、apt-get installでのversion pinがあります。

version pinとは

一言で言えば、apt-get installでパッケージをインストールする際、明示的にパッケージバージョンを指定することです。 Datadogのブログ記事にも、このベストプラクティスが紹介されています。

version pinといっても具体的にどういうものか、となるので、ベストプラクティスに則った例を上記エントリから引用します。

FROM debian:12
RUN apt-get install python=3.11

ここでは、Pythonのバージョンを3.11に固定することで、勝手に3.12などがインストールされてしまい、それによる予期せぬ動作の変更を防げます。要するに、ビルドの再現性を高めているわけですね。

version pinのメンテが辛い

僕はhadolintに怒られたために、このversion pinを導入しました。しかし、これが結構面倒なんですよね。
何が面倒なのかというと、パッケージリポジトリも容量は有限なので、古いバージョンのパッケージが削除されてしまうんですね。結果として、Dockerfileは変えていないのに、ビルドが失敗することになってしまった。ビルドの再現性を高めたはずが、逆に再現性が崩れてしまったわけです。

また、ベースイメージタグを厳密に指定していない中でパッケージのみversion pinを行ったら、当然ビルドは失敗しやすくなります。

今後どうするか

もちろんすべてのバージョンをガチガチに固められれば理想的かもしれませんが、セキュリティアップデート等も取り込めず、上記のようにビルドも壊れてしまった中で、イマイチversion pinのメリットを感じられません。もうversion pinは諦めて、ビルドが壊れたら考える、ということにしたい。

でもどうなんですかね、JavaもPythonもGoも、利用するライブラリのバージョンはロックしてテストを行い、それを本番環境に反映するのが一般的です。アプリケーションが利用する環境にあるパッケージはどこまでロックするべきなのか、というのは難しい問題ですね。

この話、結局のところ包括的なテストを簡単にできるようにしよう、という話になりそうで厄介なんだよな。