一种 core 文件在 docker 中的挂接方法

core 文件在 docker 中的特别之处

core 文件产生的路径，是由宿主机上的 /proc/sys/kernel/core_pattern 来指定的

默认是在可执行文件所在目录

因此有几个问题：

• 不能通过 /proc/sys/kernel/core_pattern 来修改 core 产生路径，你改了就会影响宿主机上其他容器的 core 路径
• 不能简单 -v 挂接，直接挂接可执行文件所在目录，则容器内的程序都要被覆盖掉啦
• core 文件在生产环境中对于程序员又特别重要
  • 同宿主机上会开很多容器，容器状态有正常、有异常，人工手动经常性的去检查是否有 core 文件，不是很现实
  • 这种情况下，获取 core 文件的自动化脚本也很难实现

解决方法

0. 原理

利用 a 、 b 变量实现交换，可以：

tmp := a
a = b
b = tmp

细节见下步骤

1. Dockerfile 文件调整

• 工作目录下的所有内容，在 Dockerfile 中，不是 COPY 到工作目录
• 先把所有内容 COPY 到一个临时目录，如 /tmp/work/ 下

2. 使用 docker-entrypoint.sh 来作为入口程序脚本

docker-entrypoint.sh 大致如下：

mv /tmp/work your_work_dir
exec "$@"

以上的意思是，先把临时目录下的所有内容移到工作目录下，然后开始

3. 正常挂接工作目录

通过 1 、 2 点， 这比如 docker run -v 就可以正常挂接工作目录到宿主机了

以上

该方案中的缺点

通常我们可能会给程序发信号量，来触发诸如资源热更新、打开性能分析器等操作

然而 docker kill 发送信号量有个小缺陷：

细节见官方文档： https://docs.docker.com/engine/reference/commandline/kill/

文中提到：

Note: ENTRYPOINT and CMD in the shell form run as a subcommand of /bin/sh -c, which does not pass signals. This means that the executable is not the container’s PID 1 and does not receive Unix signals.

通过 docker-entrypoint.sh 并使用 exec "$@" 的方式启动程序，docker kill 的信号量会被屏蔽

该方案的附带补充

需要捕获信号量的程序，可内置 http 服务

这样就可以通过 curl 命令来触发你要的功能，如资源热更新

以上