This is required to make the libnetwork's namespace mgmt
directory configurable
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: d3af5e3d4bc0aadf25d571835893a9d5bead56b3
Component: engine
There are currently problems with "swarm init" and "swarm join" when an
explicit --listen-addr flag is not provided. swarmkit defaults to
finding the IP address associated with the default route, and in cloud
setups this is often the wrong choice.
Introduce a notion of "advertised address", with the client flag
--advertise-addr, and the daemon flag --swarm-default-advertise-addr to
provide a default. The default listening address is now 0.0.0.0, but a
valid advertised address must be detected or specified.
If no explicit advertised address is specified, error out if there is
more than one usable candidate IP address on the system. This requires a
user to explicitly choose instead of letting swarmkit make the wrong
choice. For the purposes of this autodetection, we ignore certain
interfaces that are unlikely to be relevant (currently docker*).
The user is also required to choose a listen address on swarm init if
they specify an explicit advertise address that is a hostname or an IP
address that's not local to the system. This is a requirement for
overlay networking.
Also support specifying interface names to --listen-addr,
--advertise-addr, and the daemon flag --swarm-default-advertise-addr.
This will fail if the interface has multiple IP addresses (unless it has
a single IPv4 address and a single IPv6 address - then we resolve the
tie in favor of IPv4).
This change also exposes the node's externally-reachable address in
docker info, as requested by #24017.
Make corresponding API and CLI docs changes.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: a0ccd0d42fdb0dd2005f67604cb81a5a6b26787e
Component: engine
When daemon has liveRestore set, daemon shutdown should not shutdown
plugins. Fixes#24759
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: 4a44cf1d4c8e540b67aaa3834291a964c6ab7524
Component: engine
This adds an `--oom-score-adjust` flag to the daemon so that the value
provided can be set for the docker daemon's process. The default value
for the flag is -500. This will allow the docker daemon to have a
less chance of being killed before containers do. The default value for
processes is 0 with a min/max of -1000/1000.
-500 is a good middle ground because it is less than the default for
most processes and still not -1000 which basically means never kill this
process in an OOM condition on the host machine. The only processes on
my machine that have a score less than -500 are dbus at -900 and sshd
and xfce( my window manager ) at -1000. I don't think docker should be
set lower, by default, than dbus or sshd so that is why I chose -500.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: a894aec8d81de5484152a76d76b80809df9edd71
Component: engine
This patch makes sure daemon resources are cleaned up on shutdown if
there are no running containers.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2d5dc94b9b547a9ba73f7b613e358b03fdfb2b84
Component: engine
Now that Windows base images can be loaded directly into docker via "docker load" of a specialized tar file (with docker pull support on the horizon) we no longer have need of the custom images code path that loads images from a shared central location. Removing that code and it's call points.
Signed-off-by: Stefan J. Wernli <swernli@microsoft.com>
Upstream-commit: 3e109f349ff42ea1a0f555b6e645c51d9bc1539b
Component: engine
Most modern distros have the limit for the maximum root keys at 1000000
but some do not. Because we are creating a new key for each container
we need to bump this up as the older distros are having this limit at
200.
Using 1000000 as the limit because that is that most distros are setting
this to now. If someone has this value configured over that we do not
change it.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: ca3e4545aa7d0da3a36fef41d85d02e9f2c4d15d
Component: engine
Its a minor thing but the daemon's output looks like this when there are
no containers to load:
```
INFO[0001] Loading containers: start.
INFO[0001] Loading containers: done.
```
That blank line (or more correctly, the \n) is unnecessary when
there are no containers to load since there is no `.` printed
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 478dd721ab7aca37264897b664dfa2ec953d7048
Component: engine
we store the active sandbox after daemon.containerd.Restore, but there
is a chance the `Restore` will set the container to exit see
(https://github.com/docker/docker/blob/master/libcontainerd/client_linux.go#L469).
so we should check if the container is really running before add it to
activesandbox.
Signed-off-by: Lei Jitang <leijitang@huawei.com>
Upstream-commit: 78f3094518b1f3f498bd2629667877f9a87d452f
Component: engine
This patch introduces a new experimental engine-level plugin management
with a new API and command line. Plugins can be distributed via a Docker
registry, and their lifecycle is managed by the engine.
This makes plugins a first-class construct.
For more background, have a look at issue #20363.
Documentation is in a separate commit. If you want to understand how the
new plugin system works, you can start by reading the documentation.
Note: backwards compatibility with existing plugins is maintained,
albeit they won't benefit from the advantages of the new system.
Signed-off-by: Tibor Vass <tibor@docker.com>
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: f37117045c5398fd3dca8016ea8ca0cb47e7312b
Component: engine
As described in our ROADMAP.md, introduce new Swarm management API
endpoints relying on swarmkit to deploy services. It currently vendors
docker/engine-api changes.
This PR is fully backward compatible (joining a Swarm is an optional
feature of the Engine, and existing commands are not impacted).
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Victor Vieux <vieux@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 534a90a99367af6f6bba1ddcc7eb07506e41f774
Component: engine
This flags enables full support of daemonless containers in docker. It
ensures that docker does not stop containers on shutdown or restore and
properly reconnects to the container when restarted.
This is not the default because of backwards compat but should be the
desired outcome for people running containers in prod.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: d705dab1b1bd0a946d647374325d61fac57736db
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
It feels better to test where it's required than listing everywhere it
is not required.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 72fefc0441d57b59f27bebdb144e0e35c0c63a0d
Component: engine
… and refactor a little bit some daemon on the way.
- Move `SearchRegistryForImages` to a new file (`daemon/search.go`) as
`daemon.go` is getting pretty big.
- `registry.Service` is now an interface (allowing us to decouple it a
little bit and thus unit test easily).
- Add some unit test for `SearchRegistryForImages`.
- Use UniqueExactMatch for search filters
- And use empty restore id for now in client.ContainerStart.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 636c276f67b3cd96a95dec2f6cfc419b7f219892
Component: engine
This fix tries to cover the issue raised in #22463 by adding
filter for events emitted by docker daemon so that user could
utilize filter to receive events of interest.
Documentations have been updated for this fix.
Additional tests have been added to cover the changes in this fix.
This fix fixes#22463.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 62014aaf9abeb4256cb66e7ae06bfdf5a77d1140
Component: engine
This fix tries to cover the issue raised in #22463 by emitting
events for docker daemon so that user could be notified by
scenarios like config reload, etc.
This fix adds the `daemon reload`, and events for docker daemon.
Additional tests have been added to cover the changes in this fix.
This fix fixes#22463.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 382c152a73dfa1d771334ffbe79759c5c3596144
Component: engine
The filtering is made server-side, and the following filters are
supported:
* is-official (boolean)
* is-automated (boolean)
* has-stars (integer)
Signed-off-by: Fabrizio Soppelsa <fsoppelsa@mirantis.com>
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: e009ebdf4c0bf0ff64da8d48eefad63d0644de3e
Component: engine
This fix tries to address issues raised in #20936 and #22443
where `docker pull` or `docker push` fails because of the
concurrent connection failing.
Currently, the number of maximum concurrent connections is
controlled by `maxDownloadConcurrency` and `maxUploadConcurrency`
which are hardcoded to 3 and 5 respectively. Therefore, in
situations where network connections don't support multiple
downloads/uploads, failures may encounter for `docker push`
or `docker pull`.
This fix tries changes `maxDownloadConcurrency` and
`maxUploadConcurrency` to adjustable by passing
`--max-concurrent-uploads` and `--max-concurrent-downloads` to
`docker daemon` command.
The documentation related to docker daemon has been updated.
Additional test case have been added to cover the changes in this fix.
This fix fixes#20936. This fix fixes#22443.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 7368e41c07c21a1e2c6a49abecd1c2fc76404e49
Component: engine
This gives discovery a chance to initialize, particularly if the K/V
store being used is in a container.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2dce79e05ab8f8fd22ca7b2f73121b2d7723f7cf
Component: engine
