Docker ENTRYPOINT vs CMD: Understanding the Differences

Introduction: Docker ENTRYPOINT vs CMD

Applications can be run and managed inside containers with the help of the Docker platform. An application has to have its Docker image created using Docker files before it can be used within a container. 

A Docker file is a text file with instructions that Docker follows to build the Docker image. A directive and an argument make up each instruction. Two of these directives are ENTRYPOINT and CMD.

Docker has completely changed how we create, run, and maintain applications. Thanks to its containerization technology, developers may package apps with all their dependencies, which ensures consistency across different environments. 

What runs within a Docker container is determined by two fundamental Dockerfile instructions: ENTRYPOINT and CMD. It’s essential to comprehend the differences if you want to maximize your Docker workflows.

At ARZ Host, we’ll explore the specifics of Docker ENTRYPOINT vs CMD in this post, outlining their functions, differences, and ideal applications. By the time you’re done, you’ll know exactly how to apply these guidelines to your Docker projects.

Come on, let’s get going!

What is CMD in a Dockerfile?

When running a container based on an image, the CMD instruction in a Dockerfile indicates the default command to be performed.

Let’s dive into an example to examine what CMD does inside a Dockerfile in more detail.

Open your code editor and make a directory called docker-demo to follow along. Make a Dockerfile file inside this directory. The file must be named Dockerfile, but you are free to give the directory any name you like.

The following code should then be copied and pasted into the Dockerfile.

There are two instructions in this Dockerfile. Every instruction is made up of an argument and a directive. Keep in mind that writing the directives in uppercase helps to make them stand out from the arguments.

The two directives we have in the current situation are FROM and CMD. The parent picture, named Alpine, upon which our custom image will be constructed, comes after the FROM directive. Docker Hub, a cloud-based storage repository for Docker images, will be the source of the parent image download.

The default command ([“echo”, “Hello World!”]) provided by the CMD directive is the next thing we need to discuss. This command will be used when a container is constructed from the custom Docker image, which we haven’t yet produced.

The parameter to CMD in our example is [“echo”, “Hello World!”]. Hello World! is the argument supplied to the executable, and echo is the initial string that symbolizes the executable. The command [“echo”, “Hello World!”] will be utilized when we run a container from the custom Docker image, and the message “Hello World!” will appear in the terminal.

First, we must create an image, which we must then execute as a container to see the CMD directive in action. To create a custom Docker image called custom-image: v1, run the following command while in the docker-demo directory.

• Docker build -t custom-image: v1

Remember to use dot (.) following the build command. It suggests using “docker-demo” as the current directory as the build context.

Let’s now list the images in our system to confirm that the image was created. Execute the subsequent command:

• Docker image catalog

Our custom image, custom-image: v1, is listed, as you can see. Now let’s use the following command to launch this Docker image as a container:

• docker run custom-image: v1 in a container

The Hello World! a message appeared in the console when we ran the Docker image named custom-image: v1 as a container and performed the command given by the CMD directive ([“echo”, “Hello World!”]).

The CMD directive’s ability to alter the default command when executing the container is an important aspect to keep in mind. Let’s use the following command to illustrate this:

• run custom-image: v1 echo in a docker container Greetings, ARZ Host!

Upon executing this command, Hello ARZ Host will appear!

The default argument (“Hello World!”) listed in the Dockerfile was superseded by the parameter echo Hello ARZ Host! that we gave in the command line.

It’s essentially a way to define the application or process the container should start by default.

Here are some key points about CMD:

• Default behavior: The container runs the CMD process if you don’t provide any arguments when starting the container with docker run.
• Override-able: You can override the CMD instruction by specifying your own command when running the container using docker run <image_name> <your_command>.
• Multiple CMD instructions: If you have multiple CMD instructions in your Dockerfile, only the last one is considered.

Now that you are well-versed in the CMD directive’s operation, let’s examine the ENTRYPOINT directive’s differences from CMD. Having problems with cmd? Is it not recognizing the pip command? See our article on PIP Not Recognized in CMD to fix it.

What is ENTRYPOINT in a Dockerfile?

The ENTRYPOINT instruction in a Dockerfile effectively defines the main purpose of the container by specifying the executable or command that is executed by default when a container starts up based on that image.

