Container engine interop

[Chuxel]

The Docker CLI is as close to a standard as exist in interoperating with container engines. This is why engines like Podman mirror the command line interface. The reference implementation of the dev container spec (#9) and things built up from it should generally support anything that mimics the Docker CLI since it intentionally does not directly talk to the engine's daemon as an abstraction. However, there have been subtle differences that have come up particularly around the areas of file mounting and permissions. Similar to #10, there's also been interest from communities using engines and CLIs like Singularity, nerdctl, crictl, and even straight kubectl.

Today, the runArgs property is used heavily, and needs some abstraction for common properties (see #2). Any orchestrator support (see #10) would help in the case of more complex multi-container configurations. However, these do not resolve the simpler single container case where no orchestrator format is in-play.

To make it clear for how container engine communities could contribute support to the reference implementation or adopt the dev container spec in another form, I'd propose we:

1. Implement Port features.json properties for most common runtime arguments #2 and document how to add support for alternate engines in the reference implementation (Publish reference implementation #9)
2. Move runArgs to be an engine under a property much like orchestrators in Orchestrator interop #10 or customizations in Move settings and extensions properties to vscode namespace #1 (e.g. "docker" {"runArgs":""} or "docker.runArgs": ""), with details on how to add other engine specific properties.

[oschulz]

Direct support for non-Docker container runtimes would be awesome! We currently use a workaround for Singularity and Shifter - it works quite well, but it's fiddly and but it's not trivial for less experienced users to set up.

[zephyros-dev]

I'm currently using Podman, but I'd like to have the devcontainers configuration to work also for people who use Docker. Podman requires settings some specific runtime arguments as specified in here, however those settings won't work with Docker. This suggestion:

Move runArgs to be an engine under a property much like orchestrators in #10 or customizations in #1 (e.g. "docker" {"runArgs":""} or "docker.runArgs": ""), with details on how to add other engine specific properties.

should allows settings podman-specific properties if needed, however I believed this is not implemented yet as I cannot find it in the specification. Would love to have this feature supported.

[russell-parks]

👍 and echoing @zephyros-dev somewhat. Some people are comfortable switching to podman with the change to docker desktop usability in the enterprise (me). Some are more comfortable staying with docker desktop even with a price attached. I'd like to not have to keep an edited file in my git repository with custom settings for podman while developing alongside others who have docker.