DockerfileにはENTRYPOINTとCMDという2種類のコンテナ起動コマンド指定方法がありますが、これらの違いや、どう使い分けるべきかは初心者にとって分かりづらいポイントの一つです。
本記事では、
- ENTRYPOINTとは何か
- CMDとの違い
- ENTRYPOINTの基本的な使い方
- ENTRYPOINTを上書きしてコンテナ内に入る方法（デバッグや一時的な変更に便利）
といったポイントを分かりやすく解説します。
ENTRYPOINTとは
ENTRYPOINTはコンテナが起動した際に「必ず実行されるコマンド」を定義する命令文です。Dockerfileで設定することで、そのイメージから生成される全てのコンテナは同じENTRYPOINTコマンドを実行します。
例えば、以下のようなDockerfileがあったとします。
FROM alpine:latest
ENTRYPOINT ["echo", "Hello"]このイメージからコンテナを起動すると、echo "Hello"が必ず実行され、コンテナは「Hello」を表示して終了します。
CMDとの違いは？
CMDも似たような役割を持ちますが、CMDは「デフォルトで実行されるコマンド」の指定です。
デフォルトなのでイメージ実行時の引数で上書きできます。
一方、ENTRYPOINTは「必ず実行されるコマンド」の指定となります。
両者を組み合わせることで、ENTRYPOINTでメインコマンドを固定しつつ、CMDでオプションや引数を柔軟に変更する、という使い方が可能です。
例えば以下のDockerfileを考えます。
FROM alpine:latest
ENTRYPOINT ["echo"]
CMD ["Hello", "World"]この場合、コンテナ起動時にecho Hello Worldが実行されます。
もしコンテナ起動コマンドでdocker run イメージ名 Foo Barのように引数を渡せば、echo Foo Barが実行されます。ENTRYPOINTはechoを固定し、CMDや実行時引数によってメッセージ部分を変更可能にしているわけです。
ENTRYPOINTを使うメリット
- メインプロセスの固定化:
アプリケーションやサービスを起動する際に、必ず実行しなければならないコマンドを固定できます。
例: Webサーバーの起動コマンドなど。 - 柔軟なオプション指定:
CMDやdocker run実行時に指定した引数がENTRYPOINTの後ろに引き継がれるため、柔軟に起動パラメータを変えられます。
ENTRYPOINTを上書きしてコンテナ内に入る方法
「必ず実行されるコマンド」がENTRYPOINTで固定されていると、コンテナにシェルで入って中を見たい時に不便に感じることがあります。
しかし、docker runコマンドでは--entrypointオプションを使ってENTRYPOINTを簡単に上書き可能です。
これにより、トラブルシューティングやデバッグがスムーズになります。
実例
先ほどのENTRYPOINT ["echo"]があるイメージを使って考えてみましょう。
通常、このイメージでコンテナを起動するとechoコマンドが実行されるだけで終了してしまいます。
docker run --rm your_image
# => Hello World（やCMDで定義した内容）を表示して終了しかし、--entrypointオプションを使ってsh（もしくは/bin/sh）をENTRYPOINTに指定すると、echoではなくshが実行されるため、そのままコンテナのシェルに入れます。
docker run --rm -it --entrypoint sh your_image上記コマンドを実行すると、コンテナ内部のshプロンプトに入ることができます。
ここでlsをしたり、環境変数を確認したりして、コンテナ内部の状態を確認できます。
ポイント
--entrypointを使うとENTRYPOINTで固定されていたコマンドを一時的に変更できる。-itオプションでコンテナ内部の対話型ターミナルへアクセス可能。- ENTRYPOINTが設定されているイメージでも、簡単にデバッグや環境確認ができる。
まとめ
ENTRYPOINTはコンテナの起動時に必ず実行されるコマンドを指定するためのDockerfile命令文です。CMDとの組み合わせにより、固定的な起動コマンドと可変的な引数をバランスよく運用できます。
一方でデバッグや一時的な状況確認の際には、--entrypointを活用してshなどのシェルへ直接コンテナ内に入ることが可能です。
これにより、トラブルシューティングや環境調査が格段に容易になります。
初心者のうちは、ENTRYPOINTとCMDの違いをしっかり理解し、目的に応じて使い分けられるようになれば、Dockerイメージ管理がよりスムーズになるでしょう。
