Docker · 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。

Docker 构建缓存复用已记录的工作，也可能复用过期结果

Sun, 20 Feb 2028 00:00:00 +0000

Docker 构建缓存保存构建操作的结果，让后续构建在相关输入仍匹配时复用已有工作。缓存命中不表示命令重新运行并生成相同输出，而是构建器接受了一份先前结果。这个区别直接影响软件包安装、生成时间戳、远程下载，以及输出可能变化却没有相应声明输入变化的操作。理解缓存时，首先要区分“再次执行”和“取出已经执行过的结果”。

坏掉的样子

没有变化的 RUN apt-get update 可以直接复用昨天的结果，完全不访问软件仓库。构建器通常不会为了判断这条 RUN 是否仍然新鲜，先检查远端仓库有没有更新。因此，缓存构建成功不能独立证明软件包已经收到最新安全修复。刷新策略必须明确，并与项目要求的可复现性一致，不能依赖某次构建恰好缓存失效。

COPY 的输入不同于普通命令字符串。文件内容和相关元数据参与缓存计算，但源文件修改时间本身不参与。部署脚本如果只是 touch 文件，依赖它的 RUN 仍可能继续命中缓存。反过来，即使文本完全相同，改变可执行权限也可能使 COPY 失效，从而重新执行后续工作。排查时需要比较实际输入，不能只看文件大小和肉眼可见的文字。

基础镜像、步骤实际使用的构建参数和前置依赖也会影响结果。缓存失效沿依赖传播，不能把复杂多阶段构建一律解释成从某行开始全部重做的直线。下面使用简单的单阶段链：复制文件发生变化，就使其后的时间戳 RUN 重新执行，而固定基础镜像的文件系统层仍可继续复用。这种受控结构让实验结论容易对应到真实原因。

快速验证

使用宿主 Python 运行脚本，并连接一个可用于实验的 Docker 构建器。如果本地没有指定摘要，先拉取它。实测环境是 Docker 29.3.1、Buildx 0.32.1，以及 Linux arm64 的 Python 3.11.16 基础镜像。构建和容器均关闭网络。脚本删除自己的临时标签，不清理其他镜像，也不对全局构建缓存执行 prune：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,shlex,subprocess,uuid

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

name='xbcatm-cache-'+uuid.uuid4().hex[:10];tag=name+':probe'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);app=root/'app.txt';app.write_text('initial '+name);app.chmod(0o644)
 build_code="from pathlib import Path;import time;Path('/built-at').write_text(str(time.time_ns()))"
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY app.txt /app.txt\nRUN python -c {shlex.quote(build_code)}\n')
 def build(*options):return docker('build','--network','none','--progress','plain',*options,'-t',tag,str(root))
 def stamp():return docker('run','--rm','--network','none',tag,'python','-c',"from pathlib import Path;print(Path('/built-at').read_text())").stdout.strip()
 build();initial=stamp();base_layers=inspect(BASE)['RootFS']['Layers']
 result=build();assert stamp()==initial and 'CACHED' in result.stderr
 timestamp=app.stat().st_mtime_ns+10_000_000_000;os.utime(app,ns=(timestamp,timestamp))
 build();assert stamp()==initial
 print('unchanged inputs reuse the RUN result; changing only source mtime also leaves that result cached')
 app.chmod(0o755);build();mode_changed=stamp();assert mode_changed!=initial
 app.write_text('changed '+name);build();content_changed=stamp();assert content_changed!=mode_changed
 print('changing copied-file permissions or content invalidates COPY and reruns the dependent RUN')
 build('--no-cache');assert stamp()!=content_changed
 assert inspect(tag)['RootFS']['Layers'][:len(base_layers)]==base_layers
 print('no-cache reruns the instruction while this pinned base retains the same filesystem layer prefix')
finally:docker('image','rm',tag,check=False)

首次构建把纳秒时间戳写进 /built-at。第二次用相同输入构建，日志出现缓存操作，镜像中的时间戳也完全相同。这比比较构建耗时更有说服力：命令可能执行得很快，但保留下来的同一个时间戳表明，这里复用了之前记录的结果。测试同时看日志和目标文件，避免把其他步骤命中缓存误认为目标 RUN 命中。

随后脚本只推进源文件的修改时间，镜像内时间戳保持不变。这直接验证文档所说的 mtime 排除规则，不代表所有文件元数据都被忽略。接着把模式从 0644 改为 0755，时间戳更新，证明本次 COPY 依赖会受到可执行位变化的影响。两步只改变一个因素，能够区分时间与权限的不同作用。

再修改文件文本，会得到另一个时间戳。输入中包含本次实验的唯一名字，避免以前的同类实验碰巧提供初始应用结果。每一步都读取实际镜像内容进行断言，而不是看到构建日志任意位置有 CACHED 就宣布被研究的操作已经复用。对于多条 RUN 的真实项目，也应采用能定位具体步骤的证据。

最后，应用输入保持不变，使用 --no-cache 后 RUN 再次执行。镜像检查仍显示与原来相同的固定基础层前缀。这个选项禁止构建指令复用缓存，不会把明确选择的基础摘要自动替换成另一个新版本。需要更新基础镜像时，应选择预期的新产物；浮动标签是否重新查询，则还涉及单独的拉取策略。

把新鲜度变成明确输入

让稳定的依赖输入先于频繁修改的源码，并通过窄范围 COPY 避免无关文件成为依赖。如果要求重复得到受控结果，就固定软件包版本或经过校验的下载产物。需要主动刷新依赖时，更新这些声明并审阅产物，不应把“这次没有命中缓存”本身当作安全更新策略，因为远端内容和安装规则仍可能不可控。

