The swarm scope network connected containers with autostart enabled
there was a dependency problem with the cluster to be initialized before
we can autostart them. With the current container restart code happening
before cluster init, these containers were not getting autostarted
properly. Added a fix to delay the container start of those containers
which has atleast one swarm scope endpoint to until after the cluster is
initialized.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Upstream-commit: c9fb551d60584ac4ad01561e2f56b7b7cc9483b9
Component: engine
`Mounts` allows users to specify in a much safer way the volumes they
want to use in the container.
This replaces `Binds` and `Volumes`, which both still exist, but
`Mounts` and `Binds`/`Volumes` are exclussive.
The CLI will continue to use `Binds` and `Volumes` due to concerns with
parsing the volume specs on the client side and cross-platform support
(for now).
The new API follows exactly the services mount API.
Example usage of `Mounts`:
```
$ curl -XPOST localhost:2375/containers/create -d '{
"Image": "alpine:latest",
"HostConfig": {
"Mounts": [{
"Type": "Volume",
"Target": "/foo"
},{
"Type": "bind",
"Source": "/var/run/docker.sock",
"Target": "/var/run/docker.sock",
},{
"Type": "volume",
"Name": "important_data",
"Target": "/var/data",
"ReadOnly": true,
"VolumeOptions": {
"DriverConfig": {
Name: "awesomeStorage",
Options: {"size": "10m"},
Labels: {"some":"label"}
}
}]
}
}'
```
There are currently 2 types of mounts:
- **bind**: Paths on the host that get mounted into the
container. Paths must exist prior to creating the container.
- **volume**: Volumes that persist after the
container is removed.
Not all fields are available in each type, and validation is done to
ensure these fields aren't mixed up between types.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: fc7b904dced4d18d49c8a6c47ae3f415d16d0c43
Component: engine
When the `-t` flag is passed on exec make sure to add the TERM env var
to mirror the expected configuration from run.
Fixes#9299
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 4633f15f13d51530de2438c298a1084c55e4fedf
Component: engine
New driver options:
- `splunk-gzip` - gzip compress all requests to Splunk HEC
(enabled by default)
- `splunk-gzip-level` - change compression level.
Messages are sent in batches by 1000, with frequency of 5 seconds.
Maximum buffer is 10,000 events. If HEC will not be available, Splunk
Logging Driver will keep retrying while it can hold messages in buffer.
Added unit tests for driver.
Signed-off-by: Denis Gladkikh <denis@gladkikh.email>
Upstream-commit: 4907cc7793cf469fc2d6fc0f842d08bd045da569
Component: engine
- So that swarm init will still work w/o specifying the advertise
address when the daemon is running inside a container
Signed-off-by: Alessandro Boch <aboch@docker.com>
Upstream-commit: c0b24c600e30656144522f85b053f015525022da
Component: engine
The restriction is no longer necessary given changes at the runc layer
related to mount options of the rootfs. Also cleaned up the docs on
restrictions left for userns enabled mode. Re-enabled tests related to
--read-only when testing a userns-enabled daemon in integration-cli.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 6062ae5742e49ec1a79073c327f3d1343c218a12
Component: engine
This fix tries to fix 26326 where `docker inspect` will not show
ulimit even when daemon default ulimit has been set.
This fix merge the HostConfig's ulimit with daemon default in
`docker inspect`, so that when daemon is started with `default-ulimit`
and HostConfig's ulimit is not set, `docker inspect` will output
the daemon default.
An integration test has been added to cover the changes.
This fix fixes 26326.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 7d705a7355d650feffc966e08efc0f92297145a8
Component: engine
This PR adds support for running regular containers to be connected to
swarm mode multi-host network so that:
- containers connected to the same network across the cluster can
discover and connect to each other.
- Get access to services(and their associated loadbalancers)
connected to the same network
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Upstream-commit: 99a98ccc14a9427be47c8006e130750710db0a16
Component: engine
