mirror of https://github.com/docker/cli.git
Add Dockerfile reference docs for using ARG in FROM
Also fixed some examples of using `docker build` to clarify that the positional argument is a directory, not a file. Also fixed some terminology. Dockerfiles contain instructions, not directives or commands. Signed-off-by: Daniel Nephin <dnephin@docker.com>
This commit is contained in:
parent
91ca194713
commit
6e40868ade
|
@ -135,9 +135,11 @@ The instruction is not case-sensitive. However, convention is for them to
|
||||||
be UPPERCASE to distinguish them from arguments more easily.
|
be UPPERCASE to distinguish them from arguments more easily.
|
||||||
|
|
||||||
|
|
||||||
Docker runs instructions in a `Dockerfile` in order. **The first
|
Docker runs instructions in a `Dockerfile` in order. A `Dockerfile` **must
|
||||||
instruction must be \`FROM\`** in order to specify the [*Base
|
start with a \`FROM\` instruction**. The `FROM` instruction specifies the [*Base
|
||||||
Image*](glossary.md#base-image) from which you are building.
|
Image*](glossary.md#base-image) from which you are building. `FROM` may only be
|
||||||
|
proceeded by one or more `ARG` instructions, which declare arguments that are used
|
||||||
|
in `FROM` lines in the `Dockerfile`.
|
||||||
|
|
||||||
Docker treats lines that *begin* with `#` as a comment, unless the line is
|
Docker treats lines that *begin* with `#` as a comment, unless the line is
|
||||||
a valid [parser directive](#parser-directives). A `#` marker anywhere
|
a valid [parser directive](#parser-directives). A `#` marker anywhere
|
||||||
|
@ -356,11 +358,12 @@ the `Dockerfile`:
|
||||||
* `COPY`
|
* `COPY`
|
||||||
* `ENV`
|
* `ENV`
|
||||||
* `EXPOSE`
|
* `EXPOSE`
|
||||||
|
* `FROM`
|
||||||
* `LABEL`
|
* `LABEL`
|
||||||
* `USER`
|
|
||||||
* `WORKDIR`
|
|
||||||
* `VOLUME`
|
|
||||||
* `STOPSIGNAL`
|
* `STOPSIGNAL`
|
||||||
|
* `USER`
|
||||||
|
* `VOLUME`
|
||||||
|
* `WORKDIR`
|
||||||
|
|
||||||
as well as:
|
as well as:
|
||||||
|
|
||||||
|
@ -371,14 +374,14 @@ as well as:
|
||||||
> variable, even when combined with any of the instructions listed above.
|
> variable, even when combined with any of the instructions listed above.
|
||||||
|
|
||||||
Environment variable substitution will use the same value for each variable
|
Environment variable substitution will use the same value for each variable
|
||||||
throughout the entire command. In other words, in this example:
|
throughout the entire instruction. In other words, in this example:
|
||||||
|
|
||||||
ENV abc=hello
|
ENV abc=hello
|
||||||
ENV abc=bye def=$abc
|
ENV abc=bye def=$abc
|
||||||
ENV ghi=$abc
|
ENV ghi=$abc
|
||||||
|
|
||||||
will result in `def` having a value of `hello`, not `bye`. However,
|
will result in `def` having a value of `hello`, not `bye`. However,
|
||||||
`ghi` will have a value of `bye` because it is not part of the same command
|
`ghi` will have a value of `bye` because it is not part of the same instruction
|
||||||
that set `abc` to `bye`.
|
that set `abc` to `bye`.
|
||||||
|
|
||||||
## .dockerignore file
|
## .dockerignore file
|
||||||
|
@ -469,7 +472,7 @@ All of the README files are included. The middle line has no effect because
|
||||||
|
|
||||||
You can even use the `.dockerignore` file to exclude the `Dockerfile`
|
You can even use the `.dockerignore` file to exclude the `Dockerfile`
|
||||||
and `.dockerignore` files. These files are still sent to the daemon
|
and `.dockerignore` files. These files are still sent to the daemon
|
||||||
because it needs them to do its job. But the `ADD` and `COPY` commands
|
because it needs them to do its job. But the `ADD` and `COPY` instructions
|
||||||
do not copy them to the image.
|
do not copy them to the image.
|
||||||
|
|
||||||
Finally, you may want to specify which files to include in the
|
Finally, you may want to specify which files to include in the
|
||||||
|
@ -492,24 +495,40 @@ Or
|
||||||
|
|
||||||
The `FROM` instruction initializes a new build stage and sets the
|
The `FROM` instruction initializes a new build stage and sets the
|
||||||
[*Base Image*](glossary.md#base-image) for subsequent instructions. As such, a
|
[*Base Image*](glossary.md#base-image) for subsequent instructions. As such, a
|
||||||
valid `Dockerfile` must have `FROM` as its first instruction. The image can be
|
valid `Dockerfile` must start with a `FROM` instruction. The image can be
|
||||||
any valid image – it is especially easy to start by **pulling an image** from
|
any valid image – it is especially easy to start by **pulling an image** from
|
||||||
the [*Public Repositories*](https://docs.docker.com/engine/tutorials/dockerrepos/).
|
the [*Public Repositories*](https://docs.docker.com/engine/tutorials/dockerrepos/).
|
||||||
|
|
||||||
- `FROM` must be the first non-comment instruction in the `Dockerfile`.
|
- `ARG` is the only instruction that may proceed `FROM` in the `Dockerfile`.
|
||||||
|
See [Understand how ARG and FROM interact](#understand-how-arg-and-from-interact).
|
||||||
|
|
||||||
- `FROM` can appear multiple times within a single `Dockerfile` in order to
|
- `FROM` can appear multiple times within a single `Dockerfile` to
|
||||||
create multiple images or use one build stage as a dependency for another.
|
create multiple images or use one build stage as a dependency for another.
|
||||||
Simply make a note of the last image ID output by the commit before each new
|
Simply make a note of the last image ID output by the commit before each new
|
||||||
`FROM` command. Each `FROM` command resets all the previous commands.
|
`FROM` instruction. Each `FROM` instruction clears any state created by previous
|
||||||
|
instructions.
|
||||||
|
|
||||||
- Optionally a name can be given to a new build stage. That name can be then
|
- Optionally a name can be given to a new build stage by adding `AS name` to the
|
||||||
used in subsequent `FROM` and `COPY --from=<name|index>` commands to refer back
|
`FROM` instruction. The name can be used in subsequent `FROM` and
|
||||||
to the image built in this stage.
|
`COPY --from=<name|index>` instructions to refer to the image built in this stage.
|
||||||
|
|
||||||
- The `tag` or `digest` values are optional. If you omit either of them, the
|
- The `tag` or `digest` values are optional. If you omit either of them, the
|
||||||
builder assumes a `latest` tag by default. The builder returns an error if it
|
builder assumes a `latest` tag by default. The builder returns an error if it
|
||||||
cannot match the `tag` value.
|
cannot find the `tag` value.
|
||||||
|
|
||||||
|
### Understand how ARG and FROM interact
|
||||||
|
|
||||||
|
`FROM` instructions support variables that are declared by any `ARG`
|
||||||
|
instructions that occur before the first `FROM`.
|
||||||
|
|
||||||
|
```Dockerfile
|
||||||
|
ARG CODE_VERSION=latest
|
||||||
|
FROM base:${CODE_VERSION}
|
||||||
|
CMD /code/run-app
|
||||||
|
|
||||||
|
FROM extras:${CODE_VERSION}
|
||||||
|
CMD /code/run-extras
|
||||||
|
```
|
||||||
|
|
||||||
## RUN
|
## RUN
|
||||||
|
|
||||||
|
@ -947,7 +966,7 @@ Optionally `COPY` accepts a flag `--from=<name|index>` that can be used to set
|
||||||
the source location to a previous build stage (created with `FROM .. AS <name>`)
|
the source location to a previous build stage (created with `FROM .. AS <name>`)
|
||||||
that will be used instead of a build context sent by the user. The flag also
|
that will be used instead of a build context sent by the user. The flag also
|
||||||
accepts a numeric index assigned for all previous build stages started with
|
accepts a numeric index assigned for all previous build stages started with
|
||||||
`FROM` command. In case a build stage with a specified name can't be found an
|
`FROM` instruction. In case a build stage with a specified name can't be found an
|
||||||
image with the same name is attempted to be used instead.
|
image with the same name is attempted to be used instead.
|
||||||
|
|
||||||
`COPY` obeys the following rules:
|
`COPY` obeys the following rules:
|
||||||
|
@ -1353,7 +1372,7 @@ elsewhere. For example, consider this Dockerfile:
|
||||||
A user builds this file by calling:
|
A user builds this file by calling:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ docker build --build-arg user=what_user Dockerfile
|
$ docker build --build-arg user=what_user .
|
||||||
```
|
```
|
||||||
|
|
||||||
The `USER` at line 2 evaluates to `some_user` as the `user` variable is defined on the
|
The `USER` at line 2 evaluates to `some_user` as the `user` variable is defined on the
|
||||||
|
@ -1379,7 +1398,7 @@ this Dockerfile with an `ENV` and `ARG` instruction.
|
||||||
Then, assume this image is built with this command:
|
Then, assume this image is built with this command:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ docker build --build-arg CONT_IMG_VER=v2.0.1 Dockerfile
|
$ docker build --build-arg CONT_IMG_VER=v2.0.1 .
|
||||||
```
|
```
|
||||||
|
|
||||||
In this case, the `RUN` instruction uses `v1.0.0` instead of the `ARG` setting
|
In this case, the `RUN` instruction uses `v1.0.0` instead of the `ARG` setting
|
||||||
|
@ -1401,7 +1420,7 @@ Unlike an `ARG` instruction, `ENV` values are always persisted in the built
|
||||||
image. Consider a docker build without the `--build-arg` flag:
|
image. Consider a docker build without the `--build-arg` flag:
|
||||||
|
|
||||||
```
|
```
|
||||||
$ docker build Dockerfile
|
$ docker build .
|
||||||
```
|
```
|
||||||
|
|
||||||
Using this Dockerfile example, `CONT_IMG_VER` is still persisted in the image but
|
Using this Dockerfile example, `CONT_IMG_VER` is still persisted in the image but
|
||||||
|
|
Loading…
Reference in New Issue