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

Question

In Dockerfiles there are two commands that look similar to me: CMD and ENTRYPOINT. But I guess that there is a (subtle?) difference between them - otherwise it would not make any sense to have two commands for the very same thing.

The documentation states for CMD-

The main purpose of a CMD is to provide defaults for an executing container.

and for ENTRYPOINT:

An ENTRYPOINT helps you to configure a container that you can run as an executable.

So, what's the difference between those two commands?

Anglomania

^ that! Thanks @slm . Here's another very similar reference that might be a bit more up-to-date: docs.docker.com/reference/builder/#entrypoint – Messer

As confusing as the difference between ADD and COPY – Petie

This link provides difference in between RUN, CMD, and ENTRYPOINT: goinbigdata.com/docker-run-vs-cmd-vs-entrypoint – Artimas

Just note that CMD and ENTRYPOINT both have different forms to be written, exec and shell form. So make yourself a favor and understand the subtle differences in behavior depending on the form being used. Then read docs.docker.com/engine/reference/builder/…. – Anta

I think this phoenixnap.com/kb/docker-cmd-vs-entrypoint explains it very clearly. – Ebsen

This is the best blog I found goinbigdata.com/docker-run-vs-cmd-vs-entrypoint – Intense

Answer 1

Docker has a default entrypoint which is /bin/sh -c but does not have a default command.

When you run docker like this: docker run -i -t ubuntu bash the entrypoint is the default /bin/sh -c, the image is ubuntu and the command is bash.

The command is run via the entrypoint. i.e., the actual thing that gets executed is /bin/sh -c bash. This allowed Docker to implement RUN quickly by relying on the shell's parser.

Later on, people asked to be able to customize this, so ENTRYPOINT and --entrypoint were introduced.

Everything after the image name, ubuntu in the example above, is the command and is passed to the entrypoint. When using the CMD instruction, it is exactly as if you were executing
docker run -i -t ubuntu <cmd>
The parameter of the entrypoint is <cmd>.

You will also get the same result if you instead type this command docker run -i -t ubuntu: a bash shell will start in the container because in the ubuntu Dockerfile a default CMD is specified:
CMD ["bash"].

As everything is passed to the entrypoint, you can have a very nice behavior from your images. @Jiri example is good, it shows how to use an image as a "binary". When using ["/bin/cat"] as entrypoint and then doing docker run img /etc/passwd, you get it, /etc/passwd is the command and is passed to the entrypoint so the end result execution is simply /bin/cat /etc/passwd.

Another example would be to have any cli as entrypoint. For instance, if you have a redis image, instead of running docker run redisimg redis -H something -u toto get key, you can simply have ENTRYPOINT ["redis", "-H", "something", "-u", "toto"] and then run like this for the same result: docker run redisimg get key.

Widthwise

So according to this, if I put this on the top of my Dockerfile: RUN ln -sf /bin/bash /bin/sh && ln -sf /bin/bash /bin/sh.distrib OR I put this at the end of my Dockerfile: ENTRYPOINT ["/bin/bash", "-c"], both of them are doing the exact same thing in my Debian containers: changing /bin/sh to /bin/bash? – Angleaangler

Not at all. ENTRYPOINT sets a metadata that can (but can be overridden) at runtime, so if you don't change anything, after starting your container, the result will be the same, however, RUN will be exectuted at build time and no matter what you do at runtime, it will be here. – Widthwise

By default there's no ENTRYPOINT; whether a shell is used depends on the used form of the CMD command (docs.docker.com/engine/reference/builder/#cmd). – Doughnut

Thanks for this, the historical context helps a lot as I was struggling to remember the seemingly arcane rules about what is overridden and what is appended etc. A useful point for technical documentation writers everywhere: help the reader build a mental model of the system, don't just list facts and scenarios :-) – Crocodilian

This is a fabulous answer. I think Docker documentation should add this under a section called CMD vs ENTRYPOINT. – Facetious

+1 for the ubuntu Dockerfile CMD default. I was wondering why it still works if I don't specify bash as the command. – Drawbridge

does ENTRYPOINT override CMD please? – Penelope

@Webman No. They are two different instructions. If they both exist, CMD would be treated as ENTRYPOINT’s parameters. – Nanji

