Docker比较常用的场景是『运行无界面的后台服务』或者『运行Web服务』。不过有时出于个人的喜好或特定的需求，我们会希望在Docker中运行带图形界面的应用程序。
将容器中的图形界面展示到外部的一般性思路：
目前Unix/Linux比较主流的图形界面服务是X11，而X11服务的图形显示方式实际上是一种Client/Server模式，在服务端和客户端之间，X11通过『DISPLAY』环境变量来指定将图形显示到何处。如下面的流程所示，请注意服务端与客户端的位置，服务端是用于提供显示信息的。
[应用程序]->[X11客户端]->[X11服务端]->[显示屏幕]
DISPLAY的格式是『unix:端口』或『主机名:端口』，前一种格式表示使用本地的unix套接字，后一种表示使用tcp套接字。
默认情况下，X11的服务端会监听本地的『unit:0』端口，而DISPLAY的默认值为『:0』，这实际上是『unit:0』的简写。因此如果在Linux的控制台启动一个图形程序，它就会出现在当前主机的显示屏幕中。
基于这个原理，将Docker中的GUI程序显示到外面，就是通过某种方式把X11的客户端的内容从容器里面传递出来。基本的思路无非有两种：
通过SSH连接或远程控制软件，最终通过tcp套接字将数据发送出来
让容器和主机共享X11的unix套接字，直接将数据发送出来
从应用场景上划分，又可以分成两类情况：『运行本地的GUI程序』和『运行远程服务器上的GUI程序』。这两类情况在操作上很相似，但前者可以使用unix套接字，而后者必然要使用tcp套接字转发，原理上有很大差别。先说本地运行GUI程序的情况。
本地运行GUI程序的情况
运行方法：
$ docker run -d \
-v /etc/localtime:/etc/localtime:ro
-v /tmp/.X11-unix:/tmp/.X11-unix
-e DISPLAY=unix$DISPLAY
-v $HOME/slides:/root/slides
-e GDK_SCALE
-e GDK_DPI_SCALE
–name test
test:latest
其中的『-v /tmp/.X11-unix:/tmp/.X11-unix』参数就是将主机上X11的unix套接字共享到了容器里面。因为每个unix套接字实际上就是系统/tmp/.X11-unix目录下面依据套接字编号命名的一个特殊文件。
命令执行完，程序并没有启动。
这是由于X11服务默认只允许『来自本地的用户』启动的图形程序将图形显示在当前屏幕上。
解决的办法很简单，允许所有用户访问X11服务即可。这个事情可以用xhost命令完成。
$ sudo apt-get install x11-xserver-utils
$ xhost +
参数『+』表示允许任意来源的用户。
现在再次运行前面的docker run命令，就会看到程序启动起来了，速度相当快。由于是直接共享了X11的unix套接字，在效率上与运行安装在主机上的程序基本没有差异。
在远程服务器上用Docker运行GUI程序的情况。
这种情况多出现在将Docker作为产品测试环境使用的场景。利用Docker用后既消除的特点，能够快速的为每次测试提供干净的上下文环境。有时为了在非Linux系统中使用Linux的图形化软件，也可以通过远程Docker运行的方法实现。
此时，整个数据连接实际就变成了这样的：
[应用程序]->[X11客户端]->[SSH服务端]->[SSH客户端]->[X11服务端]->[显示屏幕]
这种情况实际上已经演化成为了通过tcp套接字转发的X11连接，只不过用户并没有直接使用SSH连接到容器里面的tcp端口上，而是连接到了远程主机。相应的X11数据先从容器传递到了主机，再通过SSH通过传递到了用户的电脑上。
这就必须有要求用于展示的用后电脑安装有X11服务，大多数的Linux系统默认就具备了，Mac系统可以安装XQuartz软件，Windows则可以使用Xming等第三方X11服务端实现。
首先将本地的X11服务运行起来。
其次，当用户使用SSH连接运行程序的服务器时，应该开启SSH的『X11-Forwarding』功能。具体来说，有两个注意点。
1）检测服务器上的/etc/ssh/sshd_config文件，是否已经有『X11Forwarding yes』这样的配置，如果没有则需要加上。
2）当连接到服务器时，应该在ssh命令后面加上-X参数，表示使用X11-Forwarding特性。
$ ssh -X @
登陆上去后运行刚才的docker run命令，并不能看到LibreOffice运行起来的迹象。通过log发现错误还是『Failed to open display』。在前面已经说过，对于远程连接运行GUI的情况，必然要换成tcp套接字的X11转发方式。而命令中的『-v /tmp/.X11-unix:/tmp/.X11-unix』参数仅仅是共享了unix套接字。那么怎样才能换成tcp套接字呢？需要修改两个地方：
1）首先为容器里面设置的环境变量『DISPLAY』，不能是『unix$DISPLAY』了
2）其次共享unix套接字可以不必了，而是要用『–net=host』让容器内的网络环境与主机共享
DISPLAY改成什么呢？首先要看SSH登陆后得到的系统DISPLAY变量值，我这里看到的是『localhost:10.0』，主机的localhost:10.0到了容器里面就要变成0.0.0.0:10.0。原因不解释了，这个是Docker默认添加的映射。
因此DISPLAY的值应该赋予『0.0.0.0:10.0』。可以简写为『:10.0』，X11会先去找unix:10.0，发现没有那个套接字文件，然后就会去试0.0.0.0:10.0。结果是一样的。修改过后的启动命令变成了：
$ docker run -d \
-v /etc/localtime:/etc/localtime:ro \
–net=host \
-e DISPLAY=:10.0 \
-v $HOME/slides:/root/slides \
-e GDK_SCALE \
-e GDK_DPI_SCALE \
–name test \
test
再次运行这个镜像，然而，依旧没有看到程序界面。查看Docker logs，这次的错误信息是：
『X11 connection rejected because of wrong authentication』。
这是因为在使用SSH通道转发X11时，会生成一个随机的授权cookie，存放在服务器的Xauthority文件中。这个cookie会在每次X11客户端发送数据时被用到。我们使用了『–net=host』参数后，容器中的X11客户端将直接通过tcp套接字与外部通信，然而容器里面并没有这个授权文件。因此我需要加上参数『-v $HOME/.Xauthority:/root/.Xauthority』把授权文件也放到容器里面。此外，启动命令中的两个GDK开头的环境变量在服务器端的Ubuntu上是不存在的，因此也可以删掉。
现在我们得到了最终的启动命令：
$ docker run -d \
-v /etc/localtime:/etc/localtime:ro \
–net=host \
-e DISPLAY=:10.0 \
-v $HOME/slides:/root/slides \
-v $HOME/.Xauthority:/root/.Xauthority \
–name test \
test
执行这个命令后，就看到程序已经在本地电脑的显示器上运行起来啦！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
