This fix tries to address the issue raised in #20083 where
comment is not supported in `.dockerignore`.
This fix updated the processing of `.dockerignore` so that any
lines starting with `#` are ignored, which is similiar to the
behavior of `.gitignore`.
Related documentation has been updated.
Additional tests have been added to cover the changes.
This fix fixes#20083.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
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>
The 'Unix Signals' (https://en.wikipedia.org/wiki/Unix_signal#Handling_signals) wiki explains that:
> 'There are two signals which cannot be intercepted and handled: SIGKILL and SIGSTOP.'
Signed-off-by: kevinmeredith <kevin.m.meredith@gmail.com>
The documentation already says the cache miss happens only at `ARG`
variable usage, not declaration, but there is a very common implicit
usage: `RUN`, which this commit documents even more, improving on #21790.
Also, use `definition` instead of `declaration`: it's the same thing, and
`definition` is already used in this documentation, contrary to
`declaration`.
Also, distinguish between "instructions" and "variables defined by `ARG`
instructions".
Signed-off-by: Thomas Riccardi <riccardi@systran.fr>
Fixing the links
Updating with Seb's comments
Adding weight
Fixing the engine aliases
Updating after Arun pushed
Removing empty file
Signed-off-by: Mary Anthony <mary@docker.com>
Removing old networking.md
Updating dockernetworks.md with images
Adding information on network plugins
Adding blurb about links to docker networking
Updating the working documentation
Adding Overlay Getting Started
Downplaying links by removing refs/examples, adding refs/examples for network.
Updating getting started to reflect networks not links
Pulling out old network material
Updating per discussion with Madhu to add Default docs section
Updating with bridge default
Fix bad merge
Updating with new cluster-advertise behavior
Update working and NetworkSettings examples
Correcting example for default bridge discovery behavior
Entering comments
Fixing broken Markdown Syntax
Updating with comments
Updating all the links
Signed-off-by: Mary Anthony <mary@docker.com>
GitHub flavored markdown is now supported for links and images. Also, ran LinkChecker and FileResolver. Yay!
Fixes from Spider check
Output for docker/docker now goes into engine directory
Signed-off-by: Mary Anthony <mary@docker.com>
- The build-time variables are passed as environment-context for command(s)
run as part of the RUN primitve. These variables are not persisted in environment of
intermediate and final images when passed as context for RUN. The build environment
is prepended to the intermediate continer's command string for aiding cache lookups.
It also helps with build traceability. But this also makes the feature less secure from
point of view of passing build time secrets.
- The build-time variables also get used to expand the symbols used in certain
Dockerfile primitves like ADD, COPY, USER etc, without an explicit prior definiton using a
ENV primitive. These variables get persisted in the intermediate and final images
whenever they are expanded.
- The build-time variables are only expanded or passed to the RUN primtive if they
are defined in Dockerfile using the ARG primitive or belong to list of built-in variables.
HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy, FTP_PROXY and NO_PROXY are built-in
variables that needn't be explicitly defined in Dockerfile to use this feature.
Signed-off-by: Madhav Puri <madhav.puri@gmail.com>
- rewrite intro to Dockerfile reference usage section to remove
references to 'source repository'
- Closes#14714
- Fixes: #8648
- Updating with Seb's comments
Signed-off-by: Mary Anthony <mary@docker.com>
* Clarify the list of supported instructions.
* Clarify behavior of ONBUILD, based on comments by @SvenDowideit, @theJeztah in PR #14735.
* Reorder list of instructions in alphabetical order.
Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com>
The current documentation correctly states that dockerignore pattern
searches are non-recursive. However, the example given for Markdown
files seems to contradict this by saying that `*.md` will exclude *all*
Markdown files. This commit clarifies the situation by explicitly
specifying that `*.md` will only exclude files in the root directory of
the project.
Signed-off-by: Tim Wraight <tim.wraight@tangentlabs.co.uk>
Tweaking for Hugo
Updating the Dockerfile with new sed; fix broken link on Kitematic
Fixing image pull for Dockerfile
Removing docs targets
Signed-off-by: Mary Anthony <mary@docker.com>
Yong Tang
Thomas Leonard
John Howard
Charles Law
kevinmeredith
Thomas Riccardi
mikelinjie
Sven Dowideit
Tomasz Kopczynski
Bastiaan Bakker
Victor Vieux
Prayag Verma
Mary Anthony
Doug Davis
Aidan Hobson Sayers
Shijiang Wei
Mike Brown
Grant Reaber
Charles Chan
Tim Waugh
Madhav Puri
Amen Belayneh
David Calavera
bin liu
Morgan Bauer
Patrick Hemmer
Dharmit Shah
Ankush Agarwal
John Tims
jgeiger
Tim Wraight
Chris McKinnel