如何在Docker文件中使用“ADD”命令包含Docker构建上下文之外的文件?

从Docker文档中:

路径必须位于生成的上下文中;您不能添加../something/something,因为docker构建的第一步是将上下文目录(和子目录)发送到docker守护进程。

我不想重组我的整个项目,只是为了在这件事上适应Docker。我想将所有Docker文件保存在同一个子目录中。

此外,Docker似乎还不支持符号链接:Dockerfile ADD命令不支持主机#1676上的符号链接。

我唯一能想到的另一件事是包含一个预构建步骤,将文件复制到Docker构建上下文中(并配置我的版本控制以忽略这些文件)。还有比这更好的解决方法吗?


当前回答

我花了很长时间试图找出一个好的模式,以及如何更好地解释这个特性支持的情况。我意识到最好的解释方法如下。。。

Dockerfile:将只看到其自身相对路径下的文件上下文:“空间”中的一个位置,您要共享的文件和Dockerfile将被复制到该位置

因此,尽管如此,这里有一个Dockerfile的示例,它需要重用一个名为start.sh的文件

Dockerfile文件

它将始终从其相对路径加载,将其当前目录作为指定路径的本地引用。

COPY start.sh /runtime/start.sh

文件夹

考虑到这个想法,我们可以考虑为Dockerfile创建多个副本来构建特定的东西,但它们都需要访问start.sh。

./all-services/
   /start.sh
   /service-X/Dockerfile
   /service-Y/Dockerfile
   /service-Z/Dockerfile
./docker-compose.yaml

考虑到这个结构和上面的文件,这里有一个docker-compose.yml

码头组合.yaml

在本例中,共享上下文目录是运行时目录。这里的思维模式是一样的,认为这个目录下的所有文件都被移到了所谓的上下文中。同样,只需指定要复制到同一目录的Dockerfile。可以使用dockerfile指定。主要内容所在的目录是要设置的实际上下文。

docker-compose.yml如下

version: "3.3"
services:
  
  service-A
    build:
      context: ./all-service
      dockerfile: ./service-A/Dockerfile

  service-B
    build:
      context: ./all-service
      dockerfile: ./service-B/Dockerfile

  service-C
    build:
      context: ./all-service
      dockerfile: ./service-C/Dockerfile

所有服务都被设置为上下文,共享文件start.sh以及每个Dockerfile指定的Dockerfile都被复制到那里。每个人都可以按照自己的方式构建,共享开始文件!

其他回答

解决此问题的最佳方法是使用-f独立于构建上下文指定Dockerfile。

例如,此命令将赋予ADD命令访问当前目录中任何内容的权限。

docker build -f docker-files/Dockerfile .

更新:Docker现在允许在构建上下文之外使用Dockerfile(已在18.03.0-ce中修复)

docker build -f ../Dockerfile .

我在一个项目和一些数据文件中遇到了同样的问题,由于HIPAA的原因,我无法在回购上下文中移动这些文件。我最终使用了2个Dockerfile。一个构建主应用程序,而不需要我在容器外部所需的东西,并将其发布到内部存储库。然后,第二个dockerfile提取该图像并添加数据,然后创建一个新图像,然后将其部署并永远不会存储在任何地方。不太理想,但它对我将敏感信息排除在回购之外的目的起到了作用。

如果您阅读第2745期中的讨论,不仅docker可能永远不支持符号链接,他们也可能永远不会支持在您的上下文之外添加文件。这似乎是一种设计理念,即进入docker构建的文件应该明确地成为其上下文的一部分,或者来自一个URL,在该URL中,它可能也会以固定版本部署,这样构建就可以用docker容器附带的公知URL或文件重复。

我更喜欢从版本控制的源代码构建,即docker构建-t东西http://my.git.org/repo-否则我会在随机的地方用随机文件进行构建。从根本上说,不是……——斯文·多维迪特,多克公司

只是我的看法,但我认为您应该进行重组,以分离代码和docker存储库。这样,容器可以是通用的,并在运行时而不是构建时引入任何版本的代码。

或者,使用docker作为基本的代码部署工件,然后将dockerfile放在代码存储库的根目录中。如果您这样做,那么使用父docker容器获取更一般的系统级详细信息和子容器获取特定于您的代码的设置可能是有意义的。

一个简单的解决方法可能是在运行该卷并以这种方式访问文件时,简单地将其装载(使用-v或--mount标志)到容器中。

例子:

docker run -v /path/to/file/on/host:/desired/path/to/file/in/container/ image_name

有关详细信息,请参阅:https://docs.docker.com/storage/volumes/

我经常发现自己为此使用--buildarg选项。例如,在Dockerfile中放入以下内容后:

ARG SSH_KEY
RUN echo "$SSH_KEY" > /root/.ssh/id_rsa

你可以这样做:

docker build -t some-app --build-arg SSH_KEY="$(cat ~/file/outside/build/context/id_rsa)" .

但请注意Docker文档中的以下警告:

警告:不建议使用构建时间变量来传递密钥,如github密钥、用户凭据等。使用docker history命令,映像的任何用户都可以看到构建时间变量值。