2. 镜像锁定概念：为什么你要较真那个「身份标识」
好，咱们正式开始聊镜像锁定。很多新手刚接触 Singularity 时，觉得「容器不就是拉下来跑就完了吗？」——嗯，这话如果只在本地折腾、服务器永远不会重启，那也许没问题。但一旦你进入生产环境、要让别人（甚至是另一个实验室的同事）复现你的结果，镜像的「身份」就会变成一个硬核问题。
我进入正题。我们得先把几个基础概念掰扯清楚：Tag、Digest、Locked 镜像。这三个词，你能搞定，后面所有质控流程就很好上手了。
2.1 Tag：好记，但不可靠
你应该见过类似这样的拉取命令：
singularity pull docker://ubuntu:20.04那个 20.04 就是 Tag。Tag 本质上是一个人类友好的别名。它的设计初衷是方便记忆——比如 latest、v1.0、20.04。听起来很直接，但这里面有个大坑。
Tag 可以被更新覆盖。一个标准的 Tag 指向的镜像内容，随时可能改变。举个例子：今天你拉 ubuntu:20.04，它包含某个版本的 libc；一个月后镜像的维护者打了一个安全补丁，重新用同样的 Tag 推送了一遍，你再拉，libc 版本就不一样了。
这意味着什么？——你的计算环境不再是「可复现」的。我遇到过最惨的一次，一位合作者在论文投稿后，审稿人要求复现分析结果，结果因为 Tag 指向的内容变了，同样的命令跑出了不同的统计 P 值。那叫一个尴尬。
核心观点：Tag ≈ 人的昵称，可以改名、可以冒用、可以重推。你如果用 Tag 来「锁定」镜像，那你锁定的其实是一团雾水。
2.2 Digest：真正的「指纹」
Digest 就不一样了。它基于镜像的内容哈希生成。只要镜像的二进制内容有任何变动（哪怕一个字节不一样），Digest 就会变成完全不同的字符串。
Singularity 的 Digest 长这样：
sha256:2a8a7b7d9f9c8b6b8b7c2a8a7b7d9f9c8b6b8b7c2a8a7b7d9f9c8b6b8b7c你可以通过 singularity inspect 命令来查看你本地的镜像 Digest：
singularity inspect --labels my_image.sif | grep Digest或者更直接一点，在拉取镜像时直接指定 Digest：
singularity pull docker://ubuntu@sha256:2a8a7b7d9f9c8b6b8b7c2a8a7b7d9f9c8b6b8b7c2a8a7b7d9f9c8b6b8b7c注意那个 @ 符号。在 Docker/Singularity 的命名体系里，@ 表示你是在用 Digest 而不是 Tag 拉镜像。这么做的好处是——你一直拿到的是同一包内容。
我个人的习惯：所有用于生产或论文复现的镜像，一律使用 Digest 拉取。Tag 只用于开发阶段的快速测试。你想想看，如果审稿人将来要按照你的方法重跑，你能保证同一个 Tag 一年后内容不变吗？Digest 可以。
2.3 Locked 镜像：把「指纹」写进配方
好，现在咱们把 Tag 和 Digest 放在一起看。
Locked 镜像的定义很直接：一个 Locked 镜像 = 你知道它的 Digest，且你有一个机制让后续所有拉取都基于这个 Digest，而不是任何 Tag。
在实际的 Singularity 项目里，我们通常用一个配方文件（比如 Singularity.def 或 singularity.recipe）来声明依赖。但配方文件里如果写死了某个基础镜像的 Digest，那这个镜像就是 Locked 的。
举个完整的 Locked 镜像示例：
Bootstrap: docker
From: ubuntu@sha256:2a8a7b7d9f9c8b6b8b7c2a8a7b7d9f9c8b6b8b7c2a8a7b7d9f9c8b6b8b7c
%post
apt-get update && apt-get install -y python3
pip3 install numpy==1.21.0注意 From: 这一行。没有 Tag，唯一标识就是 Digest。只要你拉下来、构建出的 SIF 文件，Digest 也和配方里写的一致，那这个 SIF 就是 Locked 镜像。
曾经有一次，我在搭建一个跨团队的分析管道时，一号团队用了 From: ubuntu:20.04，二号团队用了 From: ubuntu@sha256:xxxx。半年后两台机器上的镜像大小差了 200MB，运行同一套脚本出了一个数据差异。从那以后，我们团队的默认策略就变成了「所有基础镜像必须提供 Digest」。
2.4 为什么要锁定？三个逃不开的理由
你可能会问：「我就是一个跑常规分析的工具，有必要这么较真吗？」好，我给你三个理由，你听听看能不能说服自己。
- 复现性：科学计算和数据管道的结果必须可复现。一个会随时间「飘移」的镜像，等于给你的论文和报告埋下了一颗定时炸弹。Locked 镜像保证你一个月后、一年后拉下来的东西，跟你今天一模一样。
- 安全审计：如果你能锁定一个镜像的内容，你就可以基于它的 Digest 做安全扫描。写一份报告说「我用了 image X, Digest Y，没有高优先级的 CVE」，这比说「我用了 ubuntu:20.04」要硬气得多。因为后者的内容可能随时更换，你没法保证自己现在的扫描结果一天后还成立。
- 环境隔离与控制：在大型集群或云平台上，你经常需要管理成百上千个镜像。如果不锁定，运维人员去排查问题时，根本没法确定一个特定的 SIF 文件到底包含什么。Locked 镜像给了你一张「快照」，你能清楚地知道这个镜像的完整构建历史。
一句话总结：Tag 是名，Digest 是实。Locked 镜像就是用 Digest 来固定镜像的身份，形成一个不可篡改、可复现、可审计的容器单元。这才是质控的起点。
2.5 本章知识结构图
2.6 一个简单的概念对比表
| 概念 | 本质 | 是否可变 | 是否可锁定 | 实际场景举例 |
|---|---|---|---|---|
| Tag | 人类可读的别名 | 是（可被重新推送） | 否 | :latest, :v1.0 |
| Digest | 内容哈希签名 | 否（内容变则哈希变） | 是 | @sha256:xxxx |
| Locked 镜像 | Digest 写死的 SIF | 否（构建后不可再变） | 是 | .sif 文件 + Digest 凭证 |
看懂这个表，我相信你对「锁定」就有了一个基本的判断力。下一节咱们要进入实操：怎么在 Singularity 里具体打一个 Locked 镜像的标签、验证它的 Digest，以及写一份可以让别人复现的锁定配方。但在此之前，记住一句话就行——
镜像锁定，锁定的是 Digest，不是 Tag。 这是整个质控方法的第一块基石。