Commit Graph

77 Commits

Author SHA1 Message Date
Sebastiaan van Stijn 7d92573852
Merge pull request #4599 from laurazard/plugin-signal-handling
cli-plugins: terminate plugin when CLI exits
2023-12-12 14:58:04 +01:00
Laura Brehm 1554ac3b5f
cli-plugins: terminate plugin when CLI exits
Previously, long lived CLI plugin processes weren't
properly handled
(see: https://github.com/docker/cli/issues/4402)
resulting in plugin processes being left behind
running, after the CLI process exits.

This commit changes the plugin handling code to open
an abstract unix socket before running the plugin and
passing it to the plugin process, and changes the
signal handling on the CLI side to close this socket
which tells the plugin that it should exit.

This implementation makes use of sockets instead of
simply setting PDEATHSIG on the plugin process
so that it will work on both BSDs, assorted UNIXes
and Windows.

Signed-off-by: Laura Brehm <laurabrehm@hey.com>
2023-12-12 13:54:30 +00:00
Sebastiaan van Stijn 8e9aec6904
golangci-lint: revive: enable import-shadowing
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-11-20 19:52:41 +01:00
Sebastiaan van Stijn febb37a38e
remove buildkit as dependency
This copies the github.com/moby/buildkit/util/appcontext
package as an internal package. The appcontext package from
BuildKit was the only remaining dependency on BuildKit, and
while we may need some of its functionality, the implementation
is not correct for how it's used in docker/cli (so would need
a rewrite).

Moving a copy of the code into the docker/cli (but as internal
package to prevent others from depending on it) is a first step
in that process, and removes the circular dependency between
BuildKit and the CLi.

We are only using these:

    tree vendor/github.com/moby/buildkit
    vendor/github.com/moby/buildkit
    ├── AUTHORS
    ├── LICENSE
    └── util
        └── appcontext
            ├── appcontext.go
            ├── appcontext_unix.go
            ├── appcontext_windows.go
            └── register.go

    3 directories, 6 files

Before this:

    go mod graph | grep ' github.com/docker/cli'
    github.com/moby/buildkit@v0.11.6 github.com/docker/cli@v23.0.0-rc.1+incompatible

After this:

    go mod graph | grep ' github.com/docker/cli'
    # (nothing)

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-09-28 00:04:51 +02:00
Sebastiaan van Stijn bb57783ab8
cmd/docker: areFlagsSupported: don't Ping if not needed
This is a similar fix as 006c946389, which
fixed this for detection of commands that were executed. Make sure we don't
call the "/_ping" endpoint if we don't need to.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-08-22 09:34:09 +02:00
Sebastiaan van Stijn 88f44ec159
cli: SetupRootCommand: remove redundant flags return
The flag-set that was returned is a pointer to the command's Flags(), which
is in itself passed by reference (as it is modified / set up).

This patch removes the flags return, to prevent assuming it's different than
the command's flags.

While SetupRootCommand is exported, a search showed that it's only used internally,
so changing the signature should not be a problem.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-06-28 16:26:50 +02:00
Kevin Alvarez c39c711a18
load plugin command stubs when required
We are currently loading plugin command stubs for every
invocation which still has a significant performance hit.
With this change we are doing this operation only if cobra
completion arg request is found.

- 20.10.23: `docker --version` takes ~15ms
- 23.0.1: `docker --version` takes ~93ms

With this change `docker --version` takes ~9ms

Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2023-03-28 06:16:55 +02:00
Sebastiaan van Stijn fc6be6ad30
cli: pass dockerCLI's in/out/err to cobra cmds
Both the DockerCLI and Cobra Commands provide accessors for Input, Output,
and Error streams (usually STDIN, STDOUT, STDERR). While we were already
passing DockerCLI's Output to Cobra, we were not doing so for the other
streams (and were passing none for plugin commands), potentially resulting
in DockerCLI output/input to mean something else than a Cobra Command's
intput/output/error.

