What is the difference between CMD and ENTRYPOINT in a Dockerfile?

The ENTRYPOINT specifies a command that will always be executed when the container starts.

The CMD specifies arguments that will be fed to the ENTRYPOINT.

If you want to make an image dedicated to a specific command you will use ENTRYPOINT ["/path/dedicated_command"]

Otherwise, if you want to make an image for general purpose, you can leave ENTRYPOINT unspecified and use CMD ["/path/dedicated_command"] as you will be able to override the setting by supplying arguments to docker run.

For example, if your Dockerfile is:

FROM debian:wheezy
ENTRYPOINT ["/bin/ping"]
CMD ["localhost"]

Running the image without any argument will ping the localhost:

$ docker run -it test
PING localhost (127.0.0.1): 48 data bytes
56 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.096 ms
56 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.088 ms
56 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.088 ms
^C--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.088/0.091/0.096/0.000 ms

Now, running the image with an argument will ping the argument:

$ docker run -it test google.com
PING google.com (173.194.45.70): 48 data bytes
56 bytes from 173.194.45.70: icmp_seq=0 ttl=55 time=32.583 ms
56 bytes from 173.194.45.70: icmp_seq=2 ttl=55 time=30.327 ms
56 bytes from 173.194.45.70: icmp_seq=4 ttl=55 time=46.379 ms
^C--- google.com ping statistics ---
5 packets transmitted, 3 packets received, 40% packet loss
round-trip min/avg/max/stddev = 30.327/36.430/46.379/7.095 ms

For comparison, if your Dockerfile is:

FROM debian:wheezy
CMD ["/bin/ping", "localhost"]

Running the image without any argument will ping the localhost:

$ docker run -it test
PING localhost (127.0.0.1): 48 data bytes
56 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.076 ms
56 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.087 ms
56 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.090 ms
^C--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.076/0.084/0.090/0.000 ms

But running the image with an argument will run the argument:

docker run -it test bash
root@e8bb7249b843:/#

See this article from Brian DeHamer for even more details: https://www.ctl.io/developers/blog/post/dockerfile-entrypoint-vs-cmd/

According to docker docs,

Both CMD and ENTRYPOINT instructions define what command gets executed when running a container. There are few rules that describe their co-operation.

1. Dockerfile should specify at least one of CMD or ENTRYPOINT commands.
2. ENTRYPOINT should be defined when using the container as an executable.
3. CMD should be used as a way of defining default arguments for an ENTRYPOINT command or for executing an ad-hoc command in a container.
4. CMD will be overridden when running the container with alternative arguments.

The tables below show what command is executed for different ENTRYPOINT / CMD combinations:

-- No ENTRYPOINT

╔════════════════════════════╦═════════════════════════════╗
║ No CMD                     ║ error, not allowed          ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD ["exec_cmd", "p1_cmd"] ║ exec_cmd p1_cmd             ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD ["p1_cmd", "p2_cmd"]   ║ p1_cmd p2_cmd               ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ /bin/sh -c exec_cmd p1_cmd  ║
╚════════════════════════════╩═════════════════════════════╝

-- ENTRYPOINT exec_entry p1_entry

╔════════════════════════════╦══════════════════════════════════╗
║ No CMD                     ║ /bin/sh -c exec_entry p1_entry   ║
╟────────────────────────────╫──────────────────────────────────╢
║ CMD ["exec_cmd", "p1_cmd"] ║ /bin/sh -c exec_entry p1_entry   ║
╟────────────────────────────╫──────────────────────────────────╢
║ CMD ["p1_cmd", "p2_cmd"]   ║ /bin/sh -c exec_entry p1_entry   ║
╟────────────────────────────╫──────────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ /bin/sh -c exec_entry p1_entry   ║
╚════════════════════════════╩══════════════════════════════════╝

-- ENTRYPOINT ["exec_entry", "p1_entry"]

╔════════════════════════════╦═════════════════════════════════════════════════╗
║ No CMD                     ║ exec_entry p1_entry                             ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD ["exec_cmd", "p1_cmd"] ║ exec_entry p1_entry exec_cmd p1_cmd             ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD ["p1_cmd", "p2_cmd"]   ║ exec_entry p1_entry p1_cmd p2_cmd               ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd  ║
╚════════════════════════════╩═════════════════════════════════════════════════╝

Yes, that is a good question. I don't understand it fully yet, but:

I understand that ENTRYPOINT is the binary that is being executed. You can overide entrypoint by --entrypoint="".

docker run -t -i --entrypoint="/bin/bash" ubuntu

CMD is the default argument to container. Without entrypoint, default argument is command that is executed. With entrypoint, cmd is passed to entrypoint as argument. You can emulate a command with entrypoint.

# no entrypoint
docker run ubuntu /bin/cat /etc/passwd

# with entry point, emulating cat command
docker run --entrypoint="/bin/cat" ubuntu /etc/passwd

So, main advantage is that with entrypoint you can pass arguments (cmd) to your container. To accomplish this, you need to use both:

# Dockerfile
FROM ubuntu
ENTRYPOINT ["/bin/cat"]

and

docker build -t=cat .

then you can use:

docker run cat /etc/passwd
#              ^^^^^^^^^^^
#                   CMD
#          ^^^      
#          image (tag)- using the default ENTRYPOINT

In a nutshell:

• CMD sets default command and/or parameters to the entrypoint, which can be overwritten from command line when docker container runs (docker run example "override").
• ENTRYPOINT command is overwritten before the image with its own command line flag (docker run --entrypoint="override" image). Then, all CMD arguments will be added after ENTRYPOINT as its parameters. In many cases, the entrypoint is set as sh -c. You can find this with docker inspect image -f '{{ .Config.Entrypoint }}'
• Both can be combined. (docker run --entrypoint="/docker-entrypoint.sh" image arg1 arg2)

If you need more details or would like to see difference on example, there is a blog post that comprehensively compare CMD and ENTRYPOINT with lots of examples - https://codewithyury.com/docker-run-vs-cmd-vs-entrypoint/

Difference between CMD and ENTRYPOINT by intuition:

• ENTRYPOINT: command to run when container starts.
• CMD: command to run when container starts or arguments to ENTRYPOINT if specified.

Yes, it's confusing.

You can override any of them when running docker run.

Difference between CMD and ENTRYPOINT by example:

docker run -it --rm yourcontainer /bin/bash            <-- /bin/bash overrides CMD
                                                       <-- /bin/bash does not override ENTRYPOINT
docker run -it --rm --entrypoint ls yourcontainer      <-- overrides ENTRYPOINT with ls
docker run -it --rm --entrypoint ls yourcontainer  -la  <-- overrides ENTRYPOINT with ls and overrides CMD with -la

More on difference between CMD and ENTRYPOINT:

Argument to docker run such as /bin/bash overrides any CMD command we wrote in Dockerfile.

ENTRYPOINT cannot be overriden at run time with normal commands such as docker run [args]. The args at the end of docker run [args] are provided as arguments to ENTRYPOINT. In this way we can create a container which is like a normal binary such as ls.

So CMD can act as default parameters to ENTRYPOINT and then we can override the CMD args from [args].

ENTRYPOINT can be overriden with --entrypoint.

I'll add my answer as an example¹ that might help you better understand the difference.

Let's suppose we want to create an image that will always run a sleep command when it starts. We'll create our own image and specify a new command:

FROM ubuntu
CMD sleep 10

Building the image:

docker build -t custom_sleep .
docker run custom_sleep
# sleeps for 10 seconds and exits

What if we want to change the number of seconds? We would have to change the Dockerfile since the value is hardcoded there, or override the command by providing a different one:

docker run custom_sleep sleep 20

While this works, it's not a good solution, as we have a redundant "sleep" command. Why redundant? Because the container's only purpose is to sleep, so having to specify the sleep command explicitly is a bit awkward.

Now let's try using the ENTRYPOINT instruction:

FROM ubuntu
ENTRYPOINT sleep

This instruction specifies the program that will be run when the container starts.

Now we can run:

docker run custom_sleep 20

What about a default value? Well, you guessed it right:

FROM ubuntu
ENTRYPOINT ["sleep"]
CMD ["10"]

The ENTRYPOINT is the program that will be run, and the value passed to the container will be appended to it.

The ENTRYPOINT can be overridden by specifying an --entrypoint flag, followed by the new entry point you want to use.

^{Not mine, I once watched a tutorial that provided this example}

There are some good answers for it. I want to explain it through demo per Doc

• CMD defines default commands and/or parameters for a container. CMD is an instruction that is best to use if you need a default command which users can easily override. If a Dockerfile has multiple CMDs, it only applies the instructions from the last one.
• ENTRYPOINT is preferred when you want to define a container with a specific executable.

