It allows to get easily all the variables defined in a
composefile (the `map[string]interface{}` representation that
`loader.ParseYAML` returns at least) and their default value too.
This commit also does some small function extract on substitution
funcs to reduce a tiny bit duplication.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
PersistentPreRunE needs to be called within the help function to initialize all the flags (notably the orchestrator flag)
Add an e2e test as regression test
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
This should make it easier for people to write custom composefile
parser without duplicating too much code. It takes the default
transformers and any additional number of transformer for any
types. That way it's possible to transform a `cli/compose` map into a
custom type that would use some of `cli/compose` types and its own.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
This flag was added in Docker 17.06, API version 1.31 through
moby@8dc8cd4719f165c01c98e7d3ce1d6cea6a8f60b8, but didn't add
API-version annotations.
This patch adds the missing annotations to hide this flag if
the CLI is connected to an older version of the daemon that
doesn't support that API.
Before this patch:
DOCKER_API_VERSION=1.30 docker swarm init --help | grep data-path-addr
--data-path-addr string Address or interface to use for data path traffic (format: <ip|interface>)
DOCKER_API_VERSION=1.31 docker swarm init --help | grep data-path-addr
--data-path-addr string Address or interface to use for data path traffic (format: <ip|interface>)
With this patch applied:
DOCKER_API_VERSION=1.30 docker swarm init --help | grep data-path-addr
# (no result)
DOCKER_API_VERSION=1.31 docker swarm init --help | grep data-path-addr
--data-path-addr string Address or interface to use for data path traffic (format: <ip|interface>)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Use `Contains` instead of `Include`
- Use `ToJSON` instead of `ToParam`
- Remove usage of `ParseFlag` as it is deprecated too
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Even though those fields are not supported by `docker stack deploy`
they are defined in versions `3.x` of compose schema, so the `compose`
package should be able to marshal/unmarshal them.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Clarified ambiguous error message
Update kubernetes/cli.go
Infromed user of why the error was caused when file is not there
Signed-off-by: Justyn Temme <justyntemme@gmail.com>
- remove some hints that are no longer needed
- added a nolint: unparam for removeSingleSigner() (return bool is only used in tests)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
'CheckInitialized' in the credential-helper library actually invokes
`pass`, which isn't desirable (see #699).
This moves the check to be simpler, and then pass will only be invoked
when it's needed (such as for `docker login` or when pulling from a
private registry).
This logic could also reasonably live in the credential-helper library,
but it's simple enough it seems fine in either location.
Signed-off-by: Euan Kemp <euank@euank.com>
Stores complete OCI descriptor instead of digest and platform
fields. This includes the size which was getting lost by not
storing the original manifest bytes.
Attempt to support existing cached files, if not output
the filename with the incorrect content.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
It makes it easier to get the correct stack from a compose config
struct without requiring the client (and thus talking to k8s API)
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
- Handle `bundlefile` directly in the `top-level`
command. `bundlefile` is still experimental and will be deprecated
in future version — this should make be easier to remove it.
- Validate the `stack` name in all cases (i.e. whatever the
orchestrator is used)
- Load the composefile ahead of choosing the orchestrator. This
removes some slight duplication.
- Makes `RunDeploy` easier to use from outside packages (like
`docker/app`) with a preloaded configuration.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
- Add the possibility to skip interpolation
- Add the possibility to skip schema validation
- Allow customizing the substitution function, to add special cases.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
> Run an init inside the container that forwards signals and reaps
processes
This is supported on `run` and now on Swarm services too, so it's also
possible to have in on a composefile :).
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
That field is automaticaly populated with any `x-*` field in the yaml.
And marshalling the compose config struct put them back into place.
This make it possible to get those extra fields without re-inventing
the wheel (i.e. reimplementing 80% of the `cli/compose/*` packages.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
The output of this information can be confusing,
so removing until we have a better design for this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Renaming DOCKER_ORCHESTRATOR to DOCKER_STACK_ORCHESTRATOR
* Renaming config file option "orchestrator" to "stackOrchestrator"
* "--orchestrator" flag is no more global but local to stack command and subcommands
* Cleaning all global orchestrator code
* Replicating Hidden flags in help and Supported flags from root command to stack command
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
Unfortunately, this is for now the only way to see the output of RUN commands when using buildkit.
It is equivalent to `DOCKER_BUILDKIT=1 docker build . 2>&1 | cat`
Signed-off-by: Tibor Vass <tibor@docker.com>
With this patch the following become true even with buildkit enabled:
1. `docker build -q .` only outputs the created image's sha256 ID.
2. `docker build -q .` outputs as if no `-q` was specified, if error occurred
3. `docker build . &> out` outputs JSON (instead of TTY characters)
Signed-off-by: Tibor Vass <tibor@docker.com>
This commit brings a more pedantic change in the following ambiguous case:
cat Dockerfile | docker build -f otherDockerfile -
The legacy builder does not error out and prefers the Dockerfile from stdin
while the buildkit-based one errors out.
Note that this is only in the case where stdin is a Dockerfile (not an archive)
Signed-off-by: Tibor Vass <tibor@docker.com>
* Kubernetes native filtering (server side) is an exact match, now filtering on name is made client-side to add prefix-matching
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
This patch adds annotations to mark the checkpoint commands as Linux only, which
hides them if the daemon is running a non-matching operating-system type;
Before:
docker
Usage: docker COMMAND
A self-sufficient runtime for containers
...
Management Commands:
config Manage Docker configs
container Manage containers
image Manage images
After:
docker
Usage: docker COMMAND
A self-sufficient runtime for containers
...
Management Commands:
checkpoint Manage checkpoints
config Manage Docker configs
container Manage containers
image Manage images
This change also prints errors when attempting to use checkpoint commands or
flags if the feature is not supported by the Daemon's operating system;
$ docker checkpoint --help
docker checkpoint is only supported on a Docker daemon running on linux, but the Docker daemon is running on windows
$ docker checkpoint create --help
docker checkpoint create is only supported on a Docker daemon running on linux, but the Docker daemon is running on windows
$ docker checkpoint ls --help
docker checkpoint ls is only supported on a Docker daemon running on linux, but the Docker daemon is running on windows
$ docker checkpoint rm --help
docker checkpoint rm is only supported on a Docker daemon running on linux, but the Docker daemon is running on windows
$ docker container start --checkpoint=foo mycontainer
"--checkpoint" requires the Docker daemon to run on linux, but the Docker daemon is running on windows
$ docker container start --checkpoint-dir=/foo/bar mycontainer
"--checkpoint-dir" requires the Docker daemon to run on linux, but the Docker daemon is running on windows
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Vincent Demeester
Silvin Lubecki
Vincent Demeester
Silvin
Sebastiaan van Stijn
Justyn Temme
Vimal Raghubir
Sebastiaan van Stijn
Arash Deshmeh
Sami Tabet
Tibor Vass
Tibor Vass
Tõnis Tiigi
Ying Li
Euan Kemp
Derek McGowan
Eli Uriegas
Andrew Hsu
Nassim 'Nass' Eddequiouaq