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.
A friend today asked me whether I thought that the license for his software project (GPLv3) was potentially keeping people from adopting it. The short answer is is yes, but I figured I could expand on that a bit. And before I get too far: I am not a lawyer, I am not your lawyer, this is not legal advice, please seek competent counsel in your jurisdiction for advice. Instead, I want to talk a bit about why different licenses exist and what they mean.
Recently, I’ve been spending a fair amount of time looking at the OCI runtime specification and at the reference implementation, runc. I tend to learn best by doing, and the low-level bits of how containers work have interested me for a long while now, so I’ve started writing a new non-production OCI runtime to learn more about it. In the OCI spec, the docker run interface that folks familiar with Docker containers use has been broken up into multiple steps: create and start. But what’s interesting about runc’s implementation here is that the standard input/output streams (which I tend to refer to as STDIO) for the container’s main process are hooked up to the STDIO streams of runc create rather than that of runc start. This means that if you run runc create in one terminal, and then run runc start in a second terminal, the input and output of your container will be hooked up to the first terminal rather than the second! I’m not entirely clear on the history of why runc behaves this way, but I think the how is interesting on its own. And that how is through multiple processes synchronizing via a FIFO.
LinuxFest Northwest (LFNW) is a local community conference about Linux put on every year by the Bellingham Linux Users Group and Bellingham Technical College. I spoke at LFNW last year, and had a proposal accepted again to speak this year. Unfortunately, COVID-19 threw a wrench in it, and the conference had to be canceled due to health concerns. The conference moved to an online conference made up of pre-recorded sessions (webinar-style), with an online discussion board. I recorded one of my sessions. This post is here to document what I did, as a first-time online presenter who primarily uses Linux.
Note: This post was originally published on the AWS Containers Blog. On March 10, 2020, we introduced Bottlerocket, a new special-purpose operating system designed for hosting Linux containers. In this post, I want to take you through some of the goals we started with, engineering choices we made along the way, and our vision for how the OS will continue to evolve in the future.
In the welcome post of this blog, one of the things I said I wanted to write was a description of how this blog was built. I didn’t want to do that at the very beginning, as it would be weird for a brand-new blog to only have such meta-content. But the blog has been around for a year now, and I was prompted by something I saw on the Internet: @hillelogram Have you considered writing your own static site generator?