What is a container image?
A container image is a fixed, static file that includes executable code to run an isolated process on IT infrastructure. The image is composed of system libraries, system tools and other platform settings a software program requires to run on a containerization platform, such as Docker, Kubernetes or Podman. The image shares the operating system (OS) kernel of its host machine.
A container image is compiled from file system layers built onto a base or parent image. These layers encourage the reuse of various system components, so the developer does not have to create everything from scratch for every project. Technically, a base image is used for an entirely new container image, while a parent image refers to an existing container image that is being modified. However, in practice, the terms are used interchangeably.
Why are container images used?
Container images bundle an application, providing a consistent and efficient way to package and deploy applications. They also have the following attributes:
- Portability and consistency. The required IT infrastructure software is included in a modularized container that is portable across multiple platforms and environments. This enables application developers to avoid common incompatibility problems that arise when, for example, a version of an OS on which the application was developed and tested is not the same as what was installed in production.
- Efficiency. Containers are lighter and more efficient than traditional virtual machines (VMs). Additionally, more containers can fit onto a single physical server than a virtual server, saving time and money.
- Standardization and consistency. By standardizing IT infrastructure and OSes in containers, organizations can maintain consistent security and governance.
- Flexibility. Containers provide modularization that enables the components that an application uses, such as a database, callable subroutines and even the application itself, to be stored in individual, virtual containers. This gives IT flexibility because it can, for example, change a database in one container without having to modify or retest other components, like applications that might exist outside of the database container.
Container image types
Developers classify container images stored in registries as either private or public based on their intended use. Private registries are accessible only to specific users and are used for applications that are not to be shared -- for example, an app that's designed for a specific organization's employees. Developers use public registries to share applications they want to make public.
Although a developer can create a container image from scratch using a container platform, like Docker, Kubernetes or Podman, many IT companies offer prebuilt container images of their own systems or applications that can help simplify the image creation process. Examples of vendor-provided container images include Microsoft SQL Server, various Linux distributions or images made publicly available by vendors like Amazon, IBM and Oracle. GitHub maintains its own container images in GitHub Container Registry, and the Docker community maintains official Python container images on Docker Hub.
As developers explore these various container image types, they must ensure that the images being furnished are authentic so they do not introduce malware into their systems.

How are container images created?
A key benefit of container images is the ability to borrow from many components that already exist in IT infrastructure to construct the contents of the container. These contents can be tailored to fit the needs of the applications that will invoke or exist in the container. Container images consist of the following components:
- Base image. Container images are built using a layered structure. The bottom layer is the foundation, where most container workflows start and the container's file systems are stored.
- Libraries. These are collections of prewritten code that the application in the container runs.
- Application code. These are executable files required for the implementation of the various programs and commands.
- Configuration files. These govern the container's creation and operation.
Containers can also be divided into the following four functional types:
- Object containers. These store metadata about a particular container image, such as when it was created and by whom.
- Dependency containers. They manage object creation and the lifecycle of objects within the application.
- Authentication containers. These containers help establish a user's identity and enforce access control policies.
- Container runtimes. These foundational software programs act as bridges among the container images, OS and hardware, executing applications and ensuring they function properly.
How do container images work?
Container images are essentially blueprints for creating containers. They are identified through the first 12 characters of a true identifier, such as Secure Hash Algorithm 256, and have a virtual size that is measured in terms of distinct underlying layers. Images can be tagged or untagged and are searchable through a true identifier only.
Container images rely on open standards and operate across different infrastructure, including virtual and physical machines and cloud-hosted instances, to be widely interoperable. In container deployments, applications are isolated from one another and abstracted from the underlying infrastructure.
Container images can vary in size. Large images might include all the runtime, infrastructure dependencies, application and OS kernel images that an application requires to run. The result can be a heavy load container image that is fully integrated but resource-intensive and difficult to maintain when a change must be made somewhere within it.
Another approach to containerization that is more often used is to modularize the various components of an end-to-end application execution process into discrete, individual containers that are invoked by the application as the app requires them. For example, one container might house the database. Another container image might include all the IT infrastructure dependencies and supporting subroutines that the app needs to run. Still another container might have the security and authorization routine for the app or the runtime instructions. In this way, a single container image can be modified without having to modify all other containers that an application uses.
Container images are initially uploaded to a container registry, which is a central storage location for these images. Authorized users can then pull them into their applications.
Container image benefits and drawbacks
Container images offer numerous benefits, including the following:
- Ease of use. The container image format is designed to download quickly and start instantly.
- Reusability. Because a container image bundles an application and its dependencies, the app does not need to be rebuilt for other environments.
- Lightweight. A running container generally consumes less compute and memory than a comparable VM.
Container images also have the following drawbacks:
- Potential for fraudulent images. Organizations must monitor for fraudulent images and train users on best practices when they pull from public container repositories. They can create a limited, trusted list of available images to avoid this issue.
- Container image sprawl. Organizations can end up with an accumulation of similar or unused container images, which can lead to storage inefficiencies and potential security risks.
- Resource consumption. Stopped containers are not automatically removed and continue to consume storage resources. Docker commands can be used to remove unused images and containers. Automation can also be used to purge containers after a predefined period of nonuse.
Although most enterprises use Linux for container deployments, learn about the benefits of using Docker on Windows.