Distributing images

A registry is a service that stores, manages, and distributes images. Public services, such as Docker Hub (https://hub.docker.com) and Quay (https://quay.io), collect all kinds of pre-built images of popular tools, such as Ubuntu, nginx, and custom images from other developers. The Alpine Linux tool we've used many times already is actually pulled from Docker Hub (https://hub.docker.com/_/alpine). You can upload your own tool onto these services and share them with everyone else as well.

If you need a private registry, but for some reason you don't want to subscribe to the paid plans of registry service providers, you can always set up one on your own with the Docker Registry (https://hub.docker.com/_/registry). Other popular registry service providers include Harbor (https://goharbor.io/) and Portus (http://port.us.org/).

Before provisioning a container, Docker will try to locate the specified image in a rule indicated in the image name. An image name consists of three sections, [registry/]name[:tag], and it's resolved with the following rules:

  • If the registry field is left out, Docker searches for the name on Docker Hub
  • If the registry field is a registry server, Docker searches the name for it
  • You can have more than one slash in a name
  • The tag defaults to latest if it's omitted

For example, an image name such as gcr.io/google-containers/guestbook:v3 instructs Docker to download v3 of google-containers/guestbook from gcr.io. Likewise, if you want to push an image to a registry, tag your image in the same manner and push it with docker push [IMAGE]. To list the images you currently own locally, use docker images. You can remove an image with docker rmi [IMAGE]. The following example shows how to work between different registries: downloading an nginx image from Docker Hub, tagging it to a private registry path, and pushing it accordingly. The private registry is hosted locally with docker run -p 5000:5000 registry.

Here, we use the registry mentioned previously with the most basic setup. A more detailed guide about the deployment can be found at the following link: https://docs.docker.com/registry/deploying/.

Notice that although the default tag is latest, you have to tag and push it explicitly:

$ docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
802b00ed6f79: Pull complete
...
Status: Downloaded newer image for nginx:latest

$ docker tag nginx localhost:5000/comps/prod/nginx:1.15
$ docker push localhost:5000/comps/prod/nginx:1.15
The push refers to repository [localhost:5000/comps/prod/nginx]
...
8b15606a9e3e: Pushed
1.15: digest: sha256:(64-digits-hash) size: 948
$ docker tag nginx localhost:5000/comps/prod/nginx
$ docker push localhost:5000/comps/prod/nginx
The push refers to repository [localhost:5000/comps/prod/nginx]
...
8b15606a9e3e: Layer already exists
latest: digest: sha256:(64-digits-hash) size: 948

Most registry services ask for authentications if you're going to push images. docker login is designed for this purpose. For some older versions of Docker, you may sometimes receive an image not found error when attempting to pull an image, even though the image path is valid. This is likely to mean that you're unauthorized with the registry that keeps the image.

In addition to images distributed via the registry service, there are options to dump images as a TAR archive and import them back into the local repository:

  • docker commit [CONTAINER]: Commits the changes of the container layer into a new image
  • docker save --output [filename] IMAGE1 IMAGE2 ...: Saves one or more images to a TAR archive
  • docker load -i [filename]: Loads a TAR image into the local repository
  • docker export --output [filename] [CONTAINER]: Exports a container's filesystem as a TAR archive
  • docker import --output [filename] IMAGE1 IMAGE2: Imports an exported TAR archive

The commitsave, and export commands look pretty much the same. The main difference is that a saved image preserves files in between layers even if they are to be deleted eventually. On the other hand, an exported image squashes all intermediate layers into one final layer. Another difference is that a saved image keeps metadata such as layer histories, but this isn't available with an exported image. As a result, the exported image is usually smaller in size.

The following diagram depicts the relationship of states between a container and the images. The captions on the arrows are the corresponding Docker sub-commands:

The container technology is tightly bound to operating system features, which means an image built for one platform can't run on another platform without recompiling a new image on the target platform. To make this simpler, Docker introduced the Image Manifest, which supports multi-arch builds. We won't discuss multi-arch builds in this book further, but you can find more information at the following link: https://docs.docker.com/edge/engine/reference/commandline/manifest/
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset