runc/runtime.md

60 lines
3.4 KiB
Markdown
Raw Normal View History

# Runtime and Lifecycle
2015-06-06 08:39:27 +08:00
## State
Runtime MUST store container metadata on disk so that external tools can consume and act on this information.
It is recommended that this data be stored in a temporary filesystem so that it can be removed on a system reboot.
On Linux/Unix based systems the metadata MUST be stored under `/run/opencontainer/containers`.
For non-Linux/Unix based systems the location of the root metadata directory is currently undefined.
Within that directory there MUST be one directory for each container created, where the name of the directory MUST be the ID of the container.
For example: for a Linux container with an ID of `173975398351`, there will be a corresponding directory: `/run/opencontainer/containers/173975398351`.
Within each container's directory, there MUST be a JSON encoded file called `state.json` that contains the runtime state of the container.
For example: `/run/opencontainer/containers/173975398351/state.json`.
The `state.json` file MUST contain all of the following properties:
* **`version`**: (string) is the OCF specification version used when creating the container.
* **`id`**: (string) is the container's ID.
This MUST be unique across all containers on this host.
There is no requirement that it be unique across hosts.
The ID is provided in the state because hooks will be executed with the state as the payload.
This allows the hooks to perform cleanup and teardown logic after the runtime destroys its own state.
* **`pid`**: (int) is the ID of the main process within the container, as seen by the host.
* **`bundlePath`**: (string) is the absolute path to the container's bundle directory.
This is provided so that consumers can find the container's configuration and root filesystem on the host.
*Example*
```json
{
"version": "0.2.0",
"id": "oc-container",
"pid": 4422,
"bundlePath": "/containers/redis"
}
```
## Lifecycle
The lifecycle describes the timeline of events that happen from when a container is created to when it ceases to exist.
1. OCI compliant runtime is invoked by passing the bundle path as argument.
config: Single, unified config file Reverting 7232e4b1 (specs: introduce the concept of a runtime.json, 2015-07-30, #88) after discussion on the mailing list [1]. The main reason is that it's hard to draw a clear line around "inherently runtime-specific" or "non-portable", so we shouldn't try to do that in the spec. Folks who want to flag settings as non-portable for their own system are welcome to do so (e.g. "we will clobber 'hooks' in bundles we run") are welcome to do so, but we don't have to have to split the config into multiple files to do that. There have been a number of additional changes since #88, so this isn't a pure Git reversion. Besides copy-pasting and the associated link-target updates, I've: * Restored path -> destination, now that the mount type contains both source and target paths again. I'd prefer 'target' to 'destination' to match mount(2), but the pre-7232e4b1 phrasing was 'destination' (possibly due to Windows using 'target' for the source?). * Restored the Windows mount example to its pre-7232e4b1 content. * Removed required mounts from the config example (requirements landed in 3848a238, config-linux: specify the default devices/filesystems available, 2015-09-09, #164), because specifying those mounts in the config is now redundant. * Used headers (vs. bold paragraphs) to set off mount examples so we get link anchors in the rendered Markdown. * Replaced references to runtime.json with references to config.json. [1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY Subject: Single, unified config file (i.e. rolling back specs#88) Date: Wed, 4 Nov 2015 09:53:20 -0800 Message-ID: <20151104175320.GC24652@odin.tremily.us> Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2. The container's runtime environment is created according to the configuration in [`config.json`](config.md).
Any updates to `config.json` after container is running do not affect the container.
3. The container's state.json file is written to the filesystem.
4. The prestart hooks are invoked by the runtime.
If any prestart hook fails, then the container is stopped and the lifecycle continues at step 8.
5. The user specified process is executed in the container.
6. The poststart hooks are invoked by the runtime.
If any poststart hook fails, then the container is stopped and the lifecycle continues at step 8.
7. Additional actions such as pausing the container, resuming the container or signaling the container may be performed using the runtime interface.
The container could also error out or crash.
8. The container is destroyed by undoing the steps performed during create phase (step 2).
9. The poststop hooks are invoked by the runtime and errors, if any, are logged.
10. The state.json file associated with the container is removed and the return code of the container's user specified process is returned or logged.
Note: The lifecycle is a WIP and it will evolve as we have more use cases and more information on the viability of a separate create phase.
## Hooks
config: Single, unified config file Reverting 7232e4b1 (specs: introduce the concept of a runtime.json, 2015-07-30, #88) after discussion on the mailing list [1]. The main reason is that it's hard to draw a clear line around "inherently runtime-specific" or "non-portable", so we shouldn't try to do that in the spec. Folks who want to flag settings as non-portable for their own system are welcome to do so (e.g. "we will clobber 'hooks' in bundles we run") are welcome to do so, but we don't have to have to split the config into multiple files to do that. There have been a number of additional changes since #88, so this isn't a pure Git reversion. Besides copy-pasting and the associated link-target updates, I've: * Restored path -> destination, now that the mount type contains both source and target paths again. I'd prefer 'target' to 'destination' to match mount(2), but the pre-7232e4b1 phrasing was 'destination' (possibly due to Windows using 'target' for the source?). * Restored the Windows mount example to its pre-7232e4b1 content. * Removed required mounts from the config example (requirements landed in 3848a238, config-linux: specify the default devices/filesystems available, 2015-09-09, #164), because specifying those mounts in the config is now redundant. * Used headers (vs. bold paragraphs) to set off mount examples so we get link anchors in the rendered Markdown. * Replaced references to runtime.json with references to config.json. [1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY Subject: Single, unified config file (i.e. rolling back specs#88) Date: Wed, 4 Nov 2015 09:53:20 -0800 Message-ID: <20151104175320.GC24652@odin.tremily.us> Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
See [runtime configuration for hooks](./config.md#hooks)