Fixes TOC in dockerfile_best_practices.md
Decided to put the link in a reference word. Closes #14573 Signed-off-by: Vincent Demeester <vincent@sbr.pm>
This commit is contained in:
parent
9264d38424
commit
d03923732f
|
@ -126,14 +126,18 @@ generate new images and the cache will not be used.
|
|||
Below you'll find recommendations for the best way to write the
|
||||
various instructions available for use in a `Dockerfile`.
|
||||
|
||||
### [`FROM`](https://docs.docker.com/reference/builder/#from)
|
||||
### FROM
|
||||
|
||||
[Dockerfile reference for the FROM instruction](https://docs.docker.com/reference/builder/#from)
|
||||
|
||||
Whenever possible, use current Official Repositories as the basis for your
|
||||
image. We recommend the [Debian image](https://registry.hub.docker.com/_/debian/)
|
||||
since it’s very tightly controlled and kept extremely minimal (currently under
|
||||
100 mb), while still being a full distribution.
|
||||
|
||||
### [`RUN`](https://docs.docker.com/reference/builder/#run)
|
||||
### RUN
|
||||
|
||||
[Dockerfile reference for the RUN instruction](https://docs.docker.com/reference/builder/#run)
|
||||
|
||||
As always, to make your `Dockerfile` more readable, understandable, and
|
||||
maintainable, put long or complex `RUN` statements on multiple lines separated
|
||||
|
@ -200,7 +204,9 @@ a given package because it is much easier to read than an instruction like:
|
|||
|
||||
RUN apt-get install -y package-foo && apt-get install -y package-bar
|
||||
|
||||
### [`CMD`](https://docs.docker.com/reference/builder/#cmd)
|
||||
### CMD
|
||||
|
||||
[Dockerfile reference for the CMD instruction](https://docs.docker.com/reference/builder/#cmd)
|
||||
|
||||
The `CMD` instruction should be used to run the software contained by your
|
||||
image, along with any arguments. `CMD` should almost always be used in the
|
||||
|
@ -218,7 +224,9 @@ conjunction with [`ENTRYPOINT`](https://docs.docker.com/reference/builder/#entry
|
|||
you and your expected users are already quite familiar with how `ENTRYPOINT`
|
||||
works.
|
||||
|
||||
### [`EXPOSE`](https://docs.docker.com/reference/builder/#expose)
|
||||
### EXPOSE
|
||||
|
||||
[Dockerfile reference for the EXPOSE instruction](https://docs.docker.com/reference/builder/#expose)
|
||||
|
||||
The `EXPOSE` instruction indicates the ports on which a container will listen
|
||||
for connections. Consequently, you should use the common, traditional port for
|
||||
|
@ -231,7 +239,9 @@ how to map the specified port to the port of their choice.
|
|||
For container linking, Docker provides environment variables for the path from
|
||||
the recipient container back to the source (ie, `MYSQL_PORT_3306_TCP`).
|
||||
|
||||
### [`ENV`](https://docs.docker.com/reference/builder/#env)
|
||||
### ENV
|
||||
|
||||
[Dockerfile reference for the ENV instruction](https://docs.docker.com/reference/builder/#env)
|
||||
|
||||
In order to make new software easier to run, you can use `ENV` to update the
|
||||
`PATH` environment variable for the software your container installs. For
|
||||
|
@ -254,7 +264,10 @@ Similar to having constant variables in a program (as opposed to hard-coding
|
|||
values), this approach lets you change a single `ENV` instruction to
|
||||
auto-magically bump the version of the software in your container.
|
||||
|
||||
### [`ADD`](https://docs.docker.com/reference/builder/#add) or [`COPY`](https://docs.docker.com/reference/builder/#copy)
|
||||
### ADD or COPY
|
||||
|
||||
[Dockerfile reference for the ADD instruction](https://docs.docker.com/reference/builder/#add)<br/>
|
||||
[Dockerfile reference for the COPY instruction](https://docs.docker.com/reference/builder/#copy)
|
||||
|
||||
Although `ADD` and `COPY` are functionally similar, generally speaking, `COPY`
|
||||
is preferred. That’s because it’s more transparent than `ADD`. `COPY` only
|
||||
|
@ -297,7 +310,9 @@ And instead, do something like:
|
|||
For other items (files, directories) that do not require `ADD`’s tar
|
||||
auto-extraction capability, you should always use `COPY`.
|
||||
|
||||
### [`ENTRYPOINT`](https://docs.docker.com/reference/builder/#entrypoint)
|
||||
### ENTRYPOINT
|
||||
|
||||
[Dockerfile reference for the ENTRYPOINT instruction](https://docs.docker.com/reference/builder/#entrypoint)
|
||||
|
||||
The best use for `ENTRYPOINT` is to set the image's main command, allowing that
|
||||
image to be run as though it was that command (and then use `CMD` as the
|
||||
|
@ -347,7 +362,7 @@ exec "$@"
|
|||
> This script uses [the `exec` Bash command](http://wiki.bash-hackers.org/commands/builtin/exec)
|
||||
> so that the final running application becomes the container's PID 1. This allows
|
||||
> the application to receive any Unix signals sent to the container.
|
||||
> See the [`ENTRYPOINT`](https://docs.docker.com/reference/builder/#ENTRYPOINT)
|
||||
> See the [`ENTRYPOINT`](https://docs.docker.com/reference/builder/#entrypoint)
|
||||
> help for more details.
|
||||
|
||||
|
||||
|
@ -371,14 +386,18 @@ Lastly, it could also be used to start a totally different tool, such Bash:
|
|||
|
||||
$ docker run --rm -it postgres bash
|
||||
|
||||
### [`VOLUME`](https://docs.docker.com/reference/builder/#volume)
|
||||
### VOLUME
|
||||
|
||||
[Dockerfile reference for the VOLUME instruction](https://docs.docker.com/reference/builder/#volume)
|
||||
|
||||
The `VOLUME` instruction should be used to expose any database storage area,
|
||||
configuration storage, or files/folders created by your docker container. You
|
||||
are strongly encouraged to use `VOLUME` for any mutable and/or user-serviceable
|
||||
parts of your image.
|
||||
|
||||
### [`USER`](https://docs.docker.com/reference/builder/#user)
|
||||
### USER
|
||||
|
||||
[Dockerfile reference for the USER instruction](https://docs.docker.com/reference/builder/#user)
|
||||
|
||||
If a service can run without privileges, use `USER` to change to a non-root
|
||||
user. Start by creating the user and group in the `Dockerfile` with something
|
||||
|
@ -397,14 +416,18 @@ daemon as root but running it as non-root), you may be able to use
|
|||
Lastly, to reduce layers and complexity, avoid switching `USER` back
|
||||
and forth frequently.
|
||||
|
||||
### [`WORKDIR`](https://docs.docker.com/reference/builder/#workdir)
|
||||
### WORKDIR
|
||||
|
||||
[Dockerfile reference for the WORKDIR instruction](https://docs.docker.com/reference/builder/#workdir)
|
||||
|
||||
For clarity and reliability, you should always use absolute paths for your
|
||||
`WORKDIR`. Also, you should use `WORKDIR` instead of proliferating
|
||||
instructions like `RUN cd … && do-something`, which are hard to read,
|
||||
troubleshoot, and maintain.
|
||||
|
||||
### [`ONBUILD`](https://docs.docker.com/reference/builder/#onbuild)
|
||||
### ONBUILD
|
||||
|
||||
[Dockerfile reference for the ONBUILD instruction](https://docs.docker.com/reference/builder/#onbuild)
|
||||
|
||||
An `ONBUILD` command executes after the current `Dockerfile` build completes.
|
||||
`ONBUILD` executes in any child image derived `FROM` the current image. Think
|
||||
|
@ -438,7 +461,7 @@ These Official Repositories have exemplary `Dockerfile`s:
|
|||
|
||||
## Additional resources:
|
||||
|
||||
* [Dockerfile Reference](https://docs.docker.com/reference/builder/#onbuild)
|
||||
* [Dockerfile Reference](https://docs.docker.com/reference/builder/)
|
||||
* [More about Base Images](https://docs.docker.com/articles/baseimages/)
|
||||
* [More about Automated Builds](https://docs.docker.com/docker-hub/builds/)
|
||||
* [Guidelines for Creating Official
|
||||
|
|
Loading…
Reference in New Issue