Docker Images

A Docker image is a self-contained unit that contains everything required for an application to run. An image can then we run as-is, without any additional code, on a supported Docker environment.

The main difference between a Docker image and a container is that an image is a static, immutable snapshot of an application and its dependencies, while a container is a running instance of an image with its own isolated filesystem, network stack, and process space, capable of maintaining its state during runtime. You can and often would multiple containers all sourced from the same single image.

Image = build-time

Container = run-time

As images contain only the data that they require, images are small in size (Windows images do tend to be larger than Linux) meaning they are quick to inititally source from the registry and quick to deploy as containers. Some application focused images can run in single-digit MiB.

Pull an image

A Docker server has a local repository where it stores images. To get an image into the local repository is an act called pulling. You will often hear the phrase, pull image x from Docker Hub. This means in effect that on the Docker server a command is run that downloads or pulls the image from a remote source (Docker Hub) into the Docker’s local repository so it can then be deployed as a container.

docker image pull {image:tag}

Push an image

Keeping your Docker images in a registry keeps it available and ready to use. Docker Hub is the default choice but you can use private registries as well. The example below uses Docker Hub for simplicity.

This example uses an image called simple-nginx:latest.

First login to Docker Hub

docker login

The image must have a tag that works in a public registry like Docker Hub. The image of simple-nginx:latest won’t work as it would try to put the image into a repository called simple-nginx. So you need to prefix your image with the target repositorty which will match your account profile.

docker image tag simple-nginx:latest grinntec/simple-nginx:latest

Now push the newly tagged image to the Docker Hub repository

docker image push grinntec/simple-nginx:latest

Registries

A registry is a way to store and publish images for consumption. The most commonly used registry for Docker is the Docker Hub registry. You can browse the Docker Hub registry to locate an image you want to run. Each image will have meta data and documentation so you can check into details or review the usecase prior to pulling and deploying the image. Think of the registry, at least public ones, like a market place. There are other public Docker registries based on your needs search them out. And it’s not unusual for companies to host their own registry for internal consumption. In the Cloud these are hosted on PaaS registry services call Azure Container Registry (ACR) and AWS Elastic Container Registry (ECR).

There are official and unofficia images in the Dockere Hub regsitry. An official image means that Docker Inc have vetted and curated the image so it can be seen as up-to-date, high-quality, secure, and well documented; In other words its a trusted source image and should be safe to run. The alternate is unofficial which in essencs is the oopposite whereby these images should be seen as un-safe and you use them at your own risk.

Docker Hub

Names and tags

When you address an image by for example, pulling it, you often use the image:tag syntax and more often than not the tag is latest rather than a version number. Latest is meant to imply that you want to latest stable release of the image. The same tag is often used in other code libraries such as GitHub so it’s a normal reference in the industry to use. To that effect, if you run docker uimahe pull {image} and do not specify a tag value Docker will presume you want latest and append that for you in the background, although this command will fail if the publisher hasn’t tagged their image with latest in the registry.

Layers

Docker images and layers are closely related and crucial to understanding how Docker optimizes storage and distribution. Docker images are composed of multiple layers. Each layer represents a set of filesystem changes, such as adding, modifying, or deleting files. Layers are stacked on top of each other to form a complete image. This layered approach provides several advantages:

On Docker Hub you can inspect the image layers and dig into details such as packages and vulnerabilities with links to the CVE.

Reusability: Common layers can be shared across multiple images. This allows for efficient use of storage, as well as faster image download and deployment times.

vCaching: Docker caches intermediate layers during the build process. If a certain step in your Dockerfile doesn’t change, Docker can reuse the cached layer instead of rebuilding it. This significantly speeds up the image build process.

Version control and traceability: Each layer is versioned and can be tracked individually. This makes it easier to maintain and update images by only modifying the necessary layers.

Image size optimization: By splitting an image into layers, you can minimize the size of the image by only including the necessary components.

When you create a container from an image, Docker combines the image’s layers into a single, writable layer called the container layer. This writable layer allows the container to store any changes made during its runtime while the underlying image layers remain read-only.

Multi-architecture

Images are often created to be able to run on multiple different CPU and operating systems architectures such as ARM, AMD, x64 and Linux or Windows. To be able to make using Docker as smooth as possible these variations are written to a manifest file and automatically called based on the system. Meaning you do not need to specify the architecture type when using the image.