What is a Container and what is a Container Image?

You have heard of containers, but find them a bit of a mystery? Then this article is perfect for you. In it, we explain the concept and characteristics of containers. This helps to understand why containers are one of the big trends in IT.

What is a Container? 

The concept of a container is based on that of a shipping container. It is a standardized box holding whatever you want to deliver (=> your application), but sets no constraints on whether transportation is by air, sea or land (=> on what hardware platform the application is to run on).

At the OS level, a container is simply another process on your host machine that has been isolated from all other processes. This isolation leverages chroot, kernel namespaces and cgroups, features that have been in Linux for a long time, but were not really used by developers. However, in 2013, Docker and Quay worked to make these capabilities approachable and easy to use, sparking the container revolution. Unlike a virtual machine, a container does not include hardware drivers or a kernel, thus operation teams are free to choose the hardware and host OS they want (e.g. Linux, MacOS, MS Windows). To run a container, you need to install a Container Engine such as Docker, CRI-O, Podman or containerd. The open source engine runC from Docker is the underlying technology used in these container engines. CRI-O is the engine used in Kubernetes since version 1.18.

Since this primarily a Kubernetes Blog Post, I will quickly introduce pods. Kubernetes does not run containers directly, but wraps one or more containers into a higher-level structure called a pod. Any containers in the same pod will share the same resources and local network. Pods are used as the unit of replication in Kubernetes.

Figure 1: The hierarchical layers of two containers (“Container Engine” and above) and the underlying hardware. The Pod is a Kubernetes-only component.

What is a Container Image?

At a high-level the container engine downloads an image and unpacks it into an isolated runtime filesystem bundle, which it mounts onto the underlying filesystem. The bundle must hold everything needed to run an application including all dependencies, configuration, scripts and binaries. The image also contains other configuration for the container, such as environment variables, a default command to run, and other metadata. Images are read only and immutable, thus the container engine must provide a thin read/write capability, like COW (Copy On Write), to store all file system mutations. All changes made to the running container, such as writing new files, modifying existing files, and deleting files, are written to this container layer.

Containers at Safe Swiss Cloud

Learn more about the Kubernetes/OpenShift distribution as implemented at Safe Swiss Cloud.

What makes up an Image?

According to Wikipedia, an image is a serialized copy of the entire state of a computer system stored in some non-volatile form such as a file. A system is said to be capable of using system images if it can be shut down and later restored to exactly the same state. A container image is little different. Today, almost all major tools and engines have moved to the OCI (Open Container Initiative) image format which defines the layers and metadata within a container image. OCI defines a container image composed of tar files for each layer, and a manifest.json file with the metadata. Image layers are connected together in a parent-child relationship. Each image layer represents changes between itself and the parent layer.Each layer has a tag and a Universally Unique Identifier (UUID). When creating an image with e.g. Dockerfile (see next section), each directive in the file creates a new layer. 

Figure 2: The Pod, Container and Image hierarchy showing a hypothetical webapp as the image. Layer 1 is the parent image.

Where do you get the Container Image from?

You can build your own image or you can pull a ready made one from one of many public registries such as docker.io or quay.io. It can also come from a private registry like that included with OpenShift or from your own computer. To build your own image you can use tools such as Docker,  Buildah, Podman, Kaniko or OCIBuilder. All images are built from a ready-made parent image or self constructed base image, which often contains a small, lightweight operating system like alpine, which can be only 5MB in size. The instructions on how to build the image are defined in e.g. a Dockerfile. Images, like those delivered with OpenShift, are available as “builder images” for popular programming languages such as Golang, Python and Java as well as frameworks like .NET. Image versions are tagged e.g. “latest” or “version1.0” and stored in image repositories. A collection of image repositories is called an image registry. 

Further Reading

Containers at Safe Swiss Cloud

Learn more about the Kubernetes/OpenShift distribution as implemented at Safe Swiss Cloud.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Please Note:
You may use one of these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>