本质上 symlink 只是一个文件或目录的"链接"(anchor)，实际上，早期的 symlink 实现中，一个 symlink 就是包含了一个路径名的普通文件。

所以，一个 symlink 在容器和宿主机上指向的实际目标很可能是不同的，比如通过以下脚本新建的容器：

```
mkdir volume
ln -s / volume/root
docker run --rm -ti -v `pwd`/volume:/data -w /data busybox sh
```

在宿主机，和容器内分别执行`ls root`, 看到的内容是不同的，分别是宿主机和容器的根目录。

如果你希望 symlink 在容器和宿主机上指向的目标一致，靠谱一点的办法是将目标文件放在 volume 内，而且采用相对路径的方式创建 symlink， 比如：

```
mkdir volume
cd volume
touch target
ln -s ./target symlink1
ln -s `pwd`/target symlink2
docker run --rm -ti -v `pwd`:/data -w /data busybox sh
```

在以上脚本建立的容器内执行` cat /data/symlink1`和`cat /data/symlink2`，会发现前者能正确访问到文件，后者则会报错

我之前也遇到过软链接相关的问题，但时间久远，细节不太记得了，不能确定和你的是不是一个问题，方便的话贴个重现脚本看看吧？

以前 PT 玩的多的时候也想过做一个类似的工具。

前两天刚在[reddit]( https://www.reddit.com/r/docker/comments/6j2s2s/kernelunregister_netdevice_waiting_for_lo_to/)上也看到了这个 bug 的讨论。

1. 不推荐去读“系统”的资料，读一下官方的 quickstart 和基本介绍，知道 docker 能干什么，不能干什么，然后着眼于你的应用，用 Docker 去解决你的问题就可以了。
2. 你目前的用法应该是有问题的，Docker 推崇的是单容器-单进程-单应用，虽然现实中会有所妥协，但一般不会把整个应用及其依赖的服务打到一个镜像，用一个容器来跑。更常见的做法是 database 和 webserver 用独立的镜像，独立的容器来跑，然后用 docker-compose 或 kubernetes 之类的工具将一批容器组织成一个应用单元。
3. Dockerfile 的问题，直接把 Dockerfile 的内容贴出来会更方便讨论。

@Muninn 提到的两段构建的玩法，一年前我们在自己开发的镜像制作管理工具中实现过： https://github.com/CtripCloud/docker-make#two-images-one-for-compile-one-for-deployment

--env 是生效的，你 docker exec 进容器执行下 echo $PROXY 就知道了。

caddyfile 是你构建镜像的时候就已经生成好的一个文件，里边的内容不会因为这次 docker run 而改变。否则的话，一个镜像内那么多脚本中用到环境变量，那这些文件的内容也太难控制了。


你需要的东西，其实是一个自定义 entrypoint，在每次容器拉起来时，根据环境变量修改 caddyfile

@initialdp 哈哈，各种坑啊...

@initialdp 不同之处应该不是这样的吧，PyObject_CallObject定义在abstract.c里边，从设计上来看应该是一个通用接口函数(执行第一个参数所代表的可执行对象），而PyInstance_New是PyClass_Type的tp_call域的值，它的职能很明确，就是用来实例化old style class的。所以如果有一个类A，则调用PyObject_CallObject(A,...)将最终导致PyInstance_New(A,...)的执行。

PyInstance_New只能实例化old style class.