Compose · XB 现场笔记

Docker 健康状态与 Prometheus up 回答不同问题

Mon, 21 Feb 2028 00:00:00 +0000

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 发布到宿主回环地址，结束时清理自身项目、数据卷和标签：

from pathlib import Path
from tempfile import TemporaryDirectory
from urllib.parse import urlencode
from urllib.request import urlopen
import json,subprocess,time,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
PROM='prom/prometheus@sha256:38c3b05c3bc744ff1b0b7b4eb82196026442845e62a1e2073795565da506d7a2'
def run(args,check=True):
 result=subprocess.run(args,text=True,capture_output=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def docker(*args,check=True):return run(['docker',*args],check)
def inspect(identity):return json.loads(docker('inspect',identity).stdout)[0]

name='xbcatm-prom-health-'+uuid.uuid4().hex[:10];tag=name+':prometheus'
with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);file=root/'compose.yaml'
 def compose(*args,check=True):return run(['docker','compose','-p',name,'-f',str(file),*args],check)
 def wait(predicate):
 deadline=time.monotonic()+25
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except (OSError,ValueError):pass
 time.sleep(.2)
 raise AssertionError('observation did not become true')
 server='''from http.server import BaseHTTPRequestHandler,HTTPServer
from pathlib import Path
Path('/ready').touch()
class H(BaseHTTPRequestHandler):
 def do_GET(self):
 ready=Path('/ready').exists()
 code=(503 if Path('/broken-metrics').exists() else 200) if self.path=='/metrics' else (200 if ready else 503)
 body=('# TYPE app_ready gauge\\napp_ready '+str(int(ready))+'\\n').encode()
 self.send_response(code);self.send_header('Content-Type','text/plain; version=0.0.4');self.end_headers();self.wfile.write(body)
 def log_message(self,*args):pass
HTTPServer(('0.0.0.0',8080),H).serve_forever()
'''
 (root/'prometheus.yml').write_text('global:\n scrape_interval: 1s\n scrape_timeout: 500ms\nscrape_configs:\n - job_name: app\n static_configs:\n - targets: [app:8080]\n')
 (root/'Dockerfile').write_text(f'FROM {PROM}\nCOPY prometheus.yml /etc/prometheus/prometheus.yml\n')
 health=['CMD','python','-c','import urllib.request;urllib.request.urlopen("http://127.0.0.1:8080/health",timeout=.5).read()']
 file.write_text(json.dumps({'services':{'app':{'image':BASE,'command':['python','-c',server],'restart':'always','healthcheck':{'test':health,'interval':'1s','timeout':'1s','retries':2,'start_period':'3s'}},'prometheus':{'image':tag,'ports':[{'target':9090,'published':'0','host_ip':'127.0.0.1'}],'volumes':['metrics:/prometheus']}},'volumes':{'metrics':{}}},indent=2))
 try:
 docker('build','--network','none','-t',tag,str(root));compose('up','-d')
 app=compose('ps','-q','app').stdout.strip();prometheus=compose('ps','-q','prometheus').stdout.strip()
 port=inspect(prometheus)['NetworkSettings']['Ports']['9090/tcp'][0];assert port['HostIp']=='127.0.0.1'
 endpoint='http://127.0.0.1:'+port['HostPort']
 def value(expression):
 with urlopen(endpoint+'/api/v1/query?'+urlencode({'query':expression}),timeout=2) as response:data=json.load(response)
 result=data['data']['result'];return float(result[0]['value'][1]) if result else None
 wait(lambda:value('up{job="app"}')==1 and value('app_ready')==1 and inspect(app)['State']['Health']['Status']=='healthy')
 time.sleep(11)
 original=inspect(app)
 docker('exec',app,'python','-c','from pathlib import Path;Path("/ready").unlink()')
 wait(lambda:value('up{job="app"}')==1 and value('app_ready')==0 and inspect(app)['State']['Health']['Status']=='unhealthy')
 current=inspect(app);assert current['RestartCount']==0 and current['State']['StartedAt']==original['State']['StartedAt']
 print('Docker unhealthy and app_ready=0 coexist with Prometheus up=1 because the metrics endpoint is still scrapeable')
 docker('exec',app,'python','-c','from pathlib import Path;Path("/broken-metrics").touch()')
 wait(lambda:value('up{job="app"}')==0)
 assert inspect(app)['State']['Running'] and inspect(app)['RestartCount']==0
 print('returning HTTP 503 from /metrics changes up to 0 without stopping or restarting the application')
 finally:
 compose('down','--volumes','--remove-orphans',check=False);docker('image','rm',tag,check=False)

