moby/daemon/info_unix.go

374 lines
12 KiB
Go
Raw Normal View History

//go:build !windows
package daemon // import "github.com/docker/docker/daemon"
import (
"context"
Add "Warnings" to /info endpoint, and move detection to the daemon When requesting information about the daemon's configuration through the `/info` endpoint, missing features (or non-recommended settings) may have to be presented to the user. Detecting these situations, and printing warnings currently is handled by the cli, which results in some complications: - duplicated effort: each client has to re-implement detection and warnings. - it's not possible to generate warnings for reasons outside of the information returned in the `/info` response. - cli-side detection has to be updated for new conditions. This means that an older cli connecting to a new daemon may not print all warnings (due to it not detecting the new conditions) - some warnings (in particular, warnings about storage-drivers) depend on driver-status (`DriverStatus`) information. The format of the information returned in this field is not part of the API specification and can change over time, resulting in cli-side detection no longer being functional. This patch adds a new `Warnings` field to the `/info` response. This field is to return warnings to be presented by the user. Existing warnings that are currently handled by the CLI are copied to the daemon as part of this patch; This change is backward-compatible with existing clients; old client can continue to use the client-side warnings, whereas new clients can skip client-side detection, and print warnings that are returned by the daemon. Example response with this patch applied; ```bash curl --unix-socket /var/run/docker.sock http://localhost/info | jq .Warnings ``` ```json [ "WARNING: bridge-nf-call-iptables is disabled", "WARNING: bridge-nf-call-ip6tables is disabled" ] ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-07-19 11:45:32 +00:00
"fmt"
"os/exec"
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
"path/filepath"
"strings"
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
v2runcoptions "github.com/containerd/containerd/runtime/v2/runc/options"
"github.com/docker/docker/api/types"
containertypes "github.com/docker/docker/api/types/container"
"github.com/docker/docker/daemon/config"
"github.com/docker/docker/pkg/rootless"
"github.com/docker/docker/pkg/sysinfo"
"github.com/pkg/errors"
"github.com/sirupsen/logrus"
)
// fillPlatformInfo fills the platform related info.
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
func (daemon *Daemon) fillPlatformInfo(v *types.Info, sysInfo *sysinfo.SysInfo, cfg *configStore) {
v.CgroupDriver = cgroupDriver(&cfg.Config)
v.CgroupVersion = "1"
if sysInfo.CgroupUnified {
v.CgroupVersion = "2"
}
if v.CgroupDriver != cgroupNoneDriver {
v.MemoryLimit = sysInfo.MemoryLimit
v.SwapLimit = sysInfo.SwapLimit
v.KernelMemory = sysInfo.KernelMemory
v.KernelMemoryTCP = sysInfo.KernelMemoryTCP
v.OomKillDisable = sysInfo.OomKillDisable
v.CPUCfsPeriod = sysInfo.CPUCfs
v.CPUCfsQuota = sysInfo.CPUCfs
v.CPUShares = sysInfo.CPUShares
v.CPUSet = sysInfo.Cpuset
v.PidsLimit = sysInfo.PidsLimit
}
daemon: reload runtimes w/o breaking containers The existing runtimes reload logic went to great lengths to replace the directory containing runtime wrapper scripts as atomically as possible within the limitations of the Linux filesystem ABI. Trouble is, atomically swapping the wrapper scripts directory solves the wrong problem! The runtime configuration is "locked in" when a container is started, including the path to the runC binary. If a container is started with a runtime which requires a daemon-managed wrapper script and then the daemon is reloaded with a config which no longer requires the wrapper script (i.e. some args -> no args, or the runtime is dropped from the config), that container would become unmanageable. Any attempts to stop, exec or otherwise perform lifecycle management operations on the container are likely to fail due to the wrapper script no longer existing at its original path. Atomically swapping the wrapper scripts is also incompatible with the read-copy-update paradigm for reloading configuration. A handler in the daemon could retain a reference to the pre-reload configuration for an indeterminate amount of time after the daemon configuration has been reloaded and updated. It is possible for the daemon to attempt to start a container using a deleted wrapper script if a request to run a container races a reload. Solve the problem of deleting referenced wrapper scripts by ensuring that all wrapper scripts are *immutable* for the lifetime of the daemon process. Any given runtime wrapper script must always exist with the same contents, no matter how many times the daemon config is reloaded, or what changes are made to the config. This is accomplished by using everyone's favourite design pattern: content-addressable storage. Each wrapper script file name is suffixed with the SHA-256 digest of its contents to (probabilistically) guarantee immutability without needing any concurrency control. Stale runtime wrapper scripts are only cleaned up on the next daemon restart. Split the derived runtimes configuration from the user-supplied configuration to have a place to store derived state without mutating the user-supplied configuration or exposing daemon internals in API struct types. Hold the derived state and the user-supplied configuration in a single struct value so that they can be updated as an atomic unit. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 20:12:30 +00:00
v.Runtimes = make(map[string]types.Runtime)
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
for n, p := range stockRuntimes() {
v.Runtimes[n] = types.Runtime{Path: p}
}
for n, r := range cfg.Config.Runtimes {
daemon: reload runtimes w/o breaking containers The existing runtimes reload logic went to great lengths to replace the directory containing runtime wrapper scripts as atomically as possible within the limitations of the Linux filesystem ABI. Trouble is, atomically swapping the wrapper scripts directory solves the wrong problem! The runtime configuration is "locked in" when a container is started, including the path to the runC binary. If a container is started with a runtime which requires a daemon-managed wrapper script and then the daemon is reloaded with a config which no longer requires the wrapper script (i.e. some args -> no args, or the runtime is dropped from the config), that container would become unmanageable. Any attempts to stop, exec or otherwise perform lifecycle management operations on the container are likely to fail due to the wrapper script no longer existing at its original path. Atomically swapping the wrapper scripts is also incompatible with the read-copy-update paradigm for reloading configuration. A handler in the daemon could retain a reference to the pre-reload configuration for an indeterminate amount of time after the daemon configuration has been reloaded and updated. It is possible for the daemon to attempt to start a container using a deleted wrapper script if a request to run a container races a reload. Solve the problem of deleting referenced wrapper scripts by ensuring that all wrapper scripts are *immutable* for the lifetime of the daemon process. Any given runtime wrapper script must always exist with the same contents, no matter how many times the daemon config is reloaded, or what changes are made to the config. This is accomplished by using everyone's favourite design pattern: content-addressable storage. Each wrapper script file name is suffixed with the SHA-256 digest of its contents to (probabilistically) guarantee immutability without needing any concurrency control. Stale runtime wrapper scripts are only cleaned up on the next daemon restart. Split the derived runtimes configuration from the user-supplied configuration to have a place to store derived state without mutating the user-supplied configuration or exposing daemon internals in API struct types. Hold the derived state and the user-supplied configuration in a single struct value so that they can be updated as an atomic unit. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 20:12:30 +00:00
v.Runtimes[n] = types.Runtime{
Path: r.Path,
Args: append([]string(nil), r.Args...),
}
}
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
v.DefaultRuntime = cfg.Runtimes.Default
v.RuncCommit.ID = "N/A"
v.ContainerdCommit.ID = "N/A"
v.InitCommit.ID = "N/A"
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
if _, _, commit, err := parseDefaultRuntimeVersion(&cfg.Runtimes); err != nil {
daemon: reload runtimes w/o breaking containers The existing runtimes reload logic went to great lengths to replace the directory containing runtime wrapper scripts as atomically as possible within the limitations of the Linux filesystem ABI. Trouble is, atomically swapping the wrapper scripts directory solves the wrong problem! The runtime configuration is "locked in" when a container is started, including the path to the runC binary. If a container is started with a runtime which requires a daemon-managed wrapper script and then the daemon is reloaded with a config which no longer requires the wrapper script (i.e. some args -> no args, or the runtime is dropped from the config), that container would become unmanageable. Any attempts to stop, exec or otherwise perform lifecycle management operations on the container are likely to fail due to the wrapper script no longer existing at its original path. Atomically swapping the wrapper scripts is also incompatible with the read-copy-update paradigm for reloading configuration. A handler in the daemon could retain a reference to the pre-reload configuration for an indeterminate amount of time after the daemon configuration has been reloaded and updated. It is possible for the daemon to attempt to start a container using a deleted wrapper script if a request to run a container races a reload. Solve the problem of deleting referenced wrapper scripts by ensuring that all wrapper scripts are *immutable* for the lifetime of the daemon process. Any given runtime wrapper script must always exist with the same contents, no matter how many times the daemon config is reloaded, or what changes are made to the config. This is accomplished by using everyone's favourite design pattern: content-addressable storage. Each wrapper script file name is suffixed with the SHA-256 digest of its contents to (probabilistically) guarantee immutability without needing any concurrency control. Stale runtime wrapper scripts are only cleaned up on the next daemon restart. Split the derived runtimes configuration from the user-supplied configuration to have a place to store derived state without mutating the user-supplied configuration or exposing daemon internals in API struct types. Hold the derived state and the user-supplied configuration in a single struct value so that they can be updated as an atomic unit. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 20:12:30 +00:00
logrus.Warnf(err.Error())
} else {
v.RuncCommit.ID = commit
}
if rv, err := daemon.containerd.Version(context.Background()); err == nil {
v.ContainerdCommit.ID = rv.Revision
} else {
logrus.Warnf("failed to retrieve containerd version: %v", err)
}
v.InitBinary = cfg.GetInitPath()
if initBinary, err := cfg.LookupInitPath(); err != nil {
Prefer loading `docker-init` from an appropriate "libexec" directory The `docker-init` binary is not intended to be a user-facing command, and as such it is more appropriate for it to be found in `/usr/libexec` (or similar) than in `PATH` (see the FHS, especially https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html and https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA). This adjusts the logic for using that configuration option to take this into account and appropriately search for `docker-init` (or the user's configured alternative) in these directories before falling back to the existing `PATH` lookup behavior. This behavior _used_ to exist for the old `dockerinit` binary (of a similar name and used in a similar way but for an alternative purpose), but that behavior was removed in 4357ed4a7363a1032edf93cf03232953c805184f when that older `dockerinit` was also removed. Most of this reasoning _also_ applies to `docker-proxy` (and various `containerd-xxx` binaries such as the shims), but this change does not affect those. It would be relatively straightforward to adapt `LookupInitPath` to be a more generic function such as `libexecLookupPath` or similar if we wanted to explore that. See https://github.com/docker/cli/blob/14482589df194a86b2ee07df643ba3277b40df7d/cli-plugins/manager/manager_unix.go for the related path list in the CLI which loads CLI plugins from a similar set of paths (with a similar rationale - plugin binaries are not typically intended to be run directly by users but rather invoked _via_ the CLI binary). Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
2023-03-22 20:26:43 +00:00
logrus.Warnf("failed to find docker-init: %s", err)
} else if rv, err := exec.Command(initBinary, "--version").Output(); err == nil {
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
if _, commit, err := parseInitVersion(string(rv)); err != nil {
Prefer loading `docker-init` from an appropriate "libexec" directory The `docker-init` binary is not intended to be a user-facing command, and as such it is more appropriate for it to be found in `/usr/libexec` (or similar) than in `PATH` (see the FHS, especially https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html and https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA). This adjusts the logic for using that configuration option to take this into account and appropriately search for `docker-init` (or the user's configured alternative) in these directories before falling back to the existing `PATH` lookup behavior. This behavior _used_ to exist for the old `dockerinit` binary (of a similar name and used in a similar way but for an alternative purpose), but that behavior was removed in 4357ed4a7363a1032edf93cf03232953c805184f when that older `dockerinit` was also removed. Most of this reasoning _also_ applies to `docker-proxy` (and various `containerd-xxx` binaries such as the shims), but this change does not affect those. It would be relatively straightforward to adapt `LookupInitPath` to be a more generic function such as `libexecLookupPath` or similar if we wanted to explore that. See https://github.com/docker/cli/blob/14482589df194a86b2ee07df643ba3277b40df7d/cli-plugins/manager/manager_unix.go for the related path list in the CLI which loads CLI plugins from a similar set of paths (with a similar rationale - plugin binaries are not typically intended to be run directly by users but rather invoked _via_ the CLI binary). Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
2023-03-22 20:26:43 +00:00
logrus.Warnf("failed to parse %s version: %s", initBinary, err)
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
} else {
v.InitCommit.ID = commit
}
} else {
Prefer loading `docker-init` from an appropriate "libexec" directory The `docker-init` binary is not intended to be a user-facing command, and as such it is more appropriate for it to be found in `/usr/libexec` (or similar) than in `PATH` (see the FHS, especially https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html and https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA). This adjusts the logic for using that configuration option to take this into account and appropriately search for `docker-init` (or the user's configured alternative) in these directories before falling back to the existing `PATH` lookup behavior. This behavior _used_ to exist for the old `dockerinit` binary (of a similar name and used in a similar way but for an alternative purpose), but that behavior was removed in 4357ed4a7363a1032edf93cf03232953c805184f when that older `dockerinit` was also removed. Most of this reasoning _also_ applies to `docker-proxy` (and various `containerd-xxx` binaries such as the shims), but this change does not affect those. It would be relatively straightforward to adapt `LookupInitPath` to be a more generic function such as `libexecLookupPath` or similar if we wanted to explore that. See https://github.com/docker/cli/blob/14482589df194a86b2ee07df643ba3277b40df7d/cli-plugins/manager/manager_unix.go for the related path list in the CLI which loads CLI plugins from a similar set of paths (with a similar rationale - plugin binaries are not typically intended to be run directly by users but rather invoked _via_ the CLI binary). Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
2023-03-22 20:26:43 +00:00
logrus.Warnf("failed to retrieve %s version: %s", initBinary, err)
}
Add "Warnings" to /info endpoint, and move detection to the daemon When requesting information about the daemon's configuration through the `/info` endpoint, missing features (or non-recommended settings) may have to be presented to the user. Detecting these situations, and printing warnings currently is handled by the cli, which results in some complications: - duplicated effort: each client has to re-implement detection and warnings. - it's not possible to generate warnings for reasons outside of the information returned in the `/info` response. - cli-side detection has to be updated for new conditions. This means that an older cli connecting to a new daemon may not print all warnings (due to it not detecting the new conditions) - some warnings (in particular, warnings about storage-drivers) depend on driver-status (`DriverStatus`) information. The format of the information returned in this field is not part of the API specification and can change over time, resulting in cli-side detection no longer being functional. This patch adds a new `Warnings` field to the `/info` response. This field is to return warnings to be presented by the user. Existing warnings that are currently handled by the CLI are copied to the daemon as part of this patch; This change is backward-compatible with existing clients; old client can continue to use the client-side warnings, whereas new clients can skip client-side detection, and print warnings that are returned by the daemon. Example response with this patch applied; ```bash curl --unix-socket /var/run/docker.sock http://localhost/info | jq .Warnings ``` ```json [ "WARNING: bridge-nf-call-iptables is disabled", "WARNING: bridge-nf-call-ip6tables is disabled" ] ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-07-19 11:45:32 +00:00
// Set expected and actual commits to the same value to prevent the client
// showing that the version does not match the "expected" version/commit.
v.RuncCommit.Expected = v.RuncCommit.ID
v.ContainerdCommit.Expected = v.ContainerdCommit.ID
v.InitCommit.Expected = v.InitCommit.ID
if v.CgroupDriver == cgroupNoneDriver {
if v.CgroupVersion == "2" {
v.Warnings = append(v.Warnings, "WARNING: Running in rootless-mode without cgroups. Systemd is required to enable cgroups in rootless-mode.")
} else {
v.Warnings = append(v.Warnings, "WARNING: Running in rootless-mode without cgroups. To enable cgroups in rootless-mode, you need to boot the system in cgroup v2 mode.")
}
} else {
if !v.MemoryLimit {
v.Warnings = append(v.Warnings, "WARNING: No memory limit support")
}
if !v.SwapLimit {
v.Warnings = append(v.Warnings, "WARNING: No swap limit support")
}
if !v.KernelMemoryTCP && v.CgroupVersion == "1" {
// kernel memory is not available for cgroup v2.
// Warning is not printed on cgroup v2, because there is no action user can take.
v.Warnings = append(v.Warnings, "WARNING: No kernel memory TCP limit support")
}
if !v.OomKillDisable && v.CgroupVersion == "1" {
// oom kill disable is not available for cgroup v2.
// Warning is not printed on cgroup v2, because there is no action user can take.
v.Warnings = append(v.Warnings, "WARNING: No oom kill disable support")
}
if !v.CPUCfsQuota {
v.Warnings = append(v.Warnings, "WARNING: No cpu cfs quota support")
}
if !v.CPUCfsPeriod {
v.Warnings = append(v.Warnings, "WARNING: No cpu cfs period support")
}
if !v.CPUShares {
v.Warnings = append(v.Warnings, "WARNING: No cpu shares support")
}
if !v.CPUSet {
v.Warnings = append(v.Warnings, "WARNING: No cpuset support")
}
// TODO add fields for these options in types.Info
if !sysInfo.BlkioWeight && v.CgroupVersion == "2" {
// blkio weight is not available on cgroup v1 since kernel 5.0.
// Warning is not printed on cgroup v1, because there is no action user can take.
// On cgroup v2, blkio weight is implemented using io.weight
v.Warnings = append(v.Warnings, "WARNING: No io.weight support")
}
if !sysInfo.BlkioWeightDevice && v.CgroupVersion == "2" {
v.Warnings = append(v.Warnings, "WARNING: No io.weight (per device) support")
}
if !sysInfo.BlkioReadBpsDevice {
if v.CgroupVersion == "2" {
v.Warnings = append(v.Warnings, "WARNING: No io.max (rbps) support")
} else {
v.Warnings = append(v.Warnings, "WARNING: No blkio throttle.read_bps_device support")
}
}
if !sysInfo.BlkioWriteBpsDevice {
if v.CgroupVersion == "2" {
v.Warnings = append(v.Warnings, "WARNING: No io.max (wbps) support")
} else {
v.Warnings = append(v.Warnings, "WARNING: No blkio throttle.write_bps_device support")
}
}
if !sysInfo.BlkioReadIOpsDevice {
if v.CgroupVersion == "2" {
v.Warnings = append(v.Warnings, "WARNING: No io.max (riops) support")
} else {
v.Warnings = append(v.Warnings, "WARNING: No blkio throttle.read_iops_device support")
}
}
if !sysInfo.BlkioWriteIOpsDevice {
if v.CgroupVersion == "2" {
v.Warnings = append(v.Warnings, "WARNING: No io.max (wiops) support")
} else {
v.Warnings = append(v.Warnings, "WARNING: No blkio throttle.write_iops_device support")
}
}
Add "Warnings" to /info endpoint, and move detection to the daemon When requesting information about the daemon's configuration through the `/info` endpoint, missing features (or non-recommended settings) may have to be presented to the user. Detecting these situations, and printing warnings currently is handled by the cli, which results in some complications: - duplicated effort: each client has to re-implement detection and warnings. - it's not possible to generate warnings for reasons outside of the information returned in the `/info` response. - cli-side detection has to be updated for new conditions. This means that an older cli connecting to a new daemon may not print all warnings (due to it not detecting the new conditions) - some warnings (in particular, warnings about storage-drivers) depend on driver-status (`DriverStatus`) information. The format of the information returned in this field is not part of the API specification and can change over time, resulting in cli-side detection no longer being functional. This patch adds a new `Warnings` field to the `/info` response. This field is to return warnings to be presented by the user. Existing warnings that are currently handled by the CLI are copied to the daemon as part of this patch; This change is backward-compatible with existing clients; old client can continue to use the client-side warnings, whereas new clients can skip client-side detection, and print warnings that are returned by the daemon. Example response with this patch applied; ```bash curl --unix-socket /var/run/docker.sock http://localhost/info | jq .Warnings ``` ```json [ "WARNING: bridge-nf-call-iptables is disabled", "WARNING: bridge-nf-call-ip6tables is disabled" ] ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-07-19 11:45:32 +00:00
}
if !v.IPv4Forwarding {
v.Warnings = append(v.Warnings, "WARNING: IPv4 forwarding is disabled")
}
if !v.BridgeNfIptables {
v.Warnings = append(v.Warnings, "WARNING: bridge-nf-call-iptables is disabled")
}
if !v.BridgeNfIP6tables {
v.Warnings = append(v.Warnings, "WARNING: bridge-nf-call-ip6tables is disabled")
}
}
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
func (daemon *Daemon) fillPlatformVersion(v *types.Version, cfg *configStore) {
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
if rv, err := daemon.containerd.Version(context.Background()); err == nil {
v.Components = append(v.Components, types.ComponentVersion{
Name: "containerd",
Version: rv.Version,
Details: map[string]string{
"GitCommit": rv.Revision,
},
})
}
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
if _, ver, commit, err := parseDefaultRuntimeVersion(&cfg.Runtimes); err != nil {
daemon: reload runtimes w/o breaking containers The existing runtimes reload logic went to great lengths to replace the directory containing runtime wrapper scripts as atomically as possible within the limitations of the Linux filesystem ABI. Trouble is, atomically swapping the wrapper scripts directory solves the wrong problem! The runtime configuration is "locked in" when a container is started, including the path to the runC binary. If a container is started with a runtime which requires a daemon-managed wrapper script and then the daemon is reloaded with a config which no longer requires the wrapper script (i.e. some args -> no args, or the runtime is dropped from the config), that container would become unmanageable. Any attempts to stop, exec or otherwise perform lifecycle management operations on the container are likely to fail due to the wrapper script no longer existing at its original path. Atomically swapping the wrapper scripts is also incompatible with the read-copy-update paradigm for reloading configuration. A handler in the daemon could retain a reference to the pre-reload configuration for an indeterminate amount of time after the daemon configuration has been reloaded and updated. It is possible for the daemon to attempt to start a container using a deleted wrapper script if a request to run a container races a reload. Solve the problem of deleting referenced wrapper scripts by ensuring that all wrapper scripts are *immutable* for the lifetime of the daemon process. Any given runtime wrapper script must always exist with the same contents, no matter how many times the daemon config is reloaded, or what changes are made to the config. This is accomplished by using everyone's favourite design pattern: content-addressable storage. Each wrapper script file name is suffixed with the SHA-256 digest of its contents to (probabilistically) guarantee immutability without needing any concurrency control. Stale runtime wrapper scripts are only cleaned up on the next daemon restart. Split the derived runtimes configuration from the user-supplied configuration to have a place to store derived state without mutating the user-supplied configuration or exposing daemon internals in API struct types. Hold the derived state and the user-supplied configuration in a single struct value so that they can be updated as an atomic unit. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 20:12:30 +00:00
logrus.Warnf(err.Error())
} else {
v.Components = append(v.Components, types.ComponentVersion{
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
Name: cfg.Runtimes.Default,
daemon: reload runtimes w/o breaking containers The existing runtimes reload logic went to great lengths to replace the directory containing runtime wrapper scripts as atomically as possible within the limitations of the Linux filesystem ABI. Trouble is, atomically swapping the wrapper scripts directory solves the wrong problem! The runtime configuration is "locked in" when a container is started, including the path to the runC binary. If a container is started with a runtime which requires a daemon-managed wrapper script and then the daemon is reloaded with a config which no longer requires the wrapper script (i.e. some args -> no args, or the runtime is dropped from the config), that container would become unmanageable. Any attempts to stop, exec or otherwise perform lifecycle management operations on the container are likely to fail due to the wrapper script no longer existing at its original path. Atomically swapping the wrapper scripts is also incompatible with the read-copy-update paradigm for reloading configuration. A handler in the daemon could retain a reference to the pre-reload configuration for an indeterminate amount of time after the daemon configuration has been reloaded and updated. It is possible for the daemon to attempt to start a container using a deleted wrapper script if a request to run a container races a reload. Solve the problem of deleting referenced wrapper scripts by ensuring that all wrapper scripts are *immutable* for the lifetime of the daemon process. Any given runtime wrapper script must always exist with the same contents, no matter how many times the daemon config is reloaded, or what changes are made to the config. This is accomplished by using everyone's favourite design pattern: content-addressable storage. Each wrapper script file name is suffixed with the SHA-256 digest of its contents to (probabilistically) guarantee immutability without needing any concurrency control. Stale runtime wrapper scripts are only cleaned up on the next daemon restart. Split the derived runtimes configuration from the user-supplied configuration to have a place to store derived state without mutating the user-supplied configuration or exposing daemon internals in API struct types. Hold the derived state and the user-supplied configuration in a single struct value so that they can be updated as an atomic unit. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 20:12:30 +00:00
Version: ver,
Details: map[string]string{
"GitCommit": commit,
},
})
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
}
if initBinary, err := cfg.LookupInitPath(); err != nil {
Prefer loading `docker-init` from an appropriate "libexec" directory The `docker-init` binary is not intended to be a user-facing command, and as such it is more appropriate for it to be found in `/usr/libexec` (or similar) than in `PATH` (see the FHS, especially https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html and https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA). This adjusts the logic for using that configuration option to take this into account and appropriately search for `docker-init` (or the user's configured alternative) in these directories before falling back to the existing `PATH` lookup behavior. This behavior _used_ to exist for the old `dockerinit` binary (of a similar name and used in a similar way but for an alternative purpose), but that behavior was removed in 4357ed4a7363a1032edf93cf03232953c805184f when that older `dockerinit` was also removed. Most of this reasoning _also_ applies to `docker-proxy` (and various `containerd-xxx` binaries such as the shims), but this change does not affect those. It would be relatively straightforward to adapt `LookupInitPath` to be a more generic function such as `libexecLookupPath` or similar if we wanted to explore that. See https://github.com/docker/cli/blob/14482589df194a86b2ee07df643ba3277b40df7d/cli-plugins/manager/manager_unix.go for the related path list in the CLI which loads CLI plugins from a similar set of paths (with a similar rationale - plugin binaries are not typically intended to be run directly by users but rather invoked _via_ the CLI binary). Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
2023-03-22 20:26:43 +00:00
logrus.Warnf("failed to find docker-init: %s", err)
} else if rv, err := exec.Command(initBinary, "--version").Output(); err == nil {
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
if ver, commit, err := parseInitVersion(string(rv)); err != nil {
Prefer loading `docker-init` from an appropriate "libexec" directory The `docker-init` binary is not intended to be a user-facing command, and as such it is more appropriate for it to be found in `/usr/libexec` (or similar) than in `PATH` (see the FHS, especially https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html and https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA). This adjusts the logic for using that configuration option to take this into account and appropriately search for `docker-init` (or the user's configured alternative) in these directories before falling back to the existing `PATH` lookup behavior. This behavior _used_ to exist for the old `dockerinit` binary (of a similar name and used in a similar way but for an alternative purpose), but that behavior was removed in 4357ed4a7363a1032edf93cf03232953c805184f when that older `dockerinit` was also removed. Most of this reasoning _also_ applies to `docker-proxy` (and various `containerd-xxx` binaries such as the shims), but this change does not affect those. It would be relatively straightforward to adapt `LookupInitPath` to be a more generic function such as `libexecLookupPath` or similar if we wanted to explore that. See https://github.com/docker/cli/blob/14482589df194a86b2ee07df643ba3277b40df7d/cli-plugins/manager/manager_unix.go for the related path list in the CLI which loads CLI plugins from a similar set of paths (with a similar rationale - plugin binaries are not typically intended to be run directly by users but rather invoked _via_ the CLI binary). Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
2023-03-22 20:26:43 +00:00
logrus.Warnf("failed to parse %s version: %s", initBinary, err)
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
} else {
v.Components = append(v.Components, types.ComponentVersion{
Prefer loading `docker-init` from an appropriate "libexec" directory The `docker-init` binary is not intended to be a user-facing command, and as such it is more appropriate for it to be found in `/usr/libexec` (or similar) than in `PATH` (see the FHS, especially https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html and https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA). This adjusts the logic for using that configuration option to take this into account and appropriately search for `docker-init` (or the user's configured alternative) in these directories before falling back to the existing `PATH` lookup behavior. This behavior _used_ to exist for the old `dockerinit` binary (of a similar name and used in a similar way but for an alternative purpose), but that behavior was removed in 4357ed4a7363a1032edf93cf03232953c805184f when that older `dockerinit` was also removed. Most of this reasoning _also_ applies to `docker-proxy` (and various `containerd-xxx` binaries such as the shims), but this change does not affect those. It would be relatively straightforward to adapt `LookupInitPath` to be a more generic function such as `libexecLookupPath` or similar if we wanted to explore that. See https://github.com/docker/cli/blob/14482589df194a86b2ee07df643ba3277b40df7d/cli-plugins/manager/manager_unix.go for the related path list in the CLI which loads CLI plugins from a similar set of paths (with a similar rationale - plugin binaries are not typically intended to be run directly by users but rather invoked _via_ the CLI binary). Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
2023-03-22 20:26:43 +00:00
Name: filepath.Base(initBinary),
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
Version: ver,
Details: map[string]string{
"GitCommit": commit,
},
})
}
} else {
Prefer loading `docker-init` from an appropriate "libexec" directory The `docker-init` binary is not intended to be a user-facing command, and as such it is more appropriate for it to be found in `/usr/libexec` (or similar) than in `PATH` (see the FHS, especially https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html and https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA). This adjusts the logic for using that configuration option to take this into account and appropriately search for `docker-init` (or the user's configured alternative) in these directories before falling back to the existing `PATH` lookup behavior. This behavior _used_ to exist for the old `dockerinit` binary (of a similar name and used in a similar way but for an alternative purpose), but that behavior was removed in 4357ed4a7363a1032edf93cf03232953c805184f when that older `dockerinit` was also removed. Most of this reasoning _also_ applies to `docker-proxy` (and various `containerd-xxx` binaries such as the shims), but this change does not affect those. It would be relatively straightforward to adapt `LookupInitPath` to be a more generic function such as `libexecLookupPath` or similar if we wanted to explore that. See https://github.com/docker/cli/blob/14482589df194a86b2ee07df643ba3277b40df7d/cli-plugins/manager/manager_unix.go for the related path list in the CLI which loads CLI plugins from a similar set of paths (with a similar rationale - plugin binaries are not typically intended to be run directly by users but rather invoked _via_ the CLI binary). Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
2023-03-22 20:26:43 +00:00
logrus.Warnf("failed to retrieve %s version: %s", initBinary, err)
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
}
daemon.fillRootlessVersion(v)
}
func (daemon *Daemon) fillRootlessVersion(v *types.Version) {
if !rootless.RunningWithRootlessKit() {
return
}
rlc, err := rootless.GetRootlessKitClient()
if err != nil {
logrus.Warnf("failed to create RootlessKit client: %v", err)
return
}
rlInfo, err := rlc.Info(context.TODO())
if err != nil {
logrus.Warnf("failed to retrieve RootlessKit version: %v", err)
return
}
v.Components = append(v.Components, types.ComponentVersion{
Name: "rootlesskit",
Version: rlInfo.Version,
Details: map[string]string{
"ApiVersion": rlInfo.APIVersion,
"StateDir": rlInfo.StateDir,
"NetworkDriver": rlInfo.NetworkDriver.Driver,
"PortDriver": rlInfo.PortDriver.Driver,
},
})
switch rlInfo.NetworkDriver.Driver {
case "slirp4netns":
if rv, err := exec.Command("slirp4netns", "--version").Output(); err == nil {
if _, ver, commit, err := parseRuntimeVersion(string(rv)); err != nil {
logrus.Warnf("failed to parse slirp4netns version: %v", err)
} else {
v.Components = append(v.Components, types.ComponentVersion{
Name: "slirp4netns",
Version: ver,
Details: map[string]string{
"GitCommit": commit,
},
})
}
} else {
logrus.Warnf("failed to retrieve slirp4netns version: %v", err)
}
case "vpnkit":
if rv, err := exec.Command("vpnkit", "--version").Output(); err == nil {
v.Components = append(v.Components, types.ComponentVersion{
Name: "vpnkit",
Version: strings.TrimSpace(string(rv)),
})
} else {
logrus.Warnf("failed to retrieve vpnkit version: %v", err)
}
}
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
}
Add "Warnings" to /info endpoint, and move detection to the daemon When requesting information about the daemon's configuration through the `/info` endpoint, missing features (or non-recommended settings) may have to be presented to the user. Detecting these situations, and printing warnings currently is handled by the cli, which results in some complications: - duplicated effort: each client has to re-implement detection and warnings. - it's not possible to generate warnings for reasons outside of the information returned in the `/info` response. - cli-side detection has to be updated for new conditions. This means that an older cli connecting to a new daemon may not print all warnings (due to it not detecting the new conditions) - some warnings (in particular, warnings about storage-drivers) depend on driver-status (`DriverStatus`) information. The format of the information returned in this field is not part of the API specification and can change over time, resulting in cli-side detection no longer being functional. This patch adds a new `Warnings` field to the `/info` response. This field is to return warnings to be presented by the user. Existing warnings that are currently handled by the CLI are copied to the daemon as part of this patch; This change is backward-compatible with existing clients; old client can continue to use the client-side warnings, whereas new clients can skip client-side detection, and print warnings that are returned by the daemon. Example response with this patch applied; ```bash curl --unix-socket /var/run/docker.sock http://localhost/info | jq .Warnings ``` ```json [ "WARNING: bridge-nf-call-iptables is disabled", "WARNING: bridge-nf-call-ip6tables is disabled" ] ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-07-19 11:45:32 +00:00
func fillDriverWarnings(v *types.Info) {
for _, pair := range v.DriverStatus {
if pair[0] == "Extended file attributes" && pair[1] == "best-effort" {
msg := fmt.Sprintf("WARNING: %s: extended file attributes from container images "+
"will be silently discarded if the backing filesystem does not support them.\n"+
" CONTAINERS MAY MALFUNCTION IF EXTENDED ATTRIBUTES ARE MISSING.\n"+
" This is an UNSUPPORTABLE configuration for which no bug reports will be accepted.\n", v.Driver)
Add "Warnings" to /info endpoint, and move detection to the daemon When requesting information about the daemon's configuration through the `/info` endpoint, missing features (or non-recommended settings) may have to be presented to the user. Detecting these situations, and printing warnings currently is handled by the cli, which results in some complications: - duplicated effort: each client has to re-implement detection and warnings. - it's not possible to generate warnings for reasons outside of the information returned in the `/info` response. - cli-side detection has to be updated for new conditions. This means that an older cli connecting to a new daemon may not print all warnings (due to it not detecting the new conditions) - some warnings (in particular, warnings about storage-drivers) depend on driver-status (`DriverStatus`) information. The format of the information returned in this field is not part of the API specification and can change over time, resulting in cli-side detection no longer being functional. This patch adds a new `Warnings` field to the `/info` response. This field is to return warnings to be presented by the user. Existing warnings that are currently handled by the CLI are copied to the daemon as part of this patch; This change is backward-compatible with existing clients; old client can continue to use the client-side warnings, whereas new clients can skip client-side detection, and print warnings that are returned by the daemon. Example response with this patch applied; ```bash curl --unix-socket /var/run/docker.sock http://localhost/info | jq .Warnings ``` ```json [ "WARNING: bridge-nf-call-iptables is disabled", "WARNING: bridge-nf-call-ip6tables is disabled" ] ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-07-19 11:45:32 +00:00
v.Warnings = append(v.Warnings, msg)
continue
}
}
}
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
// parseInitVersion parses a Tini version string, and extracts the "version"
// and "git commit" from the output.
//
// Output example from `docker-init --version`:
//
// tini version 0.18.0 - git.fec3683
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
func parseInitVersion(v string) (version string, commit string, err error) {
parts := strings.Split(v, " - ")
if len(parts) >= 2 {
gitParts := strings.Split(strings.TrimSpace(parts[1]), ".")
if len(gitParts) == 2 && gitParts[0] == "git" {
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
commit = gitParts[1]
}
}
parts[0] = strings.TrimSpace(parts[0])
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
if strings.HasPrefix(parts[0], "tini version ") {
version = strings.TrimPrefix(parts[0], "tini version ")
}
if version == "" && commit == "" {
err = errors.Errorf("unknown output format: %s", v)
}
return version, commit, err
}
// parseRuntimeVersion parses the output of `[runtime] --version` and extracts the
// "name", "version" and "git commit" from the output.
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
//
// Output example from `runc --version`:
//
// runc version 1.0.0-rc5+dev
// commit: 69663f0bd4b60df09991c08812a60108003fa340
// spec: 1.0.0
daemon: reload runtimes w/o breaking containers The existing runtimes reload logic went to great lengths to replace the directory containing runtime wrapper scripts as atomically as possible within the limitations of the Linux filesystem ABI. Trouble is, atomically swapping the wrapper scripts directory solves the wrong problem! The runtime configuration is "locked in" when a container is started, including the path to the runC binary. If a container is started with a runtime which requires a daemon-managed wrapper script and then the daemon is reloaded with a config which no longer requires the wrapper script (i.e. some args -> no args, or the runtime is dropped from the config), that container would become unmanageable. Any attempts to stop, exec or otherwise perform lifecycle management operations on the container are likely to fail due to the wrapper script no longer existing at its original path. Atomically swapping the wrapper scripts is also incompatible with the read-copy-update paradigm for reloading configuration. A handler in the daemon could retain a reference to the pre-reload configuration for an indeterminate amount of time after the daemon configuration has been reloaded and updated. It is possible for the daemon to attempt to start a container using a deleted wrapper script if a request to run a container races a reload. Solve the problem of deleting referenced wrapper scripts by ensuring that all wrapper scripts are *immutable* for the lifetime of the daemon process. Any given runtime wrapper script must always exist with the same contents, no matter how many times the daemon config is reloaded, or what changes are made to the config. This is accomplished by using everyone's favourite design pattern: content-addressable storage. Each wrapper script file name is suffixed with the SHA-256 digest of its contents to (probabilistically) guarantee immutability without needing any concurrency control. Stale runtime wrapper scripts are only cleaned up on the next daemon restart. Split the derived runtimes configuration from the user-supplied configuration to have a place to store derived state without mutating the user-supplied configuration or exposing daemon internals in API struct types. Hold the derived state and the user-supplied configuration in a single struct value so that they can be updated as an atomic unit. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 20:12:30 +00:00
func parseRuntimeVersion(v string) (runtime, version, commit string, err error) {
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
lines := strings.Split(strings.TrimSpace(v), "\n")
for _, line := range lines {
if strings.Contains(line, "version") {
s := strings.Split(line, "version")
runtime = strings.TrimSpace(s[0])
version = strings.TrimSpace(s[len(s)-1])
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
continue
}
if strings.HasPrefix(line, "commit:") {
commit = strings.TrimSpace(strings.TrimPrefix(line, "commit:"))
continue
}
}
Add containerd, runc, and docker-init versions to /version This patch adds version information about the containerd, runc, and docker-init components to the /version endpoint. With this patch applied, running: ``` curl --unix-socket /var/run/docker.sock http://localhost/version | jq . ``` Will produce this response: ```json { "Platform": { "Name": "" }, "Components": [ { "Name": "Engine", "Version": "dev", "Details": { "ApiVersion": "1.40", "Arch": "amd64", "BuildTime": "2018-11-08T10:23:42.000000000+00:00", "Experimental": "false", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "KernelVersion": "4.9.93-linuxkit-aufs", "MinAPIVersion": "1.12", "Os": "linux" } }, { "Name": "containerd", "Version": "v1.1.4", "Details": { "GitCommit": "9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b" } }, { "Name": "runc", "Version": "1.0.0-rc5+dev", "Details": { "GitCommit": "a00bf0190895aa465a5fbed0268888e2c8ddfe85" } }, { "Name": "docker-init", "Version": "0.18.0", "Details": { "GitCommit": "fec3683" } } ], "Version": "dev", "ApiVersion": "1.40", "MinAPIVersion": "1.12", "GitCommit": "7d02782d2f", "GoVersion": "go1.11.2", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.9.93-linuxkit-aufs", "BuildTime": "2018-11-08T10:23:42.000000000+00:00" } ``` When using a recent version of the CLI, that information is included in the output of `docker version`: ``` Client: Docker Engine - Community Version: 18.09.0 API version: 1.39 Go version: go1.10.4 Git commit: 4d60db4 Built: Wed Nov 7 00:46:51 2018 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: dev API version: 1.40 (minimum version 1.12) Go version: go1.11.2 Git commit: 7d02782d2f Built: Thu Nov 8 10:23:42 2018 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.1.4 GitCommit: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b runc: Version: 1.0.0-rc5+dev GitCommit: a00bf0190895aa465a5fbed0268888e2c8ddfe85 docker-init: Version: 0.18.0 GitCommit: fec3683 ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-10-05 10:30:10 +00:00
if version == "" && commit == "" {
err = errors.Errorf("unknown output format: %s", v)
}
return runtime, version, commit, err
}
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
func parseDefaultRuntimeVersion(rts *runtimes) (runtime, version, commit string, err error) {
shim, opts, err := rts.Get(rts.Default)
if err != nil {
return "", "", "", err
}
shimopts, ok := opts.(*v2runcoptions.Options)
if !ok {
return "", "", "", fmt.Errorf("%s: retrieving version not supported", shim)
}
rt := shimopts.BinaryName
if rt == "" {
rt = defaultRuntimeName
daemon: reload runtimes w/o breaking containers The existing runtimes reload logic went to great lengths to replace the directory containing runtime wrapper scripts as atomically as possible within the limitations of the Linux filesystem ABI. Trouble is, atomically swapping the wrapper scripts directory solves the wrong problem! The runtime configuration is "locked in" when a container is started, including the path to the runC binary. If a container is started with a runtime which requires a daemon-managed wrapper script and then the daemon is reloaded with a config which no longer requires the wrapper script (i.e. some args -> no args, or the runtime is dropped from the config), that container would become unmanageable. Any attempts to stop, exec or otherwise perform lifecycle management operations on the container are likely to fail due to the wrapper script no longer existing at its original path. Atomically swapping the wrapper scripts is also incompatible with the read-copy-update paradigm for reloading configuration. A handler in the daemon could retain a reference to the pre-reload configuration for an indeterminate amount of time after the daemon configuration has been reloaded and updated. It is possible for the daemon to attempt to start a container using a deleted wrapper script if a request to run a container races a reload. Solve the problem of deleting referenced wrapper scripts by ensuring that all wrapper scripts are *immutable* for the lifetime of the daemon process. Any given runtime wrapper script must always exist with the same contents, no matter how many times the daemon config is reloaded, or what changes are made to the config. This is accomplished by using everyone's favourite design pattern: content-addressable storage. Each wrapper script file name is suffixed with the SHA-256 digest of its contents to (probabilistically) guarantee immutability without needing any concurrency control. Stale runtime wrapper scripts are only cleaned up on the next daemon restart. Split the derived runtimes configuration from the user-supplied configuration to have a place to store derived state without mutating the user-supplied configuration or exposing daemon internals in API struct types. Hold the derived state and the user-supplied configuration in a single struct value so that they can be updated as an atomic unit. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 20:12:30 +00:00
}
daemon: consolidate runtimes config validation The daemon has made a habit of mutating the DefaultRuntime and Runtimes values in the Config struct to merge defaults. This would be fine if it was a part of the regular configuration loading and merging process, as is done with other config options. The trouble is it does so in surprising places, such as in functions with 'verify' or 'validate' in their name. It has been necessary in order to validate that the user has not defined a custom runtime named "runc" which would shadow the built-in runtime of the same name. Other daemon code depends on the runtime named "runc" always being defined in the config, but merging it with the user config at the same time as the other defaults are merged would trip the validation. The root of the issue is that the daemon has used the same config values for both validating the daemon runtime configuration as supplied by the user and for keeping track of which runtimes have been set up by the daemon. Now that a completely separate value is used for the latter purpose, surprising contortions are no longer required to make the validation work as intended. Consolidate the validation of the runtimes config and merging of the built-in runtimes into the daemon.setupRuntimes() function. Set the result of merging the built-in runtimes config and default default runtime on the returned runtimes struct, without back-propagating it onto the config.Config argument. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 21:24:22 +00:00
rv, err := exec.Command(rt, "--version").Output()
if err != nil {
return "", "", "", fmt.Errorf("failed to retrieve %s version: %w", rt, err)
}
runtime, version, commit, err = parseRuntimeVersion(string(rv))
if err != nil {
return "", "", "", fmt.Errorf("failed to parse %s version: %w", rt, err)
}
return runtime, version, commit, err
daemon: reload runtimes w/o breaking containers The existing runtimes reload logic went to great lengths to replace the directory containing runtime wrapper scripts as atomically as possible within the limitations of the Linux filesystem ABI. Trouble is, atomically swapping the wrapper scripts directory solves the wrong problem! The runtime configuration is "locked in" when a container is started, including the path to the runC binary. If a container is started with a runtime which requires a daemon-managed wrapper script and then the daemon is reloaded with a config which no longer requires the wrapper script (i.e. some args -> no args, or the runtime is dropped from the config), that container would become unmanageable. Any attempts to stop, exec or otherwise perform lifecycle management operations on the container are likely to fail due to the wrapper script no longer existing at its original path. Atomically swapping the wrapper scripts is also incompatible with the read-copy-update paradigm for reloading configuration. A handler in the daemon could retain a reference to the pre-reload configuration for an indeterminate amount of time after the daemon configuration has been reloaded and updated. It is possible for the daemon to attempt to start a container using a deleted wrapper script if a request to run a container races a reload. Solve the problem of deleting referenced wrapper scripts by ensuring that all wrapper scripts are *immutable* for the lifetime of the daemon process. Any given runtime wrapper script must always exist with the same contents, no matter how many times the daemon config is reloaded, or what changes are made to the config. This is accomplished by using everyone's favourite design pattern: content-addressable storage. Each wrapper script file name is suffixed with the SHA-256 digest of its contents to (probabilistically) guarantee immutability without needing any concurrency control. Stale runtime wrapper scripts are only cleaned up on the next daemon restart. Split the derived runtimes configuration from the user-supplied configuration to have a place to store derived state without mutating the user-supplied configuration or exposing daemon internals in API struct types. Hold the derived state and the user-supplied configuration in a single struct value so that they can be updated as an atomic unit. Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-08-31 20:12:30 +00:00
}
func cgroupNamespacesEnabled(sysInfo *sysinfo.SysInfo, cfg *config.Config) bool {
return sysInfo.CgroupNamespaces && containertypes.CgroupnsMode(cfg.CgroupNamespaceMode).IsPrivate()
}
// Rootless returns true if daemon is running in rootless mode
func Rootless(cfg *config.Config) bool {
return cfg.Rootless
}
func noNewPrivileges(cfg *config.Config) bool {
return cfg.NoNewPrivileges
}