github/linuxkit
1
0
Fork 0
mirror of https://github.com/linuxkit/linuxkit.git synced 2025-07-20 17:49:10 +00:00
Code Issues Projects Releases Wiki Activity

Update configuration docs

Browse Source 
Fix section names, add internal links

Signed-off-by: Daniel Nephin <dnephin@gmail.com>
This commit is contained in:
Daniel Nephin 2017-06-01 13:27:06 -04:00
parent 1d003717db
commit b18685ecd5
1 changed files with 15 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
docs/yaml.md
View File

@ -1,4 +1,4 @@
# Yaml configuration # Configuration Reference
The yaml configuration specifies the components and the build time artifacts. All components The yaml configuration specifies the components and the build time artifacts. All components
are downloaded at build time to create an image. The image is self-contained and immutable, are downloaded at build time to create an image. The image is self-contained and immutable,
@ -9,7 +9,7 @@ Each section adds file to the root file system
## `kernel` ## `kernel`
This section defines the kernel configuration. The `image` field specifies the Docker image, The `kernel` section defines the kernel configuration. The `image` field specifies the Docker image,
which should contain a `bzImage` (for `amd64` architecture, others may vary) and a file which should contain a `bzImage` (for `amd64` architecture, others may vary) and a file
called `kernel.tar` which is a tarball that is unpacked into the root, which should usually called `kernel.tar` which is a tarball that is unpacked into the root, which should usually
contain a kernel modules directory. See [`kernel/`](../kernel/) for source code. `cmdline` contain a kernel modules directory. See [`kernel/`](../kernel/) for source code. `cmdline`
@ -17,7 +17,7 @@ specifies the kernel command line options if required.
## `init` ## `init`
This section currently just lists images that is used for the `init` system and are unpacked directly The `init` section is a list of images that are used for the `init` system and are unpacked directly
into the root filesystem. This should bring up `containerd`, start the system and daemon containers, into the root filesystem. This should bring up `containerd`, start the system and daemon containers,
and set up basic filesystem mounts. See [`pkg/init/`](../pkg/init/) for source code. For ease of and set up basic filesystem mounts. See [`pkg/init/`](../pkg/init/) for source code. For ease of
modification `runc` and `containerd` images, which just contain these programs are added here modification `runc` and `containerd` images, which just contain these programs are added here
@ -25,19 +25,21 @@ rather than bundled into the `init` container.
## `onboot` ## `onboot`
These containers are run to completion sequentially, using `runc` before anything else is started. The `onboot` section is a list of images. These images are run before any other
They can be used to configure one shot settings. For details of the config for each container, see images. They are run sequentially and each must exit before the next one is run.
below. These images can be used to configure one shot settings. See [Image
specification](#image-specification) for a list of supported fields.
## `services` ## `services`
These containers are started with `containerd` and are expected to remain running. Startup order The `services` section is a list of images for long running services which are
is not guaranteed, so containers should wait on any resources, such as networking, that they need. run with `containerd`. Startup order is undefined, so containers should wait
For details of the config for each container, see below. on any resources, such as networking, that they need. See [Image
specification](#image-specification) for a list of supported fields.
## `trust` ## `trust`
This section specifies which build components are to be cryptographically verified with The `trust` section specifies which build components are to be cryptographically verified with
[Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/) prior to pulling. [Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/) prior to pulling.
Trust is a central concern in any build system, and LinuxKit's is no exception: Docker Content Trust provides authenticity, Trust is a central concern in any build system, and LinuxKit's is no exception: Docker Content Trust provides authenticity,
integrity, and freshness guarantees for the components it verifies. The LinuxKit maintainers are responsible for signing integrity, and freshness guarantees for the components it verifies. The LinuxKit maintainers are responsible for signing
@ -49,8 +51,9 @@ The image name may include tag or digest, but the matching also succeeds if the
## Image specification ## Image specification
For each image in the `system` and `daemon` sections you can specify the OCI options that are passed to Entries in the `onboot` and `services` sections specify an OCI image and
`runc`, so you can specify what capabilities are needed and so on. Most LinuxKit packages now define defaults in the `org.mobyproject.config` image label. For more details see the [OCI specification](https://github.com/opencontainers/runtime-spec/blob/master/spec.md). options. Default values may be specified using the `org.mobyproject.config` image label.
For more details see the [OCI specification](https://github.com/opencontainers/runtime-spec/blob/master/spec.md).
- `name` a unique name for the program being executed, used as the `containerd` id. - `name` a unique name for the program being executed, used as the `containerd` id.
- `image` the Docker image to use for the root filesystem. The default command, path and environment are - `image` the Docker image to use for the root filesystem. The default command, path and environment are