mirror of
https://github.com/linuxkit/linuxkit.git
synced 2025-07-19 17:26:28 +00:00
Merge pull request #1356 from justincormack/roadmap
Add the beginings of a roadmap and faq
This commit is contained in:
commit
448a0e4335
24
README.md
24
README.md
@ -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
32
docs/faq.md
Normal 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.
|
Loading…
Reference in New Issue
Block a user