The containerd maintainers (including me) are happy to announce the release of containerd 2.0! This is the first major release of containerd since 1.0 was released in 2017, and represents a commitment both to the evolution of the containerd project and continued investment in stability, reliability, and efficiency.
containerd 2.0 will be the first new major release of containerd since the initial stable release of 1.0 in December, 2017. After six years of iteration, development, and refinement, 2.0 will encapsulate the learning we’ve had building and supporting containerd at large scale (and as the default container runtime for a number of managed container offerings). With that, 2.0 brings some major refactorings of core services (CRI, image management), new functionality (sandbox plugins, transfer plugins, image verifier plugins), improvements (better user namespace support, NRI updates), and removals of deprecated functionality.
I’ll be speaking at KubeCon+CloudNativeCon EU 2023 in Amsterdam next week. I’d love it if you came to see me! I tried this before with SCALE 18x and shared my expected schedule, and I want to try sharing it again! If you feel like you want to join me or meet up during the conference, please reach out and let me know.
It’s been a bit since I’ve written on this blog about anything other than containers, but I’ve been reading a lot of new (to me) Go code lately and wanted to discuss unit testing. I’m pretty firmly in the camp that testing is critical for building reliable, maintainable systems, and unit testing is an important component of that (though I do not believe it is sufficient on its own; integration, functional, or end-to-end testing is also often just as important). Unit testing is a somewhat special form of testing though, since the goal is to test the smallest functional unit of a system. One tool used as a part of unit testing that has been popular for as long as I’ve been employed as a software engineer is that of a test double.
One of the really nice things about Docker containers is that the defaults mostly just work. One of those defaults is networking; docker run gives you a perfectly serviceable network experience with containers able to access the Internet, access each other, and expose services. runj is a much lower-level tool than Docker, so that sort of out-of-the-box network experience wouldn’t be something runj would directly provide. However, I recently added support to runj for some of the pieces that make a networking experience like that possible. Higher-level tools that use runj, like nerdctl, might use these pieces in the future.
One of the core use-cases for modern container systems is to run networked workloads, often across a group of machines deployed in a cluster. A variety of different networking models exist, but until now no networking at all was possible with runj. Now, after this change, runj has its first networking capability! The functionality that pull request enable jails to share the IPv4 network stack with the underlying FreeBSD host, similar to the “host networking” model common for Linux containers.
In March, I open-sourced runj, an experimental OCI-compatible runtime for FreeBSD jails. I started runj in order to teach myself more about FreeBSD in general and jails in particular, and the initial contribution policy I set was designed to give me the space to learn at my own pace. However, as I wrote in that first blog post, the amount of attention runj received on its first day really surprised me. The attention since then has continued, and I’ve had the opportunity to connect with members of the FreeBSD community who have shared my excitement about connecting FreeBSD with the broader container ecosystem. Everyone I’ve spoken with has been incredibly kind and respectful of the space I requested, which did give me the opportunity to learn on my own. I really appreciate their kindness, and now that I’ve achieved the first part of my learning goal I’m ready to move forward and work together rather than working alone.
This past September, I joined the containerd project as a security advisor. In March, I increased my involvement as a reviewer. And this week, I joined the Moby project as a maintainer. My colleague Kazuyoshi Kato wrote about joining containerd on his blog and I’ve been wanting to do that too.
containerd 1.5.0 was released today and now works on a new operating system: FreeBSD! This new release includes a series of patches (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) which allow containerd to build, enable the native and zfs snapshotters, and use a compatible runtime like runj. I’m really excited about this! It’s awesome that only a small amount of work was needed to make containerd compatible with FreeBSD and that so much of it worked straight out of the box. And with a runtime for jails, containerd’s powerful APIs can now be used to manage FreeBSD’s native process isolation capability. In the rest of the post, we can take a look at how to use containerd on FreeBSD!
Today, I open-sourced runj, a new experimental, proof-of-concept OCI-compatible runtime for FreeBSD jails. For the past 6.5 years I’ve been working on Linux containers, but never really had much experience with FreeBSD jails. runj (pronounced “run jay”) is a vehicle for me to learn more about FreeBSD in general and jails in particular. With my position on the Technical Oversight Board of the Open Containers Initiative, I’m also interested in understanding how the OCI runtime specification can be adapted to other operating systems like FreeBSD.