Commit Graph

103 Commits

Author SHA1 Message Date
Sebastiaan van Stijn 14f97cc10a
cli/command: DockerCli.ServerInfo() load info lazily
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-28 16:52:02 +01:00
Sebastiaan van Stijn 3b7235edca
cli/command: initialize client and load content lazily
This allows commands that don't require a client connection (such as `context use`)
to be functional, but still produces an error when trying to run a command that
needs to connect with the API;

    mkdir -p ~/.docker/ && echo '{"currentContext":"nosuchcontext"}' >  ~/.docker/config.json
    docker version
    Failed to initialize: unable to resolve docker endpoint: load context "nosuchcontext": context does not exist: open /root/.docker/contexts/meta/8bfef2a74c7d06add4bf4c73b0af97d9f79c76fe151ae0e18b9d7e57104c149b/meta.json: no such file or directory

    docker context use default
    default
    Current context is now "default"

    docker version
    Client:
     Version:           22.06.0-dev
     API version:       1.42
     ...

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-28 16:52:02 +01:00
Sebastiaan van Stijn 60987b8d7a
cli/command: DockerCli: keep reference to options for later use
Store a reference to the options in the client, so that they are available
for later use.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-28 15:14:36 +01:00
Sebastiaan van Stijn 181769f18c
cli/command: remove DockerCli.loadConfigFile()
This makes it more transparent what's happening.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-28 13:24:07 +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
Sebastiaan van Stijn e36d5a0929
cli/command: DockerCli.CurrentContext: improve GoDoc
Also move the resolveContextName() function together with the
method for easier cross-referencing.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-22 14:27:44 +01:00
Sebastiaan van Stijn 793f09705d
cli/command: resolveContextName() move conflicting options check
There's no strict need to perform this validation inside this function;
validating flags should happen earlier, to allow faster detecting of
configuration issues (we may want to have a central config "validate"
function though).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-22 13:54:28 +01:00
Sebastiaan van Stijn 2f5698511a
cli/command: resolveContextName() don't validate if context exists
resolveContextName() is used to find which context to use, based on the
available configuration options. Once resolved, the context name is
used to load the actual context, which will fail if the context doesn't
exist, so there's no need to produce an error at this stage; only
check priority of the configuration options to pick the context
with the highest priority.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-22 13:53:10 +01:00
Sebastiaan van Stijn 3499669e18
cli/flags: merge CommonOptions into ClientOptions
CommonOptions was inherited from when the cli and daemon were in the same
repository, and some options would be shared between them. That's no longer
the case, and some options are even "incorrect" (for example, while the
daemon can be configured to run on multiple hosts, the CLI can only connect
with a single host / connection). This patch does not (yet) address that,
but merges the CommonOptions into the ClientOptions.

An alias is created for the old type, although it doesn't appear there's
any external consumers using the CommonOptions type (or its constructor).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-22 12:32:18 +01:00
Sebastiaan van Stijn de6020a240
cli/context/store: simplify error handling, and make it more idiomatic
The package defined various special errors; these errors existed for two reasons;

- being able to distinguish "not found" errors from other errors (as "not found"
  errors can be ignored in various cases).
- to be able to update the context _name_ in the error message after the error
  was created. This was needed in cases where the name was not available at the
  location where the error was produced (e.g. only the "id" was present), and
  the helpers to detect "not found" errors did not support wrapped errors (so
  wrapping the error with a "name" could break logic); a `setContextName` interface
  and corresponding `patchErrContextName()` utility was created for this (which
  was a "creative", but not very standard approach).

This patch:

- Removes the special error-types, replacing them with errdefs definitions (which
  is a more common approach in our code-base to detect error types / classes).
- Removes the internal utilities for error-handling, and deprecates the exported
  utilities (to allow external consumers to adjust their code).
- Some errors have been enriched with detailed information (which may be useful
  for debugging / problem solving).
- Note that in some cases, `patchErrContextName()` was called, but the code
  producing the error would never return a `setContextName` error, so would
  never update the error message.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-30 11:19:25 +02:00
Sebastiaan van Stijn e484243c29
cli/command: NewDockerCli(): use WithStandardStreams()
`NewDockerCli` was configuring the standard streams using local code; this patch
instead uses the available `WithStandardStreams()` option to do the same.

