xpra icon
Bug tracker and wiki

Version 21 (modified by Antoine Martin, 4 months ago) (diff)

--

http://xpra.org/icons/docker.png

Getting Started : Xpra + Docker


The information below has not been verified by xpra.org, use at your own risk.


Rationale

Xpra and docker can be used to isolate GUI applications from unix user accounts.

Depending on chosen setup, regular unix applications can have full access to all the files in the user's home directory.

For example, it can be used to constrain a web browser (or a proprietary application like Skype) to the resource it really needs to run and no more. The applications segregated in this way have a very restricted view of the system they run on.

Resources

  • Docker
  • x11docker can run GUI applications in docker images using xpra. It has no dependencies inside of docker images.
  • OZ doesn't use Docker but runs applications in containers and hooks them up to X11 using xpra.
  • Subuser tries to wrap the solution to make it more easily accessible - the 0.3 release adds XPRA support.
  • https://github.com/rogaha/docker-desktop is a working showcase for combining docker and Xpra for the desktop - using Xephyr to forward a whole desktop, which is a little odd since one of the major benefits of xpra is rootless applications (the version numbers they refer to are confusing too)
  • https://github.com/retog/docker-x11-xpra is a base image to build dockerize application for xpra access, the image itself provides minimal tools suitable for testing and demo (xeyes, xterm).

Setup

Setup with xpra on host only

Using x11docker on host, you can run GUI applications in docker images like in this example: x11docker --xpra x11docker/lxde pcmanfm

Setup with xpra on host and in docker image

If you are running CentOS, see here: wiki/Usage/Docker/CentOS for installation instructions.


Sockets Access

The xpra client needs to connect to the xpra server running inside the docker container. To do so, you can:

  • use a TCP socket or run an SSH server in the container - neither are very practical
  • share the xpra socket directory between the host and the container. To do this you have multiple options:
    • bind mount the directory containing the socket (.xpra or /tmp usually)
    • use the socket-dir option at either end to point to the same location
    • create symlinks to individual sockets, but this can get messy very quickly

By default, Xpra uses the hostname as part of the unix domain socket name. If the hostname is different inside the container, you will need one of those workarounds:

  • specify the socket filename to use explicitly with --bind=/path/to/socketname
  • symlink or bind mount the server's unix domain socket if that's what you want to use to connect
  • you can also connect to a specific unix domain socket by path using:
    xpra attach socket:/path/to/yourcontainers/socket
    

mmap

In order to be able to use mmap acceleration, the server expects to find the mmap file in the exact same path that the client used to create it. So you must ensure that the path to the mmap file (by default found in $TMPDIR) is the same on the host and in the container. (again, bind mounting a directory solves this problem)

Alternatively, you can also specify the absolute path to the mmap file:

xpra attach --mmap=/path/to/desired/mmapfile