我正在尝试构建一个简单的容器,该容器将允许用户将目录文件路径传递到主机上应存在的可执行文件。
我希望此方法具有一定的灵活性,如果用户未指定目录文件路径,它将使用默认路径。根据我的研究,我需要在运行时使用ARG并可能使用-e flag。让我们通过这个简单的Dockerfile来看一个例子。
FROM ubuntu:latest
#Assign the default value
ARG DIRHOME=/opt/docker/q
#if -e has not been set the use default DIRHOME
ADD $DIRHOME /q
Dockerfile驻留在我将运行的文件夹/ opt / docker中
docker build --build-arg DIRHOME=/q .
这一切都成功运行,但是如您所见,我一直在使用默认值。用户是否可以在运行时将其文件路径传递给q可执行文件以覆盖DIRHOME变量?如下
docker run -e "QHOME=/user1/lib/q" <container id>
我认为这是与构建上下文有关的问题,因此,如果我在/ opt / docker中运行我的Dockerfile,则它将其视为根,并且无法找到路径/ user1 / lib / q。任何潜在的解决方法?
答案 0 :(得分:1)
运行docker构建时,您从docker映像内的DIRHOME
复制文件。因此DIRHOME
在构建后并没有真正的用途。将容器内的路径设置为环境变量更为合理:
ENV qpath /q
ADD /opt/docker/q $qpath
然后,当您尝试使用docker run
运行映像时,将数据从主机传递到容器的标准方法是使用卷。那么您可以使用环境变量:
docker run -v /user1/lib/q:/q image
答案 1 :(得分:1)
通常,这里有用的模式是在Docker容器内使用固定路径,并让管理员使用docker run -v
选项将需要挂载的任何内容挂载到该容器中。绝对不需要主机路径和容器路径匹配。路径名称可以是Dockerfile中的固定属性,不是您特别希望通过ARG进行配置的名称。
例如,如果这是某种安全扫描程序,则管理员可以运行
sudo docker run \
-v $GOPATH/bin:/scan \
myscanner \
myprogram
扫描仪将查看/scan/myprogram
;但在主机上为$GOPATH/bin/myprogram
。
如果程序的主要目标是处理主机上的文件,请考虑将Docker 作为设计目标使处理主机文件变得困难;除了此卷映射问题之外,如果您想从Docker内部运行此作业,还会出现文件系统权限反复出现的问题以及更多的问题。考虑使用一些更简单的打包机制(分发静态链接的二进制文件,Python虚拟环境,RPM或dpkg软件包等)。作为用户,我宁愿运行
myscanner $(which myprogram)