Docker标签快速入门 (A quick introduction to Docker tags)

If you’ve worked with Docker even for a little while, I bet you’ve come across tags. They often look like “my_image_name:1” where the part after the colon is known as a tag. The tag is not always specified when tagging images, but we’ll get to the bottom of that later.

如果您与Docker一起工作了一段时间，我敢打赌您会碰到标签。它们通常看起来像“ my_image_name：1”，其中冒号后面的部分称为标签。标记图像时并不总是指定该标记，但是稍后我们将介绍它。

Ever since I started using Docker, I’ve been very confused about tags. The documentation doesn’t explain them very well, and there really aren’t any thorough explanations on the topic. That’s why I decided to write this post.

自从我开始使用Docker以来，我一直对标签感到困惑。该文档对它们的解释不是很好，并且对此主题确实没有任何详尽的解释。这就是为什么我决定写这篇文章的原因。

什么是Docker标签？ (What are Docker tags?)

So, what exactly are Docker tags? In simple words, Docker tags convey useful information about a specific image version/variant. They are aliases to the ID of your image which often look like this: f1477ec11d12. It’s just a way of referring to your image. A good analogy is how Git tags refer to a particular commit in your history.

那么，Docker标签到底是什么？简而言之，Docker标记传达有关特定映像版本/变量的有用信息。它们是图像ID的别名，通常看起来像这样： f1477ec11d12 。这只是引用您的图片的一种方式。一个很好的类比是Git标签如何引用历史记录中的特定提交。

The two most common cases where tags come into play are:

标签起作用的两种最常见的情况是：

When building an image, we use the following command:
构建图像时，我们使用以下命令：

docker build -t username/image_name:tag_name .

Let’s try to unpack what this command does for a bit. We tell the Docker daemon to fetch the Docker file present in the current directory (that’s what the . at the end does). Next, we tell the Docker daemon to build the image and give it the specified tag. If you run docker images, you should see an image whose repository is username/image_name and tag is tag_name.

让我们尝试解压缩该命令的功能。我们告诉Docker守护进程获取当前目录中存在的Docker文件(这就是.结尾的意思)。接下来，我们告诉Docker守护程序构建映像并为其指定指定标签。如果运行docker images ，应该会看到一个镜像，其存储库为username/image_name ，标签为tag_name 。

username/image_name is not a mandatory format for specifying the name of the image. It’s just a useful convention to avoid tagging your image again when you need to push it to a registry.

username/image_name不是用于指定图像名称的强制格式。这只是一个有用的约定，可以避免在需要将图像推送到注册表时再次对其进行标记。

Your image can be named anything you want. For the public Docker registry, you’re restricted to a two level hierarchy while naming images. For example, your image cannot have the name a/b/c:1. This restriction usually doesn’t exist in private registries. As stated before, it’s not mandatory to specify a tag_name. We’ll see what happens in that case soon.

您的图像可以命名为任何您想要的名称。对于公共Docker注册表，在命名映像时仅限于两级层次结构。例如，您的图片名称不能为a/b/c:1. 此限制通常在私人注册表中不存在。如前所述，指定tag_name.不是强制性的tag_name. 我们将很快看到在这种情况下会发生什么。

2. Explicitly tagging an image through the tag command.

2.通过tag命令明确标记图像。

docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

This command just creates an alias (a reference) by the name of the TARGET_IMAGE that refers to the SOURCE_IMAGE. That’s all it does. It’s like assigning an existing image another name to refer to it. Notice how the tag is specified as optional here as well, by the [:TAG] .

此命令仅通过引用SOURCE_IMAGE.的TARGET_IMAGE的名称创建别名(引用) SOURCE_IMAGE. 这就是全部。这就像为现有图像分配另一个名称来引用它一样。注意这里的[:TAG]也将标签指定为可选[:TAG] 。

如果不指定标签会怎样？ (What happens when you don’t specify a tag?)

Alright, now let’s uncover what happens when you don’t specify a tag while tagging an image. This is where the latest tag comes into the picture. Whenever an image is tagged without an explicit tag, it’s given the latest tag by default. It’s an unfortunate naming choice that causes a lot of confusion. But I like to think of it as the default tag that’s given to images when you don’t specify one.

好了，现在让我们发现在标记图像时未指定标记时会发生什么。这是latest标签进入图片的地方。每当为图像添加标签而没有显式标签时，默认情况下都会为其赋予latest标签。这是一个不幸的命名选择，引起了很多混乱。但我想将其视为未指定图像时赋予图像的默认标记 。

A lot of confusion around latest is caused due to the expectation that it’s the latest version of the image, especially in Dockerfiles. Let’s consider the various scenarios with an example:

人们对latest的困惑是由于人们期望它是映像的最新版本，尤其是在Dockerfiles中。让我们以一个示例来考虑各种场景：

方案1： (Scenario 1:)

Suppose the following statement is present in our Dockerfile:

假设在我们的Dockerfile中存在以下语句：

FROM debian

Since we didn’t specify any tag, Docker will add the latest tag and try to pull the image debian:latest .

由于我们未指定任何标签，因此Docker将添加latest标签并尝试提取图像debian:latest 。

方案2： (Scenario 2:)

FROM debian:9.3

Since the tag is explicitly mentioned here, Docker will pull the Debian image tagged 9.3

由于此处已明确提及该标签，因此Docker将提取标记为9.3的Debian映像。

Another thing to keep in mind is that there is no rule which states that an image needs to have just one tag. An image can have multiple tags and they’re usually used to specify major and minor versions. For example, consider this:

要记住的另一件事是，没有规则指出图像只需要一个标签。一个图像可以有多个标签，它们通常用于指定主要和次要版本。例如，考虑一下：

At the time of writing this post, the latest tag for the Debian image points to the 9.3 release and the 9 release. This will most likely change in the future whenever the major or minor version is bumped for the image.

在撰写本文时，Debian映像的latest标签指向9.3版本和 9版本。每当更改主要或次要版本的映像时，将来这种情况很可能会改变。

Please note that tags being used for semantic versioning is a convention that’s followed, but tags weren’t designed just for that purpose.

请注意，用于语义版本控制的标签是遵循的约定，但标签并非仅用于此目的。

总之，最新不是特殊标签 (In conclusion, latest is not a special tag)

The main takeaway from what we’ve covered so far is that latest is just like any other tag. The onus is on the developer to tag the images properly such that latest always points to the latest stable release of the image.

到目前为止，我们主要介绍的内容是最新的标签与其他任何标签一样 。开发人员有责任正确标记图像，以便“ latest始终指向图像的最新稳定版本。

Hence, we don’t explicitly specify a tag in our Dockerfiles when pulling images, since we might end up with a completely different version of the base image than what we had used before. There is no guarantees about whether it’ll be a major bump or minor bump. Even an old release can be tagged as latest.

因此，在拉取映像时，我们不会在Dockerfile中明确指定标签，因为我们最终可能会获得与之前使用的映像完全不同的版本。不能保证它会是主要颠簸还是次要颠簸。甚至旧版本也可以标记为latest 。

P.S. If you found any misconceptions/errors in the post, please feel free to tweet to me @ScribbingOn.

PS：如果您在帖子中发现任何误解/错误，请随时通过@ScribbingOn向我发送推文。

Thanks to Jérôme Petazzoni for helping me make sense of some of this.

感谢JérômePetazzoni帮助我理解了其中的一些内容。