Docker イメージの公開
1. Dockerイメージのタグ (Tags) を深く理解する
Dockerイメージのタグ（Tags）は、イメージに貼り付ける「人間が読める付箋」のようなものであり、主にイメージの特定のバージョンやバリアント（Variant）を識別するために使用されます。完全なタグ名は、リポジトリ（Repository）名とタグ名の2つの部分で構成され、コロン (:) で区切られます。操作時にタグを指定しない場合、Dockerは常にデフォルトで latest タグを使用します。
1.1 Dockerタグの解剖学
完全に仕様に準拠したDockerイメージ名は次のようになります：docker.io/username/image_name:tag。これを分解して見てみましょう：
docker.io: これはイメージレジストリ（Registry）のドメイン名です。省略した場合、Dockerはデフォルトで公式の Docker Hub (docker.io) を使用しているとみなします。他社のレジストリを使用する場合は、そのドメイン名（Googleのgcr.ioや社内レジストリのドメイン名など）に置き換える必要があります。username: Docker Hubのユーザー名（または組織名）です。これは非常に重要であり、Docker Hubに対してあなたのイメージをどの「フォルダ」に保存すべきかを指示します。image_name: このイメージに付けた具体的な名前です。名前はシンプルで分かりやすく、そのイメージにどのようなアプリケーションやサービスが含まれているかを示すものであるべきです。tag: 具体的なバージョン番号やバリアントの識別子です。一般的なタグには、latest（最新版）、1.0、2.0-beta（ベータ版）、stable（安定版）などがあり、コードコミットのハッシュ値（Commit Hash）を使用することもできます。
1.2 なぜわざわざタグを付けるのか？
- バージョン管理 (Versioning): タグを使用すると、アプリケーションの異なるバージョン（例：
1.0、1.1、latest）を同時に並行してメンテナンスできます。 - 再現性 (Reproducibility): プロダクション環境では、いつでも変更される可能性のある
latestタグを絶対に使用すべきではありません。明確な数値のバージョンタグを使用するべきです。これにより、デプロイ（Deploy）のたびに全く同じ内容がプル（Pull）されることが保証されます。 - 組織管理 (Organization): タグを使用すると、アプリケーションの現在の状態を簡単に区別できます。例えば、開発環境 (dev)、ステージング環境 (staging)、プロダクション環境 (prod) のイメージをタグで明確に分けることができます。
- 迅速なロールバック (Rollbacks): リリースしたばかりの 2.0 バージョンに致命的なバグ (Bug) があった場合、サーバー上のイメージタグを 1.9 に戻すだけで、瞬時にロールバックを完了できます。
2. 既存のイメージにタグを付ける
イメージにタグを付けるには、docker tag コマンドを使用します。基本構文は以下の通りです：
docker tag ソースイメージ[:旧タグ] ターゲットイメージ[:新タグ]- ソースイメージ: タグを付けたい元のイメージ。イメージIDを使用することも、既存の名前とタグを使用することもできます。
- ターゲットイメージ: 付与したい新しい名前と新しいタグ。フォーマットは必ず ユーザー名/イメージ名:タグ とします。
2.1 タグ付けの実践デモンストレーション
シナリオ1：イメージIDを使用したタグ付け
docker images で確認したビルド（Build）したばかりのイメージのIDが a1b2c3d4e5f6 であり、これをバージョン 1.0 と命名したいと仮定します。
docker tag a1b2c3d4e5f6 myusername/myimage:1.0シナリオ2：既存のイメージに新しいタグを追加する
ローカルにすでに myimage:latest というイメージがあり、これに 1.0 というタグを追加し、プッシュ（Push）に備えてユーザー名も付与したいと仮定します。
docker tag myimage:latest myusername/myimage:1.0注意：これはイメージ自体をコピーするわけではありません。同じ物理イメージに複数の付箋を貼るだけです。これら2つのタグは、現在全く同じ基盤のイメージレイヤー（Layer）を指しています。
シナリオ3：Beta版（ベータ版）のリリース
webapp に対して大規模なリファクタリングを行い、テスト版をリリースしたいとします。
docker tag webapp:latest myusername/webapp:2.0-betaこれにより、テスターは専属で 2.0-beta をプルしてテストを実行でき、一般ユーザーは引き続き安全に latest バージョンを使用し続けることができます。
3. イメージを Docker Hub にプッシュ (Push) する
タグ付けが完了したら、次はいよいよ公開フェーズです！プッシュする前に、ターミナル（Terminal）でDocker Hubアカウントにログイン（Login）する必要があります。
3.1 Docker Hub へのログイン
docker login コマンドを使用します：
docker loginターミナルでDocker Hubのユーザー名とパスワードの入力を求められます。2要素認証 (2FA) を有効にしている場合、ここではログインパスワードを入力することはできず、Web画面でパーソナルアクセストークン (Personal Access Token) を生成し、それをパスワードとして入力する必要があります。
3.2 プッシュ操作の実行
docker push コマンドを使用して、タグ付けされたイメージをクラウドにプッシュします。構文は非常にシンプルです：
docker push イメージ名[:タグ]例：
先ほどタグ付けした 1.0 バージョンをプッシュします：
docker push myusername/myimage:1.0ターミナルにプログレスバーが表示され、Dockerがイメージをレイヤーごとに Docker Hub へアップロードしているのが分かります。
複数のタグのプッシュ：
この 1.0 バージョンを同時に最新のデフォルトバージョンにもしたい場合は、両方のタグをプッシュする必要があります：
docker push myusername/myimage:1.0
docker push myusername/myimage:latest3.3 よくあるプッシュ失敗のトラブルシューティング (Troubleshooting)
- "denied: requested access to the resource is denied": 最も一般的なエラーです。通常、ログインを忘れているか、プッシュしようとしている
usernameが自分のアカウントではないことが原因です。イメージ名の中のユーザー名のスペルが間違っていないか確認してください。 - "unauthorized: authentication required": 認証の有効期限切れ、または失敗です。もう一度
docker loginを実行してください。 - "403 Forbidden": 通常、エンタープライズ/組織アカウント下のレジストリにプッシュしようとしたものの、個人アカウントに管理者からの「書き込み (Write/Push)」権限が付与されていない場合に発生します。
4. イメージレイヤー (Layers) とプッシュ最適化メカニズム
Dockerイメージは階層化（レイヤー化）されています。docker push を実行する際、Dockerは非常にスマートで、Docker Hub上にまだ存在しないレイヤーのみをアップロードします。
アプリケーションコードの1行だけを変更して再ビルドした場合、基盤となる大部分のシステムレイヤーや依存パッケージレイヤーはすでに Docker Hub 上に存在するため、Dockerはそれらを直接スキップし、変更があった数十KBのコードレイヤーのみをアップロードします。これが、最初のプッシュには数分かかる場合でも、その後のアップデートのプッシュがわずか数秒で完了する理由です。
4.1 プッシュとプルをより高速にするには？
イメージが小さいほど、ネットワーク転送は高速になります。前の章で最適化テクニックについて詳しく解説しましたが、ここで簡単に復習しましょう：
- 軽量なベースイメージの使用: 例えば Alpine Linux を選択します。
- コマンドの統合:
&&を使用して複数のRUNインストラクションを繋ぎ、レイヤー数を減らします。 - こまめなクリーンアップ: ソフトウェアのインストール完了後、すぐにインストールパッケージのキャッシュを削除します。
- マルチステージビルド (Multi-stage builds): 究極の切り札です。コンパイル環境と実行環境を分離し、最終的な実行成果物のみを保持します。