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

使用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)。

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

这里有一个轻量级的解决方案，可以避免在容器上安装任何X服务器，vnc服务器或sshd守护进程。它在简单中得到的好处，却在安全和隔离中失去了。

它假设您使用带有X11转发的ssh连接到主机。

在主机的sshd配置中添加该行

X11UseLocalhost no

因此，主机上转发的X服务器端口在所有接口上都是开放的(不仅仅是lo)，特别是在Docker虚拟接口docker0上。

容器在运行时需要访问. xauthority文件，以便连接到服务器。为此，我们定义了一个只读卷，指向主机上的主目录(可能不是一个明智的主意!)，并相应地设置XAUTHORITY变量。

docker run -v $HOME:/hosthome:ro -e XAUTHORITY=/hosthome/.Xauthority

这还不够，我们还必须从主机传递DISPLAY变量，但是用ip代替主机名:

-e DISPLAY=$(echo $DISPLAY | sed "s/^.*:/$(hostname -i):/")

我们可以定义一个别名:

 alias dockerX11run='docker run -v $HOME:/hosthome:ro -e XAUTHORITY=/hosthome/.Xauthority -e DISPLAY=$(echo $DISPLAY | sed "s/^.*:/$(hostname -i):/")'

然后像这样测试:

dockerX11run centos xeyes

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

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

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

根据Jürgen Weigert的回答，我有一些改进:

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_DIR=/tmp/.docker.xauth
XAUTH=$XAUTH_DIR/.xauth
mkdir -p $XAUTH_DIR && touch $XAUTH
xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
docker run -ti -v $XSOCK:$XSOCK -v $XAUTH_DIR:$XAUTH_DIR -e XAUTHORITY=$XAUTH xeyes

唯一的区别是它创建了一个目录$XAUTH_DIR，用于放置$XAUTH文件，并将$XAUTH_DIR目录而不是$XAUTH文件挂载到docker容器中。

这种方法的好处是你可以在/etc/rc.中写入命令在/tmp目录下创建一个名为$XAUTH_DIR的空文件夹，并将其模式更改为777。

tr '\n' '\000' < /etc/rc.local | sudo tee /etc/rc.local >/dev/null
sudo sed -i 's|\x00XAUTH_DIR=.*\x00\x00|\x00|' /etc/rc.local >/dev/null
tr '\000' '\n' < /etc/rc.local | sudo tee /etc/rc.local >/dev/null
sudo sed -i 's|^exit 0.*$|XAUTH_DIR=/tmp/.docker.xauth; rm -rf $XAUTH_DIR; install -m 777 -d $XAUTH_DIR\n\nexit 0|' /etc/rc.local

当系统重启时，在用户登录前，如果容器的重启策略为always, docker会自动挂载$XAUTH_DIR目录。用户登录后，可以在~/中写入命令。配置文件是创建$XAUTH文件，然后容器将自动使用这个$XAUTH文件。

tr '\n' '\000' < ~/.profile | sudo tee ~/.profile >/dev/null
sed -i 's|\x00XAUTH_DIR=.*-\x00|\x00|' ~/.profile
tr '\000' '\n' < ~/.profile | sudo tee ~/.profile >/dev/null
echo "XAUTH_DIR=/tmp/.docker.xauth; XAUTH=\$XAUTH_DIR/.xauth; touch \$XAUTH; xauth nlist \$DISPLAY | sed -e 's/^..../ffff/' | xauth -f \$XAUTH nmerge -" >> ~/.profile

毕竟，容器将在每次系统重新启动和用户登录时自动获取Xauthority文件。

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

使用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)。

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

上帝还有另一个解决办法。在容器中运行GUI应用程序，而不使用VNC, SSH和X11转发。这里也提到了。