Docker不遵循生成目录中的符号链接

我正在对接一个应用程序，该应用程序涉及通过Clang将二进制文件与其他C文件链接。我们维护二进制文件的符号链接版本，因为它们在整个代码库中使用。我的Docker build目录包含整个代码库（包括源文件以及指向这些源文件的符号链接），当我执行类似于

cat[symlinked_file]

的操作时，Docker会识别这些文件（即，该文件已正确地

cat

）。但是，当我在Makefile中运行我的Clang命令时，它无法链接符号链接的文件（这些命令在Docker中无法正常工作）。然后我将原件复制到符号链接所在的目录中，替换了符号链接，Docker在构建时没有抛出任何错误

---

有人知道怎么避开这件事吗？我需要给Docker或Clang任何特殊命令吗？我不知道为什么Clang在Docker容器内的行为与在Docker容器外的不同。我从Ubuntu 16.04的基本映像运行，以供参考

Docker将使用符号链接（至少在我的linux主机上构建时是这样），但它复制的是符号链接本身，而不遵循链接。因此，您还需要将符号链接目标单独包含在构建上下文中，并复制到图像中。此上下文被发送到docker引擎，生成发生在该服务器上的容器中，因此任何指向该上下文之外的文件的链接都不会解析。您还希望这些链接是相对的，或者链接的绝对路径必须指向图像中相同的绝对路径。下面是一个带有相对链接的示例，显示了上下文内部和外部文件之间的差异：

$ ls -al
total 8
drwxr-xr-x  2 bmitch bmitch 4096 Mar  2 21:08 .
drwxr-xr-x 13 bmitch bmitch 4096 Mar  2 21:07 ..
lrwxrwxrwx  1 bmitch bmitch   11 Mar  2 21:08 outside.txt -> ../test.out
lrwxrwxrwx  1 bmitch bmitch   10 Mar  2 21:08 source.txt -> target.txt
-rw-r--r--  1 bmitch bmitch    0 Mar  2 21:08 target.txt

$ cat Dockerfile
FROM busybox
COPY . /build-context
WORKDIR /build-context
CMD find .

$ docker build -t test-symlink .
Sending build context to Docker daemon 3.584 kB
Step 1/4 : FROM busybox
 ---> 7968321274dc
Step 2/4 : COPY . /build-context
 ---> 8238dac16669
Removing intermediate container dd653dfdf7a4
Step 3/4 : WORKDIR /build-context
 ---> c1850cb52f0e
Removing intermediate container 7ee87e20d525
Step 4/4 : CMD find .
 ---> Running in e710e965d98c
 ---> fd57eb8f426b
Removing intermediate container e710e965d98c
Successfully built fd57eb8f426b

$ docker run test-symlink
.
./outside.txt
./Dockerfile
./source.txt
./target.txt

$ docker run -it --rm test-symlink /bin/sh
/build-context # ls -al
total 12
drwxr-xr-x    2 root     root          4096 Mar  3 02:09 .
drwxr-xr-x   20 root     root          4096 Mar  3 02:09 ..
-rw-r--r--    1 root     root            69 Mar  3 02:08 Dockerfile
lrwxrwxrwx    1 root     root            11 Mar  3 02:08 outside.txt -> ../test.out
lrwxrwxrwx    1 root     root            10 Mar  3 02:08 source.txt -> target.txt
-rw-r--r--    1 root     root             0 Mar  3 02:08 target.txt
/build-context # cat outside.txt
cat: can't open 'outside.txt': No such file or directory
/build-context # cat target.txt
/build-context # exit

---

我最近遇到了完全相同的问题。经过大量的研究和测试，以下是我从Docker团队中发现的

是的，我们选择不遵循docker build的符号链接，因为 在不同的基础上可能出现的不一致结果 系统

基本上，这不是即将推出的功能

这是我的文件夹结构。位于同一目录级别的两个存储库

/cms-code
/cms-themes

我想将

/cms-code

中的

/public

文件夹符号链接到

/cms-themes

文件夹。在

/cms code

内部构建

Dockerfile

以将公用文件夹复制或添加到图像中。不幸的是，我得到的只是一个复制到图像/容器中的符号链接，而不是任何内容

我看到的选项：

创建一个bash/sh脚本，将文件复制到公共文件中 已设置存储库。[不利于积极发展或 文件更改时刷新]

使用Git的子模块系统移动我的

cms主题

repo到

/cms code

存储库。[不适合我的特殊情况]

使用

docker compose

将

/cms code

中的

/public

文件夹设置为与我的主机

/cms主题

目录同步。[这最终是我想要的 已选择。它仍然不理想，但确实有效。CMS容器 （运行后）查看

/public

的所有内容，这些内容实际上是

/cms主题中的文件

希望这对您有所帮助并与您的情况相关。如果您有任何问题，请告诉我。如果您不熟悉compose中的卷，我可以共享一个示例

docker compose.yml

文件

更新--添加撰写文件引用作为要点：

---

符号链接目标是在构建上下文目录中还是在文件系统的另一个文件夹中？是的。Dockerfile所在的顶级目录

dir

包含子目录

dir1

和

dir2

。符号链接文件以及目标位于

dir1

中。我发现了另一个问题关于构建上下文之外的文件，我可以理解为什么Docker会在该场景中失败，但这让我困惑，为什么当所有必需的文件都在构建上下文中时，Docker会失败。这是有道理的，但我的所有目标都在构建上下文中：（@Rads docker不遵循符号链接，它会复制链接本身，如上图所示。因此，我不希望复制单个链接文件，因为您也没有复制目标。windows文件系统非常不同，我不知道它们是否在文件系统级别具有符号链接，或者其他不同的东西，例如带有链接文件名的特殊文件，和要分析的数据。MacOS应该像Linux一样运行，但我没有一个环境来测试上述命令。@BMitch我删除了我的评论，因为它听起来太负面了。你的回答在一定程度上肯定是有帮助的。但我建议你考虑这样一个事实，即docker引擎在不同的操作系统中有着显著的不同。MacOS的运行方式不像LinuxLinux在许多情况下，可能也是因为Docker Desktop和Docker CE的不同。您上面的评论在不同的操作系统中是不一致的。Docker遵循符号链接，我已经确认了这一点，就像您一样，我也没有所有的环境要测试。因此，存在很大的不一致性。@Rads Docker在桌面上的Linux VM中运行，so这一半应该是相同的。但是docker cli（客户端与引擎对话）在Mac或Win环境下运行，可能会看到一些差异。与其在评论中进行调试，不如发布一个涵盖您正在使用的平台的答案，或者发布一个关于是否可以在您的平台上获得链接的不同问题。如果您可以共享一个

docker compose.yml

文件非常有帮助！@Aadibhatti——当然……我用这些信息更新了我的答案。希望这会有帮助。如果你有更多问题，请告诉我。