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

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

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

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

在Linux上，您可以装载其他目录，而不是符号链接它们

mount --bind olddir newdir

看见https://superuser.com/questions/842642了解更多详情。

我不知道其他操作系统是否也有类似的功能。我还尝试使用Samba共享一个文件夹并将其重新安装到Docker上下文中，这同样有效。

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

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

docker build -f docker-files/Dockerfile .

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

docker build -f ../Dockerfile .

您还可以创建图像首先需要的内容的tarball，并将其用作上下文。

https://docs.docker.com/engine/reference/commandline/build/#/tarball-上下文

我认为更简单的解决方法是改变“上下文”本身。

因此，例如，不要给出：

docker build -t hello-demo-app .

它将当前目录设置为上下文，假设您希望父目录作为上下文，只需使用：

docker build -t hello-demo-app ..

我经常发现自己为此使用--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命令，映像的任何用户都可以看到构建时间变量值。

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

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

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

使用docker compose，我通过创建一个服务来装载所需的卷并提交容器的映像来完成这一点。然后，在后续服务中，我依赖于先前提交的映像，该映像将所有数据存储在装载位置。然后，您必须将这些文件复制到其最终目的地，因为在运行docker commit命令时不会提交主机装载的目录

你不必使用docker compose来实现这一点，但它会让生活变得简单一些

# docker-compose.yml

version: '3'
  services:
    stage:
      image: alpine
      volumes:
        - /host/machine/path:/tmp/container/path
      command: bash -c "cp -r /tmp/container/path /final/container/path"
    setup:
      image: stage

# setup.sh

# Start "stage" service
docker-compose up stage

# Commit changes to an image named "stage"
docker commit $(docker-compose ps -q stage) stage

# Start setup service off of stage image
docker-compose up setup

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

例子：

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

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

一种快速而肮脏的方法是将构建上下文设置为所需的多个级别，但这可能会产生后果。如果您使用的是这样的微服务架构：

./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目录，而不必担心路径。请记住，您可能会意外地将此目录提交给源代码管理，但脚本清理操作应该足够简单。

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

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

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

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

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

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

使用链接解决问题：

ln路径/to/file/outer/context/file_to_copy/文件_to_copy

在Dockerfile上，只需：

复制file_to_COPY/path/to/file

创建一个包装docker构建shell脚本，该脚本获取文件，然后调用docker构建，然后删除文件。

在我的快速浏览中，这里没有提到一个简单的解决方案：

有一个名为docker_build.sh的包装脚本让它创建tarball，将大文件复制到当前工作目录调用docker构建清理油布球、大文件等

这个解决方案很好，因为（1.）它没有复制SSH私钥的安全漏洞（2.）另一个解决方案使用sudo绑定，所以它有另一个安全漏洞，因为它需要root权限才能进行绑定。

如何在两个Dockerfile之间共享typescript代码

我也遇到过同样的问题，只是在两个typescript项目之间共享文件。其他一些答案对我不起作用，因为我需要保留共享代码之间的相对导入路径。我通过这样组织代码来解决这个问题：

api/
  Dockerfile
  src/
    models/
      index.ts

frontend/
  Dockerfile
  src/
    models/
      index.ts

shared/
  model1.ts
  model2.ts
  index.ts

.dockerignore

注意：在将共享代码提取到顶部文件夹后，我避免了更新导入路径，因为我更新了api/models/index.ts和frontend/models//index.ts以从共享导出：（例如export*from'../../shared）

由于构建上下文现在高了一个目录，我不得不做一些额外的更改：

更新build命令以使用新上下文：docker build-f Dockerfile。。（两个点而不是一个）在顶层使用一个.dockerignore来排除所有node_module。（例如**/node_modules/**）在Dockerfile COPY命令前面加上api/或frontend/复制共享（除了api/src或frontend/src）工作目录/usr/src/appCOPY api/package*.json./<----前缀为api/运行npm ciCOPY api/src api/ts*.json./<----前缀为api/复制共享usr/src/shared<----添加RUN npm运行构建

这是我可以将所有内容发送到docker的最简单方法，同时保留两个项目中的相对导入路径。棘手的（令人讨厌的）部分是构建上下文在一个目录中引起的所有更改/后果。

我个人对一些答案感到困惑，所以决定简单地解释一下。

当想要创建图像。

我总是选择项目的根作为Dockerfile中的上下文。

例如，如果您使用COPY命令，如COPY。

第一个点（.）是上下文，第二个点（。）是容器工作目录

假设上下文是项目根、点（.），代码结构如下

sample-project/
  docker/
    Dockerfile

如果要构建映像

您的路径（运行docker build命令的路径）是/full-path/sample-project/，你应该这样做

docker build -f docker/Dockerfile . 

如果您的路径是/full-path/sampleproject/docker/，你应该这样做

docker build -f 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

我想今年早些时候，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/