DockerFile / docker compose CMD, entry point, docker run, docker compose exec, run

https://devtron.ai/blog/cmd-and-entrypoint-differences/ 

CMD & ENTRYPOINT means same thing for DockerFile && DockerCompose.yml

except DockerCompose.yml overwrites CMD and ENTRYPOINT if already defined in DockerFile

• ENTRYPOINT (Dockerfile) / entrypoint (Docker Compose):

  • Defines the primary executable or script that will always be run when the container starts.
  • It's the "fixed" part of the command.
  • Arguments provided by CMD (or the command in Docker Compose) are appended to the ENTRYPOINT command.
  • Less easily overridden at runtime; requires the --entrypoint flag with docker run.

  • CMD (Dockerfile) / command (Docker Compose):

    • Provides default arguments or a default command that can be easily overridden when the container is run.
    • If an ENTRYPOINT is defined, CMD provides arguments to that ENTRYPOINT.
    • If no ENTRYPOINT is defined, CMD defines the entire command to be executed.
    • Easily overridden by providing arguments directly to docker run or by defining a command in Docker Compose.

    Consider a Dockerfile with:

    Code

    
    

    ENTRYPOINT ["nginx"]

    CMD ["-g", "daemon off;"]

    When this container runs, nginx -g "daemon off;" will be executed. If you run docker run myimage bash, bash will be treated as an argument to nginx, resulting in nginx bash, which is likely not what you want.

    Now, consider a Dockerfile with:

    Code

    
    

    CMD ["nginx", "-g", "daemon off;"]

    When this container runs, nginx -g "daemon off;" will be executed. If you run docker run myimage bash, bash will override the CMD, and only bash will be executed.

  ----------------------------------------------------------------------------------------------

docker run:

Purpose:

Creates and starts a new container from a specified Docker image.

Behavior:

When you use docker run, you are launching a fresh instance of a container, complete with its own isolated filesystem, network configuration, and process space.

Use Case:

Ideal for initiating new services, testing images, or running one-off commands in a fresh environment.

docker compose exec:

Purpose:

Executes a command inside an already running container that is part of a Docker Compose service.

Behavior:

It allows you to interact with a container that is actively running within your Docker Compose application, without creating a new container. The command runs within the existing container's environment and filesystem.

docker compose exec [SERVICE] /bin/bash command is used to execute the /bin/bash command within a running container that is part of a Docker Compose service.

Explanation:

docker compose exec:

This is the command used to execute a command within a running container managed by Docker Compose.

[SERVICE]:

This placeholder represents the name of the service defined in your docker-compose.yml file (e.g., web, db, app). You need to replace this with the actual name of the service you want to interact with.

/bin/bash:

This is the command being executed inside the container. It launches a Bash shell, providing you with an interactive command-line interface within that specific container.

If you need to access a running Docker container managed by Docker Compose and it does not have /bin/bash installed, you can try the following methods:

Use /bin/sh or /bin/ash: Many lightweight Docker images (like Alpine Linux-based images) do not include bash but provide sh (Bourne Shell) or ash (Almquist Shell). You can attempt to access the container using these shells:

Code

    docker compose exec <service_name> sh

docker compose run:

This command is used within a Docker Compose project, defined by a docker-compose.yaml file.

It runs a one-time command against a specific service defined in the docker-compose.yaml file.

It leverages the configuration (volumes, networks, etc.) defined for that service in the YAML file, but the command passed with run overrides the default command defined in the service.

Crucially, docker compose run does not create or map the service's ports by default, preventing port collisions if other services are already running. The --service-ports flag or manual port mapping with -p is required to expose ports.

docker compose run does create a new container for the execution of the specified one-time command. By default, this container persists after the command finishes. However, the --rm flag can be used to automatically remove the container once the command exits. This is a common practice for transient tasks like running migrations or tests.

Both docker compose run, docker compose exec respects ENTRYPOINT defined etiher in yml or in dockerFile:

https://stackoverflow.com/questions/76260433/does-docker-compose-exec-service-command-ignore-the-entrypoint

docker compose exec does not use defined ENTRYPOINT from the Dockerfile of the service's image by default.

    It allows you to run a command in an already running container. It would make no sense to execute the entrypoint as part of that, as it might run a long running process or similar, and never return, or exit, an then never actually run the command you wanted to. Hope that makes sense.

docker compose run uses the defined ENTRYPOINT from the Dockerfile of the service's image by default.

When you use docker compose run <service_name> [command], the ENTRYPOINT defined in the Dockerfile for the specified service_name will be executed. Any command you provide after the service name will then be appended as arguments to that ENTRYPOINT.

You can also override the ENTRYPOINT for a specific docker compose run command by using the --entrypoint flag, for example:

Code

docker compose run --entrypoint=/bin/bash my_service

This would start a bash shell within the my_service container, ignoring its default ENTRYPOINT.