Because of cherry-pick from commit
5efcec77170dd6c4087d4f1fb3695c32d94edfb4 into
components/cli/vendor/github.com/docker/docker
Signed-off-by: Nishant Totla <nishanttotla@gmail.com>
This fixes an issue where if a stop signal is set, and a user sends
SIGKILL, `container.ExitOnNext()` is not set, thus causing the container
to restart.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 114652ab86609e5c0cbfad84f642942b466a0596)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
(cherry picked from commit f1ade82d82e6436971c6b7d08eb1da57ed9ba756)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
The health check process doesn't have all the environment
varialbes in the container or has them set incorrectly.
This patch should fix that problem.
Signed-off-by: Boaz Shuster <ripcurld.github@gmail.com>
(cherry picked from commit 5836d86ac4d617e837d94010aa60384648ab59ea)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
If a service alias is copied to task, then the DNS resolution on the
service name will resolve to service VIP and all of Task-IPs and that
will break the concept of vip based load-balancing resulting in all the
dns-rr caching issues.
This is a regression introduced in #33130
Signed-off-by: Madhu Venugopal <madhu@docker.com>
(cherry picked from commit 38c15531501578b96d34be5ce7f33a0be6be078f)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
the source was missing from the second dispatch
Signed-off-by: Daniel Nephin <dnephin@docker.com>
(cherry picked from commit 3f2604157790408acf5ad05c74cebe105f2b6979)
Since this new version of the CLI resolves image digests for swarm
services by default, and we do not want integration tests to talk to
Docker Hub, update CLI tests to suppress this behavior.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: d012569b78c27e6e52bc5006d9a1d7a2099b1c2b
Component: engine
The --allow-nondistributable-artifacts daemon option specifies
registries to which foreign layers should be pushed. (By default,
foreign layers are not pushed to registries.)
Additionally, to make this option effective, foreign layers are now
pulled from the registry if possible, falling back to the URLs in the
image manifest otherwise.
This option is useful when pushing images containing foreign layers to a
registry on an air-gapped network so hosts on that network can pull the
images without connecting to another server.
Signed-off-by: Noah Treuhaft <noah.treuhaft@docker.com>
Upstream-commit: 67fdf574d5acd6ddccb6ece0ffe0ace1c1608712
Component: engine
URL query encode log details, so that characters like spaces don't make
log parsing ambiguous. Add a helper function to parse these details to a
map, if needed
Add support for details on service logs
Signed-off-by: Drew Erny <drew.erny@docker.com>
Upstream-commit: 68f21418ac1f1acb2874b45878a5938475becf1f
Component: engine
Allows for a plugin type that can be used to scrape metrics.
This is useful because metrics are not neccessarily at a standard
location... `--metrics-addr` must be set, and must currently be a TCP
socket.
Even if metrics are done via a unix socket, there's no guarentee where
the socket may be located on the system, making bind-mounting such a
socket into a container difficult (and racey, failure-prone on daemon
restart).
Metrics plugins side-step this issue by always listening on a unix
socket and then bind-mounting that into a known path in the plugin
container.
Note there has been similar work in the past (and ultimately punted at
the time) for consistent access to the Docker API from within a
container.
Why not add metrics to the Docker API and just provide a plugin with
access to the Docker API? Certainly this can be useful, but gives a lot
of control/access to a plugin that may only need the metrics. We can
look at supporting API plugins separately for this reason.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 0e8e8f0f318656be80e34db9b5e390ffeef3fd0d
Component: engine
This commit in conjunction with a libnetwork side commit,
cleans up the libnetwork SetClusterProvider logic interaction.
The previous code was inducing libnetwork to spawn several go
routines that were racing between each other during the agent
init and close.
A test got added to verify that back to back swarm init and leave
are properly processed and not raise crashes
Signed-off-by: Flavio Crisciani <flavio.crisciani@docker.com>
Upstream-commit: e2ec006797fa14f59bcf7b9c23505ccdf1d3ded3
Component: engine
Allows storing key under any directory. In the case where the
"/etc/docker" directory is not preserved, this file can be
specified to a location where it will be preserved to ensure
the ID does not change across restarts.
Note this key is currently only used today to generate the ID
used in Docker info and for manifest schema v1 pushes. The key
signature and finger on these manifests are not checked or
used any longer for security, deprecated by notary.
Removes old key migration from a pre-release of Docker which put
the key under the home directory and was used to preserve ID used
for swarm v1 after the file moved.
closes#32135
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Upstream-commit: e428c824c35e85a02fffee592b79ab7db1a0c4d2
Component: engine
objects into the REST API responses. In the CLI, display only
whether the nodes' TLS info matches the cluster's TLS info, or
whether the node needs cert rotation.
Signed-off-by: Ying Li <ying.li@docker.com>
Upstream-commit: 64cccedbce86542fc9289ad9cca1dd758f2f21c2
Component: engine
Actually look inside the container to see if the secret data is present
and correct. Test absolute paths, relative paths, and just a basename.
Test the scenario where a service references the same secret under
different targets.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 0da7bd0314a61919428fe036660b822b0bf22d35
Component: engine
This adds support to specify custom container paths for secrets.
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
Upstream-commit: 67d282a5c95ca1d25cd4e9c688e89191f662d448
Component: engine
This reverts commit 7e3a596a63fd8d0ab958132901b6ded81f8b44c0.
Unfortunately, it was pointed out in https://github.com/moby/moby/pull/29076#commitcomment-21831387
that the `socketcall` syscall takes a pointer to a struct so it is not possible to
use seccomp profiles to filter it. This means these cannot be blocked as you can
use `socketcall` to call them regardless, as we currently allow 32 bit syscalls.
Users who wish to block these should use a seccomp profile that blocks all
32 bit syscalls and then just block the non socketcall versions.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: dcf2632945b87acedeea989a5aa36c084a20ae88
Component: engine
