Dockerの「latest」タグを理解する
Dockerのタグは、名前によってイメージを識別するために使用されます。各イメージには複数のタグを割り当てることができます。タグはmy-image:latestのような形をしており、コロンの前の部分がイメージ名を定義し、後の部分がバージョンを指定します。
コロンの後に何もなくても、画像にタグを付けることができます。画像には自動的にlatestがそのバージョンタグとして付与されます。これはDockerの初心者にとって一般的な混乱の原因です。
最新の問題点
latest タグの意味は、実際に存在する以上の特別な意味を示唆しているようです。実際には、latest は他に何も指定していない場合のデフォルトタグとして使用されます。それが使用されるのはその時だけであり、あなたが作成した最新のイメージを自動的に指すわけではありません。
ここに結果として得られる問題の例があります:
Creates my-image:latest (first image)
docker build -t my-image
Updates my-image:latest (second image)
docker build -t my-image:latest
Creates my-image:v1 (third image)
docker build -t my-image:v1
もし今、docker run my-image:latest を実行した場合、構築された2番目のイメージが使用されます。v1 タグはlatestとは完全に独立しているため、3番目のイメージを構築しても既存の2つには影響しません。もしmy-image:v1もlatestイメージにしたい場合は、手動でタグを付けて別の操作でプッシュする必要があります。
これにより、Dockerエコシステム内で多くの混乱が生じます。多くのイメージ作成者は最新のリリースにlatestタグを付けています。これにより、Dockerが意図していなかった重要性がこのタグに付与されます。別の著者は開発ビルドにlatestを使用する一方で、latestタグをまったく公開しない人もいます。
画像の著者間での一貫性の欠如は、latestが本当に最新の画像であるかどうかを不明瞭にする可能性があります。latestの最も重要なルールは、特定の画像がタグをどのように使用するかについて決して仮定しないことです。
最新へのピン留めを避ける
より具体的な代替手段が利用可能な場合、画像のlatestタグを使用すべきではありません。画像の作者がlatestタグを積極的に更新していることを知らない限り、それに対して固定すると、期待するバージョンを得られないかもしれません。
ほとんどのイメージはセマンティック バージョニングを使用してリリース タグを作成します。my-image:1.1 を取得する方が my-image:latest よりもずっと安全です。もし著者が latest を維持していない場合、古くて役に立たないイメージになる可能性があります。逆に、latest を維持している著者は、しばしば最新の開発バージョンにそのタグを使用します。これに固定することは、警告なしに定期的に重大な変更が起こる可能性が高いです。
いくつかのコンテナエコシステムプロジェクトは、この理由から latest の使用を警告しています。Kubernetesは、latest を使用することが予測不可能であるだけでなく、コンテナで使用される実際のイメージバージョンを特定するのが難しくなると指摘しています。
latest タグでデプロイされたコンテナをロールバックすることは、直接的には不可能です。作業するための参照点がありません。イメージタグを 1.1.0 から 2.1.0 に変更すると、必要に応じてアップグレードを簡単に元に戻すことができます。コンテナオーケストレーションツールは「新しい latest イメージ」を「古い latest イメージ」に戻す手助けはできません。
不変性
より根本的には、良いタグ付けの実践は、画像タグは不変であるべきだと指示します。一度タグが付けられたら、そのタグは同じ画像に再利用されるべきではありません。これにより、下流の消費者は特定のバージョンに固定でき、毎回同じ画像が得られるという安心感を持つことができます。
latestは本質的に可変であるため、このシステムを壊します。latestを使用する場合、変更を受け入れる必要があります。画像の作成者として、latestタグのみで公開する場合、ユーザーがあなたの画像を自信を持って参照することをより難しくします。
多くのツールは、画像タグの使用方法について仮定を立てます。latestは特別扱いされることが多く、常に注意を払う必要があります。たとえば、Kubernetesは、latestタグの新しいバージョンを常に取得しようとしますが、既にローカルに存在していてもです。他のタグは、クラスタ内に既に存在しない場合にのみ取得されます。
タグ付けのより良いアプローチ
公開される画像にタグを付けるときは、セマンティック バージョニングに従うようにしてください。これは、画像に加えた各変更の重要性を伝えるのに役立つ、広く理解されている標準です。
プライベート用の画像を作成する際、より多くのオプションがあります。CIサーバーによって生成された画像は、パイプラインを実行したコミットのSHAでタグ付けされることがよくあります。これにより、各パイプラインが将来的に上書きされることのないユニークなタグを作成します。また、これにより、コンテナレジストリ内の画像を、それらを生成したコードベースの変更と照合するのに役立ちます。
最後に、latest タグについて考えすぎないでください。あなたのイメージの「最新」バージョンでそれを更新する必要はありません。しばしば、まったく無視するのが最善です - docker buildをタグ名なしで実行しない限り、それは決して作成されません。もしlatest タグを公開する場合は、それが何を示すのかを明確にしておいてください。
要約
Dockerのlatestタグの一見したシンプルさは、さまざまな問題の沼を隠しています。イメージの作成者としても、消費者としても、これらの問題に直面するでしょう。問題は、タグの意味的な不整合から生じています。動的に聞こえる一方で、それはユーザーが指定した値がない場合にDockerによって割り当てられる静的なタグに過ぎません。
可能な限り、特定のイメージバージョンを固定するべきです。これにより、破壊的な変更やあいまいなサードパーティのツールの動作を避けることができます。イメージの作者として、セマンティックリリースバージョンを提供し、プロジェクトがlatestをどのように扱うかを明確にするよう努めてください。これにより、潜在的なユーザーがイメージを参照する方法を評価するのに役立ちます。