Re: [MirageOS-devel] Some thoughts on operating unikernel environments

[Thomas Leonard <talex5@xxxxxxxxx>]

On 21 August 2015 at 17:07, Gareth Rushgrove <gareth@xxxxxxxxxxxxxxxxx> wrote:
> I'd managed to get a bunch of throughts out of how head an into blog
> post form, on the theme of operating unikernels.
>
> The general gist is, assuming unikernels are awesome, how do we build
> and run production systems based on them?
>
> http://www.morethanseven.net/2015/08/21/operating-unikernel-challenges/
>
> This is mainly a list of problems, I'd love to heard from anyone who
> has done any hard thinking on any of them or cut any tools in this
> space.

Hi Gareth,

A few thoughts:


"How do I compose several unikernels together to build an application?"

I think you answer this later, in the Orchestration section: the same
way we do with other VMs/containers - using Docker Compose, Ubuntu
Juju, etc. I haven't built anything big enough to need this yet
though.


What does a Continuous integration or deployment pipeline look like?

Amir gives an example in "Towards Heroku for Unikernels: Part 1 -
Automated deployment":

http://amirchaudhry.com/heroku-for-unikernels-pt1/


"By removing the operating system we remove things like host firewalls ..."

I see two main uses for firewalls. One is to avoid accidentally
exposing a host-only service (e.g. a database used by a web app in the
same VM) and the other is to provide basic access contol between VMs
(only the web VM can access the DB VM).

For the first, two services in the same Mirage unikernel will
communicate directly using OCaml datatypes. When everything is a
library, using a network for internal communication would be crazy.
Also, while Linux allows any process to listen on the network, Mirage
uses dependency injection so that only components that need network
access will be given it.

For the second, whatever is composing the services should configure
the network, in my opinion. In other words, if I say I want my web
server VM connected to a database VM, then nothing else should have
access to the DB VM.

I would certainly like to see a higher-level API for networking, that
doesn't allow unexpected connections. e.g. we currently offer services
a low-level network API like:

  val connect : network -> ipaddr -> port -> flow
  val listen : network -> port -> callback -> unit

With this API, a library with network access can connect anywhere in
the world by supplying any IP address and port number, and must handle
its own encryption. A higher-level capability-style API could offer
something more abstract, e.g.

  module type SturdyRef = sig
    type t
    val connect : t -> flow
  end

Here, our web server would simply get a SturdyRef.t for the database,
and all it could do would be to connect to it.


What does debugging a system based on unikernels look like?

There's an example here: https://mirage.io/wiki/profiling

"As a motivating example, we'll track down a (real, but now fixed) bug
in MirageOS's TCP stack."


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel