This partially reverts e0b59ab52b,
and does not automatically disable proxying signals in TTY-mode
Before this change:
------------------------------------
Start a container with a TTY in one shell:
```
docker run -it --init --name repro-28872 busybox sleep 30
```
then, in another shell, kill the docker cli:
```
kill `pgrep -f repro-28872`
```
Notice that the CLI was killed, but the signal not forwarded to the container;
the container continues running
```
docker container inspect --format '{{ .State.Status }}' repro-28872
running
docker container rm -f repro-28872
```
After this change:
------------------------------------
Start a container with a TTY in one shell:
```
docker run -it --init --name repro-28872 busybox sleep 30
```
then, in another shell, kill the docker cli:
```
kill `pgrep -f repro-28872`
```
Verify that the signal was forwarded to the container, and the container exited
```
docker container inspect --format '{{ .State.Status }}' repro-28872
exited
docker container rm -f repro-28872
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
For backward compatibility: if no custom options are provided for the network,
and only a single network is specified, omit the endpoint-configuration
on the client (the daemon will still create it when creating the container)
This fixes an issue on older versions of legacy Swarm, which did not support
`NetworkingConfig.EndpointConfig`.
This was introduced in 5bc09639cc (#1767)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Follows the proposal on issue [#34394](https://github.com/moby/moby/issues/34394)
- Maintains current behavior as default (Pull image if missing)
- Adds tristate flag allowing modification (PullMissing, PullAlways, PullNever)
Signed-off-by: Zander Mackie <zmackie@gmail.com>
This refactors the way networking options are parsed, and makes the
client able to pass options for multiple networks. Currently, the
daemon does not yet accept multiple networks when creating a container,
and will produce an error.
For backward-compatibility, the following global networking-related
options are associated with the first network (in case multiple
networks are set);
- `--ip`
- `--ip6`
- `--link`
- `--link-local-ip`
- `--network-alias`
Not all of these options are supported yet in the advanced notation,
but for options that are supported, setting both the per-network option
and the global option will produce a "conflicting options" error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The commit contains cli changes to support driver options for a network in
docker run and docker network connect cli's. The driver-opt, aliases is now
supported in the form of csv as per network option in service commands in
swarm mode since docker/cli#62 . This commit extends this support to docker
run command as well.
For docker connect command `--driver-opt` is added to pass driver specific
options for the network the container is connecting to.
Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds validation to `docker container run` / `docker container create`;
Validation of labels provided through flags was removed in 31dc5c0a9a,
after the validation was changed to fix labels without values, and to prevent
labels from being expanded with environment variables in 2b17f4c8a8
However, now empty label names from _files_ (`--label-file`) followed different
validation rules than labels passed through `--label`.
This patch adds back minimal validation for labels passed through the command-line
Before this patch:
```bash
docker container create \
--name label \
--label==with-leading-equal-sign \
--label=without-value \
--label=somelabel=somevalue \
--label " = " \
--label=with-quotes-in-value='{"foo"}' \
--label='with"quotes"in-key=test' \
busybox
docker container inspect --format '{{json .Config.Labels}}' label
```
```json
{
"": "with-leading-equal-sign",
" ": " ",
"somelabel": "somevalue",
"with\"quotes\"in-key": "test",
"with-quotes-in-value": "{\"foo\"}",
"without-value": ""
}
```
After this patch:
```bash
docker container create \
--name label \
--label==with-leading-equal-sign \
--label=without-value \
--label=somelabel=somevalue \
--label " = " \
--label=with-quotes-in-value='{"foo"}' \
--label='with"quotes"in-key=test' \
busybox
invalid argument "=with-leading-equal-sign" for "-l, --label" flag: invalid label format: "=with-leading-equal-sign"
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Proxies configured in config.json were only taking effect
when using `docker run`, but were being ignored when
using `docker create`.
Before this change:
echo '{"proxies":{"default":{"httpProxy":"httpProxy","httpsProxy":"httpsProxy","noProxy":"noProxy","ftpProxy":"ftpProxy"}}}' > config.json
docker inspect --format '{{.Config.Env}}' $(docker --config=./ create busybox)
[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
With this change applied:
echo '{"proxies":{"default":{"httpProxy":"httpProxy","httpsProxy":"httpsProxy","noProxy":"noProxy","ftpProxy":"ftpProxy"}}}' > config.json
docker inspect --format '{{.Config.Env}}' $(docker --config=./ create busybox)
[NO_PROXY=noProxy no_proxy=noProxy FTP_PROXY=ftpProxy ftp_proxy=ftpProxy HTTP_PROXY=httpProxy http_proxy=httpProxy HTTPS_PROXY=httpsProxy https_proxy=httpsProxy PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
Reported-by: Silvano Cirujano Cuesta <Silvanoc@users.noreply.github.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Previously, these errors were only printed when using `docker run`, but were
omitted when using `docker container create` and `docker container start`
separately.
Given that these warnings apply to both situations, this patch moves generation
of these warnings to `docker container create` (which is also called by
`docker run`)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
A while ago, Docker split the "Domainname" field out from the "Hostname"
field for the container configuration. There was no real user-visible
change associated with this (and under the hood "Domainname" was mostly
left unused from the command-line point of view). We now add this flag
in order to match other proposed changes to allow for setting the NIS
domainname of a container.
This also includes a fix for the --hostname parsing tests (they would
not error out if only one of .Hostname and .Domainname were incorrectly
set -- which is not correct).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
- make it possible to extract the formatter implementation from the
"common" code, that way, the formatter package stays small
- extract some formatter into their own packages
This is essentially moving the "formatter" implementation of each type
in their respective packages. The *main* reason to do that, is to be
able to depend on `cli/command/formatter` without depending of the
implementation detail of the formatter. As of now, depending on
`cli/command/formatter` means we depend on `docker/docker/api/types`,
`docker/licensing`, … — that should not be the case. `formatter`
should hold the common code (or helpers) to easily create formatter,
not all formatter implementations.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
The integration test TestExportContainerWithOutputAndImportImage in moby/moby is the same as TestExportContainerAndImportImage,
except for the output file option. Adding a unit test to cover the output file option of the export command here allows
the removal of the redundant integration test TestExportContainerWithOutputAndImportImage.
Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.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>
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>
Switch from x/net/context to context made "go vet" see the previously
unseen errors:
> cli/command/container/start.go:57::error: the cancelFun function is
> not used on all paths (possible context leak) (vet)
> cli/command/container/start.go:63::error: this return statement may be
> reached without using the cancelFun var defined on line 57 (vet)
> cli/command/container/run.go:159::error: the cancelFun function is not
> used on all paths (possible context leak) (vet)
> cli/command/container/run.go:164::error: this return statement may be
> reached without using the cancelFun var defined on line 159 (vet)
Do call the cancel function.
Note we might end up calling it twice which is fine as long as I can see
from the Go 1.10 source code.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Since go 1.7, "context" is a standard package. Since go 1.9,
x/net/context merely provides some types aliased to those in
the standard context package.
The changes were performed by the following script:
for f in $(git ls-files \*.go | grep -v ^vendor/); do
sed -i 's|golang.org/x/net/context|context|' $f
goimports -w $f
for i in 1 2; do
awk '/^$/ {e=1; next;}
/\t"context"$/ {e=0;}
{if (e) {print ""; e=0}; print;}' < $f > $f.new && \
mv $f.new $f
goimports -w $f
done
done
[v2: do awk/goimports fixup twice]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
- Some of them don't make sense anymore
- Some are deprecated and removed from the engine since a few versions
already.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Some of them are skipped for now (because the feature is not supported
or needs more work), some of them are fixed.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>