Announcing the 23.0 major release for Mirantis Container Runtime—and Moby

We’re excited to announce the first major release of Mirantis Container Runtime—and the Moby project—in two years. The 23.0 release brings widely anticipated features like experimental Container Storage Interface (CSI) and alternative OCI runtime support as well BuildKit by default, critical improvements to health checks, and various other improvements such as more flexible seccomp and a new API version. 

We’ll dive into those changes—and the deprecation of Windows 2016 support—in a moment…but first, you might be asking, “What’s this about Moby?”

For more on what's new in Moby 23.0, check out this Webinar from Mirantis and YouTube Kubernetes creators WeMakeDevs.

This release is the culmination of two years of work to not only advance the technology, but to work together with our friends both at Docker Inc. and in the wider open source community to support the ongoing health and independence of the Moby project.

Moby is the open source container framework that you might know as “Docker” or the “Docker Engine”— it unifies a variety of libraries and components into a polished container development and execution experience. It’s the project “upstream” of not only Mirantis Container Runtime, but Docker CE and Docker Desktop, as well as various open source projects. 

Mirantis Container Runtime has always had an “upstream-first” approach to development, with our engineers contributing directly to the Moby project in order to deliver the work we do on MCR to the entire community, in the open. With MCR 23.0, we are deepening the customer-facing aspects of this commitment by following upstream version numbers so users can easily understand what code is present in MCR, and seamlessly switch between the community open source project and the supported, enterprise-grade Mirantis Container Runtime. 

For customers, this helps you rest assured that you’re building on a trusted, industry-standard engine without gotchas, surprises, or vendor lock-in—precisely what you need from a foundational component like a container runtime.

In this spirit, the Mirantis Container Runtime team and the Moby development community are excited to share some high-impact changes in Moby and Mirantis Container Runtime. You can read further about these changes and more—including additional notable changes ranging from to rootless improvements to updated seccomp filters—in the full release notes. 

This release introduces experimental support for Container Storage Interface (CSI) drivers in Swarm. CSI drivers are the same storage drivers that Kubernetes uses, and as Swarm matures as a CSI-compliant implementation it is expected that an entire ecosystem of persistent storage backends will become available.

To be usable with Swarm, a CSI driver must not be directly coupled to the Kubernetes control plane. The driver must also be (re)packaged natively for Swarm as an Engine plugin.

At this time, CSI on Swarm is only fit for development and experimental use. Mirantis is working actively with the Moby development community to evangelize Swarm CSI and mature its implementation, quickly addressing any bugs and missing features as they become apparent.

If you are interested in experimenting with or helping iterate on Swarm CSI, check out the community-led and coordinated effort on GitHub.

Moby 23.0 also significantly enhances support for alternative OCI runtimes, finally enabling support for some well-known alternatives to “conventional” containerization, such as Kata Containers and gVisor. While previous releases did support some alternative runtimes, they had to be “drop-in” compatible with the default runc implementation.

In the 23.0 release, we additionally support alternative shims, the programs that mediate between containerd (the component of Moby that manages containers) and the “concrete” runtime that executes the container itself (for example, the Kata Containers containerd shim uses a lightweight hypervisor).

While it is not currently possible to use alternate shims with cri-dockerd (and thus Kubernetes), the implementation allows for experimentation with and standalone use of other containerization technologies. Mirantis plans to improve support for alternative runtimes by fixing any incompatibilities as they become apparent, and is also exploring packaging alternate runtimes so that MCR customers can switch easily and at-will.

The 23.0 release defaults to the BuildKit builder (DOCKER_BUILDKIT=1) on Linux. In addition, the 23.0 CLI will make docker build an alias for docker buildx build. This reflects the growing maturity of BuildKit, and it will help customers to take advantage of the significant improvements that BuildKit brings in caching, performance, and flexibility. Though this is a large change in behavior, it is also a mostly transparent one, and users should be aware that they can still request the previous behavior through DOCKER_BUILDKIT=0.

For more information on the differences between the legacy builder and BuildKit, consult Differences between legacy builder and BuildKit from the upstream documentation.

The 23.0 release increments the supported Docker Engine API version to 1.42. With this version of the API, the volume prune action only considers anonymous volumes, ignoring those that were given a name at creation. This change in behavior only occurs when both the CLI and daemon support API version 1.42. 

Only Mirantis Container Runtime 23.0 supports API 1.42 at this time, and thus an updated API client such as the Mirantis Container Runtime 23.0 CLI is required to encounter this new behavior. Users should be aware that older versions of the Docker Engine API continue to consider both anonymous and named volumes when performing a volume prune.

A new all=1 filter is available for use with Docker Engine API 1.42 to widen the filtering to once again consider named volumes. Specifically, using the Mirantis Container Runtime 23.0 CLI, docker volume prune --filter all=1 produces the same result as docker volume prune with an older CLI. docker system prune -a is not able to specify this filter, and as such will always reflect the default behavior of the negotiated API version.

You can refer to Docker Engine API (1.42) for the full API documentation, and to the Engine API version history for the full list of changes.

Version 23.0 will not support Windows Server 2016—while this may be disappointing to some users, it is the result of paying down significant technical debt in Moby. Customers on Windows Server 2019 and newer will benefit from faster development of and fixes for Windows container support, as the mature implementation of containers present in newer versions of Windows will be used universally.

Note: Mirantis Container Runtime 20.10 continues to support Windows Server 2016. End-of-Life for Mirantis Container Runtime 20.10 has been extended to December 2023 to ease the transition.

The overhead that is required to perform a health check is no longer counted as part of the time threshold – this helps significantly reduce the chances of a “thundering herd” situation when a node is under heavy load, as increased overhead will not mark your containers as unhealthy. Also, health checks now properly resume when the daemon is restarted with running containers. Finally, rather than being left to hang indefinitely, timed-out health check processes are now more reliably terminated.

In addition to the above changes implemented upstream, Mirantis Container Runtime 23.0 includes some distribution-specific differences:

This major version is supported on new platforms including:

• Oracle Linux 8

• RHEL 9

• Windows Server 2022

Support for Rocky Linux 9 and Ubuntu 22.04 Jammy is coming soon.

Beginning with the release of MCR 23.0, Mirantis will no longer deliver unsupported storage drivers to customers. While this creates an upgrade barrier for customers using MCR 20.10 with an unsupported storage driver, it is certain to prevent the late discovery of an unsupportable MCR deployment.

overlay2 is the only storage driver MCR will build and support, with the exception of the btrfs storage driver on the SLES platform, which will be supported in parallel with overlay2.

While Mirantis will continue to make the vfs storage driver available, it is only present for the purpose of helping to debug the storage backend. The vfs driver remains unsupported and is unsuited for use in production environments.

In removing the unsupported storage drivers, Mirantis aims to align customers with a longer-term migration to new storage backends that are currently under development in the Moby project.

Other points of interest:

• overlay2 is now preferred to btrfs and ZFS, which affects new MCR deployments running on SLES systems.

• overlay2 can no longer be used on a filesystem without d_type, which may prevent in-place upgrades of some existing systems.

This is an exciting milestone for both Mirantis Container Runtime and Moby, and we’re thrilled to share it with the community. If you have any questions or thoughts, don’t hesitate to get in touch—or get involved!