密钥挂载还需要单独考虑：密钥内容变化不会自动使构建缓存失效。如果密钥影响一次需要刷新的下载，可以使用明确的非敏感修订输入，或显式要求相关步骤重新执行。不要为了改变缓存键，把真实凭据塞进构建参数；缓存控制与凭据传递有不同的安全边界，不应混在一个字段里处理。

缓存命中日志说明性能方面的复用，真正执行的测试说明行为。记录最终产物身份，测试该产物，并保留足以解释它如何生成的构建输入。快速重建只有在复用的工作仍符合本次发布意图时才有价值；否则，速度只是把陈旧结果更快地交给了下一阶段。

来源

Docker build cache invalidation，缓存输入、修改时间、RUN 复用与显式失效，已核验 2026-09-12。
Dockerfile reference，COPY 元数据、RUN 指令与构建参数，已核验 2026-09-12。

ENTRYPOINT 和 CMD 定义可被运行者覆盖的启动默认值

Sun, 03 Oct 2027 00:00:00 +0000

镜像的 ENTRYPOINT 和 CMD 共同参与容器创建时的启动命令。使用 exec 形式 ENTRYPOINT 时，CMD 通常提供追加给入口的默认参数；没有入口时，CMD 可以提供可执行程序及其参数。这些是启动默认值，不是强制执行边界。有权限创建容器的运行者，可以替换入口或参数，因此不能把 ENTRYPOINT 描述成无论如何都不可改变的程序锁。

坏掉的样子

在 docker run image ... 中写到镜像名之后的参数，会替换 CMD，不是自动加到原 CMD 默认值之后。exec 形式入口仍然保留，除非显式覆盖。用户以为自己只是追加一个选项，却可能丢掉全部默认参数。因此，命令行工具需要说明哪些值可省略、哪些必须重新提供，以及自身参数解析器如何处理覆盖。

exec 形式使用 JSON 数组，不会隐式运行 shell。$DEMO 这样的字符串会原样传给程序，而不是自动展开环境变量。管道、重定向和通配符也需要真正的解释器，才会获得相应含义。shell 形式会改变参数和进程语义，所以两种形式之间的切换并不只是语法美化，不能只看命令表面似乎相同。

启动包装脚本还可能让服务藏在不转发停止信号的 shell 后面。Docker 通常向容器主进程发送停止信号，等待配置的超时，必要时强制终止。即使服务自身正确安装了 SIGTERM 处理函数，如果信号只到达另一个不会转发的进程，这个处理函数也无法发挥作用。排查优雅退出失败时，应先确认信号实际发给了谁。

快速验证

先取得固定基础镜像，再用宿主 Python 和 Docker 构建器运行脚本。实测为 Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16。实验创建独立临时容器并关闭网络，等待每个服务打印就绪信息后测试停止，结束时删除自己的容器和镜像标签，不依赖启动后盲目等待固定时长来猜测服务已经准备好：

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

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

name='xbcatm-entrypoint-'+uuid.uuid4().hex[:10];tag=name+':probe';containers=[name+'-exec',name+'-child']
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory)
 (root/'args.py').write_text('import json,sys\nprint(json.dumps(sys.argv[1:]))\n')
 (root/'service.py').write_text('import json,os,signal\ndef stop(signum,frame):\n print("stopped",flush=True)\n raise SystemExit(0)\nsignal.signal(signal.SIGTERM,stop)\nprint(json.dumps({"pid":os.getpid()}),flush=True)\nwhile True:signal.pause()\n')
 (root/'exec.sh').write_text('#!/bin/sh\nexec python /service.py "$@"\n')
 (root/'child.sh').write_text('#!/bin/sh\npython /service.py "$@" &\nwait $!\n')
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY args.py service.py exec.sh child.sh /\nRUN chmod +x /exec.sh /child.sh\nENV DEMO=expanded\nENTRYPOINT ["python", "/args.py"]\nCMD ["default", "$DEMO"]\n')
 docker('build','--network','none','-t',tag,str(root))
 assert json.loads(docker('run','--rm','--network','none',tag).stdout)==['default','$DEMO']
 assert json.loads(docker('run','--rm','--network','none',tag,'changed').stdout)==['changed']
 assert docker('run','--rm','--network','none','--entrypoint','python',tag,'-c','print("override")').stdout.strip()=='override'
 assert docker('run','--rm','--network','none','--entrypoint','/bin/sh',tag,'-c','printf "%s" "$DEMO"').stdout=='expanded'
 print('CMD supplies literal default arguments; trailing arguments replace it; --entrypoint replaces the executable')
 for container,wrapper in zip(containers,['/exec.sh','/child.sh']):
 docker('run','-d','--name',container,'--network','none','--entrypoint',wrapper,tag)
 deadline=time.monotonic()+10
 while time.monotonic()<deadline:
 logs=docker('logs',container).stdout
 if logs.strip():break
 time.sleep(.05)
 else:raise AssertionError('service did not become ready')
 pid=json.loads(logs.splitlines()[0])['pid']
 assert (pid==1)==(wrapper=='/exec.sh')
 docker('stop','--time','1',container)
 state=inspect(container)['State'];logs=docker('logs',container).stdout
 if wrapper=='/exec.sh':assert state['ExitCode']==0 and 'stopped' in logs
 else:assert state['ExitCode']==137 and 'stopped' not in logs
 print('exec makes the handler PID 1 and stops cleanly; the non-forwarding shell wrapper leaves its child unnotified until forced termination')
finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',tag,check=False)

第一部分让镜像命令打印收到的参数列表。不加覆盖时，它收到 default 和字面的 $DEMO，尽管镜像把 DEMO 定义为 expanded。在镜像名后提供 changed，会替换两个默认参数，程序最终只收到一个参数。这些断言检查实际参数向量，避免仅凭 Dockerfile 的外观推测启动结果。

使用 --entrypoint python 并提供明确的 Python 参数，可以运行另一条命令，输出 override。显式调用 /bin/sh -c 则会展开 $DEMO，输出 expanded。两组结果共同说明 ENTRYPOINT 可以被覆盖，也说明变量展开属于被调用的 shell，而不是 exec 形式内部隐藏的自动处理步骤。

第二部分比较两个启动同一服务的包装脚本。exec 版本用 Python 替换自身，服务报告容器内 PID 为一。Docker 停止容器时，已安装的 SIGTERM 处理函数打印 stopped，随后以零状态退出。实验同时核对日志消息和退出码，证明信号实际到达了服务，并走过被设计的结束路径。

另一个包装脚本把 Python 作为子进程启动，自己等待，却不转发信号。服务报告的 PID 不是一。使用一秒停止超时后，本次环境记录退出码 137，服务也没有打印 stopped。这里直接观察了强制终止结果，不是仅仅因为看到 shell 脚本存在，就断言服务一定无法优雅停止；具体包装方式和处理规则才决定行为。

Linux PID 命名空间中的 PID 一具有特殊的信号和子进程回收责任。exec 包装脚本可以让服务成为信号接收者，但不会自动实现应用清理、排空在途工作，或回收任意后代进程。服务仍需要合适的行为；如果其进程模型需要初始化或监督机制，应明确选择并测试，而不是认为写上 exec 就完成全部退出设计。

把启动和停止视为同一个接口

exec 形式应使用有效 JSON 数组和双引号字符串。明确可执行程序及稳定参数，并说明调用方如何替换默认值。如果初始化必须使用 shell 包装，而包装脚本最后要把控制权交给单个前台服务，就用适当的 exec 完成交接。转发参数时保留引号，避免原来的参数边界在脚本中再次被拆分。

测试真实部署入口，包括编排配置提供的覆盖。正确的镜像入口可能被配置替换成另一层 shell，覆盖命令也可能遗漏必要初始化。应检查实际进程树，并在具有代表性的活动工作下执行终止验证。只测试一个立即退出的打印命令，无法证明长时间运行服务的停止路径正确。

按照服务契约选择停止信号和宽限时间，分别记录就绪、清理成功和退出状态。容器经过 SIGKILL 最终消失，确实说明它已经停止，但单凭这个观察，不能证明请求完成或缓冲状态被安全处理。只有对应业务结束条件的证据，才能支持“优雅退出已经通过”的结论。

来源

Dockerfile ENTRYPOINT and CMD，exec 与 shell 形式、参数组合以及入口覆盖，已核验 2026-09-12。
Docker container stop，停止信号、等待超时与强制终止，已核验 2026-09-12。
pid_namespaces(7)，命名空间初始进程的信号规则及成员终止，已核验 2026-09-12。

镜像标签可以移动，既有容器仍保留原先选择的镜像

Tue, 24 Aug 2027 00:00:00 +0000

镜像标签是与镜像引用关联的可读名字。如果仓库策略没有禁止重新指派，同一个标签之后可以标识另一个产物。v1.4 和 latest 的区别首先是命名惯例，而不是前者天然不可变。要复现部署，需要记录实际选择的产物，以及影响行为的平台和运行配置。只保存一个看起来像版本号的名字，并不足以证明当时运行的是哪些内容。

坏掉的样子

latest 不会要求仓库寻找最新上传镜像或最高语义版本，它是在引用省略标签时采用的惯例默认值。发布另一个版本，不会自动移动 latest；必须有人或自动化更新这个具体引用。如果把每次 push 都解释成自动更新 latest，就会错误理解发布流程，甚至误判为什么一个节点仍然取得旧版本。

标签的本地解析结果，也可能不同于仓库当前结果。拉取策略、本地镜像是否存在，以及编排工具的行为，共同决定何时查询仓库。因此，两台机器运行相同可读标签，仍可能使用不同产物。仅记录命令文本，会留下实际取回什么、是否保留缓存引用等不确定性；排查时应读取所选产物身份。

移动标签不会改写已经创建的容器所选择的镜像。重启该容器，会保留原配置的镜像和可写状态，不会按照标签的新目标重新创建实例。如果更新流程只是重新打标签，然后 restart 旧容器，命令可能成功，应用却仍运行旧内容。标签更新、容器替换和容器重启需要分别判断，不能混成同一个动作。

快速验证

先取得固定基础镜像，再用 Python 和 Docker 构建器运行脚本。实测环境是 Docker 29.3.1、Linux arm64。所有标签使用独特的本地名字，不向仓库推送任何内容；容器关闭网络，清理只删除实验自己的容器与标签。因此可以实际验证移动行为，又不改变已有发布引用：

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

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

name='xbcatm-tags-'+uuid.uuid4().hex[:10];tags=[name+':one',name+':two',name+':release',name+':latest'];container=name+'-old'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory)
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY version.txt /version.txt\nCMD ["cat", "/version.txt"]\n')
 for tag,version in zip(tags,['one','two']):
 (root/'version.txt').write_text(version+'\n');docker('build','--network','none','-t',tag,str(root))
 one=inspect(tags[0])['Id'];two=inspect(tags[1])['Id'];assert one!=two
 docker('image','tag',tags[0],tags[2]);docker('image','tag',tags[0],name)
 assert inspect(tags[2])['Id']==inspect(tags[3])['Id']==one
 docker('create','--name',container,'--network','none',tags[2])
 docker('image','tag',tags[1],tags[2])
 assert inspect(tags[2])['Id']==two and inspect(tags[3])['Id']==one
 assert inspect(container,'container')['Image']==one
 assert docker('start','--attach',container).stdout.strip()=='one'
 assert docker('run','--rm','--network','none',tags[2]).stdout.strip()=='two'
 assert docker('run','--rm','--network','none',tags[3]).stdout.strip()=='one'
 print('moving release changes newly created containers; the existing container still runs its original image')
 print('omitting a tag selected latest, but updating release did not update latest')
 docker('image','rm',tags[2]);assert inspect(tags[1])['Id']==two
 print('removing one tag leaves another reference to the same image intact; all operations stayed local')
finally:
 docker('rm','-f',container,check=False);docker('image','rm',*tags,check=False)

脚本构建两个镜像，/version.txt 分别包含 one 与 two，镜像身份不同。它先让 release 指向第一份镜像，再用没有显式标签的仓库名标记同一镜像。检查确认，省略标签会得到 latest，而这两个引用最初都选择第一份镜像。这里直接验证默认标签规则，不靠名字含义猜测。

移动 release 之前，脚本从该引用创建一个容器，但暂不启动。随后把 release 移到第二份镜像。此时 release 选择新产物，latest 仍选择第一份。实验把标签重新指派与默认标签惯例分开，说明相关名字不会自动一起移动；如果生产流程会同时更新多个标签，那是流程自身明确执行的行为。

启动先前创建的容器，输出 one；从 release 新建容器，输出 two；从 latest 新建容器，则输出 one。容器检查也保留最初所选的镜像身份。这些断言对照实际运行结果，因此不只是根据标签表的显示推理。尤其是“创建后尚未运行”的旧容器，仍然不会因标签移动而更换镜像。

删除 release 标签后，第二份镜像仍通过 two 标签可用。标签是引用，删除一个引用，不一定删除共享内容或所有其他名字。实际回收取决于剩余引用和引擎存储规则；本实验不会清理构建缓存，也不测量物理空间回收。不能把取消一个标签直接当作磁盘上的全部层已经消失。

实验比较当前引擎返回的身份，但不假定 inspect 的 Id 在所有版本和存储方式下都等于 OCI 配置摘要。现代镜像存储可能暴露不同对象层次。仓库索引、平台清单、镜像配置和层数据，各自都有摘要，所以说明身份时应保留对象类型与引用上下文。相同哈希格式不能代替对象含义。

提升经过测试的同一产物

通过仓库部署时，从发布流程记录带仓库名的摘要引用。摘要可能标识包含多个平台清单的镜像索引，因此仍要选择预期平台。保留对应产物及其必需数据，才能让后续回滚真正拉取成功；单独保存哈希无法恢复已经不可取得的内容。产物身份确定与产物持续可用，是不同的要求。

标签可以继续用于人类查找。如果发布流程承诺版本标签永不移动，就应配置并验证仓库的不可变策略，而不是看到版本形状就认定承诺成立。固定摘要也不会证明作者是谁或软件安全，来源证明与行为验证分别回答这些问题。内容寻址解决的是选择哪份对象，不会替代整个发布审查。

部署后，把运行工作负载选择的产物及其预期行为，与发布记录逐一对照。标签已更新、拉取成功和容器正在运行，是三个独立观察。只有把它们连接到同一份通过验证的产物，才能确认本次发布真正生效，而不是仅仅完成了若干看起来相关的命令。

来源

Docker image tag，本地标签创建与默认 latest 标签，已核验 2026-09-12。
Docker image pull，按标签或摘要拉取仓库产物，已核验 2026-09-12。
OCI image index 1.1.1，索引引用不同平台镜像清单的结构，已核验 2026-09-12。
OCI image manifest 1.1.1，清单对配置与层对象的引用，已核验 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。

先复制依赖输入，再复制应用代码

Tue, 17 Aug 2027 00:00:00 +0000

Dockerfile 顺序决定昂贵构建操作依赖哪些先前输入。如果应用源码在依赖安装之前被复制，即使依赖声明未变，修改源码也可能让安装重跑。先复制依赖输入、安装依赖，再复制应用代码，可以建立更小的依赖边界，让它与安装器真正需要的工作匹配。这里优化的是依赖关系，而不只是把几行命令挪到看起来更整齐的位置。

坏掉的样子

在软件包安装前使用宽泛的 COPY . .，会让文档、生成输出或无关源码编辑，都可能成为重做昂贵工作的原因。问题不在于 COPY 天生很慢，而在于后续安装依赖了一份包含无关变化的文件系统状态。这些变化并不是选择和安装依赖所必需，却通过前置步骤扩大了失效范围。

如果安装还读取锁文件、本地包源码、补丁、工作区元数据或包管理器配置，仅复制一个清单也不够。遗漏真实输入，可能保留已经不符合构建意图的缓存结果。正确边界必须包含安装器实际使用的全部输入，而不是只选择常见 Dockerfile 示例里出现的某个文件名。否则，表面命中率提高，实际正确性却下降。

缓存顺序也不能修复可变依赖。相同安装命令可能一直保留旧结果，而干净构建却从远端解析到不同内容。固定版本和校验哈希解决产物选择问题，控制 COPY 顺序解决复用问题。两者都需要处理，构建更快并不能证明软件包图可复现，也不能证明依赖已经更新到本次发布要求的版本。

快速验证

使用宿主 Python、Docker 构建器和已取得的固定基础镜像运行脚本。它先通过 HTTPS 下载两个公开的 idna wheel，并在构建前验证固定 SHA-256。容器构建关闭网络，pip 从本地 wheel 目录安装，并强制要求哈希。实测环境为 Docker 29.3.1，Linux arm64 基础镜像内 Python 为 3.11.16：

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

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
WHEELS={
 '3.10':('https://files.pythonhosted.org/packages/76/c6/c88e154df9c4e1a2a66ccf0005a88dfb2650c1dffb6f5ce603dfbd452ce3/idna-3.10-py3-none-any.whl','946d195a0d259cbba61165e88e65941f16e9b36ea6ddb97f00452bae8b1287d3'),
 '3.11':('https://files.pythonhosted.org/packages/0e/61/66938bbb5fc52dbdf84594873d5b51fb1f7c7794e9c0f5bd885f30bc507b/idna-3.11-py3-none-any.whl','771a87f49d9defaf64091e6e6fe9c18d4833f140bd19464795bc32d966ca37ea')}
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result

name='xbcatm-order-'+uuid.uuid4().hex[:10];tags=[name+':early',name+':late']
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'wheels').mkdir()
 for version,(url,digest) in WHEELS.items():
 with urlopen(url,timeout=40) as response:data=response.read()
 assert hashlib.sha256(data).hexdigest()==digest
 (root/'wheels'/url.rsplit('/',1)[1]).write_bytes(data)
 install='RUN pip install --no-index --no-deps --require-hashes --find-links=/wheels -r /app/requirements.txt && python -c "import time;open(\'/installed\',\'w\').write(str(time.time_ns()))"\n'
 common=f'FROM {BASE}\nLABEL example.run="{name}"\nCOPY wheels /wheels\n'
 (root/'early.Dockerfile').write_text(common+'COPY requirements.txt app.py /app/\n'+install+'CMD ["python", "/app/app.py"]\n')
 (root/'late.Dockerfile').write_text(common+'COPY requirements.txt /app/\n'+install+'COPY app.py /app/\nCMD ["python", "/app/app.py"]\n')
 def requirement(version):
 (root/'requirements.txt').write_text(f'idna=={version} --hash=sha256:{WHEELS[version][1]}\n')
 def application(message):
 (root/'app.py').write_text(f'import idna\nprint({message!r},idna.__version__,idna.encode("bücher.example").decode())\n')
 def build():
 for tag,kind in zip(tags,['early','late']):docker('build','--network','none','-f',str(root/(kind+'.Dockerfile')),'-t',tag,str(root))
 def marks():
 return [docker('run','--rm','--network','none',tag,'cat','/installed').stdout for tag in tags]
 requirement('3.10');application('first');build();first=marks()
 application('second');build();second=marks()
 assert first[0]!=second[0] and first[1]==second[1]
 for tag in tags:assert docker('run','--rm','--network','none',tag).stdout.strip()=='second 3.10 xn--bcher-kva.example'
 print('editing only application code reruns the early-copy dependency install but reuses the late-copy install')
 requirement('3.11');build();third=marks()
 assert all(a!=b for a,b in zip(second,third))
 for tag in tags:assert docker('run','--rm','--network','none',tag).stdout.strip()=='second 3.11 xn--bcher-kva.example'
 print('changing the hashed requirement reruns both installs and actually changes idna from 3.10 to 3.11')
finally:docker('image','rm',*tags,check=False)

提前复制版本的 Dockerfile 在 pip 之前一起复制 requirements.txt 与 app.py。延后复制版本先复制依赖声明，执行相同安装命令，再复制应用。两者都提前加入经过验证的 wheel 目录，因为这些文件确实是安装输入。pip 之后立即写入标记，用来观察安装所在操作是否真的执行，而不是凭耗时猜测。

初始应用使用 idna 3.10 编码 bücher.example。两个镜像都调用实际安装的库，得到预期 ASCII 域名 xn--bcher-kva.example。这验证真实第三方依赖，不用 sleep 代替安装，也不把镜像构建成功直接当成应用能够导入软件包的证明。运行结果同时包含版本，能够确认到底安装了哪个版本。

只把应用消息从 first 改为 second 后，两个镜像都输出新消息和版本 3.10。提前复制的镜像得到新的安装标记，延后复制的镜像保留原标记。程序输出证明源码变更已进入两份镜像，标记比较则指出哪一份布局重复执行了不必要的依赖工作。这样可以排除“缓存太多导致应用没更新”的错误解释。

接着，把依赖声明改为 idna 3.11 和对应哈希。两份安装标记都改变，应用也都报告 3.11，并继续得到相同预期域名转换。这是必须验证的相反情况：真实依赖声明变化，在两种布局下都应让安装失效。如果某个布局忽略了这项输入，即使很快也不正确，不能只用源码修改时的成功缓存来评价它。

两个 wheel 从实验开始就一起提供，因此修改 requirement 不会同时改变 wheel 目录，第二次失效的原因保持明确。结束时清理临时镜像与文件，不清理其他构建器状态。安装时间戳只是测试观测手段，不是建议给生产可复现产物增加的随机输入；正式构建应去掉这类只为证明执行次数而加入的标记。

让缓存边界对应软件包边界

审查安装器会读取什么，再把这些输入放到安装操作之前。让无关文件留在该 COPY 范围之外，并用 .dockerignore 排除构建完全不需要的材料。被忽略的文件之后无法满足必需 COPY，因此当某个依赖明明在工作区却构建不可见时，应检查真实构建上下文，而不是不断加禁用缓存选项。

包管理器缓存挂载，可以在安装确实需要重跑时减少下载，但不能替代正确失效规则或输出校验。依赖安装结果复用与下载缓存复用，是不同层次的优化；修改任意一层后，都应运行最终应用验证。不能因为下载更少，就认定安装状态一定与新的锁文件一致。

用有代表性的构建测量效果：完全相同输入、只改源码、升级依赖。三种情况都保留正确性断言。有效的 Dockerfile 应让必要工作重新执行，让不必要工作继续复用，并提供足够证据区分两者。这样，构建性能的改进才能与实际发布内容保持一致。

来源

Optimize Docker cache usage，稳定依赖层与窄范围 COPY，已核验 2026-09-12。
Docker cache invalidation，变化输入如何使后续依赖工作失效，已核验 2026-09-12。
pip install reference，离线 wheel 安装与强制哈希校验，已核验 2026-09-12。

后续镜像层删除文件，并不会擦除先前层的原始字节

Mon, 16 Aug 2027 00:00:00 +0000

容器镜像层描述按顺序应用的文件系统变化。一层可以新增或替换文件，也可以记录某个先前路径应从合并文件系统中消失。普通容器进程看到的是最终合并视图，但这个视图不等于随镜像分发的全部字节历史。因此，仅检查运行中的容器，可能遗漏早期层仍然保留的数据，尤其容易误判删除操作的实际效果。

坏掉的样子

把凭据复制进镜像，再通过后续 RUN 删除，不会从早期不可变层中移除凭据。能够取得相关层的人，仍可能恢复原始字节。同样，把很大的构建压缩包放进某层，再在下一条指令里删除，最终路径虽然不存在，分发内容仍可能包含整个压缩包。目录看起来干净，并不能证明镜像已经没有这份数据。

镜像层是文件系统变更集，不一定是紧凑的二进制差分。替换大文件，可能把替换后的完整内容放入另一层。删除通过 whiteout 标记，在应用层时屏蔽原有路径。OCI 还规定了隐藏下层目录内容的不透明目录规则，所以不能把正确应用镜像层简化成反复普通解压 tar；删除和覆盖语义需要被专门处理。

不是每条 Dockerfile 指令都会创建文件系统层。ENV、LABEL 和 CMD 改变镜像配置，可以产生标记为 empty_layer 的历史条目。因此，Dockerfile 行数、构建历史条目数，都不能可靠地替代根文件系统层数。即使没有增加应用文件字节，这些配置变化仍然影响执行方式和产物身份，不应被当成无关信息。

快速验证

使用 Python、Docker 构建器和固定摘要的基础镜像运行脚本。实测为 Docker 29.3.1，采用 containerd 镜像存储，基础镜像内为 Linux arm64 的 Python 3.11.16。标记内容特意设为公开文本。脚本构建并保存一个临时镜像，直接读取归档成员，不把归档解压到宿主文件系统，结束时删除自己的标签：

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

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

name='xbcatm-whiteout-'+uuid.uuid4().hex[:10];tag=name+':probe';marker=b'PUBLIC_DEMONSTRATION_BYTES\n'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'original.txt').write_bytes(marker)
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY original.txt /demo/original.txt\nRUN rm /demo/original.txt\nENV EXAMPLE_MODE=demo\nLABEL example.purpose="public fixture"\nCMD ["python", "-c", "from pathlib import Path;assert not Path(\'/demo/original.txt\').exists();print(\'absent\')"]\n')
 docker('build','--network','none','-t',tag,str(root))
 assert docker('run','--rm','--network','none',tag).stdout.strip()=='absent'
 archive=root/'image.tar';docker('image','save','-o',str(archive),tag)
 with tarfile.open(archive) as outer:
 manifests=json.load(outer.extractfile('manifest.json'));assert len(manifests)==1
 manifest=manifests[0];config=json.load(outer.extractfile(manifest['Config']))
 assert len(manifest['Layers'])==len(config['rootfs']['diff_ids'])
 assert len(manifest['Layers'])==len(inspect(BASE)['RootFS']['Layers'])+2
 found_data=False;found_whiteout=False
 for layer in manifest['Layers'][-2:]:
 with tarfile.open(fileobj=outer.extractfile(layer),mode='r:*') as contents:
 for entry in contents:
 path=entry.name.removeprefix('./')
 if path=='demo/original.txt':found_data=contents.extractfile(entry).read()==marker
 if path=='demo/.wh.original.txt':found_whiteout=True
 assert found_data and found_whiteout
 assert all(item.get('empty_layer') for item in config['history'][-3:])
 print('the final container hides the removed file, but the older layer still contains the exact public marker')
 print('the deletion layer contains a whiteout; ENV, LABEL and CMD add metadata history without filesystem layers')
finally:docker('image','rm',tag,check=False)

Dockerfile 先把 original.txt 复制到 /demo，再在后续 RUN 删除。容器默认命令断言路径不存在，并输出 absent。这验证最终运行视图，却不能证明镜像归档里也没有对应字节，所以实验接下来单独检查保存后的表示。把两个观察拆开，是避免将“看不见”误判为“没有保存”的关键。

归档的 manifest.json 指明配置文件和有序层文件。脚本读取配置中的 rootfs.diff_ids，检查文件系统层数量与清单一致，再读取最后两个层归档。在这个特定构建中，它们分别对应 COPY 新增与后续删除。实验依赖的是保存产物的实际清单，而不是猜测某个长哈希文件名一定属于哪条指令。

新增层仍包含完全相同的 PUBLIC_DEMONSTRATION_BYTES 标记。删除层则包含 demo/.wh.original.txt，指示应用层时隐藏下层文件，而不是原地编辑那个旧层。这两个事实都有直接断言，因此不能把容器中文件缺失当作安全擦除证据。真实凭据若曾进入分发层，之后删除路径并不能撤销已经发生的暴露。

配置历史的最后三条分别对应 ENV、LABEL 和 CMD，并被标记为不产生文件系统层。相对于基础镜像，本次只增加两个文件系统层，而不是五个。这为“每条 Dockerfile 指令必然追加文件系统差分”的说法提供了明确反例，同时保留配置历史和文件系统内容之间的关系，便于解释 inspect 与 history 为什么计数不同。

归档表示和运行时存储是不同接口。这里检查的是实测 Docker 版本生成的 image-save 格式，以及 OCI 变更集语义。实验没有假定快照存储内部也必须用同样可见的 .wh. 文件名保存删除标记，也没有测量某台宿主实际分配了多少磁盘块。内部实现细节不能仅凭归档内容反推。

在字节进入镜像之前排除无用内容

选择合适的构建上下文和忽略规则，避免无关文件进入 COPY 输入。构建凭据通过构建器的密钥机制传递，并确保命令没有把凭据写入保留输出。如果真实凭据已经进入发布层，需要轮换并处理已有副本；补一个删除层不是完整修复，因为旧字节可能仍在仓库、缓存或此前下载者手里。

只在某次操作期间需要的软件包索引或临时归档，应在同一次构建操作中创建并删除。独立最终阶段可以只复制必要运行产物，而不继承构建阶段的文件系统层。不过，仍要检查导出的缓存和复制输出，因为早期构建材料可能留在构建器，或者经另一种导出路径传播。多阶段结构不会自动证明所有输入都已保密。

最终应根据真实产物和运行依赖判断结果。层数更少，本身不能保证下载更小、启动更快或内容更安全。真正需要回答的是：哪些字节随产物分发，哪些路径在运行时可见，以及每一份保留文件是否具有必要用途。这样才能把空间优化、运行正确性与敏感内容处理放在各自准确的证据上。

来源

OCI filesystem layer changesets 1.1.1，文件新增、修改、删除及 whiteout 应用规则，已核验 2026-09-12。
OCI image configuration 1.1.1，根文件系统 DiffID 与不产生文件层的历史条目，已核验 2026-09-12。
Dockerfile reference，COPY、RUN、ENV、LABEL 和 CMD 的行为，已核验 2026-09-12。

Docker 健康检查报告状态，恢复动作需要明确的消费者

Mon, 05 Jul 2027 00:00:00 +0000

Docker HEALTHCHECK 在容器内运行配置的命令，并把结果记录为健康状态。它提供了主进程是否运行之外的另一项观察，但含义取决于命令检查什么：进程存在、HTTP 响应，还是应用特定的就绪条件。Docker 不会因为出现 HEALTHCHECK 指令，就自动推导出一份通用业务就绪契约，检查者必须明确这个信号能证明哪些行为。

坏掉的样子

总是返回零的命令，即使应用无法提供有用工作，也会产生看起来正常的健康报告。shell 命令序列还可能因为最后一条命令成功，而掩盖前面的失败。反过来，如果探测依赖一个非必需外部服务，就可能把仍可工作的应用标成不健康，并促使消费该状态的系统执行不必要恢复。探测含义必须符合实际消费者需求。

独立 Docker 的重启策略响应容器终止，不是只要健康状态变成 unhealthy 就触发。加入 restart=always，不会让 Docker 因探测失败而重启仍然存活的应用。同样，健康检查也不会自动从所有代理的路由表中移除容器。必须有控制器或代理明确读取该状态，并实现预期动作，不能把观察配置当成恢复配置。

探测时序也容易被误解。重试阈值统计连续失败，启动宽限则改变早期哪些失败会被计数。启动期的一次成功可以结束初始宽限行为。检测耗时取决于命令持续时间、间隔、超时和配置，不能简单承诺一次请求失败就立刻停止流量。解释延迟时，应沿实际探测时间线检查，而不是只看一个 retries 数字。

快速验证

先取得固定基础镜像，再用宿主 Python 和 Docker 运行脚本。实测为 Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16。它只创建一个临时镜像和容器，关闭容器外部网络，使用自身回环 HTTP 服务。被改变的状态仅是实验内部一个无害就绪文件，结束后清理自己的容器和标签：

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

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],text=True,capture_output=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(container):return json.loads(docker('inspect',container).stdout)[0]
def wait_for(container,wanted):
 deadline=time.monotonic()+25
 while time.monotonic()<deadline:
 state=inspect(container)
 if state['State']['Health']['Status']==wanted:return state
 time.sleep(.1)
 raise AssertionError('health did not reach '+wanted)

