What is Moby?

Moby is a set of building blocks that can be used to create a container tool like Docker. The "building blocks" that Moby provides include pull, push, and creating images, which can be used by a container engine to create a usable container tool.

The idea behind Moby is to provide a modular approach to building container tools, allowing developers to mix and match different components to create a tool that meets their specific needs. By providing a set of building blocks, Moby makes it easier for developers to create their own container tools, rather than relying on pre-built tools that may not meet all of their requirements.

Changes with Moby 23.0

After almost two years after its last major release, Moby is finally getting its next major release. Moby 23.0, brings some exciting new features and improvements, along with a couple of deprecations.

Let's go over all the new features and changes that have been announced along with Moby.

CSI driver support

The latest update now offers experimental support for Container Storage Interface (CSI) drivers in Swarm, which are identical to the storage drivers employed by Kubernetes. As Swarm continues to evolve into a CSI-compliant implementation, it's expected that a complete range of persistent storage backends will soon be accessible.

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.

There is even a community-driven GitHub repository to experiment with various CSI drivers for Swarm. Check it out if you're interested in playing around with them.

Alternative OCI support

Moby 23.0 introduces alternative OCI runtime support, which is another significant feature that allows developers to use a different container runtime other than runc. This feature provides developers with the flexibility to choose the runtime that best suits their needs.

The Open Container Initiative (OCI) runtime specification provides a standard interface for container runtimes. This means that any runtime that supports the OCI runtime specification can be used with Moby, as long as it also supports the runc API.

This new feature is particularly useful for folks who require specific features that are not available in runc, or who prefer to use a different runtime for other reasons. With alternative OCI runtime support, you can choose the runtime that best suits your needs, without having to compromise on functionality or performance.

Use BuildKit by default

BuildKit is a container-building engine that has been introduced in Moby, and it has significantly improved the container-building experience. BuildKit provides a more secure and efficient way to build containers, and it has quickly become a popular choice for developers.

One of the best updates is that BuildKits is enabled by default in Moby. This means that you can leverage all the features of BuildKit without having to do anything extra. BuildKit is designed to work seamlessly with Moby, making it a great choice for building secure and efficient containers quickly and easily. To learn about the differences between the legacy builder and BuildKit, check out this page in the Docker documentation.

However, if your requirements are not satisfied by BuildKits, or you want to use a different container builder, prefer you can opt-out of BuildKit support as well. This provides quite a bit of flexibility if you want to stick to other container-building tools.

Health checks

Moby has made significant improvements to the health check feature for containers. One of the most notable improvements is that the overhead required to perform a health check is no longer counted as part of the time threshold. This means that the chances of a "thundering herd" situation occurring when a node is under heavy load are significantly reduced. With this improvement, the increased overhead will not mark containers as unhealthy.

Health checks now properly resume when the daemon is restarted with running containers. This is a significant improvement as it ensures that health checks are correctly performed when the daemon is restarted, and running containers are not left in an unhealthy state.

The health check processes that are terminated due to time-outs are more reliably handled. Previously, timed-out health checks could run indefinitely, causing issues inexplicable issues. With the latest improvements, timed-out health check processes are now more reliably terminated, ensuring that containers are not left in an unhealthy state.

Windows server - a default requirement

Moby 23.0 and the Mirantis Container Runtime by extension, will not support Windows Server 2016, which may be disappointing news for some. However, this decision was made to pay down significant technical debt in Moby. By focusing on newer versions of Windows, specifically Windows Server 2019 and newer, Moby can benefit from faster development and fixes for Windows container support. The mature implementation of containers in newer versions of Windows will be used universally, making it easier to build container tools that are efficient and reliable.

It is important to note that Mirantis Container Runtime 20.10 will continue to support Windows Server 2016, and its end-of-life has been extended to December 2023 to ease the transition. While Moby 23.0 may not support Windows Server 2016, you can still use Mirantis Container Runtime 20.10 to continue using containers on Windows Server 2016.

Gotchas while upgrading MCR

