fir3net
PPS-Firenetbanner-780.5x190-30-03-17

What is the Difference Between Docker CMD and ENTRYPOINT ?

Contents[Hide]

Within the world of Docker, CMD and ENTRYPOINT are often the cause of confusion. But why, you may ask? This is because both CMD and ENTRYPOINT are used to execute commands at container run time.
But do not fear, my fellow Fir3net reader, in this article we will look at the how the 2 differ and when they should be used. 

CMD

CMD allows you to define a command that is executed at run time ; The command defined by CMD is executed via sh -c.  Here is CMD in action,

Dockerfile

First of all lets build the Dockerfile, with our CMD instruction defined. Within our Dockerfile we instruct our container to send 2 ICMP ping requests to 4.2.2.2.

FROM busybox
CMD ["ping", "-c", "2", "4.2.2.2"]

Build

We quickly build the container,

docker build -t cmd-example .

Run

We run the container. As expected, based on our Dockerfile, 2 pings are sent to 4.2.2.2.

root@server tmp]# docker run --restart=always -i -t cmd-example
PING 4.2.2.2 (4.2.2.2): 56 data bytes
64 bytes from 4.2.2.2: seq=0 ttl=54 time=6.163 ms
64 bytes from 4.2.2.2: seq=1 ttl=54 time=6.044 ms

--- 4.2.2.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 6.044/6.103/6.163 ms

 Additionally we can also see sh -c executing the ping command via the output of docker ps at the point we run our container,

CONTAINER ID        IMAGE                           COMMAND                   
06ae12e77ac9        cmd-example                     "/bin/sh -c '\"ping\" \""

Overriding

To override CMD, append the command to the end of your docker run line, like so,

[root@server tmp]# docker run --restart=always -i -t cmd-example /bin/date
Fri Sep 16 11:38:09 UTC 2016

Note: CMD differs from RUN, as CMD executes at run time, whereas RUN runs at build time.

Entrypoint

ENTRYPOINT provides you with the ability to use a container as if it was an executable. In other words ENTRYPOINT allows you to define the executing program (sh -c in the case of CMD). Arguments can then be passed in using CMD (or docker run).

Dockerfile

Within the Dockerfile, we instruct ping to execute at run time. We then pass in the arguments via CMD. In this case we pass the arguments to ping 8.8.8.8 twice.

FROM busybox
ENTRYPOINT ["/bin/ping"]
CMD ["8.8.8.8", "-c", "2"]

Build

A quick build of the container....

docker build -t entrypoint-example .

Run

Here is where things differ with ENTRYPOINT. If we run the container as normal we get the expected results,

[root@server tmp]# docker run --restart=always -i -t entrypoint-example
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=4.671 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=4.465 ms

--- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 4.294/4.425/4.671 ms

We can now pass in alternative argument. This in essence overrides the arguments set via CMD. Like so,

[root@server tmp]# docker run --restart=always -i -t entrypoint-example 4.2.2.2 -c 2
PING 4.2.2.2 (4.2.2.2): 56 data bytes
64 bytes from 4.2.2.2: seq=0 ttl=54 time=6.239 ms
64 bytes from 4.2.2.2: seq=1 ttl=54 time=5.874 ms

--- 4.2.2.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 5.874/6.056/6.239 ms

When running the container, we can see via docker ps that instead of sh -c being used (in the case of CMD) the command defined by ENTRYPOINT is used for execution.

CONTAINER ID        IMAGE                           COMMAND                   
fdae5c6d9c6e        entrypoint-example              "/bin/ping 8.8.8.8 -c"

Overriding

Much like CMD you can override the argument set in the Dockerfile. In this case the --entrypoint switch is used,

[root@server tmp]# docker run --restart=always -i -t --entrypoint=/bin/date entrypoint-example
Fri Sep 16 11:41:21 UTC 2016

Tags: Linux, Docker, CMD

About the Author

RDonato

R Donato

Rick Donato is the Founder and Chief Editor of Fir3net.com. He currently works as a Principal Network Security Engineer and has a keen interest in automation and the cloud.

You can find Rick on Twitter @f3lix001