Docker Terminology & Concepts
  • 07 Apr 2021
  • 4 Minutes to read
  • Dark
    Light
  • PDF

Docker Terminology & Concepts

  • Dark
    Light
  • PDF

While Docker users rarely need to worry about the implementation details, these may become important when you manage and troubleshoot a private Docker registry.

Here's a brief guide to help familiarize yourself with basic Docker terminology and concepts.

Registry; a registry is a Docker feed in ProGet, but generally speaking it's a server that hosts Docker repositories and related metadata. registry-1.docker.io and mcr.microsoft.com are also registries.

Repository; a repository is contained within a registry, and is essentially just the name of a container and a collection of tags. It's kind of like a package name. For example, inedo/proget and dotnet/core are repository names, but don't refer to a specific image.

Image; an image, or container image, is what many people think of when they say "container". The Docker client downloads images from a repository and runs an image as a container. Behind the scenes, an image is comprised of a manifest and bunch of layers described in that manifest.

Layer; a layer is a .tar archive file (like a .zip file) that represents a "file system snapshot". By extracting a number of layers on top of each other (i.e. in the same directory), you end up with the file system that's used by a container.

When you use the Docker client to build a container image, each command generates a new snapshot. Before running a container image, the Docker client assembles all of the layer files to make the file system.

Layers can be stored within the registry (as a blob), or they can be a url. Many Windows-based images use url-based layers, perhaps for licensing purposes.

Blob; blobs are the low-level storage mechanism in a registry, and they're essentially just files without a name. Instead of using filenames, blobs are accessed by their digest (hash). This means humans really can't work with blobs, and you need a tag or a manifest to reference them in a meaningful manner.

Blobs are used to store layers (.tar files) and container configuration files (.json files). In Docker v1, blobs used to be used to store manifests (.json files), but those are now stored separately.

Digest (hash); digest and hash are generally synonymous in Docker terminology, and both refer to the SHA256-based hash of a blob. It's effectively the "filename" of a blob - but because it's automatically generated by the file's contents, it can never be changed.

Tag; this is how container images in a repository are accessed by humans. Essentially it's a human-readable alias of the digest (hash) of a manifest. Tags are not part of any image metadata themselves, they are purely a label provided by whatever repository their corresponding images are hosted in (whether it’s Docker client’s local repository, Docker Hub, ProGet, etc.).

For example, the tags inedo/proget:5.3.1 and inedo/proget:5.3.2-ci.4 would refer those container images.

A tag is formatted with two parts («image-name»:«tag»), which can be a bit confusing because the second part of a tag is also called a tag. As such, tag (an alias of a manifest's digest) and tag (the second part of a tag) are often used interchangeably.

In practice, tags (manifest digest aliases) are «image-name»:«version-like-string», and the «version-like-string» can convention-driven words (like latest or latest-v6) or semantic versions.

Manifest. A manifest is a JSON document that lists all of the layers of the image, which can be either blobs or urls. It may contain the digest for a container configuration file in a "config" element.

Like everything else in Docker, manifests can only be found using a digest (hash), even though they are not blobs. Practically, manifests are referenced by a tag, which provides the required digest.

Container configuration file. This is a JSON document that is stored as a blob, and is referenced via the "config" element of an image manifest. It's produced by the Docker client at build time, and contains metadata that's used to run the image, such as environment variables, exposed ports, operating system, etc.

Container configuration files are optional, and not all container images will use them.

Manifest list (fat manifest). A manifest list is a sort of "virtual" image that allows users to use a single tag to refer to multiple container images for different architectures (such as AMD/Intel x64, or ARM, etc.).

A manifest list is a JSON document that lists other image manifests, along with their architectures. For example, the hypothetical tag fatimg/java-jdk:5.2.1 could reference a manifest list instead of a manifest. In that case, the Docker client would search the list for a compatible architecture (such as x64), and then follow the digest to find the manifest file, and then start assembling the image.

Dockerfile is a code file that's written in a proprietary programming language. It's processed by the Docker client to construct an image by creating file system snapshots after each command (these become layers), then building a manifest and container configuration file.


Was this article helpful?