Port features.json properties for most common runtime arguments

[Chuxel]

As a part of development for dev container features (#60), we introduced properties for the most common runtime arguments used in devcontainer.json's runArgs property. The great part about this implementation is that it worked with Docker Compose as well and is abstracted enough to work with other potential orchestrators or container runtimes down the road. It would be awesome to bring these to devcontainer.json as well.

Specifically:

• privileged
• capAdd
• securityOpt
• init
• mounts in a revised form that is not quite so engine specific
• entrypoint (which would be useful with the proposed overrideEntrypoint from Suggestion: use overrideCommand as false by default microsoft/vscode-remote-release#3614 (comment))

We could also bring containerEnv into Docker Compose as it is in features.json.

Ideally we'd continue this trend whenever a new property along these lines is added to features.json (and vice versa).

[joshspicer]

I like this - will clean up our templates a bit and improve readability.

[Chuxel]

Yep! It should future proof the spec as well given interest in different container engines. These can have orchestrators that have subtle tweaks in how these need are set. We don't want to "be the orchestrator", but provide a place to house subset of properties that are specific to dev that need to happen regardless of them - e.g. capAdd to enable ptrace based debuggers.

[numeralz]

Is is possible to specify overrides for a feature added to devcontainer.json? It may solve a class of issues where the default arguments (like mounts) of feature definitions need to be removed/changed.

For example, I added the docker-in-docker feature to my devcontainer.json, but in order to be able to have docker-in-docker enabled in more than one containers on one host, you must mount /var/lib/docker to a uniquely-named volume.

	"features": {
		"docker-in-docker": {
			"version": "latest",
			"moby": true,
			"dockerDashComposeVersion": "v1"
			//FIXME: can we have "customizations": { "mounts": [  ] } or similar
		},
        },
        // attempt to mount /var/lib/docker to unique :
	"mounts": [
		"source=UNIQUE-dind-var-lib-docker,target=/var/lib/docker,type=volume"
	]

Fails because "docker-in-docker" feature def has a built-in mount to /var/lib/docker which conflicts with my uniquely-named volume:
from error log, formatted for readability:

...
--mount source=UNIQUE-dind-var-lib-docker,target=/var/lib/docker,type=volume   <-- my attempt
--mount type=volume,src=dind-var-lib-docker,dst=/var/lib/docker    <-- built-in
--mount type=volume,src=vscode,dst=/vscode -l
...
echo Container started
docker: Error response from daemon: Duplicate mount point: /var/lib/docker. <-- conflict
...

The drop-in features are great until they don't work for rare edge cases. I suppose this issue could be resolved by adding an additional config parameter to disable/rename /var/lib/docker mount, but something like "features.*.customizations" could reduce the overall need to design features with every possible use-case in mind.

microsoft/vscode-dev-containers#1249

https://github.com/microsoft/vscode-dev-containers/blob/72359e9ca313b7ab529a9481aae84432a81e007f/script-library/container-features/src/devcontainer-features.json#L36

microsoft/vscode-remote-release#5679

---

FYI: If anyone has this issue, the workaround is to use manual script method docker-in-docker.md#script-use and remove the "docker-in-docker" feature from devcontainer.json.

[Chuxel]

@numeralz Thanks for the reminder on this one - I raised #62 for the proposed solution to handle this one.

[chrmarti]

We added mounts, containerEnv, containerUser, init, privileged, capAdd, and securityOpt as part of #95.