如何在Linux Docker容器中运行GUI应用程序?
是否有任何图像设置vncserver或其他东西,以便您可以-例如-在Firefox周围添加额外的加速沙箱?
如何在Linux Docker容器中运行GUI应用程序?
是否有任何图像设置vncserver或其他东西,以便您可以-例如-在Firefox周围添加额外的加速沙箱?
当前回答
虽然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.
其他回答
根据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文件。
OSX
Jürgen Weigert有最好的答案,在Ubuntu上为我工作,然而在OSX上,docker运行在VirtualBox内部,所以解决方案没有更多的工作就不能工作。
我让它和这些额外的配料一起工作:
Xquartz (OSX不再随X11服务器发货) 使用socat进行Socket转发 Bash脚本启动容器
我很感激用户的评论来改善OSX的这个答案,我不确定套接字转发X是否安全,但我的预期用途是只在本地运行docker容器。
此外,该脚本有点脆弱,因为它不容易获得机器的IP地址,因为它是在我们的本地无线,所以它总是一些随机的IP。
我用来启动容器的BASH脚本:
#!/usr/bin/env bash
CONTAINER=py3:2016-03-23-rc3
COMMAND=/bin/bash
NIC=en0
# Grab the ip address of this box
IPADDR=$(ifconfig $NIC | grep "inet " | awk '{print $2}')
DISP_NUM=$(jot -r 1 100 200) # random display number between 100 and 200
PORT_NUM=$((6000 + DISP_NUM)) # so multiple instances of the container won't interfer with eachother
socat TCP-LISTEN:${PORT_NUM},reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\" 2>&1 > /dev/null &
XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth.$USER.$$
touch $XAUTH
xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
docker run \
-it \
--rm \
--user=$USER \
--workdir="/Users/$USER" \
-v "/Users/$USER:/home/$USER:rw" \
-v $XSOCK:$XSOCK:rw \
-v $XAUTH:$XAUTH:rw \
-e DISPLAY=$IPADDR:$DISP_NUM \
-e XAUTHORITY=$XAUTH \
$CONTAINER \
$COMMAND
rm -f $XAUTH
kill %1 # kill the socat job launched above
我能够让xeyes和matplotlib使用这种方法工作。
Windows 7 +。
在Windows 7+上使用MobaXterm更容易一些:
为windows安装MobaXterm 开始MobaXterm 配置X服务器:“设置”—“> X11 (tab)”—“> X11远程访问”设置为“full” 使用这个BASH脚本启动容器
run_docker.bash:
#!/usr/bin/env bash
CONTAINER=py3:2016-03-23-rc3
COMMAND=/bin/bash
DISPLAY="$(hostname):0"
USER=$(whoami)
docker run \
-it \
--rm \
--user=$USER \
--workdir="/home/$USER" \
-v "/c/Users/$USER:/home/$USER:rw" \
-e DISPLAY \
$CONTAINER \
$COMMAND
这里有一个轻量级的解决方案,可以避免在容器上安装任何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
我来晚了,但对于不想走XQuartz道路的Mac用户,这里有一个工作示例,它使用Xvfb和VNC使用桌面环境(xfce)构建Fedora映像。这很简单,也很有效:
https://github.com/ddual/docker_recipes#fedora-with-an-x-window-system https://github.com/ddual/docker_recipes/tree/master/fedora_gui
在Mac上,您可以使用屏幕共享(默认)应用程序访问它,连接到localhost:5901。
Dockerfile:
FROM fedora
USER root
# Set root password, so I know it for the future
RUN echo "root:password123" | chpasswd
# Install Java, Open SSL, etc.
RUN dnf update -y --setopt=deltarpm=false \
&& dnf install -y --setopt=deltarpm=false \
openssl.x86_64 \
java-1.8.0-openjdk.x86_64 \
xorg-x11-server-Xvfb \
x11vnc \
firefox \
@xfce-desktop-environment \
&& dnf clean all
# Create developer user (password: password123, uid: 11111)
RUN useradd -u 11111 -g users -d /home/developer -s /bin/bash -p $(echo password123 | openssl passwd -1 -stdin) developer
# Copy startup script over to the developer home
COPY start-vnc.sh /home/developer/start-vnc.sh
RUN chmod 700 /home/developer/start-vnc.sh
RUN chown developer.users /home/developer/start-vnc.sh
# Expose VNC, SSH
EXPOSE 5901 22
# Set up VNC Password and DisplayEnvVar to point to Display1Screen0
USER developer
ENV DISPLAY :1.0
RUN mkdir ~/.x11vnc
RUN x11vnc -storepasswd letmein ~/.x11vnc/passwd
WORKDIR /home/developer
CMD ["/home/developer/start-vnc.sh"]
start-vnc.sh
#!/bin/sh
Xvfb :1 -screen 0 1024x768x24 &
sleep 5
x11vnc -noxdamage -many -display :1 -rfbport 5901 -rfbauth ~/.x11vnc/passwd -bg
sleep 2
xfce4-session &
bash
# while true; do sleep 1000; done
如果需要,请查看链接的自述文件以获得构建和运行命令。
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/