As map reference, if all networks use same, it could cause strange
results.
Closes: #23304
Signed-off-by: Kai Qiang Wu(Kennan) <wkqwu@cn.ibm.com>
Upstream-commit: 1cac7e6cbd3d1501d0fc29fc55b7ada981974998
Component: engine
This adds support for filtering by network ID, to be
consistent with other filter options.
Note that only *full* matches are returned; this is
consistent with other filters (e.g. volume), that
also return full matches only.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 7c46ba02e694ae540866b29ebf0dab76e556cc13
Component: engine
If Windows updates are being applied via a RUN command in a docker build, the build will not stop if there was a failure in postRunProcessing. To enable this behavior, we explicitly set the exit code of the container to a failure if postRunProcessing fails during servicing container step. For completeness, also avoid running servicing operation if the original exit code of the container is non-zero so that original failure exit code does not get overwritten.
Signed-off-by: Stefan J. Wernli <swernli@microsoft.com>
Upstream-commit: 2266e7f2345c88a8e195fd959550d0d657bec843
Component: engine
Currently `start` will hide some errors and throw a consolidated error,
which will make it hard to debug because developer can't find the
original error.
This commit allow daemon to log original errors first.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: b4740e3021a39a502ffc82f0f70e9b7ed2f0875f
Component: engine
This is similar to network scopes where a volume can either be `local`
or `global`. A `global` volume is one that exists across the entire
cluster where as a `local` volume exists on a single engine.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2f40b1b281a3be8f34d82a5170988ee46ea1f442
Component: engine
Also add docs to detach events
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: 3accde6dee079fbde42f1928002bce43cb15833d
Component: engine
If we attach to a running container and stream is closed afterwards, we
can never be sure if the container is stopped or detached. Adding a new
type of `detach` event can explicitly notify client that container is
detached, so client will know that there's no need to wait for its exit
code and it can move forward to next step now.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 83ad006d4724929ccbde4bdf768374fad0eeab44
Component: engine
This fix tries to address the issue raised in #23055.
Currently `docker search` result caps at 25 and there is
no way to allow getting more results (if exist).
This fix adds the flag `--limit` so that it is possible
to return more results from the `docker search`.
Related documentation has been updated.
Additional tests have been added to cover the changes.
This fix fixes#23055.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 92f10fe228c1b4b527b87ac47401132322283ea3
Component: engine
Add support for reading journal extras details, and setting timestamps to UTC
Upstream-commit: 94b2d3554c84f33a598a36ba38038f7bbcd97e43
Component: engine
This PR adds support for user-defined health-check probes for Docker
containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus
some corresponding "docker run" options. It can be used with a restart policy
to automatically restart a container if the check fails.
The `HEALTHCHECK` instruction has two forms:
* `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container)
* `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image)
The `HEALTHCHECK` instruction tells Docker how to test a container to check that
it is still working. This can detect cases such as a web server that is stuck in
an infinite loop and unable to handle new connections, even though the server
process is still running.
When a container has a healthcheck specified, it has a _health status_ in
addition to its normal status. This status is initially `starting`. Whenever a
health check passes, it becomes `healthy` (whatever state it was previously in).
After a certain number of consecutive failures, it becomes `unhealthy`.
The options that can appear before `CMD` are:
* `--interval=DURATION` (default: `30s`)
* `--timeout=DURATION` (default: `30s`)
* `--retries=N` (default: `1`)
The health check will first run **interval** seconds after the container is
started, and then again **interval** seconds after each previous check completes.
If a single run of the check takes longer than **timeout** seconds then the check
is considered to have failed.
It takes **retries** consecutive failures of the health check for the container
to be considered `unhealthy`.
There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list
more than one then only the last `HEALTHCHECK` will take effect.
The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK
CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands;
see e.g. `ENTRYPOINT` for details).
The command's exit status indicates the health status of the container.
The possible values are:
- 0: success - the container is healthy and ready for use
- 1: unhealthy - the container is not working correctly
- 2: starting - the container is not ready for use yet, but is working correctly
If the probe returns 2 ("starting") when the container has already moved out of the
"starting" state then it is treated as "unhealthy" instead.
For example, to check every five minutes or so that a web-server is able to
serve the site's main page within three seconds:
HEALTHCHECK --interval=5m --timeout=3s \
CMD curl -f http://localhost/ || exit 1
To help debug failing probes, any output text (UTF-8 encoded) that the command writes
on stdout or stderr will be stored in the health status and can be queried with
`docker inspect`. Such output should be kept short (only the first 4096 bytes
are stored currently).
When the health status of a container changes, a `health_status` event is
generated with the new status. The health status is also displayed in the
`docker ps` output.
Signed-off-by: Thomas Leonard <thomas.leonard@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b6c7becbfe1d76b1250f6d8e991e645e13808a9c
Component: engine
When told to read additional attributes from logs that we've sent to the
journal, pull out all of the non-trusted, non-user fields that we didn't
hard-code ourselves. More of PR#20726 and PR#21889.
When reading entries in the journald log reader, set the time zone on
timestamps that we read to UTC, so that we send UTC values to the client
instead of values that are local to whatever timezone dockerd happens to
be running in.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com> (github: nalind)
Upstream-commit: 0da0a8f9dae35e6a9cb63b9e4a3285e24c001af3
Component: engine
In order to be consistent on creation of volumes for bind mounts
we need to create the source directory if it does not exist and the
user specified he wants it relabeled.
Can not do this lower down the stack, since we are not passing in the
mode fields.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: 322cc99c6962ecb56be3107061eb7f61364d05f8
Component: engine
"copy" can be misleading for humans because Go has its own builtin "copy" function
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
Upstream-commit: 8bce6265fca22c117cf6d69d9ffd4ee78da9db8a
Component: engine
Now daemon/logger.Copier does not use ContainerID
Addendum to #23141
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
Upstream-commit: 518709a87e04f55babc5162861aa4ba9a423f0c8
Component: engine
Log drivers are instantiated on a per-container basis, and passed the
container ID (along with other information) when they're initialized.
Drivers that care about that value are caching the value that they're
passed when they're initialized and using it in favor of the value
contained in Message structures that are passed to them, so the field in
Messages is unused, so we remove it.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Upstream-commit: 7772d270c06cc6c26359b556c95563bae31c1038
Component: engine
device Base should not exists on failure:
--- FAIL: TestDevmapperCreateBase (0.06s)
graphtest_unix.go:122: stat
/tmp/docker-graphtest-079240530/devicemapper/mnt/Base/rootfs/a subdir:
no such file or directory
--- FAIL: TestDevmapperCreateSnap (0.00s)
graphtest_unix.go:219: devmapper: device Base already
exists.
it should be:
--- FAIL: TestDevmapperCreateBase (0.25s)
graphtest_unix.go:122: stat
/tmp/docker-graphtest-828994195/devicemapper/mnt/Base/rootfs/a subdir:
no such file or directory
--- FAIL: TestDevmapperCreateSnap (0.13s)
graphtest_unix.go:122: stat
/tmp/docker-graphtest-828994195/devicemapper/mnt/Snap/rootfs/a subdir:
no such file or directory
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Upstream-commit: b18062122d76a9f53822889874aa12103d491372
Component: engine
Fixes#23031
If a profile is explicitly passed but the system is not built with seccomp support,
error out rather than just running without a profile at all as we would previously.
Behaviour is unchanged if no profile is specified or unconfined is specified.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 6bd797b43fa738efc7eed02e96c21b352aa1c25b
Component: engine
When a partial ID or name is used in `docker ps` filters, today the
entire list of containers is walked even though there are shorter paths
to acquiring the subset of containers that match the ID or name. Also,
container's locks are used during this walk, causing increased lock
contention on a busy daemon.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
Upstream-commit: 8e4a451448376932d57885541be22c9a38de5668
Component: engine
This fix tries to fix build errors caused by updating
aws-sdk-go to v1.1.30.
This fix fixes#22961.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 46ea8ff75d03999e08f77f526e93d8489eb0fabd
Component: engine
1) docker create / run / start: this would create a snapshot device and mounts it onto the filesystem.
So the first time GET operation is called. it will create the rootfs directory and return the path to rootfs
2) Now when I do docker commit. It will call the GET operation second time. This time the refcount will check
that the count > 1 (count=2). so the rootfs already exists, it will just return the path to rootfs.
Earlier it was just returning the mp: /var/lib/docker/devicemapper/mnt/{ID} and hence the inconsistent paths error.
Signed-off-by: Shishir Mahajan <shishir.mahajan@redhat.com>
Upstream-commit: 09d0720e2fb6e30ee018887399f353f93ac2d421
Component: engine