Change the following code inside the Dockerfile:

• FROM alpine
• ENTRYPOINT [“Hello world!”, “echo”]

As you can see, we have merely changed ENTRYPOINT in place of CMD in the Dockerfile.

Next, run the following command to create a custom Docker image called custom-image: v2:

• build using docker -t custom-image: v2

Let’s now list the images in our system to confirm that the image was created. Execute the subsequent command:

• list of Docker images

Our custom image, custom-image: v2, is listed, as you can see. Now let’s use the following command to launch this Docker image as a container:

• docker run custom-image: v2 in a container

The console will display the message “Hello World!” in print.

This is the same outcome that we got via the CMD directive. What differentiates them from one another, then?

We are unable to change the ENTRYPOINT directive’s default command, in contrast to the CMD directive. Let’s put this into practice by running the subsequent command:

• run custom-image: v2 echo in a docker container ARZ Host, hello!

Upon executing the earlier command, an output will be displayed.

As you can see, the Dockerfile’s default argument (“Hello World!”) is attached to the argument (“echo Hello ARZ Host!”) that we gave in the command line. It is not a substitute for the default parameter.

At this point, you have to be fully aware of how the ENTRYPOINT directive works inside of a Dockerfile.

Thus far, we have utilized the Dockerfile’s CMD and ENTRYPOINT directives separately. They can, however, also be utilized in tandem. In the following section, let’s examine how.

Here’s a breakdown of what ENTRYPOINT does:

• Sets the default command: When you run a container from the image, the ENTRYPOINT command executes by default. This establishes the container’s core functionality, like running a web server or database.
• Executable or script: ENTRYPOINT can point to an executable file path or a shell script containing the commands to be executed.
• Arguments vs. override: Unlike CMD (another Dockerfile instruction), arguments provided during container startup with docker run are appended to the ENTRYPOINT command, not used to override it.

Here’s when to use ENTRYPOINT:

• Consistent execution: If your container has a specific task that always needs to run, ENTRYPOINT is ideal for ensuring it executes every time the container starts.
• Default behavior: Use ENTRYPOINT to set the container’s default behavior, allowing for customization through arguments during runtime.

In essence, ENTRYPOINT provides a way to define the core functionality of your Docker container and control how it behaves by default.

How to Use CMD & ENTRYPOINT Together?

In Docker, CMD and ENTRYPOINT are instructions used in a Dockerfile to specify what command should be run within a container. While they both define the runtime behavior of the container, they have different purposes and can be used together to create more flexible and powerful configurations.

CMD Instruction

• Purpose: To provide default arguments for the ENTRYPOINT instruction or to specify a command to run if ENTRYPOINT is not specified.
• Syntax:
  • Shell form: CMD command param1 param2
  • Exec form: CMD [“executable”, “param1”, “param2”]
  • Parameter form: CMD [“param1”, “param2”]

ENTRYPOINT Instruction

• Purpose: To set the container’s main command that will always be executed.
• Syntax:
  • Shell form: ENTRYPOINT command param1 param2
  • Exec form: ENTRYPOINT [“executable”, “param1”, “param2”]

Using CMD and ENTRYPOINT Together

When both ENTRYPOINT and CMD are used together in a Dockerfile, CMD provides default arguments to the ENTRYPOINT. If you only define ENTRYPOINT, you cannot override it when starting the container, but you can override the CMD arguments.

Example Usage

Let’s look at a practical example where both instructions are used.

Dockerfile:

• FROM ubuntu:20.04
• # Set the main command to be executed when the container starts
• ENTRYPOINT [“echo”]
• # Set the default parameter for the ENTRYPOINT
• CMD [“Hello, world!”]

Explanation:

• ENTRYPOINT [“echo”] sets the main command to echo.
• CMD [“Hello, world!”] provides the default argument to the ENTRYPOINT.

When you build and run this container, it will output “Hello, world!” by default:

• docker build -t my-echo.
• docker run my-echo
• # Output: Hello, world!

However, you can override the CMD arguments when running the container:

• docker run my-echo “Hello from Docker!”
• # Output: Hello from Docker!
• In this case, docker run my-echo “Hello from Docker!” overrides the default “Hello, world!” argument with “Hello from Docker!”.

