基础镜像固定策略是什么
Dockerfile 的第一行决定了镜像底座，也决定了构建可复现的程度。标签从宽到严分为几级：主版本（node:20）、小版本（node:20.18）、补丁版本（node:20.18.0）、带发行版变体（node:20.18.0-alpine3.20），以及最严格的摘要（@sha256:…）。固定越细，同一份 Dockerfile 在不同时间构建出的结果越一致；代价是要有配套的升级机制，否则会在旧版本上停留。
基本信息
| 固定级别 | 主版本 → 小版本 → 补丁版本 → 发行版变体 → 摘要 |
|---|---|
| 摘要写法 | FROM node@sha256:一串十六进制 |
| 可复现性 | 摘要最严格：内容变了摘要必然变，标签漂移无法命中 |
| 风险面 | 写 latest 或只写主版本，底座内容会随时间变化 |
| 更新手段 | 人工巡检、自动化升级工具、定期重建流水线 |
| 验收方式 | docker image inspect 看 Created 与 RepoDigests |
典型使用场景
- 需要可复现构建的安全敏感项目：固定补丁版本或摘要
- 定期跟进上游安全修复：固定到小版本，让补丁自动跟随
- 区分 alpine、slim、debian 等变体，按体积与 glibc 依赖需求选择
- 多服务统一底座，用一个变量集中管理版本再做批量升级
- 事故复盘时比对底座版本，确认问题是否来自上游变更
常见固定写法
常见固定写法
# 固定到补丁版本与发行版变体：可复现与可维护之间的平衡点
FROM node:20.18.0-alpine3.20
# 固定到摘要：最严格，上游任何内容变动都不会影响本次构建
FROM node@sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# 用构建参数统一管理底座版本，便于批量升级
ARG NODE_VERSION=20.18.0
FROM node:${NODE_VERSION}-alpine3.20
# 核对实际拉到的底座信息
# docker image inspect node:20.18.0-alpine3.20 --format '{{.Created}} {{.RepoDigests}}'固定级别怎么选
| 写法示例 | 可复现性 | 代价 |
|---|---|---|
| node:20 | 低：小版本随时变 | 省心但结果漂移 |
| node:20-alpine | 低：变体内部仍会更新 | 体积小，风险同上 |
| node:20.18.0 | 较高：补丁需手动跟 | 要定期巡检升级 |
| node:20.18.0-alpine3.20 | 高：底座与变体双固定 | 升级动作更明确 |
| node@sha256:… | 最高：内容级锁定 | 必须建立主动更新流程 |
固定摘要不会自动获得上游安全修复：摘要对应的是某个确定内容，上游发补丁不会改变这个摘要。凡是锁摘要的项目，都要把「定期重建并更新摘要」写进例行流程。
多此一举的写法是把固定与自动升级混在一起：既写死摘要又期望 latest 更新。二者只能选一个，然后在 README 或流水线注释里写清选的是哪条路线。