This also moves the variable holding the default runtime name from the
engine-api repository into docker repository
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Upstream-commit: 69af7d0d13670b8e2a03a38b4d9a849fc109b338
Component: engine
Return the correct status code on flag parsins errors.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 5ab24342258c70438ab8edf708ebc466b1677f38
Component: engine
Move container options into a struct so that tests should pass.
Remove unused FlagSet arg from Parse
Disable interspersed args on docker run
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: a77f2450c70312f8c26877a18bfe2baa44d4abb9
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
Since 1.9, the following short variant options have been
deprecated in favor of their long variants:
`docker run -c (--cpu-shares)`
`docker build -c (--cpu-shares)`
`docker create -c (--cpu-shares)`
`docker update -c (--cpu-shares)`
However, `-c` is still widely used and is considered as
a convenient option for swarm (see #16271).
This fix undeprecated the command line short
variant options of `-c` and updated the deprecated.md.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: fea7acf0e9f0532af7451a3c3835a0cfabf4fb20
Component: engine
This patch will allow users to specify namespace specific "kernel parameters"
for running inside of a container.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: 9caf7aeefd23263a209c26c8439d26c147972d81
Component: engine
This fix tries to fix the discrepancy between API and CLI on hostname
validation. Previously, the hostname validation was handled at the
CLI interface in runconfig/opts/parse.go and return an error if the
hostname is invalid. However, if an end user use the remote API to
pass the hostname, the error will not be returned immediately.
Instead the error will only be thrown out when the container creation
fails. This creates behavior discrepancy between API and CLI.
In this fix, the hostname validation was moved to
verifyContainerSettings so the behavior will be the same for API and
CLI.
After the change, since CLI does not handle the hostname validation
any more, the previous unit tests about hostname validation on CLI
in runconfig/opts/parse_test.go has to be updated as well because
there is no validation at this stage. All those unit tests are moved
to integration test TestRunTooLongHostname so that the hostname
validation is still properly covered as before.
Note: Since the hostname validation moved to API, the error message
changes from `invalid hostname format for --hostname:` to
`invalid hostname format:` as well because `--hostname` is passed
to CLI only.
This fix fixes#21595.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: ee4bd806ba6ccac0013eb812e7f30bfcfe12d22a
Component: engine
This fix tries to fix issues encountered when running a container with a hostname
that is longer than HOST_NAME_MAX(64).
Previously, `could not synchronise with container process` was generated as the
length of the regex check was missing.
This fix covers the length check so that a hostname that is longer than
HOST_NAME_MAX(64) will be given a correct error message.
Several unit tests cases and additional integration test cases are added as well.
This fix closes#21445.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: fa44b4e81ee87f1c2b39ad335a22795415c8cdf2
Component: engine
it was introduced with #20566 as a result of merge
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: 93f57705110e196dca1cf2b2ce7d261ee97b9e4e
Component: engine
The issue comes from the implementation of volumeSplitN() where a
driver letter (`[a-zA-Z]:`) was assumed to follow either `:`, `/`,
or `\\`.
In Windows driver letter appears in two situations:
a. `^[a-zA-Z]:` (A colon followed by `^[a-zA-Z]:` is OK as colon is
the separator in volume option)
b. A string in the format like `\\?\C:\Windows\...` (UNC).
Therefore, a driver letter can only follow either a `:` or `\\`
This PR removes the condition of `/` before the driver letter so
that options like `-v /tmp/q:/foo` could be handled correctly. A
couple of tests has also been added.
This PR fixes#20122.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 800a7d513d3b80478a7996cb2c357b72f65e0b09
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
This allows users to provide a FQDN as hostname or to use distinct hostname and
domainname parts. Depends on https://github.com/docker/libnetwork/pull/950
Signed-off-by: Tim Hockin <thockin@google.com>
Upstream-commit: 53c5de29217f9633117cb01ada180d1133d76737
Component: engine
Following #19995 and #17409 this PR enables skipping userns re-mapping
when creating a container (or when executing a command). Thus, enabling
privileged containers running side by side with userns remapped
containers.
The feature is enabled by specifying ```--userns:host```, which will not
remapped the user if userns are applied. If this flag is not specified,
the existing behavior (which blocks specific privileged operation)
remains.
Signed-off-by: Liron Levin <liron@twistlock.com>
Upstream-commit: 6993e891d10c760d22e0ea3d455f13858cd0de46
Component: engine
also fix wrong function comment
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Upstream-commit: d266142230bd041c8299eef329cf79a17f8f7478
Component: engine
Make sure the image configuration is not overriden by the default
value in the `create` flag.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: a252516ec19c9c83055a882da894712f2e812ecc
Component: engine
This brings in the container-local alias functionality for containers
connected to u ser-defined networks.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: e221b8a3d64c13178e156fc3ece5e9894dac1603
Component: engine
It's like `MemorySwappiness`, the default value has specific
meaning (default false means enable oom kill).
We need to change it to pointer so we can update it after
container is created.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
(cherry picked from commit 9c2ea42329179c589f5a8991ccf0253eb10fc897)
Conflicts:
vendor/src/github.com/docker/engine-api/types/container/host_config.go
Upstream-commit: f4a687334b1d026c84809fd005e1a82225d1c86f
Component: engine
dockerfile.Config is almost redundant with ImageBuildOptions.
Unify the two so that the latter can be removed. This also
helps build's API endpoint code to be less dependent on package
dockerfile.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: 5190794f1d85d5406611eb69c270df62ac1cdc7f
Component: engine
These validators are only used by runconfig.Parse() or some other part of the
client, so move them into the client-side package.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 0007f5a85935b2edcb08eb2d7e736e4db59157a9
Component: engine
The parse.go file is used almost exclusively in the client. The few small
functions that are used outside of the client could easily be copied out
when the client is extracted, allowing this runconfig/opts package to
move to the client.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 2b7ad47bd2649c3f164e8b57b31fae313045c8f4
Component: engine
