docker compose upの--pullオプション、missingでもlatestタグは毎回プルされることがあるらしい
この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。
docker composeで指定してるイメージを最新にする手順を確認したのでメモ。基本はシンプルだけど、--pullオプションのpolicy周りで気になる挙動があった。
基本の更新手順
やることは2つだけ。
docker compose pulldocker compose up -dpullでレジストリから最新イメージを取得して、up -dで差分があれば再作成、なければそのまま維持される。既存コンテナのconfigやイメージが変わってなければ何も起きない。
固定タグ（myapp:v1.2.3）ならこの2ステップで十分。latestタグだと「いつ変わったか」が追いにくくなるので、本番運用では固定タグかdigest指定（myapp@sha256:...）の方が再現性は高い。
--pullオプションでワンコマンド化
docker compose upに--pullをつけると、起動時に自動でプルしてくれる。
docker compose up -d --pull always指定できる値はalways / missing / neverの3つで、デフォルトはpolicy（compose.ymlのpull_policyフィールド、未指定ならmissing相当）。
always: 毎回プルするmissing: ローカルにイメージがなければプルするnever: プルしない
compose.yml側にもpull_policyを書ける。値の種類はもう少し多くて、dailyやevery_12hのような時間ベース指定もあるらしい（実機未確認）。digest固定みたいに絶対に変わらないイメージにはmissing、featureブランチのimageみたいに常に追いたいものにはalways、という使い分けが基本になりそう。
missingでもlatestタグは再プルされることがある
ここが気になったポイント。GitHubのdocker/composeのissueで、--pull missingを指定してるのにphpmyadmin:latestが既にローカルにあるにもかかわらず毎回プルを試みる、という報告があった（#12726）。
missingポリシーは「イメージが存在しなければプルする」という定義のはずだけど、latestタグの場合はcomposeが「常に最新か確認する」動作になってる可能性がある。実機で検証したわけじゃないので断定はできないけど、latestタグを使ってる環境で--pull missingを過信しない方がよさそう。
固定タグやdigest運用にしておけば、この手の「意図しない再プル」問題自体を避けられる。
ビルドしてる場合
image:じゃなくてbuild:でローカルビルドしてる場合は、そもそもpullの対象にならない。
docker compose builddocker compose up -dベースイメージまで更新したいときはdocker compose build --pullでベースイメージの再取得を強制できる。今回はここまでは試してない。
後片付け
再作成後に古いイメージが残るので、不要なら消しておく。
# 未使用イメージの削除（タグなしイメージ含む）docker image prune
# 使われていないコンテナ・ネットワーク・イメージまとめて削除docker system prunedocker system pruneは範囲が広いので、本番環境で使うときは-aつけずに一旦様子見した方が安全。