hyperkit VS runj

The author uses a Mac and uses Docker Desktop or colima x Docker CLI to realize a Docker development environment. Dcoker Desktop uses an internal HyperKit (macOS hypervisor) to launch a Linux VM and run dockerd in it. Docker Desktop is based on Lima, and it generates Lima configuration files, and it is used to run Linux.

Sorry, I was misinformed. It seems MacOS still does use a tool called hyperkit to run a (presumably linux) VM as a backend for docker. I thought it was using something similar to jails.

You might try using HyperKit as the hypervisor with Kubernetes. It uses Apple's own hypervisor. Minikube, or rather docker, supports it. I would go with minicube as you can start and stop it as needed with ease.

I've been reading many forum posts: moby/hyperkit#149 docker/for-mac#900

What’s the magic behind docker working on macOS?. The answer is virtualization accomplished by the moby/hyperkit hypervisor (AFAIK), a toolkit for embedding hypervisor capabilities in your application, which means that dockerd works in a VM virtualized by the hyperkit. Why I’m telling you this is once you decide to work with containerd on your macOS environment to discover capabilities and more adapt to it because we assume you use containerd in your Kubernetes environment as a default container runtime, you had to have the same virtualization technology under the hood to let containerd working on macOS. Also, you need to have some client tooling to interact with containerd by keeping simplicity and usability in mind.

Docker on Mac is based on Hyperkit which is a lightweight VM. https://github.com/moby/hyperkit Crostini is running in a full KVM instance. You challenged me about the Termina shell. Type it in and see if I'm right. No need to debate this anymore when you can verify for yourself.

Docker Desktop doesn't use virtualbox behind the scenes. It uses hyperkit.

a couple projects underway for containers, still wip but promising.

https://hackmd.io/7BIT_khIRQyPAe4EdiigHg

https://github.com/samuelkarp/runj

> it's a shame that docker is built around linux

There is some interesting work happening to get an OCI-compatible runtime working

https://github.com/samuelkarp/runj

So somebody else created runj (runj is an experimental, proof-of-concept OCI-compatible runtime for FreeBSD jails.) https://github.com/samuelkarp/runj

Shout out to https://github.com/samuelkarp/runj which aims to provide OCI compatible runtime for FreeBSD jails. We are working on a Jails based sandbox implementation for running OCaml builds on FreeBSD, https://github.com/ocurrent/obuilder. If runj gets more support then it would be a good alternative to the various iocage/ezjail/etc solutions or the raw Jails implementation we have right now.

If you want to get a little more bleeding edge, follow along with samuelkarp/runj project which attempts to get docker images running via runj/containerd

containerd only runs on FreeBSD with the help of a shim to use [runj](https://github.com/samuelkarp/runj) as a backend for running the actual jails containers.

> VM's disk is a zfs filesystem on the host, it makes snapshotting (edit- ok maybe not, see below) and managing it super easy!

I think you mean that it's a ZFS volume? Although it should be possible to export a filesystem to a guest over NFS (or I guess 9p), but I haven't run into a lot of discussion or gotten around to testing it myself...

> It would be really cool if there were tools that brought them in line with docker, in terms of easy deployment and provisioning of new jails/vms. If I didn't have so many damn project ideas already...

My dream would be to see https://github.com/samuelkarp/runj polished and docker+containerd+runj made to work as the way to run the docker frontend with jails as the backend.

https://github.com/samuelkarp/runj is a proof of concept.

Pull up your sleeves and start committing

Experimental FreeBSD on FreeBSD OCI containers with runj