Docker Images for IncludeOS | Hacker News Reader

Docker Images for IncludeOS

blog.includeos.org

46 pointsingve15 comments

for those of us who can't keep of track of which software named "xOS" is which anymore:

    IncludeOS is an includable, minimal unikernel operating system for C++ services running in the cloud. We provide a bootloader, standard libraries and the build- and deployment system. You just provide the service.

Yeah, there's sooo many of them. And I seem to recall another similarly named project from ten years ago or so too.

So, is it really a unikernel, or is it a linkable pid1?

It certainly looks like it is really a unikernel - it boots itself, is tested via qemu instead of chroots / docker (the images are for building IncludeOS), uses newlib and virtio, etc.

Please don't use preformatted syntax for quotes. Just dump the quote as-is, otherwise it's really hard to read, because it's all on one line. If you do wish to use preformatted syntax, wrap at 70 chars. Maybe less to keep it readable on mobile, too.

Unikernels are awesome. But it looks like these are docker images for building unikernels, not running the unikernel itself using docker tooling. Is it possible to do that? Or is the problem that docker inherits the host kernel and therefore you need to run the unikernel inside qemu inside docker? Is there any way to avoid this extra layer of virtualization so that you can run unikernels with docker tooling?

That would be pointless because a docker container is explicitly everything but the kernel. Just run the unikernel as a vm.

There are use cases where running a unikernel in isolated userspace can be advantageous. I'm building a multitenant routing and packet forwarding framework. The Linux kernel has matured to the point that it can handle routing logic efficiently, without the need for any application to listen for packets. Network namespaces further enable multitenancy of routing and packet forwarding. Of course, it would be nice to launch short-lived, stateless applications like L4-7 load balancers into those namespaces. I would like to use containers for this, because "boot" times are faster than any VM. However in a multitenant environment where security is critical, the greater attack surface of containers worries me. I want to mitigate the situation by running applications in unikernels to minimize the attack surface.

Or am I totally wrong in thinking containers are necessary here? Is the boot time of a VM limited by the kernel on the guest, or the hypervisor on the host? Do unikernels solve the slow boot problem of VM's entirely?

boot times are faster in containers because they don't boot. They're piggy-backing on the host's kernel.

> Is it possible to do that? Or is the problem that docker inherits the host kernel

Since containers are "merely" sandboxed processes there is no "host"† to speak of and no "inheritance": it's just exactly the current kernel that exec() a process in a highly segregated environment (from mount points to network stack). So obviously that's not possible.

† as opposed to "guest" in VM parlance

The intention is to use the Docker image as a developer SDK rather than downloading and installing the relevant SDKs locally.

For running unikernels -- that is a task left to the user. There is a plethora of information publicly available for working with hypervisors (eg: Hyper-V, Xen, etc), and, as mentioned by other commenters, Docker does not run unikernels.

You'd lose out on most of the awesome if you allowed unikernels to run without being kernels, no?

Docker is basically just a fancy chroot. In addition to changing the root directory, it changes the root pid, the set of network devices, the hostname, and a few other things, but at a conceptual level it's not doing anything fundamentally different from what chroot does to a process - it changes some pointers in the kernel's struct for the process. Instead of "root directory" being a global variable in the kernel, each process has a root directory pointer, and chroot changes that. Each process also now has a network-device-list pointer, a hostname pointer, etc., and Docker changes those too.

The flip side is that Docker (unless you're using boot2docker or something) isn't virtualization, so it is basically zero overhead. Running qemu inside Docker is as efficient as running it outside; it's not like nested virtualization or anything.

Another blog without a link to the homepage.

That's a tough one.

Here: http://www.includeos.org/

A demonstration of IncludeOS with Mender at Embedded Linux Conference Portland: https://www.youtube.com/watch?v=S_0D5Yh9czo

Reply on news.ycombinator.com