容器镜像

什么是容器镜像?

容器镜像是容器运行的只读模板,包含应用程序、运行时、系统依赖和启动配置,是容器交付链路中的核心制品。这个标签聚合 Docker 镜像、Dockerfile、基础镜像、镜像仓库、Harbor、镜像扫描、镜像签名、版本管理和供应链治理内容。

显示更多

这个页面适合围绕镜像构建、分发和安全治理查找文章;如果希望把镜像、容器运行、网络存储和 Kubernetes 交付串起来学习,可以进入容器技术学习路径页。

按学习路径系统学习容器技术内容

如果希望从镜像构建、漏洞扫描、镜像签名和仓库权限继续进入供应链与运行时安全治理,可以进入云原生安全学习路径页。

按学习路径系统学习云原生安全内容

  • 构建阶段重点关注 Dockerfile、基础镜像、缓存和镜像瘦身
  • 分发阶段重点关注 Harbor、权限、标签策略和镜像仓库治理
  • 生产阶段重点关注漏洞扫描、签名校验、节点镜像清理和供应链安全
治理建议

容器镜像治理可以按构建、分发、安全、清理四个阶段推进:构建阶段规范 Dockerfile 和基础镜像,分发阶段治理仓库权限和标签策略,安全阶段接入扫描与签名,运行阶段关注节点镜像缓存、磁盘压力和版本追溯。

学习路径

了解更多关于容器镜像的信息

容器镜像治理应该先做什么?

容器镜像治理不建议一开始就只上扫描工具,应该先把镜像构建和分发流程规范起来。 如果基础镜像、Dockerfile、镜像标签和仓库权限都比较混乱,后面的漏洞扫描、签名和准入控制很难形成闭环。

比较稳妥的顺序是:先统一基础镜像和 Dockerfile 写法,再规范镜像命名、版本标签和仓库项目;等交付对象稳定后,再接入漏洞扫描、镜像签名、保留策略和发布准入。这样治理不会停留在报告层面,而是能真正影响构建和上线流程。

基础镜像越小越好吗?

不一定。镜像体积小通常意味着下载更快、攻击面更小,但生产环境还要考虑兼容性、可维护性、安全更新和排障成本。

Alpine、Debian slim、Distroless 和企业自维护基础镜像各有适用场景。 Alpine 体积小,但部分依赖可能遇到兼容性问题;Distroless 攻击面更小,但调试成本更高;企业基础镜像则适合统一证书、时区、安全基线和运行时依赖。选型时不能只看大小,还要看团队能否长期维护。

latest标签为什么有风险?

latest 的核心风险是不可追溯。 它不是一个稳定版本,而是一个会变化的标签,同一个部署配置在不同时间可能拉取到不同镜像。

  1. 回滚时不清楚应该回到哪个真实镜像。
  2. 测试、预发、生产可能无意间运行不同内容。
  3. 事故排查时难以关联代码提交、构建记录和镜像摘要。

生产环境更推荐使用语义版本、构建号、Git SHA 或镜像 digest,并在 CI/CD 或发布平台中保存镜像与代码版本的对应关系。

镜像扫描发现漏洞后应该如何处理?

镜像扫描结果不能简单理解成“有漏洞就全部阻断”。更实际的做法是先判断漏洞来源和影响范围,再决定处理优先级。

例如基础镜像漏洞通常需要平台侧更新基础镜像,应用依赖漏洞需要业务侧升级依赖;有些漏洞虽然等级高,但在当前镜像中没有可利用路径,也需要结合暴露面判断。对生产流程来说,高危可利用漏洞应进入发布门禁,中低危问题可以进入周期修复计划,同时保留例外审批和修复期限。

镜像仓库治理为什么不仅是存储问题?

镜像仓库看起来是存放镜像的地方,但在企业交付链路中,它更像制品中心。谁能推送镜像、谁能覆盖标签、哪些镜像能进入生产、旧镜像什么时候清理,都会影响交付稳定性和安全性。

因此 Harbor、Nexus、JFrog Artifactory 等工具选型时,不能只看能不能存镜像,还要看权限模型、审计记录、漏洞扫描、复制同步、保留策略和 CI/CD 集成能力。仓库治理做不好,后续发布回滚、镜像追溯和安全合规都会受影响。

镜像构建缓存应该如何管理?

镜像构建缓存的目标是加速构建,但不能牺牲可控性和安全性。 常见做法是把变化较少的依赖安装步骤放在 Dockerfile 前面,把频繁变化的业务代码放在后面,这样可以更好复用缓存层。

同时要注意 .dockerignore,避免把本地日志、临时文件、密钥、node_modules 或构建缓存目录带入镜像上下文。对于 CI 场景,可以配合远程缓存和多阶段构建,但生产镜像仍然要保持版本清晰、内容可追溯、构建过程可复现。