You cannot override an ENTRYPOINT when starting a container unless you add the --entrypoint flag.

1. CMD

Docker file

  FROM centos:8.1.1911

  CMD ["echo", "Hello Docker"]

Run result

$ sudo docker run <image-id>
Hello Docker
$ sudo docker run <image-id> hostname   # hostname is exec to override CMD
244be5006f32

2. ENTRYPOINT

Docker file

  FROM centos:8.1.1911

  ENTRYPOINT ["echo", "Hello Docker"]

Run result

$ sudo docker run <image-id>
Hello Docker
$ sudo docker run <image-id> hostname   # hostname as parameter to exec
Hello Docker hostname

3. There are many situations in which combining CMD and ENTRYPOINT would be the best solution for your Docker container. In such cases, the executable is defined with ENTRYPOINT, while CMD specifies the default parameter.

Docker file

  FROM centos:8.1.1911

  ENTRYPOINT ["echo", "Hello"]
  CMD ["Docker"]

Run result

$ sudo docker run <image-id>
Hello Docker
$ sudo docker run <image-id> Ben
Hello Ben

The accepted answer is fabulous in explaining the history. I find this table explain it very well from official doc on 'how CMD and ENTRYPOINT interact':

I run across this and at the beginning I found it really confusing to be honest and I think this confusion comes from using the word "CMD" because in fact what goes there acts as argument. So after digging a little bit I understood how it works. Basically:

ENTRYPOINT --> what you specify here would be the command to be executed when you container starts. If you omit this definition docker will use /bin/sh -c bash to run your container.

CMD --> these are the arguments appended to the ENTRYPOINT unless the user specifies some custom argument, i.e: docker run ubuntu <custom_cmd> in this case instead of appending what's specified on the image in the CMD section, docker will run ENTRYPOINT <custom_cmd>. In case ENTRYPOINT has not been specified, what goes here will be passed to /bin/sh -c acting in fact as the command to be executed when starting the container.

As everything it's better to explain what's going on by examples. So let's say I create a simple docker image by using the following specification Dockerfile:

From ubuntu
ENTRYPOINT ["sleep"]

Then I build it by running the following:

docker build . -t testimg

This will create a container that everytime you run it sleeps. So If I run it as following:

docker run testimg

I'll get the following:

sleep: missing operand
Try 'sleep --help' for more information.

This happens because the entry point is the "sleep" command which needs an argument. So to fix this I'll just provide the amount to sleep:

docker run testimg 5

This will run correctly and as consequence the container will run, sleeps 5 seconds and exits. As we can see in this example docker just appended what goes after the image name to the entry point binary docker run testimg <my_cmd>. What happens if we want to pass a default value (default argument) to the entry point? in this case we just need to specify it in the CMD section, for example:

From ubuntu
ENTRYPOINT ["sleep"]
CMD ["10"]

In this case if the user doesn't pass any argument the container will use the default value (10) and pass it to entry point sleep.

Now let's use just CMD and omit ENTRYPOINT definition:

FROM ubuntu
CMD ["sleep", "5"]

If we rebuild and run this image it will basically sleeps for 5 seconds.

So in summary, you can use ENTRYPOINT in order to make your container acts as an executable. You can use CMD to provide default arguments to your entry point or to run a custom command when starting your container that can be overridden from outside by user.

I would like to differentiate the differences between CMD, RUN & ENTRYPOINT in an effortless manner.

Let’s take an npm init example for node.

CMD :

Let’s assume below is the initial command we added in dockerfile

CMD [ "npm", "init" ]

Now, If I run docker run -t node npm install

It will override the npm init command from the dockerfile.

CMD [ "npm", "init" ] This will become  CMD [ "npm", "install" ]

It will execute the npm install command rather than npm init as it overrides with npm install.

Now, Let’s talk about

ENTRYPOINT :

Let’s assume the same command is added in docker file but with ENTRYPOINT

ENTRYPOINT [ "npm", "init" ]

Now, If I run docker run -t node install

It will append the npm init command with npm install in the dockerfile.

ENTRYPOINT [ "npm", "init" ] This will become  ENTRYPOINT [ "npm", "init", "install" ]

It will execute the both npm init & npm install commands.

To Sum-up :

RUN: This will execute while the image is generating. Used to install any dependencies like node_modules. Ex. RUN npm install

CMD : To use when you want to override the complete command

ENTRYPOINT: To use when you want to append some additional command.