This patch sets them to the same streams when constructing the Cobra
command.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-01-15 13:44:33 +01:00
Sebastiaan van Stijn 006c946389
cmd/docker: make feature detection lazy again
Commit 20ba591b7f fixed incorrect feature
detection in the CLI, but introduced a regression; previously the "ping"
would only be executed if needed (see b39739123b),
but by not inlining the call to `ServerInfo()` would now always be called.

This patch inlines the code again to only execute the "ping" conditionally,
which allows it to be executed lazily (and omitted for commands that don't
require a daemon connection).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-12-06 10:17:50 +01:00
Adyanth Hosavalike 20ba591b7f
Fix bug where incorrect response is returned
When server is unreachable and docker checkpoint (or any command that
needs to check the server type) is run, incorrect error was returned.

When checking if the daemon had the right OS, we compared the OSType
from the clients ServerInfo(). In situations where the client cannot
connect to the daemon, a "stub" Info is used for this, in which we
assume the daemon has experimental enabled, and is running the latest
API version.

However, we cannot fill in the correct OSType, so this field is empty
in this situation.

This patch only compares the OSType if the field is non-empty, otherwise
assumes the platform matches.

before this:

    docker -H unix:///no/such/socket.sock checkpoint create test test
    docker checkpoint create is only supported on a Docker daemon running on linux, but the Docker daemon is running on

with this patch:

    docker -H unix:///no/such/socket.sock checkpoint create test test
    Cannot connect to the Docker daemon at unix:///no/such/socket.sock. Is the docker daemon running?

