Welcome back. Throughout the course, we've used tags. In the networking lesson, we used the tag 16. 04 to specify the version of Ubuntu. And in other lessons, the tag latest was implied because we didn't specify a tag for ourselves. In this lesson, we're going to cover tagging a bit more.

Tags provide you with a way of identifying specific versions of an image. Tags make it easy to deploy a specific version, and then if something goes wrong, you can easily roll back to the previous version. One of the useful features of tags is that an image can have more than one tag. This is useful if you want to have version numbers as well as named versions.

An example of this is the Ubuntu image, which has tags for the version, the OS code name, and optionally a tag to indicate the development image, et cetera. So tags are rather versatile and are an important mechanism for a solid continuous delivery process. However, we're not going to cover the use cases here.

Rather, since this is an intro course, I want to cover how to actually tag an image. To do that, we have this basic Dockerfile. Starting at the top, you can see the use of the tagged image version. This is going to use the Ubuntu image that's tagged 16. 04. Then it will create a directory and create a file with the contents of Version 1.

The Docker command will simply print the message to standard out by using the concatenate command. Okay, let's build this Dockerfile into an image. With the T flag, we're actually specifying the tag. Thus far, we've used the tag as just the local image name. However, the tag structure allows you to define a Docker registry where the image will reside.

If you don't include a registry name, Docker assumes that you want to use its registry by default. And then you can specify your registry, your username and the image name. And finally you can end it with a tag. Now, this may sound confusing, so let's use an example. Let's give this an image name of tag_demo.

And it takes a second to build, and here at the end, notice it says successfully tagged as tag_demo:latest. Up here, we only provided the image name, so Docker provided the tag of latest automatically. If you don't provide a tag, then Docker automatically uses the special tag called latest. If we list off the images, there it is, and the tag says latest.

Now, imagine you want this image to be Version 1. So, let's use the command that we haven't used before called docker tag, and we'll specify the tag_demo image with a tag of latest. And now we need to set our new tag. It doesn't require the same name. However, I'm going to keep it the same name for consistency.

So we'll call it tag_demo:v1. OK, and listing it off, you can see that it's listed as v1. Notice that both images have the same ID. That's because it's the same image with just a different way to reference it. If I was to run a container based on the tag_demo image, without specifying a tag, it's going to use the image with a tag of latest.

Anytime you reference an image and you don't provide a specific tag, it's always going to look for a tag named latest. So, running this returns the message in the file of v1. And if we run another and specify the tag of v1, again we get the same message because these two containers are using the same image, which you can tell from the IDs.

Now, let's edit the Dockerfile to write out a different message, let's say, "Version 2," this time, and let's save this, great. Now, let's build this image. This time, I'm going to specify a tag of v2. Okay, check this out. It says it was tagged with v2. Recall that previously when we built the images, we didn't specify the tag, so it automatically used the tag of latest.

Now, if I list off these images, notice that the v2 image has a different ID than the v1 or latest. Let's create a container based on the image with a tag of latest. Before we do, what do you expect is gonna be printed to the screen here? Which text will print out for the latest image? Well, if you said, "Version 1," then you're correct.

If you said, "Version 2," maybe running the container tagged v2, it will help clarify things. Notice it prints out, "Version 2". The reason is that we built the image after changing the message, and we explicitly set the tag to v2, which means that the latest tag is still set to v1. Let's update the latest tag to point to v2.

So we specify v2, and then we set the latest tag, perfect. Now, listing off the images again, you can see that the IDs match between v2 and latest. If we run a container based on the latest tag, it shows the message, "Version 2". If we run again without specifying a tag, it automatically tries the one with a tag of latest and again, Version 2.

Let's make another change to the Dockerfile and we'll change the message again to Version 3, and let's save this, perfect. Now, let's build it again, and tag it with a name but without providing a tag explicitly, so that it's automatically going to be tagged as latest. Listing off the images, the three named tag_demo each have a different tag.

If we run a container based on the image named tag_demo, it going to print off the message, "Version 3". So now let's tag the latest image as v3. And listing off the images, you can see that v3 and latest are both the same image. Running either the image named latest or v3 will produce the same message.

Throughout the course so far, I've used some of the public images in the Dockerfile as our base image. Let's use one of our own images as a base. First, let's create a new directory and CD into it. And now let's use nano to create a new Dockerfile. And for this, the only instruction we're going to use is the FROM instruction, and we'll specify tag_name and we'll use v2, and now let's build this.

And we'll tag it as different_tag_demo, and we're not going to provide a tag so that it will automatically be set to latest. And if we run a container based on this new image, it prints off Version 2 because, in the Dockerfile, we explicitly used the v2 tag. Outside of the development environments, it's considered a best practice to use explicit tags for the image that you want to use in your Dockerfile.

Do you recall earlier in the course I mentioned Docker Hub? Well, before we wrap up this lesson, I want to show how to push an image to Docker Hub. Let's push the latest version of tag_demo. This is done with a docker push command. If I try this out now, it's going to throw an error. Okay, notice here it's throwing an error because I'm not logged in yet.

So, before you can push an image, you need to authenticate with the docker login command. Before that, you need to have an account set up on Docker Hub. Now, that's a separate thing. You'll need to go create an account for yourself. Notice it has my username set here as a default, so I can press enter to accept that.

And I'll paste in my password, and there we go. We're all logged in. Let's run the docker push command again and specify the image name, and we get another error message. Don't worry, this is expected. Notice here in the URL it's trying to push the image to docker.io/library, followed by the name of the image.

The reason that this failed is that you can't just upload an image of whatever name you want. That would be potentially chaotic. That's why Docker makes you specify the name of your Docker Hub account in the tag. If you recall, I mentioned that the tag structure is a bit more complex than just an image name.

It also allows you to specify a registry, a username, et cetera. In order to push to my Docker Hub account, I need to tag this with my username. So, if I switch over to the Docker Hub UI, you can see it here. The username is separated with a forward slash, then the image name, and then the specific tag.

Okay, perfect, listing off the images, you can see that it has the same ID has the image named tag_demo. Okay, now we are actually ready to push this image to Docker Hub. This time, we just need to provide the new tag of sowhelmed/tag_demo. And if you're following along, you'll need to use your own account name.

Now, back in the Docker UI, there we go. There's our image. It even lists off the command to run so that anybody else can download this image. So, there you have it! Tagging in Docker allows you to give images specific identifiers. An image can have more than one tag. And Docker has a special tag called latest that will be automatically used if you don't specify a tag.

However, the latest tag only represents the last image that you built that you didn't provide a tag, unless you tag it as latest for yourself. So, don't think that by typing latest you're going to automatically get the newest image. That's not how it works. And finally, when you upload a image to the Docker Registry, you'll need to update the tag to include some additional information, such as the account name.

All right, let's wrap up this lesson here. In the next lesson, we're going to summarize what we've covered throughout the course and wrap things up. So, if you're ready to wrap up this course, then I'll see you in the next lesson.