A HealthConfig entry was added to the ContainerSpec associated with the
service being created or updated.
Signed-off-by: Cezar Sa Espinola <cezarsa@gmail.com>
The --name flag was inadvertently added to
docker service update, but is not supported,
as it has various side-effects (e.g., existing
tasks are not renamed).
This removes the flag from the service update
command.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This fix tries to address the issue in 24712 and add
`--env-file` file to `docker create service`.
Related documentation has been updated.
An additional integration has been added.
This fix fixes 24712.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
In #23614 `docker inspect` was semantically enhanced to inspect "everything".
Therefore moving its logic to `_docker_container_inspect` was not correct.
This commit moves it back to its original top-level location (`_docker_inspect`)
so that it can be called by `_docker_{container,image}_inspect` and others (will
be added in follow-up PRs).
Parameterization was added in order to get caller-specific behavior.
Signed-off-by: Harald Albers <github@albersweb.de>
containers may specify these cgroup values at runtime. This will allow
processes to change their priority to real-time within the container
when CONFIG_RT_GROUP_SCHED is enabled in the kernel. See #22380.
Also added sanity checks for the new --cpu-rt-runtime and --cpu-rt-period
flags to ensure that that the kernel supports these features and that
runtime is not greater than period.
Daemon will support a --cpu-rt-runtime flag to initialize the parent
cgroup on startup, this prevents the administrator from alotting runtime
to docker after each restart.
There are additional checks that could be added but maybe too far? Check
parent cgroups to ensure values are <= parent, inspecting rtprio ulimit
and issuing a warning.
Signed-off-by: Erik St. Martin <alakriti@gmail.com>
`docker network prune` prunes unused networks, including overlay ones.
`docker system prune` also prunes unused networks.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
The following sentences (introduced in v1.11 via #21160) were misleading for Swarm mode services (>= v1.12)
For networks backed by multi-host network driver, such as Overlay,
this command also shows the container endpoints in other hosts in the
cluster. These endpoints are represented as "ep-{endpoint-id}" in the output.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
This fix tries to address the issue raised in 24392 where
labels with duplicate keys exist in `docker info`, which
contradicts with the specifications in the docs.
The reason for duplicate keys is that labels are stored as
slice of strings in the format of `A=B` (and the input/output).
This fix tries to address this issue by checking conflict
labels when daemon started, and remove duplicate labels (K-V).
The existing `/info` API has not been changed.
An additional integration test has been added to cover the
changes in this fix.
This fix fixes 24392.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Currently, there's no way to restart the tasks of a service without
making an actual change to the service. This leads to us giving awkward
workarounds as in
https://github.com/docker/docker.github.io/pull/178/files, where we tell
people to scale a service up and down to restore balance, or make
unnecessary changes to trigger a restart.
This change adds a --force option to "docker service update", which
forces the service to be updated even if no changes require that.
Since rolling update parameters are respected, the user can use
"docker service --force" to do a rolling restart. For example, the
following is supported:
docker service update --force --update-parallelism 2 \
--update-delay 5s myservice
Since the default value of --update-parallelism is 1, the default
behavior is to restart the service one task at a time.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Cezar Sa Espinola