Skip to main content
Hello and welcome to this comprehensive lesson on Docker commands, arguments, and entry points. My name is Mumshad Mannambeth, and in this session, we will dive into how containers run processes and how these concepts later translate into pod definitions in Kubernetes. Although these topics are often overlooked in certification curricula, understanding them is essential for mastering containerization.

​
Understanding Container Commands

When you run a Docker container using the Ubuntu image, as shown below:
Docker launches a container based on the Ubuntu image, which starts and immediately exits since it runs a default process that completes quickly. If you inspect the currently running containers:
you will notice that the container is absent because it has already exited. However, viewing all containers—including those that have stopped—with:
reveals that the container is in an “exited” state:
This behavior is different from traditional virtual machines. Containers are optimized to run a single task or process, such as hosting a web server, application server, database, or performing a specific computation. Once the task completes, the container stops because its lifecycle is tied directly to the process running inside it.

​
Default Commands in Docker Images

Each Docker image contains instructions that define the process to run when a container starts. Many popular images, such as nginx or MySQL, include a CMD instruction in their Dockerfile that sets the default command. For instance, the nginx image typically has the command nginx, and the MySQL image uses mysqld. Consider this Dockerfile snippet for installing and configuring nginx:
Now, let’s examine the Ubuntu image’s Dockerfile. Notice that in this example, the default command is set to Bash:
Remember: Bash is a shell, not a persistent server process. When the Ubuntu container is launched without an attached terminal, the shell exits immediately.

​
Overriding the Default Command

To override the default command for a container, you can append a command to the end of the docker run command. For example, this command instructs the container to run sleep 5:
In this scenario, the container executes sleep 5, waits for five seconds, and then exits. If you want to permanently change the behavior of the image so that it always runs sleep 5, you must create a new image based on Ubuntu and specify the new default command in its Dockerfile. You can specify the command in either of two formats:
  1. Shell form:
  2. JSON array format:
Build the new image with:
Then run the container using:
By default, this container will sleep for five seconds.

​
Configuring ENTRYPOINT for Runtime Arguments

Sometimes, you may want to specify only runtime arguments without changing the default command. In such cases, the ENTRYPOINT instruction is useful. This instruction sets the executable to run when the container starts, and any command-line arguments provided at runtime are appended to it. Consider the following Dockerfile:
After building and running this image:
the container executes sleep 5 by default. You can override the sleep duration at runtime by specifying a new parameter:
This command runs sleep 10.
  • With CMD alone, runtime arguments replace the default command.
  • With ENTRYPOINT, runtime arguments are appended to the specified executable, allowing you to override just the parameters.

​
Overriding ENTRYPOINT at Runtime

At times, you might want to completely override the ENTRYPOINT. For example, if you wish to use a different command (like switching from sleep to sleep2.0), you can do so using the --entrypoint flag in the docker run command. Given the Dockerfile:
Build the image:
Running the container without modifications:
will produce an error because sleep expects an operand:
However, running with a new parameter:
executes sleep 10. To override the ENTRYPOINT with a different executable, run:
This command starts the container with sleep2.0 10 (provided that sleep2.0 is a valid command).
The image is a plain white background with no discernible objects or features.

​
Conclusion

This lesson explained the inner workings of Docker commands, arguments, and how the ENTRYPOINT instruction allows dynamic parameter passing at runtime. These concepts not only help in managing Docker containers efficiently but also lay the groundwork for understanding how they translate into pod definitions in Kubernetes in subsequent lessons. Happy Dockering! For further reading, check out the following resources:

Watch Video