I just stumbled upon something in review. There is a special software to act as ENTRYPOINT: github.com/Yelp/dumb-init – Cressi

@Facetious I found it in the docs : docs.docker.com/engine/reference/… – Aesir

@SalathielGenèse Apparently you missed the "/builder/" part of the url. Here is the correct link: docs.docker.com/engine/reference/builder/… – Campstool

But really for now CMD and ENTRYPOINT looks like legacy things. Both are editable during docker run, both could be added to Dockerfile before build... After all the same could be done with one CMD and that's it. What the hell is this? hsto.org/web/ca2/564/592/ca25645927e9445c9a70475de1be7afc.png – Turpentine

Note: this currently accepted answer does not seem up-to-date: e.g., the first remark that Docker has a default entrypoint which is "/bin/sh -c" is not accurate (at least not anymore), and it does not refer to official docs; so you may want to have a look to that other answer? – Restitution

You can check the default ENTRYPOINT and CMD values of an image by using docker image inspect image_name command. – Bradfordbradlee

Here's where the docker builder currently decides to prepend the shell to the CMD. This doesn't make use of an entry point – Astraddle

As much as there's a lovely symmetry in this answer having precisely 2222 upvotes, it's that helpful that I'm going to have ruin that symmetry via a +1. – Obstructionist

The key part is: Another example would be to have any cli as entrypoint. For instance, if you have a redis image, instead of running docker run redisimg redis -H something -u toto get key, you can simply have ENTRYPOINT ["redis", "-H", "something", "-u", "toto"] and then run like this for the same result: docker run redisimg get key. – Relapse

Answer 2

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/

Etude

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. is a good to-the-point summary. – Gouty

ENTRYPOINT can also be overridden using --entrypoint flag. for e.g docker run -it --entrypoint bash test – Rheometer

@Jingguo Yao : What if CMD contains a command such as - CMD ["nginx","-g","daemon","off"]? Would it be chained? – Unbraid

@Unbraid CMD is the ENTRYPOINT's default argument, you override it by passing a new arg when running the image. – Delfeena

ENTRYPOINT is often pointed to an entry script (rather than a command) that can do many useful things like: verify requirements before execution (like readyness probes on dependencies); proxy/wrap a command to validate it, or to change the executing user, or to change files' owner (for example when mounting hostPath on Minikube, by default files get overridden with UID/GID 1000:1000), etc.. – Tagalog

This is the most intuitive explanation. – Relapse

This should have been the chosen answer, as it immediately gets right to the point and avoids ambiguous (and poorly worded) language. – Magistracy

Answer 3

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 shows 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  ║
╚════════════════════════════╩═════════════════════════════════════════════════╝

Cresting

What are px_cmd and exec_entry ? What does mean when they are on the same execution line ? They are passed as argument to each other ? Even when the /bin/sh -c is involved ? – Crosshatch

@Crosshatch Both 'px_cmd' and 'exec_entry' are just dummy strings here. You may just notice that /bin/sh -c would be added to CMD as prefix while CMD written in executable syntax(not list syntax). – Nanji

@Rafaf: I didn't get the last point CMD will be overridden when running the container with alternative arguments. Let's say I have CMD at end of my image at my image as CMD "mvn clean test". How it ll be overridden. Thanks – Kiefer

@Kiefer If the user specifies arguments to docker run then they will override the default specified in CMD. – Thesaurus

ENTRYPOINT exec_entry p1_ent was wrongly explained. The shell form prevents any CMD or run command line arguments from being used - docs.docker.com/engine/reference/builder/#entrypoint – Truditrudie

@MariuszMiesiak it's now updated. Thanks for your feedback. – Cresting

BTW: this answer definitely should be the accepted answer! (while the current one claims that "Docker has a default entrypoint which is /bin/sh -c"…) – Restitution

Struggling to see the need for the two middle rows in each of the tables being duplicated. Is it just that the dummy commands differ or am I missing some actual info that gets introduced by this middle-row duplication? – Deadfall

