ECS Task Definition - When overriding ENTRYPOINT, Docker image's CMD is dropped

Viewed 3921

I have a Docker Image built with the following CMD

# Dockerfile
...
CMD ["nginx", "-g", "daemon off;"]

When my task definition does not include entryPoint or command the task successfully enters a running state.

{
  "containerDefinitions": [
    {
      "image": "<myregistry>/<image>",
      ...
    }
  ]
}

I need to run an agent in some instances of this container, so I am using an entrypoint for this task to run my agent. The problem is when I add an entryPoint parameter to the task definition, the container starts and immediately stops.

This is what I'm doing to add the entryPoint:

{
  "containerDefinitions": [
    {
      "image": "<myregistry>/<image>",
      ...
      "entryPoint": [
        "custom-entry-point.sh"
      ],
    }
  ]
}

And here is the contents of custom-entry-point.sh:

#!/bin/bash
/myagent &
echo "CMD is: $@"
exec "$@"

To confirm my suspicion that CMD is dropped, the logs just show:

CMD is: 

If I add the CMD array from the Dockerfile to the task definition with the command parameter, it works fine and the task starts:

{
  "containerDefinitions": [
    {
      "image": "<myregistry>/<image>",
      ...
      "entryPoint": [
        "custom-entry-point.sh"
      ],
      "command": [
        "nginx",
        "-g",
        "daemon off;"
    }
  ]
}

And the logs show the expected:

CMD is: nginx -g daemon off;

I have many docker images with various iterations of CMD, I do not want to have to copy these into my task definitions. It seems that just adding only an entryPoint to a task definition should not override a docker image's CMD with an empty value.

Hoping some ECS / fargate experts can help shed some light on a path forward.

3 Answers

I got the same problem, with my entrypoint and command attributes being something like sh -c .... I needed to delete sh -c, put the commands directly, and add #!/bin/sh at the top of my scripts.

I don't think this has anything to do with ECS. This is how Docker behaves, and there's no way to change it as far as I know.

See https://docs.docker.com/engine/reference/builder/

If CMD is defined from the base image, setting ENTRYPOINT will reset CMD to an empty value. In this scenario, CMD must be defined in the current image to have a value.

This particular snippet only refers to defining a new ENTRYPOINT in the image, but this Github discussion confirms the same behavior holds when overriding ENTRYPOINT at runtime.

Related