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

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

mount --bind olddir newdir

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

我不知道其他操作系统是否也有类似的功能。我还尝试使用Samba共享一个文件夹并将其重新安装到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/

使用链接解决问题：

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

在Dockerfile上，只需：

复制file_to_COPY/path/to/file

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

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

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

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

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

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