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幫助我理解了其中的一些內容。