应显式设置 timeout 并调用 client.containers.list(all=true) 获取全状态容器，再通过 inspect 获取 health.status；判断就绪需结合日志关键词、端口探测及 healthcheck 状态三重验证。
如何用 docker-py 获取容器实时状态并避免连接超时
直接调用 docker-py 的 client.containers.list() 会默认只返回运行中容器，且不带健康检查字段。如果容器处于 exited 或 created 状态但未被识别，大概率是 Docker daemon 响应慢或 socket 连接未设超时。
实操建议：
- 初始化 client 时必须显式设置
timeout参数，例如docker.DockerClient(base_url='unix:///var/run/docker.sock', timeout=5) - 要获取所有状态（包括已退出容器），需传参
all=True：client.containers.list(all=True) - 健康状态不在默认属性里，得手动 inspect：
container.attrs['State']['Health']['Status']（仅当容器启用HEALTHCHECK时存在） - 避免在循环中反复创建 client 实例，复用单个实例更稳定
怎么判断容器是否真的“就绪”而非仅“运行中”
running 状态不等于服务可用——比如 Nginx 容器启动快，但配置加载失败后仍显示 running；PostgreSQL 可能卡在 initdb 阶段。靠 container.status 不够，得结合日志 + 端口探测。
实操建议：
- 用
container.logs(timestamps=False, tail=100)提取最近日志，搜索关键成功标识（如"ready for connections"或"listening on"） - 对暴露端口做轻量级探测：
socket.create_connection((host, port), timeout=2)，别用requests.get（HTTP 层太重，且可能被防火墙拦截） - 若容器启用了
healthcheck，优先读container.attrs['State']['Health']['Status']，值为"healthy"才算真正就绪
重启失败容器时如何防止雪崩式重试
直接对异常容器调 container.restart() 很危险：如果镜像或配置本身有缺陷，连续重启会迅速耗尽资源，还可能触发 Docker daemon 的 rate limit（尤其在 swarm 模式下）。
实操建议：
- 加退避机制：首次失败后等待 1s，第二次 2s，第三次 4s，上限设为 30s，用
time.sleep(min(30, 2 ** attempt)) - 限制最大重试次数（如 3 次），超过则发告警并停止操作
- 重启前先检查资源占用：
container.stats(stream=False)中的MemoryStats和CPUStats，若内存使用 >95%，先跳过本轮 - 记录每次重启的 exit code：
container.attrs['State']['ExitCode']，非 0 值要存档用于事后分析
为什么用 subprocess 调 docker ps 不可靠
看似简单，但 subprocess.run(['docker', 'ps', '-q']) 在高并发或容器数多时容易卡住，且输出格式随 Docker 版本变化（比如 24.0+ 默认启用 --format 模板，旧脚本会解析错）。更严重的是，它绕过了 Python 的异常处理链路，错误码和 stderr 难以统一捕获。
实操建议：
- 彻底弃用
subprocess调 docker CLI，除非调试极简场景（如单容器本地开发） - 生产环境一律走
docker-py，它底层仍是 HTTP API，但封装了重试、超时、JSON 解析和类型转换 - 若必须用 CLI（如调用
docker exec执行诊断命令），至少用capture_output=True, text=True, timeout=10控制行为
容器状态管理真正的复杂点不在“查”或“启”，而在“判”——判健康、判就绪、判可恢复。很多脚本卡在“容器 running 就认为 OK”，结果线上服务明明监听着端口，却返回 502。这需要把日志关键词、端口连通性、healthcheck 状态三者交叉验证，而不是依赖单一字段。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
