Container Engines: How They Work and Top 7 Options

What Are Container Engines?

Container engines can run multiple, isolated instances, known as containers, on the same operating system kernel. Containers perform virtualization at the operating system level, and provide a controllable, easily manageable environment for running applications and dependencies. Container isolation can also enhance security by separating programs, applications and code from other applications running on the same physical host. 

Most modern container engines use the Open Container Initiative (OCI) container image format. OCI container images are a representation of a container and the software that should run within it, making it possible to create new containers in a predictable, repeatable way. 

A key component of a container engine is the container runtime, which communicates with the operating system kernel to perform the containerization process and configure access and  security policies for running containers.

This is part of our series of articles about container platforms.

Related content: read our blog post about container isolation ›

In this article, you will learn:

• How Do Container Engines Work?
• What is a Container Runtime?
• Top 7 Container Engines
• Docker
• CoreOS rkt
• runC
• Containerd
• CRI-O
• Hyper-V and Windows Containers
• LXC
• Container Security with Aqua

How Do Container Engines Work?

Container engines traditionally had their own format for container images (for instance, Docker, LXD and RKT each had their own format). Some image formats constituted a single layer, while others consisted of tree-like layer stacks. However, almost all major tools and engines today have adopted the OCI format, which specifies the metadata and layers in each container image. defines the layers and metadata of a container image. The format defines container images consisting of a tar file for each layer and a manifest.json file that contains metadata.

The OCI (Open Container Initiative) is built on the Docker V2 image format and has successfully integrated an extensive ecosystem of container engines, cloud providers and tools, including security screening, building, signing and migrating tools. 

There are several container engines available, including LXD, RKT, Docker and CRI-O. Additionally, it is not uncommon for cloud vendors, container platforms and Platform as a Service (PaaS) providers to have their own built-in container engine that uses OCI-compatible container images. All these various platforms support interoperability, as they have a container image format that complies with industry standards.

At a deeper level, container engines don’t typically run containers, but rather rely on OCI-compliant runtimes (i.e. runc). Container engines usually:

• Handle user inputs
• Handle inputs over APIs (usually the Container Orchestrator’s API)
• Pull the container image from a registry server
• Use your graphics driver to decompress and expand container images on disk
• Prepare mount points for containers, usually using copy-on-write storage
• Prepare metadata to pass to the container runtime to launch the container correctly, based on container image defaults (e.g. ArchX86 and SECCOM rules) or user input that override the defaults (e.g. CMD and ENTRYPOINT)
• Call the container runtime 

What is a Container Runtime?

The container runtime is a commonly used low-level component in container engines, but can also be used for manual testing. The OCI runtime standard reference implementation is runc.

The container runtime typically:

• Consumes the mount point from the Container Engine (it can also be a regular directory for testing)
• Consumes metadata from the Container Engine (you can also manually create config.json for testing)
• Communicates with the kernel to launch the containerization process (clone system calls)
• Configures cgroups
• Configures SELinux policies
• Configures AppArmor rules

Top 7 Container Engines

Following are the seven of the world’s most widely used container engines. 

Docker

• Product page: https://www.docker.com/products/docker-hub
• Documentation: https://docs.docker.com/
• License: Free and paid options
• Operating system support: Windows, Linux, Mac

The Docker container system offers a full set of features, with both free and paid options, making it the dominant container technology. It is the default container runtime in Kubernetes, with its own image specifications, command line interface and container image building service. 

Docker allows you to control container state through a RESTful API. It runs on each node as a daemon, with the command-line client using the API to build, deploy and maintain container images. It is supported by Windows, Linux and Mac.

CoreOS rkt

• Repo: https://github.com/rkt/rkt
• License: Open source
• Operating system support: Linux 

Pronounced “Rocket”, rkt is an open-source production container runtime that supports Docker and appc images. rkt is easy to use in Kubernetes and offers unique features such as TPM support. While it is optimized for application containers and offers compatibility and portability, rkt doesn’t have as many third-party integrations as Docker. The future of rkt is uncertain, as CNCF support was discontinued in 2019. 

runC

• Repo: https://github.com/opencontainers/runc
• License: Open source
• Operating system support: Linux

This lightweight, open-source, universal container runtime allows you to run containers from the command line. runC is based on the OCI specification and has a standardized, readable document for the container runtime elements, as well as a Docker code-based implementation. It uses the Docker libcontainer library interface to set up containers.

Because runC is standardized, it allows containers to be portable so you don’t have to be tied to a specific vendor or technology.

Containerd

• Product page: https://containerd.io/downloads/
• Documentation: https://containerd.io/docs/
• License: Open source
• Operating system support: Linux, Windows

An open-source daemon supported by Linux and Windows, containerd is an interface between container engines and runtimes. It facilitates the management of container life cycles through API requests, so you don’t have to make multiple system calls, which might vary between platforms. Thus, the containerd API adds a layer of abstraction and enhances container portability.

CRI-O

• Repo: https://github.com/cri-o/cri-o
• License: Open source
• Operating system support: Red Hat Linux

An implementation of the Kubernetes Container Runtime Interface (CRI), CRI-O is an open-source, lightweight alternative for Docker and rkt in Kubernetes. It enables the use of OCI-compatible runtimes to run pods—it primarily supports Kata and runc but you can plug in any OCI-compliant container runtime. 

Hyper-V and Windows Containers

• Documentation: https://docs.microsoft.com/en-us/virtualization/windowscontainers/
• License: Free
• Operating system support: Windows, Linux

These two container technologies, available for free starting from Windows Server 2016, are lightweight alternatives to full Windows VMs. Windows Containers provide abstraction, much like Docker, while Hyper-V Containers use VM virtualization. Each Hyper-V container has its own kernel, making them more portable than typical containers, allowing you to run applications that aren’t compatible with your host system. 

The increased isolation of Hyper-V (from the host and other environments) also provides enhanced security. Compared to containers that use a shared kernel, Hyper-V can have a larger infrastructure footprint.

LXC 

• Repo: https://github.com/lxc/lxc
• License: Open source
• Operating system support: Linux

Part of the open-source LinuxContainers.org project, LXC offers low-level tools for container management and is older than Docker. The LXC application environment is isolated and similar to a full VM, but without its own kernel. LXC is based on Unix processes, so it doesn’t have a central daemon—containers act as if they are managed by separate programs.

Container Security with Aqua

Aqua’s security platform provides full visibility and control over cloud-native applications, with tight runtime security controls and intrusion prevention capabilities, at any scale.

• Full lifecycle security of containerized applications (Windows and Linux containers, CaaS, or serverless)
• Multi-tenancy Management
• Superior Runtime Protection – enforce image immutability & least privileges, enabling the lockdown of container activity to allow only legitimate behavior, enforcing container runtime network profiles
• Ensure Business-Critical Applications’ Continuity – blocking suspicious activity and rotate secrets with no container restart