A toolkit for building secure, portable and lean operating systems for containers
Go to file
Ilya Dmitrichenko 12d6e38b48 Use directory: true instead fo writing a dummy file
Signed-off-by: Ilya Dmitrichenko <errordeveloper@gmail.com>
2017-04-08 05:53:22 +01:00
base update runc to version ac50e77bbb440dcab354a328c79754e2502b79ca 2017-04-07 11:46:34 +02:00
docs Update security arch docs with feedback 2017-04-05 11:29:07 -07:00
examples Make init accept a list of images not just a single one. 2017-04-07 14:25:28 +01:00
kernel Sign and verify kernel image on make push 2017-04-04 08:33:48 -07:00
pkg update runc to version ac50e77bbb440dcab354a328c79754e2502b79ca 2017-04-07 11:46:34 +02:00
projects Use directory: true instead fo writing a dummy file 2017-04-08 05:53:22 +01:00
reports Fix minor typos in weekly report 2017-04-03 13:33:35 +01:00
scripts Remove some obsolete scripts 2017-04-06 17:57:16 +01:00
src moby: Add -img-name flag to moby run gcp 2017-04-07 15:35:54 +01:00
test Make init accept a list of images not just a single one. 2017-04-07 14:25:28 +01:00
tools tools: rename mkimage-gce to mkimage-gcp 2017-04-06 16:59:57 +01:00
vendor vendor: Update the HyperKit go bindings 2017-04-07 10:52:40 +01:00
.gitignore Merge pull request #1476 from riyazdf/make-cleaner 2017-04-04 17:23:12 +01:00
Makefile makefile: Add targets to test GCP 2017-04-07 15:22:12 +01:00
moby.yml Make init accept a list of images not just a single one. 2017-04-07 14:25:28 +01:00
README.md Simplify the instructions if you already have Go installed 2017-04-07 15:03:39 +01:00
vendor.conf vendor: Update the HyperKit go bindings 2017-04-07 10:52:40 +01:00

Moby

Moby, a toolkit for building custom minimal, immutable Linux distributions.

  • Secure defaults without compromising usability
  • Everything is replaceable and customisable
  • Immutable infrastructure applied to building Linux distributions
  • Completely stateless, but persistent storage can be attached
  • Easy tooling, with easy iteration
  • Built with containers, for running containers
  • Designed for building and running clustered applications, including but not limited to container orchestration such as Docker or Kubernetes
  • Designed from the experience of building Docker Editions, but redesigned as a general purpose toolkit
  • Designed to be managed by external tooling, such as Infrakit or similar tools
  • Includes a set of longer term collaborative projects in various stages of development to innovate on kernel and userspace changes, particularly around security

Getting Started

Build the moby tool

Simple build instructions: use make to build. This will build the Moby customisation tool.

If you already have go installed you can use go get -u github.com/docker/moby/src/cmd/moby to install the moby tool, and then use moby build moby.yml to build the example configuration. You can use go get -u github.com/docker/moby/src/cmd/infrakit-instance-hyperkit to get the hyperkit infrakit tool.

Once you have built the tool, use bin/moby build moby.yml to build the example configuration, and bin/moby run moby to run locally. Use halt to terminate on the console.

Build requirements:

  • GNU make
  • GNU or BSD tar (not busybox tar)
  • Docker

Booting and Testing

If you have a recent version of Docker for Mac installed you can use moby run <name> to execute the image you created with moby build <name>.yml

The Makefile also specifies a number of targets:

  • make qemu will boot up a sample Moby in qemu in a container
  • on OSX: make hyperkit will boot up Moby in hyperkit
  • make test or make hyperkit-test will run the test suite
  • There are also docs for booting on Google Cloud
  • More detailed docs will be available shortly, for running single hosts and clusters.

Building your own customised image

To customise, copy or modify the moby.yml to your own file.yml or use one of the examples and then run ./bin/moby build file.yml to generate its specified output. You can run the output with ./scripts/qemu.sh or on OSX with ./bin/moby run file. moby run targets will be available for other platforms shortly.

The yaml file specifies a kernel and base init system, a set of containers that are built into the generated image and started at boot time. It also specifies what formats to output, such as bootable ISOs and images for various platforms.

Yaml Specification

The yaml format is loosely based on Docker Compose:

  • kernel specifies a kernel Docker image, containing a kernel and a filesystem tarball, eg containing modules. mobylinux/kernel is built from kernel/
  • init is the base init process Docker image, which is unpacked as the base system, containing init, containerd, runc and a few tools. Built from base/init/
  • system are the system containers, executed sequentially in order. They should terminate quickly when done.
  • daemon is the system daemons, which normally run for the whole time
  • files are additional files to add to the image
  • outputs are descriptions of what to build, such as ISOs.

For the images, you can specify the configuration much like Compose, with some changes, eg capabilities must be specified in full, rather than add and drop, and there are no volumes only binds.

The config is liable to be changed, and there are missing features; full documentation will be available shortly.

Architecture

There is an overview of the architecture covering how the system works.

Security design

There is an overview of the security considerations and direction covering the security design of the system.

Roadmap

This project was extensively reworked from the code we are shipping in Docker Editions, and the result is not yet production quality. The plan is to return to production quality during Q2 2017, and rebase the Docker Editions on this open source project.

This is an open project without fixed judgements, open to the community to set the direction. The guiding principles are:

  • Security informs design
  • Infrastructure as code: immutable, manageable with code
  • Sensible secure and well tested defaults
  • An open, pluggable platform for diverse use cases
  • Easy to use and participate in the project
  • Built with containers, for portability and reproducibility
  • Run with system containers, for isolation and extensibility
  • A base for robust products

Development reports

There are weekly development reports summarizing work carried out in the week.

FAQ

See FAQ.