对于使用Nvidia驱动程序的OpenGL渲染，请使用以下图像:

https://github.com/thewtex/docker-opengl-nvidia

对于其他OpenGL实现，确保映像具有与主机相同的实现。

虽然Jürgen Weigert的回答基本上涵盖了这个解决方案，但一开始我并不清楚那里描述的是什么。所以我要加上我的看法，以防有人需要澄清。

首先，相关文档是X安全性手册页。

许多在线资料都建议只挂载X11 unix套接字和~/。Xauthority文件放入容器。这些解决方案通常靠运气工作，不需要真正理解为什么，例如容器用户最终与用户拥有相同的UID，因此不需要魔术键授权。

首先，Xauthority文件的模式为0600，因此容器用户将无法读取它，除非它具有相同的UID。

即使您将文件复制到容器中，并更改了所有权，仍然存在另一个问题。如果在主机和容器上使用相同的Xauthority文件运行xauth list，您将看到列出了不同的条目。这是因为xauth根据运行位置筛选条目。

容器中的X客户端(即GUI应用程序)的行为将与xauth相同。换句话说，它看不到用户桌面上运行的X会话的神奇cookie。相反，它会看到您之前打开的所有“远程”X会话的条目(如下所述)。

所以，你需要做的是添加一个新的条目，包含容器的主机名和与主机cookie相同的十六进制键(即在你的桌面上运行的X会话)，例如:

containerhostname/unix:0   MIT-MAGIC-COOKIE-1   <shared hex key>

问题是cookie必须在容器中添加xauth add:

touch ~/.Xauthority
xauth add containerhostname/unix:0 . <shared hex key>

否则，xauth将以一种只能在容器外部看到的方式标记它。

该命令的格式为:

xauth add hostname/$DISPLAY protocol hexkey

在哪里。表示MIT-MAGIC-COOKIE-1协议。

注意:不需要复制或绑定挂载. xauthority到容器中。只需创建一个空白文件，如图所示，并添加cookie。

Jürgen Weigert的答案通过使用FamilyWild连接类型在主机上创建一个新的权限文件并将其复制到容器中来解决这个问题。注意，它首先从~/中提取当前X会话的十六进制键。使用xauth nlist。

所以基本步骤是:

提取用户当前X会话的cookie的十六进制键。 在容器中创建一个新的Xauthority文件，使用容器主机名和共享的十六进制密钥(或创建一个具有FamilyWild连接类型的cookie)。

我承认我不是很了解FamilyWild是如何工作的，也不是很了解xauth或X客户机是如何根据运行位置从Xauthority文件中过滤条目的。欢迎提供这方面的更多信息。

如果你想要分发Docker应用，你需要一个启动脚本来运行容器，该容器为用户的X会话获取十六进制密钥，并以前面解释的两种方式之一将其导入容器。

它还有助于理解授权过程的机制:

在容器中运行的X客户机(即GUI应用程序)在Xauthority文件中查找与容器的主机名和$DISPLAY值匹配的cookie条目。 如果找到匹配的条目，X客户端将其与授权请求一起通过/tmp/. xml目录中的适当套接字传递给X服务器。X11-unix目录挂载在容器中。

注意:X11 Unix套接字仍然需要挂载在容器中，否则容器将没有到X服务器的路由。出于安全原因，大多数发行版默认禁用对X服务器的TCP访问。

为了获得更多信息，并更好地掌握X客户端/服务器关系是如何工作的，查看SSH X转发的示例案例也很有帮助:

The SSH server running on a remote machine emulates its own X server. It sets the value of $DISPLAY in the SSH session to point to its own X server. It uses xauth to create a new cookie for the remote host, and adds it to the Xauthority files for both the local and remote users. When GUI apps are started, they talk to SSH's emulated X server. The SSH server forwards this data back to the SSH client on your local desktop. The local SSH client sends the data to the X server session running on your desktop, as if the SSH client was actually an X client (i.e. GUI app). The X server uses the received data to render the GUI on your desktop. At the start of this exchange, the remote X client also sends an authorization request, using the cookie that was just created. The local X server compares it with its local copy.

Xauthority becomes an issue with newer systems. I can either discard any protection with xhost + before running my docker containers, or I can pass in a well prepared Xauthority file. Typical Xauthority files are hostname specific. With docker, each container can have a different host name (set with docker run -h), but even setting the hostname of the container identical to the host system did not help in my case. xeyes (I like this example) simply would ignore the magic cookie and pass no credentials to the server. Hence we get an error message 'No protocol specified Cannot open display'

Xauthority文件的编写方式可以使主机名无关紧要。 我们需要将认证家族设置为“FamilyWild”。我不确定xauth是否有合适的命令行，所以这里有一个结合xauth和sed的示例。我们需要改变nlist输出的前16位。FamilyWild的值为65535或0xffff。

docker build -t xeyes - << __EOF__
FROM debian
RUN apt-get update
RUN apt-get install -qqy x11-apps
ENV DISPLAY :0
CMD xeyes
__EOF__
XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth
xauth nlist :0 | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
docker run -ti -v $XSOCK:$XSOCK -v $XAUTH:$XAUTH -e XAUTHORITY=$XAUTH xeyes

如果您已经构建了映像，还有另一个答案:

使用sudo调用docker (如何修复docker:获得许可被拒绝的问题) 在主机和容器共享之间共享相同的USER & home & passwd (提示:使用用户id代替用户名) 驱动相关库的dev文件夹工作得很好 加上X11向前。

    docker run --name=CONTAINER_NAME --network=host --privileged \
      -v /dev:/dev \
      -v `echo ~`:/home/${USER} \
      -p 8080:80 \
      --user=`id -u ${USER}` \
      --env="DISPLAY" \
      --volume="/etc/group:/etc/group:ro" \
      --volume="/etc/passwd:/etc/passwd:ro" \
      --volume="/etc/shadow:/etc/shadow:ro" \
      --volume="/etc/sudoers.d:/etc/sudoers.d:ro" \
      --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \
      -it REPO:TAG /bin/bash

你可能会问，如果这么多东西都是一样的，那么使用docker还有什么意义呢?嗯，我能想到的一个原因是克服软件包依赖的地狱(https://en.wikipedia.org/wiki/Dependency_hell)。

所以我认为这种用法更适合开发人员。

http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/上给出的解决方案似乎是在容器内启动GUI应用程序的一种简单方法(我尝试在ubuntu 14.04上使用firefox)，但我发现需要对作者发布的解决方案进行一个小小的额外更改。

具体来说，对于运行容器，作者已经提到:

    docker run -ti --rm \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    firefox

但我发现(根据同一网站上的一个特定评论)有两个额外的选项

    -v $HOME/.Xauthority:$HOME/.Xauthority

and

    -net=host 

需要在运行容器时指定，以便firefox正常工作:

    docker run -ti --rm \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -v $HOME/.Xauthority:$HOME/.Xauthority \
    -net=host \
    firefox

我已经创建了一个docker映像，其中包含该页面的信息和这些额外的发现:https://hub.docker.com/r/amanral/ubuntu-firefox/

这不是轻量级的，但是一个很好的解决方案，使docker特性与完整的桌面虚拟化相同。Ubuntu和CentOS的Xfce4或IceWM都可以工作，noVNC选项可以通过浏览器轻松访问。

https://github.com/ConSol/docker-headless-vnc-container

它运行noVNC以及tigerVNC的vncserver。然后它为给定的窗口管理器调用startx。此外，libss_wrapper . dll。用于模拟用户的密码管理。