Presenting FreeBSD! How We Made It Happen.

We’re happy to announce that FreeBSD is now available for use on DigitalOcean!

FreeBSD will be the first non-Linux distribution available for use on our platform. It’s been widely requested because of its reputation of being a stable and performant OS. While similar to other open source unix-like operating systems, it’s unique in that the development of both its kernel and user space utilities are managed by the same core team, ensuring consistent development standards across the project. FreeBSD also offers a simple, yet powerful package management system that allows you to compile and install third-party software for your system with ease.

One particularly compelling attribute of the FreeBSD project is the quality of their documentation, including the FreeBSD Handbook which provides a comprehensive and thoughtful overview of the operating system. We at DigitalOcean love effective and concise technical writing, and so we’ve also produced numerous FreeBSD tutorials to aid new users with Getting Started with FreeBSD.

We understand that this has been a long standing user request, and we’ve heard you. You might be asking yourself - what took so long?

The internal structure of DigitalOcean’s engineering team has rapidly changed over time due to the dynamic growth of the company. What began as a couple of guys coding furiously in a room in Brooklyn has ballooned to a 100+ person organization serving hundreds of thousands of users around the globe. As we’ve grown, by necessity we’ve needed to adjust and reorganize ourselves and our systems to be able to better serve our users. There have been many experiments in how we approach, prioritize and execute this work; this image is a result of the successful alignment of a few key elements.

Last year, we built our metadata service — allowing a droplet to have access to information about itself at the time that it’s being created. This is a powerful thing because it gives a vanilla image a mechanism to configure itself independently. This service was a big part what allowed us to offer CoreOS, and in building it, it gave us more flexibility in what we could offer moving forward. Our backend code would no longer need to know the contents of the image to be able to serve it. On creation, the droplet itself could query for configurables — hostnames, ssh keys, and the like — and configure itself instead of relying on a third party.

This fundamental decoupling is an echo of a familiar refrain: build well defined interfaces and don’t let knowledge leak across those boundaries unnecessarily. It’s allowed us to free images from customization by our backend code, and entirely sidestep the problematic issue of modifying a UFS filesystem from a Linux host.

Since we now had a feasible mechanism to allow images to be instantiated independently of our backend, we just needed to put the parts together that would allow us to inject the configuration upon creation. FreeBSD doesn’t itself offer cloud versions of the OS similar to what Canonical and Red Hat provide, so we started from a publicly available port of cloud-init meant to allow FreeBSD to run on OpenStack.

In order to query metadata, we need to have an initial network configuration in order to build our configuration, since DigitalOcean’s droplets use static networking. During boot time, we bring up the droplet on a v4 link-local address in order to do the initial query to the service. From there, we pick up the real network config, hostname, and ssh keys. The cloud-init project then writes a configuration that’s associated with the droplet’s ID. Linking this configuration to the droplet ID is the mechanism that allows it to know whether the image is being created from a snapshot or new create, or is just a rebooted instance of an already configured droplet.

Once this configuration has been injected, FreeBSD’s boot process can continue and use it accordingly — eventually booting into the instance as expected.

This endeavor began life as an experiment in how we organize ourselves in the engineering team. We were given a few weeks to pick a project, self organize in cross-functional teams, and execute. A lot went right during this process that allowed this project to succeed.

Deadlines are powerful things. Not in a punitive or negative sense of the word, but in a sense that there will be a well defined time where work on this will collectively end. So is having a very clear picture of what “done” looks like. In the case of BSD, it was particularly powerful to have a clear goal of a alpha functional BSD droplet with a date to drive for. Given the freedom to focus on a single goal, clear communication, and well defined restraints, we were able to finally deliver a long standing user request with relative ease.

This is the start to the many things we’re excited to build in 2015!

By: Neal Shrader