Asked  7 Months ago    Answers:  5   Viewed   101 times

How can you run GUI applications in a Docker container?

Are there any images that set up vncserver or something so that you can - for example - add an extra speedbump sandbox around say Firefox?



You can simply install a vncserver along with Firefox :)

I pushed an image, vnc/firefox, here: docker pull creack/firefox-vnc

The image has been made with this Dockerfile:

# Firefox over VNC
# VERSION               0.1
# DOCKER-VERSION        0.2

FROM    ubuntu:12.04
# Make sure the package repository is up to date
RUN     echo "deb precise main universe" > /etc/apt/sources.list
RUN     apt-get update

# Install vnc, xvfb in order to create a 'fake' display and firefox
RUN     apt-get install -y x11vnc xvfb firefox
RUN     mkdir ~/.vnc
# Setup a password
RUN     x11vnc -storepasswd 1234 ~/.vnc/passwd
# Autostart firefox (might not be the best way to do it, but it does the trick)
RUN     bash -c 'echo "firefox" >> /.bashrc'

This will create a Docker container running VNC with the password 1234:

For Docker version 18 or newer:

docker run -p 5900:5900 -e HOME=/ creack/firefox-vnc x11vnc -forever -usepw -create

For Docker version 1.3 or newer:

docker run -p 5900 -e HOME=/ creack/firefox-vnc x11vnc -forever -usepw -create

For Docker before version 1.3:

docker run -p 5900 creack/firefox-vnc x11vnc -forever -usepw -create
Tuesday, June 1, 2021
answered 7 Months ago

My conclusion is that the canonical way of doing this is to run X with a lightweight desktop environment such as LXDE on the Docker container. Then you can connect to it with a VNC client. Using a browser on the host is not possible.

For other options, see the other answers.

Friday, July 23, 2021
answered 5 Months ago

A container is basically a process. There is no technical issue with running 500 processes on a decent-sized Linux system, although they will have to share the CPU(s) and memory.

The cost of a container over a process is some extra kernel resources to manage namespaces, file systems and control groups, and some management structures inside the Docker daemon, particularly to handle stdout and stderr.

The namespaces are introduced to provide isolation, so that one container does not interfere with any others. If your groups of 5 containers form a unit that does not need this isolation then you can share the network namespace using --net=container. There is no feature at present to share cgroups, AFAIK.

What is wrong with what you suggest:

  • it is not "the Docker way". Which may not be important to you.
  • you have to maintain the scripting to get it to work, worry about process restart, etc., as opposed to using an orchestrator designed for the task
  • you will have to manage conflicts in the filesystem, e.g. two processes need different versions of a library, or they both write to the same output file
  • stdout and stderr will be intermingled for the five processes
Wednesday, July 28, 2021
answered 4 Months ago

The free version of TightVnc viewer (I have TightVnc Viewer 1.5.4 8/3/2011) build does not support this. What you need is RealVNC but VNC Enterprise Edition 4.2 or the Personal Edition. Unfortunately this is not free and you have to pay for a license.

From the RealVNC website [releasenote]

VNC Viewer: Full-screen mode can span monitors on a multi-monitor system.
Monday, August 9, 2021
answered 4 Months ago

Ok, here is the thing:

1) Log in to remote machine

2) Check which display was set with echo $DISPLAY

3) Run xauth list

4) Copy the line corresponding to your DISPLAY

5) Enter your docker container

6) xauth add <the line you copied>*

7) Set DISPLAY with export DISPLAY=<ip-to-host>:<no-of-display>

*so far so good right?

This was nothing new...however here is the twist: The line printed by xauth list for the login user looks something like this (in my case):

<hostname-of-machine>/unix:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>

Because i use the bridged docker setup, the X forwarding port is not listening locally, because the sshd is not running in the container. Change the line above to:

<ip-of-host>:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>

In essence: Remove the /unix part.

<ip-of-host> is the IP address where the sshd is running.

Set the DISPLAY variable as above.

So the error was that the DISPLAY name in the environment variable was not the "same" as the entry in the xauth list / .Xauthority file and the client could therefor not authenticate properly.

I switched back to an untrusted X11 forwarding setting.

The X11UseLocalhost no setting in the sshd_config file however is important, because the incomming connection will come from a "different" machine (the docker container).

Wednesday, August 11, 2021
answered 4 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :