Docker

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

Docker 构建缓存保存构建操作的结果，让后续构建在相关输入仍匹配时复用已有工作。缓存命中不表示命令重新运行并生成相同输出，而是构建器接受了一份先前结果。这个区别直接影响软件包安装、生成时间戳、远程下载，以及输出可能变化却没有相应声明输入变化的操作。理解缓存时，首先要区分“再次执行”和“取出已经执行过的结果”。 依据原文历史样例说明机制。当前审核仍为已修订、执行受阻。本次绘图未执行 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 基础镜像。构建 RUN 指令和运行容器关闭外部网络，但镜像解析仍可能访问仓库。脚本删除自己的临时标签，不清理其他镜像，也不对全局构建缓存执行 prune： ...

镜像的 ENTRYPOINT 和 CMD 共同参与容器创建时的启动命令。使用 exec 形式 ENTRYPOINT 时，CMD 通常提供追加给入口的默认参数；没有入口时，CMD 可以提供可执行程序及其参数。这些是启动默认值，不是强制执行边界。有权限创建容器的运行者，可以替换入口或参数，因此不能把 ENTRYPOINT 描述成无论如何都不可改变的程序锁。 坏掉的样子 在 docker run image ... 中写到镜像名之后的参数，会替换 CMD，不是自动加到原 CMD 默认值之后。exec 形式入口仍然保留，除非显式覆盖。用户以为自己只是追加一个选项，却可能丢掉全部默认参数。因此，命令行工具需要说明哪些值可省略、哪些必须重新提供，以及自身参数解析器如何处理覆盖。 exec 形式使用 JSON 数组，不会隐式运行 shell。$DEMO 这样的字符串会原样传给程序，而不是自动展开环境变量。管道、重定向和通配符也需要真正的解释器，才会获得相应含义。shell 形式会改变参数和进程语义，所以两种形式之间的切换并不只是语法美化，不能只看命令表面似乎相同。 启动包装脚本还可能让服务藏在不转发停止信号的 shell 后面。Docker 通常向容器主进程发送停止信号，等待配置的超时，必要时强制终止。即使服务自身正确安装了 SIGTERM 处理函数，如果信号只到达另一个不会转发的进程，这个处理函数也无法发挥作用。排查优雅退出失败时，应先确认信号实际发给了谁。 运行参数替换 CMD 默认值；exec 改变信号送达路径，却不实现应用清理。 快速验证 使用启用断言的宿主 Python 3.7 或更新版本，以及能够取得固定基础镜像的 Docker 构建器。早期记录报告 Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16；这里没有复现该次运行。PID 断言要求容器使用私有 PID 命名空间，且没有注入 init。实验关闭容器网络，等待服务就绪输出后测试停止，并尝试清理容器和镜像标签，不依赖盲目等待固定时长猜测就绪： ...

镜像标签是与镜像引用关联的可读名字。如果仓库策略没有禁止重新指派，同一个标签之后可以标识另一个产物。v1.4 和 latest 的区别首先是命名惯例，而不是前者天然不可变。要复现部署，需要记录实际选择的产物，以及影响行为的平台和运行配置。只保存一个看起来像版本号的名字，并不足以证明当时运行的是哪些内容。 原文仅在本地操作的历史样例，本次未重跑；不表示执行了仓库操作。需记录所选产物与平台；摘要对象类型、内容可用性和验证仍然重要。 坏掉的样子 latest 不会要求仓库寻找最新上传镜像或最高语义版本，它是在引用省略标签时采用的惯例默认值。发布另一个版本，不会自动移动 latest；必须有人或自动化更新这个具体引用。如果把每次 push 都解释成自动更新 latest，就会错误理解发布流程，甚至误判为什么一个节点仍然取得旧版本。 标签的本地解析结果，也可能不同于仓库当前结果。拉取策略、本地镜像是否存在，以及编排工具的行为，共同决定何时查询仓库。因此，两台机器运行相同可读标签，仍可能使用不同产物。仅记录命令文本，会留下实际取回什么、是否保留缓存引用等不确定性；排查时应读取所选产物身份。 移动标签不会改写已经创建的容器所选择的镜像。重启该容器，会保留原配置的镜像和可写状态，不会按照标签的新目标重新创建实例。如果更新流程只是重新打标签，然后 restart 旧容器，命令可能成功，应用却仍运行旧内容。标签更新、容器替换和容器重启需要分别判断，不能混成同一个动作。 快速验证 先取得固定基础镜像，再用 Python 和 Docker 构建器运行脚本。实测环境是 Docker 29.3.1、Linux arm64。所有标签使用独特的本地名字，不向仓库推送任何内容；容器关闭网络，清理只删除实验自己的容器与标签。因此可以实际验证移动行为，又不改变已有发布引用： ...

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

Dockerfile 顺序决定昂贵构建操作依赖哪些先前输入。如果应用源码在依赖安装之前被复制，即使依赖声明未变，修改源码也可能让安装重跑。先复制依赖输入、安装依赖，再复制应用代码，可以建立更小的依赖边界，让它与安装器真正需要的工作匹配。这里优化的是依赖关系，而不只是把几行命令挪到看起来更整齐的位置。 依据原文历史样例说明机制。当前审核仍为已修订、执行受阻。本次绘图未执行 Docker 命令，未增加运行、页面、集成或发布验证。 坏掉的样子 在软件包安装前使用宽泛的 COPY . .，会让文档、生成输出或无关源码编辑，都可能成为重做昂贵工作的原因。问题不在于 COPY 天生很慢，而在于后续安装依赖了一份包含无关变化的文件系统状态。这些变化并不是选择和安装依赖所必需，却通过前置步骤扩大了失效范围。 如果安装还读取锁文件、本地包源码、补丁、工作区元数据或包管理器配置，仅复制一个清单也不够。遗漏真实输入，可能保留已经不符合构建意图的缓存结果。正确边界必须包含安装器实际使用的全部输入，而不是只选择常见 Dockerfile 示例里出现的某个文件名。否则，表面命中率提高，实际正确性却下降。 缓存顺序也不能修复可变依赖。相同安装命令可能一直保留旧结果，而干净构建却从远端解析到不同内容。固定版本和校验哈希解决产物选择问题，控制 COPY 顺序解决复用问题。两者都需要处理，构建更快并不能证明软件包图可复现，也不能证明依赖已经更新到本次发布要求的版本。 快速验证 使用宿主 Python、Docker 构建器和已取得的固定基础镜像运行脚本。它先通过 HTTPS 下载两个公开的 idna wheel，并在构建前验证固定 SHA-256。构建 RUN 指令关闭外部网络，pip 从本地 wheel 目录安装并强制要求哈希；镜像解析仍可能访问仓库。实测环境为 Docker 29.3.1，Linux arm64 基础镜像内 Python 为 3.11.16： ...

容器镜像层描述按顺序应用的文件系统变化。一层可以新增或替换文件，也可以记录某个先前路径应从合并文件系统中消失。普通容器进程看到的是最终合并视图，但这个视图不等于随镜像分发的全部字节历史。因此，仅检查运行中的容器，可能遗漏早期层仍然保留的数据，尤其容易误判删除操作的实际效果。 原文历史样例，本次未重跑。image-save 归档不同于快照存储内部表示和物理磁盘分配。后续删除不能修复已经暴露的凭据。 坏掉的样子 把凭据复制进镜像，再通过后续 RUN 删除，不会从早期不可变层中移除凭据。能够取得相关层的人，仍可能恢复原始字节。同样，把很大的构建压缩包放进某层，再在下一条指令里删除，最终路径虽然不存在，分发内容仍可能包含整个压缩包。目录看起来干净，并不能证明镜像已经没有这份数据。 镜像层是文件系统变更集，不一定是紧凑的二进制差分。替换大文件，可能把替换后的完整内容放入另一层。删除通过 whiteout 标记，在应用层时屏蔽原有路径。OCI 还规定了隐藏下层目录内容的不透明目录规则，所以不能把正确应用镜像层简化成反复普通解压 tar；删除和覆盖语义需要被专门处理。 不是每条 Dockerfile 指令都会创建文件系统层。ENV、LABEL 和 CMD 改变镜像配置，可以产生标记为 empty_layer 的历史条目。因此，Dockerfile 行数、构建历史条目数，都不能可靠地替代根文件系统层数。即使没有增加应用文件字节，这些配置变化仍然影响执行方式和产物身份，不应被当成无关信息。 快速验证 使用 Python、Docker 构建器和固定摘要的基础镜像运行脚本。实测为 Docker 29.3.1，采用 containerd 镜像存储，基础镜像内为 Linux arm64 的 Python 3.11.16。标记内容特意设为公开文本。脚本构建并保存一个临时镜像，直接读取归档成员，不把归档解压到宿主文件系统，结束时删除自己的标签： ...

Docker HEALTHCHECK 在容器内运行配置的命令，并把结果记录为健康状态。它提供了主进程是否运行之外的另一项观察，但含义取决于命令检查什么：进程存在、HTTP 响应，还是应用特定的就绪条件。Docker 不会因为出现 HEALTHCHECK 指令，就自动推导出一份通用业务就绪契约，检查者必须明确这个信号能证明哪些行为。 展示原文历史样例，本次未重跑。健康状态间距不代表测得时长。原文用 CMD 启动服务，此图不声称 ENTRYPOINT 或信号转发行为。审核仍为已修订、执行受阻。 坏掉的样子 总是返回零的命令，即使应用无法提供有用工作，也会产生看起来正常的健康报告。shell 命令序列还可能因为最后一条命令成功，而掩盖前面的失败。反过来，如果探测依赖一个非必需外部服务，就可能把仍可工作的应用标成不健康，并促使消费该状态的系统执行不必要恢复。探测含义必须符合实际消费者需求。 独立 Docker 的重启策略响应容器终止，不是只要健康状态变成 unhealthy 就触发。加入 restart=always，不会让 Docker 因探测失败而重启仍然存活的应用。同样，健康检查也不会自动从所有代理的路由表中移除容器。必须有控制器或代理明确读取该状态，并实现预期动作，不能把观察配置当成恢复配置。 探测时序也容易被误解。重试阈值统计连续失败，启动宽限则改变早期哪些失败会被计数。启动期的一次成功可以结束初始宽限行为。检测耗时取决于命令持续时间、间隔、超时和配置，不能简单承诺一次请求失败就立刻停止流量。解释延迟时，应沿实际探测时间线检查，而不是只看一个 retries 数字。 快速验证 先取得固定基础镜像，再用宿主 Python 和 Docker 运行脚本。实测为 Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16。它只创建一个临时镜像和容器，关闭容器外部网络，使用自身回环 HTTP 服务。被改变的状态仅是实验内部一个无害就绪文件，结束后清理自己的容器和标签： ...