firecracker-go-sdk
firectl
firecracker-go-sdk | firectl | |
---|---|---|
1 | 1 | |
456 | 457 | |
1.3% | 2.4% | |
7.4 | 1.8 | |
15 days ago | 9 days ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
firecracker-go-sdk
firectl
-
Deploying Firecracker VMs
, "should represent the path to a file that contains a JSON which stores the entire configuration for all of the microVM's resources" (okay this is fair enough). Also, they stipulate, "**The JSON must contain the configuration for the guest kernel and rootfs, as these are mandatory, but all of the other resources are optional, so it's your choice if you want to configure them or not. Because using this configuration method will also start the microVM, you need to specify all desired pre-boot configurable resources in that JSON.**" **File Names for the Pre-Boot Resources** (included within the greater repo here): 1. **firecracker.yaml** - Names of resources are contained here ; 'file nad the names of their fields are the same that are used in API requests' (cool) 2. **tests/framework/vm_config.json** (boilerplate config file to guide us - great) > *"After the machine is booted, you can still use the socket to send API requests for post-boot operations."* (this honestly feels clunky as a mf) ### Conclusion Somewhat of a pain in the ass (just looking through the directions); the fact that we'd have to go grab a uncompressed kernel image + file system image (ext4) is kind of a fucking hassle / burden. Was hoping for a solution more akin to Docker where it can just be spun up real quick & then deployed. But they claim that this 'jailer' feature (that they keep hyping) will **ensure** (I guess?) that whatever is done within the container will remain within the container (and not escape). I haven't seen anything that sticks out about this project that leads me to believe that it possesses that capability, but I definitely don't want to rule it out. ### Extra Documentation + Information 1. **OSv Running on 'Firecracker'** (yay more work though) - http://blog.osv.io/blog/2019/04/19/making-OSv-run-on-firecraker/ 2. **Building OSv Images Using Docker** - http://blog.osv.io/blog/2015/04/27/docker/ 3. **firecracker containerd** (this is something that's probably important for the overall mission of what we want to accomplish here) - https://github.com/firecracker-microvm/firecracker-containerd ### Firecracker Containerd **Description** - "*firecracker-containerd enables containerd to manage containers as Firecracker microVMs*" - "This repository enables the use of a container runtime, containerd, to manage Firecracker microVMs. Like traditional containers, Firecracker microVMs offer fast start-up and shut-down and minimal overhead. Unlike traditional containers, however, they can provide an additional layer of isolation via the KVM hypervisor." **They Also Identify Potential Use-Cases in the Repo Such as** 1. "*Sandbox a partially or fully untrusted third party container in its own microVM. This would reduce the likelihood of leaking secrets via the third party container, for example.*" 2. "*Bin-pack disparate container workloads on the same host, while maintaining a high level of isolation between containers. Because the overhead of Firecracker is low, the achievable container density per host should be comparable to running containers using kernel-based container runtimes, without the isolation compromise of such solutions. Multi-tenant hosts would particularly benefit from this use case.*" Really interesting feature of this repo here is: "*A root file filesystem image builder that constructs a firecracker microVM root filesystem containing runc and the firecracker-containerd agent.*" (that could save a lot of time on that whole filesystem image thing that they were mentioning prior) **Additional Links of Importance** 1. **Getting Started Guide** - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/docs/getting-started.md 2. **Quickstart Guide** - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/docs/quickstart.md 3. **A Root Filesystem Image Builder** - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/tools/image-builder 4. **Runtime Linking Containerd** - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/runtime **Documentation All Located Here** - https://github.com/firecracker-microvm/firecracker-containerd/tree/main/docs (definitely fucking needed because there's a lot here to wrap one's head around) - **Design Approaches Doc** - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/docs/design-approaches.md - **Shim Architecture** - https://github.com/firecracker-microvm/firecracker-containerd/blob/main/docs/shim-design.md - **Launching 4k VMs Using Firecracker** - https://github.com/firecracker-microvm/firecracker-demo - **firectl** (CLI options for manipulating this tool from terminal ; this is important as well) - https://github.com/firecracker-microvm/firectl [damn, there's a lot that came with this here!]
What are some alternatives?
undocker
linux-hardened - Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening
actuated - Blazingly fast CI runners
firecracker-demo - A demo running 4000 Firecracker microVMs.
firecracker - Secure and fast microVMs for serverless computing.
Zappa - Serverless Python
cloud-hypervisor - A Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.
firebuild - Convenience of containers, security of virtual machines
QEMU - Official QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are ignored. Please only use release tarballs from the QEMU website.
containers-roadmap - This is the public roadmap for AWS container services (ECS, ECR, Fargate, and EKS).