应用通过同一个小型 HTTP 服务提供 /health 与 /metrics。就绪文件控制健康响应和显式定义的 app_ready gauge；另一个文件控制指标请求本身是否返回错误。两个独立开关让实验区分应用状态与抓取可用性，同时使用真正的 Prometheus，不用本地模拟计算替代抓取、存储和查询行为。

Prometheus 每秒抓取 app:8080，使用默认指标路径和半秒抓取超时。Compose 则单独执行应用内部健康命令。控制器先等待健康状态正常、up 为一、app_ready 为一，再让应用继续运行超过初始启动阶段，之后才改变条件。这样后续重启观察不会被过早的启动时机混淆。

删除 /ready 后，/health 返回 HTTP 503，gauge 变为零。两次健康探测失败后，Docker 报告 unhealthy。但 /metrics 仍返回成功响应和有效指标数据，所以 Prometheus 继续记录 up=1。实验通过真实 Docker 检查和 Prometheus 查询接口同时验证三个观察，不只是根据配置推测结果。

应用设置了 restart: always，但启动时间不变，重启次数仍为零，直接证明不健康状态没有触发引擎重启。这个结果对事故判断很有用：进程仍运行、指标处理器仍工作，与就绪契约失败可以同时成立。如果监控只看前两者，就可能在用户已经受影响时仍显示服务正常。

创建 /broken-metrics 后，指标端点也返回 HTTP 503，下一次相关抓取把 up 记录为零，应用进程却继续运行。实验因此把抓取失败与进程退出独立验证。指标路径错误、超时或格式无效，同样可能导致抓取失败，而不能单独证明整个进程已经结束，需要继续检查测量路径和服务状态。

控制器轮询实际状态，不假定两套探测时钟完全对齐。这里的短间隔只用于可丢弃实验，不是通用生产建议。清理只删除自身临时指标卷，因为断言完成后不需要保留其中样本。真实监控数据的保留和删除应按照另外的存储策略处理，不能直接照搬实验清理范围。

按契约与观察路径分别告警

为抓取可用性、应用就绪和用户可见成功保留不同信号。自定义指标需要准确含义和有界标签集合。如果导出 Docker 健康状态，应记录 exporter、目标身份和更新延迟，再验证指标确实对应引擎状态，而不是因为名字相似就认定已经连接。明确采集链路，也有助于定位指标本身失真的原因。

还要区分失败抓取、序列缺失和目标被移除。查询结果为空，不自动等于采样值为零；发现和陈旧标记规则会影响哪些序列仍然存在。告警规则应考虑预期目标清单和可接受观察间隙，否则目标消失时可能反而没有告警，或者把正常发现变化误判为服务故障。

最后，单独测试行动。在拥有相应职责的系统里验证告警路由、流量移除或恢复行为。准确监控应保留这些区别，让操作者能够判断是服务失败、测量路径失败，还是两者同时失败，而不是把所有状态压缩成一个含义不清的健康标签。

来源

Compose healthcheck and restart settings，容器探测配置与服务重启策略，已核验 2026-09-12。
Prometheus jobs and instances，描述抓取成功与否的 up 序列，已核验 2026-09-12。
Prometheus scrape configuration，抓取目标、路径、间隔与超时，已核验 2026-09-12。
Docker restart policies，针对容器终止的重启行为，已核验 2026-09-12。

Compose 项目把资源声明与外部输入组合起来

Wed, 18 Aug 2027 00:00:00 +0000

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 只发布到宿主回环地址，由引擎自动分配可用端口：

from pathlib import Path
from tempfile import TemporaryDirectory
from urllib.request import urlopen
import json,os,subprocess,time,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def run(args,check=True,env=None):
 result=subprocess.run(args,text=True,capture_output=True,timeout=120,env=env)
 if check:assert result.returncode==0,result.stderr
 return result
def docker(*args,check=True):return run(['docker',*args],check)

