Docker - 在替换PID 1时捕获日志

Question

我一直在互联网上寻找有关此问题的信息，但这似乎是一个特定的用例。

我正在尝试在Kubernetes / Openshift集群中部署运行旧版后端的docker容器。

使用entrypoint.sh脚本启动容器，该脚本将在启动之前初始化后端所需的依赖项。

我想将后端作为PID 1 - 以使用docker / openshift捕获后端日志。

要做到这一点，我在entrypoint.sh脚本的末尾有一个exec命令，它启动我的后端，从而用我的后端替换了entrypoint.sh进程 - 由docker分配PID 1。

问题：

当exec在entrypoint.sh中执行时，docker停止捕获日志，因此我在执行“docker logs $ MY_CONTAINER_ID”时没有来自docker捕获的后端进程的任何日志。 / p>

进入容器时，我确实看到一切正常：

我的后端进程以PID 1运行，并且正确设置了进程文件描述符1/2，捕获了后端进程的STDOUT和STDERR。

有人知道这是否是一个缺少的配置问题？或者docker只是设计成这样工作，考虑到我用exec替换PID 1？

Answer 1

我在你所描述的内容中看不出任何错误。应捕获进程ID 1的stdout / stderr，如果它们继承父进程的stdout / stderr（进程ID 1），则应捕获它们。

如果应用程序设置为登录到普通文件且不使用stdout / stderr，则可能遇到问题。在这些情况下，如果他们只接受文件，请使用/proc/1/fd/1作为日志文件路径。这将导致日志消息通过进程ID 1的stdout输出。

请注意，如果您的应用程序使用希望在您提供的路径上执行自己的日志文件轮换的日志记录框架，则需要禁用它，您希望它继续使用相同的文件路径而不是尝试重命名或截断它。

Answer 2

我想出了这个问题：

后端实际上是设置为在STDOUT和STDERR之间创建符号链接以记录容器本身中的文件。例如：应用程序代码登录STDOUT，后端启动脚本将STDOUT重定向到日志文件（旧版应用程序......）。

当执行入口点时，docker容器本身使用STDOUT和STDERR的管道进程。

问题：

当后端进程在最后替换entrypoint.sh进程时，STDOUT和STDERR符号链接会发生变化 - 如上所述，我猜这会对docker守护进程产生影响并阻止docker收集任何进一步的日志STDOUT和STDERR。