The following terminology is essential to know when discussing containers and their source images. Also, understanding the concepts around image format and how images are stored on your filesystem will allow you to make better decisions regarding managing the sharing and distribution of your container images.
A container is the encapsulation of an application and all of its required dependencies and system resources running within an isolated “space” on a host machine. Containers share the host machine’s operating system and kernel, but they utilize low-level features that allow isolation between processes running inside the container and other processes on the same host. Containers enable the portability of an application or service between different computing environments without the risk of changes in behavior because of differing dependency sets.
A container image is an immutable, executable binary that provides all of the dependencies and configuration required for creating a container. It encompasses all of the environment configuration and explicitly defines all of the resources to which a container will have access after it is launched. Images can be thought of as a snapshot of a complete filesystem stored as an archive that can be unpacked and run within the context of a collection of root filesystem changes.
Using Docker (which requires the installation of Docker Engine) is a common way of building container images. Building images with Docker also requires a text file called a
Dockerfile, a file that serves as the blueprint for a container that explicitly defines the image environment, dependencies, and other configurations. However, there are other options available that use existing
Dockerfiles or an equivalent of a
Dockerfile to build images. Some examples are buildah, orca-build, img, and kaniko.
Images can inherit from other images, and many are built from an initial set of dependencies and configurations that come from a base image. Commonly used base images can describe a base operating system (e.g., ubuntu, alpine, centos) and/or include a specific package or set of dependencies (e.g., java, swift, bash). A base image is not based on any other image and uses the word
scratch in the first line of the image’s
Example: Base Image
Dockerfile for alpine
An image that is based on another will specify the image it inherits from, also known as a parent image, in the first line of the
Dockerfile. A parent image is not required to be a base image.
When an image is built, it is assigned a unique ID in the form of an SHA-256 hex digest calculated from the contents of the image.
An image tag is an alias that is used to point to a specific image binary within an image repository. The tag can be set to any text but is generally used to indicate a specific version of a named image. A tag is unique to an image binary; however, an image binary can have multiple tags. This capability is commonly used along with semantic versioning to tag the latest minor and/or patch version as the latest major version available. For example, the latest binary of an image could potentially have the tags
:latest, similar to the figure below:
Figure 1: Image tags
This is a preview of the Getting Started With Container Registries Refcard. To read the entire Refcard, please download the PDF from the link above.