I have read all answers and I want to summarize for better understanding at first glance like following:

Firstly, the whole command that gets executed in the container includes two parts: the command and the arguments

• ENTRYPOINT defines the executable invoked when the container is started (for command)

• CMD specifies the arguments that get passed to the ENTRYPOINT (for arguments)

In the Kubernetes In Action book points an important note about it. (chapter 7)

Although you can use the CMD instruction to specify the command you want to execute when the image is run, the correct way is to do it through the ENTRYPOINT instruction and to only specify the CMD if you want to define the default arguments.

You can also read this article for great explanation in a simple way

Comments on EntryPoint function in code

// ENTRYPOINT /usr/sbin/nginx.

// Set the entrypoint (which defaults to sh -c) to /usr/sbin/nginx.

// Will accept the CMD as the arguments to /usr/sbin/nginx.

Another reference from documents

You can use the exec form of ENTRYPOINT to set fairly stable default commands and arguments and then use CMD to set additional defaults that are more likely to be changed.

Example:

FROM ubuntu:14.04.3
ENTRYPOINT ["/bin/ping"]
CMD ["localhost", "-c", "2"]

Build: sudo docker build -t ent_cmd .

CMD arguments are easy to override.

NO argument (sudo docker -it ent_cmd)                :  ping localhost 
argument    (sudo docker run -it ent_cmd google.com) :  ping google.com

.

To override EntryPoint argument, you need to supply entrypoint
sudo docker run -it --entrypoint="/bin/bash" ent_cmdd

p.s: In presence of EntryPoint, CMD will hold arguments to fed to EntryPoint. In absense of EntryPoint, CMD will be the command which will be run.

CMD:

• CMD ["executable","param1","param2"]: ["executable","param1","param2"] is the first process.
• CMD command param1 param2: /bin/sh -c CMD command param1 param2 is the first process. CMD command param1 param2 is forked from the first process.
• CMD ["param1","param2"]: This form is used to provide default arguments for ENTRYPOINT.

ENTRYPOINT (The following list does not consider the case where CMD and ENTRYPOINT are used together):

• ENTRYPOINT ["executable", "param1", "param2"]: ["executable", "param1", "param2"] is the first process.
• ENTRYPOINT command param1 param2: /bin/sh -c command param1 param2 is the first process. command param1 param2 is forked from the first process.

As creack said, CMD was developed first. Then ENTRYPOINT was developed for more customization. Since they are not designed together, there are some functionality overlaps between CMD and ENTRYPOINT, which often confuse people.

Most people explain it perfectly here, so I won't repeat all the answers. But to get a good feeling I would suggest testing it yourself by looking at the processes in the container.

Create a tiny Dockerfile of the form:

FROM ubuntu:latest
CMD /bin/bash

Build it, run it in with docker run -it theimage and run ps -eo ppid,pid,args in the container. Compare this output to the output you receive from ps when using:

• docker run -it theimage bash
• Rebuilding the image but with ENTRYPOINT /bin/bash and running it in both ways
• Using CMD ["/bin/bash"]
• ...

This way you will easily see the differences between all possible methods for yourself.

The official documentation of Dockerfile best practices does a great job explaining the differences. Dockerfile best practices

CMD:

The CMD instruction should be used to run the software contained by your image, along with any arguments. CMD should almost always be used in the form of CMD ["executable", "param1", "param2"…]. Thus, if the image is for a service, such as Apache and Rails, you would run something like CMD ["apache2","-DFOREGROUND"]. Indeed, this form of the instruction is recommended for any service-based image.

ENTRYPOINT:

The best use for ENTRYPOINT is to set the image’s main command, allowing that image to be run as though it was that command (and then use CMD as the default flags).

CMD command mentioned inside Dockerfile file can be overridden via docker run command while ENTRYPOINT can not be.

From rebuilding an OS image from scratch ( Just writing FROM scratch and copying the minimum file system with COPY in dockerfile) I came to know that,

If you don't specify ENTRYPOINT and CMD in your dockerfile, docker will use

/bin/sh -c

as the default ENTRYPOINT and will take CMD if you define CMD in docker file or pass command-line argument (which will override defined CMD) while running a container.

Suppose you pass an argument (or define CMD in dockerfile) ls then it will be fed to ENTRYPOINT. That is,

/bin/sh -c ls

/bin/sh -c is going to run whatever argument passed to it. You will get the output for "ls" command and the container will then exit.

