OS specific dev containers

[Chuxel]

One of the value propositions of dev containers is that teams that use mixed operating systems can all benefit from a consistent toolchain regardless of host OS. However, in some cases, there may be development containers that will only ever work on a specific operating system. (See microsoft/vscode-dev-containers#169.)

This feature request tracks the idea of being dev containers being able to declare where they are expected to work.

For example, one possible way this could work is that devcontainer.json could have a property that declared the host OS platforms it supported (macos, windows, linux). Not specifying any platform could mean that it works with any for backwards compatibility.

To use a property like this we could set things up so that, if a devcontainer.json in the vscode-dev-containers repo has a value for property, any lists in VS Code include / exclude it based on the host OS VS Code is running on. Similarly, in the case of an "open folder in container..." scenario with an existing repository with a devcontainer.json in it, we could at least warn that the dev container is not intended for use on the current host OS if it is not in the list.

//cc: @chrmarti

[bhack]

I cannot see the internals but I suppose that It Is not a so complex task.

[frank-dspeed]

This should not get done!!! The Container and The Software your Coding Identifys it self already.

[frank-dspeed]

Don't get me wrong but i wan't to give you some examples a -windows image will only run on windows a -arm image will run on arm

you can not even guess on what platforms this can get executed i am runnong for example vscode on my android with custom theme. i think no one did expect that?!?

[frank-dspeed]

containers have only one boundarie the CPU Architecture they are running on https://github.com/unicorn-engine/unicorn

[bhack]

@frank-dspeed We need this cause docker has some feature portability limit and you cannot limit the use cases to the common features.
Check again the thread microsoft/vscode-dev-containers#169

[bhack]

How much work Is required for this feature?

[frank-dspeed]

i am for adding that only to the description of the dev container maybe as anything else would mean we need to guess the host os

[bhack]

We have os.platform() and os.type() what is the problem?

[bhack]

@Chuxel we need to think also to cross-compile sceneraios.
E.g. see openwrt Docker images when you have different containers with prepared precompiled toolchains for every arch:
https://hub.docker.com/r/openwrtorg/sdk/tags

[samrocketman]

Use case

Take, for example, the open source game Endless Sky. It builds across 3 different operating systems.

You can see the build artifacts workflow for Windows, Mac, and Linux.

Multi-OS support

It makes sense to build a windows artifact when developing from a Windows host. Same goes for Mac on Mac or Linux on Linux.

I know there's no Mac containers but at a minimum it should be possible to support Windows containers on Windows and Linux containers on Linux.

[frank-dspeed]

Now after some more years of edge case evaluation and triage the result is still that you should simply document the processor architecture that runs on and the os. Containers could also get deployed to remote container hosts while they are containers. So the Host OS of the developer is less relevant. see also vscode online.

Short Logical Arrgument for CPU OS only meta

The Reason is the following a Container is not a VM it is a Isolated Process that runs binary processes with the same processor architecture and kernel of the core main host operation system so they can be seen as simple binarys that simply get executed with some extra binarys you can see them as selfextracting zip files or any other packaged Binary Application.

Current state of Isolation

MacOS Also supports containers it is defacto the first os that did implement them the name was chroot + some hardening via process.

Today freebsd jails will allow macos containers and windows containers are getting implemented by microsoft at present

https://marcocetica.com/posts/understanding-freebsd-jail/

macos containers are more near then you all do expect

[chrmarti]

Windows containers are tracked as #445.

FreeBSD support is tracked as #727.

This issue is about having host OS-specific properties in the devcontainer.json.

[blackliner]

What about being able to run two different environments: Ubuntu 18.04 and Ubuntu 20.04

Would this also be covered? Our product gets compiled for different (Linux) OS, and being confined to only one environment in the devcontainer world is limiting :-(

[frank-dspeed]

@blackliner out of my view this will not even really be covered by this solution you could define maybe a remote location that is able to offer both environments but thats up to you.

[chrmarti]

@blackliner That sounds like you would want different versions of Ubuntu inside the container. (This issue is about the host OS, not the container OS.)

[blackliner]

Yes, it's about having different OS inside the docker. Its not the same I guess, but very close in terms of feature set I guess?

[Chuxel]

@blackliner Yeah its quite different since what you are talking about would be a way to affect the image or Dockerfile when starting up a dev container... or put another way having multiple dev container configurations. The good news for your needs is we've started on a capability that would allow multiple dev container configurations to be under the same .devcontainer folder (devcontainers/spec#6). You'd then be prompted when opening as a dev container as to which one you'd like to use.

At that point you can have a common Dockerfile or Docker Compose file with different build arguments or devcontainer.json config. There is then also the dev container features capability that allows you to reuse scripts and config across multiple dev container configuration files or even repositories.

What this issuue is about is not any of that, but rather the ability to indicate that certain devcontainer.json properties should only be applied for a given local OS (not the one in the container). FWIW - this same capability could be used here, but a developer could still end up picking the wrong one and hit problems that they do not understand based purely on the local machine they use. That isn't ideal since consistency and reducing "it works on my machine" situations is a key benefit of dev containers, so some affordance for those situations makes sense.

Make sense?

[blackliner]

Don't get me wrong, I am fully aware about your proposal being about different Host OS and mapping them to guest OS. But IMHO this is just one view of a fully configurable N to N mapping.
1 host OS can run 1 guest: easy
N host OS can run 1 guest: possible today (kinda, given docker supports your platform)
1 host OS can run N guest: my request
N host OS can run N guest: your request

Make sense? Oh, and thanks for the links, will dig them later.

[frank-dspeed]

@blackliner there is something that is a logic failure in your complexity matrix you need to add the CPU to that 1 CPU type can run only (N) Host OS the () references the N as partial as not all Processors can run any OS.

you need to add first a CPU level to that also the CPU Tells you if docker support is possible not only the OS. Containers are Layered over the Host OS Kernel running with it and its sys calls to the CPU.

Also you need to take GPU's into consideration as soon as you code something that shows something that should move fast.

[manuth]

As I think I've got another use case for this feature, I thought I'd just go and post it here.
Hope I'm at the right spot here

So I have a docker container with some x11 applications in it. On Linux, it's working out great.
I'm mapping ~/.Xauthority, /tmp/.X11-unix and the DISPLAY variable to the container and I'm ready to go.

However, on Windows (using WSL), there are a whole bunch of additional variables and a volumes that I have to add to the container:
https://github.com/microsoft/wslg/blob/5886a29a21232dfd87bd50d14e431ddae24663a8/samples/container/Containers.md

One could say that I could easily add /mnt/wslg:/mnt/wslg to my docker-compose.yml file, but if I do so, running this devcontainer on my linux would create an /mnt/wslg on my linux system which is an unwanted side effect.

[stepkun]

Currently there are several incompatibilities between docker compose on Window and on Linux if you want to use video and audio from within a container.
Therefore I had to separate the definitions into platform specific compose-<platform>.yaml files.
It would be really great if I could select the proper file winthin devcontainer.json with the help of a built in variable , which provides different values for different platforms, for example like nodes process.platform() does.

So that I could do someting like

	"dockerComposeFile": [
		"compose-common.yaml",
		"compose-${host_platform}.yaml"
	],

[rvodden]

Another use case here is if you're using rootless docker on Linux with vscode then remote user has to be "root", whereas on windows its preferable to run as a non-root user.

[stepkun]

Recently I found a workaraound:
naming the linux specific file compose-.yaml (pay attention to the dash before the dot!)
and naming the windows specific file compose-Windows_NT.yaml
then in the devcontainer.json I use

	"dockerComposeFile": [
		// on Linux ${localEnv:OS} will evolve to "" on Window to "Windows_NT"
		"compose-${localEnv:OS}.yaml"
	],