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.
what can it do
check the uniqueness and validity of the VMM id, maximum length of 64 characters, alphanumeric only
assign NUMA node
check the existence of the exec_file
run the VMM as a specific user / group
assign cgroups
assign the VMM into a dedicated network namespace
a VMM can be damonized
what does it do
This part comes from the jailer documentation1. When the jailer starts, it goes through the following process:
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.
Firecracker1 is recently making rounds on the internet as this relatively new, awesome technology for running lightweight VMs.
As something coming from AWS and powering AWS Lambda, my original perception was that it’s not easy to set up and use. However, this write from Julia Evans2 proved me wrong. So, as I have recently picked up a used Dell R720 with decent amount of RAM and CPUs, it was time to take these two for a spin together.
This is a clarification to the previous write up about Keycloak Authorization Services1. The documentation of the response_mode documents the two values which can be used: decision and permissions. In the first Keycloak article2, I have wrongly assumed that no response_mode in the grant_type=urn:ietf:params:oauth:grant-type:uma-ticket call implies the value of permissions.