2018-10-29 16:14:51 +00:00
# Albatross: orchestrate and manage MirageOS unikernels with Solo5
2017-05-26 14:30:34 +00:00
2018-01-16 13:44:23 +00:00
[](https://travis-ci.org/hannesm/albatross)
2019-01-27 18:15:38 +00:00
The goal of albatross is robust deployment of [MirageOS ](https://mirage.io )
unikernels using [Solo5 ](https://github.com/solo5/solo5 ), including precise
error handling of failures. The code running under superuser privileges is
minimimal. Albatross is supposed to be run on a machine in the dom0, next to the
hypervisor. Albatross keeps track of unikernel resource usage (memory, CPUs,
bridges, block storage and active block devices). Policies restricting these
resources for administrative domains are available. Local and remote deployments
are supported, remote ones are authenticated and encrypted via a mutually
authenticated TLS connection using X.509 client certificates. Multi-tenancy
deployments are possible, tenants do not need any other access to the machine:
console output and statistics gathered by the host are accessible via TLS.
Albatross keeps the information of running unikernels persistently, and starts
these unikernels when the albatross daemon is started. This means that whenever
a unikernel was started, it keeps running until it crashes or an explicit
destroy command is issued.
The administrative domain is similar to DNS: each unikernel has a name (e.g.
`foo.hello` ), which consists of labels separated by dots. Policies and
access is done on a name basis - if access to `foo` is granted, `foo.hello` ,
`foo.bar.hello` , etc. can be accessed, but not `bar` or `bar.hello` .
## Components
Albatross consists of a set of binaries. Several daemons, which communicate in a
request-response style over Unix domain sockets, are run in the host system:
2019-03-27 23:11:43 +00:00
- `albatrossd` : privileged to create and destroy unikernels
- `albatross_console` : reads the console output of unikernels
- `albatross_log` : event log
- `albatross_stats` : statistics gathering (rusage, ifstat, BHyve debug counters)
- `albatross_tls_endpoint` : remote deployment via TLS with client certificate, and proxies to local daemons
- `albatross_tls_inetd` : remote deployment via TLS and inetd (alternative to `albatross_tls_endpoint` )
- `albatross_influx` : statistic reporting from `albatross_stats` to influx
The main daemon is the privileged `albatrossd` , which supervises unikernels. It opens
2019-01-27 18:15:38 +00:00
a listening Unix domain socket, reads the persisted unikernel configuration,
starts these unikernels, and awaits commands. Access can be regulated by Unix
file permissions, only those users who can write to that socket can send
commands.
2019-03-27 23:11:43 +00:00
`Albatross_console` does not keep any persistent state, but a ring buffer of console
2019-01-27 18:15:38 +00:00
output from each unikernel. These messages can be retrieved by a client, as a
stream of messages (history, and whenever a new line is output, it is send to
the interested client). Each unikernel output can only be read by a single
client, to avoid amplification of traffic if lots of clients are connected.
2019-03-27 23:11:43 +00:00
`Albatrossd` sends a message to `albatross_console` whenever a new unikernel is started,
upon reception `albatross_console` opens and reads the fifo which the unikernel will
2019-01-27 18:15:38 +00:00
write their standard output to.
2019-03-27 23:11:43 +00:00
`Albatross_log` keeps a persistent event log for albatross, can be read by clients.
2019-01-27 18:15:38 +00:00
2019-03-27 23:11:43 +00:00
`Albatross_stats` gathers periodically statistics (memory, CPU, network, hypervisor)
2019-01-27 18:15:38 +00:00
from all running unikernels.
2019-03-27 23:11:43 +00:00
`Albatross_tls_endpoint` and `albatross_tls_inetd` listen on a TCP port, and proxy requests from
2019-01-27 18:15:38 +00:00
remote clients to the respective daemons described above. They enforce client
authentication, and use the commen names of the client certificate chain as
administrative domain. The policies are embedded in CA certificates, the command
is embedded in the leaf certificate.
The following command-line applications for local and remote management are provided:
2019-03-27 23:11:43 +00:00
- `albatross_client_local` : sends a command locally to the Unix domain sockets
- `albatross_client_remote_tls` : connects to a remote TLS endpoint and sends a command
- `albatross_provision_request` : creates a certificate signing request containing a command
- `albatross_provision_ca` : certificate authority operations: sign, generate, and revoke (NYI)
- `albatross_client_bistro` : command line utility to execute a command remotely: request, sign, remote (do not use in production, requires CA key locally)
2017-05-26 14:30:34 +00:00
2019-01-27 18:15:38 +00:00
## Installation
2017-05-26 14:30:34 +00:00
2017-12-20 22:06:51 +00:00
To install Albatross, run `opam pin add albatross
2018-09-21 20:31:04 +00:00
https://github.com/hannesm/albatross`.
2017-05-26 14:30:34 +00:00
2019-01-27 18:15:38 +00:00
Init scripts for FreeBSD are provided in the `packaging/rc.d` subdirectory.
TODO: from here on, this documentation is not up to date.
It may help to read [the _outdated_ blog article ](https://hannes.nqsb.io/Posts/VMM )
for motivation of albatross and an overview over its functionality.
