如何在Docker文件中使用“ADD”命令包含Docker构建上下文之外的文件？
从Docker文档中：
路径必须位于生成的上下文中；您不能添加../something/something，因为docker构建的第一步是将上下文目录（和子目录）发送到docker守护进程。
我不想重组我的整个项目，只是为了在这件事上适应Docker。我想将所有Docker文件保存在同一个子目录中。
此外，Docker似乎还不支持符号链接：Dockerfile ADD命令不支持主机#1676上的符号链接。
我唯一能想到的另一件事是包含一个预构建步骤，将文件复制到Docker构建上下文中（并配置我的版本控制以忽略这些文件）。还有比这更好的解决方法吗？
当前回答
一种快速而肮脏的方法是将构建上下文设置为所需的多个级别，但这可能会产生后果。如果您使用的是这样的微服务架构：
./Code/Repo1
./Code/Repo2
...
您可以将构建上下文设置为父代码目录，然后访问所有内容，但事实证明，对于大量存储库，这可能会导致构建花费很长时间。
示例情况可能是另一个团队在Repo1中维护数据库模式，而您的团队在Repo2中的代码依赖于此。您希望在不担心模式更改或污染其他团队的存储库的情况下，将这种依赖关系与您自己的种子数据固定在一起（当然，根据更改的内容，您可能仍然需要更改种子数据脚本）第二种方法很粗糙，但避开了长构建的问题：
在中创建sh（或ps1）脚本/Code/Rep2复制所需文件并调用所需的docker命令，例如：
#!/bin/bash
rm -r ./db/schema
mkdir ./db/schema
cp -r ../Repo1/db/schema ./db/schema
docker-compose -f docker-compose.yml down
docker container prune -f
docker-compose -f docker-compose.yml up --build
在docker compose文件中，只需将上下文设置为Repo2根目录并使用的内容/dockerfile中的db/schema目录，而不必担心路径。请记住，您可能会意外地将此目录提交给源代码管理，但脚本清理操作应该足够简单。
其他回答
我认为更简单的解决方法是改变“上下文”本身。
因此，例如，不要给出：
docker build -t hello-demo-app .
它将当前目录设置为上下文，假设您希望父目录作为上下文，只需使用：
docker build -t hello-demo-app ..
创建一个包装docker构建shell脚本，该脚本获取文件，然后调用docker构建，然后删除文件。
在我的快速浏览中，这里没有提到一个简单的解决方案：
有一个名为docker_build.sh的包装脚本让它创建tarball，将大文件复制到当前工作目录调用docker构建清理油布球、大文件等
这个解决方案很好，因为（1.）它没有复制SSH私钥的安全漏洞（2.）另一个解决方案使用sudo绑定，所以它有另一个安全漏洞，因为它需要root权限才能进行绑定。
我花了很长时间试图找出一个好的模式，以及如何更好地解释这个特性支持的情况。我意识到最好的解释方法如下。。。
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都被复制到那里。每个人都可以按照自己的方式构建，共享开始文件！
一种快速而肮脏的方法是将构建上下文设置为所需的多个级别，但这可能会产生后果。如果您使用的是这样的微服务架构：
./Code/Repo1
./Code/Repo2
...
您可以将构建上下文设置为父代码目录，然后访问所有内容，但事实证明，对于大量存储库，这可能会导致构建花费很长时间。
示例情况可能是另一个团队在Repo1中维护数据库模式，而您的团队在Repo2中的代码依赖于此。您希望在不担心模式更改或污染其他团队的存储库的情况下，将这种依赖关系与您自己的种子数据固定在一起（当然，根据更改的内容，您可能仍然需要更改种子数据脚本）第二种方法很粗糙，但避开了长构建的问题：
在中创建sh（或ps1）脚本/Code/Rep2复制所需文件并调用所需的docker命令，例如：
#!/bin/bash
rm -r ./db/schema
mkdir ./db/schema
cp -r ../Repo1/db/schema ./db/schema
docker-compose -f docker-compose.yml down
docker container prune -f
docker-compose -f docker-compose.yml up --build
在docker compose文件中，只需将上下文设置为Repo2根目录并使用的内容/dockerfile中的db/schema目录，而不必担心路径。请记住，您可能会意外地将此目录提交给源代码管理，但脚本清理操作应该足够简单。
如果您阅读第2745期中的讨论，不仅docker可能永远不支持符号链接，他们也可能永远不会支持在您的上下文之外添加文件。这似乎是一种设计理念，即进入docker构建的文件应该明确地成为其上下文的一部分，或者来自一个URL，在该URL中，它可能也会以固定版本部署，这样构建就可以用docker容器附带的公知URL或文件重复。
我更喜欢从版本控制的源代码构建，即docker构建-t东西http://my.git.org/repo-否则我会在随机的地方用随机文件进行构建。从根本上说，不是……——斯文·多维迪特，多克公司
只是我的看法，但我认为您应该进行重组，以分离代码和docker存储库。这样，容器可以是通用的，并在运行时而不是构建时引入任何版本的代码。
或者，使用docker作为基本的代码部署工件，然后将dockerfile放在代码存储库的根目录中。如果您这样做，那么使用父docker容器获取更一般的系统级详细信息和子容器获取特定于您的代码的设置可能是有意义的。