Co-authored-by: Adyanth Hosavalike <ahosavalike@ucsd.edu>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-12-06 08:55:47 +01:00
Sebastiaan van Stijn a7e2c3ea1e
cli/command: add Cli.CurrentVersion() function
This internalizes constructing the Client(), which allows us to provide
fallbacks when trying to determin the current API version.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-28 10:49:01 +01:00
CrazyMax d1cabdff99
build: set default context builder if not specified
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-11-04 08:42:34 +01:00
Sebastiaan van Stijn 1da95ff6aa
format code with gofumpt
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-30 11:59:11 +02:00
Sebastiaan van Stijn 90f1238fb2
cli-plugins/manager: add IsPluginCommand(() utility
This makes it more convenient to check if a command is a plugin-stub

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-30 02:24:23 +02:00
Sebastiaan van Stijn 7af8aac169
fix broken alias check is buildx is installed as alias for builder
Commit cbec75e2f3 updated `runDocker()` to load
plugin-stubs before `processAliases()` was executed. As a result, plugin
stubs were considered as "builtin commands", causing the alias verification
to fail;

Without alias installed:

```bash
docker version
Client:
 Version:           22.06.0-beta.0-140-g3dad26ca2.m
 API version:       1.42
 Go version:        go1.19.1
 Git commit:        3dad26ca2
 Built:             Wed Sep 28 22:36:09 2022
 OS/Arch:           darwin/arm64
 Context:           default
...
```

After running `docker buildx install`;

```bash
./build/docker buildx install

cat ~/.docker/config.json
{
    "aliases": {
        "builder": "buildx"
    }
}

./build/docker version
not allowed to alias with builtin "buildx" as target
```

This patch moves loading the stubs _after_ the call to `processAliases()`, so
that verification passes. As an extra precaution, the `processAliases()` function
is also updated to exclude plugin-stub commands.

Note that cbec75e2f3 also introduced a performance
regression, which may be related to the early loading of plugins (and creating
stubs); it looks like various other code locations may also be loading plugins,
for example `tryPluginRun()` calls `pluginmanager.PluginRunCommand()`, which
also traverses plugin directories.

We should look under what circumstances the plugin stub-commands are actually
needed, and make sure that they're only created in those situations.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-29 22:40:51 +02:00
Nicolas De Loof cbec75e2f3
Adopt Cobra completion v2 to support completion by CLI plugins
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
2022-05-12 12:59:10 +02:00
Sebastiaan van Stijn db141c21e9
hide swarm-related commands based on the current swarm status and role
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-05-02 14:57:59 +02:00
Sebastiaan van Stijn 257f6149ba
Remove ClientInfo as it is not practically used.
The information in this struct was basically fixed (there's
some discrepancy around the "DefaultVersion" which, probably,
should never vary, and always be set to the Default (maximum)
API version supported by the client.

Experimental is now always enabled, so this information did
not require any dynamic info as well.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-03-04 15:46:50 +01:00
CrazyMax 6fef143dbc
Set buildx as default builder
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-03 10:38:05 +01:00
Silvin Lubecki 5695d699ae
Merge pull request #2735 from thaJeztah/fix_flag_hiding
Fix buildkit flags not being hidden without buildkit enabled
2020-10-29 15:59:02 +01:00
Tonis Tiigi 857f5856f8 handle sigterm on running a plugin
While running a plugin and canceling with SIGTERM, main process will
close right away without letting the plugin close itself down and handle
the exit code properly. Add appcontext that is useful for handling
sigterm, as well as supporting sigkill when things go wrong.

Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
2020-10-21 22:32:49 -07:00
Sebastiaan van Stijn 977d3ae046
Always enable experimental features
The CLI disabled experimental features by default, requiring users
to set a configuration option to enable them.

Disabling experimental features was a request from Enterprise users
that did not want experimental features to be accessible.

We are changing this policy, and now enable experimental features
by default. Experimental features may still change and/or removed,
and will be highlighted in the documentation and "usage" output.

For example, the `docker manifest inspect --help` output now shows:

    EXPERIMENTAL:
      docker manifest inspect is an experimental feature.

      Experimental features provide early access to product functionality. These features
      may change between releases without warning or can be removed entirely from a future
      release. Learn more about experimental features: https://docs.docker.com/go/experimental/

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-10-02 15:59:42 +02:00
Sebastiaan van Stijn b4eb079045
Fix buildkit flags not being hidden without buildkit enabled
These annotations use `nil` as value, which caused the flag-hiding functions
to ignore the annotations, and therefore not hiding the flags.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-09-22 14:47:55 +02:00
Sebastiaan van Stijn 719169db63
Replace deprecated Cobra command.SetOutput() with command.SetOut()
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-05-07 14:25:59 +02:00
Sebastiaan van Stijn b39739123b
cli: perform feature detection lazily
- Perform feature detection when actually needed, instead of during
  initializing
- Version negotiation is performed either when making an API request,
  or when (e.g.) running `docker help` (to hide unsupported features)
- Use a 2 second timeout when 'pinging' the daemon; this should be
  sufficient for most cases, and when feature detection failed, the
  daemon will still perform validation (and produce an error if needed)
- context.WithTimeout doesn't currently work with ssh connections (connhelper),
  so we're only applying this timeout for tcp:// connections, otherwise
  keep the old behavior.

Before this change:

    time sh -c 'DOCKER_HOST=tcp://42.42.42.41:4242 docker help &> /dev/null'
    real   0m32.919s
    user   0m0.370s
    sys    0m0.227s

    time sh -c 'DOCKER_HOST=tcp://42.42.42.41:4242 docker context ls &> /dev/null'
    real   0m32.072s
    user   0m0.029s
    sys    0m0.023s

After this change:

    time sh -c 'DOCKER_HOST=tcp://42.42.42.41:4242 docker help &> /dev/null'
    real   0m 2.28s
    user   0m 0.03s
    sys    0m 0.03s

    time sh -c 'DOCKER_HOST=tcp://42.42.42.41:4242 docker context ls &> /dev/null'
    real   0m 0.13s
    user   0m 0.02s
    sys    0m 0.02s

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-04-10 16:33:21 +02:00
Ian Campbell 7d0645c5fe Use command.Cli instead of command.DockerCli
The linter is complaining:

    cmd/docker/docker.go:72:23⚠️ dockerCli can be github.com/docker/cli/cli/command.Cli (interfacer)

Unclear precisely which change in the preceeding commits caused it to notice
this possibility.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-04-26 15:43:03 +01:00
Ian Campbell 40a6cf7c47 Include CLI plugins in help output on unknown flag.
Previously `docker --badopt` output would not include CLI plugins.

Fixes #1813

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-04-26 15:21:20 +01:00
Ian Campbell 79a75da0fd Hide experimental builtin commands in help output on unknown flag.
Previously `docker --badopt` would always include experimental commands even if
experimental was not enabled.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-04-26 15:09:09 +01:00
Tibor Vass 1ed02c40fe cli-plugins: alias an existing allowed command (only builder for now)
With this patch it is possible to alias an existing allowed command.
At the moment only builder allows an alias.

This also properly puts the build command under builder, instead of image
where it was for historical reasons.

Signed-off-by: Tibor Vass <tibor@docker.com>
2019-04-19 01:26:45 +00:00
Ian Campbell 8c087b6a1e cmd/docker: only parse global arguments once.
Before calling `cmd.Execute` we need to reset the arguments to be used to not
include the global arguments which we have already parsed. This is precisely
the `args` which we have in our hand at this point.

This fixes `TestGlobalArgsOnlyParsedOnce/builtin` in the cli-plugins e2e tests.

`TestGlobalArgsOnlyParsedOnce/plugin` is still broken will be fixed next.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-04-03 15:07:38 +01:00
Simon Ferquel 3beb60a96e Fix error message on experimental flags
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
2019-03-21 16:21:03 +01:00
Ian Campbell d4ced2ef77 allow plugins to have argument which match a top-level flag.
The issue with plugin options clashing with globals is that when cobra is
parsing the command line and it comes across an argument which doesn't start
with a `-` it (in the absence of plugins) distinguishes between "argument to
current command" and "new subcommand" based on the list of registered sub
commands.

Plugins breaks that model. When presented with `docker -D plugin -c foo` cobra
parses up to the `plugin`, sees it isn't a registered sub-command of the
top-level docker (because it isn't, it's a plugin) so it accumulates it as an
argument to the top-level `docker` command. Then it sees the `-c`, and thinks
it is the global `-c` (for AKA `--context`) option and tries to treat it as
that, which fails.

In the specific case of the top-level `docker` subcommand we know that it has
no arguments which aren't `--flags` (or `-f` short flags) and so anything which
doesn't start with a `-` must either be a (known) subcommand or an attempt to
execute a plugin.

We could simply scan for and register all installed plugins at start of day, so
that cobra can do the right thing, but we want to avoid that since it would
involve executing each plugin to fetch the metadata, even if the command wasn't
going to end up hitting a plugin.

Instead we can parse the initial set of global arguments separately before
hitting the main cobra `Execute` path, which works here exactly because we know
that the top-level has no non-flag arguments.

One slight wrinkle is that the top-level `PersistentPreRunE` is no longer
called on the plugins path (since it no longer goes via `Execute`), so we
arrange for the initialisation done there (which has to be done after global
flags are parsed to handle e.g. `--config`) to happen explictly after the
global flags are parsed. Rather than make `newDockerCommand` return the
complicated set of results needed to make this happen, instead return a closure
which achieves this.

The new functionality is introduced via a common `TopLevelCommand` abstraction
which lets us adjust the plugin entrypoint to use the same strategy for parsing
the global arguments. This isn't strictly required (in this case the stuff in
cobra's `Execute` works fine) but doing it this way avoids the possibility of
subtle differences in behaviour.

Fixes #1699, and also, as a side-effect, the first item in #1661.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-03-13 11:28:17 +00:00
Corey Quon d871451049
Fix issue where plugin command error exit code is printed out
Signed-off-by: Corey Quon <corey.quon@docker.com>
2019-02-26 09:39:07 -08:00
Silvin Lubecki 2e5639da02
Merge pull request #1564 from ijc/plugins
Basic framework for writing and running CLI plugins
2019-01-31 17:44:46 +01:00
Ian Campbell baabf6e8ad Ensure that plugins are only listed once in help outputs.
They were listed twice in `docker --help` (but not `docker help`), since the
stubs were added in both `tryRunPluginHelp` and the `setHelpFunc` closure.

Calling `AddPluginStubCommands` earlier in `setHelpFunc` before the call to
`tryRunPluginHelp` is sufficient. Also it is no longer necessary to add just
valid plugins (`tryRunPluginHelp` handles invalid plugins correctly) so remove
that logic (which was in any case broken for e.g. `docker --help`).

Update the e2e test to check for duplicate entries and also to test `docker
--help` which was previously missed.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-30 13:55:42 +00:00
Ian Campbell 935d47bbe9 Ignore unknown arguments on the top-level command.
This allows passing argument to plugins, otherwise they are caught by the parse
loop, since cobra does not know about each plugin at this stage (to avoid
having to always scan for all plugins) this means that e.g. `docker plugin
--foo` would accumulate `plugin` as an arg to the `docker` command, then choke
on the unknown `--foo`.

This allows unknown global args only, unknown arguments on subcommands (e.g.
`docker ps --foo`) are still correctly caught.

Add an e2e test covering this case.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-30 13:45:26 +00:00
Ian Campbell 53f018120a Integrate CLI plugins with `docker «plugin» --help`.
To achieve this we hook in at the beginning of our custom `HelpFunc` and detect
the plugin case by adding stub commands.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-30 13:45:25 +00:00
Ian Campbell 20a284721c Integrate CLI plugins with `docker help «foo»`
Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-30 13:45:18 +00:00
Ian Campbell c43da09188 Add stubs when calling help due to no arguments
e.g. the `docker` case which should act as `docker help`.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-30 13:44:06 +00:00
Ian Campbell f912b55bd1 Integrate CLI plugins into `docker help` output.
To do this we add a stub `cobra.Command` for each installed plugin (only when
invoking `help`, not for normal running).

This requires a function to list all available plugins so that is added here.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-30 13:44:06 +00:00
Ian Campbell f1f31abbe5 Add support for running a CLI plugin
Also includes the  scaffolding for finding a validating plugin candidates.

Argument validation is moved to RunE to support this, so `noArgs` is removed.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-30 13:44:04 +00:00
Silvin Lubecki f65d5365a2 Fix using a nil dockerCli if an error occurred during cli creation, using the standard error stream instead.
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
2019-01-29 16:21:39 +01:00
Ian Campbell 20c19830a9 Move versioning variables to a separate package.
This helps to avoid circular includes, by separating the pure data out from the
actual functionality in the cli subpackage, allowing other code which is
imported to access the data.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-29 11:26:40 +00:00
Ian Campbell c5168117af Push setup of opts and default flagset into SetupRootCommand
I'm shortly going to add a second user (plugins) which want to share some
behaviour.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-29 11:26:21 +00:00
Ian Campbell ccef1598b1 Move `disableFlagsInUseLine` from `main` into our `cli` library
... and expose. I would like to use this from another site.

This implies also moving (and exposing) the `visitAll` helper.

Unit test them while I'm here.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-29 11:26:21 +00:00
Ian Campbell 158a766886 Fold `dockerPreRun` into `DockerCli.Initialize`
All of the current callers follow the pattern:

    dockerPreRun(opts)
    err := dockerCli.Initialize(opts) ...

So there is no semantic change into merging the content of `dockerPreRun` into the head of `Initialize`.

I'm about to add a new caller outside of the `cmd/docker` package and this
seems preferable exporting `DockerPreRun`.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-01-29 11:26:21 +00:00
Silvin Lubecki 7f207f3f95 Introduce functional arguments to NewDockerCli for a more stable API.
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
2019-01-28 14:52:58 +01:00
Sebastiaan van Stijn 15e40e7ee2
Merge pull request #1429 from AkihiroSuda/fix-docker-invalid-subcommand
Fix `docker invalid-subcommand` regression
2018-10-24 20:45:01 +02:00
Tibor Vass bbd01fe3df build: only show buildkit-specific flags if buildkit is enabled
Signed-off-by: Tibor Vass <tibor@docker.com>
2018-10-10 21:09:22 +00:00
Akihiro Suda d708cada43 Fix `docker invalid-subcommand` regression
Starting with a3fe7d62b8,
`docker invalid-subcommand` did not exit with non-zero status.

Fix #1428

Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
2018-10-10 18:23:42 +09:00