The State field allows printing the container state without
additional information about uptime, healthcheck, etc.
With this patch, the container's state can be printed independently:
```bash
docker ps -a --format '{{.State}}'
running
paused
exited
created
```
```bash
docker ps -a --format 'table {{.Names}}\t{{.State}}\t{{.Status}}'
NAMES STATE STATUS
elastic_burnell running Up About a minute
pausie paused Up 5 minutes (Paused)
peaceful_stonebraker exited Exited (0) 10 hours ago
vigilant_shaw created Created
```
```bash
docker ps -a --format 'raw'
container_id: 0445f73f3a71
image: docker-cli-dev
command: "ash"
created_at: 2019-07-12 11:16:11 +0000 UTC
state: running
status: Up 2 minutes
names: elastic_burnell
labels:
ports:
container_id: 1aff69a3912c
image: nginx:alpine
command: "nginx -g 'daemon of ..."
created_at: 2019-07-12 11:12:10 +0000 UTC
state: paused
status: Up 6 minutes (Paused)
names: pausie
labels: maintainer=NGINX Docker Maintainers <docker-maint@nginx.com>
ports: 80/tcp
container_id: d48acf66c318
image: alpine:3.9.3
command: "id -u"
created_at: 2019-07-12 00:52:17 +0000 UTC
state: exited
status: Exited (0) 10 hours ago
names: peaceful_stonebraker
labels:
ports:
container_id: a0733fe0dace
image: b7b28af77ffe
command: "/bin/sh -c '#(nop) ..."
created_at: 2019-07-12 00:51:29 +0000 UTC
state: created
status: Created
names: vigilant_shaw
labels:
ports:
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
1. Adds `docker events` description info on the two scope types of events.
2. Adds `docker events` note in two places about backlog limit of event log.
Further info and background info in Issue 727
Signed-off-by: Bret Fisher <bret@bretfisher.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When deploying a stack using a relative path as bind-mount
source in the compose file, the CLI converts the relative
path to an absolute path, relative to the location of the
docker-compose file.
This causes a problem when deploying a stack that uses
an absolute Windows path, because a non-Windows client will
fail to detect that the path (e.g. `C:\somedir`) is an absolute
path (and not a relative directory named `C:\`).
The existing code did already take Windows clients deploying
a Linux stack into account (by checking if the path had a leading
slash). This patch adds the reverse, and adds detection for Windows
absolute paths on non-Windows clients.
The code used to detect Windows absolute paths is copied from the
Golang filepath package;
1d0e94b1e1/src/path/filepath/path_windows.go (L12-L65)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `aufs` storage driver is deprecated in favor of `overlay2`, and will
be removed in a future release. Users of the `aufs` storage driver are
recommended to migrate to a different storage driver, such as `overlay2`, which
is now the default storage driver.
The `aufs` storage driver facilitates running Docker on distros that have no
support for OverlayFS, such as Ubuntu 14.04 LTS, which originally shipped with
a 3.14 kernel.
Now that Ubuntu 14.04 is no longer a supported distro for Docker, and `overlay2`
is available to all supported distros (as they are either on kernel 4.x, or have
support for multiple lowerdirs backported), there is no reason to continue
maintenance of the `aufs` storage driver.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a test to verify that killing the docker CLI forwards
the signal to the container. Test-case for moby/moby 28872
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
This code was attempting to check Linux file permissions
to determine if the key was accessible by other users, which
doesn't work, and therefore prevented users on Windows
to load keys.
Skipping this check on Windows (correspinding tests
were already skipped).
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>
Co-Authored-By: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds capabilities to import a .zip file with importZip.
Detects the content type of source by checking bytes & DetectContentType.
Adds LimitedReader reader, a fork of io.LimitedReader,
was needed for better error messaging instead of just getting back EOF.
We are using limited reader to avoid very big files causing memory issues.
Adds a new file size limit for context imports,
this limit is used for the main file for .zip & .tar and individual compressed
files for .zip.
Added TestImportZip that will check the import content type
Then will assert no err on Importing .zip file
Signed-off-by: Goksu Toprak <goksu.toprak@docker.com>
To test, add $(pwd)/build/plugins-linux-amd64 to "cliPluginsExtraDirs" config and run:
make plugins
make binary
HELLO_EXPERIMENTAL=1 docker helloworld
To show it enabled:
HELLO_EXPERIMENTAL=1 DOCKER_CLI_EXPERIMENTAL=enabled docker helloworld
Signed-off-by: Tibor Vass <tibor@docker.com>
This is less of a layering violation and removes some ugly hardcoded
`"kubernetes"` strings which were needed to avoid an import loop.
Signed-off-by: Ian Campbell <ijc@docker.com>
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>
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>
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>
Sebastiaan van Stijn
Sebastiaan van Stijn
Bret Fisher
Silvin Lubecki
Tibor Vass
Adrian Plata
Vincent Demeester
Silvin Lubecki
Andrew Hsu
Rohan Verma
Jintao Zhang
Thibault Coupin
Tonis Tiigi
Goksu Toprak
Tibor Vass
Ian Campbell