There is slight difference in the order of events;

Previously, user-provided options would be applied first, after which NewDockerCli
would check if any of "in", "out", or "err" were nil, and if so set them to the
default stream (or writer) for that output.

The new code unconditionally sets the defaults _before_ applying user-provided
options. In practive, howver, this makes no difference; the fields set are not
exported, and the only functions updating them are `WithStandardStreams`,
`WithInputStream`, and `WithCombinedStream`, neither of which checks the old
value (so always overrides).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-08-31 17:10:53 +02:00
Nick Santos 1d9ab7803a
cli: set timeout connection ping on sockets as well
Note that this does not fully fix the referenced issue, but
at least makes sure that API clients don't hang forever on
the initialization step.

See: https://github.com/docker/cli/issues/3652
Signed-off-by: Nick Santos <nick.santos@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-07-29 14:34:01 +02:00
Nick Santos 50893d72d4
also treat DOCKER_CONTEXT='' as unset
Signed-off-by: Nick Santos <nick.santos@docker.com>
2022-07-29 11:05:42 +02:00
Nick Santos aa7b1b24a5
command: treat DOCKER_HOST the same if it's empty or unset
print appropriate warning messages on 'context list'/'context use'

Signed-off-by: Nick Santos <nick.santos@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-07-29 11:04:52 +02:00
Sebastiaan van Stijn 6874c2e80b
cli/command: remove unused args from ResolveDefaultContext()
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-07-21 18:11:48 +02:00
Sebastiaan van Stijn 374d0f88cd
cli: initializeFromClient(): detect swarm status from ping (if available)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-05-02 14:57:57 +02:00
Sebastiaan van Stijn 1db2da57c8
use client consts for environment variable names
It's slightly more verbose, but helps finding the purpose of each
of the environment variables. In tests, I kept the fixed strings.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-03-30 17:42:20 +02:00
Sebastiaan van Stijn 6745f62a0b
Merge pull request #3136 from thaJeztah/remove_clientinfo
Remove ClientInfo as it is not practically used.
2022-03-15 15:12:22 +01: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
Sebastiaan van Stijn b7e4f3daa6
remove alias for cli/config imports
Just `config` as name for the package should work; this also revealed that one
file was importing the same package twice.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-03-04 14:45:33 +01:00
Sebastiaan van Stijn cc08fc1af0
Implement WithDefaultContextStoreConfig() DockerCliOption
Just a minor refactor to make this slightly cleaner

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-03-03 14:47:59 +01:00
Sebastiaan van Stijn d35b50c0c3
NewAPIClientFromFlags: rename variable to not collide with import
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-03-03 14:47:54 +01:00
Sebastiaan van Stijn 3f7e7bf9d2
cli/command: remove deprecated io/ioutil and use t.TempDir()
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-02-25 15:42:14 +01:00
CrazyMax e38e6c51ff
bring back and expose BuildKitEnabled func
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-24 17:57:56 +01:00
Nicolas De Loof 193ede9b12
remove obsolete mutli-orchestrator support
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
2022-02-22 15:28:12 +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
Sebastiaan van Stijn 08a1ccc60a
Remove support for encrypted TLS private keys
> Legacy PEM encryption as specified in RFC 1423 is insecure by design. Since
> it does not authenticate the ciphertext, it is vulnerable to padding oracle
> attacks that can let an attacker recover the plaintext

From https://go-review.googlesource.com/c/go/+/264159

> It's unfortunate that we don't implement PKCS#8 encryption so we can't
> recommend an alternative but PEM encryption is so broken that it's worth
> deprecating outright.

This feature allowed using an encrypted private key with a supplied password,
but did not provide additional security as the encryption is known to be broken,
and the key is sitting next to the password in the filesystem. Users are recommended
to decrypt the private key, and store it un-encrypted to continue using it.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-01-27 14:26:32 +01:00
Sebastiaan van Stijn 15535d4594
context: deprecate support for encrypted TLS private keys
> Legacy PEM encryption as specified in RFC 1423 is insecure by design. Since
> it does not authenticate the ciphertext, it is vulnerable to padding oracle
> attacks that can let an attacker recover the plaintext

From https://go-review.googlesource.com/c/go/+/264159

> It's unfortunate that we don't implement PKCS#8 encryption so we can't
> recommend an alternative but PEM encryption is so broken that it's worth
> deprecating outright.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2021-07-28 14:42:45 +02: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 2b1138c118
Fix initializing client modifying custom HTTPHeaders
When initializing the API client, the User-Agent was added to any custom
HTTPHeaders that were configured. However, because the map was not properly
dereferenced, the original map was modified, causing the User-Agent to also
be saved to config.json after `docker login` and `docker logout`:

Before this change;

    $ cat ~/.docker/config.json
    cat: can't open '/root/.docker/config.json': No such file or directory

    $ docker login -u myusername
    Password:
    ...
    Login Succeeded

    $ cat ~/.docker/config.json
    {
        "auths": {
            "https://index.docker.io/v1/": {
                "auth": "<base64 auth>"
            }
        },
        "HttpHeaders": {
            "User-Agent": "Docker-Client/19.03.12 (linux)"
        }
    }

    $ docker logout
    {
        "auths": {},
        "HttpHeaders": {
            "User-Agent": "Docker-Client/19.03.12 (linux)"
        }
    }

After this change:

    $ cat ~/.docker/config.json
    cat: can't open '/root/.docker/config.json': No such file or directory

    $ docker login -u myusername
    Password:
    ...
    Login Succeeded

    $ cat ~/.docker/config.json
    {
        "auths": {
            "https://index.docker.io/v1/": {
                "auth": "<base64 auth>"
            }
        }
    }

    $ docker logout
    Removing login credentials for https://index.docker.io/v1/

    $ cat ~/.docker/config.json
    {
        "auths": {}
    }

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-09-29 17:24:07 +02:00
Daniil Nikolenko cb010db830 Fix bug with panic when DOCKER_CLI_EXPERIMENTAL environment variable is incorrect
Signed-off-by: Daniil Nikolenko <qoo2p5@gmail.com>
2020-05-24 23:21:20 +03:00
Silvin Lubecki 54f766d240 Partially revert cf663b526a as it breaks the version negotiation with an older docker engine.
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
2020-05-20 16:10:43 +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 d0a80bf445
update docker, replace github.com/docker/pkg/term, github.com/docker/pkg/mount
These packages are now living in their own repository. Updating
docker/docker to replace the dependencies.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-04-22 17:16:13 +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
Sebastiaan van Stijn 43b2f52d0c
Remove "docker engine" subcommands
These subcommands were created to allow upgrading a Docker Community
engine to Docker Enterprise, but never really took off.

This patch removes the `docker engine` subcommands, as they added
quite some complexity / additional code.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2019-12-12 17:51:25 +01:00
Anca Iordache 22a5dad847 app-214 Load Client info in getter function
Signed-off-by: Anca Iordache <anca.iordache@docker.com>

Possible approach for client info

- split ClientInfo() into ClientInfo() and loadClientInfo()
- split ConfigFile() into ConfigFile() and loadConfigFile()
- ConfigFile() and ClientInfo() call their corresponding loadXX function
  if it has not yet been loaded; this allows them to be used before
  Initialize() was called.
- Initialize() *always* (re-)loads the configuration; this makes sure
  that the correct configuration is used when actually calling commands.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2019-11-08 11:39:07 +01:00
Ian Campbell 520be05c49 Dynamically register kubernetes context store endpoint type.
This removes the need for the core context code to import
`github.com/docker/cli/cli/context/kubernetes` which in turn reduces the
transitive import tree in this file to not pull in all of Kubernetes.

Note that this means that any calling code which is interested in the
kubernetes endpoint must import `github.com/docker/cli/cli/context/kubernetes`
itself somewhere in order to trigger the dynamic registration. In practice
anything which is interested in Kubernetes must import that package (e.g.
`./cli/command/context.list` does for the `EndpointFromContext` function) to do
anything useful, so this restriction is not too onerous.

As a special case a small amount of Kubernetes related logic remains in
`ResolveDefaultContext` to handle error handling when the stack orchestrator
includes Kubernetes. In order to avoid a circular import loop this hardcodes
the kube endpoint name.

