docker健康检查通过周期性执行命令（如curl -f访问/health端点）判断服务真实可用性，核心参数需匹配应用行为：interval设15–30秒、timeout略大于接口平均响应时间、retries通常为3、start-period覆盖冷启动时长；命令必须返回0才标记healthy，且dockerfile定义基础检查、docker-compose.yml推荐用于生产环境灵活覆盖。
要让 docker 容器真正“活”得健康，光靠进程不退出远远不够。健康检查不是锦上添花的配置项，而是判断应用是否具备服务能力的关键信号——它能揪出那些“进程在跑、请求全挂”的假死容器，并为自动恢复提供依据。
健康检查的核心参数怎么设才合理
四个关键参数决定检查是否有效：interval（间隔）、timeout（单次超时）、retries（失败容忍次数）、start-period（启动宽限期）。它们不是随便填的数字，而需匹配应用真实行为：
- interval：建议设为 15–30 秒。太短会增加负载，太长则故障发现延迟；对高敏感服务可压到 5–10 秒，但需确认应用能稳定响应
- timeout：应略大于健康端点平均响应时间（如加 2–3 秒余量）。若接口通常耗时 800ms，timeout 设为 3s 更稳妥，避免偶发慢响应误判
- retries：设为 3 是通用起点。若网络抖动常见，可调至 5；若要求严格（如金融类），可降为 2，但需配合更宽松的 timeout
- start-period：必须覆盖应用冷启动全过程。Spring Boot 应用常需 45–60 秒加载上下文，Nginx 静态服务可能只需 5 秒——这个值填小了会导致刚启动就被标记 unhealthy
检查命令写法要注意什么
命令返回码是健康状态的唯一判决依据，0=healthy，1=unhealthy，2=禁用。实际编写时容易踩坑：
- 用 curl -f 而非 curl -I 或裸 curl：-f 确保非 2xx/3xx 响应直接报错退出，避免 HTTP 503 返回 0 导致误判
- 避免依赖外部工具缺失：Alpine 镜像默认无 curl，Dockerfile 中要先 RUN apk add --no-cache curl；或改用 wget --spider -q（更轻量）
- HTTP 检查优先访问 /actuator/health（Spring Boot）、/healthz（K8s 风格）等专用端点，而非根路径 /，避免页面渲染逻辑干扰
- 数据库类服务慎用纯端口连通性检查（如 nc -z localhost 5432）：连接通 ≠ 服务可用。应执行简单 SQL 如 psql -U user -d db -c "SELECT 1" 并捕获结果
Dockerfile 和 docker-compose.yml 怎么选
两者不是互斥，而是分层协作关系：
- Dockerfile 中定义基础检查：适用于所有该镜像的实例，比如统一用 curl 检查 /health。适合标准化程度高的中间件（如 Nginx、Redis）
- docker-compose.yml 中覆盖或增强：生产环境推荐做法。例如同一镜像部署测试/预发/线上环境时，线上可加更严苛的 timeout 和 retries；或为特定服务启用自定义脚本：test: ["CMD-SHELL", "./health-check.sh"]
- 注意优先级：运行时传入的 healthcheck 配置（如 docker run --health-cmd） > docker-compose.yml > Dockerfile。镜像级配置可被显式禁用：HEALTHCHECK NONE
怎么验证和排查健康状态异常
配置完别只信日志，要用命令实打实看状态：
- 实时查看：docker inspect myapp | jq '.State.Health'（需安装 jq）或简化版 docker inspect --format='{{.State.Health.Status}}' myapp
- 查失败详情：docker inspect --format='{{json .State.Health.Log}}' myapp，输出含每次检查的起止时间、退出码、原始输出，能快速定位是超时、连接拒绝还是业务返回错误
- 临时调试：进入容器手动执行健康命令，确认路径、权限、依赖是否就绪。比如 docker exec -it myapp sh -c "curl -v http://localhost:8080/health"
- 结合编排平台：在 Swarm 中，docker service ps myservice 显示容器状态；在 Kubernetes 中，kubectl get pods 的 READY 列依赖 readinessProbe，需区分 liveness 与 readiness 配置差异
