Dockerfile - ENTRYPOINT

A Dockerfile is a script file that is defined with a set of instructions on how to build a Docker image. It is used for defining the environment and configuration for an application, specifying the base image, dependencies, and commands needed to set up the application. It helps in automating the creation of customDocker images, for the applications. Dockerfile provides consistency and reproducibility across different environments.

So you can say Dockerfile is a blueprint for building Docker images. It consists of instructions that tell Docker how to build an image. One such instruction is 'ENTRYPOINT'. It specifies the command that will always run when a new container is started. In this article, we will look at the ENTRYPOINT instruction in detail.

The ENTRPOINT specifies the command that will always be executed when a container starts. It has two possible forms of execution:

1. Exec Form

The exec form specifies what executable will be run along with its parameters. The executable is executed directly. This is the recommended form for the ENTRYPOINT command.

ENTRYPOINT ["executable", "parameter1", "parameter2"]

2. Shell Form

The shell form specifies the command to be run from a shell. Yes, these commands are executed through a shell, just like you execute a command in your terminal.

ENTRYPOINT command param1 param2

ENTRYPOINT can never be overridden, unlike CMD. The command in the CMD instruction is overridden when you add another command when running the docker container from the CLI. In the case of ENTRYPOINT, the commands in the docker CLI are appended as parameters to the ENTRYPOINT command. Let's see this in action:

Create a file named 'Dockerfile' and add these instructions.

FROM ubuntu ENTRYPOINT ["echo", "Docker"]

Now, open a terminal in the same directory and enter this command to build the image.

docker build -t my-container .

Output

Run the container with executing the following command:

docker run --rm --name c1 my-container

--rm removes the container as soon as it executes the command. --name is used to name the container. When you run the above command, Docker runs a container from the my-container image named c1 and removes it as soon as the command mentioned in ENTRYPOINT (echo in our case) exits.

Output

Now run the container with some additional argument in the docker run command.

docker run --rm --name c1 my-container is awesome

Output

The extra arguments are appended to the ENTRYPOINT command. If it was CMD instead of ENTRYPOINT the command in CMD would be overridden by the command in docker run.

If you add the CMD instruction to the Dockerfile, it gets appended to the ENTRYPOINT command (if no additional arguments are passed to the docker CLI). Update the Dockerfile:

FROM ubuntu ENTRYPOINT ["echo", "Docker"]CMD ["is", "cool"]

Build the container again:

docker build -t my-container

And run it without any additional arguments

docker run --rm --name c1 my-container

Output

So far we have worked with the exec form of ENTRYPOINT that executes the command binary directly. In exec form there is no environment variable processing as it is not executed through a shell. So when you try to use environment variables in commands ($PWD for example). Change the command in the Docker file:

FROM ubuntu ENTRYPOINT ["echo", "$PWD"]

Now build and run the image again.

docker build -t my-container .docker run --rm --name c1 my-container

Output

See, the environment variable username does not gets replaced as the echo command was not executed from the shell.

Update the ENTRYPOINT to run it in shell form. When you use the shell form, ENTRYPOINT executes the command in /bin/sh -c. So the full command would be /bin/sh -c echo $PWD.

FROM ubuntu ENTRYPOINT echo $PWD

Now build and run the image again.

docker build -t my-container .docker run --rm --name c1 my-container

Output

The environment variable gets processed and the value of PWD is logged to the terminal instead of "$PWD". Now, if you are confused as to what values get appended to ENTRYPOINT and when, you can just refer to this table.

ENTRYPOINT vs CMD

The following are the difference between ENTRYPOINT and CMD:

ENTRYPOINT vs RUN in Docker

The following are the difference between ENTRYPOINT and RUN in Docker:

Use of Entrypoint in Dockerfile

The following are the some of the reasons and insights to uses docker ENTRYPOINT in Dockerfile or Docker Compose:

• Use ENTRYPOINT to define the main executable or script that should run when the container starts.
• Ensures consistency in container behavior across different environments.
• Allows for easy configuration and flexibility using CMD to provide default arguments.
• Example: ENTRYPOINT ["python", "app.py"] ensures python app.py runs by default, with CMD allowing overrides like docker run myapp --debug.

Best Practices for using Entrypoint

Here’s a simple guide to using ENTRYPOINT in Docker the right way:

• Stick to the Exec Form: Use the exec form (ENTRYPOINT ["python", "app.py"]) instead of the shell form. It’s more reliable because it handles signals correctly, allowing the container to shut down properly.
• Pair ENTRYPOINT with CMD for Flexibility: Set your main command with ENTRYPOINT and use CMD to set default arguments. This way, you can change the arguments without altering the main command. For example:

ENTRYPOINT ["python"]
CMD ["app.py"]

