init-snapshot VS bocker

At CodeSandbox we use Firecracker to run our VMs (more info here: https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s...).

To answer the questions:

> what version of the kernel do you use (the github page says 5.10 but isn't that quite old?)

Right, they have tested with 5.10, but it also works with higher kernel versions. Our host currently runs 5.19 and we're planning to upgrade to 6.1 soon. The guest runs 5.15.63, we use a config very similar to the recommended config by FC team (it's in the FC repo). It's important to mention that we had to disable async pagefaulting (a KVM feature) with more modern kernel versions, as VMs could get stuck waiting for an PF resolve.

> What do you use to build the 'micro' images

We created a CLI that creates a rootfs from a Docker image. It pulls the image, creates a container and then extracts the fs from it to an ext4 disk. For the init, we forked the open sourced init from the Fly team (https://github.com/superfly/init-snapshot) and changed/added some functionality.

> How do you keep timesync of you're not using a timesync daemon?

IIRC we expose the time as a PTP device (handled by kvm) and run phc2sys to sync the time in an interval. Firecracker has some documentation on this, where it recommends chrony. It can also be done with vsock, but it would be more manual.

> Handle kernel and app logs without adding an log daemon, and same through vsocks, etc?

The init forwards stdout/stderr of the command it runs to its own stdout, which Firecracker then logs out by itself. A supervisor reads these and writes the logs to files.

Unless they’ve changed things, there is no containerization within the VM a la kata. They run their own custom init inside the VM and use it to start the entry point. https://github.com/superfly/init-snapshot is the source.

Jerome wrote our init in Rust, and, after being cajoled by Josh Triplett, [we released the code (https://github.com/superfly/init-snapshot), which you can go read.

When I did a talk about docker I also wanted to show a bit of what it does under the hood without going through all the layers and without too much details. This ~120 lines of shell script is really good in providing just an intro into what's needed for containers: https://github.com/p8952/bocker/blob/master/bocker

i tried it and like the concnpt, but until it can be launched via a systemd userspace service (without previously manually booting it) among other problems i will keep using docker (or bocker)

Bocker is in this same category...docker clone in bash that's helpful in seeing what's really happening underneath with nsenter, namespaces, network bridging, cgroups, etc.

https://github.com/p8952/bocker

Docker implemented in around 100 lines of bash: https://github.com/p8952/bocker

This is the most mindblowing example for enterprise security teams that think Docker is a new threat on a single tenant Linux host.

No, buddies, all this stuff is already there. If you were fine with your visibility before*, you're still fine. Go find a real problem while we play with our developer dopamine.

* NARRATOR: They shouldn't have been.

Bocker[1] does a reasonably good job of showing the value of Docker was mostly in Docker hub.

[1] https://github.com/p8952/bocker

Surprised no one has mentioned Bocker yet – “Docker implemented in around 100 lines of bash”. [1, 2]

[1]: https://github.com/p8952/bocker/

[2]: https://news.ycombinator.com/item?id=33218094

I was part of this, it was a fun project. I have a final pull request that never made it though, and that's too bad as it addressed some hardcoding issues and added a few helpful commands: https://github.com/p8952/bocker/pull/23

Revisiting the project, it looks like more people tried submitting PRs for the following couple years. Funny, for a project that was definitely an exercise in "do X in 100 lines of code"