このページで解説している内容は、以下の YouTube 動画の解説で見ることができます。

Docker超入門：ONBUILD実践➂：base-imageとwhale-imageの構築手順

ONBUILD実践➂：base-imageとwhale-imageの構築手順

　前回までで base-image を作成し、ONBUILD命令が1回目のビルドでは発動しないことを確認しました。
いよいよ今回は 2回目のビルド を行い、ONBUILDが実際に動作する流れを解説していきます。

ここで行うことの確認

　「ONBUILD実践➂：base-imageとwhale-imageの構築手順」では、下図のオレンジ枠の２回目のビルド操作を行っていきます。

webcontent.tar の作成

　ONBUILDでは tar 形式でまとめた Web コンテンツをコピーする設定をしました。ここでは index.html と whale.png をまとめてアーカイブします。

コマンド書式

tar cvf アーカイブ名 ファイル1 ファイル2 …
オプション説明
c新しいアーカイブを作成
v処理中のファイルを表示（verbose）
f出力するファイル名を指定

実行例

tar cvf webcontent.tar index.html whale.png

出力例

PS C:\Users\joeac\Desktop\docker\Webserver2> tar cvf webcontent.tar index.html whale.png
a index.html
a whale.png

出力には a index.html や a whale.png が表示され、まとめられたことが確認できます。
さらに ls コマンドで確認すると webcontent.tar が生成されています。

PS C:\Users\joeac\Desktop\docker\Webserver2> ls

    Directory: C:\Users\joeac\Desktop\docker\Webserver2

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          2025/09/27    23:25             71 Dockerfile
-a---          2025/09/27    23:25            381 Dockerfile.base
-a---          2025/09/27    23:27             95 index.html
-a---          2025/09/28     1:26          10752 webcontent.tar
-a---          2025/09/27    22:16           7792 whale.png

base-container の停止

新しいイメージをビルドする前に、稼働中の base-container を停止しておきます。

PS C:\Users\joeac\Desktop\docker\Webserver2> docker container stop base-container
base-container
コマンド説明
docker container stop <コンテナ名>指定したコンテナを停止する。

ここでは base-container が対象です。

2回目のビルド（whale-image の作成）

次に、Dockerfile を用いて whale-image をビルドします。

ここで、「Dockerfile.base」と「Dockerfile」を確認しておきます。

「Dockerfile」では、ベースイメージに「base-image」を指定しています。

２回目のビルド時に「ONBUILD ADD webcontent.tar /var/www/html」が実行されます。

「base-image」は、既に作成済みなので、「whale-image」を作成します。

実行例

docker build -t whale-image .
オプション説明
-t作成するイメージの名前を指定。ここでは whale-image
.カレントディレクトリをビルドコンテキストとして使用

　このとき、Dockerfile.base に仕込まれていた ONBUILD ADD webcontent.tar /var/www/html が発動し、webcontent.tar が /var/www/html にコピーされます。
つまり、2回目のビルドで初めて Web コンテンツが自動配置されるわけです。

出力例

PS C:\Users\joeac\Desktop\docker\Webserver2> docker build -t whale-image .
[+] Building 1.2s (7/7) FINISHED                                 docker:desktop-linux
 => [internal] load build definition from Dockerfile                             0.1s

（省略）

 => => unpacking to docker.io/library/whale-image:latest                         0.1s

View build details: docker-desktop://dashboard/build/desktop-linux/desktop-linux/n33yjqgns26iptmlxxxmt64e3

whale-container の作成と実行

作成した whale-image をもとにコンテナを起動します。

実行例

docker run --name whale-container -it -d -p 80:80 whale-image
オプション説明
--name whale-containerコンテナ名を whale-container に指定
-it対話モード + 擬似TTYを付与
-dバックグラウンドで起動
-p 80:80ホストの80番ポートをコンテナの80番ポートに割り当て

出力例

PS C:\Users\joeac\Desktop\docker\Webserver2> docker run --name whale-container -it -d -p 80:80 whale-image
49666bc6cd1d07ca4f96cbe8c499cc021510b636bdc7fad6735dffa38554e120

これで whale-container が起動し、Nginx が Web コンテンツを配信します。

Webブラウザで確認

　ブラウザを開いて http://localhost にアクセスすると、今度は Nginx のデフォルトページではなく、ONBUILD でコピーされた index.html と whale.png が反映されたページ が表示されます。

ONBUILDで準備したWebコンテンツが表示されます。

イラストで理解する ONBUILD の流れ

ONBUILD の動作を図で表現すると直感的に理解できます。

まとめ

　ここまでの流れで、ONBUILD命令が「1回目のビルドでは保留され、2回目のビルドで発動する」ことを実際に体験できました。

  • 1回目：base-image を作成（ONBUILDはまだ動かない）
  • 2回目：whale-image を作成（ONBUILDが発動してWebコンテンツが配置される）
  • コンテナ起動後：ブラウザでカスタムページが表示される

　この仕組みを利用すると、開発用のベースイメージにあらかじめ ONBUILD を仕込んでおき、後続のビルドで必要な処理を自動化できます。結果として、環境構築の手間を減らし、チーム開発やデプロイ作業を効率化できるのです。

ONBUILD命令の注意点

ONBUILD命令は、ベースイメージを作るときにとても便利な仕組みです。
　しかし、便利さの裏にはいくつか注意しなければならないポイントがあります。ここを理解していないと、「なぜか思った通りに動かない…」というトラブルに直面してしまうこともあるんです。

ONBUILDは「次のビルド」で実行される

　ONBUILD命令は、自分のビルドでは実行されず、次のビルドで発動するという特殊な動きをします。
　これを忘れると「ビルドしたのにCOPYされていない」「ADDが効いていない」といった勘違いにつながります。

図で表すとこんなイメージです。

意図しないコマンドが実行される可能性

ONBUILDで定義した命令は、そのイメージをベースにする人すべてに影響します。
つまり、自分だけでなく、他の開発者がそのイメージを利用したときにも勝手に実行されます。

　これが便利な場面もありますが、場合によっては「不要なCOPYが走る」「セキュリティ的に避けたい処理が入る」などのトラブルになる可能性があります。

トラブルを避けるための工夫

ONBUILD命令を使うときのポイントを表にまとめました。

注意点解説
1回目では動かないONBUILDは次のビルドで発動するため、動作確認のタイミングを間違えやすい。
影響範囲に注意他人がベースイメージを利用するときに、不要な処理が走る危険がある。
過度に多用しないすべてをONBUILDに任せると「ブラックボックス化」し、管理が難しくなる。
代替手段を検討明示的にCOPYやRUNを記述したほうがわかりやすい場面もある。

実務でのベストプラクティス

  • チームで共有するイメージでは、ONBUILD命令を多用しすぎない。
  • 「自分専用」のビルド環境など、用途が限定されるケースで使う。
  • 公式イメージや他人のイメージをベースにする場合は、ONBUILD命令が仕込まれていないか確認する。

まとめ

ONBUILD命令は、後続のビルドに自動処理を仕込めるとても便利な仕組みです。
　しかし、「いつ発動するのか」「誰に影響するのか」 を意識しないと、思わぬトラブルを招くことがあります。

　適切に使えば、環境構築を自動化して効率アップにつながりますが、使いすぎず「ここぞ！」という場面で活用するのがベストです。