上QQ阅读APP看书，第一时间看更新

Storing and sharing container images

So far, you have already pulled your first hello-world container with the docker pull hello-world command and even used the docker run hello-world command. Under the hood, a few things happen during an image pull:

Docker Engine connects to the so-called Docker image registry. The registry can be specified explicitly, but by default, this is the official public registry, called Docker Hub (https://hub.docker.com/).
Docker Engine authenticates to the registry, if needed. This can be the case if you are running a private registry or paid plan for Docker Hub.
The selected hello-world image is downloaded as a set of layers identified by SHA256 digests. Each layer is unpacked after being downloaded.
The image is stored locally.

A similar procedure happens if you execute the docker run command and the image is not present in the local store. The first time, it will be pulled, and later, the locally cached image will be used.

If you are familiar with GitHub or other source repository managed hosting, you will find many concepts in image management and image registries similar.

So, intuitively, the image registry is an organized, hierarchical system for storing Docker images. The hierarchy of images consists of the following levels:

Registry: This is the top level of the hierarchy.
Repository: Registries host multiple repositories, which are storage units for images.
Tag: A versioning label for a single image. Repositories group multiple images identified by the same image name and different tags.

Each image in the registry is identified by an image name and tag, and the hierarchy above is reflected in the final image name. The following scheme is used: <registryAddress>/<userName>/<repositoryName>:<tag> ,for example, localregistry:5000/ptylenda/test-application:1.0.0. When using Docker commands, some of these parts are optional and if you do not provide a value, the default will be used:

<registryAddress> is the DNS name or IP address (together with the port) of the registry that is used for storing the image. If you omit this part, the default Docker Hub registry (docker.io) will be used. Currently, there is no way of changing the default value of the registry address, so if you would like to use a custom registry, you have to always provide this part.
<userName> identifies the user or organization that owns the image. In the case of Docker Hub, this is a so-called Docker ID. Whether this part is required depends on the registry – for Docker Hub, if you do not provide a Docker ID, it will assume official images, which are a curated set of Docker repositories that are maintained and reviewed by Docker.
<repositoryName> is a unique name within your account. The image name is formed as <registryAddress>/<userName>/<repositoryName>.
<tag> is a unique label within a given image repository that is used for organizing images, in most cases using a versioning scheme, for example, 1.0.0. If this value is not provided, the default, latest, will be used. We will focus on tagging and versioning images later in this chapter.

With multi-architecture Docker image variants, it is possible to have different images under the same image name and tag for different architectures. The version of the image will be automatically chosen based on the architecture of the machine running the Docker client. Identifying such images can be performed explicitly using an additional @sha256:<shaTag> part after the image tag, for example, docker.io/adamparco/demo:latest@sha256:2b77acdfea5dc5baa489ffab2a0b4a387666d1d526490e31845eb64e3e73ed20. For more details, please go to https://engineering.docker.com/2019/04/multi-arch-images/.

Now that you know how Docker images are identified, let's take a look at how to push an image to the Docker registry.