X

News, tips, partners, and perspectives for the Oracle Linux operating system and upstream Linux kernel work

A Brief History of Linux Containers

Mark Cram
Product Management: Oracle Linux Cloud Native Environment

The latest update to Oracle Linux Cloud Native Environment introduces new functionally that we'll cover in upcoming posts but before we dive into those features, let's take a look at the history of Linux containers to see how we got here.

The first fundamental building block that led to the creation of Linux containers was submitted to the Kernel by Google. It was the first version of a feature named control groups or cgroups. A cgroup is a collection of processes whose use of system resources is constrained by the Kernel to better manage completing workloads and to contain their impact on other processes.

The second building block was the namespaces feature which allows the system to apply a restricted view of system resources to processes or groups of processes. Namespaces were actually introduced much earlier than cgroups but they were limited to specific object types like hostnames and Process IDs. It wasn't until 2008 and the creation of network namespaces that we could create different views of key network objects for different processes. Processes could now be prevented from knowing about each other, communicating with each other and each could have a unique network configuration.

The availability of these Kernel features led to the formation of LXC (Linux Containers) which provides a simple interface to create and manage containers, which are simply processes that are limited in what they can see by namespaces and what they can use by cgroups.

Docker expanded LXC's functionality by providing a full container life-cycle management tool (also named Docker™). Docker's popularity led to its name now being synonymous with containers. In time Docker replaced LXC with its own libcontainer and additional controls were added which utilized Kernel features such as AppAmor, capabilities, seccomp and SELinux. These gave developers improved methods of restricting what container processes could see and do.

A key component to Docker's success was the introduction of a container and image format for portability, i.e. a container or image could be transferred between systems without any impact to functionality. This provided the assurance of repeatable, consistent deployments.

This container and image format is based on individual file system layers where each layer is intentionally separated for re-use but is presented as a unified file system when the container starts. Layers also allow images to extend another image. For example, an image may use oraclelinux:7-slim as its first layer and add additional software in other layers.

This separation of layers allows images and containers to share the same bits on disk across multiple instances. This improves resource utilization and start-up time. A new API was created by Docker to facilitate image transfer but pre-existing union filesystems like aufs and then OverlayFS were the base methods to present the unified container filesystem.

While most of us are familiar with Docker, what is less well-known is that those container and image formats and how a container is launched from an image are published standards of the Open Container Initiative. These standards are designed for interoperability so any runtime-spec compliant runtime can use an image-spec compliant image to launch a container. Docker was a founding member of the Open Container Initiative and contributed the Docker V2 Image specification to act as the basis of the image specification.

Through standards like these, interoperability is enhanced which helps the industry continue to develop and grow at a rapid pace. So if you're creating images today with Docker or other Open Container Initiative compliant tools, they can continue to work on other compliant tools like Kata containers which we'll be looking at in an upcoming blog post.


Note: There were alternatives available in other operating systems and outside of mainline Linux prior to LXC but the focus of the article was Linux. Similarly, there were other projects in parallel to LXC which contributed to the industry but are not mentioned for brevity.

Docker is a trademark of Docker, Inc. in the United States and/or other countries.

Linux® is a registered trademark of Linus Torvalds in the United States and/or other countries.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.