daemon: let shim binary of runtime configurable#43736
daemon: let shim binary of runtime configurable#43736liubin wants to merge 1 commit intomoby:masterfrom
Conversation
|
Additional note to reviewers: If this idea is acceptable, I will go on the next steps, including process First of all, I would like to hear your thoughts on this approach. |
|
This seems mostly ok. |
|
Thank you @cpuguy83, Kata Containers shim has its configuration file, users can use this file or annotations to set shim/runtime options. |
|
I feel this should be called "name" rather than a "binary" as the value is not a binary file path |
|
@AkihiroSuda though the name of |
api/types/types.go
Outdated
| // This is exposed here only for internal use | ||
| // It is not currently supported to specify custom shim configs | ||
| Shim *ShimConfig `json:"-"` | ||
| Shim *ShimConfig `json:"shim"` |
There was a problem hiding this comment.
This type is also used in the Info type, which is used for the /info response;
Line 302 in 9ccedde
So;
- some changes are needed in the
Runtimedefinition in the Swagger file - and an entry to be added to the API version-history.md
There was a problem hiding this comment.
Fixed, please take a look again.
api/types/types.go
Outdated
| @@ -657,15 +657,16 @@ type Runtime struct { | |||
| Path string `json:"path"` | |||
There was a problem hiding this comment.
Curious; your example shows a runtime configuration that ONLY has shim.binary set (but no path); is that a valid configuration?
- If so (and the
pathis optional), we should consider adding anomitemptyto this field. - If that means that at least
pathand/orshim.binarymust be specified, then we should probably have a validation for that (error if none are set?).
There was a problem hiding this comment.
Thank you for the review, @thaJeztah
The path is used for configuring OCI runtime for io.containerd.runc.v2 shim, for other shims, they may or may not need the path property, so I added the omitempty attribute.
|
As these fields are now added to the API, and were previously "internal" (so not part of the JSON output), I guess we should also look what we want the API response to look like. Currently (in this PR, the response will be something like; {
"path": "crun",
"shim": {
"binary": "io.containerd.runc.v2"
}
}Question is; do we want the type Runtime struct {
Path string `json:"path"`
Args []string `json:"runtimeArgs,omitempty"`
*ShimConfig
}
// ShimConfig is used by runtime to configure containerd shims
type ShimConfig struct {
Binary string `json:"shim,omitempty"`
// This is exposed here only for internal use
// It is not currently supported to specify custom shim options
Opts interface{} `json:"-"`
}Which would look like; {
"path": "runc",
"shim": "io.containerd.runc.v2"
}^^^ input/suggestions welcome on the above; wdyt @AkihiroSuda @cpuguy83 ? |
Users can add additional runtimes by adding configurations
to daemon.json, but it can only be used for specific OCI
runtimes under io.containerd.runc.v2.
By exposing shim and its binary property, users can set
containerd shim v2 runtime directly:
{
"default-runtime": "runc",
"runtimes": {
"kata": {
"shim": {
"binary": " io.containerd.kata.v2"
}
}
}
}
Now users can use `--runtime kata` to start containers run
inside Kata Containers.
Signed-off-by: liubin <liubin0329@gmail.com>
29b347a to
778a776
Compare
|
I updated the code, and now for such a {
"runtimes": {
"runc-1": {},
"kata": {
"shim": {
"binary": "io.containerd.kata.v2"
}
},
"runx": {
"path": "runc",
"runtimeArgs": [
"--debug"
]
}
}
}
The {
"io.containerd.runc.v2": {
"path": "runc",
"shim": {
"binary": "io.containerd.runc.v2"
}
},
"kata": {
"shim": {
"binary": "io.containerd.kata.v2"
}
},
"runc": {
"path": "runc",
"shim": {
"binary": "io.containerd.runc.v2"
}
},
"runc-1": {},
"runx": {
"path": "runc",
"runtimeArgs": [
"--debug"
]
}
}
|
|
@cpuguy83 @AkihiroSuda @thaJeztah PATL, thanks. |
| type ShimConfig struct { | ||
| Binary string | ||
| Opts interface{} | ||
| Binary string `json:"binary"` |
There was a problem hiding this comment.
Nit: Maybe call this Type which, as I recall, is generally how they are referred to in containerd.
Then we can have another field like Path so people can customize the path to the binary.
There was a problem hiding this comment.
The alternative would be to flatten the output, and show it as shim; #43736 (comment)
{ "path": "runc", "shim": "io.containerd.runc.v2" }
Or would that be simplifying it too much?
| example: ["--debug", "--systemd-cgroup=false"] | ||
| shim: | ||
| description: | | ||
| Specify the containerd shim v2 name or binary when invoked. |
There was a problem hiding this comment.
Configuration options for containerd shims.
| properties: | ||
| binary: | ||
| description: | | ||
| A containerd shim v2 name or the absolute path of the binary. |
There was a problem hiding this comment.
Maybe we can forgo the v2 here.
| Path string `json:"path"` | ||
| Path string `json:"path,omitempty"` | ||
| Args []string `json:"runtimeArgs,omitempty"` | ||
|
|
||
| // This is exposed here only for internal use | ||
| // It is not currently supported to specify custom shim configs | ||
| Shim *ShimConfig `json:"-"` | ||
| Shim *ShimConfig `json:"shim,omitempty"` |
There was a problem hiding this comment.
The Path and Args fields are effectively ignored when Shim != nil so users who set both might be surprised to find some of their configuration is ignored. The technical reason is that the Path and Args fields are passed as options to the runc shim. Other shims are unlikely to accept a runc options message and the daemon wouldn't know how to marshal the options to the protobuf message type the other shim is expecting, so the daemon makes no attempt to mutate a provided shim config.
Lines 122 to 135 in be62811
Since the daemon can't marshal the options for arbitrary shims from JSON, the shim name is the only thing which could be configured from the daemon for shims which are not io.containerd.runc.v2. It's one string, and the docker run --runtime flag also happens to be one string... No daemon.json configuration would be required to use alternative runtimes if the daemon was to interpret --runtime values (which do not correspond to any runtimes property in daemon.json) as the desired shim name! This is how containerd's ctr and nerdctl commands behave, to great effect.
There was a problem hiding this comment.
From a UX perspective, the --runtime option was meant to be the more "convenient" option, where the user can use docker info to see which runtimes are available/configured on the daemon, and use those as option (--runtime=runc, --runtime=kata), and the daemon-configuratioin can contain additional config options (IIRC, this could even be multiple versions of runc, e.g.).
No daemon.json configuration would be required to use alternative runtimes if the daemon was to interpret --runtime values
I know that access to the API already is equivalent to root, but if the --runtime value passed can be (as is being discussed here) either a name (io.containerd.runc.v2) or a path to a binary, that could potentially open up some "interesting" things (--runtime=/bin/rm, --runtime=/some/arbitrary/script.sh)
|
FYI, this PR appears to be a duplicate of |
- What I did
Let users configure shim's binary for additional runtimes
- How I did it
Set json tag of the golang struct definition.
- How to verify it
Edit daemon.json.
{ "default-runtime": "runc", "runtimes": { "kata": { "shim": { "binary": " io.containerd.kata.v2" } } } }and then run
docker run --net none --runtime kata -it alpine:3.15 sh.Note: you need Kata Containers shim has been installed.
- Description for the changelog
daemon: let shim binary of runtime configurable
- A picture of a cute animal (not mandatory but encouraged)