name='xbcatm-health-'+uuid.uuid4().hex[:10];tag=name+':probe'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory)
 (root/'server.py').write_text('from http.server import BaseHTTPRequestHandler,HTTPServer\nfrom pathlib import Path\nclass Handler(BaseHTTPRequestHandler):\n def do_GET(self):\n code=200 if Path("/ready").exists() else 503\n self.send_response(code);self.end_headers();self.wfile.write(str(code).encode())\n def log_message(self,*args):pass\nHTTPServer(("127.0.0.1",8080),Handler).serve_forever()\n')
 probe='import urllib.request;urllib.request.urlopen("http://127.0.0.1:8080/health",timeout=.5).read()'
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY server.py /server.py\nHEALTHCHECK --interval=1s --timeout=1s --retries=2 --start-period=5s CMD ["python", "-c", {json.dumps(probe)}]\nCMD ["python", "/server.py"]\n')
 docker('build','--network','none','-t',tag,str(root))
 began=time.monotonic()
 docker('run','-d','--name',name,'--network','none','--restart','always',tag)
 initial=inspect(name);assert initial['State']['Health']['Status']=='starting'
 first=wait_for(name,'unhealthy');assert first['State']['Running'] and first['RestartCount']==0
 assert first['State']['StartedAt']==initial['State']['StartedAt']
 assert first['State']['Health']['FailingStreak']>=2
 assert any(log['ExitCode']!=0 and '503' in log['Output'] for log in first['State']['Health']['Log'])
 time.sleep(max(0,12-(time.monotonic()-began)))
 stable=inspect(name);assert stable['State']['Running'] and stable['RestartCount']==0
 assert stable['State']['StartedAt']==initial['State']['StartedAt'] and stable['State']['Health']['Status']=='unhealthy'
 docker('exec',name,'python','-c','from pathlib import Path;Path("/ready").touch()')
 healthy=wait_for(name,'healthy');assert healthy['RestartCount']==0 and healthy['State']['Health']['FailingStreak']==0
 docker('exec',name,'python','-c','from pathlib import Path;Path("/ready").unlink()')
 unhealthy=wait_for(name,'unhealthy');assert unhealthy['RestartCount']==0 and unhealthy['State']['Running']
 assert unhealthy['State']['StartedAt']==initial['State']['StartedAt']
 print('starting -> unhealthy -> healthy -> unhealthy follows the real HTTP probe; failure logs contain HTTP 503')
 print('restart=always does not restart a still-running process solely because its health is unhealthy')
finally:
 docker('rm','-f',name,check=False);docker('image','rm',tag,check=False)

/ready 不存在时，服务返回 HTTP 503。Dockerfile 健康检查使用 Python HTTP 客户端，遇到该状态会抛出错误并以失败状态结束。配置为一秒间隔、一秒超时、两次重试、五秒启动期。容器采用 restart=always 启动，初始检查记录健康状态为 starting，随后观察实际探测结果。

计入连续失败后，Docker 报告 unhealthy，健康日志包含真实 HTTP 503 错误，失败计数至少为二。实验保存初始启动时间，并等待到启动至少十二秒后，再确认主进程仍运行且没有重启。这样可以排除把初始启动行为误当成已进入稳定运行阶段后的恢复策略，结论不依赖一个过早的瞬时观察。

创建 /ready 后，HTTP 端点返回 200，之后的探测让健康状态变成 healthy，连续失败计数清零。同一个容器进程继续运行。这说明检查命令实际观察到应用恢复，不需要控制器为了清除状态而人为重启。状态变化来自被检查行为改变，能够与进程寿命独立对照。

删除该文件，端点再次失败，健康状态最终回到 unhealthy。启动时间始终相同，RestartCount 始终为零。实验覆盖完整的失败、恢复、再次失败，而不是只观察一次启动故障，就假定后续情况全部一样。这也说明健康状态不是只能从 starting 单向走向某个永久结果，它会随后续探测变化。

Docker 消费的是探测进程退出状态：零表示成功，一表示失败，二在 Dockerfile 契约中保留。Python 客户端遇到 HTTP 错误自然返回失败进程状态。脚本同时读取诊断输出，有助于区分真实就绪失败与探测程序缺失、命令拼写错误等问题。只看 unhealthy，无法知道检查究竟在哪一步失败。

单独定义响应动作

选择成本低、耗时有界、含义符合消费者要求的检查。内部 HTTP 探测可以验证应用处理，但不能证明公共 DNS、TLS 终止、代理路由或终端用户可达性；这些路径重要时，需要外部观察。探测应避免破坏性操作，也不要把凭据写进保留的健康日志。检查失败应提供有用信息，而不是制造额外事故。

Compose 启动依赖需要等待就绪时，应显式配置基于健康状态的条件。对于运行期路由或修复，核对真实控制器的策略，并测试它采取的动作。观察与行动应明确连接，同时留出合理宽限，避免把短暂依赖问题变成重启风暴。配置里存在健康检查，不等于这些后续行为已经被验证。

事故期间，分别检查主进程状态、健康状态、探测日志和重启历史。存活但不健康、已经退出、不断重启，是不同故障。每种状态都有清晰证据，才便于选择正确恢复方式，而不是看到一个红色标签就反复重启，掩盖真正的应用或依赖问题。

来源

Dockerfile HEALTHCHECK reference，探测退出码、间隔、重试、启动宽限及健康状态，已核验 2026-09-12。
Start containers automatically，针对容器终止的重启策略，已核验 2026-09-12。
Control startup order in Compose，消费健康状态的显式依赖启动条件，已核验 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。

Docker · XB 现场笔记

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

坏掉的样子

快速验证

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

延伸阅读

来源

Docker 构建缓存复用已记录的工作，也可能复用过期结果

坏掉的样子

快速验证

把新鲜度变成明确输入

延伸阅读

来源

ENTRYPOINT 和 CMD 定义可被运行者覆盖的启动默认值

坏掉的样子

快速验证

把启动和停止视为同一个接口

来源

镜像标签可以移动，既有容器仍保留原先选择的镜像

坏掉的样子

快速验证

提升经过测试的同一产物

延伸阅读

来源

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

坏掉的样子

快速验证

记录真正影响项目的输入

来源

先复制依赖输入，再复制应用代码

坏掉的样子

快速验证

让缓存边界对应软件包边界

延伸阅读

来源

后续镜像层删除文件，并不会擦除先前层的原始字节

坏掉的样子

快速验证

在字节进入镜像之前排除无用内容

来源

Docker 健康检查报告状态，恢复动作需要明确的消费者

坏掉的样子

快速验证

单独定义响应动作

延伸阅读

来源

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

坏掉的样子

快速验证

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

来源

相关镜像共享文件层，运行中的容器各自保存修改

坏掉的样子

快速验证

构建并替换预期产物

延伸阅读

来源