Unikernels are a growing technology that augment existing virtual machine and container deployments with compact, single-purpose appliances. Two main flavors exist: clean-slate unikernels, which are often language specific, such as MirageOS (OCaml) and HaLVM (Haskell), and more evolutionary unikernels that leverage existing OS technology recreated in library form, notably Rump Kernel used to build Rumprun unikernels. To date, these have been something of a specialist’s game: promising technology that requires considerable effort and expertise to actually deploy. After a brief introduction for newcomers to unikernels, Mindy will demonstrate the great strides that have been taken recently to integrate unikernels with existing deployments. Specifically, we will show various ways in which Rumprun and MirageOS unikernels can be used to deploy a LAMP stack, all managed using the popular Docker toolchain (Docker build, Docker run, and the Docker Hub). The result is unikernels that can be used to augment and evolve existing Linux container- and VM-based deployments, one microservice at a time. We no longer need a revolution—welcome to the microservice evolution!

1. Unikernels and Docker: from
Revolution to Evolution
Mindy Preston

2. Mindy Preston
Member of Technical Staff at Docker, tweets @mindypreston
2

3. A maintainer of
• the MirageOS unikernel
• VPNKit, part of Docker4Mac and Docker4Windows
3

4. 4

5. Some Definitions
• "docker": you're all probably pretty solid on this :)
• "unikernels": artifacts representing a set of software which runs in a
single address space, with no distinction between kernel and userspace
code.
• "library operating system": a build system which can link a group of
libraries representing traditional OS functions with an application to
produce a unikernel.
5

6. Artifact
6

7. "nobody cares about containers unikernels"
• something which allows the execution of general application code
• something easily described completely (you can enumerate the things it
needs)
• something low-overhead (small in terms of binary size, cpu/mem, or
some othe resource consumption)
7

8. Artifact is Code
application code (= source)
(intepreter & dependencies) + external app dependencies
OS + shared libraries
computer
• a very nice way to get runtime errors
8

9. Artifact is Instructions
application code |> compiler & dependencies |> binary
OS + shared libraries
computer
• shared libraries are an opportunity for chaos
• few guarantees on build environment
9

10. Artifact is Instructions + (some)
environment
app code + shared libs |> compiler + deps |> static binary
OS
computer
• resource consumption cost
• build environment is still not necessarily reproducible
10

11. Artifact is Code + Build Spec
app code + base img + deps + config |> container builder |> image
container runner
OS
computer
• [ Dockerfile ] for a more complete and repeatable description
• (although reproducibility can be sabotaged: RUN apk add)
• apps that need to tune system parameters (privileged mode)
11

12. Artifact is Code + OS
app code + app deps + OS deps |> unikernel builder |> unikernel
unikernel runner
computer
• library operating systems: system dependencies on the same conceptual
level as application dependencies
• unikernels: the artifact we generate, which doesn't need to run on a
traditional OS
• note what's missing: build environment isn't necessarily well-specified
12

13. build unikernels in
containers
13

14. to follow along...
get started with docker pull ocaml/opam:ubuntu or your OS of
choice
you can also try docker pull halvm/base to give the Haskell
unikernel project HaLVM a shot
14

15. "OS
Dependencies"
15

16. what has your OS done for you lately?
• timekeeping
• networking
• entropy/randomness
• storage
• logs
• I/O: keyboard, mouse, video, sound, pancake printer, light-up bracelet...
16

17. sidebar: rump
• twiddling knobs in the kernel is tough
• it's way easier if you can test things in isolation
17

18. libraries in your
favorite language
18

19. you too are a systems programmer!
• most unikernel projects supply implementations for things like
networking
• some are swappable (including MirageOS - make the types agree and
you're good to go)
• you can write your own!
19

20. reject the default reality and substitute your
own
• common failure points for applications are "external" problems, which the
OS notices
• you can stress your application easily, by providing libraries that always
have edge cases occurring
20

21. fail gloriously,loudly,often
• network interfaces that always have new packets waiting
• random number generators that read from a static list
• entropy sources that always block
• filesystems that are always full
• block devices that are always busy
• DNS that always sends you to
supertrustworthy.plzgivemeyourcreds.com
21

22. OS libraries in your applications
• Docker4Mac and Docker4Windows hosts can have complicated
networking situations
• VPNs, custom DNS, mandatory proxies
• the Mac or Windows machine is configured to do the right thing — don't
break that!
• if nc google.com 80 works from the terminal, it should work from a
container
• use a unikernel networking library to reimplement an old solution to this:
22

23. VPNKit
23

24. VPNKit
• vpnkit is a piece of a library operating system, on your machine, right
now, as part of docker
• let's use unikernels to make the whole stack work better!
24

25. something more dramatic
run a unikernel with docker tools* - Martin Lucina's unikernel-runner
* (given direct access to /dev/kvm on the host)
25

26. where we're going
• we'll have done a good job when unikernels Just Work
• it should be just as easy to build, ship, run, and scale a unikernel as a
process or a container
• sometimes you'll want a unikernel and sometimes you won't — we want
to let you do the right thing no matter what
26

27. Unikernel is Just
Another Target
27

28. You Can Make It Happen!
• VPNKit - help improve libraries in Docker4Mac/Win
• HyperKit - dig into the D4M/W hypervisor!
• unikernel.org - find or list your favorite unikernel project!
• MirageOS summer hack retreat - join us face-to-face to improve
MirageOS!
28

29. special thanks to...
• my rad fellow Dockerites
• the fantastic contributors to Docker, MirageOS, HaLVM, Rump, and myriad
other unikernel projects
• Justin Cormack for last minute slide assistance and real good emceeing
29

30. Questions?
• @mindypreston
• mindy.preston@docker.com
• docker run -d -P mindypreston/dockercon2016
30