This allows you to override app.py with another script when running the container.

• Avoid Overriding ENTRYPOINT Too Often: Don’t override ENTRYPOINT with the --entrypoint flag unless you have to. It can lead to confusion and unexpected behavior. If you need to change something, adjust CMD instead.

Common Mistakes: Debugging with Entrypoint

When you need to debug a Docker container, it's best not to modify the 'ENTRYPOINT' directly in the Dockerfile. Instead, use the '--entrypoint' flag when running the container to temporarily change it. Let’s break down why this approach is better.

Why Not Change Entrypoint in the Dockerfile?

• Disrupts the original setup: Changing the 'ENTRYPOINT' in the Dockerfile can interfere with the container’s intended behavior. Containers are typically set up to run a specific command, and modifying this could cause unexpected issues. The whole purpose of the container is to run the application or service as designed, and altering that command can lead to confusion or failures.
• Takes extra time: Every time you modify the 'ENTRYPOINT', you’ll need to rebuild the Docker image. This is an extra step that makes your debugging process more time-consuming. Instead of quickly testing something, you’ll be waiting for the image to rebuild each time you make a change, which slows you down.
• Not efficient: Constantly updating the Dockerfile and rebuilding the image just to test a small change is not an efficient way to debug. It creates unnecessary work when all you really need is a quick way to try out different commands or setups. Fortunately, there’s a simpler way to achieve this: using the '--entrypoint' flag when you run the container.

By using the '--entrypoint' flag, you can temporarily override the 'ENTRYPOINT' without having to rebuild the Docker image. This allows you to quickly test different commands and troubleshoot issues while keeping the Dockerfile intact.

A better way: Use the --entrypoint flag

Instead of changing the ENTRYPOINT in the Dockerfile, you can override it at runtime using the --entrypoint flag. This lets you test different commands or setups without affecting the original Dockerfile.

For example:

docker run --entrypoint "/bin/bash" my-container

This command tells Docker to run /bin/bash instead of the usual entry point. This allows you to open a shell inside the container to explore, run commands, and troubleshoot without modifying the Dockerfile.

Why this is better?

• No Need for Rebuilds: You don’t have to rebuild your image every time you want to try something new.
• More flexibility: You can run different commands or set up the container in different ways, all while keeping the Dockerfile unchanged.
• Keeps things clean: You don't have to keep changing the Dockerfile for testing, so your setup stays clean and consistent.

Example:

Let’s say your container normally starts a Flask app like this:

ENTRYPOINT ["python", "app.py"]

If you want to debug it, instead of changing the Dockerfile, you can run:

docker run --entrypoint "/bin/bash" my-flask-container

This will open a shell inside the container, letting you inspect files, check logs, and manually test commands. Once you're done debugging, you can exit the shell, and the container will stop as usual.

By using the --entrypoint flag, you can easily change the entry command for debugging purposes without needing to touch the Dockerfile.

Docker Entrypoint Log

In Docker, the ENTRYPOINT command sets up the main process or command that the container will always run. This command can be a script, an application, or any executable that acts as the heart of the container’s function. As the container runs, any output from the ENTRYPOINT command is collected as logs. These logs are important because they give insight into what’s happening inside the container—whether it’s successfully running, throwing errors, or reporting status updates.

Docker makes it easy to access these logs. Using the docker logs command, you can view the ongoing output from the ENTRYPOINT command. This makes it simpler to monitor, troubleshoot, and debug the container's main process, as you can immediately see messages or errors that might point to an issue.

Example: Viewing docker Entrypoint Logs

Let’s say we’re running a simple Python application in a Docker container. This application logs a message every few seconds, which we can then view using Docker logs.

First, create a Python file called app.py

# app.py
import time

while True:
    print("The application is up and running...")
    time.sleep(5)

Next, create a dockerfile to set up the container and use entrypoint to run this application

# Dockerfile
FROM python:3.9-slim

# Copy app.py into the container
COPY app.py /app.py

# Set ENTRYPOINT to run app.py when the container starts
ENTRYPOINT ["python", "/app.py"]

Build the Docker image and start the container

docker build -t entrypoint-example .
docker run --name demo-container entrypoint-example

Now, in a separate terminal, you can view the logs using:

docker logs demo-container

You should see output like this:

These log messages indicate that the container is running as expected. If there were any problems, they’d be captured here, making it easier to diagnose issues. In short, Entrypoint logs are an essential tool for monitoring and maintaining your Docker containers, giving you real-time feedback on the status and health of the containerized application.

Conclusion

Entrypoint are essential for building Dockerfiles. Use Entrypoint when you want to build executable Docker images using commands that always need to be executed. Thus, Entrypoint acts as an important element in your Dockerfile and can be primarily used when you want to specify command that should be run whenever a container starts.