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

从Docker文档中:

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

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

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

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


当前回答

我想今年早些时候,buildx中添加了一个功能来实现这一点。

如果你有dockerfile 1.4+和buildx 0.8+,你可以这样做

docker buildx build --build-context othersource= ../something/something .

然后在docker文件中,可以使用from命令添加上下文

ADD –from=othersource . /stuff

查看此相关帖子https://www.docker.com/blog/dockerfiles-now-support-multiple-build-contexts/

其他回答

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

该行为由docker或podman用于向构建过程呈现文件的上下文目录提供。这里有一个很好的技巧,就是在构建指令期间将上下文dir更改为要向守护进程公开的目录的完整路径。例如:

docker build -t imageName:tag -f /path/to/the/Dockerfile /mysrc/path

使用/myrc/path代替。(当前目录),您将使用该目录作为上下文,因此构建过程可以看到该目录下的任何文件。在这个示例中,您将向docker守护进程公开整个/myrc/path树。当使用docker时,触发构建的用户ID必须具有从上下文目录递归读取任何单个目录或文件的权限。

如果您有/home/user/myCoolProject/Dockerfile,但希望将不在同一目录中的文件带到此容器构建上下文中,这可能非常有用。

这里有一个使用上下文dir构建的示例,但这次使用podman而不是docker。

让我们以Dockerfile为例,在Dockerfile中有一个COPY或ADD指令,它从项目外部的目录中复制文件,例如:

FROM myImage:tag
...
...
COPY /opt/externalFile ./
ADD /home/user/AnotherProject/anotherExternalFile ./
...

为了构建这个,使用位于/home/user/myCoolProject/Dockerfile中的容器文件,只需执行以下操作:

cd /home/user/myCoolProject
podman build -t imageName:tag -f Dockefile /

更改上下文目录的一些已知用例是在使用容器作为工具链来构建源代码时。例如:

podman build --platform linux/s390x -t myimage:mytag -f ./Dockerfile /tmp/mysrc

或者它可以是路径相关的,例如:

podman build --platform linux/s390x -t myimage:mytag -f ./Dockerfile ../../

另一个使用这次全局路径的示例:

FROM myImage:tag
...
...
COPY externalFile ./
ADD  AnotherProject ./
...

注意,现在Dockerfile命令层中省略了COPY和ADD的完整全局路径。在这种情况下,context目录必须相对于文件所在的位置,如果externalFile和AnotherProject都在/opt目录中,则用于构建它的context目录应为:

podman build -t imageName:tag -f ./Dockerfile /opt

在docker中将COPY或ADD与上下文目录一起使用时请注意:docker守护程序将尝试将上下文目录树上可见的所有文件“流式传输”到守护程序,这可能会降低构建速度。并要求用户具有上下文目录的递归权限。特别是在通过API使用构建时,这种行为的成本可能会更高。然而,使用podman,构建是即时进行的,不需要递归权限,这是因为podman不会枚举整个上下文目录,也不会使用客户端/服务器架构。当您使用不同的上下文目录来面对此类问题时,使用podman而不是docker来构建此类案例可能会更有趣。

一些参考文献:

https://docs.docker.com/engine/reference/commandline/build/https://docs.podman.io/en/latest/markdown/podman-build.1.html

正如GitHub问题中所描述的那样,构建实际上发生在/tmp/docker-12345中,因此相对路径如/相对添加/some文件是相对于/tmp/docker-12345的。因此,它将搜索/tmp/relative add/some文件,该文件也显示在错误消息中*

不允许包含来自构建目录之外的文件,因此这将导致“禁止路径”消息。"

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

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都被复制到那里。每个人都可以按照自己的方式构建,共享开始文件!

在我的例子中,Dockerfile就像一个包含占位符的模板一样编写,我使用配置文件将其替换为实际值。

所以我不能直接指定这个文件,而是像这样将其导入docker构建:

sed "s/%email_address%/$EMAIL_ADDRESS/;" ./Dockerfile | docker build -t katzda/bookings:latest . -f -;

但由于管道的原因,COPY命令无法工作。但上述方法通过-f(明确表示未提供文件)来解决问题。只执行-如果不使用-f标志,则不会提供上下文和Dockerfile,这是一个警告。