在WSL2下使用上下文为父级（..）的Docker YML文件需要太长时间才能生成

我有这个文件夹结构

folder_ext
folder_docker
       |---> folder_int
folder_1
folder_2
.......

我的docker文件都包含在文件夹\u docker中。在docker-compose.yml文件中，我设置了如下上下文

version: '3'
services:
  nginx:
    container_name: my_nginx
    build:
      context: ..
      dockerfile: ./folder_docker/nginx/Dockerfile

node_modules
build
discard 

在

Dockerfile

中，我从文件夹\u ext复制了一些文件

COPY./folder\u ext/container\u folder\u ext

但在下面的某个地方，我还复制了docker/nginx/nginx.tmp文件夹中的文件

COPY./folder\u docker/nginx/nginx.tmpl/etc/nginx/conf.d/nginx.tmpl

我还使用

.dockeringore

忽略我未使用的文件夹和文件

不幸的是，在WSL2（Ubuntu发行版）下，在开始处理Dockerfile中的第一条命令之前大约45分钟，这个开始构建过程的时间太长了。我不知道为什么，但这对我来说是一个巨大的问题，因为我想做很多构建，我正在浪费我的时间与这个摊位

如果我使用下面这样的替代方案，其中上下文设置在

文件夹\u ext

中

version: '3'
services:
  nginx:
    container_name: my_nginx
    build:
      context: ../folder_ext
      dockerfile: ../folder_docker/nginx/Dockerfile

构建几乎立即开始（约2秒），但对于第二个副本，我收到一个错误“构建上下文外部的docker禁止路径”

COPY../folder\u docker/nginx/nginx.tmpl/etc/nginx/conf.d/nginx.tmpl

我不想移动我的文件夹基础设施只是为了让它构建得更快，因为它是一个遵循这种文件夹结构的git项目。这似乎是一个WSL2/Windows问题，因为在生产服务器下，构建时间是可以接受的

---

还有其他解决方案吗？

子文件夹中的

.dockeringore

文件似乎被忽略

父文件中的原始

.dockeringnore

文件就是这样的

.git
node_modules
build

在每个父文件夹（如

文件夹_ext

，

文件夹_1

，

文件夹_2

等）中，也有自己的

。DockRignore

文件用于其子文件夹，如下所示

version: '3'
services:
  nginx:
    container_name: my_nginx
    build:
      context: ..
      dockerfile: ./folder_docker/nginx/Dockerfile

node_modules
build
discard 

似乎，

docker compose

只考虑了根据上下文位于父目录中的第一个

.dockeringone

文件

我修复了以下问题。我只使用了父文件夹中存在的一个

.dockeringore

文件，并删除了所有子文件夹的

.dockerginore

。然后我像这样更改了唯一的父文件

.dockeringore

的排除项

.git
node_modules
build 
folder_ext/node_modules
folder_ext/build
folder_1/node_modules
folder_1/build
folder_1/discard
folder_2/node_modules
folder_2/build
folder_2/discard

---

一些

文件夹是否很大？您在等待时有没有收到任何输出？@DavidMaze嗨，谢谢您的回答。当我在.dockeringnore中包含所有父文件夹时，它工作正常。当我只排除我在第二个场景中使用的特定文件夹ie
folder\u ext
时，它会再次停止。在
文件夹\u ext
中，我还有一个.dockrignore，它排除了我要忽略的所有文件夹。这让我发疯。在生产服务器（不是本地）上，所有场景都可以正常工作。只有在我的本地机器上，我遇到了这个问题，这是一个git映像，就像我在生产服务器上遇到的一样。@DavidMaze使用--verbose和--log-level调试，我没有得到任何信息。只是“xxxx大楼”