Advanced Example

You can use ENTRYPOINT and CMD together for more complex use cases, such as running a script with default parameters.

Dockerfile:

• FROM python:3.9-slim
• # Add a script to the container
• COPY script.py /usr/local/bin/script.py
• # Set the main command to run the script
• ENTRYPOINT [“python”, “/usr/local/bin/script.py”]
• # Provide default parameters for the script
• CMD [“–help”]

Script.py:

• import sys
• if __name__ == “__main__”:
• print (f”Script received arguments: {sys.argv[1:]}”)

Explanation:

• ENTRYPOINT [“python”, “/usr/local/bin/script.py”] ensures the script is always run with Python.
• CMD [“–help”] provides a default argument for the script.

When you build and run this container, it will execute the script with the –help argument:

• docker build -t my-script.
• docker run my-script
• # Output: Script received arguments: [‘–help’]

You can override the default argument by providing a different one:

• docker run my-script –version
• # Output: Script received arguments: [‘–version’]

The advantages of combining the CMD and ENTRYPOINT directives in the same Dockerfile are as follows: it’s helpful to give users the option to supply command-line arguments in addition to a default command to be executed, allowing them to obtain the wanted custom output.

The default command specified by the ENTRYPOINT directive in the Dockerfile above cannot be overridden; however, the arguments specified by the CMD directive can be overridden. For example, we can override the text World! by passing another argument from the command line, which will then be appended to Hello.

Best Practices

1. Use ENTRYPOINT for the main command: If you want to ensure a specific command is always run, use ENTRYPOINT.
2. Use CMD for default arguments: Use CMD to define default arguments that can be overridden when the container runs.
3. Exec form over Shell form: Prefer the exec form ([“executable”, “param1”, “param2”]) for both ENTRYPOINT and CMD because it is more predictable and avoids issues with signal handling and command parsing.
4. Combine wisely: Use both together to create flexible containers that have a specific command but allow for argument overrides.

By understanding and correctly combining CMD and ENTRYPOINT, you can create Docker containers that are both powerful and flexible, providing sensible defaults while allowing for custom behavior when needed.

What’s the Difference Between CMD & ENTRYPOINT?

The goal of both ENTRYPOINT and CMD directives is the same. When a Docker image is used as a container, it offers default commands that should be run. However, there are differences in the way their arguments function.

The primary difference is that while the argument supplied to the CMD directive can be overridden, the argument passed to the ENTRYPOINT directive cannot. This implies that when executing the container, the ENTRYPOINT directive provides a preset command that cannot be changed, while the CMD directive gives you flexibility in choosing other inputs.

The decision between ENTRYPOINT and CMD is based on your unique needs. It is customary to combine the two commands, nevertheless. The CMD directive is used to send default parameters to the ENTRYPOINT directive, while the ENTRYPOINT directive defines the default command.

The following table provides an overview of the differences between CMD and ENTRYPOINT:

Features	CMD	ENTRYPOINT
Provide default commands to be executed when the Docker image is run as a container	Yes	Yes
Arguments can be overridden by the user	Yes	No
Purpose	Defines the default command to execute when a container starts.	Defines the executable process to run when a container starts.
Overridable	Yes, can be overridden by arguments passed to docker run.	No, arguments passed to docker run are treated as arguments to the ENTRYPOINT process.
Use Case	Suitable for providing default arguments that can be customized by users.	Ideal for specifying the core functionality of the container that should always run.
Format	CMD [“executable”, “argument1”, “argument2”] (shell form)	CMD command argument1 argument2 (exec form) <br> ENTRYPOINT [“executable”, “argument1”, “argument2”] (shell form) <br> ENTRYPOINT command argument1 argument2 (exec form)

Because of the ENTRYPOINT instruction, the container will always execute the default shell, /bin/bash. To run a script (source /app/startup.sh) and maintain the container running (tail -f /dev/null), the CMD offers default options (-c). When executing the container, users can still use their commands to override these settings.

Conclusion: Docker ENTRYPOINT Vs CMD

We discovered the function of the ENTRYPOINT and CMD directives inside a Dockerfile by reading this blog post. We also comprehended the differences in their functions and the appropriate times to select each. At this point, you ought to feel comfortable using these directives in your Dockerfile when creating Docker images.

