将容器映像推送到容器注册表，然后部署这些映像时，需要为映像标记和版本控制制定一个策略。 本文介绍两种方法，其中的每种方法在容器生命周期内都适用：
- 稳定标记 - 可重复使用的标记，例如，这些标记可指示类似于 mycontainerimage:1.0 的主要版本或次要版本。
- 唯一标记 - 对要推送到注册表的每个映像使用不同标记，例如 mycontainerimage:abc123。
稳定标记
建议：使用稳定标签来管理您的容器构建的基础镜像。 请避免在部署中使用稳定标记，因为这些标记会持续接收更新，并可能导致生产环境出现不一致情况。
稳定标记意味着开发人员或生成系统可以持续提取特定的标记，从而持续获取更新。 “稳定”并不意味着内容已冻结。 相反，“稳定”表示该映像应该根据该版本的意图保持稳定。 为了保持“稳定”，可以通过应用安全修补程序或框架更新来维护系统。
示例
某个框架团队交付了版本 1.0。 他们知道，将来他们将会提供更新，其中包括次要更新。 为了支持给定主要版本和次要版本的稳定标记，它们创建了两组稳定标记。
:1- 主要版本的稳定标记。1表示“最新的”1.* 版本。:1.0- 版本1.0的稳定标记，可以让开发人员绑定到1.0的更新版本，而不会在1.1发布时自动升级到1.1。
有基础映像更新可用，或者发布了框架的任何类型的维护版本时，使用稳定标记的映像将更新到最新摘要（代表该版本的最新稳定版本）。
在这种情况下，会继续维护主要和次要标记。 在基础映像方案中，这使得映像所有者可以提供经过维护的映像。
删除未标记的清单
如果更新具有稳定标记的映像，则以前标记的图像将取消标记，这会导致映像变成孤立映像。 上一个映像的清单和唯一层数据将保留在注册表中。 若要维护注册表大小，可以定期删除稳定映像更新生成的未标记清单。 例如，自动清除早于指定持续时间的未标记清单，或设置未标记清单的保留策略。
唯一标记
建议：在部署中使用唯一标签，特别是在可在多个节点上扩展的环境中。 你可能想要特意部署一致的组件版本。 如果容器重启，或者编排器扩展更多实例，则主机不会意外地提取与其他节点不一致的较新版本。
唯一标记仅仅表示推送到注册表的每个映像具有唯一的标记。 不会重复使用这些标记。 可以遵循多种模式来生成唯一标记，其中包括：
日期时间戳 - 此方法相当常见，因为使用它可以清楚地判断映像的生成时间。 但是，如何将它关联到生成系统呢？ 是否需要查找同时完成的生成？ 处于哪个时区？ 所有生成系统是否已校准为 UTC 时间？
Git 提交 - 在开始支持基础映像更新之前可以使用此方法。 如果基础映像更新已发生，则会使用与上一生成相同的 Git 提交来启动生成系统。 但是，基础映像包含新内容。 Git 提交通常提供半稳定标记。
清单摘要 - 推送到容器注册表的每个容器映像关联到某个清单，该清单由唯一的 SHA-256 哈希或摘要标识。 尽管摘要是唯一的，但它很长且难以阅读，并且与您的构建环境无关。
生成 ID - 这可能是最佳选项，因为此 ID 可能是增量式的，使你能够关联到特定的生成来查找所有项目和日志。 但与清单摘要一样，用户很难阅读它。
如果组织使用多个生成系统，此选项的一种变通方式是使用生成系统名称作为标记的前缀：
<build-system>-<build-id>。 例如，可将 API 团队的 Jenkins 生成系统与 Web 团队的 Azure Pipelines 生成系统中的生成区分开来。
锁定已部署的镜像标签
作为最佳做法，建议将其 属性设置为 write-enabled，以false任何已部署的映像标记。 这样做可防止无意中从注册表中删除映像并防止可能的部署中断。 可在发布管道中包含锁定步骤。
锁定已部署的映像仍然允许使用 Azure 容器注册表功能从注册表中删除其他未部署的映像，以维护注册表。 例如，自动清除早于指定持续时间的未标记清单或解锁的映像，或设置未标记清单的保留策略。
后续步骤
有关本文中的概念的详细讨论，请参阅博客文章 Docker 标记：标记和版本控制 Docker 映像的最佳做法。
若要最大程度地提高 Azure 容器注册表的性能并以经济高效的方式使用它，请参阅有关 Azure 容器注册表的最佳做法。