name='xbcatm-project-'+uuid.uuid4().hex[:10];environment=os.environ.copy();environment.pop('TASK_COMPOSE_GREETING',None)
with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);file=root/'compose.yaml'
 def compose(*args,check=True,env=None):return run(['docker','compose','-p',name,'--env-file',str(root/'.env'),'-f',str(file),*args],check,env or environment)
 def container(service):return compose('ps','-q',service).stdout.strip()
 def inspect(identity):return json.loads(docker('inspect',identity).stdout)[0]
 def request():
 port=inspect(container('api'))['NetworkSettings']['Ports']['8080/tcp'][0]
 assert port['HostIp']=='127.0.0.1'
 deadline=time.monotonic()+10
 while time.monotonic()<deadline:
 try:
 with urlopen('http://127.0.0.1:'+port['HostPort'],timeout=1) as response:return response.read().decode()
 except OSError:time.sleep(.1)
 raise AssertionError('published endpoint unavailable')
 server='from http.server import BaseHTTPRequestHandler,HTTPServer\nimport os\nclass H(BaseHTTPRequestHandler):\n def do_GET(self):self.send_response(200);self.end_headers();self.wfile.write(os.environ["GREETING"].encode())\n def log_message(self,*args):pass\nHTTPServer(("0.0.0.0",8080),H).serve_forever()\n'
 spec={'services':{'api':{'image':BASE,'command':['python','-c',server],'environment':{'GREETING':'${TASK_COMPOSE_GREETING:-default}'},'ports':[{'target':8080,'published':'0','host_ip':'127.0.0.1'}],'volumes':['state:/state']},'client':{'image':BASE,'command':['python','-c','import time;time.sleep(180)']}},'volumes':{'state':{}}}
 file.write_text(json.dumps(spec,indent=2));(root/'.env').write_text('TASK_COMPOSE_GREETING=from-file\n')
 try:
 rendered=json.loads(compose('config','--format','json').stdout);assert rendered['services']['api']['environment']['GREETING']=='from-file'
 override=environment|{'TASK_COMPOSE_GREETING':'from-shell'}
 rendered=json.loads(compose('config','--format','json',env=override).stdout);assert rendered['services']['api']['environment']['GREETING']=='from-shell'
 compose('up','-d',env=override);assert request()=='from-shell'
 api=container('api');client=container('client');first_network=next(iter(inspect(api)['NetworkSettings']['Networks'].values()))['NetworkID']
 result=docker('exec',client,'python','-c','import urllib.request;print(urllib.request.urlopen("http://api:8080",timeout=2).read().decode())')
 assert result.stdout.strip()=='from-shell'
 docker('exec',client,'python','-c','import socket;s=socket.socket();assert s.connect_ex(("127.0.0.1",8080))!=0;s.close()')
 docker('exec',api,'python','-c','from pathlib import Path;Path("/state/record").write_text("preserved")')
 volume=next(m['Name'] for m in inspect(api)['Mounts'] if m['Destination']=='/state')
 assert volume==name+'_state'
 compose('down');assert docker('network','inspect',first_network,check=False).returncode!=0
 assert docker('volume','inspect',volume,check=False).returncode==0
 compose('up','-d',env=override);assert request()=='from-shell'
 api=container('api');assert next(iter(inspect(api)['NetworkSettings']['Networks'].values()))['NetworkID']!=first_network
 docker('exec',api,'python','-c','from pathlib import Path;assert Path("/state/record").read_text()=="preserved"')
 assert docker('exec',container('client'),'python','-c','import urllib.request;print(urllib.request.urlopen("http://api:8080",timeout=2).read().decode())').stdout.strip()=='from-shell'
 print('shell interpolation overrides .env; internal clients resolve api:8080 while localhost remains their own container')
 print('the host endpoint is published only on loopback; down/up recreates the project network and retains the named data volume')
 finally:compose('down','--volumes','--remove-orphans',check=False)

私有环境文件提供 TASK_COMPOSE_GREETING=from-file。脚本显式选择这个文件，并先从调用环境中移除同名变量。compose config --format json 把服务的 GREETING 解析成 from-file；随后在调用环境提供 from-shell，渲染值变为后者。这直接验证本次使用的插值优先级，也避免工作目录中其他环境文件干扰实验。

采用覆盖值启动项目后，API 返回 from-shell。宿主请求使用容器检查发现的实际发布端口，并断言绑定地址为 127.0.0.1。这同时验证有效配置和预期暴露范围。仅仅成功渲染文档，不能证明容器真的以该值运行，也不能证明端口按预期绑定，因此实验还检查了运行结果。

客户端服务通过 Compose 网络请求 http://api:8080，成功得到相同响应；请求自己回环地址的 8080 端口则失败。这两项观察区分了服务名发现、宿主端口发布和容器本地回环。应用请求没有嵌入固定容器 IP，因此后续网络重建时仍能表达同一逻辑目标，而不依赖旧地址碰巧被复用。

