Merge pull request #1356 from justincormack/roadmap

Add the beginings of a roadmap and faq
This commit is contained in:
Justin Cormack 2017-03-22 14:52:53 +00:00 committed by GitHub
commit 448a0e4335
2 changed files with 56 additions and 0 deletions

View File

@ -59,3 +59,27 @@ For the images, you can specify the configuration much like Compose, with some c
there are no volumes only `binds`.
The config is liable to be changed, and there are missing features; full documentation will be available shortly.
## 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.
Security by default is a key aim. In the short term this means using modern kernels, using best practise settings for the kernel, from [KSPP](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)
and elsewhere. It also means working to incorporate more security features into the kernel, including those in our [projects](projects/). In userspace, the core system components
are key to security, and we believe they should be written in type safe languages, such as Rust, Go and OCaml, and run with maximum privilege separation and isolation.
There is ongoing work to remove C components, and to improve, fuzz test and isolate the base daemons.
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
## FAQ
See [FAQ](docs/faq.md).

32
docs/faq.md Normal file
View File

@ -0,0 +1,32 @@
# FAQ
Please open an issue if you want to add a question here.
## How do updates work?
Moby does not require being installed on a disk, it is often run from an ISO, PXE or other
such means, so it does not require an on disk upgrade method such as the ChromeOS code that
is often used. It would definitely be possible to use that type of upgrade method if the
system is installed, and it would be useful to support this for that use case, and an
updater container to control this for people who want to use this.
We generally use external tooling such as [Infrakit](https://github.com/docker/infrakit) or
CloudFormation templates to manage the update process externally from Moby, including
doing rolling cluster upgrades to make sure distributed applciations stay up and responsive.
Updates may preserve the state disk used by applications if needed, either on the same physical
node, or by reattaching a virtual cloud volume to a new node.
## What do I need to build Moby?
We have tried to make this as simple as possible, by using containers for the build process, so
you should be able to build Moby on any OSX or Linux laptop; we should have Windows build support
soon.
## Why not use `systemd`?
In order to keep the system minimal, `systemd` did not seem appropriate, as it brings in a lot
of dependencies and functionality that we do not need. At present we are using the `busybox`
`init` process, and a small set of minimal scripts, but we expect to replace that with a small
standalone `init` process and a small piece of code to bring up the system containers where the
real work takes place.