在容器之前，开发人员在物理机或虚拟机中运行代码，为操作系统和电脑创建独特版本的安装包（通常与所安装的其他软件有共同的依赖关系和交互）。容器改变了这一点，允许开发人员生成小型的可移动的单元（容器镜像）——这些单元可以捆绑所有必需的依赖关系，在任何地方运行并使用自动化进行部署。
在旧模式中，出现问题时，要求开发人员一个一个地分析和修补系统。在新模式中，开发人员不断生成新的容器化版本来修复问题并添加功能。这些流入管道并驻留在专门的编目好的存储（容器镜像注册表）中，等待处理（例如质量保证测试），然后在生产中进行部署。
这是注册表发挥作用的地方：在整个过程中，注册表仍然是你要运行的镜像的真实来源。第一个优点是你可以在任何地方运行相同的代码；第二个优点是在IT控制的存储库中保护这一段代码，因此你可以轻松地恢复到干净的环境。结果是生产中不再有“配置漂移”。
现在，自动化系统不再需要劳动密集型且容易出错的手动修补，而是持续监控正在运行的系统，并询问“是否正在运行所需（修补过）的版本？”如果没有，系统会自动触发更新。
就像一个仓库
与物理仓库和经典分销供应链一样，持续流和容器镜像存储既带来安全挑战，也带来机遇。考虑零售分销供应链中的这些场景：
——你如何检测并防止篡改最终存放在商店货架上的产品？
——你如何防止假冒？
——当报告有受污染的成分时，你如何隔离不良库存？你如何量化风险并识别有风险的客户？
——如何只让经过授权的人查看库存？
这些“供应链”相关事宜在基于容器的软件中有类似之处，而一些镜像注册表带有处理这些问题的功能。
财务风险和隐私考虑
公共注册服务基本且易于使用，这就是它们如此受欢迎的原因。但是，由于它们在开发人员之间共享，并且主机镜像在多个位置由多达1000个人运行，用公共注册表不太现实。
许多流行的软件组件是开源的并且易于在因特网上找到（通常是预先打包的容器镜像）。但是把这些组件直接用于生产是万万不行的。
可以找到各种开源和商业支持的私有容器镜像注册表。有些提供了一些企业级功能，例如容器镜像安全扫描。有些私有注册表功能齐全，具有严格的治理和审计日志记录等功能。
具有扫描功能的注册表有什么用？
容器的构成方式使得我们可以分析内容并确定其中包含的所有部件。这意味着当在容器镜像中的一个小包中新发现安全漏洞时，你可以判断系统是否易于受到攻击。
行业和政府机构赞助商经常更新常见漏洞和风险（CVE）数据库。一些容器镜像注册表可以利用它们来执行库存镜像的静态分析。无论何时更新，使用镜像或有新的CVE数据库通知，都可以触发扫描。
从互联网下载的这些容器是否值得信赖？通常不行。但是要知道开发人员也不是完美的：他们的代码可能包含错误，并且可能包含存在缺陷的库和包。
如果你的系统记录流和容器镜像的使用，你甚至可以生成报告，以特定的时间、日期和位置量化风险——这就跟在仓库中使用摄像头一样。
用于治理的镜像签名和访问控制
可以对容器镜像签名，并在部署时验证签名——这类似于识别物品出处的激光全息图。同时，一些开源代码可能不被许可用于特定用途，可能使你处于法律风险之中。
通过私有注册表，你可以决定谁来批准可以在你的系统上运行的容器，并允许验证镜像未被篡改。
基于角色的访问控制实施与特定活动、位置和部门相关的用户权限，即谁可以发布更新的镜像，谁可以使用它们。
治理补充扫描。如果没有特定的程序和保护措施，错误和恶意代码（或未经许可使用的代码）可能会在整个组织中出现。
支持复制的好处
当大规模运行时，单个中央注册表不太可能满足需求。在运行容器的系统附近运行注册表可以减少部署延迟并减少网络中断的风险。在负载均衡器之后运行多个注册表实例可带来规模和高可用性的优势。有时，还需要将开发、测试和生产注册表分离为自动化CI / CD管道的一部分。
如果你的注册表支持策略驱动的自动镜像复制，那么多个注册表可以支持自动的持续容器开发工作流程、负载均衡、高可用性和全球规模的多云运维——所有这些都具有最小的运维开销和延迟。
小结
许多流行的容器注册表都是开源的，但有些注册表有更广泛的社区支持。从长远来看，应该寻找在一个有效的组织（如CNCF）的治理下的、充满活力的社区（拥有大量积极参与的开发人员和组织）提供的解决方案。这可以增加快速识别和修复错误的可能性，并添加新的功能。
应用程序开发是一个永无止境的过程，但容器镜像注册表使事情尽可能清晰明了。不过不要满足于提供基本功能和API的简单容器镜像注册表。
