-
-
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.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
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.
-
-
containers-roadmap
This is the public roadmap for AWS container services (ECS, ECR, Fargate, and EKS).
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
Firecracker keeps a bitmap of which pages have been dirtied (it's a flag you can turn on), so you can make incremental snapshots of only the changed pages (more here: https://github.com/firecracker-microvm/firecracker/blob/main...).
In our case we changed Firecracker to use a shared mmap instead of an private mmap, so in our case the dirtied pages were synced back automatically to the backing memory file. The main reason for this was to reduce IO on snapshot time. I'm also looking at other ways we can do this, because using a shared mmap fragments the underlying xfs fs pretty fast. Maybe we can batch writes more instead of writing single pages.
When QEMU saves a snapshot, it tries to be "smart" about memory, only saving the memory in use[1]. This trades off CPU at snapshot time for I/O at transfer time. How compatible is Firecracker's virtual memory subsystem with doing something like that?
[1] https://github.com/qemu/qemu/blob/7dd9d7e0bd29abf590d1ac235c...
Regarding turning Dockerfiles into a MicroVM: https://gruchalski.com/posts/2021-03-23-introducing-firebuil..., on GitHub: https://github.com/combust-labs/firebuild. This could get you started.
Disclaimer: Iām the author.
- you can then get a list of the tarballs in this image by extracting this tarball and reading the file `manifest.json`; `Config` -> `Layers` will give you a list of tarballs (see undocker for how to do this: https://github.com/larsks/undocker)
Did you guys think about live migrations? https://github.com/cloud-hypervisor/cloud-hypervisor seems to support it and it shares a good amount of code with firecracker.
I use Zappa, it just schedules a frequent execution of the lambda: https://github.com/zappa/Zappa#keeping-the-server-warm
This is still a thing, Fargate pull times are super slow: https://github.com/aws/containers-roadmap/issues/696. We run all of our workloads on fargate, and it's really annoying when you're trying to iterate on something and you have to sit there waiting on "Provisioning..." for 1-2 minutes every time you launch a task. I don't think the control plane is that slow, as EC2 based ECS launches tasks really fast if the images are already cached on the machine.
This is really cool. I've also been working with Firecracker, but for isolated CI runners with Docker and KinD/K3s support. Starting with GitHub Actions [1] I've also had interest in making OpenFaaS use pause/resume from Gatsby.js who wanted to reduce their hosting costs. The main challenges were around the networking - if you use CNI and the Go SDK [2] then restores simply don't work. Not sure if you're working with netlink and IMAP directly to get around it?
My question is how are you guaranteeing uniqueness, or do you only clone snapshots for a single tenant? [3]
[1] https://github.com/self-actuated/actuated