Daemonic Dispatches

The many ways to launch FreeBSD in EC2

Talking to FreeBSD users recently, I became aware that while I've created a lot of tools, I haven't done a very good job of explaining how, and more importantly when to use them. So for all of the EC2-curious FreeBSD users out there: Here are the many ways to launch and configure FreeBSD in EC2 — ranging from the simplest to the most complicated (but most powerful):

Launch FreeBSD and SSH in

This is the most straightforward way to get started with FreeBSD: Using either the EC2 API (most easily accessed via the awscli package) or the AWS Console, spin up a "stock FreeBSD" AMI. You have a few choices to make here:

1. Whether to use the Community or Marketplace AMIs.
2. Which EC2 Region you want to launch your instance into.
3. Which of many EC2 instance types you want to use.
4. How large you want the root disk to be (the root filesystem will be resized automatically if you select a size larger than the default 10 GB) and whether to attach additional disks.

For a "hobbyist" the easiest answers will probably be to use the Marketplace AMIs, in the EC2 region which is geographically closest to you, with a t2.micro and a single 10 GB disk (the default).

After you launch the instance, you can ssh in as the ec2-user user and then su to root (no password required). From this point on, setting up your EC2 instance is just like setting up a physical server.

Launch FreeBSD and provide user-data

But what if you want a more automated process — something which will yield a consistent configuration, without the time-consuming process of SSHing in to set things up? Enter configinit.

When you launch an EC2 instance, you have the option of providing it with some "user-data". On FreeBSD, this is processed by configinit, which is a tool I wrote for configuring FreeBSD systems. For example, you can pass user-data of

>>/etc/rc.conf
firstboot_pkgs_list="apache24"
apache24_enable="YES"

to have FreeBSD install the apache24 package when it first boots and enable the Apache daemon. For more complex configurations you can provide a tarball containing files with directives to append to or replace multiple configuration files; to launch Portsnap mirrors, I have a configinit file which adds lines to rc.conf and newsyslog.conf, creates lighttpd.conf, runs a script to start synchronizing with the portsnap master server, etc.

Use the AMI Builder to create a customized FreeBSD AMI

Maybe rather than having commands run when FreeBSD first boots, you'd prefer to set things up ahead of time. Enter the FreeBSD AMI Builder.

This is an AMI which boots into a memory disk and installs FreeBSD onto the root disk — and then lets you make further changes before you create a new AMI from it. Long time EC2 users may recall that in the early days of EC2 — when everything was Ubuntu — the normal way to create a new AMI was to boot up an instance, make changes, and then package it up; this follows the same idea, but because the AMI Builder boots into a memory disk it avoids "contaminating" the image you're creating with keys and log files.

To make the process of building new AMIs even easier, the AMI Builder can make use of IAM Roles and runs configinit; so you can repeatably create customized FreeBSD AMIs in a matter of minutes with a single command.

I have built FreeBSD AMI Builder images in the us-east-1 region; the currently supported releases are FreeBSD 11.2 (ami-000414bbf0ee227c5) and FreeBSD 12.0 (ami-09baac3ede1d33201).

Build a FreeBSD AMI from a modified FreeBSD source tree

The options above all give you a FreeBSD RELEASE — possibly customized by installing extra packages and editing configuration files, but (unless you launch the AMI Builder and then buildworld/buildkernel inside there) you'll be running the binaries shipped by the FreeBSD Project. What if you have changes to FreeBSD itself — say, if there's a bug which was fixed after the release which you need to backport the fix for, or you need a custom kernel configuration? Enter make ec2ami.

This is in fact the exact mechanism used by the FreeBSD release engineering team to produce official FreeBSD AMIs — of course, they have the AWS keys needed to publish images into the official FreeBSD Release Engineering AWS account, but anyone with an AWS account can follow the same process using their own keys. Just run a buildworld/buildkernel of your modified FreeBSD, set up a few parameters (AWS keys, AWS region, and an S3 bucket to be used for staging the upload), and cd /usr/src/release && make ec2ami.

Build your own disk image

Finally, some people will want to build AMIs which are even more customized than you can easily do via the FreeBSD release code. Maybe you want to have a system which boots into a memory disk, so that it will keep working even if its EBS volume dies. Maybe you want to boot from NFS, making use of Amazon's Elastic File System (aka. NFS-as-a-service). Maybe you want to build an AMI for a completely different OS. For this, there's bsdec2-image-upload.

As the name suggests, that tool simply uploads a disk image and bakes it into an EC2 AMI. If you're going this route, everything else is up to you... but if you need to go this route, you're doing something sufficiently obscure that you almost certainly need to do everything yourself anyway.

---

I hope I've provided tools which help you to run FreeBSD in EC2, no matter how common or unusual your needs are. If you find my work useful, please consider supporting my work in this area; while this is both something I enjoy working on and something which is useful for my day job (Tarsnap, my online backup service), having support would make it easier for me to prioritize FreeBSD/EC2 issues over other projects.