
Docker Images for IncludeOS - ingve
http://blog.includeos.org/2017/03/28/docker-containers-for-includeos
======
sdwisely
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.

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

~~~
geofft
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.

------
chatmasta
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?

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

~~~
chatmasta
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?

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

------
dorian-graph
Another blog without a link to the homepage.

~~~
mazeminder
That's a tough one.

Here: [http://www.includeos.org/](http://www.includeos.org/)

------
ralphmender
A demonstration of IncludeOS with Mender at Embedded Linux Conference
Portland:
[https://www.youtube.com/watch?v=S_0D5Yh9czo](https://www.youtube.com/watch?v=S_0D5Yh9czo)

