This fix tries to add a flag `--stop-timeout` to specify the timeout value
(in seconds) for the container to stop before SIGKILL is issued. If stop timeout
is not specified then the default timeout (10s) is used.
Additional test cases have been added to cover the change.
This fix is related to #22471. Another pull request will add `--shutdown-timeout`
to daemon for #22471.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: e66d2108911a2fad016205bdd6bf181f7e822c1c
Component: engine
"VolumeDriver.Mount" is being called on container start.
Make the symmetric call on container stop.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: d576509d8ad1ef4770cb3959a792748c8658b0be
Component: engine
This removes the SetStoppedLocking, and
SetRestartingLocking functions, which
were not used anywhere.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: a28c389da109808c5b39da02fdfd24b9e36137fe
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
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
This moves the types for the `engine-api` repo to the existing types
package.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 91e197d614547f0202e6ae9b8a24d88ee131d950
Component: engine
Those are needed in order to reload their value upon docker daemon
restart.
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Upstream-commit: 2998945a54577e24a6414d576bc861e58fa87359
Component: engine
This will add a label to any volume that is shared into a container.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: 5a277c8a4a9107f18211aabd6e332dbafb1a8469
Component: engine
"--restart" and "--rm" are conflict options, if a container is started
with AutoRemove flag, we should forbid the update action for its Restart
Policy.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 4754c64ab5b5bf5ae6f8a3040606296910e6cb19
Component: engine
The memory should always be smaller than memoryswap,
we should error out with message that user know how
to do rather than just an invalid argument error if
user update the memory limit bigger than already set
memory swap.
Signed-off-by: Lei Jitang <leijitang@huawei.com>
Upstream-commit: 92394785fa3e55b19402fc762c030d28b36b6cfc
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 fix tries to fix logrus formatting by removing `f` from
`logrus.[Error|Warn|Debug|Fatal|Panic|Info]f` when formatting string
is not present.
This fix fixes#23459.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: a72b45dbec3caeb3237d1af5aedd04adeb083571
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 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
SELinux labeling should be disabled when using --privileged mode
/etc/hosts, /etc/resolv.conf, /etc/hostname should not be relabeled if they
are volume mounted into the container.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: c3dd6074b0f07cd7e57d677cc06b4c57a302a02f
Component: engine
Currently, using a custom detach key with an invalid sequence, eats a
part of the sequence, making it weird and difficult to enter some key
sequence.
This fixes by keeping the input read when trying to see if it's the key
sequence or not, and "writing" then is the key sequence is not the right
one, preserving the initial input.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 0fb6190243d6101f96283e487cd4911142a05483
Component: engine
