I have a Dockerfile that I use to build the same image but for slightly different purposes. Most of the time I want it to just be an "environment" without a specific entrypoint so that the user just specifies that on the Docker run line:

docker run --rm -it --name ${CONTAINER} ${IMAGE} any_command parameters

But for some applications I want users to download the container and run it without having to set a command.

docker build -t ${IMAGE}:demo (--entrypoint ./demo.sh) <== would be nice to have

Yes, I can have a different Dockerfile for that, or append an entrypoint to the basic Dockerfile during builds, or various other mickey-mouse hacks, but those are all just one more thing that can go wrong, adding complexity, and are workarounds for the essential requirement.

Any ideas? staged builds?

CodePudding user response：

Excuse me if I am out of scope, but what about using tags to express the difference in the images?

E.g You could have image_name:no-entrypoint, if the users use that image they have to specify an entrypoint and arguments

And another image_name:with_entrypoint, in this case the user can run it as is.

CodePudding user response：

The Dockerfile CMD directive sets the default command. So if your Dockerfile ends with

CMD default_command

then you can run the image in multiple ways

docker run "$IMAGE"
# runs default_command

docker run "$IMAGE" any_command parameters
# runs any_command instead

A container must run a command; you can't "just run a container" with no process in it.

You do not want ENTRYPOINT here since its syntax is noticeably harder to work with at the command line. Your any_command would be passed as arguments to the entrypoint process, rather than replacing the built-in default.