Similarly to avoid an import loop the existing `TestDefaultContextInitializer`
cannot continue to unit test for the Kubernetes case, so that aspect of the
test is carved off into a very similar test in the kubernetes context package.

Lastly, note that the kubernetes endpoint is now modifiable via
`WithContextEndpointType`.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-20 13:28:11 +01:00
Ian Campbell f820766f6a Export `DefaultContextStoreConfig()` and `ResolveDefaultContext()`
These are needed by any dynamically registered (via
`RegisterDefaultStoreEndpoints`) endpoint type to write a useful/sensible unit
test.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-20 13:28:11 +01:00
Ian Campbell 1433e27420 Allow dynamically registered context endpoint to provide their defaults.
Previously an endpoint registered using `RegisterDefaultStoreEndpoints` would
not be taken into consideration by `resolveDefaultContext` and so could not
provide any details.

Resolve this by passing a `store.Config` to `resolveDefaultContext` and using
it to iterate over all registered endpoints. Any endpoint can ensure that their
type implements the new `EndpointDefaultResolver` in order to provide a default.

The Docker and Kubernetes endpoints are special cased, shortly the Kubernetes
one will be refactored to be dynamically registered.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-20 13:28:11 +01:00
Ian Campbell 087c3f7d08 Support dynamic registration of context store endpoint types
This is a yet unused and the default set remains the same, no expected
functional change.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-20 13:28:11 +01:00
Ian Campbell d84e278aac fix a few typos
Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-20 13:28:11 +01:00
Ian Campbell 1e5129f027 rename package import kubcontext → kubecontext
The (small number) of other places which name this import use `kubecontext`,
make it consistent.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-14 13:46:40 +01:00
Simon Ferquel a3efd5d195 Cleanup context store interfaces
This remove the term "context" from context store interfaces, to make
them more concise

Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
2019-04-18 15:49:36 +02:00
Simon Ferquel 225c9b189a Split the context store interface
This is to make it easier to implement support for exporting contexts in
3rd party code, or to create mocks in tests.

2 exemples where it simplify things:
- docker-app desktop-specific context decorator (which rewrites parts of
the docker context to simplify UX when using on Docker Desktop contexts)
- ucp for including a context in the connection bundle

Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
2019-04-18 15:03:46 +02:00
Jean-Christophe Sirot b3aa17187f Make default context behaves like a real context:
- when using "--context default" parameter
- when printing the list of contexts
- when exporting the default context to a tarball

Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
(+1 squashed commit)
Squashed commits:
[20670495] Fix CLI initialization for the `docker stack deploy --help` command and ensure that the dockerCli.CurrentContext() always returns a non empty context name (default as a fallback)
Remove now obsolete code handling empty string context name
Minor code cleanup

Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
2019-03-18 11:45:46 +01:00
Jean-Christophe Sirot 37fcaf7a29 Resolve the docker Endpoint even if the client already exists. In that case the `TestDialStdio` e2e test had to be modified: the `--tls` option triggers an error since the endpoint resolution tries to read the `${DOCKER_CERT_PATH}/ca.pem` file which does not exist.
Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
2019-03-13 14:18:41 +01:00
Jean-Christophe Sirot 3b26cfce8b Always initialize context store
Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
2019-03-13 14:18:41 +01:00
Ian Campbell 891b3d953e cli-plugins: use `docker system dial-stdio` to call the daemon
This means that plugins can use whatever methods the monolithic CLI supports,
which is good for consistency.

This relies on `os.Args[0]` being something which can be executed again to
reach the same binary, since it is propagated (via an envvar) to the plugin for
this purpose. This essentially requires that the current working directory and
path are not modified by the monolithic CLI before it launches the plugin nor
by the plugin before it initializes the client. This should be the case.

Previously the fake apiclient used by `TestExperimentalCLI` was not being used,
since `cli.Initialize` was unconditionally overwriting it with a real one
(talking to a real daemon during unit testing, it seems). This wasn't expected
nor desirable and no longer happens with the new arrangements, exposing the
fact that no `pingFunc` is provided, leading to a panic. Add a `pingFunc` to
the fake client to avoid this.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-02-18 11:53:37 +00: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