Understanding the nuances between ENTRYPOINT and CMD is vital for effective Dockerfile creation and container management. By appropriately leveraging these instructions, you can create flexible, reliable, and predictable Docker images. 

Use CMD to provide default commands and ENTRYPOINT to enforce mandatory execution, combining them when needed to achieve the desired balance between configurability and control.

Do you want to know more about Docker? Comment Below. Do you want to read More articles like this? Subscribe to our Blog.

FAQS (Frequently Asked Questions)

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

ENTRYPOINT and CMD both specify commands that should be run within a Docker container. The primary difference lies in their intended use and behavior:

• CMD: This instruction provides defaults for an executing container. It can include an executable or just parameters to ENTRYPOINT. If you specify a command when running the container (e.g., docker run myimage mycommand), that command will override the CMD instruction.
• ENTRYPOINT: This instruction sets up the container to run as if it were a specific executable. It is often used to ensure that a container runs a particular script or application, regardless of any command line arguments passed during container startup. ENTRYPOINT can be overridden, but it requires the –entry point flag when running the container.

2: Can you combine ENTRYPOINT and CMD in a Dockerfile? How do they work together?

Yes, ENTRYPOINT and CMD can be combined in a Dockerfile, and they often work together to provide flexible command execution:

When combined, ENTRYPOINT specifies the executable, and CMD provides the default arguments to that executable. For example:

• ENTRYPOINT [“python”, “app.py”]
• CMD [“–help”]

In this configuration, running the container without arguments (docker run myimage) will execute python app.py –help. However, you can override the CMD by providing additional arguments (docker run myimage –version), which would execute the python app.py –version.

3: How do you override ENTRYPOINT and CMD when running a Docker container?

You can override ENTRYPOINT and CMD in the following ways:

CMD Override: You can override the CMD instruction by specifying a command at the end of the docker run command. For example:

• docker run myimage echo “Hello World”
• This will replace the CMD specified in the Dockerfile.

ENTRYPOINT Override: To override the ENTRYPOINT, you use the –entrypoint flag:

• docker run –entrypoint /bin/bash myimage

This command will run /bin/bash instead of the ENTRYPOINT specified in the Dockerfile. Any additional arguments can follow to override CMD.

4: In what scenarios should you prefer ENTRYPOINT over CMD?

You should prefer ENTRYPOINT over CMD in the following scenarios:

• Fixed Application Execution: When you want the container to always run a specific application or script. ENTRYPOINT ensures that the container behaves like a single executable unit. For example, a container designed to run a web server like Nginx or Apache should have an ENTRYPOINT to ensure the server starts.
• Ensuring Mandatory Commands: When you need to ensure that certain commands are always executed regardless of user input. ENTRYPOINT can enforce that these commands are run.
• Combining with CMD for Arguments: When you need to provide flexibility with default arguments but still ensure a specific command is executed, combining ENTRYPOINT and CMD can be very effective.

5: What are the syntax forms of ENTRYPOINT and CMD in a Dockerfile, and which should you use?

Both ENTRYPOINT and CMD have two syntax forms: exec form and shell form. The exec form is generally preferred for clarity and robustness.

Exec Form: This form is an array that runs the command directly, without invoking a shell. It is preferred because it avoids issues with shell parsing and signal handling.

• ENTRYPOINT [“executable”, “param1”, “param2”]
• CMD [“param3”, “param4”]

Shell Form: This form is a single string that gets executed in a shell (/bin/sh -c). It is useful for complex commands but can introduce shell-specific behavior and signal-handling issues.

• ENTRYPOINT executable param1 param2
• CMD param3 param4

Using the exec form is recommended for most cases to ensure that the command and its arguments are passed correctly and to avoid potential issues with shell command processing and signal handling.

Latest Posts:

• Sending Email with a Dedicated Server: Step-by-Step Guide
• When Should I Invest in a Dedicated Server? 5 Signs Your Website Needs
• What is Memcached, and How Does It Boost Website Performance?
• How to Send Mass Emails on a Dedicated Server: A Complete Guide
• How can we use a Dedicated Server for Email Marketing?