So… the story so far…
As regular readers of this blog will know, I happen to be of the opinion that we should package more of OUr software using Docker containers, for a couple of reasons (at least):
- we control the software environment, including all required dependencies, and avoiding any conflicts with preinstalled software;
- the same image can be used to launch containers locally or remotely.
I also happen to believe that we should deliver all UIs through a browser. Taken together with the containerised services, this means that students just need a browser to run course related software. Which could be on their phone, for all I care.
I keep umming and ahhing about electron apps. If the apps that are electron wrapped are also packaged so that they can also be run as a service and accessed via a browser too, that’s fine, I guess…
There are some cases in which this won’t work. For example, not all applications we may want to distribute come with an HTML UI, but instead may be native applications (which is an issue becuase we are supposed to be platform independent), or cross platform applications that use native widgets (for example, Java apps, or electron apps).
One way round this is to run a desktop application in container and then expose its UI using X11, (aka the X Window System), although this looks like it may be on the way out in favour of other windowing alternatives, such as Wayland… See also Chrome OS Is Working To Remove The Last Of Its X11 Dependencies. (I am so out of my depth here!)
Although X11 does provide a way of rendering windows created on a remote (or containerised guest) system using native windows on your own desktop, a downside is that it requires X11 support on your own machine; and I haven’t found a cross-platform one that looks to be a popular de facto standard.
Another approach is to use VNC, in which the remote (or guest) system sends a compressed rendered version of the desktop back to your machine, which then renders it. (See X11 on Raspberry Pi – remote login from your laptop for a discussion of some of the similarities and differences between X11 and VNC.)
Note to self – one of the issues I’ve had with VNC is the low screen resolution of the rendered desktop… but is that just because I used a default low resolution in the remote VNC server? Another issue I’ve had in the past with novnc, a VNC client that renders desktops using HTML via a browser window, relates to video and audio support… Video is okay, but VNC doesn’t do audio?
Earlier today, I came across x11docker, that claims to run GUI applications and desktops in docker (though on Windows and Linux desktops only. The idea is that you “just type
x11docker IMAGENAME [COMMAND]” to launch a container and an X11 connection is made that allows the application to be rendered in a native X11 window. You can find a recipe for doing something similar on a Mac here: Running GUI’s with Docker on Mac OS X.
But that all seems a little fiddly, not least because of a dependency on an X11 client which might need to be separately installed. However, it seems that we can use another Docker container —
JAremko/docker-x11-bridge — running xpra (“an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens”) as bridge that can connect to an X11 serving docker container and render the desktop in a browser.
For example, Jess Frazelle’s collection of Dockerfiles containerise all manner of desktop applications (though I couldn’t get them all to work over X11; maybe I wasn’t starting the containers correctly?). I can get them running, in my browser, by starting the bridge:
docker run -d \ --name x11-bridge \ -e MODE="tcp" \ -e XPRA_HTML="yes" \ -e DISPLAY=:14 \ -p 10000:10000 \ jare/x11-bridge
and then firing up a couple of applications:
docker run -d --rm \ --name firefox \ --volumes-from x11-bridge \ -e DISPLAY=:14 \ jess/firefox docker run -d --rm \ --name gimp \ --volumes-from x11-bridge \ -e DISPLAY=:14 \ jess/gimp #Housekeeping #docker kill gimp firefox #docker rm gimp firefox #docker rmi jess/gimp jess/firefox
Another approach is to use VNC within a container, an approach I’ve used with this DIT4C Inspired RobotLab Container/ (The DIT4C container is quite old now; perhaps there’s something more recent I should use? In particular, audio support was lacking.)
It’s been a while since I had a look around for good examples of novnc containers, but this Collection of Docker images with headless VNC environments could be a useful start:
Desktop environment Xfce4 or IceWM
VNC-Server (default VNC port 5901)
noVNC – HTML5 VNC client (default http port 6901)
The containers also allow screen resolution and colour depth to be set via environment variables. The demo seems to work (without audio) using novnc in a browser, and I can connect using TigerVNC to the VNC port, though again, without audio support.
Audio is a pain. On a Linux machine, you can mount an audio device when you start a novnc container (eg fcwu/docker-ubuntu-vnc-desktop) but I’m not sure if that works on a Mac? Or how it’d work on Windows?) That said, a few years ago I did find a recipe for getting audio out of a remote container that did seem to work — More Docker Doodlings – Accessing GUI Apps Via a Browser from a Container Using Guacamole — although it seems to be broken now (did the container format change in that period I wonder?). Is there a more recent (and robust) variant of this out there somewhere, I wonder?
Hmm… here’s another approach: using a remote desktop client. Microsoft produce RDP (Remote Desktop Protocol) clients for different platforms so that might provide a useful starting point.
This repo —
danielguerra69/firefox-rdp — builds on danielguerra69/dockergui (fork of this) and shows how to create a container running Firefox that can be accessed via RDP. If I run it:
docker run --rm -d --shm-size 1g -p 3389:3389 --name firefox danielguerra/firefox-rdp
I can create a connection using the Microsoft remote desktop client at the address
localhost:3389, login with my Mac credentials, and then use the application. Testing on Youtube shows that video and audio work too. So that’s promising…
docker kill firefox; docker rm firefox; docker rmi danielguerra/firefox-rdp.)
Hmmm… so maybe now we’re getting somewhere more recent. Eg danielguerra69/ubuntu-xrdp although this doesn’t render the desktop properly for me, and danielguerra69/alpine-xfce4-xrdp doesn’t play out the audio? Ah, well… I’ve wasted enough time on this for today…
5 thoughts on “Viewing Dockerised Desktops via an X11 Bridge, novnc and RDP, Sort of…”
Interestingly, a tiny patch to docker-ubuntu-vnc-desktop also allows using the –volumes-from approach for using it as a noVNC bridge. See https://github.com/fcwu/docker-ubuntu-vnc-desktop/issues/113
Thanks for the hint ;-)
Oooh, that’s really interesting… thanks for the tip off.
Would a similar bridge approach generalise to the XRDP solution, do you know?
I haven’t investigated the RDP containers you mentioned, but in principle, a container could run the X11 server and XRDP server, and export its X socket as a volume, allowing other containers to display X applications on its X server. However, plugging sound may not work, then (it that’s a requirement).
The folk I work with, if it doesn’t do everything, even if they only want certain things, they’ll claim it’s no good and will use that as a reason not to go with it… :-(
Here’s a demo of what it looks like, running Labtainers with a (slightly modified version of) DoroWu’s noVNC bridge : https://www-public.imtbs-tsp.eu/~berger_o/weblog/2019/04/15/labtainers-in-a-web-desktop-through-novnc-x11-proxy-full-docker-containers/
Comments are closed.