Part 7: A Developer’s Guide to Open Container Initiative (OCI) and Container Runtimes

Explore the Open Container Initiative (OCI), container runtimes, Docker, containerd, runc, and how to interact with containers using command-line tools.

Introduction

Containers have revolutionized the way we build, ship, and run applications. But as the container ecosystem rapidly expanded, so did fragmentation, leading to compatibility and standardization challenges. To address this, the Open Container Initiative (OCI) was born.

This chapter dives deep into what OCI is, its role in standardizing container technology, and introduces you to various tools like Docker, containerd, and runc — tools that form the backbone of today’s container landscape.

What is the Open Container Initiative (OCI)?

The Open Container Initiative (OCI) is a collaborative project under the Linux Foundation, created to set industry standards around container formats and runtimes.

• Purpose: Eliminate fragmentation by setting clear standards
• Focus Areas: Image Format Specification and Runtime Specification
• Major Contributors: Google, AWS, Microsoft, Alibaba, Docker, Cisco, Goldman Sachs, and more

By promoting interoperability, OCI helps ensure that a container image built using one tool can reliably run using another runtime.

What are the Various Container Runtimes?

A container runtime is software that manages the execution of containers.

Here’s what a container runtime generally does:

• Loads and executes container images
• Manages container lifecycle (start, stop, restart)
• Handles isolation of system resources
• Ensures proper networking and storage mount

In simpler terms:

A container runtime does everything related to running a container except running the application itself.

Let’s categorize runtimes based on functionality:

🧱 Sandboxed and Virtualized Runtimes

• These runtimes provide increased isolation between the containerized process and the host, as they don’t share a kernel.

⚙️ Low-Level Runtimes

• These runtimes are responsible for creating and running containers. Once the containerized process runs, the container runtime is not required to perform other tasks.

🧰 High-Level Runtimes

• These runtimes are currently the default Kubernetes container runtime. These provide image specifications, a command-line interface (CLI), and a container image-building service.

🐳 What is Docker?

Docker is a platform that enables developers and sysadmins to create, deploy, and run applications with containers.

Docker comes under the purview of the Open Container Initiative (OCI)

Playing Around with Containers

Let’s understand what containers are all about.

• The container is a container runtime that helps manage the life of a container on any physical or virtual machine.
• It’s used by the Docker engine to create, start, stop, and destroy containers.
• Containers can also pull container images from registries, mount storage, and enable networking for a container.

⚙️ Understanding Containerd

• Containerd is a container runtime designed to manage the entire container lifecycle:
• Pulling images
• Mounting storage
• Networking
• Executing containers

✅ It is used by both Docker and Kubernetes (via CRI).

Containerd installs the following useful components:

• runc — actual low-level runtime
• ctr — CLI tool for managing containers
• containerd-shim — acts as a bridge between containerd and runc

🖥️ How to Interact with Containers Using ctr

Once containerd is installed, it runs as a background daemon. Users can interact with it using the **ctr **command-line tool.

Common ctr commands:

• Pull an image:

ctr images pull docker.io/library/nginx:1.21

• List available images:

ctr images ls

• Import a local image tarball:

ctr images import my-app.tar

• Remove an image:

ctr images remove docker.io/library/nginx:1.21

• Run a container (and auto-remove it):

ctr run --rm -t docker.io/library/debian:latest cont1

These are powerful tools that provide Docker-like functionality directly from a lower layer.

containerd-shim: The Unsung Hero

The containerd-shim enables containerd to run containers without needing to be tightly coupled to them. It helps:

• Keep container processes alive even if containerd stops
• Handle **STDOUT/STDERR**
• Reap zombie processes

This design supports daemon-less containers, improving fault tolerance and system stability.

🧩 What is runc?

Runc is the reference implementation of the OCI runtime spec. It is a low-level tool for spawning and running containers.

💡 You rarely use it **runc **directly unless you’re debugging or writing a new container manager.

Why?

• It is designed for other tools like Docker, Podman, and containerd to invoke
• Not very user-friendly

Still curious? You can explore it here: runc GitHub

🔄 OCI in Kubernetes: Behind the Scenes

In Kubernetes, container runtimes plug into the system using the Container Runtime Interface (CRI). Here’s a simplified flow:

• Kubernetes talks to containerd (CRI plugin)
• containerd talks to runc
• Runc spawns the container

✅ This layered approach brings flexibility, stability, and standardization.

🧾 Recap and Takeaways

Let’s summarize what we’ve learned:

• OCI standardizes container image formats and runtimes
• Docker is a high-level tool built on containerd
• Containerd manages the container lifecycle
• Runc is the low-level runtime that executes the container process
• ctr allows you to interact with containerd directly from the CLI
• containerd-shim helps bridge the gap for managing lifecycle without coupling tightly

Understanding these layers demystifies the container ecosystem and empowers you to go beyond just using **docker run**.

🙌 Conclusion

The Open Container Initiative (OCI) plays a foundational role in modern container technologies. Standardizing how containers are built and run ensures compatibility, scalability, and portability across tools and platforms.

Whether you’re a developer deploying microservices or a DevOps engineer scaling infrastructure, understanding OCI and container runtimes like containerd and runc gives you an edge in mastering the container stack.

Stay tuned as we dive deeper into Docker internals and orchestration tools in upcoming chapters 🚀

💬 Claps, comments, and following the CodingSprints channel are appreciated! 👏

Stay updated and grow your DevOps and programming skills with us:

🔗 Connect with us: 📘 Facebook | 🐦 Twitter | 💻 GitHub | 🔗 LinkedIn

Keep building. Keep learning. See you in the next tutorial! 🚀