API 向命名状态卷写入标记。普通 compose down 之后，检查确认旧网络已不存在，命名卷却仍存在。再次启动项目，网络身份不同，卷内标记仍可读取，客户端也仍通过相同服务名访问 API。这里分别检查网络和数据，避免只看服务响应成功，就忽略底层资源到底保留了什么。

最终清理包含 --volumes，因为本实验数据都可以丢弃。这个选项比前面用于验证保留行为的普通 down 具有更大的删除范围。在真实环境中，只有确实希望删除这些卷时才应使用，不能随手加到每次重启或排错命令末尾。理解默认生命周期，也包括理解哪些显式选项会改变它。

记录真正影响项目的输入

明确必需变量名、镜像摘要、存储所有权和暴露端口。在目标执行环境中先渲染配置，但不要公开含有凭据的渲染输出。固定镜像可以减少一类漂移，却不能冻结宿主架构、挂载文件、运行配置或持久数据库内容。记录输入的目的，是知道哪些部分已经固定，哪些仍需要独立管理。

需要资源隔离的本地或 CI 实验，可以使用不同项目名。显式命名的外部网络和卷能够有意跨越项目边界，因此应审阅这些引用，不能认定项目名不同就隔离了全部连接。端口绑定也可能在其他方面独立的项目之间冲突，需要把宿主级资源纳入配置检查。

Compose 除了本地测试，也可以支持受到管理的单机部署。是否适合取决于运维要求，不应一概声称不能用于生产。宿主冗余、更新协调、备份、就绪和监控，仍需要明确方案。声明的价值在于提供清楚、可测试、边界已知的资源模型，而不是仅凭一份文件就消除所有运行差异。

来源

Compose services reference，服务配置、环境、端口和卷挂载，已核验 2026-09-12。
Networking in Compose，项目网络与服务名发现，已核验 2026-09-12。
Compose variable interpolation，shell 与环境文件的插值优先级，已核验 2026-09-12。
Docker compose down，网络删除与可选卷删除，已核验 2026-09-12。

Compose 启动顺序需要明确的就绪条件