The ubuntu image doesn't define ENTRYPOINT explicitly, so docker will user /bin/sh -c but contains CMD defined i.e bash.That means when you run the following command to run a container,

docker container run -it ubuntu

Docker actually uses ENTRYPOINT as /bin/sh -c and then feeds it with bash and ultimately what runs is

/bin/sh -c bash

which starts the interactive bash terminal (only if -i flag is specified as above and optionally -t to get native terminal like experience)

when you provide arguments via command-line the bash gets replaced with whatever you pass and output is according to that, i.e

/bin/sh -c passed_argument

You can define custom ENTRYPOINT that will override the default one but then you need to use CMD accordingly.

In case of RUN command in dockerfile, it doesn't consider the defined ENTRYPOINT and CMD but runs the commands specified as they are provided to the interactive bash terminal in the intermediate container

I know there are already many answers, but I did some more digging and wanted to share how exactly docker build handles ENTRYPOINT and CMD.

tl;dr: there's barely any fundamental difference in the two forms.

Step 1: shell to exec/JSON conversion. There are two formats for both keywords: "shell form" and "exec/JSON form." The online docs call it "exec form" while related warning messages from docker build call it "JSON form." I'll use "JSON form" for reasons that will be clear later.

• shell form: ENTRYPOINT "mycommand arg1"
• JSON form: ENTRYPOINT ["mycommand", "arg1"]

The conversion: ENTRYPOINT "foo bar", gets converted to JSON form, ENTRYPOINT ["/bin/sh", "-c", "\"foo bar\""]. Arguments in JSON form are not processed further.

ENTRYPOINT and CMD are converted separately.

Step 2: concatenation. The two resulting JSON lists of strings are concatenated, ENTRYPOINT then CMD.

This produces one big combined exec/JSON form.

Step 3: execution. running the container with docker run and no added command line arguments (which would overwrite CMD) effectively does exec $@ where $@ are the strings from step 2.

Special cases:

If ENTRYPOINT or CMD aren't specified then they are effectively converted to an empty list in step 2.

If both aren't specified then there's no command at all. Running the image without specifying one or both at the command line will raise a "no command specified" error.

How to verify: you can make a simple Dockerfile like this:

FROM scratch

ENTRYPOINT "foo"
CMD "bar"

Next run docker build -t args-test:latest . to build it.

Then you can use docker inspect args-test:latest | less to see what the lists of tokens are for CMD and ENTRYPOINT, recorded as "Cmd" and "Entrypoint" respectively. You'll see that their values in the image are always either null or a JSON list of strings. Hence "JSON form."

Example 1:

ENTRYPOINT ["echo"]
CMD "foo"      # --> ["/bin/sh", "-c", "foo"]

Concatenated JSON form: ["echo", "/bin/sh", "-c", "\"foo\""]

Prints to shell: /bin/sh -c "foo"

Why: ENTRYPOINT is in JSON form already and not modified. CMD is in "exec" form so it converted to JSON form (see step 1). The result runs echo with the tokens produced from the CMD conversion to JSON form.

Example 2:

ENTRYPOINT "echo"     # --> ["/bin/sh", "-c", "echo"]
CMD ["foo"]

Concatenated JSON form: ["/bin/sh", "-c", "echo", "foo"]

Prints to shell: empty line

Why: ENTRYPOINT is in exec form so it gets converted to JSON form ["/bin/sh", "-c", "echo"]. CMD is already in JSON form and is not modified. The resulting command is thus /bin/sh -c echo foo.

The latter is a bit of a shell puzzler. sh -c takes echo to be the command string, sets $0 to foo (and would set $1, $2, etc. to later parameters if there were any), then runs echo with no parameters. That prints the blank line.

The difference in practice: still not a lot, both CMD and ENTRYPOINT can be overridden but in different ways:

• to override CMD: docker run my-image foo bar will overwrite CMD to ["foo", "bar"]
• to override ENTRYPOINT: docker run my-image --entrypoint foo will overwrite ENTRYPOINT to be foo

The other main difference is ENTRYPOINT comes first. So when the image is run, the first token in the JSON form of ENTRYPOINT is the executable. This can matter for signal handling and other edge cases. This is the reason you get warnings from docker build if you use shell form instead of JSON form: to push you toward using the JSON forms to avoid such hard to debug issues.

Finally, from the docker-run docs themselves for --entrypoint:

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.