33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
|
# Mounts
|
||
|
|
|
||
|
|
Mounts are the main interaction mechansim in containerD. Container systems of
|
||
|
|
the past typically end up having several disparate components independently
|
||
|
|
perform mounts, resulting in complex lifecycle management and buggy behavior
|
||
|
|
when coordinating large mount stacks.
|
||
|
|
|
||
|
|
In containerD, we intend to keep mount syscalls isolated to the container
|
||
|
|
runtime component, opting to have various components produce a serialized
|
||
|
|
representation of the mount. This ensures that the mounts are performed as a
|
||
|
|
unit and unmounted as a unit.
|
||
|
|
|
||
|
|
From an architecture perspective, components produce mounts and runtime
|
||
|
|
executors consume them.
|
||
|
|
|
||
|
|
More imaginitive use cases include the ability to virtualize a series of mounts
|
||
|
|
from various components without ever having to create a runtime. This will aid
|
||
|
|
in testing and implementation of satellite components.
|
||
|
|
|
||
|
|
## Structure
|
||
|
|
|
||
|
|
The `Mount` type follows the structure of the historic mount syscall:
|
||
|
|
|
||
|
|
| Field | Type | Description |
|
||
|
|
|-------|----|-------------|
|
||
|
|
| Type | `string` | Specific type of the mount, typically operating system specific |
|
||
|
|
| Target | `string` | Intended filesystem path for the mount destination. |
|
||
|
|
| Source | `string` | The object which originates the mount, typically a device or another filesystem path. |
|
||
|
|
| Options | `[]string` | Zero or more options to apply with the mount, possibly `=`-separated key value pairs. |
|
||
|
|
|
||
|
|
We may want to further parameterize this to support mounts with various
|
||
|
|
helpers, such as `mount.fuse`, but this is out of scope, for now.
|