This article describes the prerequisites to the Introducing firebuild.
Firecracker works only on Linux. You can use this program to install and link the binaries on your system.
The tc-redirect-tap CNI plugin (mentioned below) requires golang to build, as does firebuild. firebuild requires golang 1.16+ so install it:
There is so much software out there packaged as Docker images. Operating systems, SQL and NoSQL databases, reverse proxies, compilers, everything. Safe to say, most of that software available as Docker containers is built from the common file format - the Dockerfile. Dockerfiles are awesome. They are recipes for getting a bit of software functional.
A Firecracker release comes with two binaries - the firecracker and the jailer programs. The jailer brings even more isolation options to Firecracker by creating and securing a unique execution environment for each VMM.
id, maximum length of 64 characters, alphanumeric onlyexec_filecgroupsThis part comes from the jailer documentation1. When the jailer starts, it goes through the following process:
Last night’s problem with the second VMM conflicting on the network layer with the first one was indeed the veth0 name hard coded in firectl. I’ve added the --veth-iface-name argument to firectl and I am now able to start multiple VMMs on a single bridge.
Today I have looked at creating my own bridge networks for Firecracker VMMs. I already used CNI setups when evaluating the HashiCorp Nomad firecracker task driver1. Back then I incorrectly stated that Firecracker depends on certain CNI plugins. It doesn’t, it can take advantage of any CNI setup as long as the tc-redirect-tap is in the chained plugins.
Towards the end of the Firecracker VMM with additional disks article1 I concluded that I didn’t know how to live resize an attached drive. It turns out it is possible and it’s very easy to do using the Firecracker VMM API.
To launch the VMM with the API, I have to drop the --no-api argument (obviously) and use --api-sock with the path to the socket file. In a production system, I’d use a directory other than /tmp.
Before looking at the networking options, I have looked at adding extra drives to my Firecracker VMMs. Storing data on the root file system will not scale well long term. Additional disks will be a good solution to persist application specific data across reboots and upgrades.
The quest to launch an ETCD cluster on Firecracker starts here.
In this post, I’m describing how I’ve built my initial Alpine 3.13 VMM with OpenSSH and a dedicated sudoer user. In AWS, when one launches a Ubuntu instance, one can access it via ssh ubuntu@<address>, a CentOS VM is ssh centos@<address>. At the end of this write up, I’ll have ssh alpine@<address>. This VMM will have access to the outside world so I can install additional software and even ping the BBC! For the networking, I’ll use the Docker docker0 bridge; inspired again by Julia Evans, the Day 41: Trying to understand what a bridge is1 was very helpful. I will look at my own networking setup in future write ups.
So I’ve been on the fence with the vendor directory.
On one hand, it’s great to have the modules in the project because it speeds up the build and serves as a safe storage.
On the other hand, it does increase the churn in the repository and creates a lot of duplication on disk because many projects often contain the same dependencies.
It’s good to know how to set up Firecracker VM by hand but that’s definitely suboptimal long term. So today I am looking at setting up Firecracker with CNI plugins. Firecracker needs four CNI plugins to operate: ptp, firewall, host-local and tc-redirect-tap. First three come from the CNI plugins1 repository, the last one comes from AWS Labs tc-redirect-tap2 repository.