Thu, 08 Apr 2027 00:00:00 +0000

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 访问都留在项目网络中。清理只移除该项目，不影响其他服务：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,time,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def run(args,check=True):
 result=subprocess.run(args,text=True,capture_output=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def docker(*args,check=True):return run(['docker',*args],check)
def inspect(name):return json.loads(docker('inspect',name).stdout)[0]

name='xbcatm-depends-'+uuid.uuid4().hex[:10]
with TemporaryDirectory(prefix=name+'-') as directory:
 file=Path(directory)/'compose.yaml';base=['docker','compose','-p',name,'-f',str(file)]
 def compose(*args,check=True):return run(base+list(args),check)
 def service_id(service):
 return docker('ps','-aq','--filter','label=com.docker.compose.project='+name,'--filter','label=com.docker.compose.service='+service).stdout.strip()
 def wait(predicate):
 deadline=time.monotonic()+20
 while time.monotonic()<deadline:
 result=predicate()
 if result:return result
 time.sleep(.1)
 raise AssertionError('condition did not become true')
 server='from http.server import BaseHTTPRequestHandler,HTTPServer\nfrom pathlib import Path\nclass H(BaseHTTPRequestHandler):\n def do_GET(self):self.send_response(200 if Path("/ready").exists() else 503);self.end_headers()\n def log_message(self,*args):pass\nHTTPServer(("0.0.0.0",8080),H).serve_forever()\n'
 health=['CMD','python','-c','import urllib.request;urllib.request.urlopen("http://127.0.0.1:8080",timeout=.5).read()']
 application='import urllib.request,time;urllib.request.urlopen("http://dependency:8080",timeout=2).read();print("started-after-ready",flush=True);time.sleep(180)'
 file.write_text(json.dumps({'services':{'dependency':{'image':BASE,'command':['python','-c',server],'healthcheck':{'test':health,'interval':'1s','timeout':'1s','retries':2,'start_period':'30s'}},'application':{'image':BASE,'command':['python','-c',application],'depends_on':{'dependency':{'condition':'service_healthy'}}}}},indent=2))
 process=None
 try:
 process=subprocess.Popen(base+['up','-d'],text=True,stdout=subprocess.PIPE,stderr=subprocess.PIPE)
 dependency=wait(lambda:service_id('dependency'))
 wait(lambda:inspect(dependency)['State']['Running'])
 assert inspect(dependency)['State']['Health']['Status']=='starting'
 application_id=service_id('application')
 assert not application_id or not inspect(application_id)['State']['Running']
 assert process.poll() is None
 docker('exec',dependency,'python','-c','from pathlib import Path;Path("/ready").touch()')
 stdout,stderr=process.communicate(timeout=30);assert process.returncode==0,stderr
 application_id=service_id('application');wait(lambda:'started-after-ready' in docker('logs',application_id).stdout)
 original=inspect(application_id);assert original['State']['Running']
 assert inspect(dependency)['State']['Health']['Status']=='healthy'
 docker('exec',dependency,'python','-c','from pathlib import Path;Path("/ready").unlink()')
 wait(lambda:inspect(dependency)['State']['Health']['Status']=='unhealthy')
 after=inspect(application_id);assert after['State']['Running'] and after['State']['StartedAt']==original['State']['StartedAt'] and after['RestartCount']==0
 print('service_healthy keeps the dependent application stopped until the dependency probe succeeds')
 print('later dependency health failure does not stop or restart the already-running dependent application')
 finally:
 if process is not None and process.poll() is None:process.terminate();process.communicate(timeout=10)
 compose('down','--volumes','--remove-orphans',check=False)

依赖服务运行 HTTP 服务器，在 /ready 出现前一直返回 503，健康检查请求真实端点。三十秒启动宽限让控制器有时间读取初始状态，避免早期失败马上耗尽两次失败阈值。应用声明 condition: service_healthy，并在真正启动后再自行发起 HTTP 请求，使声明条件与实际连接行为可以对照。

控制器异步启动 compose up -d，观察依赖进程已运行，但健康状态仍是 starting。此时应用要么尚未创建，要么还未运行，Compose 命令也仍在等待。实验接受这两种创建细节，因为需要验证的是依赖方启动受到条件限制，而不是绑定某一种中间容器分配顺序。这样断言对应稳定契约，而不是偶然实现顺序。

创建 /ready 后，依赖端点返回 200。Compose 成功完成启动，应用只有在自身请求成功后才打印 started-after-ready。这把声明条件连接到真正可达的行为。如果依赖方无法通过实际网络访问目标，仅仅看到健康标签变绿，证据就不够完整；实验因此同时检查了依赖服务内部探测和依赖方请求。

随后删除 /ready，经过足够失败探测，依赖变为 unhealthy。应用仍然运行，启动时间相同，重启次数为零。这是关键反例：曾经满足启动条件，不意味着 Compose 会持续让依赖方生命周期与后续健康状态同步。服务已经启动与服务能够继续完成业务，是需要分别观测的事实。

应用在首次请求后特意进入睡眠，以便独立观察进程寿命。它不是生产客户端实现，实验也没有声称睡眠状态证明依赖故障期间业务操作仍能成功。实际结论仅是 Compose 没有主动处理这个已存在的依赖方进程。限制结论范围，能避免把测试用于它并未覆盖的业务恢复能力。

一起设计启动条件和运行期处理

真正只要求进程启动时使用 service_started；具有有效健康检查的就绪要求使用 service_healthy；适当的一次性前置任务则使用成功完成条件。迁移任务成功退出，与长时间运行数据库就绪，回答的是不同问题。选择匹配前置要求的条件，并保留不满足时的有用错误输出，不能靠无限等待隐藏失败。

就绪检查应便宜且具体。TCP 监听可能已经存在，认证、表结构初始化或必需数据却还未完成。反过来，把所有非必需下游都加入检查，也可能阻止本来能提供有用功能的服务启动。检查需要表达被约束服务真正需要的最小依赖契约，而不是越多越保险的任意检查集合。

运行后，在应用和运维控制中处理依赖变化：限制重试，避免重复非幂等操作，并测试目标替换后的重新连接。Compose 能协调可重复的启动顺序，但持续正确性仍取决于服务真实通信和失败语义。把这些职责分别实现并验证，才能避免一次启动成功掩盖长期运行问题。

来源

Control startup order in Compose，已启动、健康和成功完成等依赖条件，已核验 2026-09-12。
Compose services reference，depends_on 条件与显式 Compose 重启行为，已核验 2026-09-12。
Dockerfile HEALTHCHECK，探测状态、启动宽限与连续失败计数，已核验 2026-09-12。

Compose · XB 现场笔记

Docker 健康状态与 Prometheus up 回答不同问题

坏掉的样子

快速验证

按契约与观察路径分别告警

延伸阅读

来源

Compose 项目把资源声明与外部输入组合起来

坏掉的样子

快速验证

记录真正影响项目的输入

来源

Compose 启动顺序需要明确的就绪条件

坏掉的样子

快速验证

一起设计启动条件和运行期处理

来源