docs/reference/builder: touch-up code-hints and some minor changes

- use "console" for code-hints, to make process output distinguishable
  from the commands that are executed
- use a consistent prompt for powershell examples
- minor changes in wording around "build context" to reduce confusion
  with `docker context`

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 5dd7a28267)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn 2021-04-20 11:03:34 +02:00
parent 370c28948e
commit 6b48c78672
No known key found for this signature in database
GPG Key ID: 76698F39D527CE8C
1 changed files with 40 additions and 35 deletions

View File

@ -33,11 +33,11 @@ a `Dockerfile` and a *context*. The build's context is the set of files at a
specified location `PATH` or `URL`. The `PATH` is a directory on your local specified location `PATH` or `URL`. The `PATH` is a directory on your local
filesystem. The `URL` is a Git repository location. filesystem. The `URL` is a Git repository location.
A context is processed recursively. So, a `PATH` includes any subdirectories and The build context is processed recursively. So, a `PATH` includes any subdirectories
the `URL` includes the repository and its submodules. This example shows a and the `URL` includes the repository and its submodules. This example shows a
build command that uses the current directory as context: build command that uses the current directory (`.`) as build context:
```bash ```console
$ docker build . $ docker build .
Sending build context to Docker daemon 6.51 MB Sending build context to Docker daemon 6.51 MB
@ -52,8 +52,9 @@ Dockerfile.
> **Warning** > **Warning**
> >
> Do not use your root directory, `/`, as the `PATH` as it causes the build to > Do not use your root directory, `/`, as the `PATH` for your build context, as
> transfer the entire contents of your hard drive to the Docker daemon. > it causes the build to transfer the entire contents of your hard drive to the
> Docker daemon.
{:.warning} {:.warning}
To use a file in the build context, the `Dockerfile` refers to the file specified To use a file in the build context, the `Dockerfile` refers to the file specified
@ -66,28 +67,28 @@ Traditionally, the `Dockerfile` is called `Dockerfile` and located in the root
of the context. You use the `-f` flag with `docker build` to point to a Dockerfile of the context. You use the `-f` flag with `docker build` to point to a Dockerfile
anywhere in your file system. anywhere in your file system.
```bash ```console
$ docker build -f /path/to/a/Dockerfile . $ docker build -f /path/to/a/Dockerfile .
``` ```
You can specify a repository and tag at which to save the new image if You can specify a repository and tag at which to save the new image if
the build succeeds: the build succeeds:
```bash ```console
$ docker build -t shykes/myapp . $ docker build -t shykes/myapp .
``` ```
To tag the image into multiple repositories after the build, To tag the image into multiple repositories after the build,
add multiple `-t` parameters when you run the `build` command: add multiple `-t` parameters when you run the `build` command:
```bash ```console
$ docker build -t shykes/myapp:1.0.2 -t shykes/myapp:latest . $ docker build -t shykes/myapp:1.0.2 -t shykes/myapp:latest .
``` ```
Before the Docker daemon runs the instructions in the `Dockerfile`, it performs Before the Docker daemon runs the instructions in the `Dockerfile`, it performs
a preliminary validation of the `Dockerfile` and returns an error if the syntax is incorrect: a preliminary validation of the `Dockerfile` and returns an error if the syntax is incorrect:
```bash ```console
$ docker build -t test/myapp . $ docker build -t test/myapp .
Sending build context to Docker daemon 2.048 kB Sending build context to Docker daemon 2.048 kB
@ -109,7 +110,7 @@ to accelerate the `docker build` process significantly. This is indicated by
the `Using cache` message in the console output. the `Using cache` message in the console output.
(For more information, see the [`Dockerfile` best practices guide](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/): (For more information, see the [`Dockerfile` best practices guide](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/):
```bash ```console
$ docker build -t svendowideit/ambassador . $ docker build -t svendowideit/ambassador .
Sending build context to Docker daemon 15.36 kB Sending build context to Docker daemon 15.36 kB
@ -413,14 +414,15 @@ RUN dir c:\
Results in: Results in:
```powershell ```console
PS C:\John> docker build -t cmd . PS E:\myproject> docker build -t cmd .
Sending build context to Docker daemon 3.072 kB Sending build context to Docker daemon 3.072 kB
Step 1/2 : FROM microsoft/nanoserver Step 1/2 : FROM microsoft/nanoserver
---> 22738ff49c6d ---> 22738ff49c6d
Step 2/2 : COPY testfile.txt c:\RUN dir c: Step 2/2 : COPY testfile.txt c:\RUN dir c:
GetFileAttributesEx c:RUN: The system cannot find the file specified. GetFileAttributesEx c:RUN: The system cannot find the file specified.
PS C:\John> PS E:\myproject>
``` ```
One solution to the above would be to use `/` as the target of both the `COPY` One solution to the above would be to use `/` as the target of both the `COPY`
@ -441,8 +443,9 @@ RUN dir c:\
Results in: Results in:
```powershell ```console
PS C:\John> docker build -t succeeds --no-cache=true . PS E:\myproject> docker build -t succeeds --no-cache=true .
Sending build context to Docker daemon 3.072 kB Sending build context to Docker daemon 3.072 kB
Step 1/3 : FROM microsoft/nanoserver Step 1/3 : FROM microsoft/nanoserver
---> 22738ff49c6d ---> 22738ff49c6d
@ -467,7 +470,7 @@ Step 3/3 : RUN dir c:\
---> 01c7f3bef04f ---> 01c7f3bef04f
Removing intermediate container a2c157f842f5 Removing intermediate container a2c157f842f5
Successfully built 01c7f3bef04f Successfully built 01c7f3bef04f
PS C:\John> PS E:\myproject>
``` ```
## Environment replacement ## Environment replacement
@ -910,8 +913,8 @@ the most-recently-applied value overrides any previously-set value.
To view an image's labels, use the `docker image inspect` command. You can use To view an image's labels, use the `docker image inspect` command. You can use
the `--format` option to show just the labels; the `--format` option to show just the labels;
```bash ```console
docker image inspect --format='{{json .Config.Labels}}' myimage $ docker image inspect --format='{{json .Config.Labels}}' myimage
``` ```
```json ```json
{ {
@ -980,8 +983,8 @@ port on the host, so the port will not be the same for TCP and UDP.
Regardless of the `EXPOSE` settings, you can override them at runtime by using Regardless of the `EXPOSE` settings, you can override them at runtime by using
the `-p` flag. For example the `-p` flag. For example
```bash ```console
docker run -p 80:80/tcp -p 80:80/udp ... $ docker run -p 80:80/tcp -p 80:80/udp ...
``` ```
To set up port redirection on the host system, see [using the -P flag](run.md#expose-incoming-ports). To set up port redirection on the host system, see [using the -P flag](run.md#expose-incoming-ports).
@ -1397,7 +1400,7 @@ An `ENTRYPOINT` allows you to configure a container that will run as an executab
For example, the following starts nginx with its default content, listening For example, the following starts nginx with its default content, listening
on port 80: on port 80:
```bash ```console
$ docker run -i -t --rm -p 80:80 nginx $ docker run -i -t --rm -p 80:80 nginx
``` ```
@ -1432,7 +1435,7 @@ CMD ["-c"]
When you run the container, you can see that `top` is the only process: When you run the container, you can see that `top` is the only process:
```bash ```console
$ docker run -it --rm --name test top -H $ docker run -it --rm --name test top -H
top - 08:25:00 up 7:27, 0 users, load average: 0.00, 0.01, 0.05 top - 08:25:00 up 7:27, 0 users, load average: 0.00, 0.01, 0.05
@ -1447,7 +1450,7 @@ KiB Swap: 1441840 total, 0 used, 1441840 free. 1324440 cached Mem
To examine the result further, you can use `docker exec`: To examine the result further, you can use `docker exec`:
```bash ```console
$ docker exec -it test ps aux $ docker exec -it test ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
@ -1519,7 +1522,7 @@ If you run this image with `docker run -it --rm -p 80:80 --name test apache`,
you can then examine the container's processes with `docker exec`, or `docker top`, you can then examine the container's processes with `docker exec`, or `docker top`,
and then ask the script to stop Apache: and then ask the script to stop Apache:
```bash ```console
$ docker exec -it test ps aux $ docker exec -it test ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
@ -1579,7 +1582,7 @@ ENTRYPOINT exec top -b
When you run this image, you'll see the single `PID 1` process: When you run this image, you'll see the single `PID 1` process:
```bash ```console
$ docker run -it --rm --name test top $ docker run -it --rm --name test top
Mem: 1704520K used, 352148K free, 0K shrd, 0K buff, 140368121167873K cached Mem: 1704520K used, 352148K free, 0K shrd, 0K buff, 140368121167873K cached
@ -1591,7 +1594,7 @@ Load average: 0.08 0.03 0.05 2/98 6
Which exits cleanly on `docker stop`: Which exits cleanly on `docker stop`:
```bash ```console
$ /usr/bin/time docker stop test $ /usr/bin/time docker stop test
test test
@ -1610,7 +1613,7 @@ CMD --ignored-param1
You can then run it (giving it a name for the next step): You can then run it (giving it a name for the next step):
```bash ```console
$ docker run -it --name test top --ignored-param2 $ docker run -it --name test top --ignored-param2
Mem: 1704184K used, 352484K free, 0K shrd, 0K buff, 140621524238337K cached Mem: 1704184K used, 352484K free, 0K shrd, 0K buff, 140621524238337K cached
@ -1626,7 +1629,7 @@ You can see from the output of `top` that the specified `ENTRYPOINT` is not `PID
If you then run `docker stop test`, the container will not exit cleanly - the If you then run `docker stop test`, the container will not exit cleanly - the
`stop` command will be forced to send a `SIGKILL` after the timeout: `stop` command will be forced to send a `SIGKILL` after the timeout:
```bash ```console
$ docker exec -it test ps aux $ docker exec -it test ps aux
PID USER COMMAND PID USER COMMAND
@ -1859,9 +1862,10 @@ ARG user
USER $user USER $user
# ... # ...
``` ```
A user builds this file by calling: A user builds this file by calling:
```bash ```console
$ docker build --build-arg user=what_user . $ docker build --build-arg user=what_user .
``` ```
@ -1900,7 +1904,7 @@ RUN echo $CONT_IMG_VER
Then, assume this image is built with this command: Then, assume this image is built with this command:
```bash ```console
$ docker build --build-arg CONT_IMG_VER=v2.0.1 . $ docker build --build-arg CONT_IMG_VER=v2.0.1 .
``` ```
@ -1922,7 +1926,7 @@ RUN echo $CONT_IMG_VER
Unlike an `ARG` instruction, `ENV` values are always persisted in the built 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:
```bash ```console
$ docker build . $ docker build .
``` ```
@ -2298,8 +2302,9 @@ RUN c:\example\Execute-MyCmdlet -sample 'hello world'
Resulting in: Resulting in:
```powershell ```console
PS E:\docker\build\shell> docker build -t shell . PS E:\myproject> docker build -t shell .
Sending build context to Docker daemon 4.096 kB Sending build context to Docker daemon 4.096 kB
Step 1/5 : FROM microsoft/nanoserver Step 1/5 : FROM microsoft/nanoserver
---> 22738ff49c6d ---> 22738ff49c6d
@ -2330,7 +2335,7 @@ hello world
---> 8e559e9bf424 ---> 8e559e9bf424
Removing intermediate container be6d8e63fe75 Removing intermediate container be6d8e63fe75
Successfully built 8e559e9bf424 Successfully built 8e559e9bf424
PS E:\docker\build\shell> PS E:\myproject>
``` ```
The `SHELL` instruction could also be used to modify the way in which The `SHELL` instruction could also be used to modify the way in which