docker容器生命周期自动化应采用事件驱动+元数据控制+可插拔策略，通过监听docker events实时响应容器状态变化，结合健康探针、结构化日志、优雅停机等机制实现自愈与可观测性。
做 Docker 容器生命周期自动化，关键不是写一堆脚本去轮询或硬编码重启逻辑，而是用事件驱动 + 元数据控制 + 可插拔策略的方式，让容器自己“会呼吸、能自愈、留痕迹”。
监听 docker events 做实时触发
docker events 是官方提供的轻量级事件总线，能捕获 create、start、die、kill 等原生动作，延迟低、开销小，比定时轮询 docker ps 更可靠。
- 启动监听进程：docker events --filter 'event=start' --filter 'event=die' --format '{{json .}}'
- 只处理带特定标签的容器，比如 com.example.managed=true，避免影响其他运维容器
- 事件中直接拿到 container_id 和 status，再用 docker inspect --format 提取 labels、health、restart policy 等元数据，决定下一步动作
健康检查不依赖 HEALTHCHECK 指令
内置 HEALTHCHECK 只能看进程是否存活，无法感知数据库连接断开、缓存击穿、配置加载失败等真实业务异常。需要在工具层补足。
- 支持四类探针：HTTP（GET /health）、TCP（连通端口）、SQL（SELECT 1）、自定义命令（如 curl -s http://localhost:8080/actuator/health | grep UP）
- 每个容器可单独配置超时时间、重试次数、失败阈值，例如连续 3 次 HTTP 探针失败才触发恢复
- 失败后先执行 pre-heal hook（如刷新配置、清空本地缓存），再重启容器，而不是一上来就 kill
日志与状态必须结构化留存
docker logs 默认输出是纯文本流，没有上下文、不可聚合、易丢失；docker stats 是瞬时快照，不保存历史。自动化必须补上这两块。
- 启动容器时注入统一日志处理器，比如通过 --log-driver=fluentd 或挂载 fluent-bit sidecar，并自动打标 container_id、service_name、env=prod
- 每 5 分钟采集一次 docker stats --no-stream 输出，转成 JSON 写入本地归档目录，字段含 CPU%、mem_usage、net_io、blkio
- 容器退出时自动捕获最后 100 行日志 + exit_code + OOMKilled 状态，文件名含时间戳和 short-id，便于故障回溯
优雅停机要和应用生命周期对齐
很多服务收到 SIGTERM 后立刻退出，没来得及刷盘、关闭连接、释放锁，导致下次启动失败或数据不一致。
- 启动时注入 STOP_GRACE_PERIOD=30s 环境变量，工具监听 stop 事件后，先发 SIGTERM，等待该周期，再发 SIGKILL
- 配合应用层实现 shutdown hook，比如 Spring Boot 的 ApplicationRunner 或 Java 的 Runtime.addShutdownHook
- 支持 pre-stop hook：停止前调用 curl -X POST http://localhost:8080/internal/shutdown，完成缓存 flush、DB 连接池 drain 等操作
