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>
Upstream-commit: 56f77d5ade945b3b8816a6c8acb328b7c6dce9a7
Component: engine
Some frontmatter such as the weights, menu stuff, etc is no longer used
'draft=true' becomes 'published: false'
Signed-off-by: Misty Stanley-Jones <misty@docker.com>
Upstream-commit: b30609446d212624e3d4ce814c70130b75c552a0
Component: engine
Linux kernel 4.3 and later supports "ambient capabilities" which are the
only way to pass capabilities to containers running as a non root uid.
Previously there was no way to allow containers not running as root
capabilities in a useful way.
Fix#8460
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 199e19548e93262ab00873c1d761b0d05f866042
Component: engine
The documentation was a bit unhelpful as to what are the default
capabilities, so split.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: bf7a3f010443ecd614baf0450c3193b1f5e52bc2
Component: engine
This was only mentioned in docker create documentation.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 6ba6265d1ad86680ad7f7750ae1f9abb72f1e728
Component: engine
The change to runc in https://github.com/opencontainers/runc/pull/789
was not documented previously. Also say what this affects and clean
up layout of initial table as there was some miscolouration of the
continuation lines.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 3050d9af9b2384baed599be9d7142b4775f89e10
Component: engine
Add a `--network` flag which replaces `--net` without deprecating it
yet. The `--net` flag remains hidden and supported.
Add a `--network-alias` flag which replaces `--net-alias` without deprecating
it yet. The `--net-alias` flag remains hidden and supported.
Signed-off-by: Arnaud Porterie (icecrime) <arnaud.porterie@docker.com>
Upstream-commit: c0c7d5e71586ec8e4d54aef9e061f061e9223cc4
Component: engine
fixing links after moving surfacing tutorials
fixing more links for the newly located tutorials
Signed-off-by: Victoria Bialas <victoria.bialas@docker.com>
Upstream-commit: 8eca8089fa35f652060e86906166dabc42e556f8
Component: engine
Signed-off-by: Shoubhik Bose <sbose78@gmail.com>
Added explanation for the example with image's digest ( as per @thaJeztah 's comment
Signed-off-by: Shoubhik Bose <sbose78@gmail.com>
Wrapped to ~80 chars
Signed-off-by: Shoubhik Bose <sbose78@gmail.com>
Upstream-commit: e6e8c4d700c4510e463eb16fedba51b6e8a3ccd6
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
This fix tries to address the issue raised in #21976 and allows
the options of `--add-host` and `--net=host` to work at the same time.
The documentation has been updated and additional tests have been
added to cover this change.
This fix fixes#21976.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 90bd41a74d57080711678bffa2bc4371020ee3a5
Component: engine
This fix tries to address the issue raised in #21976 and allows
the options of `--dns`, `--dns-search`, `--dns-opt` and `--net=host`
to work at the same time.
The documentation has been updated and additional tests have been
added to cover this change.
This fix fixes#21976.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 23821fe5867427fa36c265bc994b1a2c3cf9b21f
Component: engine
Automatic translation of MLS labels is currently not
supported, so should not be documented as an example.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 841cf6fffb6a821d6c5777871090c9d2bcc95b36
Component: engine
Currently the default seccomp profile is fixed. This changes it
so that it varies depending on the Linux capabilities selected with
the --cap-add and --cap-drop options. Without this, if a user adds
privileges, eg to allow ptrace with --cap-add sys_ptrace then still
cannot actually use ptrace as it is still blocked by seccomp, so
they will probably disable seccomp or use --privileged. With this
change the syscalls that are needed for the capability are also
allowed by the seccomp profile based on the selected capabilities.
While this patch makes it easier to do things with for example
cap_sys_admin enabled, as it will now allow creating new namespaces
and use of mount, it still allows less than --cap-add cap_sys_admin
--security-opt seccomp:unconfined would have previously. It is not
recommended that users run containers with cap_sys_admin as this does
give full access to the host machine.
It also cleans up some architecture specific system calls to be
only selected when needed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: a01c4dc8f85827f32d88522e5153dddc02f11806
Component: engine
Auto-creation of host-directories was marked deprecated in
Docker 1.9, but was decided to be too much of an backward-incompatible
change, so it was decided to keep the feature.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 0f70f53826ac311ca1653827c0d6bc170f300e84
Component: engine
This allows a user to specify explicitly to enable
automatic copying of data from the container path to the volume path.
This does not change the default behavior of automatically copying, but
does allow a user to disable it at runtime.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: b0ac69b67ef79c6c937f84bee3df20a1924ad334
Component: engine
All other options we have use `=` as separator, labels,
log configurations, graph configurations and so on.
We should be consistent and use `=` for the security
options too.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: cb9aeb0413ca75bb3af7fa723a1f2e6b2bdbcb0e
Component: engine
Missing documentation and man pages on seccomp options.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: 450fa7536edc03fb5b071c0d04af534b2f8572ff
Component: engine
Docker creates a UTS namespace by default, even with --net=host, so it
is reasonable to let the user set the hostname. Note that --hostname is
forbidden if the user specifies --uts=host.
Closes#12076
Signed-off-by: Jason Heiss <jheiss@aput.net>
Upstream-commit: 3f445e63b4568845f439c5d30a99ba10603b1938
Component: engine
