devcontainer.json property to execute a command whenever VS Code starts a container

[Chuxel]

Related to https://github.com/MicrosoftDocs/vsonline/issues/403

Most Docker images do not have a functional daemon system which makes starting things that need to run whenever a container is started difficult. Typically this is solved by using a custom ENTRYPOINT or CMD in a Dockerfile.

However, if you need to start something that is part of your application or a development dependency (e.g. a database or a file watcher), you may not want or be able to override the default ENTRYPOINT or CMD since it depends on scripts in the source tree actually being present. Furthermore, by default, the command and entrypoint are both overridden by VS Code in the Dockerfile case. In some cases applying a .bashrc script is enough, but this does not work in situations where sh, ash (Alpine default), or dash (Ubuntu) are used since they have no concept of an rc file.

As suggested in https://github.com/MicrosoftDocs/vsonline/issues/403, something like a postAttachCommand (or onResumeCommand as proposed there) would allow developers to resolve this situation with devcontainer.json for both Dockerfile and Docker Compose scenarios, along with any attach configs.

//cc: @chrmarti @egamma

[chrmarti]

Make sense. Note that in general you can connect with multiple windows to the same container. Would you want the command to be run only once (when starting the VS Code Server) or for each connection?

[Chuxel]

It would be once per container start, so as we were discussing in MicrosoftDocs/vsonline#403, perhaps postAttachCommand isn't quite the right property name.

I have a concrete example of where it would be useful in an improved docker-in-docker container that enables the non-root user to access the docker socket. In that case, you don't want to go change the permissions on the actual Docker socket since this affects the host OS on Linux and all containers on Windows and macOS (since it's from the VM the containers are in). Instead, I use socat to proxy the unix socket to another unix socket that I can safely change privs on. The problem is that there's no way to start socat early enough for the Docker extension to pick it up unless I change the entrypoint and set "overrideCommand": false. Since this is intended to be something you could reuse with any container image as a starting point, that ends up being a clunky solution.

I'll queue up a PR on it so you can see what I'm talking about.

[Chuxel]

@chrmarti Actually, I can just point you to the README in the branch which explains what needs to happen. I'd rather drop the use of the ENTRYPOINT in favor of this property.

https://github.com/microsoft/vscode-dev-containers/tree/clantz/dind-v2/containers/docker-in-docker#enabling-non-root-access-to-docker-in-the-container

[artificial-aidan]

Another related request. Have this also apply to non devcontainers. For example, I'd like to have a setting that ran a command every time I attached to a running container. My workflow right now has me connecting to containers created by another process, or kubernetes containers, and I'd like to be able to connect to a container, and have some commands run automatically. My plan right now was to use this extension but a built in feature would be better.

[chrmarti]

Will add postStartCommand and postAttachCommand. Both will run inside the container and the sequence when starting from scratch (or rebuilding) will be:

• initializeCommand (locally)
• postCreateCommand
• postStartCommand
• postAttachCommand

preDeleteCommand needs more discussion:

The only case where Remote-Containers deletes a container automatically is when rebuilding the container. Should it run the preDeleteCommand in that case? The container will be recreated after that.

The user can delete a container through the Remote Explorer. Should the preDeleteCommand run before that?

What if the user deletes the container through the Docker extension or some other tool or the Docker CLI? Is not running the configured command in this case good enough?

[PavelSosin-320]

The full list of Docker engine events is described in Docker spec and gives no space for discussion. It's too late Docker events
Docker images and Docker containers are observable manageable objects by definition, unlike VM.
Dockerod does support event streaming Dockerod !!! as a part of spec fulfillment.Docker events CLI command and its output can be filtered flexibly. t is simply wrong to think that containers can be taken down only manually. It can be restarted by the Docker daemon or orchestration engine will.
I suppose that the main hook should be onEvent according to the observable pattern.
So, pre-delete is redundant because of the observer, in our case, VSCode will know that when it happens.
In the case of the rebuild, another event will precede the container restart.

[chrmarti]

@PavelSosin-320 The extension does not run at all times (neither does VS Code), so we cannot catch all Docker events. These commands need to run at specific stages during the startup of the devcontainer, so invoking the commands from the extension's startup code seems appropriate.