イメージの配布——レジストリとタグ
自分でビルドしたイメージを他のマシンやチームに届けるには、レジストリと呼ばれる保管庫にアップロードします。ここではDocker HubやGitHub Container Registryといったレジストリの役割、image名の構造、タグの付け方とpush・pullの流れを学びます。特に「latest」という便利だが罠にもなるタグの正体を理解し、実務で事故らないバージョン運用の考え方まで押さえます。
自分のマシンでビルドしたイメージは、そのままでは自分のマシンの中にしか存在しない。別のマシンやサーバー、あるいはチームの他のメンバーに使ってもらうには、どこかに届ける必要がある。
この「届け先」の役割を果たすのがレジストリだ。イメージを保管し、必要なときに取り出せるようにする倉庫のような場所になる。
🏬 レジストリという保管庫
代表的なレジストリには、Dockerの公式であるDocker Hub、GitHubが提供するGitHub Container Registry（略してghcr.io）などがある。企業では自社専用のプライベートレジストリを用意することもある。
これまでのトピックでdocker pullしてきたpostgresやnginxといったイメージも、実はDocker Hubというレジストリから取得していたものだ。レジストリは初心者のうちから知らずに使っている、身近な仕組みだ。
🧾 image名の構造
レジストリを扱うために、まずimage名の構造を分解しておこう。フルの形式はregistry/名前空間/名前:タグ となる。registryを省略するとDocker Hubが暗黙に補われる。
たとえばpostgres:16は、実際にはdocker.io/library/postgres:16の短縮形だ。自分のDocker Hubアカウントに置く場合はmyuser/myapp:1.0のように名前空間として自分のユーザー名が入り、GitHub Container Registryならghcr.io/myuser/myapp:1.0のようにレジストリのドメインが先頭に付く。
🏷️ tag・push・pullの流れ
自分でビルドしたイメージにレジストリへ送るための名前を付けるには、docker tagを使う。ローカルでmyapp:latestとしてビルドしたイメージに、レジストリ用の正式な名前を付け直すイメージだ。
名前を付けたら、docker pushでレジストリへ送信する。受け取る側は、docker pullで同じ名前を指定すれば、同じイメージを取得できる。
⚠️ latestの罠
タグを省略すると、既定でlatestというタグが使われる。名前だけ見ると「常に最新版」に思えるが、実際にはただの1つのタグ名にすぎない。
問題は、latestという同じタグ名のまま中身だけを何度でも上書きpushできてしまうことだ。1週間前にpullしたlatestと、今日pullしたlatestが、実は全く違う中身になっている、ということが起こりうる。
🔒 ダイジェスト固定とバージョンタグ運用
この罠を避けるため、実務ではタグ名だけでなく、より厳密な識別子を使うことがある。それがダイジェスト（sha256から始まる長いハッシュ値）だ。ダイジェストはイメージの中身そのものから計算されるため、中身が1バイトでも変われば別の値になる。
本番運用では、latestのような曖昧なタグではなく、myapp:1.4.2のような具体的なバージョン番号のタグを使い、必要に応じてダイジェストで固定する運用が安全とされる。バージョンタグなら「1.4.2で動作確認した」という事実がそのまま追跡できる。
イメージを安全に配布・取得できるようになったら、あとはそのコンテナをどう安定して動かし続けるかだ。次は再起動や資源制限といった運用の基本を見ていく。