Compose

Docker 健康状态与 Prometheus 的 up 序列来自不同检查。Compose 健康检查在应用容器内运行命令；Prometheus 则独立抓取配置的指标端点，并记录抓取是否成功。两项观察可以合理地不一致，因为应用可能已经无法处理有用工作，却仍能提供指标，也可能业务正常而指标端点损坏。理解区别，才能避免用一个绿灯替代全部服务状态。 坏掉的样子 把 up=1 解释成应用已经就绪，可能掩盖故障。它说明目标指标抓取成功，不说明登录、数据库写入或其他业务操作成功。对于这些问题，需要合适的行为指标或外部探测。自定义就绪 gauge 可以有用，但具体含义必须由应用契约定义，不能仅凭名字叫 ready，就认为它覆盖了所有必需依赖。 反向误解是认为 Docker 健康状态会自动导出到 Prometheus。Compose 中定义 healthcheck，不会自动创建 Prometheus 指标，也不会配置抓取目标。需要 exporter 或应用埋点明确暴露所需观察。即使完成导出，采集路径和新鲜度也与引擎健康状态不同，需要知道更新延迟和失败方式，才能解释不一致。 两种观察都不会自动定义重启或路由动作。Docker 的 restart: always 处理容器终止；容器仍在运行时，不会仅因 unhealthy 就重启。监控可以根据证据告警，明确配置的控制器可以采取动作，但这些连接不会因为两个工具恰好位于同一个 Compose 项目里就凭空出现。观察、告警和修复需要分别验证。 快速验证 使用宿主 Python、Docker Compose 和两个固定镜像运行脚本。实测为 Compose 5.1.1、Docker 29.3.1、Python 3.11.16，以及 Linux arm64 上的 Prometheus 3.5.1。它构建临时 Prometheus 配置镜像，创建唯一项目，只把 Prometheus API 发布到宿主回环地址，结束时清理自身项目、数据卷和标签： ...

Docker Compose 把服务声明转化成以项目管理的容器、网络和存储连接。文件描述有用关系：服务运行哪个镜像，配置如何传入，以及使用哪些存储或网络。复现整套环境仍依赖镜像可用性、变量值、宿主能力和既有数据等外部输入。文件进入版本控制，并不自动固定这些输入；只有把它们识别清楚，声明才真正可审阅、可解释。 坏掉的样子 调用 shell 提供不同变量时，相同 Compose 文本可能解析成不同结果。环境文件参与插值，但不等于其中所有值都会自动注入每个容器。服务级 environment 声明和 env_file 设置有各自作用。应同时检查渲染配置和实际运行服务，不能因为某个文件里写了一个值，就认定它必然是最终生效值。 网络地址也是常见陷阱。Compose 网络中的服务可以通过服务名解析彼此，并使用容器端口；发布到宿主的端口属于另一条访问路径。如果客户端容器请求 localhost，通常请求会回到客户端自身，而不是兄弟 API。硬编码容器 IP 也会让替换更脆弱，稳定服务名更适合表达本来就属于服务关系的目标。 项目生命周期不意味着所有资源具有相同寿命。普通 down 删除项目容器和网络，命名卷则通常保留，除非明确要求删除卷。重建网络会改变其身份，也可能改变分配地址。数据仍在，不代表旧网络仍在；新容器已经创建，也不代表连接的数据卷为空。排查重建行为时，需要分别观察这些资源。 快速验证 使用宿主 Python、Docker Compose 和固定 Python 镜像运行脚本。实测为 Compose 5.1.1、Docker 29.3.1、Linux arm64。生成的 Compose 文档使用 YAML 接受的 JSON 语法，不需要额外 Python 解析器，并采用唯一项目名。API 只发布到宿主回环地址，由引擎自动分配可用端口： ...

Docker Compose 描述服务依赖图，并可以按声明关系启动服务。进程启动只是图中的一种条件：数据库或 API 可能已经运行，却还不能接受其他服务需要的操作。显式 service_healthy 条件让 Compose 在启动依赖方之前，等待被依赖服务的健康检查通过；前提是这个检查确实表达有意义的就绪状态，而不是随意返回成功。 坏掉的样子 简短 depends_on 形式建立启动顺序，却不建立应用就绪保证。用固定 sleep 替代也很脆弱，因为初始化时间会随存储、缓存、迁移和机器负载变化。同一段等待在某次运行中过长，在另一次又不足。条件应来自可以观察的依赖行为，而不是估计已经过去多久；否则构建机变快或变慢，都可能暴露新的偶发故障。 基于健康状态的依赖条件，也不是持续可用性保证。依赖方启动之后，被依赖服务仍可能失败或重启。Compose 不会仅因依赖后来变得不健康，就自动停止或重启已经运行的依赖方。应用仍需要处理连接中断、有界重试，以及操作可能部分完成的情况，不能把启动编排当成完整运行期容错。 嵌套在依赖项里的 restart: true，与服务自身重启策略含义不同。它针对显式 Compose 操作更新或重启依赖后，对依赖方进行相应重启，不是对每一次健康转换或引擎级崩溃的通用订阅。相似字段名容易造成误解，应按照配置层级和文档契约区分，而不是看到 restart 就认为所有失败都会触发。 快速验证 使用宿主 Python、Docker Compose 和固定 Python 镜像运行脚本。实测为 Compose 5.1.1、Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16。脚本用 YAML 接受的 JSON 语法写 Compose 文档，创建唯一项目，所有 HTTP 访问都留在项目网络中。清理只移除该项目，不影响其他服务： ...