在第一节中,我详细介绍了我使用的一些术语:
文档化图形应用程序: Docker容器从Docker映像中运行,该映像运行应用程序(传统上)使用x11 (或类似的)在主机上显示应用程序。更多细节在第二节。
在客户端上远程显示所需的软件包:例如,VNC服务器允许本地客户端的用户(例如安装了桌面Ubuntu 18.04的笔记本电脑)通过浏览器导航到特定的主机名和端口。
在这第二节中,我以gedit为例,给出了一个运行的常用方法的示例:
示例Dockerfile:
FROM ubuntu:18.04
RUN apt-get update && apt-get install -y gedit
CMD gedit示例Docker build命令:
docker build -t gedit:latest .示例Docker运行命令:
一次关闭(可能是一种有害的命令,小心使用):
xhost +local:docker随后:
docker run --rm --name=gedit -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix gedit:latest请注意:运行xhost +local:docker存在一些安全问题,因此要反转此运行的xhost -local:docker
子问题/好奇心:上面的内容将x11等安装到图像中。为了满足x11依赖关系,是否有任何方法可以使用所有这些依赖项和多个容器共享文件夹来拥有一个单独的映像?
在第三节中,我详细介绍了一个与我的问题相关的例子:
我想保持Dockerized如第2节中所解释的,它在客户端的笔记本电脑上运行良好,但它作为一个码头容器集群的一部分(例如,使用docker -组合),这样从第2节中的dockerfile构建的图像就不会被修改。
我希望包含一个额外的容器,其中包含所有所需的VNC和x11包,以便客户端能够远程运行应用程序。
发布于 2018-11-05 10:32:59
在没有x11缓冲区的情况下,无论是vnc、xvfb还是其他任何东西,您都不能在x11上运行程序。您将始终需要运行程序的系统上的x11库,否则根本无法工作。这类似于试图在系统上运行没有libc的C程序。
使用来自不同容器的带有卷的系统库是个坏主意,因为它使用相同的库创建了对两个容器的硬依赖,并且当两个系统都试图获取库上的锁以加载它时,很可能会在某个地方崩溃。
我认为,经过大量的调整,它应该是可行的,但是增加的复杂性是一个真正的足炮,并且创建了比应该存在的更多的依赖关系。
https://devops.stackexchange.com/questions/5330
复制相似问题