Support Windows Containers

[Chuxel]

Currently the Remote - Containers extension supports Linux based containers with the exception of Alpine (though Alpine is highly requested #54).

This issue is to track interest in support for Windows Containers.

[akash3456]

this error occurs on a linux container as well.

[Chuxel]

@akash3456 That's a separate topic from Windows containers. So we can reactivate your issue rather than using this one.

[wsilveiranz]

I've got into that restriction last week when working on a project where I had to create a container with a number of 3rd party components then find out why the code that I developing with those components where not working. So +1 to the support request.

[tfenster]

@Chuxel how far away is this or what needs to be done? I'd be happy to try to help if possible

[gabrielmccoll]

I would enjoy this for testing Powershell DSC in fast iterations

[alegnicitrix]

One of the main features of our software is that it runs anywhere (Windows, Linux, Mac, Android, etc.) giving customers an incredible amount of flexibility. However, a major issue that we have is having to support multiple code repos with completely different CI systems for each platform. It sometimes requires developers with specific skill sets to work on a particular platform.

We are trying to embrace this idea of a common code repo and CI pipeline for as many platforms (or at least the major ones: Windows, Linux, Mac) as possible. If Remote Containers were able to support Windows and Mac containers, this would be a giant boost towards that goal. It would allow us to offer the same consistent developer experience across all these platforms. It would also allow developers to build features for all platforms at the same time with very little effort!

[Koubek]

Hello @Chuxel. Please, could we get an update about the progress on this topic? I think for many of us it is one of the strategical building blocks and I would like to know if the support of Windows Containers is still planned and thus relevant or not.

[Chuxel]

This feature would require a significant amount of work given the number of commands that need to be fired inside of the container to do various tasks that rely on shell commands. Unfortunately the feature would only work for Windows users with Windows 10 Pro and up (given Hyper-V is required) and these containers cannot run on macOS or Linux. (Docker for WSL2 opened up Windows Home for Linux.) As a result, it's not currently on our 2020 roadmap.

[Koubek]

OK @Chuxel, I can see... Thanks for the valuable input!!!

[alegnicitrix]

This feature would require a significant amount of work given the number of commands that need to be fired inside of the container to do various tasks that rely on shell commands. Unfortunately the feature would only work for Windows users with Windows 10 Pro and up (given Hyper-V is required) and these containers cannot run on macOS or Linux. (Docker for WSL2 opened up Windows Home for Linux.) As a result, it's not currently on our 2020 roadmap.

@Chuxel , I'm not sure I understood what you meant in your reply. I'm wondering if maybe you guys misunderstood what I was originally suggesting. Here is what I was trying to suggest:

Say I have a repo that contains C/C++ code for a client application. This application is supported on multiple platforms (Windows, Linux, Mac). I have 3 different teams submitting changes to this repo. Team W checks out the repo on a Windows machine and builds the Windows version of the client (using Visual Studio 2017 compilers) and tests it on Windows. Team M checks out the repo on a Mac machine and does the same for their platform. Team L does the same for Linux (using gcc compilers).

The problem is that each of these teams has a totally different experience when it comes to build this code locally on their own machine. It is kind of hard to main 3 totally different build systems. On top of that, the CI/CD system for each of these platforms is completely different.

To simplify the developer's life, we wanted to use Remote Containers. We could potentially create 3 different dockers, one for each platform, that would have all the necessary build tools already setup and ready to go. The developer would simply checkout the repo, open VSCode, connect to the corresponding container for the kind of machine they are using at the moment, and initiate a build command (using something like cmake for example). The developer would not have to worry about setting the machine up with all the necessary tools to build. The BIG problem is that Remote Containers seems to be supported only for containers of type Linux. In other words, a developer on a Windows machine cannot connect to a Windows Remote Container to build, or a Mac developer on a Mac machine cannot connect to a Mac container to build.

Using a docker container to build the code would also simplify the CI/CD system itself.

[Chuxel]

@alegnicitrix This feature request is above windows containers - everything above applies there. To be clear, you can use Windows, macOS, or Linux with Linux containers today. The comments above still apply to Windows containers, which to be clear are not full windows but run a special flavor of windows, so last I checked, you can't RDP into them for example. Windows containers can also only be used from Windows - you can't use them from macOS or Linux. I'm not aware of any Docker support for macOS containers, and even if there was, Apple licensing undoubtedly would lock them to mac hardware like VMs.

[alegnicitrix]

@Chuxel,

Right, I'm not suggesting RDP into the containers. As you mentioned, the Windows docker are not the full Windows OS.
I'm also not suggesting that from a Windows machine you connect to a Mac docker (this is obviously not allowed by Apple).

Remote Containers only seems to support the following, which only allows you to produce Linux binaries:

• from a Windows machine connect to a Linux docker
• from a Linux machine connect to a Linux docker
• from a Mac machine connect to Linux docker

I am suggesting the following support to be added to Remote Containers:

• from a Windows machine connect to a Windows docker (so that we can produce Windows binaries)
• from a Mac machine connect to a Mac docker (so that we can produce Mac binaries)

The developer's machine would only need to have VSCode installed (which serves as the frontend UI for the developer), with the Remote Containers plugin. My cross-platform repo where we contain C/C++ code for all platforms would contain the custom docker files (one for each platform, customized to have the VSCode backend, cmake, the various build tools needed to produce binaries for each platform, + additional tools that may be specific to my company that may be part of the build process).

[ChrisAtRelativity]

• from a Windows machine connect to a Windows docker (so that we can produce Windows binaries)

This would be very helpful to our organization as well. We would be able to distribute local development and operations environments very efficiently.

[Rwandevops]

I need vscode remote container with a windows image to:

• run the tests on the products in an environment that is mirror of the servers of my clients
• allow the developers in my team to develop directly in this environment

[tst-rwildes]

If vscode supported remote connecting into a Windows Container I could create docker images that devs could use to build a given project under Windows. Then the dev could simply have just to install docker desktop (enable Windows Containers) and vscode (with various plugins). Nothing else is needed. As dev tools change I can just update the docker image and have devs fetch that latest version. Working on different branches/projects that use different tool chains and versions of those tools becomes much more doable. Without this support I could still have the docker image but it is much less useful because for vscode to work correctly the devs have to have all the correct tools installed on the host as well as the Windows Container. And if they are working on different projects/branches that use different tool sets this makes life hard. Running vscode in the correct context where it has access to all the tools (at the correct versions) that the various plugins use to do their jobs is the goal here.

[ejazr83]

The usecase described by @alegnicitrix and @tst-rwildes is very relevant for us also.

VSCode is giving first class remote support to linux containers and linux servers with remote-SSH, remote-WSL and remote - Containers but Windows is nowhere in the ecosystem. Not looking at RDP to windows servers / containers but just providing a remote dev environment where .NET framework or similar apps can be compiled and developed

As we move to remote development models where all dev work is done remotely and we have automated builds and dev environments described in code as dev containers in json to improve our dev experience, we just can not replicate this for windows devs right now.

Would it help if the focus is initially just for windows platform only?

[CarlosDomingues]

Even though using Linux Containers on a Windows host has greatly improved with WSL and WSL 2, it comes with performance issues and a few caveats (e.g. Docker in Docker).

For some languages/frameworks, developing in Windows is perfectly fine. Hence, using the same OS as the host system would make life way easier for developers while greatly improving performance in some cases.

[davetapley]

This might merit a separate issue, but:
Can we warn the user that Windows Containers aren't supported?

My experience was seeing this:

Then seeing this in the logs:

container [....] encountered an error during hcsshim::System::CreateProcess: failure in a Windows system call: The user name or password is incorrect. (0x52e)

Which led me on down a user name / password rabbit hole until I stumbled upon this issue, which seems to indicate that this just isn't supported at all?

[jachin84]

I too have a use-case for Windows Dev Containers. I'm curious what the limitation is here and why there seems to be low interest in supporting this feature?

[gerneio]

3+ years later, still no support? What have people been using in the mean time?

[ecc256]

3+ years later, still no support? What have people been using in the mean time?

I'd moved all development to Ubuntu...

[gerneio]

I'd moved all development to Ubuntu...

Some of us don't have that flexibility and still require the use of a win container for one reason on another (i.e. dependency on .NET Framework).

[erri120]

3+ years later, still no support? What have people been using in the mean time?

You can still SSH into the container if you have OpenSSH or similar running in it: https://github.com/erri120/ModOrganizer-Docker/blob/master/Dockerfile.Dev

[Chuxel]

Since it has been a bit since we've provided an update here and a frequent question has been "when," I'll mention that we do not have a specific timeframe to pick this up. Since there's been a few questions as to what it would take:

1. The first step would be to update the dev container spec (https://github.com/devcontainers/spec) with a proposal for how to manage the Windows specific aspects of the problem.
2. Next, the dev container CLI would need to be updated with a reference implementation (https://github.com/devcontainers/cli - which anyone can contribute to given it is OSS).
3. A set of windows-specifc samples, templates, Features, and other content would need to be developed given they would inherently all differ from Linux.
4. Finally, each tool or service including the Dev Containers extension would need to make sure its behaviors (and hosting environments) supported it, and commit to maintaining it long term.

Part of the challenge is that Windows Containers are bigger to start cannot do everything a VM could do like Linux containers can. In particular, they cannot support RDP (or running GUI-based apps) which is often one of the first questions raised when considering containers as an "inner loop" development environment - particularly given desktop apps are one of the considerations that drives interest. Instead the focus has been the Remote - SSH extension and the more recently introduced Remote - Tunnels extension since both of these provide a way to use VMs as well.

[jrhemstad]

My team builds C++ libraries that support both Linux and Windows and Windows support for devcontainers is vital for us.

Devcontainers have been a game changer for us and we are huge fans. They have enabled us to craft a solution that significantly simplifies local development, CI environments, and set up for first time users.

However, there is a massive gap in that story when it comes to Windows.

What are the developers on my team supposed to use for developing and triaging issues in Windows?

What should we use for the environment of our CI jobs on Windows runners?

We've invested heavily in building all this unified infrastructure around devcontainers, but it is effectively worthless for an entire axis of our support matrix.

I would think Microsoft would have a vested interest in supporting its own OS 🙂.

[BenediktRombach]

Would be interesting for us as well, mainly for debugging CI build failures as development environments are not that easy to reproduce...

[hamaney]

Microsoft certainly seems to be holding back the potential of Windows containers; there are at least four different types (App-V, MSIX, Docker, Sandbox) but no individual one has everything. I'm assuming they don't let us run anything graphical in Docker containers due to wanting to preserve their CAL revenue stream.

If you would like to request a new feature, it's always more effective to make your request in a polite and friendly manner.

[JonasSTC]

Our whole industry is built on Windows tools. We are limited in the way we work by not being able to develop and debug in windows containers. Either VSC or Pycharm gets there first and reaps the rewards of tens of thousands of industry users adopting this way of working. Please make it happen.

[Jiter]

I want once again raise interest in this option.

[arndttob]

• from a Windows machine connect to a Windows docker (so that we can produce Windows binaries)

This would be very helpful to our organization as well. We would be able to distribute local development and operations environments very efficiently.

Actually, this is working for me so far, with a huge workaround. Currently, I'm able to build .Net Applications in Windows Containers and debug the build (tested with powershell scripts so far).

• installed docker desktop
  • switched from linux to windows containers
• created an image from windows:ltsc2019
  • installed latest powershell, openssh and VS BuildTools 2022
  • configured the openssh-server (hostkeys, new user, fix filepermissions)
  • started container as daemon and mounting source code to build
• in visual studio code
  • install remote explorer, remote development, remote - ssh
  • in remote-explorer connect to docker containers openssh-server
  • in remote-explorer open mounted folder (your source code to build) in container
  • start build/debug (works also with breakpoints e.g.)

Depending on the language you want to build, VS code lets you install the required extension into the remote (container).

[gareth-walley]

Our clients are tied to Azure. Devcontainers are awesome, and we use them for local development. However, our primary deployment environment is Windows Server 2019, and not being able to use Windows Server 2019 devcontainers is a huge issue for us right now.

We get around this by running a Windows Server 2019 VM on Azure, and SSH'ing into it, however this is very inconvenient, and doesn't scale well across our team. Additionally, it is far more expensive, far slower, and relies on constant network access, so working whilst travelling is difficult.

Being able to spin up a local Windows dev container with integration into VSCode would be a gamechanger for us!

[NguyenMVo]

Agree, our main projects are Windows-targeted. Not able to apply .devcontainer creates a huge effort of maintaining.
The use of devcontainer in our Linux projects are proved with efficiency and less time-consuming for newcomers.

Please at least have a plan to support it. This issue was opened for almost 5 years but no progresses from Microsoft.

[orroth]

I develop in windows and want to use devcontainers.

[Adeas]

Any idea if support for windows containers are even planned?

[NguyenMVo]

Any idea if support for windows containers are even planned?

My workaround is using Docker Desktop with Hyper-V (not WSL) for Windows containers

[usama-elm]

Any idea if support for windows containers are even planned?

My workaround is using Docker Desktop with Hyper-V (not WSL) for Windows containers

Could you explain in more detail and share some Dockerfiles/devcontainer.json

I am interested in building a Flutter devcontainer but on Windows

[NguyenMVo]

I am interested in building a Flutter devcontainer but on Windows

I was talking about containers that running Windows (OS) image.
I'm not sure if you misunderstood something. But to achieve it, you can simply do these steps:

• Change the settings in Docker Desktop from WSL to Hyper-V
• Enable Hyper-V in Windows with some Powershell commands and then restart your machine.

More details: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v

Flutter should be cross platforms, I assume. You can use Linux as base image in your Dockerfile and run it inside your WSL on your Windows machine.

[Jiter]

Can you clarify: @NguyenMVo
Are you able to run devcontainers natively in vscode with this setup?

Docker Desktop has a setting for using Linux or Windows Containers, there is no need to switch to Hyper-V.

The Issue is about enabling the usage of devcontainers in windows based Images.

[usama-elm]

I was talking about containers that running Windows (OS) image. I'm not sure if you misunderstood something. But to achieve it, you can simply do these steps:

* Change the settings in Docker Desktop from `WSL` to `Hyper-V`

* Enable Hyper-V in Windows with some Powershell commands and then restart your machine.

Yeah I saw that information but the problem is that as of now there is no explicit support for devcontainers running Windows Server Core images as @Jiter mentioned, here is the source https://code.visualstudio.com/docs/devcontainers/containers#_system-requirements

(Docker Toolbox is not supported. Windows container images are not supported.)

[grochoge]

@NguyenMVo I'm guessing you're actually running a Linux container.

Here's what happens when I try attaching to an already running Windows container:

[8503 ms] @devcontainers/cli 0.62.0. Node.js v20.9.0. win32 10.0.19045 x64.
[8503 ms] Start: Run: docker buildx version
[11880 ms] github.com/docker/buildx v0.11.0 687feca9e8dcd1534ac4c026bc4db5a49de0dd6e
[11881 ms] 
[11881 ms] Start: Run: docker -v
[12172 ms] Start: Run: docker inspect --type container 71dc0319ce18dd8db3f01a266a5332c2dbb40ac59e0981c003e112fd00ade3b0
[12456 ms] Start: Inspecting container
[12456 ms] Start: Run: docker inspect --type container 71dc0319ce18dd8db3f01a266a5332c2dbb40ac59e0981c003e112fd00ade3b0
[12735 ms] Start: Run in container: /bin/sh
[12782 ms] Start: Run in container: uname -m
[13073 ms] Shell server terminated (code: 126, signal: null)
[13074 ms] container 71dc0319ce18dd8db3f01a266a5332c2dbb40ac59e0981c003e112fd00ade3b0 encountered an error during hcs::System::CreateProcess: failure in a Windows system call: The system cannot find the file specified. (0x2)
[13074 ms] [Event Detail:  Provider: 00000000-0000-0000-0000-000000000000]
[13074 ms] [Event Detail:  Provider: 00000000-0000-0000-0000-000000000000]
[13074 ms] [Event Detail: onecore\vm\compute\management\orchestration\vmhostedcontainer\processmanagement.cpp(173)\vmcomputeagent.exe!00007FF768DF9F4B: (caller: 00007FF768DAE13A) Exception(6) tid(398) 80070002 The system cannot find the file specified.
[13074 ms]     CallContext:[\Bridge_ProcessMessage\VmHostedContainer_ExecuteProcess] 
[13074 ms]  Provider: 00000000-0000-0000-0000-000000000000]