run cmd entrypoint

In the realm of Docker containerization, the precise configuration of startup commands defines how a container behaves f

In the realm of Docker containerization, the precise configuration of startup commands defines how a container behaves from the moment it boots. Beginners often conflate RUN, CMD, and ENTRYPOINT when crafting a Dockerfile, yet each plays a distinct role in the container lifecycle. This article dissects these three pillars, clarifying their semantics, differences, and synergistic potential for building robust, adaptable images.

The Functional Roles of RUN, CMD, and ENTRYPOINT

Before diving into configuration patterns, it’s essential to position each directive within the container’s life cycle. The distinction hinges on timing: build time versus run time.

RUN (Build-Time Execution)
The RUN instruction executes during docker build. It is the workhorse for installing packages, configuring environment settings, and compiling code. Every RUN instruction adds a new layer to the resulting image. For instance, RUN apt-get update && apt-get install -y curl fetches and installs curl at image-creation time, permanently embedding the result into the filesystem.

CMD (Run-Time Default Command)
CMD specifies which command runs when the container starts via docker run. Crucially, if a user supplies alternative arguments on the command line, CMD is overridden. A Dockerfile should contain at most one effective CMD. Its purpose is to provide sensible defaults so that docker run image-name just works out of the box.

ENTRYPOINT (Entrypoint Command)
Like CMD, ENTRYPOINT defines the command executed at container start. However, ENTRYPOINT is designed so that it is not easily overridden. Instead, it treats the container as an executable. Any arguments passed via docker run are appended after the ENTRYPOINT, enabling the container to function like a native command-line utility while still accepting runtime parameters.

Build Time vs. Run Time: The Fundamental Divide

Grasping when each instruction operates is the keystone of effective Dockerfile authoring.

  • RUN happens exclusively during image construction. Example: RUN yum install -y nginx runs once, producing a new image layer with nginx installed.
  • CMD and ENTRYPOINT execute when a container is launched. At that point, the image is immutable; the runtime environment takes over, and the specified command starts as the container’s primary process.

This temporal separation explains why you can RUN apt-get updates during build, but you cannot RUN a service start command and expect it to persist without CMD or ENTRYPOINT orchestrating it at runtime.

Combining CMD and ENTRYPOINT for Flexible Containers

In practice, ENTRYPOINT and CMD are frequently paired. The pattern yields a container with a fixed executable entry point yet configurable parameters. When combined, CMD supplies default arguments that get forwarded to ENTRYPOINT.

There are two syntax forms to be aware of:

  1. Shell form: CMD python app.py runs the command via /bin/sh -c. This form is simpler but has a notable side effect: the process runs as a child of /bin/sh, which interferes with signal handling. If the container receives SIGTERM, the shell may not forward it correctly, leading to graceful shutdown failures.

  2. Exec form (recommended): `ENTRYPOINT ["python",