---
title: "发版前用健康检查卡住不健康容器：Dockerfile HEALTHCHECK与compose period - Angryecho"
description: "准备工作 已安装Docker Engine，并能运行docker version。 官方文档：Dockerfile HEALTHCHECK 指令说明见 Docker Docs。["
canonical_url: "https://www.angryecho.com/c/Docker/p/P2TBBjU5noEpyvsmJdren"
meta:
  "og:description": "准备工作 已安装Docker Engine，并能运行docker version。 官方文档：Dockerfile HEALTHCHECK 指令说明见 Docker Docs。["
  "og:image": "https://www.angryecho.com/_og/d/c_Post%2Ctitle_~5ZCQ5qe9572R%2Cdescription_~5ZCQ5qe95LiA5LiL77yM5bCx5LiK5ZCQ5qe9572R44CC%2CpostId_P2TBBjU5noEpyvsmJdren%2Crevision_~MjAyNi0xMC0yN1QwMjo1Nzo0OS4yMjMzNTBa%2Cp_Ii9jL0RvY2tlci9wL1AyVEJCalU1bm9FcHl2c21KZHJlbiI%2Cs_b2h5qYFpMr02iOq1.png"
  "og:image:height": "630"
  "og:image:type": image/png
  "og:image:width": "1200"
  "og:title": "发版前用健康检查卡住不健康容器：Dockerfile HEALTHCHECK与compose period"
---

> Index of every page on this site: [llms.txt](https://www.angryecho.com/llms.txt)

# **发版前用健康检查卡住不健康容器：Dockerfile HEALTHCHECK与compose period**

## 准备工作

- 已安装Docker Engine，并能运行 `docker version`。
- 官方文档：Dockerfile `HEALTHCHECK` 指令说明见 Docker Docs。\[1]

## 操作步骤

### 1、在镜像里声明HEALTHCHECK

做什么：在Dockerfile末尾增加例如：

```dockerfile
HEALTHCHECK --interval=30s --timeout=3s --start-period=40s --retries=3 \
  CMD curl -f http://127.0.0.1:8080/healthz || exit 1
```

为什么：编排系统只知道进程在不在；健康检查才告诉你“进程在但服务没好”。\[1]  
如何确认：`docker build`成功后，`docker inspect`镜像配置里能看到`Healthcheck`字段。

### 2、跑起来看状态从starting到healthy

做什么：`docker run -d --name demo your:image`，然后`docker ps`观察STATUS里的`(health: ...)`。  
为什么：`start-period`内失败不计入retries，避免启动慢被误杀。\[1]  
如何确认：就绪后STATUS含`(healthy)`；故意停掉依赖服务后应变为`(unhealthy)`。

### 3、在Compose里对齐interval与依赖顺序

做什么：在`compose.yaml`服务下写`healthcheck:`块，并让依赖服务使用`depends_on: condition: service_healthy`（Compose支持时）。  
为什么：只写`depends_on`服务名只保证启动顺序，不保证可服务。\[1]  
如何确认：`docker compose up`时，下游服务在上游healthy之后才创建。

### 4、失败命令要返回非零

做什么：确保CMD在失败时`exit 1`（如`curl -f`）。  
为什么：Docker以退出码判断成败。\[1]  
如何确认：手动在容器内执行同一CMD，失败时echo $?非0。

### 5、把探测路径做成真正的业务就绪检查

做什么：`/healthz`（或你选的路径）里检查关键依赖：数据库ping、必要配置已加载，而不是只`return 200`。  
为什么：假健康检查会让编排系统把半残实例继续接流量。\[1]  
如何确认：人为断开数据库后，容器在数个interval后变`unhealthy`。

### 6、为发布流水线加一道“不健康则失败”

做什么：在CI/CD里`docker run`后轮询`docker inspect --format='{{.State.Health.Status}}'`，超时仍非healthy则失败回滚。  
为什么：镜像能构建不等于服务能就绪。  
如何确认：故意弄坏HEALTHCHECK CMD时，流水线变红。

## 注意事项

- 健康检查不是负载均衡探活的全部；公网探活还要另配。
- 别在HEALTHCHECK里做很重的迁移任务。

## 常见问题

- **一直卡在starting？** 加大 `start-period`，或检查健康检查是否在服务听端口之前就执行。\[1]
- **Compose里depends\_on不生效？** 确认Compose文件版本支持 `condition: service_healthy`，且拼写无误。
- **探活把自己打挂？** 降低频率、减轻检查逻辑，避免每次检查都跑迁移或全表扫描。

做完后，你应能在`docker ps`里看到healthy/unhealthy变化，并在上游不健康时挡住下游启动。

> 说明：以下步骤基于 Docker 官方 Dockerfile HEALTHCHECK 文档，于 2026-10-24 核对；Compose 字段名以你安装的 Compose 规格为准。健康检查只反映容器自身探测结果，不能替代网关与监控告警。

## 来源

> \[1] [Dockerfile HEALTHCHECK reference](https://docs.docker.com/reference/dockerfile/#healthcheck)，Docker Docs，核对于2026-10-24。

#Docker #HEALTHCHECK #Compose #教程 #运维

排序方式 :

### **成为第一条评论！**

Nobody's responded to this post yet. Add your thoughts and get the conversation going.

```json
{"@context":"https://schema.org","@graph":[{"@id":"https://www.angryecho.com/c/Docker/p/P2TBBjU5noEpyvsmJdren#post","@type":"DiscussionForumPosting","commentCount":0,"dateModified":"2026-10-27T02:57:49.223Z","datePublished":"2026-10-24T04:00:00.000Z","description":"准备工作 已安装Docker Engine，并能运行docker version。 官方文档：Dockerfile HEALTHCHECK 指令说明见 Docker Docs。[","headline":"发版前用健康检查卡住不健康容器：Dockerfile HEALTHCHECK与compose period","isPartOf":"https://www.angryecho.com/c/Docker","mainEntityOfPage":"https://www.angryecho.com/c/Docker/p/P2TBBjU5noEpyvsmJdren","text":"准备工作\n\n\n\n\n\n已安装Docker Engine，并能运行docker version。  \n\n\n\n官方文档：Dockerfile HEALTHCHECK 指令说明见 Docker Docs。[1]\n\n操作步骤\n\n1、在镜像里声明HEALTHCHECK\n\n做什么：在Dockerfile末尾增加例如：\n\nHEALTHCHECK --interval=30s --timeout=3s --start-period=40s --retries=3 \\\n  CMD curl -f http://127.0.0.1:8080/healthz || exit 1\n\n为什么：编排系统只知道进程在不在；健康检查才告诉你“进程在但服务没好”。[1]\n如何确认：docker build成功后，docker inspect镜像配置里能看到Healthcheck字段。\n\n2、跑起来看状态从starting到healthy\n\n做什么：docker run -d --name demo your:image，然后docker ps观察STATUS里的(health: ...)。\n为什么：start-period内失败不计入retries，避免启动慢被误杀。[1]\n如何确认：就绪后STATUS含(healthy)；故意停掉依赖服务后应变为(unhealthy)。\n\n3、在Compose里对齐interval与依赖顺序\n\n做什么：在compose.yaml服务下写healthcheck:块，并让依赖服务使用depends_on: condition: service_healthy（Compose支持时）。\n为什么：只写depends_on服务名只保证启动顺序，不保证可服务。[1]\n如何确认：docker compose up时，下游服务在上游healthy之后才创建。\n\n4、失败命令要返回非零\n\n做什么：确保CMD在失败时exit 1（如curl -f）。\n为什么：Docker以退出码判断成败。[1]\n如何确认：手动在容器内执行同一CMD，失败时echo $?非0。\n\n\n\n5、把探测路径做成真正的业务就绪检查\n\n做什么：/healthz（或你选的路径）里检查关键依赖：数据库ping、必要配置已加载，而不是只return 200。\n为什么：假健康检查会让编排系统把半残实例继续接流量。[1]\n如何确认：人为断开数据库后，容器在数个interval后变unhealthy。\n\n6、为发布流水线加一道“不健康则失败”\n\n做什么：在CI/CD里docker run后轮询docker inspect --format='{{.State.Health.Status}}'，超时仍非healthy则失败回滚。\n为什么：镜像能构建不等于服务能就绪。\n如何确认：故意弄坏HEALTHCHECK CMD时，流水线变红。\n\n注意事项\n\n\n\n\n\n健康检查不是负载均衡探活的全部；公网探活还要另配。  \n\n\n\n别在HEALTHCHECK里做很重的迁移任务。\n\n常见问题\n\n\n\n\n\n一直卡在starting？ 加大start-period，或检查健康检查是否在服务听端口之前就执行。[1]\n\n\n\nCompose里depends_on不生效？ 确认Compose文件版本支持condition: service_healthy，且拼写无误。\n\n\n\n探活把自己打挂？ 降低频率、减轻检查逻辑，避免每次检查都跑迁移或全表扫描。\n\n做完后，你应能在docker ps里看到healthy/unhealthy变化，并在上游不健康时挡住下游启动。\n\n\n\n说明：以下步骤基于 Docker 官方 Dockerfile HEALTHCHECK 文档，于 2026-10-24 核对；Compose 字段名以你安装的 Compose 规格为准。健康检查只反映容器自身探测结果，不能替代网关与监控告警。\n\n来源\n\n\n\n[1] Dockerfile HEALTHCHECK reference，Docker Docs，核对于2026-10-24。\n\n#Docker #HEALTHCHECK #Compose #教程 #运维","url":"https://www.angryecho.com/c/Docker/p/P2TBBjU5noEpyvsmJdren","author":{"@type":"Person","name":"胡图图","url":"https://www.angryecho.com/u/TYIM12067"},"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/DislikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":0}]}]}
```

## Sitemap

See the full [sitemap](https://www.angryecho.com/sitemap.md) for all pages.