关于Docker引擎与Docker容器通信机制的技术问询

嘿，这个问题问得很到位！既然你已经清楚Docker CLI和引擎是通过Unix套接字/TCP通信的，那咱们就聚焦到引擎和容器进程之间的交互逻辑上——其实核心是几种相辅相成的机制，我给你拆解明白：

1. 信号传递：最直接的进程间通信手段 #

这是docker stop这类操作最常用的方式：

• 当你执行docker stop <container-id>时，Docker Engine首先会找到容器的PID 1进程（容器内的主进程），给它发送SIGTERM信号——这是一个「优雅终止」的信号，目的是给容器内的应用留出时间做清理工作，比如关闭数据库连接、保存临时状态、停止子服务等。
• 如果容器在默认的10秒超时时间里还没主动退出，Docker Engine就会升级信号，发送SIGKILL——这是个强制终止的信号，会直接杀死整个容器的进程组，确保容器被停止。
• 你还可以通过docker stop -t <seconds>自定义超时时长，调整发送SIGKILL前的等待时间。

这里要提个小坑：如果容器内的PID 1进程没有正确处理SIGTERM（比如有些脚本或者老旧应用会忽略这个信号），那docker stop就会等到超时后才会强制终止，这也是有时候容器停得慢的原因之一。

2. Linux Cgroups：资源管控与状态同步 #

Docker Engine还会通过Linux的Cgroups（控制组）和容器进行交互，这部分更多是监控和资源限制，但也是通信的重要环节：

• Docker会为每个容器创建独立的Cgroup层级，通过Cgroups可以实时获取容器的CPU、内存、IO等资源使用情况，也能动态调整资源配额（比如用docker update --cpus 2 <container-id>给容器加CPU配额）。
• 当需要终止容器时，Cgroups也会参与回收容器占用的系统资源，确保进程被彻底清理，不会留下僵尸进程或者残留资源。

3. 自定义Shutdown Hook：上层业务级通信（可选） #

有些容器镜像会内置Docker的shutdown hook机制，这是一种更上层的业务级通信方式：

• 当容器收到SIGTERM信号后，内部的hook脚本会触发预定义的清理逻辑，比如停止服务、同步数据到外部存储、发送告警通知等，完成后再主动退出进程。
• 这种方式不是Docker引擎和容器通信的原生机制，而是依赖镜像的自定义配置，属于实践中常用的补充手段。

额外小细节：Docker Engine怎么找到容器进程？ #

Docker在创建容器时，会把容器的PID记录在容器的元数据里（通常存在/var/lib/docker/containers/<container-id>目录下的配置文件中），所以它能精准定位到目标进程，发送信号或者进行其他操作。

内容的提问来源于stack exchange，提问作者SRaj