Originally published on https://oprea.rocks/blog/how-to-properly-override-the-entrypoint-using-docker-run/
As we all know, Docker is an amazing piece of software. I don’t want to go over its benefits. That’s for another article, coming very soon. What I do want to share with you is the way to properly override a Docker image
entrypoint when using
The ENTRYPOINT of an image is similar to a COMMAND because it specifies what executable to run when the container starts, but it is (purposely) more difficult to override
Keep in mind the “what executable to run” part!
Many people trying to override the
ENTRYPOINT at runtime, using
docker runwill make mistake of passing the executable's arguments directly after it, like so (happy horizontal scrolling):
docker run --entrypoint "/bin/ls -al /root" debian
What is the problem here? Well the documentation clearly states that the
ENTRYPOINT only specifies the executable to run, when the container starts.
So they get an error like below
container_linux.go:247: starting container process caused "exec: \"/usr/bin/ls -al\": stat /usr/bin/ls -al: no such file or directory"
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"/usr/bin/ls -al\": stat /usr/bin/ls -al: no such file or directory".
ERRO error getting events from daemon: net/http: request canceled
There is something a bit counter-intuitive here and if you take a good look at the example commands on the documentation page, you’ll see that the arguments are being passed after the image name.
docker run -it --entrypoint /usr/bin/redis-cli example/redis --help
This means that if we want to pass the
-al flags to our
ls command we should write the whole thing like this:
docker run --entrypoint "/bin/ls" debian -al /root
Hope this clears things out for you and saves you a ton of headaches.