容器镜像
容器镜像是容器运行的只读模板，包含应用程序、运行时、系统依赖和启动配置，是容器交付链路中的核心制品。这个标签聚合 Docker 镜像、Dockerfile、基础镜像、镜像仓库、Harbor、镜像扫描、镜像签名、版本管理和供应链治理内容。
显示更多
这个页面适合围绕镜像构建、分发和安全治理查找文章；如果希望把镜像、容器运行、网络存储和 Kubernetes 交付串起来学习，可以进入容器技术学习路径页。
如果希望从镜像构建、漏洞扫描、镜像签名和仓库权限继续进入供应链与运行时安全治理，可以进入云原生安全学习路径页。
- 构建阶段重点关注 Dockerfile、基础镜像、缓存和镜像瘦身
- 分发阶段重点关注 Harbor、权限、标签策略和镜像仓库治理
- 生产阶段重点关注漏洞扫描、签名校验、节点镜像清理和供应链安全
容器镜像治理可以按构建、分发、安全、清理四个阶段推进：构建阶段规范 Dockerfile 和基础镜像，分发阶段治理仓库权限和标签策略，安全阶段接入扫描与签名，运行阶段关注节点镜像缓存、磁盘压力和版本追溯。
学习路径
推荐阅读
-
在CRI运行中验证容器镜像签名
Kubernetes容器镜像签名说明
-
容器基础镜像如何构建？
构建容器基础镜像是容器化应用的关键步骤之一。容器基础镜像是包含操作系统和一些基础软件的镜像，它为容器提供了运行环境和基本的工具支持。下面是构建容器基础镜像的一般步骤和注意事项：
-
容器镜像构建工具有哪些？
在容器化应用开发和部署过程中，有许多容器镜像构建工具可供选择。这些工具可以帮助开发人员和运维团队创建、管理和发布容器镜像。以下是一些常见的容器镜像构建工具：
-
容器镜像仓库渗透原理是什么？
本文将深入探讨容器镜像仓库的渗透原理，以帮助读者了解容器镜像仓库面临的潜在安全风险和威胁。我们将介绍一些常见的容器镜像仓库渗透技术和攻击方式，并提供相应的防御策略和最佳实践，以确保容器镜像仓库的安全性和可靠性。
-
容器和镜像的基本命令有哪些？
在容器和镜像的管理过程中，有一些基本的命令可以帮助用户进行创建、管理、查看和操作容器和镜像。以下是一些常见的容器和镜像的基本命令：
-
容器镜像仓库怎么用？
本文将深入探讨容器镜像仓库的使用方法和技巧，旨在帮助读者充分利用容器镜像仓库来高效地管理和分享容器镜像。我们将介绍容器镜像的上传、下载、版本控制、权限管理等关键操作，并提供一些最佳实践和注意事项，以确保容器镜像仓库的顺利运行和有效利用。
-
容器镜像仓库搭建方法及步骤
本文将介绍搭建容器镜像仓库的重要性，并提供了一些常见的容器镜像仓库解决方案。我们将详细讨论如何选择合适的容器镜像仓库，以及搭建过程的步骤和注意事项，旨在帮助读者建立高效、安全的容器镜像管理环境。
-
容器镜像和虚拟机镜像的区别
容器镜像和虚拟机镜像是两种不同的镜像类型，它们在多个方面有所区别。
-
容器镜像和虚拟机镜像哪个好？
本文将深入探讨容器镜像和虚拟机镜像的优劣势，帮助读者在选择虚拟化方案时做出明智的决策。我们将从隔离性、资源利用、启动速度、可移植性和管理复杂性等多个角度比较容器镜像和虚拟机镜像，旨在为读者提供全面的了解和指导。
-
容器镜像是什么意思？
容器镜像是指在容器化技术中使用的一种打包格式，它包含了完整的应用程序及其运行所需的所有组件和依赖项。容器镜像可以看作是一个可执行的软件包，其中包含了应用程序的代码、运行时环境、库文件、配置文件等。
-
容器和镜像的关系是什么？
容器和镜像是现代应用程序开发和部署中的两个重要概念。容器是一种轻量级的虚拟化技术，用于隔离和运行应用程序。而镜像是容器的构建和分发单位，包含了应用程序的所有依赖和运行环境。本文将深入探讨容器和镜像的关系，解释它们之间的联系和相互作用。
了解更多关于容器镜像的信息
容器镜像治理应该先做什么？
容器镜像治理不建议一开始就只上扫描工具，应该先把镜像构建和分发流程规范起来。 如果基础镜像、Dockerfile、镜像标签和仓库权限都比较混乱，后面的漏洞扫描、签名和准入控制很难形成闭环。
比较稳妥的顺序是：先统一基础镜像和 Dockerfile 写法，再规范镜像命名、版本标签和仓库项目；等交付对象稳定后，再接入漏洞扫描、镜像签名、保留策略和发布准入。这样治理不会停留在报告层面，而是能真正影响构建和上线流程。
基础镜像越小越好吗？
不一定。镜像体积小通常意味着下载更快、攻击面更小，但生产环境还要考虑兼容性、可维护性、安全更新和排障成本。
Alpine、Debian slim、Distroless 和企业自维护基础镜像各有适用场景。 Alpine 体积小，但部分依赖可能遇到兼容性问题；Distroless 攻击面更小，但调试成本更高；企业基础镜像则适合统一证书、时区、安全基线和运行时依赖。选型时不能只看大小，还要看团队能否长期维护。
latest标签为什么有风险？
latest 的核心风险是不可追溯。 它不是一个稳定版本，而是一个会变化的标签，同一个部署配置在不同时间可能拉取到不同镜像。
- 回滚时不清楚应该回到哪个真实镜像。
- 测试、预发、生产可能无意间运行不同内容。
- 事故排查时难以关联代码提交、构建记录和镜像摘要。
生产环境更推荐使用语义版本、构建号、Git SHA 或镜像 digest，并在 CI/CD 或发布平台中保存镜像与代码版本的对应关系。
镜像扫描发现漏洞后应该如何处理？
镜像扫描结果不能简单理解成“有漏洞就全部阻断”。更实际的做法是先判断漏洞来源和影响范围，再决定处理优先级。
例如基础镜像漏洞通常需要平台侧更新基础镜像，应用依赖漏洞需要业务侧升级依赖；有些漏洞虽然等级高，但在当前镜像中没有可利用路径，也需要结合暴露面判断。对生产流程来说，高危可利用漏洞应进入发布门禁，中低危问题可以进入周期修复计划，同时保留例外审批和修复期限。
镜像仓库治理为什么不仅是存储问题？
镜像仓库看起来是存放镜像的地方，但在企业交付链路中，它更像制品中心。谁能推送镜像、谁能覆盖标签、哪些镜像能进入生产、旧镜像什么时候清理，都会影响交付稳定性和安全性。
因此 Harbor、Nexus、JFrog Artifactory 等工具选型时，不能只看能不能存镜像，还要看权限模型、审计记录、漏洞扫描、复制同步、保留策略和 CI/CD 集成能力。仓库治理做不好，后续发布回滚、镜像追溯和安全合规都会受影响。
镜像构建缓存应该如何管理？
镜像构建缓存的目标是加速构建，但不能牺牲可控性和安全性。 常见做法是把变化较少的依赖安装步骤放在 Dockerfile 前面，把频繁变化的业务代码放在后面，这样可以更好复用缓存层。
同时要注意 .dockerignore，避免把本地日志、临时文件、密钥、node_modules 或构建缓存目录带入镜像上下文。对于 CI 场景，可以配合远程缓存和多阶段构建，但生产镜像仍然要保持版本清晰、内容可追溯、构建过程可复现。