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

当想要创建图像。

我总是选择项目的根作为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 ../ 

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

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

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

或者，使用docker作为基本的代码部署工件，然后将dockerfile放在代码存储库的根目录中。如果您这样做，那么使用父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/

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

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

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

但由于管道的原因，COPY命令无法工作。但上述方法通过-f（明确表示未提供文件）来解决问题。只执行-如果不使用-f标志，则不会提供上下文和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目录，而不必担心路径。请记住，您可能会意外地将此目录提交给源代码管理，但脚本清理操作应该足够简单。

如何在两个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的最简单方法，同时保留两个项目中的相对导入路径。棘手的（令人讨厌的）部分是构建上下文在一个目录中引起的所有更改/后果。