Vscode-remote-release: 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!

[qqq689]

It is a difficult process and I did not understand everything about it. Can
you help me? I hope so with you. If you want help, I will be grateful, but
I hope so from you. I am now in a challenge. We are an expert.😖😔😔

في الأربعاء، ٢٠ أيار، ٢٠٢٠ ٨:٤١ ص alegnicitrix [e-mail]
كتب:

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!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/445#issuecomment-631249151,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUECRLB3FMSHQ6FUQ3XP73RSNUQFANCNFSM4HPQICQA
.

[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?