PR 24978 adds hint of of progress to the output of `docker build`
for 1.13, in the format of
```
Step 1/5 ...
...
Step 2/5 ...
...
```
Though some of the docs hasn't been updated.
This fix did a grep in docs and updated the related places.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
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>
This commit updates documentation and change log to include
the preliminary validation of the dockerfile before instructions
in dockerfile is run one-by-one.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
The indexing of steps in the output of `docker build` starts with `Step 1`.
However, there are several places in the docs that start with `Step 0`.
This fix addresses the issue and changes `Step 0` to `Step 1` (and subsequent steps).
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
This may take some time, but start by pointing people at
LABEL instead.
MAINTAINER predates general LABEL and has basically no tooling,
only allows a single item to be added, and is has been
unofficially deprecated for some time, with many images not
including it, but we have never specifically said that it
should be replaced by LABEL as a better more generic metadata
solution.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Add sentece to RUN, CMD, and ENTRYPOINT exec sections making it clear
that it is the shell doing the environment variable expansion.
Signed-off-by: David Dooling <dooling@gmail.com>
The Dockerfile parser does not subsitute ENV variables in any form of
the ENTRYPOINT command. Any substitution, if done, is done by the shell
when the command is executed.
Signed-off-by: David Dooling <dooling@gmail.com>
Several other places in the document it states that when using the shell
form of ENTRYPOINT, CMD and command line arguments are ignored. That is
accurate, this table was not. It is now.
Signed-off-by: David Dooling <dooling@gmail.com>
Instead reserve exit code 2 to be future proof, document that it should
not be used. Implementation-wise, it is considered as unhealthy, but
users should not rely on this as it may change in the future.
Signed-off-by: Tibor Vass <tibor@docker.com>
Looks like there's issues with sourceforge project
pages. Given that sourceforge isn't really what
it used to be, trying to find alternative URLs
where possible.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The reason why the issue occurs is because sh parses the first argument after -c as the whole script to execute.
Everything after isn't executed as one might expect.
When working on the 'fix' I found out the same fix is also done in commit 2af7c5cfe2, except only for one occurrence.
Signed-off-by: Serhat Gülçiçek <serhat+signoff@equil.nl>
fixing links after moving surfacing tutorials
fixing more links for the newly located tutorials
Signed-off-by: Victoria Bialas <victoria.bialas@docker.com>
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>
