Docker Compose容器优雅停止前执行清理命令的实现方案

好问题！在Compose v3版本里，确实没有专门的顶层配置用来定义容器停止前的清理钩子，但咱们有几个实用的方案可以解决PID文件残留的问题，我给你详细说说：

方案一：在业务脚本中捕获停止信号，执行清理 #

Docker停止容器时，会给容器内的主进程发送SIGTERM信号（如果超时则发SIGKILL）。你可以修改example.sh，添加信号捕获逻辑，在收到停止信号时自动删除PID文件：

#!/bin/bash

# 定义清理函数
cleanup() {
    echo "容器即将停止，开始清理PID文件..."
    rm -f /myapp/your-service.pid  # 替换成你的PID文件实际路径
    exit 0
}

# 捕获SIGTERM（Docker默认停止信号）和SIGINT（Ctrl+C中断信号）
trap cleanup SIGTERM SIGINT

# 原来的业务执行逻辑
cd /myapp/
./your-service  # 假设这里会启动服务并生成PID文件

注意：如果你的服务是后台运行的（比如启动命令加了&），记得在脚本里用wait等待服务进程，否则bash会直接退出，没法捕获到停止信号。示例如下：

# 启动服务到后台
./your-service &
SERVICE_PID=$!
# 等待服务进程结束
wait $SERVICE_PID

方案二：启用init进程确保信号正常转发 #

如果你的服务进程没有正确处理信号，或者脚本是通过bash间接启动的，可能会出现信号无法传递的情况。这时候可以在Compose中启用Docker内置的init进程，它会负责把信号转发给容器内的所有子进程：

version: '3'
services:
  server:
    build: ./
    init: true  # 启用Docker内置的init进程
    command: bash -c "cd /myapp/ && ./example.sh"

配合方案一的脚本信号捕获，就能确保清理逻辑被正常触发。

方案三：用entrypoint脚本封装启动与清理流程 #

如果不想修改原有业务脚本，可以写一个单独的entrypoint脚本，作为容器的主进程，负责启动服务、等待服务结束，最后执行清理操作：

先创建entrypoint.sh（记得给它加执行权限：chmod +x entrypoint.sh）：

#!/bin/bash

# 启动业务服务
cd /myapp/
./example.sh &
SERVICE_PID=$!

# 等待服务进程结束，同时捕获停止信号
wait $SERVICE_PID

# 不管服务是正常退出还是被停止，都执行清理
rm -f /myapp/your-service.pid

# 保持服务的原始退出码
exit $?

然后修改Compose配置：

version: '3'
services:
  server:
    build: ./
    entrypoint: /myapp/entrypoint.sh

补充说明 #

Compose v3为了适配Swarm模式，移除了v2版本中的部分配置节点（比如stop_command），但上面的三个方案都是通用且可靠的，能完美解决你遇到的PID文件残留问题。相比在启动时删除PID文件，这种在停止时清理的方式更符合“谁创建谁清理”的原则，也能避免一些边界情况。

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