Suggestion: use overrideCommand as false by default

[felipecrs]

I believe there is something wrong with the concept behind this option overrideCommand, let me explain why:

In Dockerfiles you have ENTRYPOINT and CMD (command). The option overrideCommand actually overrides the ENTRYPOINT of the docker image, and not only the command (CMD). Maybe it should be renamed?

Nonetheless, I believe the entry point override should never execute by default. Entry points on Dockerfile's are scripts or programs which are supposed to run the first container initialization (they do not run in docker exec, but only on docker run) because of some customization needed. They (entry points) are responsible for correctly calling any further command passed to the docker run, or CMD if none is passed. See the official documentation here, and here.

Because of that, the official docker-from-docker devcontainer needs to customize the devcontainer.json with overrideCommand as false. See here.

If the reason for leaving it default to true is because someone can code a Dockerfile entry point in a wrong way, not set accordingly to execute the command line, so I say that this is not a VSCode fault and also not a responsibility of VSCode to work around it.

My suggestion is:

1. Make overrideCommand overwrite CMD and not ENTRYPOINT, default is true.
2. Create a new option overrideEntrypoint, which overrides ENTRYPOINT and not CMD, default is false.

[chrmarti]

Only overriding the cmd is not enough because some images set an interpreter as the entrypoint and we want to set cmd to a process that doesn't exit. The only way to do this reliably is by overriding the entrypoint as well.

[felipecrs]

@chrmarti I covered this in the description:

They (entry points) are responsible for correctly calling any further command passed to the docker run, or CMD if none is passed. See the official documentation here, and here.

Please take a look at the official docs mentioned. 1.

If the reason for leaving it default to true is because someone can code a Dockerfile entry point in a wrong way, not set accordingly to execute the command line, so I say that this is not a VSCode fault and also not a responsibility of VSCode to work around it.

As said, this can be easily addressed by documenting it. And if people want to use images with entry points bad written, they still can by setting the overrideEntrypoint to true.

[chrmarti]

These entrypoints are not necessarily badly written, they are just written with a different use than a DevContainer in mind.

The goal is to minimize the number of cases where the default behavior does not work and the user needs to add another flag to the devcontainer.json. I think the current default achieves that and we have the flag to turn it off to let the user take control.

[felipecrs]

You hit another point which I think is crucial: how do you know that there are more users using a devcontainer which does not comply with entrypoint best practices over the ones who do? As I said, anyone who would like to use docker "from" docker would have to set this option to false, and I believe this should be a big amount of users since it's very common to have containerized applications.

And I believe we can safely say that these entrypoints are indeed badly written since they do not comply with the Docker best practices for entrypoints.

[felipecrs]

@chrmarti by the way, do you know any image which would require this behavior (overwriting the entrypoint)?

[chrmarti]

We changed that base on the feedback in #259.

[chrmarti]

To avoid breaking existing configurations, we could deprecate overrideCommand and introduce overrideCmd and overrideEntrypoint. I'm not sure though if we would change the default of overrideEntrypoint to false. /cc @Chuxel

[felipecrs]

That's a nice idea. I still believe the default behavior of overrideEntrypoint should be false for the reasons stated above:

1. It's the Docker CLI default behavior
2. Docker recommends you to create entry points which properly execute the commands
3. If for some reason a person does not follow this recommendation, they can still set overrideEntrypoint: true
4. A good example of this is how Jenkins deals with Docker images as build agents. Sometimes you need entry points to properly start background services in the container. This does not mean that the entry point should not handle the CMD.