docker - Docker 镜像及其存储库何时会具有不同的名称？

Question

docker tag的标准用法命令是:

docker tag <image> <username>/<repository>:<tag>

例如: docker tag friendlyhello john/get-started:part1 .

来自 Java-land，我习惯了 group:artifact:version 的 Maven/Gradle 风格的坐标，所以对我来说，这是有意义的 image和 repository成为同一个:
image是您正在生产的工件，在 Java 领域，生成的工件与其代码所在的源存储库之间通常存在 1:1 的关系。所以对我来说，命令更有意义:

docker tag <username>/<repository>:<tag>

例如: docker tag john/get-started:part1 ，其中 john是用户名/组， get-started是工件/ repo 和 part1是标签/版本。

清楚:我是 不是 询问图像和存储库之间有什么区别!我了解存储库是存储图像的位置，并且我了解图像是 Docker 可执行文件，由 Dockerized 应用程序及其依赖项组成。但是从命名的角度来看，我很困惑为什么/何时它们应该彼此不同。

所以我问: image 和有什么区别？和一个 repository从命名约定的角度来看？例如，如果我想制作自己的 MySQL Docker 镜像，我会选择将镜像命名为“myapp-db”，这也是它所在的存储库的名称( smeeb/myapp-db:v1 、 smeeb/myapp-db:v2 、等等。)。

那么在什么情况下是/应该image和 repository名字不一样？

Answer 1

首先是先决条件:标签是指向图像的指针，图像是对 docker 用来制作容器的配置和层 list 的 sha256 引用。这意味着 friendlyhello不是图像的名称，而是指向图像的标签。图像是 id，类似于 c75bebcdd211.... .

接下来，每个图像都可以有零个、一个或多个标签指向它。当它没有任何标签指向它时，这被称为悬空图像。如果您构建带有标签的镜像，然后重新构建它，就会发生这种情况。以前的图像现在未标记，因为标记指向新图像。同样，您可以拥有标签 image:latest , image:v1 , image:1.0.1 , 和 myrepo:5000/image:1.0都指向相同的图像 ID。

标签有双重用途。他们可以是为了方便。但它们也被 docker push 使用和 docker pull查找发送或检索包裹的位置。如果你不做推或拉，那么你可以随意命名它，没有人会知道其中的区别。但是，如果您确实想将其存储在注册表中，则该标签需要标识哪个注册表或默认的 docker hub。并且该标签还需要标识注册表上的路径，称为存储库，以及冒号后的版本控制。

令人困惑的一点是，存储库名称末尾的短名称通常称为“图像名称”，冒号后的版本控制通常称为“标签”，如果您忘记了，我认为这更容易理解这些条款曾经像那样重载。

现在有了所有这些背景(对不起，那太多了)，这里有一些对问题的更正:

代替:

docker tag <image> <username>/<repository>:<tag>

将语法视为:

docker tag <source> <tag>

哪里 <source>可以是图像 ID 或其他标签名称。这意味着以下命令没有意义:

docker tag <username>/<repository>:<tag>

因为 docker tag需要一个来源来标记，并且它对您当前正在使用的图像没有上下文感。

最后，为什么要为图像使用存储库名称以外的名称，以下是我遇到的一些原因:

图像不会被推送到存储库。它可能用于本地测试，或工作流程中的中间步骤，或者您在同一系统上构建和运行图像。

同一图像可能有多个名称。 registry/repo/image:v1和 registry/repo/image:v1.0.1是一个常见的例子。我还将使用 registry/repo/image:STAGE 标记特定环境中的当前图像请注意，它通过了 dev 和 CI，现在处于 staging 环境中。

您可能会在注册表之间移动图像。我们从 hub.docker.com 拉取图像并使用本地注册表在本地重新标记它们。这既为我们提供了本地缓存，也为我们提供了一种控制何时将基础图像更新到下一个版本的方法。这比在生产推出过程中更新图像更可取。

我还使用标签来覆盖上游图像。因此，无需针对上游镜像的问题更改所有构建脚本，我只需进行更改并使用上游名称对其进行标记即可。然后只要我不在那个 docker 主机上运行 pull，构建就会使用我修改后的基础镜像运行。