@muthuh, It is used to distinguish when a CMD instruction (both cases in exec form) comes with or without a command inside the parameter list. In the latter case, all parameters in the parameter list (from the CMD instruction in exec form) behave as command options or command arguments since there is no command and the idea is to expect the command to arrive from an ENTRYPOINT instruction, preferably in exec form. In the former case, could (🤷) raise an error so better to use the CMD instruction in a shell form to take advantage of /bin/sh -c .... – Woodsman

Answer 4

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

Guzzle

@Blauhirn In your case, you must add arguments to CMD in list syntax, and make sure the entrypoint you sepcified could parse your arguments in CMD. Usually, I add a '-h' argument to entrypoint. Then I may execute docker run image_name -h to show some help information of this image. – Nanji

Answer 5

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/

Leap

That's a great link! – Whomp

entrypoint can be overwritten from command line using --entrypoint – Plaza

Answer 6

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.

Kampmeier

What does it mean "by intuition"? – Karly

Answer 7

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}

Veinstone

Here is a link to the tutorial: youtu.be/OYbEWUbmk90. It might be usefull to future users. – Colligate

Thank you! This explanation with the example was much clearer to me (a beginner to docker) than the accepted answer. – Insusceptible

I think this answer is the best. It's so much more clear to me as noob in Docker than the rest of the answers. – Motive

best explanation I was able to find in a web. Thanks a lot! – Selfpossession

Answer 8

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

Phox

"default commands and/or parameters for a container" You lost me here. What does default command mean for a container? – Hemato

@MehdiCharife, The default command for a Docker container refers to the command that is executed when the container is run. This command is specified in the Dockerfile using the CMD instruction. For example, if you have a Dockerfile with CMD ["echo", "Hello Docker"], when you run the Docker container without specifying a command, it will execute echo "Hello Docker". But if you run the Docker container and provide a command like sudo docker run <image-id> hostname , it will override the default command and execute hostname instead. – Phox

Answer 9

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':

Anisomerous

Answer 10

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.

Varuna

Answer 11

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.

Lycanthropy

Answer 12

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.

Rancid

Answer 13

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

Psychodrama

Answer 14

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.

Gouty

Answer 15

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.

Fishmonger

Answer 16

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).

Maui

Answer 17

• A Dockerfile should specify at least one CMD or ENTRYPOINT instruction

• Only the last CMD and ENTRYPOINT in a Dockerfile will be used

• ENTRYPOINT should be defined when using the container as an executable

• You should use the CMD instruction as a way of defining default arguments for the command defined as ENTRYPOINT or for executing an ad-hoc command in a container

• CMD will be overridden when running the container with alternative arguments

• ENTRYPOINT sets the concrete default application that is used every time a container is created using the image

• If you couple ENTRYPOINT with CMD, you can remove an executable from CMD and just leave its arguments which will be passed to 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)

Prospectus

Answer 18

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

Donetta

docker run --help command says otherwise: --entrypoint string Overwrite the default ENTRYPOINT of the image – Breechblock

Answer 19

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

Village

Answer 20

In a Dockerfile, both CMD and ENTRYPOINT are used to define what command should be run when a container is started. However, they have different purposes and behaviors:

1. CMD:
   • CMD is used to provide default arguments for the entry point command. It is typically used to specify the main command that will be executed when the container starts.
   • You can override CMD by passing command-line arguments when starting a container.
   • If a Dockerfile has multiple CMD instructions, only the last one will take effect.
   • If the CMD command is missing, the Docker image may not be runnable by itself.

Example:

FROM ubuntu
CMD ["echo", "Hello, World"]

In this example, the default command for the container is set to echo "Hello, World". You can override this command when running the container if needed.

2. ENTRYPOINT:
   • ENTRYPOINT is used to specify the main command that will run when the container starts, and it does not allow for easy override with command-line arguments.
   • Any additional arguments passed to the docker run command will be appended to the ENTRYPOINT command, not replace it.
   • ENTRYPOINT is often used for defining the primary executable for the container, such as a specific application or service.

Example:

FROM ubuntu
ENTRYPOINT ["echo", "Hello, World"]

In this example, the container's primary command is set to echo "Hello, World". If you run the container with additional arguments like this:

docker run my-container "Goodbye, World"

It will execute: echo "Hello, World" "Goodbye, World".

Carven