Removing Tags and Introduction to Multi-Stage Builds

Now run the `docker image ls` command again to see the updated list of local images: ```console $ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE docker-gs-ping latest 7f153fbcc0a8 6 minutes ago 1.11GB docker-gs-ping v1.0 7f153fbcc0a8 6 minutes ago 1.11GB ... ``` You can see that you have two images that start with `docker-gs-ping`. You know they're the same image because if you look at the `IMAGE ID` column, you can see that the values are the same for the two images. This value is a unique identifier Docker uses internally to identify the image. Remove the tag that you just created. To do this, you’ll use the `docker image rm` command, or the shorthand `docker rmi` (which stands for "remove image"): ```console $ docker image rm docker-gs-ping:v1.0 Untagged: docker-gs-ping:v1.0 ``` Notice that the response from Docker tells you that the image hasn't been removed but only untagged. Verify this by running the following command: ```console $ docker image ls ``` You will see that the tag `v1.0` is no longer in the list of images kept by your Docker instance. ```text REPOSITORY TAG IMAGE ID CREATED SIZE docker-gs-ping latest 7f153fbcc0a8 7 minutes ago 1.11GB ... ``` The tag `v1.0` has been removed but you still have the `docker-gs-ping:latest` tag available on your machine, so the image is there. ## Multi-stage builds You may have noticed that your `docker-gs-ping` image weighs in at over a gigabyte, which is a lot for a tiny compiled Go application. You may also be wondering what happened to the full suite of Go tools, including the compiler, after you had built your image. The answer is that the full toolchain is still there, in the container image. Not only this is inconvenient because of the large file size, but it may also present a security risk when the container is deployed. These two issues can be solved by using [multi-stage builds](/manuals/build/building/multi-stage.md). In a nutshell, a multi-stage build can carry over the artifacts from one build stage into another, and every build stage can be instantiated from a different base image. Thus, in the following example, you are going to use a full-scale official Go

This section reinforces the concept of removing a tag from a Docker image using `docker image rm` and verifying its removal with `docker image ls`. It highlights that removing a tag doesn't remove the actual image if other tags point to it. The section then introduces the concept of multi-stage builds to address the issue of large image sizes and potential security risks by carrying artifacts from one build stage to another, potentially using different base images for each stage.