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.
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>.
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.
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.
This always gets me, npm publish fails to authenticate:
npm ERR! code E401 npm ERR! Unable to authenticate, need: Basic realm="Artifactory Realm" npm ERR! A complete log of this run can be found in: npm ERR! /Users/rad/.npm/_logs/...Z-debug.log The solution is:
Sign-in to JFrog.