With the latest version of Moby, there are a couple of gotchas that you will need to keep in mind while upgrading your existing solutions such as the MCR. Let's take a look at these gotchas.

Deprecated storage drivers

With the release of MCR 23.0, Mirantis will no longer deliver unsupported storage drivers. This means that if you are using an unsupported storage driver with MCR 20.10, you may encounter a barrier when upgrading to MCR 23.0.

overlay2 will be the only storage driver that 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. The vfs storage driver will still be available, but it is only present for debugging purposes and is not suitable for use in production environments.

It is worth noting that overlay2 is now the preferred driver rather than btrfs and ZFS, which affects new MCR deployments running on SLES systems. In addition, overlay2 can no longer be used on a filesystem without d_type, which may prevent in-place upgrades of some existing systems.

Volume pruning and API changes

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

It is important to note that older versions of the Docker Engine API continue to consider both anonymous and named volumes when performing a volume prune. To widen the filtering to once again consider named volumes, a new all=1 filter is available for use with Docker Engine API 1.42. However, 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.

In order to encounter this new behavior, you will need to use an updated API client such as the Mirantis Container Runtime 23.0 CLI. You can refer to the official Docker API 1.42 documentation, as well as the Engine API version history to get a detailed understanding of the changes.

Seccomp filters

Seccomp filters are an essential security feature in Linux that helps restrict the system calls made by a particular process. This feature is particularly useful for reducing the attack surface of a container by limiting the number of syscalls it can make. Such a restriction helps to prevent malicious code from running inside the container, thereby making the entire system more secure.

By using Seccomp filters, system administrators can effectively reduce the risk of cyber-attacks, which have become increasingly common in recent times. The filters work by creating a whitelist of acceptable syscalls and blocking all other system calls that are not explicitly allowed. This approach ensures that only the desired processes are allowed to execute, thereby reducing the risk of exploitation.

In addition, Seccomp filters are beneficial for container-based applications, which are becoming increasingly popular in the cloud computing environment. Containers provide a lightweight and portable platform for running applications, which makes them ideal for cloud-based deployments. However, they also introduce additional security risks that need to be addressed. Check out the Linux Kernel archives page on Seccomp to learn more about it.

The latest version of the MCR has implemented a new feature that blocks v-socs by default. While this may be a positive security measure, it can also cause issues for existing workloads. If you are upgrading to MCR 23.0, you will need to manually configure your seccomp configuration to allow v-socs to run.

This change may cause unexpected interruptions to your workflow, as v-socs are often relied upon to perform essential tasks. It is crucial to take the necessary steps to unblock v-socs in order to avoid any potential downtime or data loss. To ensure a smooth transition to the new version of MCR, it is recommended that you thoroughly review the updated security measures and adjust your configurations accordingly.

Windows containers

Over the past few years, there has been a significant effort to create stable containers for Windows environments. Despite the challenges, there has been some great progress made in this area. Moby is currently the most mature implementation of Windows containers.

While Moby is the most established option for Windows containers, other projects are emerging as well. One of these is containerd, which is a lightweight container engine created for Kubernetes, and provides some support for Windows containers. However, it is still in the early stages of development and requires a lot of troubleshooting to get it to work properly.

This means that it may not be the best option for those who are new to containerization or who need a more stable, reliable solution. Overall, the work that has been put into creating stable containers for Windows environments has been impressive. While there are still some challenges to overcome, the progress made so far is a testament to the dedication and skill of the developers working on these projects.

Conclusion

In conclusion, Moby 23.0 brings exciting new features and improvements that make it even more flexible and powerful as a container-building tool. From CSI driver support to alternative OCI runtime support, and the use of BuildKit by default, Moby provides developers with the tools they need to build efficient and reliable containers quickly and easily.

While there are some gotchas to keep in mind when upgrading to MCR 23.0, the benefits of using this latest version of Moby are clear. With continued development and improvements, Moby is set to remain a popular choice for developers looking to build container tools that meet their specific needs.

For a complete overview of all the changes with Moby, check out the live stream by Mirantais where they go over all the changes with MCR and Moby.