Skip to content

Commit 0c07f86

Browse files
7c00d7c00d
committed
conversion: add document about image -> runtime configuration
Add documentation about how to convert from an OCI image configuration to an OCI runtime configuration. In particular, describe precisely what fields need to be filled given a particular configuration. The fields have been grouped into several categories, because some of the image fields are not as well-thought-out as others (such as the resource limitation fields, which should really be decided by the user not by the image creator). In addition, some fields (such as Volumes) cannot be understood by a generic configuration converter. In addition, the annotation org.opencontainers.imageSpec.exposedPorts has been defined in order to allow for hinting to runtimes what ports are exposed by a container. The same for org.containers.imageSpec.stopSignal. Signed-off-by: Aleksa Sarai <[email protected]>
1 parent 2c3fdd2 commit 0c07f86

File tree

3 files changed

+121
-1
lines changed

3 files changed

+121
-1
lines changed

‎Makefile‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -30,6 +30,7 @@ DOC_FILES := \
3030
layer.md \
3131
config.md \
3232
annotations.md \
33+
conversion.md \
3334
considerations.md \
3435
implementations.md
3536

‎conversion.md‎

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
# Conversion to OCI Runtime Configuration
2+
3+
When extracting an OCI Image into an [OCI Runtime bundle][oci-runtime-bundle], two orthogonal components of the extraction are relevant:
4+
5+
1. Extraction of the root filesystem from the set of [filesystem layers](layers.md).
6+
2. Conversion of the [image configuration blob](config.md) to an [OCI Runtime configuration blob][oci-runtime-config].
7+
8+
This section defines how to convert an `application/vnd.oci.image.config.v1+json` blob to an [OCI runtime configuration blob][oci-runtime-config] (the latter component of extraction).
9+
The former component of extraction is defined [elsewhere](layers.md) and is orthogonal to configuration of a runtime bundle.
10+
The values of runtime configuration properties not specified by this document are implementation-defined.
11+
12+
A converter MUST rely on the OCI image configuration to build the OCI runtime configuration as described by this document; this will create the "default generated runtime configuration".
13+
14+
The "default generated runtime configuration" MAY be overridden or combined with externally provided inputs from the caller.
15+
In addition, a converter MAY have its own implementation-defined defaults and extensions which MAY be combined with the "default generated runtime configuration".
16+
The restrictions in this document refer only to combining implementation-defined defaults with the "default generated runtime configuration".
17+
Externally provided inputs are considered to be a modification of the `application/vnd.oci.image.config.v1+json` used as a source, and such modifications have no restrictions.
18+
19+
For example, externally provided inputs MAY cause an environment variable to be added, removed or changed.
20+
However an implementation-defined default SHOULD NOT result in an environment variable being removed or changed.
21+
22+
[oci-runtime-bundle]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc5/bundle.md
23+
[oci-runtime-config]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc5/config.md
24+
25+
## Verbatim Fields
26+
27+
Certain image configuration fields have an identical counterpart in the runtime configuration.
28+
Some of these are purely annotation-based fields, and have been extracted into a [separate subsection](#annotation-fields).
29+
A compliant configuration converter MUST extract the following fields verbatim to the corresponding field in the generated runtime configuration:
30+
31+
| Image Field | Runtime Field | Notes |
32+
| ------------------- | --------------- | ----- |
33+
| `architecture` | `platform.arch` | |
34+
| `os` | `platform.os` | |
35+
| `Config.WorkingDir` | `process.cwd` | |
36+
| `Config.Env` | `process.env` | 1 |
37+
| `Config.Entrypoint` | `process.args` | 2 |
38+
| `Config.Cmd` | `process.args` | 2 |
39+
40+
1. The converter MAY add additional entries to `process.env` but it SHOULD NOT add entries that have variable names present in `Config.Env`.
41+
2. If both `Config.Entrypoint` and `Config.Cmd` are specified, the converter MUST append the value of `Config.Cmd` to the value of `Config.Entrypoint` and set `process.args` to that combined value.
42+
43+
### Annotation Fields
44+
45+
These fields all affect the `annotations` of the runtime configuration, and are thus subject to [precedence](#annotations).
46+
47+
| Image Field | Runtime Field | Notes |
48+
| ------------------- | --------------- | ----- |
49+
| `author` | `annotations` | 1,2 |
50+
| `created` | `annotations` | 1,3 |
51+
| `Config.Labels` | `annotations` | |
52+
| `Config.StopSignal` | `annotations` | 1,4 |
53+
54+
1. If a user has explicitly specified this annotation with `Config.Labels`, then the value specified in this field takes lower [precedence](#annotations) and the converter MUST instead use the value from `Config.Labels`.
55+
2. The value of this field MUST be set as the value of `org.opencontainers.image.author` in `annotations`.
56+
3. The value of this field MUST be set as the value of `org.opencontainers.image.created` in `annotations`.
57+
4. The value of this field MUST be set as the value of `org.opencontainers.image.stopSignal` in `annotations`.
58+
59+
## Parsed Fields
60+
61+
Certain image configuration fields have a counterpart that must first be translated.
62+
A compliant configuration converter SHOULD parse all of these fields and set the corresponding fields in the generated runtime configuration:
63+
64+
| Image Field | Runtime Field |
65+
| ------------------- | --------------- |
66+
| `Config.User` | `process.user.*` |
67+
68+
The method of parsing the above image fields are described in the following sections.
69+
70+
### `Config.User`
71+
72+
If the values of [`user` or `group`](config.md#properties) in `Config.User` are numeric (`uid` or `gid`) then the values MUST be copied verbatim to `process.user.uid` and `process.user.gid` respectively.
73+
If the values of [`user` or `group`](config.md#properties) in `Config.User` are not numeric (`user` or `group`) then a converter SHOULD resolve the user information using a method appropriate for the container's context.
74+
For Unix-like systems, this MAY involve resolution through NSS or parsing `/etc/passwd` from the extracted container's root filesystem to determine the values of `process.user.uid` and `process.user.gid`.
75+
76+
In addition, a converter SHOULD set the value of `process.user.additionalGids` to a value corresponding to the user in the container's context described by `Config.User`.
77+
For Unix-like systems, this MAY involve resolution through NSS or parsing `/etc/group` and determining the group memberships of the user specified in `process.user.uid`.
78+
If the value of [`user`](config.md#properties) in `Config.User` is numeric, the converter SHOULD NOT modify `process.user.additionalGids`.
79+
80+
If `Config.User` is not defined, the converted `process.user` value is implementation-defined.
81+
If `Config.User` does not correspond to a user in the container's context, the converter MUST return an error.
82+
83+
## Optional Fields
84+
85+
Certain image configuration fields are not applicable to all conversion use cases, and thus are optional for configuration converters to implement.
86+
A compliant configuration converter SHOULD provide a way for users to extract these fields into the generated runtime configuration:
87+
88+
| Image Field | Runtime Field | Notes |
89+
| --------------------- | ------------------ | ----- |
90+
| `Config.ExposedPorts` | `annotations` | 1 |
91+
| `Config.Volumes` | `mounts` | 2 |
92+
93+
1. The runtime configuration does not have a corresponding field for this image field.
94+
However, converters SHOULD set the [`org.opencontainers.image.exposedPorts` annotation](#config.exposedports).
95+
2. If a converter implements conversion for this field using mountpoints, it SHOULD set the `destination` of the mountpoint to the value specified in `Config.Volumes`.
96+
The other `mounts` fields are platform and context dependent, and thus are implementation-defined.
97+
Note that the implementation of `Config.Volumes` need not use mountpoints, as it is effectively a mask of the filesystem.
98+
99+
### `Config.ExposedPorts`
100+
101+
The OCI runtime configuration does not provide a way of expressing the concept of "container exposed ports".
102+
However, converters SHOULD set the **org.opencontainers.image.exposedPorts** annotation, unless doing so will [cause a conflict](#annotations).
103+
104+
**org.opencontainers.image.exposedPorts** is the list of values that correspond to the [keys defined for `Config.ExposedPorts`](config.md) (string, comma-separated values).
105+
106+
## Annotations
107+
108+
There are three ways of annotating an OCI image in this specification:
109+
110+
1. `Config.Labels` in the [configuration](config.md) of the image.
111+
2. `annotations` in the [manifest](manifest.md) of the image.
112+
3. `annotations` in the [image index](image-index.md) of the image.
113+
114+
In addition, there are also implicit annotations that are defined by this section which are determined from the values of the image configuration.
115+
A converter SHOULD NOT attempt to extract annotations from [manifests](manifest.md) or [image indices](image-index.md).
116+
If there is a conflict (same key but different value) between an implicit annotation (or annotation in [manifests](manifest.md) or [image indices](image-index.md)) and an explicitly specified annotation in `Config.Labels`, the value specified in `Config.Labels` MUST take precedence.
117+
118+
A converter MAY add annotations which have keys not specified in the image.
119+
A converter MUST NOT modify the values of annotations specified in the image.

‎manifest.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ There are three main goals of the Image Manifest Specification.
44
The first goal is content-addressable images, by supporting an image model where the image's configuration can be hashed to generate a unique ID for the image and its components.
55
The second goal is to allow multi-architecture images, through a "fat manifest" which references image manifests for platform-specific versions of an image.
66
In OCI, this is codified in an [image index](image-index.md).
7-
The third goal is to be translatable to the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec).
7+
The third goal is to be [translatable](conversion.md) to the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec).
88

99
This section defines the `application/vnd.oci.image.manifest.v1+json` [media type](media-types.md).
1010
For the media type(s) that this is compatible with see the [matrix](media-types.md#compatibility-matrix).

0 commit comments

Comments
 (0)