What Does Docker Entrypoint Do?

Dockerfiles are a critical part of working with containers; they allow us to create images from a Dockerfile and customize them to fit our usage needs because Dockerfiles work by using directives and parameters for configurations.

One of the common directives in a Dockerfile is the ENTRYPOINT directive. This directive specifies executable that runs during container creation from the Dockerfile image.

This guide looks at how the ENTRYPOINT directive in Docker works and how to use it in Dockerfiles.

Basic Usage

The ENTRYPOINT directive in a Dockerfile takes two forms, exec form and shell form. Having an ENTRYPOINT directive in the Dockerfile prevents the container from starting and stopping automatically.

The general syntax for the ENTRYPOINT directive is:

Exec form:

The exec represents the executable to run; the options are the parameters to run to the executable.

The other form of the ENTERYPOINT directive is the shell form. The shell form runs as a subcommand from /bin/sh -c [command]. The general syntax for this form is as:

Similarly, the command is a shell executable, while the options represent the parameters to pass to the command.

How ENTRYPOINT Works

In a nutshell, the ENTRYPOINT directive in a Dockerfile allows the containers created from the image to run an executable after creation. Unfortunately, the two forms of the ENTRYPOINT directive tends to behave differently:

The shell form of the ENTRYPOINT directive does not support command arguments when starting the container. Furthermore, unlike exec form that runs the executable in the background, shell form runs as a sub of /bin/sh -c launching the process with a different PID value than the container process.

On the other hand, the exec form supports arguments during container creation. This means the command is run after the executable that is set in the ENTRYPOINT. So, for example, if you add an option to the docker run command, it runs in the background after the executable set in the ENTRYPOINT. In addition, Docker allows you to override the ENTRYPOINT value by using the –entrypoint option during container creation.

Example 1: Exec Form

Let us illustrate how the exec form works. In this example, we use an nginx image as the test case.

A sample Dockerfile contains the entries as:

Let us build the image from the Docker file as:

With the image, let us create a container and launch a shell into the container.

Inside the container shell, let us perform basic commands and install a few packages.

If you run htop inside the container, you will get an output similar to the one shown below:

If you ignore all the nginx worker processes and htop, you notice the main nginx daemon is running as PID of 1.

Example 2: Shell Form

If you change the Dockerfile to look as shown in the entries below:

Build the image and create a container.

Inside the container, if we run the htop command, we see the nginx worker process is running under /bin/sh -c as:

You can also get a similar output by examing the container using the docker inspect command as:

Quick Recap

It is good not to confuse the docker ENTRYPOINT and the docker CMD directives. Although both directives define the commands to docker executes during container runtime:

Ensure to use Dockerfile ENTRYPOINT directive when running the container as an executable.

Use CMD to define default arguments for ENTRYPOINT or for running ad-hoc commands in the container.

NOTE: CMD arguments will be overridden when running the container with other arguments.

As stated earlier, any Dockerfile should include either CMD or ENTRYPOINT directive.

In Conclusion.

In conclusion, Docker ENTRYPOINT is a much suitable choice when defining executable for the containers. To learn more, check the documentation.