A unikernel built by unikraft can run in a quem vm directly. I want to know if a unikernel can run in a docker container directly? I know in 2016 a unikernel company was purchased by Docker company. If not ,whtat 's the main obtacles? Thank you.
Hey, one of the people behind Unikraft here. I’m trying to understand the use case, why would you want to run a unikernel within a container? What we tend to do is use a Dockerfile to specify the root filesystem/files you’d like to have in the unikernel, and then have Unikraft turn that into a (very slim) unikernel that runs your code/application (ie, no container at deploy time). This workflow became available with a very recent release (Kraftfile Reference (v0.6) - Unikraft) . That way you get all the power of Docker but then when you go to deploy things are as efficient as possible.
By the way, that company in 2016 was Unikernel Systems.
Nice to know you are the just people. I read the Kraftfile reference which guides people to configure, build, package and deploy an application as a unkernel. Great progress.
Since an unikernel is run in a single address space, it is necessary and expensive to construct a vm per unikernel. If an unikernel can run in a container, it is much cheaper while the os in the container can be greatly reduced due to the concept of unikernel.
Now that a unikernel consist of the targeted app and its necessary libraries, it is self contained and it can run in a container given cpu and memory.
As I am not familar with container nor unikernel, I am not sure if it is possible to run an unikernel in a container and if not what is the obstacle?
Thank you. regards, qsmeng
Hi, probably it makes sense to describe the layers a bit. For most cloud deployments, at the very bottom is a hypersor providing strong isolation (e.g., KVM, Xen, Hyper-V, etc.). Taking KVM as an example you then have the host (Linux) running the VMM (virtual machine monitor, eg, QEMU or Firecracker) and then on top of that come the actual virtual machines.
If you’re running a container in the cloud more likely than not that container is being run within a VM for security/isolation purposes. So you basically have hypervisor <> host/VMM <> VM/kernel <> VM user space <> container <> application.
Ideally what you’d want is your application running as close as possible to the hardware while still being isolated, basically something like having the application running on top of the hypervisor. With Unikraft we’ aim to get as close to that as possible by having hypervisor <> VMM <> unikernel (which has the app in it)
While the unikernel itself can run multiple apps in it, each unikernel can be quite small (eg, an NGINX Unikraft unikernel is 1.25MBs on disk), so running multiple ones and inter-connecting them isn’t a problem (in a stress tests we ran up to 90K of these on a single server).
So for building and local testing/deployment containers are great and our native tool leverages Docker files, we’re doing a docker compose integration, etc. For actual deployment we don’t put a container in the image as we feel that’s just pure overhead.
Hope this clarifies things.
Hi， I see the key idea that the closer an app is to hardware the better. By putting unikernel ontop vmm, not vm, do you mean vmm just provide cpu and memory, but not guest os?
“While the unikernel itself can run multiple apps in it”, I know occlum is of this type, but occlum must provide isolation between app using Intel hardware feature MPK.
In some hardware occasion, like AMD SEV, there are only 16 SEV VMs and no MPK, unkernel running in container will make sense?
thank you. regards
By putting unikernel ontop vmm, not vm, do you mean vmm just provide cpu and memory, but not guest os?
A unikernel is a VM, and the VMM (eg, QEMU, Firecracker), running in user-space (eg, in Linux, on the host), is used to launch it/manage it.
Occlum, like Unikraft, is a library OS. Unikernels typically leverage, and are built from, library OSes because that allows the build to pick and choose the right libs for each app at compile time, resulting in the high level of specialization that unikernels target. However, a unikernel, by most definitions, is a specialized virtual machine, which isn’t the use case Occlum is going after. Having said that, there have been multiple OSS projects in Unikraft targeting security, (eg, enclaves, MPK, etc) and Unikraft is also used for automotive virtualization.
unikernel running in container will make sense?
But what would the container here gain you? In an enclave, the reason a unikernel is attractive is that it’d have minimal code, so in principle much easier to check for bugs and certify. The container would require a container runtime environment, more code, and what would it provide as benefit?
Using occlum libos, many apps can run in an enclave isolatedly.
By “While the unikernel itself can run multiple apps in it”, do the mutiple app run also in an isolated way？
In Enclavisor paper, enclavisor as the guest os in a SEV is in charge of constructing enclave and running an app in the enclave. I expect good isolation can be acquired if an app can run in a container in the unikernel way. That is a cotainer equals to an enclave.
Hi Felipe, happy festival.
the following is from Container Runtimes - Unikraft,
“You can run Unikraft unikernels packaged by KraftKit through any OCI compliant container manager using
runu as a drop-in replacement for the
runc container runtime, thus enabling the usage of unikernels with familiar container tools and platforms such as Docker and Kubernetes.”
This is what I want.