Create base container with full GUI support

[vrapolinario]

Request from User Voice: https://windowsserver.uservoice.com/forums/304624-containers/suggestions/13785024-create-base-container-with-full-gui-support

[agowa]

As you have asked for some user stories on twitter, I'm going to add it here to:

1. Administering shitty programmed applications that often also have the status of business critical. Having them within a container will allow scheduling within k8s. And if it crashes k8s will restart it...
2. Replacement for App-V, RDSH and RDVH. Currently with linux based containers, I often spawn a simple container in some cloud and connect to it over SSH using Xrdp and have a full desktop environment. That is quite handy for interactively testing and debugging connectivity issues or just to try stuff and trash the instance afterwards.
3. Better scalability for Remote Apps. Instead of every user having a dedicated session host, or all users sharing the same and having individual sessions, we could assign every user applications and upon logon they get assigned to an already running container of that application for there own use. (Scheduling x instances using k8s and some scheduler (in best case also using k8s) assigns users to those instances/pods). Also guacamole or any other html5 based rdp client could be used to provide legacy applications in mostly browser based environments.
4. Shitty applications without CLI/API that need to be automated using something like Ranorex or AutoIt.
5. Esp. for shitty applications error messages may just appear on the gui instead of the cli, therefore for debugging purposes reproducing errors on GUI instances (even for otherwise seemingly fine running applications). Many programmers have the assumption, that if they program for windows, that there is always an interactive session and someone that could have a look at it. This assumption obviously often breaks when automating stuff (even the onboard sconfig tool on core server uses gui popups for confirmation dialogs and when invoked in ssh sessions just gets stuck)...
6. Having active directory, exchange (or any other windows server "feature") containers (I know that this is currently not a thing, but I hope for it) within k8s running on core windows servers (also allowing multiple tenants on the same hosts) and being able to spawn the management tools close to the running services e.g. in the same pod or in a container within the same cluster.
7. Oh and for developers UI testing

This issue has been open for 30 days with no updates.
@vrapolinario, please provide an update or close this issue.

[reisbel]

@vrapolinario Do you have plans to add this feature to the Windows Containers? When do you expect to release it?

[vrapolinario]

While we understand the appeal of the scenarios above, simply adding support for full desktop would make the image even bigger than it is today, and we've been trying to go the opposite direction.

For automated UI testing, we have a Windows image that supports that. And part of the feedback on that image is on the size as well. A full blown Windows container with UI support would be even bigger.

With the above said, our team is investigating how to address the above comments in future releases. We'll close this issue for now as we don't currently have anything to report (expect something in the next semester), but wanted to assure the team is investigating.
Thanks all for the feedback and please keep them coming.

[EighthMayer]

While we understand the appeal of the scenarios above, simply adding support for full desktop would make the image even bigger than it is today, and we've been trying to go the opposite direction.

Hello! I'm sorry if I'm being intrusive, but I believe that this position (at least as I understood it) makes no sense. If adding a useful feature means making bigger (separate) image, why the size becomes prioritized over said feature? Going to extreme, it is possible to make an image without anything whatsoever, and it's size will be very slim - why not take this route then?

Best regards,
Eighth

[vrapolinario]

Sorry I missed this comment. The issue here is the image composition and my previous comment is that we're exploring a way to provide customers with a smaller image size while allowing the option to add new capabilities later. We don't have a timeline on this investigation but we for sure take this feedback into account.

[zdyang]

We are diving into Remote Apps on the cloud. GUI in containers is critical for our deployment.

Look forward to this exciting feature.

[DECBuzz]

Maybe I don't understand containers, but why do we have to download a Windows image to use a container on Windows. I downloaded the same version on my system hoping Docker would realize starting with the host then run from their to build the changes in a new container. Does Docker have a FROM localhost?

[vrapolinario]

Hi @DECBuzz it might be useful for you to take a look at our documentation at http://aka.ms/containers.
Containers run based on a base image and Microsoft provides those base images (either Server Core, Nano Server, Windows, or Server depending on your need). These images have the base OS of the container. The host in this case, different from VMs, has to match the kernel, but all operations on the containers are (no punt intended) contained to environment. Let me know if that answers your question.

[naikrovek]

I'm very curious how much the container images would inflate with RDP added. Maybe if a version of each image without RDP and a version with RDP would make everyone happy. And, maybe the RDP version could just be a layer on top of the standard images.

Windows containers that support RDP would be an absolute good in my world. There are a lot of things that would be made much easier if this were a reality.

[agowa]

@naikrovek: RDP is already in the container image. It is restricted because of licensing. There are articles on how to "reenable" it. But for obvious reasons that's not something that you want to explain in a licensing audit, nor what you want to run in production.