docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #13300 from docker/master 

Publish updates from master
This commit is contained in:
Sebastiaan van Stijn 2021-08-06 19:43:43 +02:00 committed by GitHub
parent 49b85844b5 90bb8c20b2
commit 0e183e8201
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
161 changed files with 1503 additions and 1418 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ci-cd/github-actions.md
View File

@ -185,9 +185,9 @@ on:
This ensures that the main CI will only trigger if we tag our commits with `V.n.n.n.` Let’s test this. For example, run the following command:
```bash
git tag -a v1.0.2
git push origin v1.0.2
```console
$ git tag -a v1.0.2
$ git push origin v1.0.2
```
Now, go to GitHub and check your Actions

9
compose/cli-command.md
View File

@ -60,8 +60,11 @@ $ docker-compose disable-v2
### Install on Linux
You can install the new Compose CLI, including Compose V2, using the following install script:
You can install Compose V2 by downloading the adequate binary for your system
from the [project release page](https://github.com/docker/compose-cli/releases){:target="_blank" rel="noopener" class="_"} and copying it into `$HOME/.docker/cli-plugins` as `docker-compose`.
```console
$ curl -L https://raw.githubusercontent.com/docker/compose-cli/main/scripts/install/install_linux.sh | sh
```
$ mkdir -p ~/.docker/cli-plugins/
$ curl -SL https://github.com/docker/compose-cli/releases/download/v2.0.0-beta.6/docker-compose-linux-amd64 -o ~/.docker/cli-plugins/docker-compose
$ chmod +x ~/.docker/cli-plugins/docker-compose
```

4
compose/completion.md
View File

@ -44,7 +44,7 @@ available.
3. Add the following to your `~/.bash_profile`:
```shell
```bash
if [ -f $(brew --prefix)/etc/bash_completion ]; then
. $(brew --prefix)/etc/bash_completion
fi
@ -59,7 +59,7 @@ completion.
2. Add the following lines to `~/.bash_profile`:
```shell
```bash
if [ -f /opt/local/etc/profile.d/bash_completion.sh ]; then
. /opt/local/etc/profile.d/bash_completion.sh
fi

28
compose/environment-variables.md
View File

@ -42,7 +42,7 @@ named `.env`. The `.env` file path is as follows:
in `+v1.28` by limiting the filepath to the project directory.
```shell
```console
$ cat .env
TAG=v1.5
@ -58,7 +58,7 @@ image `webapp:v1.5`. You can verify this with the
[config command](reference/config.md), which prints your resolved application
config to the terminal:
```shell
```console
$ docker-compose config
version: '3'
@ -72,7 +72,7 @@ Values in the shell take precedence over those specified in the `.env` file.
If you set `TAG` to a different value in your shell, the substitution in `image`
uses that instead:
```shell
```console
$ export TAG=v2.0
$ docker-compose config
@ -90,13 +90,13 @@ By passing the file as an argument, you can store it anywhere and name it
appropriately, for example, `.env.ci`, `.env.dev`, `.env.prod`. Passing the file path is
done using the `--env-file` option:
```shell
docker-compose --env-file ./config/.env.dev up
```console
$ docker-compose --env-file ./config/.env.dev up
```
This file path is relative to the current working directory where the Docker Compose
command is executed.
```shell
```console
$ cat .env
TAG=v1.5
@ -113,7 +113,7 @@ services:
The `.env` file is loaded by default:
```shell
```console
$ docker-compose config
version: '3'
services:
@ -122,7 +122,7 @@ services:
```
Passing the `--env-file ` argument overrides the default file path:
```shell
```console
$ docker-compose --env-file ./config/.env.dev config
version: '3'
services:
@ -186,14 +186,14 @@ web:
Similar to `docker run -e`, you can set environment variables on a one-off
container with `docker-compose run -e`:
```shell
docker-compose run -e DEBUG=1 web python console.py
```console
$ docker-compose run -e DEBUG=1 web python console.py
```
You can also pass a variable from the shell by not giving it a value:
```shell
docker-compose run -e DEBUG web python console.py
```console
$ docker-compose run -e DEBUG web python console.py
```
The value of the `DEBUG` variable in the container is taken from the value for
@ -211,7 +211,7 @@ priority used by Compose to choose which value to use:
In the example below, we set the same environment variable on an Environment
file, and the Compose file:
```shell
```console
$ cat ./Docker/api/api.env
NODE_ENV=test
@ -229,7 +229,7 @@ services:
When you run the container, the environment variable defined in the Compose
file takes precedence.
```shell
```console
$ docker-compose exec api node
> process.env.NODE_ENV

2
compose/index.md
View File

@ -158,7 +158,7 @@ is the automated test suite. Automated end-to-end testing requires an
environment in which to run tests. Compose provides a convenient way to create
and destroy isolated testing environments for your test suite. By defining the full environment in a [Compose file](compose-file/index.md), you can create and destroy these environments in just a few commands:
```bash
```console
$ docker-compose up -d
$ ./run_tests
$ docker-compose down

44
compose/install.md
View File

@ -125,8 +125,8 @@ also included below.
1. Run this command to download the current stable release of Docker Compose:
```bash
sudo curl -L "https://github.com/docker/compose/releases/download/{{site.compose_version}}/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
```console
$ sudo curl -L "https://github.com/docker/compose/releases/download/{{site.compose_version}}/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
```
> To install a different version of Compose, substitute `{{site.compose_version}}`
@ -137,8 +137,8 @@ also included below.
2. Apply executable permissions to the binary:
```bash
sudo chmod +x /usr/local/bin/docker-compose
```console
$ sudo chmod +x /usr/local/bin/docker-compose
```
> **Note**: If the command `docker-compose` fails after installation, check your path.
@ -146,8 +146,8 @@ also included below.
For example:
```bash
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
```console
$ sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
```
3. Optionally, install [command completion](completion.md) for the
@ -155,7 +155,7 @@ sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
4. Test the installation.
```bash
```console
$ docker-compose --version
docker-compose version {{site.compose_version}}, build 1110ad01
```
@ -182,13 +182,13 @@ dependencies. See the [virtualenv
tutorial](https://docs.python-guide.org/dev/virtualenvs/) to get
started.
```bash
pip install docker-compose
```console
$ pip install docker-compose
```
If you are not using virtualenv,
```bash
sudo pip install docker-compose
```console
$ sudo pip install docker-compose
```
> pip version 6.0 or greater is required.
@ -198,9 +198,9 @@ sudo pip install docker-compose
Compose can also be run inside a container, from a small bash script wrapper. To
install compose as a container run this command:
```bash
sudo curl -L --fail https://github.com/docker/compose/releases/download/{{site.compose_version}}/run.sh -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
```console
$ sudo curl -L --fail https://github.com/docker/compose/releases/download/{{site.compose_version}}/run.sh -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose
```
</div>
@ -239,29 +239,29 @@ your existing containers (for example, because they have data volumes you want
to preserve), you can use Compose 1.5.x to migrate them with the following
command:
```bash
docker-compose migrate-to-labels
```console
$ docker-compose migrate-to-labels
```
Alternatively, if you're not worried about keeping them, you can remove them.
Compose just creates new ones.
```bash
docker container rm -f -v myapp_web_1 myapp_db_1 ...
```console
$ docker container rm -f -v myapp_web_1 myapp_db_1 ...
```
## Uninstallation
To uninstall Docker Compose if you installed using `curl`:
```bash
sudo rm /usr/local/bin/docker-compose
```console
$ sudo rm /usr/local/bin/docker-compose
```
To uninstall Docker Compose if you installed using `pip`:
```bash
pip uninstall docker-compose
```console
$ pip uninstall docker-compose
```
> Got a "Permission denied" error?

2
compose/reference/ps.md
View File

@ -17,7 +17,7 @@ Options:
Lists containers.
```bash
```console
$ docker-compose ps
Name Command State Ports
---------------------------------------------------------------------------------------------

2
compose/reference/pull.md
View File

@ -38,7 +38,7 @@ services:
If you run `docker-compose pull ServiceName` in the same directory as the `docker-compose.yml` file that defines the service, Docker pulls the associated image. For example, to call the `postgres` image configured as the `db` service in our example, you would run `docker-compose pull db`.
```bash
```console
$ docker-compose pull db
Pulling db (postgres:latest)...
latest: Pulling from library/postgres

2
compose/reference/top.md
View File

@ -11,7 +11,7 @@ Usage: top [SERVICE...]
Displays the running processes.
```bash
```console
$ docker-compose top
compose_service_a_1
PID USER TIME COMMAND

12
config/containers/logging/awslogs.md
View File

@ -38,7 +38,7 @@ Restart Docker for the changes to take effect.
You can set the logging driver for a specific container by using the
`--log-driver` option to `docker run`:
```bash
```console
$ docker run --log-driver=awslogs ...
```
@ -65,7 +65,7 @@ the `awslogs-region` log option or the `AWS_REGION` environment variable to set
the region. By default, if your Docker daemon is running on an EC2 instance
and no region is set, the driver uses the instance's region.
```bash
```console
$ docker run --log-driver=awslogs --log-opt awslogs-region=us-east-1 ...
```
@ -89,7 +89,7 @@ You must specify a
for the `awslogs` logging driver. You can specify the log group with the
`awslogs-group` log option:
```bash
```console
$ docker run --log-driver=awslogs --log-opt awslogs-region=us-east-1 --log-opt awslogs-group=myLogGroup ...
```
@ -112,7 +112,7 @@ Log driver returns an error by default if the log group does not exist. However,
`awslogs-create-group` to `true` to automatically create the log group as needed.
The `awslogs-create-group` option defaults to `false`.
```bash
```console
$ docker run \
--log-driver=awslogs \
--log-opt awslogs-region=us-east-1 \
@ -162,7 +162,7 @@ The format can be expressed as a `strftime` expression of
`[%b %d, %Y %H:%M:%S]`, and the `awslogs-datetime-format` value can be set to
that expression:
```bash
```console
$ docker run \
--log-driver=awslogs \
--log-opt awslogs-region=us-east-1 \
@ -237,7 +237,7 @@ INFO Another message was logged
You can use the regular expression of `^INFO`:
```bash
```console
$ docker run \
--log-driver=awslogs \
--log-opt awslogs-region=us-east-1 \

4
config/containers/logging/gcplogs.md
View File

@ -80,7 +80,7 @@ logging message.
Below is an example of the logging options required to log to the default
logging destination which is discovered by querying the GCE metadata server.
```bash
```console
$ docker run \
--log-driver=gcplogs \
--log-opt labels=location \
@ -98,7 +98,7 @@ container.
An example of the logging options for running outside of GCE (the daemon must be
configured with GOOGLE_APPLICATION_CREDENTIALS):
```bash
```console
$ docker run \
--log-driver=gcplogs \
--log-opt gcp-project=test-project

4
config/containers/logging/gelf.md
View File

@ -50,7 +50,7 @@ Restart Docker for the changes to take effect.
You can set the logging driver for a specific container by setting the
`--log-driver` flag when using `docker container create` or `docker run`:
```bash
```console
$ docker run \
--log-driver gelf –-log-opt gelf-address=udp://1.2.3.4:12201 \
alpine echo hello world
@ -82,7 +82,7 @@ The `gelf` logging driver supports the following options:
This example configures the container to use the GELF server running at
`192.168.0.42` on port `12201`.
```bash
```console
$ docker run -dit \
--log-driver=gelf \
--log-opt gelf-address=udp://192.168.0.42:12201 \

12
config/containers/logging/journald.md
View File

@ -45,7 +45,7 @@ Restart Docker for the changes to take effect.
To configure the logging driver for a specific container, use the `--log-driver`
flag on the `docker run` command.
```bash
```console
$ docker run --log-driver=journald ...
```
@ -68,7 +68,7 @@ message.
Below is an example of the logging options required to log to journald.
```bash
```console
$ docker run \
--log-driver=journald \
--log-opt labels=location \
@ -96,21 +96,21 @@ Use the `journalctl` command to retrieve log messages. You can apply filter
expressions to limit the retrieved messages to those associated with a specific
container:
```bash
```console
$ sudo journalctl CONTAINER_NAME=webserver
```
You can use additional filters to further limit the messages retrieved. The `-b`
flag only retrieves messages generated since the last system boot:
```bash
```console
$ sudo journalctl -b CONTAINER_NAME=webserver
```
The `-o` flag specifies the format for the retried log messages. Use `-o json`
to return the log messages in JSON format.
```bash
```console
$ sudo journalctl -o json CONTAINER_NAME=webserver
```
@ -121,7 +121,7 @@ when retrieving log messages.
The reason for that is that `\r` is appended to the end of the line and
`journalctl` doesn't strip it automatically unless `--all` is set:
```bash
```console
$ sudo journalctl -b CONTAINER_NAME=webserver --all
```

4
config/containers/logging/json-file.md
View File

@ -58,7 +58,7 @@ Existing containers do not use the new logging configuration.
You can set the logging driver for a specific container by using the
`--log-driver` flag to `docker container create` or `docker run`:
```bash
```console
$ docker run \
--log-driver json-file --log-opt max-size=10m \
alpine echo hello world
@ -84,6 +84,6 @@ The `json-file` logging driver supports the following logging options:
This example starts an `alpine` container which can have a maximum of 3 log
files no larger than 10 megabytes each.
```bash
```console
$ docker run -it --log-opt max-size=10m --log-opt max-file=3 alpine ash
```

4
config/containers/logging/local.md
View File

@ -48,7 +48,7 @@ Restart Docker for the changes to take effect for newly created containers. Exis
You can set the logging driver for a specific container by using the
`--log-driver` flag to `docker container create` or `docker run`:
```bash
```console
$ docker run \
--log-driver local --log-opt max-size=10m \
alpine echo hello world
@ -69,6 +69,6 @@ The `local` logging driver supports the following logging options:
This example starts an `alpine` container which can have a maximum of 3 log
files no larger than 10 megabytes each.
```bash
```console
$ docker run -it --log-driver local --log-opt max-size=10m --log-opt max-file=3 alpine ash
```

2
config/containers/logging/log_tags.md
View File

@ -11,7 +11,7 @@ The `tag` log option specifies how to format a tag that identifies the
container's log messages. By default, the system uses the first 12 characters of
the container ID. To override this behavior, specify a `tag` option:
```bash
```console
$ docker run --log-driver=fluentd --log-opt fluentd-address=myhost.local:24224 --log-opt tag="mailer"
```

10
config/containers/logging/logentries.md
View File

@ -19,21 +19,21 @@ Some options are supported by specifying `--log-opt` as many times as needed:
Configure the default logging driver by passing the
`--log-driver` option to the Docker daemon:
```bash
```console
$ dockerd --log-driver=logentries
```
To set the logging driver for a specific container, pass the
`--log-driver` option to `docker run`:
```bash
```console
$ docker run --log-driver=logentries ...
```
Before using this logging driver, you need to create a new Log Set in the
Logentries web interface and pass the token of that log set to Docker:
```bash
```console
$ docker run --log-driver=logentries --log-opt logentries-token=abcd1234-12ab-34cd-5678-0123456789ab
```
@ -45,7 +45,7 @@ Users can use the `--log-opt NAME=VALUE` flag to specify additional Logentries l
You need to provide your log set token for logentries driver to work:
```bash
```console
$ docker run --log-driver=logentries --log-opt logentries-token=abcd1234-12ab-34cd-5678-0123456789ab
```
@ -53,6 +53,6 @@ $ docker run --log-driver=logentries --log-opt logentries-token=abcd1234-12ab-34
You could specify whether to send log message wrapped into container data (default) or to send raw log line
```bash
```console
$ docker run --log-driver=logentries --log-opt logentries-token=abcd1234-12ab-34cd-5678-0123456789ab --log-opt line-only=true
```

2
config/containers/logging/splunk.md
View File

@ -92,7 +92,7 @@ scheme. This is used for verification. The `SplunkServerDefaultCert` is
automatically generated by Splunk certificates.
{% raw %}
```bash
```console
$ docker run \
--log-driver=splunk \
--log-opt splunk-token=176FCEBF-4CF5-4EDF-91BC-703796522D20 \

4
config/containers/logging/syslog.md
View File

@ -64,8 +64,8 @@ Restart Docker for the changes to take effect.
You can set the logging driver for a specific container by using the
`--log-driver` flag to `docker container create` or `docker run`:
```bash
docker run \
```console
$ docker run \
--log-driver syslog --log-opt syslog-address=udp://1.2.3.4:1111 \
alpine echo hello world
```

20
config/containers/resource_constraints.md
View File

@ -188,12 +188,12 @@ the container's cgroup on the host machine.
If you have 1 CPU, each of the following commands guarantees the container at
most 50% of the CPU every second.
```bash
docker run -it --cpus=".5" ubuntu /bin/bash
```console
$ docker run -it --cpus=".5" ubuntu /bin/bash
```
Which is the equivalent to manually specifying `--cpu-period` and `--cpu-quota`;
```bash
```console
$ docker run -it --cpu-period=100000 --cpu-quota=50000 ubuntu /bin/bash
```
@ -246,7 +246,7 @@ documentation or the `ulimit` command for information on appropriate values.
The following example command sets each of these three flags on a `debian:jessie`
container.
```bash
```console
$ docker run -it \
--cpu-rt-runtime=950000 \
--ulimit rtprio=99 \
@ -273,13 +273,13 @@ Verify that your GPU is running and accessible.
Follow the instructions at (https://nvidia.github.io/nvidia-container-runtime/)
and then run this command:
```bash
```console
$ apt-get install nvidia-container-runtime
```
Ensure the `nvidia-container-runtime-hook` is accessible from `$PATH`.
```bash
```console
$ which nvidia-container-runtime-hook
```
@ -290,7 +290,7 @@ Restart the Docker daemon.
Include the `--gpus` flag when you start a container to access GPU resources.
Specify how many GPUs to use. For example:
```bash
```console
$ docker run -it --rm --gpus all ubuntu nvidia-smi
```
@ -316,13 +316,13 @@ Exposes all available GPUs and returns a result akin to the following:
Use the `device` option to specify GPUs. For example:
```bash
```console
$ docker run -it --rm --gpus device=GPU-3a23c669-1f69-c64e-cf85-44e9b07e7a2a ubuntu nvidia-smi
```
Exposes that specific GPU.
```bash
```console
$ docker run -it --rm --gpus '"device=0,2"' ubuntu nvidia-smi
```
@ -337,7 +337,7 @@ Exposes the first and third GPUs.
You can set capabilities manually. For example, on Ubuntu you can run the
following:
```bash
```console
$ docker run --gpus 'all,capabilities=utility' --rm ubuntu nvidia-smi
```

14
config/containers/runmetrics.md
View File

@ -17,7 +17,7 @@ and network IO metrics.
The following is a sample output from the `docker stats` command
```bash
```console
$ docker stats redis1 redis2
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O
@ -50,7 +50,7 @@ corresponding to existing containers.
To figure out where your control groups are mounted, you can run:
```bash
```console
$ grep cgroup /proc/mounts
```
@ -279,7 +279,7 @@ an interface) can do some serious accounting.
For instance, you can setup a rule to account for the outbound HTTP
traffic on a web server:
```bash
```console
$ iptables -I OUTPUT -p tcp --sport 80
```
@ -289,7 +289,7 @@ rule.
Later, you can check the values of the counters, with:
```bash
```console
$ iptables -nxvL OUTPUT
```
@ -331,13 +331,13 @@ Containers can interact with their sub-containers, though.
The exact format of the command is:
```bash
```console
$ ip netns exec <nsname> <command...>
```
For example:
```bash
```console
$ ip netns exec mycontainer netstat -i
```
@ -369,7 +369,7 @@ cgroup (and thus, in the container). Pick any one of the PIDs.
Putting everything together, if the "short ID" of a container is held in
the environment variable `$CID`, then you can do this:
```bash
```console
$ TASKS=/sys/fs/cgroup/devices/docker/$CID*/tasks
$ PID=$(head -n 1 $TASKS)
$ mkdir -p /var/run/netns

6
config/containers/start-containers-automatically.md
View File

@ -34,19 +34,19 @@ any of the following:
The following example starts a Redis container and configures it to always
restart unless it is explicitly stopped or Docker is restarted.
```bash
```console
$ docker run -d --restart unless-stopped redis
```
This command changes the restart policy for an already running container named `redis`.
```bash
```console
$ docker update --restart unless-stopped redis
```
And this command will ensure all currently running containers will be restarted unless stopped.
```bash
```console
$ docker update --restart unless-stopped $(docker ps -q)
```

10
config/daemon/index.md
View File

@ -48,7 +48,7 @@ configuration.
When you start Docker this way, it runs in the foreground and sends its logs
directly to your terminal.
```bash
```console
$ dockerd
INFO[0000] +job init_networkdriver()
@ -98,8 +98,8 @@ This can be useful for troubleshooting problems.
Here's an example of how to manually start the Docker daemon, using the same
configurations as above:
```bash
dockerd --debug \
```console
$ dockerd --debug \
--tls=true \
--tlscert=/var/docker/server.pem \
--tlskey=/var/docker/serverkey.pem \
@ -274,7 +274,7 @@ Docker platform.
3. Send a `HUP` signal to the daemon to cause it to reload its configuration.
On Linux hosts, use the following command.
```bash
```console
$ sudo kill -SIGHUP $(pidof dockerd)
```
@ -292,7 +292,7 @@ by sending a `SIGUSR1` signal to the daemon.
- **Linux**:
```bash
```console
$ sudo kill -SIGUSR1 $(pidof dockerd)
```

2
config/daemon/ipv6.md
View File

@ -27,7 +27,7 @@ either IPv4 or IPv6 (or both) with any container, service, or network.
2. Reload the Docker configuration file.
```bash
```console
$ systemctl reload docker
```

8
config/daemon/prometheus.md
View File

@ -210,7 +210,7 @@ Next, start a single-replica Prometheus service using this configuration.
<div id="linux-run" class="tab-pane fade in active" markdown="1">
```bash
```console
$ docker service create --replicas 1 --name my-prometheus \
--mount type=bind,source=/tmp/prometheus.yml,destination=/etc/prometheus/prometheus.yml \
--publish published=9090,target=9090,protocol=tcp \
@ -220,7 +220,7 @@ $ docker service create --replicas 1 --name my-prometheus \
</div><!-- linux -->
<div id="mac-run" class="tab-pane fade" markdown="1">
```bash
```console
$ docker service create --replicas 1 --name my-prometheus \
--mount type=bind,source=/tmp/prometheus.yml,destination=/etc/prometheus/prometheus.yml \
--publish published=9090,target=9090,protocol=tcp \
@ -263,7 +263,7 @@ To make the graph more interesting, create some network actions by starting
a service with 10 tasks that just ping Docker non-stop (you can change the
ping target to anything you like):
```bash
```console
$ docker service create \
--replicas 10 \
--name ping_service \
@ -278,7 +278,7 @@ your graph.
When you are ready, stop and remove the `ping_service` service, so that you
are not flooding a host with pings for no reason.
```bash
```console
$ docker service remove ping_service
```

8
config/formatting.md
View File

@ -20,8 +20,8 @@ include examples of customizing the output format.
> In a Posix shell, you can run the following with a single quote:
>
> {% raw %}
> ```bash
> docker inspect --format '{{join .Args " , "}}'
> ```console
> $ docker inspect --format '{{join .Args " , "}}'
> ```
> {% endraw %}
>
@ -29,8 +29,8 @@ include examples of customizing the output format.
> escape the double quotes inside the params as follows:
>
> {% raw %}
> ```bash
> docker inspect --format '{{join .Args \" , \"}}'
> ```console
> $ docker inspect --format '{{join .Args \" , \"}}'
> ```
> {% endraw %}
>

22
config/pruning.md
View File

@ -21,7 +21,7 @@ default, `docker image prune` only cleans up _dangling_ images. A dangling image
is one that is not tagged and is not referenced by any container. To remove
dangling images:
```bash
```console
$ docker image prune
WARNING! This will remove all dangling images.
@ -31,7 +31,7 @@ Are you sure you want to continue? [y/N] y
To remove all images which are not used by existing containers, use the `-a`
flag:
```bash
```console
$ docker image prune -a
WARNING! This will remove all images without at least one container associated to them.
@ -45,7 +45,7 @@ You can limit which images are pruned using filtering expressions with the
`--filter` flag. For example, to only consider images created more than 24
hours ago:
```bash
```console
$ docker image prune -a --filter "until=24h"
```
@ -62,7 +62,7 @@ exist, especially on a development system! A stopped container's writable layers
still take up disk space. To clean this up, you can use the `docker container
prune` command.
```bash
```console
$ docker container prune
WARNING! This will remove all stopped containers.
@ -76,7 +76,7 @@ By default, all stopped containers are removed. You can limit the scope using
the `--filter` flag. For instance, the following command only removes
stopped containers older than 24 hours:
```bash
```console
$ docker container prune --filter "until=24h"
```
@ -90,7 +90,7 @@ Volumes can be used by one or more containers, and take up space on the Docker
host. Volumes are never removed automatically, because to do so could destroy
data.
```bash
```console
$ docker volume prune
WARNING! This will remove all volumes not used by at least one container.
@ -104,7 +104,7 @@ By default, all unused volumes are removed. You can limit the scope using
the `--filter` flag. For instance, the following command only removes
volumes which are not labelled with the `keep` label:
```bash
```console
$ docker volume prune --filter "label!=keep"
```
@ -119,7 +119,7 @@ rules, bridge network devices, and routing table entries. To clean these things
up, you can use `docker network prune` to clean up networks which aren't used
by any containers.
```bash
```console
$ docker network prune
WARNING! This will remove all networks not used by at least one container.
@ -133,7 +133,7 @@ By default, all unused networks are removed. You can limit the scope using
the `--filter` flag. For instance, the following command only removes
networks older than 24 hours:
```bash
```console
$ docker network prune --filter "until=24h"
```
@ -147,7 +147,7 @@ The `docker system prune` command is a shortcut that prunes images, containers,
and networks. Volumes are not pruned by default, and you must specify the
`--volumes` flag for `docker system prune` to prune volumes.
```bash
```console
$ docker system prune
WARNING! This will remove:
@ -160,7 +160,7 @@ Are you sure you want to continue? [y/N] y
To also prune volumes, add the `--volumes` flag:
```bash
```console
$ docker system prune --volumes
WARNING! This will remove:

4
desktop/faqs.md
View File

@ -38,8 +38,8 @@ variables, specify these to connect to Docker instances through Unix sockets.
For example:
```bash
export DOCKER_HOST=unix:///var/run/docker.sock
```console
$ export DOCKER_HOST=unix:///var/run/docker.sock
```
Docker Desktop Windows users can connect to the Docker Engine through a **named pipe**: `npipe:////./pipe/docker_engine`, or **TCP socket** at this URL:

6
desktop/kubernetes.md
View File

@ -21,7 +21,7 @@ The Kubernetes client command `kubectl` is included and configured to connect
to the local Kubernetes server. If you have already installed `kubectl` and
pointing to some other environment, such as `minikube` or a GKE cluster, ensure you change the context so that `kubectl` is pointing to `docker-desktop`:
```bash
```console
$ kubectl config get-contexts
$ kubectl config use-context docker-desktop
```
@ -62,8 +62,8 @@ the `PATH`.
You can test the command by listing the available nodes:
```bash
kubectl get nodes
```console
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
docker-desktop Ready master 3h v1.19.7

10
develop/develop-images/baseimages.md
View File

@ -73,8 +73,8 @@ Assuming you built the "hello" executable example by using the source code at
and you compiled it with the `-static` flag, you can build this Docker
image using this `docker build` command:
```bash
docker build --tag hello .
```console
$ docker build --tag hello .
```
Don't forget the `.` character at the end, which sets the build context to the
@ -84,7 +84,7 @@ current directory.
> you need a Linux binary, rather than a Mac or Windows binary.
> You can use a Docker container to build it:
>
> ```bash
> ```console
> $ docker run --rm -it -v $PWD:/build ubuntu:20.04
>
> container# apt-get update && apt-get install build-essential
@ -94,8 +94,8 @@ current directory.
To run your new image, use the `docker run` command:
```bash
docker run --rm hello
```console
$ docker run --rm hello
```
This example creates the hello-world image used in the tutorials.

4
develop/develop-images/build_enhancements.md
View File

@ -37,7 +37,7 @@ the [Dockerfile reference](/engine/reference/builder/) page.
Easiest way from a fresh install of docker is to set the `DOCKER_BUILDKIT=1`
environment variable when invoking the `docker build` command, such as:
```bash
```console
$ DOCKER_BUILDKIT=1 docker build .
```
@ -226,7 +226,7 @@ RUN --mount=type=ssh git clone git@github.com:myorg/myproject.git myproject
Once the `Dockerfile` is created, use the `--ssh` option for connectivity with
the SSH agent.
```bash
```console
$ docker build --ssh default .
```

32
develop/develop-images/dockerfile_best-practices.md
View File

@ -73,21 +73,21 @@ context.
> a text file named `hello` and create a Dockerfile that runs `cat` on it. Build
> the image from within the build context (`.`):
>
> ```shell
> mkdir myproject && cd myproject
> echo "hello" > hello
> echo -e "FROM busybox\nCOPY /hello /\nRUN cat /hello" > Dockerfile
> docker build -t helloapp:v1 .
> ```console
> $ mkdir myproject && cd myproject
> $ echo "hello" > hello
> $ echo -e "FROM busybox\nCOPY /hello /\nRUN cat /hello" > Dockerfile
> $ docker build -t helloapp:v1 .
> ```
>
> Move `Dockerfile` and `hello` into separate directories and build a second
> version of the image (without relying on cache from the last build). Use `-f`
> to point to the Dockerfile and specify the directory of the build context:
>
> ```shell
> mkdir -p dockerfiles context
> mv Dockerfile dockerfiles && mv hello context
> docker build --no-cache -t helloapp:v2 -f dockerfiles/Dockerfile context
> ```console
> $ mkdir -p dockerfiles context
> $ mv Dockerfile dockerfiles && mv hello context
> $ docker build --no-cache -t helloapp:v2 -f dockerfiles/Dockerfile context
> ```
Inadvertently including files that are not necessary for building an image
@ -664,7 +664,7 @@ RUN echo $ADMIN_USER > ./mark
RUN unset ADMIN_USER
```
```bash
```console
$ docker run --rm test sh -c 'echo $ADMIN_USER'
mark
@ -687,7 +687,7 @@ RUN export ADMIN_USER="mark" \
CMD sh
```
```bash
```console
$ docker run --rm test sh -c 'echo $ADMIN_USER'
```
@ -762,13 +762,13 @@ CMD ["--help"]
Now the image can be run like this to show the command's help:
```bash
```console
$ docker run s3cmd
```
Or using the right parameters to execute a command:
```bash
```console
$ docker run s3cmd ls s3://mybucket
```
@ -819,19 +819,19 @@ This script allows the user to interact with Postgres in several ways.
It can simply start Postgres:
```bash
```console
$ docker run postgres
```
Or, it can be used to run Postgres and pass parameters to the server:
```bash
```console
$ docker run postgres postgres --help
```
Lastly, it could also be used to start a totally different tool, such as Bash:
```bash
```console
$ docker run --rm -it postgres bash
```

4
develop/develop-images/multistage-build.md
View File

@ -116,7 +116,7 @@ CMD ["./app"]
You only need the single Dockerfile. You don't need a separate build script,
either. Just run `docker build`.
```bash
```console
$ docker build -t alexellis2/href-counter:latest .
```
@ -160,7 +160,7 @@ Dockerfile including every stage. You can specify a target build stage. The
following command assumes you are using the previous `Dockerfile` but stops at
the stage named `builder`:
```bash
```console
$ docker build --target builder -t alexellis2/href-counter:latest .
```

4
docker-for-mac/apple-silicon.md
View File

@ -24,8 +24,8 @@ Download Docker Desktop for Mac on Apple silicon:
You must install **Rosetta 2** as some binaries are still Darwin/AMD64. To install Rosetta 2 manually from the command line, run the following command:
```shell
softwareupdate --install-rosetta
```console
$ softwareupdate --install-rosetta
```
We expect to fix this in a future release.

20
docker-for-mac/index.md
View File

@ -175,8 +175,8 @@ You can see whether you are running experimental mode at the command line. If
`Experimental` is `true`, then Docker is running in experimental mode, as shown
here. (If `false`, Experimental mode is off.)
```bash
> docker version
```console
$ docker version
Client: Docker Engine - Community
Version: 19.03.1
@ -243,7 +243,7 @@ To manually add a custom, self-signed certificate, start by adding the
certificate to the macOS keychain, which is picked up by Docker Desktop. Here is
an example:
```bash
```console
$ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt
```
@ -347,13 +347,13 @@ ln -s $etc/docker-compose.bash-completion $(brew --prefix)/etc/bash_completion.d
Add the following to your `~/.bash_profile`:
```shell
```bash
[ -f /usr/local/etc/bash_completion ] && . /usr/local/etc/bash_completion
```
OR
```shell
```bash
if [ -f $(brew --prefix)/etc/bash_completion ]; then
. $(brew --prefix)/etc/bash_completion
fi
@ -383,15 +383,15 @@ directory.
Create the `completions` directory:
```bash
mkdir -p ~/.config/fish/completions
```console
$ mkdir -p ~/.config/fish/completions
```
Now add fish completions from docker.
```bash
ln -shi /Applications/Docker.app/Contents/Resources/etc/docker.fish-completion ~/.config/fish/completions/docker.fish
ln -shi /Applications/Docker.app/Contents/Resources/etc/docker-compose.fish-completion ~/.config/fish/completions/docker-compose.fish
```console
$ ln -shi /Applications/Docker.app/Contents/Resources/etc/docker.fish-completion ~/.config/fish/completions/docker.fish
$ ln -shi /Applications/Docker.app/Contents/Resources/etc/docker-compose.fish-completion ~/.config/fish/completions/docker-compose.fish
```
## Give feedback and get help

4
docker-for-mac/install.md
View File

@ -45,8 +45,8 @@ Your Mac must meet the following requirements to successfully install Docker Des
- You must install **Rosetta 2** as some binaries are still Darwin/AMD64. To install Rosetta 2 manually from the command line, run the following command:
```bash
softwareupdate --install-rosetta
```console
$ softwareupdate --install-rosetta
```
For more information, see [Docker Desktop for Apple silicon](apple-silicon.md).

6
docker-for-mac/networking.md
View File

@ -109,14 +109,14 @@ overlay network, not a bridge network, as these are not routed.
The command to run the `nginx` webserver shown in [Getting Started](index.md#explore-the-application)
is an example of this.
```bash
```console
$ docker run -d -p 80:80 --name webserver nginx
```
To clarify the syntax, the following two commands both expose port `80` on the
container to port `8000` on the host:
```bash
```console
$ docker run --publish 8000:80 --name webserver nginx
$ docker run -p 8000:80 --name webserver nginx
@ -126,7 +126,7 @@ To expose all ports, use the `-P` flag. For example, the following command
starts a container (in detached mode) and the `-P` exposes all ports on the
container to random ports on the host.
```bash
```console
$ docker run -d -P --name webserver nginx
```

8
docker-for-mac/space.md
View File

@ -45,19 +45,19 @@ docker system df -v
Alternatively, to list images, run:
```bash
```console
$ docker image ls
```
and then, to list containers, run:
```bash
```console
$ docker container ls -a
```
If there are lots of redundant objects, run the command:
```bash
```console
$ docker system prune
```
@ -77,7 +77,7 @@ $ docker run --privileged --pid=host docker/desktop-reclaim-space
Note that many tools report the maximum file size, not the actual file size.
To query the actual size of the file on the host from a terminal, run:
```bash
```console
$ cd ~/Library/Containers/com.docker.docker/Data
$ cd vms/0/data
$ ls -klsh Docker.raw

39
docker-for-mac/troubleshoot.md
View File

@ -40,17 +40,18 @@ system.
> Uninstall Docker Desktop from the command line
>
>To uninstall Docker Desktop from a terminal, run: `<DockerforMacPath>
>--uninstall`. If your instance is installed in the default location, this
>command provides a clean uninstall:
> To uninstall Docker Desktop from a terminal, run: `<DockerforMacPath>
> --uninstall`. If your instance is installed in the default location, this
> command provides a clean uninstall:
>
>```shell
>$ /Applications/Docker.app/Contents/MacOS/Docker --uninstall
>Docker is running, exiting...
>Docker uninstalled successfully. You can move the Docker application to the trash.
>```
>You might want to use the command-line uninstall if, for example, you find that
>the app is non-functional, and you cannot uninstall it from the menu.
> ```console
> $ /Applications/Docker.app/Contents/MacOS/Docker --uninstall
> Docker is running, exiting...
> Docker uninstalled successfully. You can move the Docker application to the trash.
> ```
>
> You might want to use the command-line uninstall if, for example, you find that
> the app is non-functional, and you cannot uninstall it from the menu.
## Diagnose and feedback
@ -61,7 +62,7 @@ documentation, on [Docker Desktop issues on
GitHub](https://github.com/docker/for-mac/issues), or the [Docker Desktop forum](https://forums.docker.com/c/docker-for-mac), we can help you troubleshoot
the log data. Before reporting an issue, we recommend that you read the information provided on this page to fix some common known issues.
>**Note**
> **Note**
>
> Docker Desktop offers support for users subscribed to a Pro or a Team plan. If you are experiencing any issues with Docker Desktop, follow the instructions in this section to send a support request to Docker Support.
@ -90,7 +91,7 @@ First, locate the `com.docker.diagnose` tool. If you have installed Docker Desk
To create *and upload* diagnostics, run:
```sh
```console
$ /Applications/Docker.app/Contents/MacOS/com.docker.diagnose gather -upload
```
@ -110,7 +111,7 @@ composed of your user ID (BE9AFAAF-F68B-41D0-9D12-84760E6B8740) and a timestamp
To view the contents of the diagnostic file, run:
```sh
```console
$ open /tmp/BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051.zip
```
@ -125,7 +126,7 @@ browse the logs yourself.
To watch the live flow of Docker Desktop logs in the command line, run the following script from your favorite shell.
```bash
```console
$ pred='process matches ".*(ocker|vpnkit).*"
|| (process in {"taskgated-helper", "launchservicesd", "kernel"} && eventMessage contains[c] "docker")'
$ /usr/bin/log stream --style syslog --level=debug --color=always --predicate "$pred"
@ -133,7 +134,7 @@ $ /usr/bin/log stream --style syslog --level=debug --color=always --predicate "$
Alternatively, to collect the last day of logs (`1d`) in a file, run:
```
```console
$ /usr/bin/log show --debug --info --style syslog --last 1d --predicate "$pred" >/tmp/logs.txt
```
@ -203,8 +204,8 @@ Tables (EPT) and Unrestricted Mode are supported.*
To check if your Mac supports the Hypervisor framework, run the following command in a terminal window.
```bash
sysctl kern.hv_support
```console
$ sysctl kern.hv_support
```
If your Mac supports the Hypervisor Framework, the command prints
@ -305,8 +306,8 @@ in the Apple documentation, and Docker Desktop [Mac system requirements](install
`DOCKER_CERT_PATH` environment variables, specify these to connect to Docker
instances through Unix sockets. For example:
```bash
export DOCKER_HOST=unix:///var/run/docker.sock
```console
$ export DOCKER_HOST=unix:///var/run/docker.sock
```
* There are a number of issues with the performance of directories bind-mounted

2
docker-for-windows/index.md
View File

@ -226,7 +226,7 @@ Run `docker version` to verify whether you have enabled experimental features. E
is listed under `Server` data. If `Experimental` is `true`, then Docker is
running in experimental mode, as shown here:
```shell
```console
> docker version
Client: Docker Engine - Community

6
docker-for-windows/networking.md
View File

@ -105,13 +105,13 @@ overlay network, not a bridge network, as these are not routed.
The command to run the `nginx` webserver shown in [Getting Started](index.md#explore-the-application)
is an example of this.
```bash
```console
$ docker run -d -p 80:80 --name webserver nginx
```
To clarify the syntax, the following two commands both publish container's port `80` to host's port `8000`:
```bash
```console
$ docker run --publish 8000:80 --name webserver nginx
$ docker run -p 8000:80 --name webserver nginx
@ -121,7 +121,7 @@ To publish all ports, use the `-P` flag. For example, the following command
starts a container (in detached mode) and the `-P` flag publishes all exposed ports of the
container to random ports on the host.
```bash
```console
$ docker run -d -P --name webserver nginx
```

11
docker-hub/index.md
View File

@ -136,12 +136,11 @@ Docker Hub.
1. Start by creating a [Dockerfile](../engine/reference/builder/) to specify your application as shown below:
```shell
cat > Dockerfile <<EOF
FROM busybox
CMD echo "Hello world! This is my first Docker image."
EOF
```
```dockerfile
# syntax=docker/dockerfile:1
FROM busybox
CMD echo "Hello world! This is my first Docker image."
```
2. Run `docker build -t <your_username>/my-private-repo .` to build your Docker
image.

8
docker-hub/vulnerability-scanning.md
View File

@ -42,14 +42,14 @@ To scan an image for vulnerabilities, push the image to Docker Hub:
2. Use the command line to log into your Docker account. See [docker login](../engine/reference/commandline/login.md) for more information.
3. Tag the image that you’d like to scan. For example, to tag a Redis image, run:
```shell
docker tag redis <your-Docker-ID>/<your-repo-name>:latest
```console
$ docker tag redis <your-Docker-ID>/<your-repo-name>:latest
```
4. Push the image to Docker Hub to trigger vulnerability scanning on the image:
```shell
docker push <your-Docker-ID>/<your-repo-name>:latest
```console
$ docker push <your-Docker-ID>/<your-repo-name>:latest
```
## View the vulnerability report

4
docsarchive.md
View File

@ -21,6 +21,6 @@ you can still access that documentation in the following ways:
- By running a container of the specific [tag for your documentation version](https://hub.docker.com/r/docs/docker.github.io)
in Docker Hub. For example, run the following to access `v1.9`:
```bash
docker run -it -p 4000:4000 docs/docker.github.io:v1.9
```console
$ docker run -it -p 4000:4000 docs/docker.github.io:v1.9
```

6
engine/api/index.md
View File

@ -70,7 +70,7 @@ unless you need to take advantage of new features.
To see the highest version of the API your Docker daemon and client support, use
`docker version`:
```bash
```console
$ docker version
Client: Docker Engine - Community
@ -107,8 +107,8 @@ You can specify the API version to use, in one of the following ways:
environment variable `DOCKER_API_VERSION` to the correct version. This works
on Linux, Windows, or macOS clients.
```bash
DOCKER_API_VERSION='1.41'
```console
$ DOCKER_API_VERSION='1.41'
```
While the environment variable is set, that version of the API is used, even

18
engine/api/sdk/examples.md
View File

@ -109,7 +109,7 @@ print(client.containers.run("alpine", ["echo", "hello", "world"]))
<div id="tab-run-curl" class="tab-pane fade" markdown="1">
```bash
```console
$ curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" \
-d '{"Image": "alpine", "Cmd": ["echo", "hello world"]}' \
-X POST http://localhost/v{{ site.latest_engine_api_version}}/containers/create
@ -214,7 +214,7 @@ print(container.id)
<div id="tab-rundetach-curl" class="tab-pane fade" markdown="1">
```bash
```console
$ curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" \
-d '{"Image": "bfirsh/reticulate-splines"}' \
-X POST http://localhost/v{{ site.latest_engine_api_version}}/containers/create
@ -285,7 +285,7 @@ for container in client.containers.list():
<div id="tab-listcontainers-curl" class="tab-pane fade" markdown="1">
```bash
```console
$ curl --unix-socket /var/run/docker.sock http://localhost/v{{ site.latest_engine_api_version}}/containers/json
[{
"Id":"ae63e8b89a26f01f6b4b2c9a7817c31a1b6196acf560f66586fbc8809ffcd772",
@ -365,7 +365,7 @@ for container in client.containers.list():
<div id="tab-stopcontainers-curl" class="tab-pane fade" markdown="1">
```bash
```console
$ curl --unix-socket /var/run/docker.sock http://localhost/v{{ site.latest_engine_api_version}}/containers/json
[{
"Id":"ae63e8b89a26f01f6b4b2c9a7817c31a1b6196acf560f66586fbc8809ffcd772",
@ -442,7 +442,7 @@ print(container.logs())
<div id="tab-containerlogs-curl" class="tab-pane fade" markdown="1">
```bash
```console
$ curl --unix-socket /var/run/docker.sock "http://localhost/v{{ site.latest_engine_api_version}}/containers/ca5f55cdb/logs?stdout=1"
Reticulating spline 1...
Reticulating spline 2...
@ -511,7 +511,7 @@ for image in client.images.list():
<div id="tab-listimages-curl" class="tab-pane fade" markdown="1">
```bash
```console
$ curl --unix-socket /var/run/docker.sock http://localhost/v{{ site.latest_engine_api_version}}/images/json
[{
"Id":"sha256:31d9a31e1dd803470c5a151b8919ef1988ac3efd44281ac59d43ad623f275dcd",
@ -581,7 +581,7 @@ print(image.id)
</div>
<div id="tab-pullimages-curl" class="tab-pane fade" markdown="1">
```bash
```console
$ curl --unix-socket /var/run/docker.sock \
-X POST "http://localhost/v{{ site.latest_engine_api_version}}/images/create?fromImage=alpine"
{"status":"Pulling from library/alpine","id":"3.1"}
@ -679,7 +679,7 @@ This example leaves the credentials in your shell's history, so consider
this a naive implementation. The credentials are passed as a Base-64-encoded
JSON structure.
```bash
```console
$ JSON=$(echo '{"username": "string", "password": "string", "serveraddress": "string"}' | base64)
$ curl --unix-socket /var/run/docker.sock \
@ -775,7 +775,7 @@ print(image.id)
</div>
<div id="tab-commit-curl" class="tab-pane fade" markdown="1">
```bash
```console
$ docker run -d alpine touch /helloworld
0888269a9d584f0fa8fc96b3c0d8d57969ceea3a64acf47cd34eebb4744dbc52
$ curl --unix-socket /var/run/docker.sock\

6
engine/api/sdk/index.md
View File

@ -22,8 +22,8 @@ installed and coexist together.
### Go SDK
```bash
go get github.com/docker/docker/client
```console
$ go get github.com/docker/docker/client
```
The client requires a recent version of Go. Run `go version` and ensure that you
@ -149,7 +149,7 @@ print client.containers.run("alpine", ["echo", "hello", "world"])
</div>
<div id="curl" class="tab-pane fade" markdown="1">
```bash
```console
$ curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" \
-d '{"Image": "alpine", "Cmd": ["echo", "hello world"]}' \
-X POST http://localhost/v{{ site.latest_engine_api_version}}/containers/create

2
engine/reference/commandline/app.md
View File

@ -383,7 +383,7 @@ pushing an official Docker image as part of your app, you may find your app
bundle becomes large with all image architectures embedded. To just push the
architecture required, you can add the `--platform` flag.
```bash
```console
$ docker login
$ docker app push my-app --platform="linux/amd64" --tag <hub-id>/<repo>:0.1.0

8
engine/release-notes/18.09.md
View File

@ -188,8 +188,8 @@ In Docker versions prior to 18.09, containerd was managed by the Docker engine d
Run the following command to get the current value of the `MountFlags` property for the `docker.service`:
```bash
sudo systemctl show --property=MountFlags docker.service
```console
$ sudo systemctl show --property=MountFlags docker.service
MountFlags=
```
Update your configuration if this command prints a non-empty value for `MountFlags`, and restart the docker service.
@ -244,8 +244,8 @@ configuration which changes mount settings (for example, `MountFlags=slave`) bre
Run the following command to get the current value of the `MountFlags` property for the `docker.service`:
```bash
sudo systemctl show --property=MountFlags docker.service
```console
$ sudo systemctl show --property=MountFlags docker.service
MountFlags=
```

34
engine/scan/index.md
View File

@ -21,20 +21,20 @@ This page contains information about the `docker scan` CLI command. For informat
The `docker scan` command allows you to scan existing Docker images using the image name or ID. For example, run the following command to scan the hello-world image:
```shell
$ docker scan hello-world
```console
$ docker scan hello-world
Testing hello-world...
Testing hello-world...
Organization: docker-desktop-test
Package manager: linux
Project name: docker-image|hello-world
Docker image: hello-world
Licenses: enabled
Organization: docker-desktop-test
Package manager: linux
Project name: docker-image|hello-world
Docker image: hello-world
Licenses: enabled
✓ Tested 0 dependencies for known issues, no vulnerable paths found.
✓ Tested 0 dependencies for known issues, no vulnerable paths found.
Note that we do not currently have vulnerability data for your image.
Note that we do not currently have vulnerability data for your image.
```
### Get a detailed scan report
@ -43,7 +43,7 @@ You can get a detailed scan report about a Docker image by providing the Dockerf
For example, if you apply the option to the `docker-scan` test image, it displays the following result:
```shell
```console
$ docker scan --file Dockerfile docker-scan:e2e
Testing docker-scan:e2e
...
@ -74,7 +74,7 @@ According to our scan, you are currently using the most secure version of the se
When using docker scan with the `--file` flag, you can also add the `--exclude-base` tag. This excludes the base image (specified in the Dockerfile using the `FROM` directive) vulnerabilities from your report. For example:
```shell
```console
$ docker scan --file Dockerfile --exclude-base docker-scan:e2e
Testing docker-scan:e2e
...
@ -105,7 +105,7 @@ Tested 200 dependencies for known issues, found 16 issues.
You can also display the scan result as a JSON output by adding the `--json` flag to the command. For example:
```shell
```console
$ docker scan --json hello-world
{
"vulnerabilities": [],
@ -158,7 +158,7 @@ $ docker scan --json hello-world
In addition to the `--json` flag, you can also use the `--group-issues` flag to display a vulnerability only once in the scan report:
```shell
```console
$ docker scan --json --group-issues docker-scan:e2e
{
{
@ -211,7 +211,7 @@ You can find all the sources of the vulnerability in the `from` section.
To view the dependency tree of your image, use the --dependency-tree flag. This displays all the dependencies before the scan result. For example:
```shell
```console
$ docker scan --dependency-tree debian:buster
$ docker-image|99138c65ebc7 @ latest
@ -322,7 +322,7 @@ Tested 200 dependencies for known issues, found 37 issues.
If you have an existing Snyk account, you can directly use your Snyk [API token](https://app.snyk.io/account){: target="_blank" rel="noopener" class="_"}:
```shell
```console
$ docker scan --login --token SNYK_AUTH_TOKEN
Your account has been authenticated. Snyk is now ready to be used.
@ -347,7 +347,7 @@ To run vulnerability scanning on your Docker images, you must meet the following
Check your installation by running `docker scan --version`, it should print the current version of docker scan and the Snyk engine version. For example:
```shell
```console
$ docker scan --version
Version: v0.5.0
Git commit: 5a09266

18
engine/security/apparmor.md
View File

@ -32,7 +32,7 @@ When you run a container, it uses the `docker-default` policy unless you
override it with the `security-opt` option. For example, the following
explicitly specifies the default policy:
```bash
```console
$ docker run --rm -it --security-opt apparmor=docker-default hello-world
```
@ -40,19 +40,19 @@ $ docker run --rm -it --security-opt apparmor=docker-default hello-world
To load a new profile into AppArmor for use with containers:
```bash
```console
$ apparmor_parser -r -W /path/to/your_profile
```
Then, run the custom profile with `--security-opt` like so:
```bash
```console
$ docker run --rm -it --security-opt apparmor=your_profile hello-world
```
To unload a profile from AppArmor:
```bash
```console
# unload the profile
$ apparmor_parser -R /path/to/profile
```
@ -154,7 +154,7 @@ profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
2. Load the profile.
```bash
```console
$ sudo apparmor_parser -r -W /etc/apparmor.d/containers/docker-nginx
```
@ -162,20 +162,20 @@ profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
To run nginx in detached mode:
```bash
```console
$ docker run --security-opt "apparmor=docker-nginx" \
-p 80:80 -d --name apparmor-nginx nginx
```
4. Exec into the running container.
```bash
```console
$ docker container exec -it apparmor-nginx bash
```
5. Try some operations to test the profile.
```bash
```console
root@6da5a2a930b9:~# ping 8.8.8.8
ping: Lacking privilege for raw socket.
@ -233,7 +233,7 @@ default unless in `privileged` mode. This line shows that apparmor has denied
If you need to check which profiles are loaded, you can use `aa-status`. The
output looks like:
```bash
```console
$ sudo aa-status
apparmor module is loaded.
14 profiles are loaded.

4
engine/security/seccomp.md
View File

@ -13,7 +13,7 @@ This feature is available only if Docker has been built with `seccomp` and the
kernel is configured with `CONFIG_SECCOMP` enabled. To check if your kernel
supports `seccomp`:
```bash
```console
$ grep CONFIG_SECCOMP= /boot/config-$(uname -r)
CONFIG_SECCOMP=y
```
@ -47,7 +47,7 @@ When you run a container, it uses the default profile unless you override it
with the `--security-opt` option. For example, the following explicitly
specifies a policy:
```bash
```console
$ docker run --rm \
-it \
--security-opt seccomp=/path/to/seccomp/profile.json \

4
engine/security/trust/trust_automation.md
View File

@ -84,7 +84,7 @@ The `FROM` tag is pulling a signed image. You cannot build an image that has a
`FROM` that is not either present locally or signed. Given that content trust
data exists for the tag `latest`, the following build should succeed:
```bash
```console
$ docker build -t docker/trusttest:testing .
Using default tag: latest
latest: Pulling from docker/trusttest
@ -97,7 +97,7 @@ Digest: sha256:d149ab53f871
If content trust is enabled, building from a Dockerfile that relies on tag
without trust data, causes the build command to fail:
```bash
```console
$ docker build -t docker/trusttest:testing .
unable to process Dockerfile: No trust data for notrust
```

46
engine/security/trust/trust_delegation.md
View File

@ -65,7 +65,7 @@ Successfully added signer: jeff to registry.example.com/user/repo
If you do not log in, you will see:
```bash
```console
$ docker trust signer add --key cert.pem jeff registry.example.com/user/repo
Adding signer "jeff" to registry.example.com/user/repo...
Initializing signed repository for registry.example.com/user/repo...
@ -111,7 +111,7 @@ Docker trust has a built-in generator for a delegation key pair,
`$ docker trust generate <name>`. Running this command will automatically load
the delegation private key in to the local Docker trust store.
```bash
```console
$ docker trust key generate jeff
Generating key for jeff...
@ -129,7 +129,7 @@ cfssl along with a local or company-wide Certificate Authority.
Here is an example of how to generate a 2048-bit RSA portion key (all RSA keys
must be at least 2048 bits):
```bash
```console
$ openssl genrsa -out delegation.key 2048
Generating RSA private key, 2048 bit long modulus
@ -144,7 +144,7 @@ Then they need to generate an x509 certificate containing the public key, which
what you need from them. Here is the command to generate a CSR (certificate
signing request):
```bash
```console
$ openssl req -new -sha256 -key delegation.key -out delegation.csr
```
@ -152,7 +152,7 @@ Then they can send it to whichever CA you trust to sign certificates, or they
can self-sign the certificate (in this example, creating a certificate that is
valid for 1 year):
```bash
```console
$ openssl x509 -req -sha256 -days 365 -in delegation.csr -signkey delegation.key -out delegation.crt
```
@ -161,7 +161,7 @@ by a CA.
Finally you will need to add the private key into your local Docker trust store.
```bash
```console
$ docker trust key load delegation.key --name jeff
Loading key from "delegation.key"...
@ -175,7 +175,7 @@ Successfully imported key from delegation.key
To list the keys that have been imported in to the local Docker trust store we
can use the Notary CLI.
```bash
```console
$ notary key list
ROLE GUN KEY ID LOCATION
@ -209,7 +209,7 @@ For DCT the name of the second delegation, in the below example
`jeff`, is there to help you keep track of the owner of the keys. In more
advanced use cases of Notary additional delegations are used for hierarchy.
```bash
```console
$ docker trust signer add --key cert.pem jeff registry.example.com/admin/demo
Adding signer "jeff" to registry.example.com/admin/demo...
@ -224,7 +224,7 @@ Successfully added signer: jeff to registry.example.com/admin/demo
You can see which keys have been pushed to the Notary server for each repository
with the `$ docker trust inspect` command.
```bash
```console
$ docker trust inspect --pretty registry.example.com/admin/demo
No signatures for registry.example.com/admin/demo
@ -244,7 +244,7 @@ Administrative keys for registry.example.com/admin/demo
You could also use the Notary CLI to list delegations and keys. Here you can
clearly see the keys were attached to `targets/releases` and `targets/jeff`.
```bash
```console
$ notary delegation list registry.example.com/admin/demo
ROLE PATHS KEY IDS THRESHOLD
@ -264,7 +264,7 @@ the `targets/release` role.
> Note you will need the passphrase for the repository key; this would have been
> configured when you first initiated the repository.
```bash
```console
$ docker trust signer add --key ben.pub ben registry.example.com/admin/demo
Adding signer "ben" to registry.example.com/admin/demo...
@ -274,7 +274,7 @@ Successfully added signer: ben to registry.example.com/admin/demo
Check to prove that there are now 2 delegations (Signer).
```bash
```console
$ docker trust inspect --pretty registry.example.com/admin/demo
No signatures for registry.example.com/admin/demo
@ -301,7 +301,7 @@ will automatically handle adding this new key to `targets/releases`.
> Note you will need the passphrase for the repository key; this would have been
> configured when you first initiated the repository.
```bash
```console
$ docker trust signer add --key cert2.pem jeff registry.example.com/admin/demo
Adding signer "jeff" to registry.example.com/admin/demo...
@ -311,7 +311,7 @@ Successfully added signer: jeff to registry.example.com/admin/demo
Check to prove that the delegation (Signer) now contains multiple Key IDs.
```bash
```console
$ docker trust inspect --pretty registry.example.com/admin/demo
No signatures for registry.example.com/admin/demo
@ -337,7 +337,7 @@ attached to the `targets/releases` role, you can use the
> Note tags that were signed by the removed delegation will need to be resigned
> by an active delegation
```bash
```console
$ docker trust signer remove registry.example.com/admin/demo
Removing signer "ben" from registry.example.com/admin/demo...
Enter passphrase for repository key with ID b0014f8:
@ -364,7 +364,7 @@ WARN[0000] Error getting targets/releases: valid signatures did not meet thresho
Resigning the delegation file is done with the `$ notary witness` command
```bash
```console
$ notary witness registry.example.com/admin/demo targets/releases --publish
```
@ -381,7 +381,7 @@ and the role specific to that signer `targets/<name>`.
1) We will need to grab the Key ID from the Notary Server
```bash
```console
$ notary delegation list registry.example.com/admin/demo
ROLE PATHS KEY IDS THRESHOLD
@ -394,7 +394,7 @@ targets/releases "" <all paths> 8fb597cbaf196f0781628b2f52bff6b3912e4e8075
2) Remove from the `targets/releases` delegation
```bash
```console
$ notary delegation remove registry.example.com/admin/demo targets/releases 1091060d7bfd938dfa5be703fa057974f9322a4faef6f580334f3d6df44c02d1 --publish
Auto-publishing changes to registry.example.com/admin/demo
@ -406,7 +406,7 @@ Successfully published changes for repository registry.example.com/admin/demo
3) Remove from the `targets/<name>` delegation
```bash
```console
$ notary delegation remove registry.example.com/admin/demo targets/jeff 1091060d7bfd938dfa5be703fa057974f9322a4faef6f580334f3d6df44c02d1 --publish
Removal of delegation role targets/jeff with keys [5570b88df0736c468493247a07e235e35cf3641270c944d0e9e8899922fc6f99], to repository "registry.example.com/admin/demo" staged for next publish.
@ -420,7 +420,7 @@ Successfully published changes for repository registry.example.com/admin/demo
4) Check the remaining delegation list
```bash
```console
$ notary delegation list registry.example.com/admin/demo
ROLE PATHS KEY IDS THRESHOLD
@ -437,7 +437,7 @@ the `$ notary key remove` command.
1) We will need to get the Key ID from the local Docker Trust store
```bash
```console
$ notary key list
ROLE GUN KEY ID LOCATION
@ -450,7 +450,7 @@ targets ...example.com/admin/demo c819f2eda8fba2810ec6a7f95f051c90276c87fd
2) Remove the key from the local Docker Trust store
```bash
```console
$ notary key remove 1091060d7bfd938dfa5be703fa057974f9322a4faef6f580334f3d6df44c02d1
Are you sure you want to remove 1091060d7bfd938dfa5be703fa057974f9322a4faef6f580334f3d6df44c02d1 (role jeff) from /home/ubuntu/.docker/trust/private? (yes/no) y
@ -466,7 +466,7 @@ snapshot and all delegations keys using the Notary CLI.
This is often required by a container registry before a particular repository
can be deleted.
```bash
```console
$ notary delete registry.example.com/admin/demo --remote
Deleting trust data for repository registry.example.com/admin/demo

2
engine/security/trust/trust_key_mng.md
View File

@ -53,7 +53,7 @@ of the repository key is recoverable; loss of the root key is not.
The Docker client stores the keys in the `~/.docker/trust/private` directory.
Before backing them up, you should `tar` them into an archive:
```bash
```console
$ umask 077; tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private; umask 022
```

2
engine/security/trust/trust_sandbox.md
View File

@ -222,7 +222,7 @@ data. Then, you try and pull it.
3. List the layers for the `test/trusttest` image you pushed:
```bash
```console
root@65084fc6f047:/# ls -l /var/lib/registry/docker/registry/v2/repositories/test/trusttest/_layers/sha256
total 12
drwxr-xr-x 2 root root 4096 Jun 10 17:26 a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4

12
engine/security/userns-remap.md
View File

@ -76,7 +76,7 @@ avoid these situations.
To verify this, use the `id` command:
```bash
```console
$ id testuser
uid=1001(testuser) gid=1001(testuser) groups=1001(testuser)
@ -135,7 +135,7 @@ procedure to configure the daemon using the `daemon.json` configuration file.
The `daemon.json` method is recommended. If you use the flag, use the following
command as a model:
```bash
```console
$ dockerd --userns-remap="testuser:testuser"
```
@ -168,7 +168,7 @@ $ dockerd --userns-remap="testuser:testuser"
2. If you are using the `dockremap` user, verify that Docker created it using
the `id` command.
```bash
```console
$ id dockremap
uid=112(dockremap) gid=116(dockremap) groups=116(dockremap)
@ -176,7 +176,7 @@ $ dockerd --userns-remap="testuser:testuser"
Verify that the entry has been added to `/etc/subuid` and `/etc/subgid`:
```bash
```console
$ grep dockremap /etc/subuid
dockremap:231072:65536
@ -196,7 +196,7 @@ $ dockerd --userns-remap="testuser:testuser"
4. Start a container from the `hello-world` image.
```bash
```console
$ docker run hello-world
```
@ -205,7 +205,7 @@ $ dockerd --userns-remap="testuser:testuser"
and not group-or-world-readable. Some of the subdirectories are still
owned by `root` and have different permissions.
```bash
```console
$ sudo ls -ld /var/lib/docker/231072.231072/
drwx------ 11 231072 231072 11 Jun 21 21:19 /var/lib/docker/231072.231072/

26
engine/swarm/admin_guide.md
View File

@ -133,8 +133,8 @@ operations like swarm heartbeat or leader elections.
To avoid interference with manager node operation, you can drain manager nodes
to make them unavailable as worker nodes:
```bash
docker node update --availability drain <NODE>
```console
$ docker node update --availability drain <NODE>
```
When you drain a node, the scheduler reassigns any tasks running on the node to
@ -161,8 +161,8 @@ From the command line, run `docker node inspect <id-node>` to query the nodes.
For instance, to query the reachability of the node as a manager:
{% raw %}
```bash
docker node inspect manager1 --format "{{ .ManagerStatus.Reachability }}"
```console
$ docker node inspect manager1 --format "{{ .ManagerStatus.Reachability }}"
reachable
```
{% endraw %}
@ -170,8 +170,8 @@ reachable
To query the status of the node as a worker that accept tasks:
{% raw %}
```bash
docker node inspect manager1 --format "{{ .Status.State }}"
```console
$ docker node inspect manager1 --format "{{ .Status.State }}"
ready
```
{% endraw %}
@ -190,9 +190,8 @@ manager:
Alternatively you can also get an overview of the swarm health from a manager
node with `docker node ls`:
```bash
docker node ls
```console
$ docker node ls
ID HOSTNAME MEMBERSHIP STATUS AVAILABILITY MANAGER STATUS
1mhtdwhvsgr3c26xxbnzdc3yp node05 Accepted Ready Active
516pacagkqp2xc3fk9t1dhjor node02 Accepted Ready Active Reachable
@ -301,7 +300,7 @@ restore the data to a new swarm.
to connect to nodes that were part of the old swarm, and presumably no
longer exist.
```bash
```console
$ docker swarm init --force-new-cluster
```
@ -350,9 +349,10 @@ except the manager the command was run from. The quorum is achieved because
there is now only one manager. Promote nodes to be managers until you have the
desired number of managers.
```bash
# From the node to recover
docker swarm init --force-new-cluster --advertise-addr node01:2377
From the node to recover, run:
```console
$ docker swarm init --force-new-cluster --advertise-addr node01:2377
```
When you run the `docker swarm init` command with the `--force-new-cluster`

54
engine/swarm/configs.md
View File

@ -141,7 +141,7 @@ real-world example, continue to
input because the last argument, which represents the file to read the
config from, is set to `-`.
```bash
```console
$ echo "This is a config" | docker config create my-config -
```
@ -149,14 +149,14 @@ real-world example, continue to
the container can access the config at `/my-config`, but
you can customize the file name on the container using the `target` option.
```bash
```console
$ docker service create --name redis --config my-config redis:alpine
```
3. Verify that the task is running without issues using `docker service ps`. If
everything is working, the output looks similar to this:
```bash
```console
$ docker service ps redis
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
@ -170,7 +170,7 @@ real-world example, continue to
how to find the container ID, and the second and third commands use shell
completion to do this automatically.
```bash
```console
$ docker ps --filter name=redis -q
5cb1c2348a59
@ -187,7 +187,7 @@ real-world example, continue to
5. Try removing the config. The removal fails because the `redis` service is
running and has access to the config.
```bash
```console
$ docker config ls
@ -204,7 +204,7 @@ real-world example, continue to
6. Remove access to the config from the running `redis` service by updating the
service.
```bash
```console
$ docker service update --config-rm my-config redis
```
@ -220,7 +220,7 @@ real-world example, continue to
8. Stop and remove the service, and remove the config from Docker.
```bash
```console
$ docker service rm redis
$ docker config rm my-config
@ -297,14 +297,14 @@ name as its argument. The template will be rendered when container is created.
2. Save the `index.html.tmpl` file as a swarm config named `homepage`. Provide
parameter `--template-driver` and specify `golang` as template engine.
```bash
```console
$ docker config create --template-driver golang homepage index.html.tmpl
```
3. Create a service that runs Nginx and has access to the environment variable
HELLO and to the config.
```bash
```console
$ docker service create \
--name hello-template \
--env HELLO="Docker" \
@ -316,7 +316,7 @@ name as its argument. The template will be rendered when container is created.
4. Verify that the service is operational: you can reach the Nginx server, and
that the correct output is being served.
```bash
```console
$ curl http://0.0.0.0:3000
<html lang="en">
@ -351,13 +351,13 @@ generate the site key and certificate, name the files `site.key` and
1. Generate a root key.
```bash
```console
$ openssl genrsa -out "root-ca.key" 4096
```
2. Generate a CSR using the root key.
```bash
```console
$ openssl req \
-new -key "root-ca.key" \
-out "root-ca.csr" -sha256 \
@ -377,7 +377,7 @@ generate the site key and certificate, name the files `site.key` and
4. Sign the certificate.
```bash
```console
$ openssl x509 -req -days 3650 -in "root-ca.csr" \
-signkey "root-ca.key" -sha256 -out "root-ca.crt" \
-extfile "root-ca.cnf" -extensions \
@ -386,13 +386,13 @@ generate the site key and certificate, name the files `site.key` and
5. Generate the site key.
```bash
```console
$ openssl genrsa -out "site.key" 4096
```
6. Generate the site certificate and sign it with the site key.
```bash
```console
$ openssl req -new -key "site.key" -out "site.csr" -sha256 \
-subj '/C=US/ST=CA/L=San Francisco/O=Docker/CN=localhost'
```
@ -414,7 +414,7 @@ generate the site key and certificate, name the files `site.key` and
8. Sign the site certificate.
```bash
```console
$ openssl x509 -req -days 750 -in "site.csr" -sha256 \
-CA "root-ca.crt" -CAkey "root-ca.key" -CAcreateserial \
-out "site.crt" -extfile "site.cnf" -extensions server
@ -452,7 +452,7 @@ generate the site key and certificate, name the files `site.key` and
to decouple the key and certificate from the services that use them.
In these examples, the secret name and the file name are the same.
```bash
```console
$ docker secret create site.key site.key
$ docker secret create site.crt site.crt
@ -461,13 +461,13 @@ generate the site key and certificate, name the files `site.key` and
3. Save the `site.conf` file in a Docker config. The first parameter is the
name of the config, and the second parameter is the file to read it from.
```bash
```console
$ docker config create site.conf site.conf
```
List the configs:
```bash
```console
$ docker config ls
ID NAME CREATED UPDATED
@ -479,7 +479,7 @@ generate the site key and certificate, name the files `site.key` and
config. Set the mode to `0440` so that the file is only readable by its
owner and that owner's group, not the world.
```bash
```console
$ docker service create \
--name nginx \
--secret site.key \
@ -498,7 +498,7 @@ generate the site key and certificate, name the files `site.key` and
5. Verify that the Nginx service is running.
```bash
```console
$ docker service ls
ID NAME MODE REPLICAS IMAGE
@ -513,7 +513,7 @@ generate the site key and certificate, name the files `site.key` and
6. Verify that the service is operational: you can reach the Nginx
server, and that the correct TLS certificate is being used.
```bash
```console
$ curl --cacert root-ca.crt https://0.0.0.0:3000
<!DOCTYPE html>
@ -543,7 +543,7 @@ generate the site key and certificate, name the files `site.key` and
</html>
```
```bash
```console
$ openssl s_client -connect 0.0.0.0:3000 -CAfile root-ca.crt
CONNECTED(00000003)
@ -588,7 +588,7 @@ generate the site key and certificate, name the files `site.key` and
this example by removing the `nginx` service and the stored secrets and
config.
```bash
```console
$ docker service rm nginx
$ docker secret rm site.crt site.key
@ -633,7 +633,7 @@ configuration file.
3. Update the `nginx` service to use the new config instead of the old one.
```bash
```console
$ docker service update \
--config-rm site.conf \
--config-add source=site-v2.conf,target=/etc/nginx/conf.d/site.conf,mode=0440 \
@ -644,14 +644,14 @@ configuration file.
`docker service ps nginx`. When it is, you can remove the old `site.conf`
config.
```bash
```console
$ docker config rm site.conf
```
5. To clean up, you can remove the `nginx` service, as well as the secrets and
configs.
```bash
```console
$ docker service rm nginx
$ docker secret rm site.crt site.key

2
engine/swarm/how-swarm-mode-works/swarm-task-states.md
View File

@ -48,7 +48,7 @@ Run `docker service ps <service-name>` to get the state of a task. The
`CURRENT STATE` field shows the task's state and how long it's been
there.
```bash
```console
$ docker service ps webserver
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
owsz0yp6z375 webserver.1 nginx UbuntuVM Running Running 44 seconds ago

22
engine/swarm/ingress.md
View File

@ -31,7 +31,7 @@ specify the port to bind on the routing mesh. If you leave off the `published`
port, a random high-numbered port is bound for each service task. You
need to inspect the task to determine the port.
```bash
```console
$ docker service create \
--name <SERVICE-NAME> \
--publish published=<PUBLISHED-PORT>,target=<CONTAINER-PORT> \
@ -51,7 +51,7 @@ is required.
For example, the following command publishes port 80 in the nginx container to
port 8080 for any node in the swarm:
```bash
```console
$ docker service create \
--name my-web \
--publish published=8080,target=80 \
@ -73,7 +73,7 @@ within the host.
You can publish a port for an existing service using the following command:
```bash
```console
$ docker service update \
--publish-add published=<PUBLISHED-PORT>,target=<CONTAINER-PORT> \
<SERVICE>
@ -83,7 +83,7 @@ You can use `docker service inspect` to view the service's published port. For
instance:
{% raw %}
```bash
```console
$ docker service inspect --format="{{json .Endpoint.Spec.Ports}}" my-web
[{"Protocol":"tcp","TargetPort":80,"PublishedPort":8080}]
@ -105,7 +105,7 @@ set the `protocol` key to either `tcp` or `udp`.
**Long syntax:**
```bash
```console
$ docker service create --name dns-cache \
--publish published=53,target=53 \
dns-cache
@ -113,7 +113,7 @@ $ docker service create --name dns-cache \
**Short syntax:**
```bash
```console
$ docker service create --name dns-cache \
-p 53:53 \
dns-cache
@ -123,7 +123,7 @@ $ docker service create --name dns-cache \
**Long syntax:**
```bash
```console
$ docker service create --name dns-cache \
--publish published=53,target=53 \
--publish published=53,target=53,protocol=udp \
@ -132,7 +132,7 @@ $ docker service create --name dns-cache \
**Short syntax:**
```bash
```console
$ docker service create --name dns-cache \
-p 53:53 \
-p 53:53/udp \
@ -143,7 +143,7 @@ $ docker service create --name dns-cache \
**Long syntax:**
```bash
```console
$ docker service create --name dns-cache \
--publish published=53,target=53,protocol=udp \
dns-cache
@ -151,7 +151,7 @@ $ docker service create --name dns-cache \
**Short syntax:**
```bash
```console
$ docker service create --name dns-cache \
-p 53:53/udp \
dns-cache
@ -180,7 +180,7 @@ set `mode` to `host`. If you omit the `mode` key or set it to `ingress`, the
routing mesh is used. The following command creates a global service using
`host` mode and bypassing the routing mesh.
```bash
```console
$ docker service create --name dns-cache \
--publish published=53,target=53,protocol=udp,mode=host \
--mode global \

8
engine/swarm/join-nodes.md
View File

@ -28,7 +28,7 @@ to [Run Docker Engine in swarm mode](swarm-mode.md#view-the-join-command-or-upda
To retrieve the join command including the join token for worker nodes, run the
following command on a manager node:
```bash
```console
$ docker swarm join-token worker
To add a worker to this swarm, run the following command:
@ -40,7 +40,7 @@ To add a worker to this swarm, run the following command:
Run the command from the output on the worker to join the swarm:
```bash
```console
$ docker swarm join \
--token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \
192.168.99.100:2377
@ -76,7 +76,7 @@ For more detail about swarm managers and administering a swarm, see
To retrieve the join command including the join token for manager nodes, run the
following command on a manager node:
```bash
```console
$ docker swarm join-token manager
To add a manager to this swarm, run the following command:
@ -88,7 +88,7 @@ To add a manager to this swarm, run the following command:
Run the command from the output on the new manager node to join it to the swarm:
```bash
```console
$ docker swarm join \
--token SWMTKN-1-61ztec5kyafptydic6jfc1i33t37flcl4nuipzcusor96k7kby-5vy9t8u35tuqm7vh67lrz9xp6 \
192.168.99.100:2377

16
engine/swarm/manage-nodes.md
View File

@ -15,7 +15,7 @@ As part of the swarm management lifecycle, you may need to view or update a node
To view a list of nodes in the swarm run `docker node ls` from a manager node:
```bash
```console
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
@ -58,7 +58,7 @@ You can run `docker node inspect <NODE-ID>` on a manager node to view the
details for an individual node. The output defaults to JSON format, but you can
pass the `--pretty` flag to print the results in human-readable format. For example:
```bash
```console
$ docker node inspect self --pretty
ID: ehkv3bcimagdese79dn78otj5
@ -103,7 +103,7 @@ Changing node availability lets you:
For example, to change a manager node to `Drain` availability:
```bash
```console
$ docker node update --availability drain node-1
node-1
@ -124,7 +124,7 @@ pair.
Pass the `--label-add` flag once for each node label you want to add:
```bash
```console
$ docker node update --label-add foo --label-add bar=baz node-1
node-1
@ -164,7 +164,7 @@ maintenance. Similarly, you can demote a manager node to the worker role.
To promote a node or set of nodes, run `docker node promote` from a manager
node:
```bash
```console
$ docker node promote node-3 node-2
Node node-3 promoted to a manager in the swarm.
@ -173,7 +173,7 @@ Node node-2 promoted to a manager in the swarm.
To demote a node or set of nodes, run `docker node demote` from a manager node:
```bash
```console
$ docker node demote node-3 node-2
Manager node-3 demoted in the swarm.
@ -210,7 +210,7 @@ Run the `docker swarm leave` command on a node to remove it from the swarm.
For example to leave the swarm on a worker node:
```bash
```console
$ docker swarm leave
Node left the swarm.
@ -232,7 +232,7 @@ manager node to remove the node from the node list.
For instance:
```bash
```console
$ docker node rm node-2
```

22
engine/swarm/networking.md
View File

@ -60,7 +60,7 @@ each other over the following ports:
To create an overlay network, specify the `overlay` driver when using the
`docker network create` command:
```bash
```console
$ docker network create \
--driver overlay \
my-network
@ -73,7 +73,7 @@ subnet and uses default options. You can see information about the network using
When no containers are connected to the overlay network, its configuration is
not very exciting:
```bash
```console
$ docker network inspect my-network
[
{
@ -110,7 +110,7 @@ connects to the network for the first time. The following example shows
the same network as above, but with three containers of a `redis` service
connected to it.
```bash
```console
$ docker network inspect my-network
[
{
@ -184,7 +184,7 @@ the first service is connected to the network. You can configure these when
creating a network using the `--subnet` and `--gateway` flags. The following
example extends the previous one by configuring the subnet and gateway.
```bash
```console
$ docker network create \
--driver overlay \
--subnet 10.0.9.0/24 \
@ -198,7 +198,7 @@ To customize subnet allocation for your Swarm networks, you can [optionally conf
For example, the following command is used when initializing Swarm:
```bash
```console
$ docker swarm init --default-addr-pool 10.20.0.0/16 --default-addr-pool-mask-length 26`
```
@ -237,7 +237,7 @@ option before using it in production.
To attach a service to an existing overlay network, pass the `--network` flag to
`docker service create`, or the `--network-add` flag to `docker service update`.
```bash
```console
$ docker service create \
--replicas 3 \
--name my-web \
@ -310,7 +310,7 @@ services which publish ports, such as a WordPress service which publishes port
2. Remove the existing `ingress` network:
```bash
```console
$ docker network rm ingress
WARNING! Before removing the routing-mesh network, make sure all the nodes
@ -324,7 +324,7 @@ services which publish ports, such as a WordPress service which publishes port
custom options you want to set. This example sets the MTU to 1200, sets
the subnet to `10.11.0.0/16`, and sets the gateway to `10.11.0.2`.
```bash
```console
$ docker network create \
--driver overlay \
--ingress \
@ -365,7 +365,7 @@ order to delete an existing bridge. The package name is `bridge-utils`.
This example uses the subnet `10.11.0.0/16`. For a full list of customizable
options, see [Bridge driver options](../reference/commandline/network_create.md#bridge-driver-options).
```bash
```console
$ docker network create \
--subnet 10.11.0.0/16 \
--opt com.docker.network.bridge.name=docker_gwbridge \
@ -396,14 +396,14 @@ that your Docker host has two different network interfaces: 10.0.0.1 should be
used for control and management traffic and 192.168.0.1 should be used for
traffic relating to services.
```bash
```console
$ docker swarm init --advertise-addr 10.0.0.1 --data-path-addr 192.168.0.1
```
This example joins the swarm managed by host `192.168.99.100:2377` and sets the
`--advertise-addr` flag to `eth0` and the `--data-path-addr` flag to `eth1`.
```bash
```console
$ docker swarm join \
--token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2d7c \
--advertise-addr eth0 \

80
engine/swarm/secrets.md
View File

@ -149,7 +149,7 @@ real-world example, continue to
input because the last argument, which represents the file to read the
secret from, is set to `-`.
```bash
```console
$ printf "This is a secret" | docker secret create my_secret_data -
```
@ -157,14 +157,14 @@ real-world example, continue to
the container can access the secret at `/run/secrets/<secret_name>`, but
you can customize the file name on the container using the `target` option.
```bash
```console
$ docker service create --name redis --secret my_secret_data redis:alpine
```
3. Verify that the task is running without issues using `docker service ps`. If
everything is working, the output looks similar to this:
```bash
```console
$ docker service ps redis
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
@ -174,7 +174,7 @@ real-world example, continue to
If there were an error, and the task were failing and repeatedly restarting,
you would see something like this:
```bash
```console
$ docker service ps redis
NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
@ -192,7 +192,7 @@ real-world example, continue to
how to find the container ID, and the second and third commands use shell
completion to do this automatically.
```bash
```console
$ docker ps --filter name=redis -q
5cb1c2348a59
@ -220,8 +220,7 @@ real-world example, continue to
6. Try removing the secret. The removal fails because the `redis` service is
running and has access to the secret.
```bash
```console
$ docker secret ls
ID NAME CREATED UPDATED
@ -237,7 +236,7 @@ real-world example, continue to
7. Remove access to the secret from the running `redis` service by updating the
service.
```bash
```console
$ docker service update --secret-rm my_secret_data redis
```
@ -253,7 +252,7 @@ real-world example, continue to
7. Stop and remove the service, and remove the secret from Docker.
```bash
```console
$ docker service rm redis
$ docker secret rm my_secret_data
@ -336,13 +335,13 @@ generate the site key and certificate, name the files `site.key` and
1. Generate a root key.
```bash
```console
$ openssl genrsa -out "root-ca.key" 4096
```
2. Generate a CSR using the root key.
```bash
```console
$ openssl req \
-new -key "root-ca.key" \
-out "root-ca.csr" -sha256 \
@ -362,7 +361,7 @@ generate the site key and certificate, name the files `site.key` and
4. Sign the certificate.
```bash
```console
$ openssl x509 -req -days 3650 -in "root-ca.csr" \
-signkey "root-ca.key" -sha256 -out "root-ca.crt" \
-extfile "root-ca.cnf" -extensions \
@ -371,13 +370,13 @@ generate the site key and certificate, name the files `site.key` and
5. Generate the site key.
```bash
```console
$ openssl genrsa -out "site.key" 4096
```
6. Generate the site certificate and sign it with the site key.
```bash
```console
$ openssl req -new -key "site.key" -out "site.csr" -sha256 \
-subj '/C=US/ST=CA/L=San Francisco/O=Docker/CN=localhost'
```
@ -399,7 +398,7 @@ generate the site key and certificate, name the files `site.key` and
8. Sign the site certificate.
```bash
```console
$ openssl x509 -req -days 750 -in "site.csr" -sha256 \
-CA "root-ca.crt" -CAkey "root-ca.key" -CAcreateserial \
-out "site.crt" -extfile "site.cnf" -extensions server
@ -440,7 +439,7 @@ generate the site key and certificate, name the files `site.key` and
secret from on the host machine's filesystem. In these examples, the secret
name and the file name are the same.
```bash
```console
$ docker secret create site.key site.key
$ docker secret create site.crt site.crt
@ -448,7 +447,7 @@ generate the site key and certificate, name the files `site.key` and
$ docker secret create site.conf site.conf
```
```bash
```console
$ docker secret ls
ID NAME CREATED UPDATED
@ -474,7 +473,7 @@ generate the site key and certificate, name the files `site.key` and
secret available in a different path. The example below creates a symbolic
link to the true location of the `site.conf` file so that Nginx can read it:
```bash
```console
$ docker service create \
--name nginx \
--secret site.key \
@ -490,7 +489,7 @@ generate the site key and certificate, name the files `site.key` and
secret is made available at `/etc/nginx/conf.d/site.conf` inside the container
without the use of symbolic links:
```bash
```console
$ docker service create \
--name nginx \
--secret site.key \
@ -512,7 +511,7 @@ generate the site key and certificate, name the files `site.key` and
5. Verify that the Nginx service is running.
```bash
```console
$ docker service ls
ID NAME MODE REPLICAS IMAGE
@ -527,7 +526,7 @@ generate the site key and certificate, name the files `site.key` and
6. Verify that the service is operational: you can reach the Nginx
server, and that the correct TLS certificate is being used.
```bash
```console
$ curl --cacert root-ca.crt https://localhost:3000
<!DOCTYPE html>
@ -557,7 +556,7 @@ generate the site key and certificate, name the files `site.key` and
</html>
```
```bash
```console
$ openssl s_client -connect localhost:3000 -CAfile root-ca.crt
CONNECTED(00000003)
@ -601,7 +600,7 @@ generate the site key and certificate, name the files `site.key` and
7. To clean up after running this example, remove the `nginx` service and the
stored secrets.
```bash
```console
$ docker service rm nginx
$ docker secret rm site.crt site.key site.conf
@ -647,7 +646,7 @@ line.
The last argument is set to `-`, which indicates that the input is read from
standard input.
```bash
```console
$ openssl rand -base64 20 | docker secret create mysql_password -
l1vinzevzhj4goakjap5ya409
@ -660,13 +659,13 @@ line.
shared with the WordPress service created later. It's only needed to
bootstrap the `mysql` service.
```bash
```console
$ openssl rand -base64 20 | docker secret create mysql_root_password -
```
List the secrets managed by Docker using `docker secret ls`:
```bash
```console
$ docker secret ls
ID NAME CREATED UPDATED
@ -680,7 +679,7 @@ line.
between the MySQL and WordPress services. There is no need to expose the
MySQL service to any external host or container.
```bash
```console
$ docker network create -d overlay mysql_private
```
@ -711,7 +710,7 @@ line.
user cannot create or drop databases or change the MySQL
configuration.
```bash
```console
$ docker service create \
--name mysql \
--replicas 1 \
@ -728,7 +727,7 @@ line.
4. Verify that the `mysql` container is running using the `docker service ls` command.
```bash
```console
$ docker service ls
ID NAME MODE REPLICAS IMAGE
@ -768,7 +767,7 @@ line.
- Stores its data, such as themes and plugins, in a volume called `wpdata`
so these files persist when the service restarts.
```bash
```console
$ docker service create \
--name wordpress \
--replicas 1 \
@ -786,7 +785,7 @@ line.
6. Verify the service is running using `docker service ls` and
`docker service ps` commands.
```bash
```console
$ docker service ls
ID NAME MODE REPLICAS IMAGE
@ -794,7 +793,7 @@ line.
nzt5xzae4n62 wordpress replicated 1/1 wordpress:latest
```
```bash
```console
$ docker service ps wordpress
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
@ -836,7 +835,7 @@ use it, then remove the old secret.
1. Create the new password and store it as a secret named `mysql_password_v2`.
```bash
```console
$ openssl rand -base64 20 | docker secret create mysql_password_v2 -
```
@ -844,7 +843,7 @@ use it, then remove the old secret.
Remember that you cannot update or rename a secret, but you can revoke a
secret and grant access to it using a new target filename.
```bash
```console
$ docker service update \
--secret-rm mysql_password mysql
@ -874,7 +873,7 @@ use it, then remove the old secret.
First, find the ID of the `mysql` container task.
```bash
```console
$ docker ps --filter name=mysql -q
c7705cf6176f
@ -883,14 +882,14 @@ use it, then remove the old secret.
Substitute the ID in the command below, or use the second variant which
uses shell expansion to do it all in a single step.
```bash
```console
$ docker container exec <CONTAINER_ID> \
bash -c 'mysqladmin --user=wordpress --password="$(< /run/secrets/old_mysql_password)" password "$(< /run/secrets/mysql_password)"'
```
**or**:
```bash
```console
$ docker container exec $(docker ps --filter name=mysql -q) \
bash -c 'mysqladmin --user=wordpress --password="$(< /run/secrets/old_mysql_password)" password "$(< /run/secrets/mysql_password)"'
```
@ -900,7 +899,7 @@ use it, then remove the old secret.
`0400`. This triggers a rolling restart of the WordPress service and
the new secret is used.
```bash
```console
$ docker service update \
--secret-rm mysql_password \
--secret-add source=mysql_password_v2,target=wp_db_password,mode=0400 \
@ -917,8 +916,7 @@ use it, then remove the old secret.
6. Revoke access to the old secret from the MySQL service and
remove the old secret from Docker.
```bash
```console
$ docker service update \
--secret-rm mysql_password \
mysql
@ -932,7 +930,7 @@ use it, then remove the old secret.
WordPress service, the MySQL container, the `mydata` and `wpdata` volumes,
and the Docker secrets.
```bash
```console
$ docker service rm wordpress mysql
$ docker volume rm mydata wpdata

84
engine/swarm/services.md
View File

@ -29,14 +29,14 @@ to supply the image name. This command starts an Nginx service with a
randomly-generated name and no published ports. This is a naive example, since
you can't interact with the Nginx service.
```bash
```console
$ docker service create nginx
```
The service is scheduled on an available node. To confirm that the service
was created and started successfully, use the `docker service ls` command:
```bash
```console
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
@ -51,7 +51,7 @@ information.
To provide a name for your service, use the `--name` flag:
```bash
```console
$ docker service create --name my_web nginx
```
@ -60,14 +60,14 @@ service's containers should run, by adding it after the image name. This example
starts a service called `helloworld` which uses an `alpine` image and runs the
command `ping docker.com`:
```bash
```console
$ docker service create --name helloworld alpine ping docker.com
```
You can also specify an image tag for the service to use. This example modifies
the previous one to use the `alpine:3.6` tag:
```bash
```console
$ docker service create --name helloworld alpine:3.6 ping docker.com
```
@ -83,14 +83,14 @@ The following example assumes a gMSA and its credential spec (called credspec.js
To use a Config as a credential spec, first create the Docker Config containing the credential spec:
```bash
docker config create credspec credspec.json
```console
$ docker config create credspec credspec.json
```
Now, you should have a Docker Config named credspec, and you can create a service using this credential spec. To do so, use the --credential-spec flag with the config name, like this:
```bash
docker service create --credential-spec="config://credspec" <your image>
```console
$ docker service create --credential-spec="config://credspec" <your image>
```
Your service will use the gMSA credential spec when it starts, but unlike a typical Docker Config (used by passing the --config flag), the credential spec will not be mounted into the container.
@ -102,7 +102,7 @@ If your image is available on a private registry which requires login, use the
your image is stored on `registry.example.com`, which is a private registry, use
a command like the following:
```bash
```console
$ docker login registry.example.com
$ docker service create \
@ -167,13 +167,13 @@ was previously published.
Assuming that the `my_web` service from the previous section still exists, use
the following command to update it to publish port 80.
```bash
```console
$ docker service update --publish-add 80 my_web
```
To verify that it worked, use `docker service ls`:
```bash
```console
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
@ -193,7 +193,7 @@ To remove a service, use the `docker service remove` command. You can remove a
service by its ID or name, as shown in the output of the `docker service ls`
command. The following command removes the `my_web` service.
```bash
```console
$ docker service remove my_web
```
@ -222,7 +222,7 @@ The following service's containers have an environment variable `$MYVAR`
set to `myvalue`, run from the `/tmp/` directory, and run as the
`my_user` user.
```bash
```console
$ docker service create --name helloworld \
--env MYVAR=myvalue \
--workdir /tmp \
@ -237,7 +237,7 @@ The following example updates an existing service called `helloworld` so that
it runs the command `ping docker.com` instead of whatever command it was running
before:
```bash
```console
$ docker service update --args "ping docker.com" helloworld
```
@ -255,7 +255,7 @@ An image version can be expressed in several different ways:
When the request to create a container task is received on a worker node, the
worker node only sees the digest, not the tag.
```bash
```console
$ docker service create --name="myservice" ubuntu:16.04
```
@ -274,7 +274,7 @@ An image version can be expressed in several different ways:
Thus, the following two commands are equivalent:
```bash
```console
$ docker service create --name="myservice" ubuntu
$ docker service create --name="myservice" ubuntu:latest
@ -283,7 +283,7 @@ An image version can be expressed in several different ways:
- If you specify a digest directly, that exact version of the image is always
used when creating service tasks.
```bash
```console
$ docker service create \
--name="myservice" \
ubuntu:16.04@sha256:35bc48a1ca97c3971611dc4662d08d131869daa692acb281c7e9e052924e38b1
@ -318,7 +318,7 @@ To see an image's current digest, issue the command
following is the current digest for `ubuntu:latest` at the time this content
was written. The output is truncated for clarity.
```bash
```console
$ docker inspect ubuntu:latest
```
@ -426,7 +426,7 @@ more details about swarm service networking, see
Imagine that you have a 10-node swarm, and you deploy an Nginx service running
three tasks on a 10-node swarm:
```bash
```console
$ docker service create --name my_web \
--replicas 3 \
--publish published=8080,target=80 \
@ -442,7 +442,7 @@ host, substitute the host's IP address or resolvable host name.
The HTML output is truncated:
```bash
```console
$ curl localhost:8080
<!DOCTYPE html>
@ -483,7 +483,7 @@ web page for (effectively) **a random swarm node** running the service.
The following example runs nginx as a service on each node in your swarm and
exposes nginx port locally on each swarm node.
```bash
```console
$ docker service create \
--mode global \
--publish mode=host,target=80,published=8080 \
@ -506,7 +506,7 @@ You can use overlay networks to connect one or more services within the swarm.
First, create overlay network on a manager node using the `docker network create`
command with the `--driver overlay` flag.
```bash
```console
$ docker network create --driver overlay my-network
```
@ -516,7 +516,7 @@ to the network.
You can create a new service and pass the `--network` flag to attach the service
to the overlay network:
```bash
```console
$ docker service create \
--replicas 3 \
--network my-network \
@ -529,13 +529,13 @@ The swarm extends `my-network` to each node running the service.
You can also connect an existing service to an overlay network using the
`--network-add` flag.
```bash
```console
$ docker service update --network-add my-network my-web
```
To disconnect a running service from a network, use the `--network-rm` flag.
```bash
```console
$ docker service update --network-rm my-network my-web
```
@ -627,7 +627,7 @@ mode, the service defaults to `replicated`. For replicated services, you specify
the number of replica tasks you want to start using the `--replicas` flag. For
example, to start a replicated nginx service with 3 replica tasks:
```bash
```console
$ docker service create \
--name my_web \
--replicas 3 \
@ -639,7 +639,7 @@ To start a global service on each available node, pass `--mode global` to
places a task for the global service on the new node. For example to start a
service that runs alpine on every node in the swarm:
```bash
```console
$ docker service create \
--name myservice \
--mode global \
@ -684,7 +684,7 @@ services run on the same node, or each node only runs one replica, or that some
nodes don't run any replicas. For global services, the service runs on every
node that meets the placement constraint and any [resource requirements](#reserve-memory-or-cpus-for-a-service).
```bash
```console
$ docker service create \
--name my-nginx \
--replicas 5 \
@ -699,7 +699,7 @@ If you specify multiple placement constraints, the service only deploys onto
nodes where they are all met. The following example limits the service to run on
all nodes where `region` is set to `east` and `type` is not set to `devel`:
```bash
```console
$ docker service create \
--name my-nginx \
--mode global \
@ -735,7 +735,7 @@ based on the value of the `datacenter` label. If some nodes have
`datacenter=us-east` and others have `datacenter=us-west`, the service is
deployed as evenly as possible across the two sets of nodes.
```bash
```console
$ docker service create \
--replicas 9 \
--name redis_2 \
@ -758,7 +758,7 @@ order they are encountered. The following example sets up a service with
multiple placement preferences. Tasks are spread first over the various
datacenters, and then over racks (as indicated by the respective labels):
```bash
```console
$ docker service create \
--replicas 9 \
--name redis_2 \
@ -807,7 +807,7 @@ In the example service below, the scheduler applies updates to a maximum of 2
replicas at a time. When an updated task returns either `RUNNING` or `FAILED`,
the scheduler waits 10 seconds before stopping the next task to update:
```bash
```console
$ docker service create \
--replicas 10 \
--name my_web \
@ -840,7 +840,7 @@ to the configuration that was in place before the most recent
Other options can be combined with `--rollback`; for example,
`--update-delay 0s` to execute the rollback without a delay between tasks:
```bash
```console
$ docker service update \
--rollback \
--update-delay 0s
@ -876,7 +876,7 @@ parallel. Tasks are monitored for 20 seconds after rollback to be sure they do
not exit, and a maximum failure ratio of 20% is tolerated. Default values are
used for `--rollback-delay` and `--rollback-failure-action`.
```bash
```console
$ docker service create --name=my_redis \
--replicas=5 \
--rollback-parallelism=2 \
@ -908,7 +908,7 @@ created automatically according to the volume specification on the service.
To use existing data volumes with a service use the `--mount` flag:
```bash
```console
$ docker service create \
--mount src=<VOLUME-NAME>,dst=<CONTAINER-PATH> \
--name myservice \
@ -920,7 +920,7 @@ scheduled to a particular host, then one is created. The default volume
driver is `local`. To use a different volume driver with this create-on-demand
pattern, specify the driver and its options with the `--mount` flag:
```bash
```console
$ docker service create \
--mount type=volume,src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=<DRIVER>,volume-opt=<KEY0>=<VALUE0>,volume-opt=<KEY1>=<VALUE1>
--name myservice \
@ -942,7 +942,7 @@ The following examples show bind mount syntax:
- To mount a read-write bind:
```bash
```console
$ docker service create \
--mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH> \
--name myservice \
@ -951,7 +951,7 @@ The following examples show bind mount syntax:
- To mount a read-only bind:
```bash
```console
$ docker service create \
--mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH>,readonly \
--name myservice \
@ -1005,7 +1005,7 @@ This example sets the template of the created containers based on the
service's name and the ID of the node where the container is running:
{% raw %}
```bash
```console
$ docker service create --name hosttempl \
--hostname="{{.Node.ID}}-{{.Service.Name}}"\
busybox top
@ -1015,7 +1015,7 @@ $ docker service create --name hosttempl \
To see the result of using the template, use the `docker service ps` and
`docker inspect` commands.
```bash
```console
$ docker service ps va8ew30grofhjoychbr6iot8c
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
@ -1023,7 +1023,7 @@ wo41w8hg8qan hosttempl.1 busybox:latest@sha256:29f5d56d12684887bdfa50dcd29fc31
```
{% raw %}
```bash
```console
$ docker inspect --format="{{.Config.Hostname}}" hosttempl.1.wo41w8hg8qanxwjwsg4kxpprj
```
{% endraw %}

30
engine/swarm/stack-deploy.md
View File

@ -39,13 +39,13 @@ a throwaway registry, which you can discard afterward.
1. Start the registry as a service on your swarm:
```bash
```console
$ docker service create --name registry --publish published=5000,target=5000 registry:2
```
2. Check its status with `docker service ls`:
```bash
```console
$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
@ -57,7 +57,7 @@ a throwaway registry, which you can discard afterward.
3. Check that it's working with `curl`:
```bash
```console
$ curl http://localhost:5000/v2/
{}
@ -72,7 +72,7 @@ counter whenever you visit it.
1. Create a directory for the project:
```bash
```console
$ mkdir stackdemo
$ cd stackdemo
```
@ -163,7 +163,7 @@ counter whenever you visit it.
2. Check that the app is running with `docker-compose ps`:
```bash
```console
$ docker-compose ps
Name Command State Ports
@ -174,7 +174,7 @@ counter whenever you visit it.
You can test the app with `curl`:
```bash
```console
$ curl http://localhost:8000
Hello World! I have been seen 1 times.
@ -187,7 +187,7 @@ counter whenever you visit it.
3. Bring the app down:
```bash
```console
$ docker-compose down --volumes
Stopping stackdemo_web_1 ... done
@ -203,7 +203,7 @@ counter whenever you visit it.
To distribute the web app's image across the swarm, it needs to be pushed to the
registry you set up earlier. With Compose, this is very simple:
```bash
```console
$ docker-compose push
Pushing web (127.0.0.1:5000/stackdemo:latest)...
@ -223,7 +223,7 @@ The stack is now ready to be deployed.
1. Create the stack with `docker stack deploy`:
```bash
```console
$ docker stack deploy --compose-file docker-compose.yml stackdemo
Ignoring unsupported options: build
@ -238,7 +238,7 @@ The stack is now ready to be deployed.
2. Check that it's running with `docker stack services stackdemo`:
```bash
```console
$ docker stack services stackdemo
ID NAME MODE REPLICAS IMAGE
@ -252,7 +252,7 @@ The stack is now ready to be deployed.
As before, you can test the app with `curl`:
```bash
```console
$ curl http://localhost:8000
Hello World! I have been seen 1 times.
@ -266,14 +266,14 @@ The stack is now ready to be deployed.
Thanks to Docker's built-in routing mesh, you can access any node in the
swarm on port 8000 and get routed to the app:
```bash
```console
$ curl http://address-of-other-node:8000
Hello World! I have been seen 4 times.
```
3. Bring the stack down with `docker stack rm`:
```bash
```console
$ docker stack rm stackdemo
Removing service stackdemo_web
@ -283,14 +283,14 @@ The stack is now ready to be deployed.
4. Bring the registry down with `docker service rm`:
```bash
```console
$ docker service rm registry
```
5. If you're just testing things out on a local machine and want to bring your
Docker Engine out of swarm mode, use `docker swarm leave`:
```bash
```console
$ docker swarm leave --force
Node left the swarm.

18
engine/swarm/swarm-mode.md
View File

@ -51,7 +51,7 @@ external to the swarm.
The output for `docker swarm init` provides the connection command to use when
you join new worker nodes to the swarm:
```bash
```console
$ docker swarm init
Swarm initialized: current node (dxn1zf6l61qsb1josjja83ngz) is now a manager.
@ -83,20 +83,20 @@ The subnet range comes from the `--default-addr-pool`, (such as `10.10.0.0/16`).
The format of the command is:
```bash
```console
$ docker swarm init --default-addr-pool <IP range in CIDR> [--default-addr-pool <IP range in CIDR> --default-addr-pool-mask-length <CIDR value>]
```
To create a default IP address pool with a /16 (class B) for the 10.20.0.0 network looks like this:
```bash
```console
$ docker swarm init --default-addr-pool 10.20.0.0/16
```
To create a default IP address pool with a `/16` (class B) for the `10.20.0.0` and `10.30.0.0` networks, and to
create a subnet mask of `/26` for each network looks like this:
```bash
```console
$ docker swarm init --default-addr-pool 10.20.0.0/16 --default-addr-pool 10.30.0.0/16 --default-addr-pool-mask-length 26
```
@ -120,7 +120,7 @@ single IP address. If so, Docker uses the IP address with the listening port
correct `--advertise-addr` to enable inter-manager communication and overlay
networking:
```bash
```console
$ docker swarm init --advertise-addr <MANAGER-IP>
```
@ -146,7 +146,7 @@ swarm.
To retrieve the join command including the join token for worker nodes, run:
```bash
```console
$ docker swarm join-token worker
To add a worker to this swarm, run the following command:
@ -160,7 +160,7 @@ This node joined a swarm as a worker.
To view the join command and token for manager nodes, run:
```bash
```console
$ docker swarm join-token manager
To add a worker to this swarm, run the following command:
@ -172,7 +172,7 @@ To add a worker to this swarm, run the following command:
Pass the `--quiet` flag to print only the token:
```bash
```console
$ docker swarm join-token --quiet worker
SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c
@ -200,7 +200,7 @@ Run `swarm join-token --rotate` to invalidate the old token and generate a new
token. Specify whether you want to rotate the token for `worker` or `manager`
nodes:
```bash
```console
$ docker swarm join-token --rotate worker
To add a worker to this swarm, run the following command:

9
engine/swarm/swarm-tutorial/add-nodes.md
View File

@ -15,7 +15,7 @@ to add worker nodes.
[Create a swarm](create-swarm.md) tutorial step to create a worker node
joined to the existing swarm:
```bash
```console
$ docker swarm join \
--token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \
192.168.99.100:2377
@ -26,7 +26,7 @@ to add worker nodes.
If you don't have the command available, you can run the following command
on a manager node to retrieve the join command for a worker:
```bash
```console
$ docker swarm join-token worker
To add a worker to this swarm, run the following command:
@ -43,7 +43,7 @@ to add worker nodes.
[Create a swarm](create-swarm.md) tutorial step to create a second worker
node joined to the existing swarm:
```bash
```console
$ docker swarm join \
--token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \
192.168.99.100:2377
@ -54,7 +54,8 @@ to add worker nodes.
5. Open a terminal and ssh into the machine where the manager node runs and
run the `docker node ls` command to see the worker nodes:
```bash
```console
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
03g1y59jwfg7cf99w4lt0f662 worker2 Ready Active
9j68exjopxe7wfl6yuxml7a7j worker1 Ready Active

10
engine/swarm/swarm-tutorial/create-swarm.md
View File

@ -13,13 +13,13 @@ machines.
node. This tutorial uses a machine named `manager1`. If you use Docker Machine,
you can connect to it via SSH using the following command:
```bash
```console
$ docker-machine ssh manager1
```
2. Run the following command to create a new swarm:
```bash
```console
$ docker swarm init --advertise-addr <MANAGER-IP>
```
@ -33,7 +33,7 @@ machines.
In the tutorial, the following command creates a swarm on the `manager1`
machine:
```bash
```console
$ docker swarm init --advertise-addr 192.168.99.100
Swarm initialized: current node (dxn1zf6l61qsb1josjja83ngz) is now a manager.
@ -56,7 +56,7 @@ machines.
2. Run `docker info` to view the current state of the swarm:
```bash
```console
$ docker info
Containers: 2
@ -74,7 +74,7 @@ machines.
3. Run the `docker node ls` command to view information about nodes:
```bash
```console
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS

6
engine/swarm/swarm-tutorial/delete-service.md
View File

@ -14,7 +14,7 @@ you can delete the service from the swarm.
2. Run `docker service rm helloworld` to remove the `helloworld` service.
```bash
```console
$ docker service rm helloworld
helloworld
@ -24,7 +24,7 @@ you can delete the service from the swarm.
removed the service. The CLI returns a message that the service is not
found:
```bash
```console
$ docker service inspect helloworld
[]
Error: no such service: helloworld
@ -34,7 +34,7 @@ you can delete the service from the swarm.
seconds to clean up. You can use `docker ps` on the nodes to verify when the
tasks have been removed.
```bash
```console
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

4
engine/swarm/swarm-tutorial/deploy-service.md
View File

@ -14,7 +14,7 @@ is not a requirement to deploy a service.
2. Run the following command:
```bash
```console
$ docker service create --replicas 1 --name helloworld alpine ping docker.com
9uk4639qpg7npwf3fn2aasksr
@ -28,7 +28,7 @@ is not a requirement to deploy a service.
3. Run `docker service ls` to see the list of running services:
```bash
```console
$ docker service ls
ID NAME SCALE IMAGE COMMAND

18
engine/swarm/swarm-tutorial/drain-node.md
View File

@ -26,7 +26,7 @@ node and launches replica tasks on a node with `ACTIVE` availability.
2. Verify that all your nodes are actively available.
```bash
```console
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
@ -38,7 +38,7 @@ node and launches replica tasks on a node with `ACTIVE` availability.
3. If you aren't still running the `redis` service from the
[rolling update](rolling-update.md) tutorial, start it now:
```bash
```console
$ docker service create --replicas 3 --name redis --update-delay 10s redis:3.0.6
c5uo6kdmzpon37mgj9mwglcfw
@ -47,7 +47,7 @@ node and launches replica tasks on a node with `ACTIVE` availability.
4. Run `docker service ps redis` to see how the swarm manager assigned the
tasks to different nodes:
```bash
```console
$ docker service ps redis
NAME IMAGE NODE DESIRED STATE CURRENT STATE
@ -62,15 +62,15 @@ tasks to different nodes:
5. Run `docker node update --availability drain <NODE-ID>` to drain a node that
had a task assigned to it:
```bash
docker node update --availability drain worker1
```console
$ docker node update --availability drain worker1
worker1
```
6. Inspect the node to check its availability:
```bash
```console
$ docker node inspect --pretty worker1
ID: 38ciaotwjuritcdtn9npbnkuz
@ -86,7 +86,7 @@ had a task assigned to it:
7. Run `docker service ps redis` to see how the swarm manager updated the
task assignments for the `redis` service:
```bash
```console
$ docker service ps redis
NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR
@ -103,7 +103,7 @@ task assignments for the `redis` service:
8. Run `docker node update --availability active <NODE-ID>` to return the
drained node to an active state:
```bash
```console
$ docker node update --availability active worker1
worker1
@ -111,7 +111,7 @@ drained node to an active state:
9. Inspect the node to see the updated state:
```bash
```console
$ docker node inspect --pretty worker1
ID: 38ciaotwjuritcdtn9npbnkuz

8
engine/swarm/swarm-tutorial/inspect-service.md
View File

@ -17,7 +17,7 @@ the Docker CLI to see details about the service running in the swarm.
To see the details on the `helloworld` service:
```bash
```console
[manager1]$ docker service inspect --pretty helloworld
ID: 9uk4639qpg7npwf3fn2aasksr
@ -37,7 +37,7 @@ the Docker CLI to see details about the service running in the swarm.
>**Tip**: To return the service details in json format, run the same command
without the `--pretty` flag.
```bash
```console
[manager1]$ docker service inspect helloworld
[
{
@ -89,7 +89,7 @@ the Docker CLI to see details about the service running in the swarm.
4. Run `docker service ps <SERVICE-ID>` to see which nodes are running the
service:
```bash
```console
[manager1]$ docker service ps helloworld
NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
@ -110,7 +110,7 @@ the Docker CLI to see details about the service running in the swarm.
>**Tip**: If `helloworld` is running on a node other than your manager node,
you must ssh to that node.
```bash
```console
[worker2]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

16
engine/swarm/swarm-tutorial/rolling-update.md
View File

@ -17,7 +17,7 @@ Redis 3.0.7 container image using rolling updates.
2. Deploy your Redis tag to the swarm and configure the swarm with a 10 second
update delay. Note that the following example shows an older Redis tag:
```bash
```console
$ docker service create \
--replicas 3 \
--name redis \
@ -47,7 +47,7 @@ Redis 3.0.7 container image using rolling updates.
3. Inspect the `redis` service:
```bash
```console
$ docker service inspect --pretty redis
ID: 0u6a4s31ybk7yw2wyvtikmu50
@ -68,7 +68,7 @@ Redis 3.0.7 container image using rolling updates.
4. Now you can update the container image for `redis`. The swarm manager
applies the update to nodes according to the `UpdateConfig` policy:
```bash
```console
$ docker service update --image redis:3.0.7 redis
redis
```
@ -86,7 +86,7 @@ Redis 3.0.7 container image using rolling updates.
5. Run `docker service inspect --pretty redis` to see the new image in the
desired state:
```bash
```console
$ docker service inspect --pretty redis
ID: 0u6a4s31ybk7yw2wyvtikmu50
@ -106,7 +106,7 @@ Redis 3.0.7 container image using rolling updates.
The output of `service inspect` shows if your update paused due to failure:
```bash
```console
$ docker service inspect --pretty redis
ID: 0u6a4s31ybk7yw2wyvtikmu50
@ -121,8 +121,8 @@ Redis 3.0.7 container image using rolling updates.
To restart a paused update run `docker service update <SERVICE-ID>`. For example:
```bash
docker service update redis
```console
$ docker service update redis
```
To avoid repeating certain update failures, you may need to reconfigure the
@ -130,7 +130,7 @@ Redis 3.0.7 container image using rolling updates.
6. Run `docker service ps <SERVICE-ID>` to watch the rolling update:
```bash
```console
$ docker service ps redis
NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR

8
engine/swarm/swarm-tutorial/scale-service.md
View File

@ -16,13 +16,13 @@ the service. Containers running in a service are called "tasks."
2. Run the following command to change the desired state of the
service running in the swarm:
```bash
```console
$ docker service scale <SERVICE-ID>=<NUMBER-OF-TASKS>
```
For example:
```bash
```console
$ docker service scale helloworld=5
helloworld scaled to 5
@ -30,7 +30,7 @@ the service. Containers running in a service are called "tasks."
3. Run `docker service ps <SERVICE-ID>` to see the updated task list:
```bash
```console
$ docker service ps helloworld
NAME IMAGE NODE DESIRED STATE CURRENT STATE
@ -48,7 +48,7 @@ the service. Containers running in a service are called "tasks."
4. Run `docker ps` to see the containers running on the node where you're
connected. The following example shows the tasks running on `manager1`:
```bash
```console
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

14
engine/swarm/swarm_manager_locking.md
View File

@ -29,7 +29,7 @@ rotate this key encryption key at any time.
When you initialize a new swarm, you can use the `--autolock` flag to
enable autolocking of swarm manager nodes when Docker restarts.
```bash
```console
$ docker swarm init --autolock
Swarm initialized: current node (k1q27tfyx9rncpixhk69sa61v) is now a manager.
@ -54,7 +54,7 @@ When Docker restarts, you need to [unlock the swarm](#unlock-a-swarm). A locked
swarm causes an error like the following when you try to start or restart a
service:
```bash
```console
$ sudo service docker restart
$ docker service ls
@ -66,7 +66,7 @@ Error response from daemon: Swarm is encrypted and needs to be unlocked before i
To enable autolock on an existing swarm, set the `autolock` flag to `true`.
```bash
```console
$ docker swarm update --autolock=true
Swarm updated.
@ -85,7 +85,7 @@ disk. There is a trade-off between the risk of storing the encryption key
unencrypted at rest and the convenience of restarting a swarm without
needing to unlock each manager.
```bash
```console
$ docker swarm update --autolock=false
```
@ -96,7 +96,7 @@ a manager goes down while it is still configured to lock using the old key.
To unlock a locked swarm, use `docker swarm unlock`.
```bash
```console
$ docker swarm unlock
Please enter unlock key:
@ -116,7 +116,7 @@ If the key has not been rotated since the node left the swarm, and you have a
quorum of functional manager nodes in the swarm, you can view the current unlock
key using `docker swarm unlock-key` without any arguments.
```bash
```console
$ docker swarm unlock-key
To unlock a swarm manager after it restarts, run the `docker swarm unlock`
@ -136,7 +136,7 @@ the swarm and join it back to the swarm as a new manager.
You should rotate the locked swarm's unlock key on a regular schedule.
```bash
```console
$ docker swarm unlock-key --rotate
Successfully rotated manager unlock key.

2
engine/tutorials/networkingcontainers.md
View File

@ -37,7 +37,7 @@ The network named `bridge` is a special network. Unless you tell it otherwise, D
Inspecting the network is an easy way to find out the container's IP address.
```bash
```console
$ docker network inspect bridge
[

8
get-started/02_our_app.md
View File

@ -56,8 +56,8 @@ see a few flaws in the Dockerfile below. But, don't worry. We'll go over them.
2. If you haven't already done so, open a terminal and go to the `app` directory with the `Dockerfile`. Now build the container image using the `docker build` command.
```bash
docker build -t getting-started .
```console
$ docker build -t getting-started .
```
This command used the Dockerfile to build a new container image. You might
@ -83,8 +83,8 @@ command (remember that from earlier?).
1. Start your container using the `docker run` command and specify the name of the image we
just created:
```bash
docker run -dp 3000:3000 getting-started
```console
$ docker run -dp 3000:3000 getting-started
```
Remember the `-d` and `-p` flags? We're running the new container in "detached" mode (in the

26
get-started/03_updating_app.md
View File

@ -24,19 +24,19 @@ Pretty simple, right? Let's make the change.
2. Let's build our updated version of the image, using the same command we used before.
```bash
docker build -t getting-started .
```console
$ docker build -t getting-started .
```
3. Let's start a new container using the updated code.
```bash
docker run -dp 3000:3000 getting-started
```console
$ docker run -dp 3000:3000 getting-started
```
**Uh oh!** You probably saw an error like this (the IDs will be different):
```bash
```console
docker: Error response from daemon: driver failed programming external connectivity on endpoint laughing_burnell
(bb242b2ca4d67eba76e79474fb36bb5125708ebdabd7f45c8eaf16caaabde9dd): Bind for 0.0.0.0:3000 failed: port is already allocated.
```
@ -55,21 +55,21 @@ ways that we can remove the old container. Feel free to choose the path that you
1. Get the ID of the container by using the `docker ps` command.
```bash
docker ps
```console
$ docker ps
```
2. Use the `docker stop` command to stop the container.
```bash
```console
# Swap out <the-container-id> with the ID from docker ps
docker stop <the-container-id>
$ docker stop <the-container-id>
```
3. Once the container has stopped, you can remove it by using the `docker rm` command.
```bash
docker rm <the-container-id>
```console
$ docker rm <the-container-id>
```
>**Note**
@ -96,8 +96,8 @@ much easier than having to look up the container ID and remove it.
1. Now, start your updated app.
```bash
docker run -dp 3000:3000 getting-started
```console
$ docker run -dp 3000:3000 getting-started
```
2. Refresh your browser on [http://localhost:3000](http://localhost:3000) and you should see your updated help text!

12
get-started/04_sharing_app.md
View File

@ -58,16 +58,16 @@ an example command that you will need to run to push to this repo.
3. Use the `docker tag` command to give the `getting-started` image a new name. Be sure to swap out
`YOUR-USER-NAME` with your Docker ID.
```bash
docker tag getting-started YOUR-USER-NAME/getting-started
```console
$ docker tag getting-started YOUR-USER-NAME/getting-started
```
4. Now try your push command again. If you're copying the value from Docker Hub, you can drop the
`tagname` portion, as we didn't add a tag to the image name. If you don't specify a tag, Docker
will use a tag called `latest`.
```bash
docker push YOUR-USER-NAME/getting-started
```console
$ docker push YOUR-USER-NAME/getting-started
```
## Run the image on a new instance
@ -87,8 +87,8 @@ new instance that has never seen this container image! To do this, we will use P
5. In the terminal, start your freshly pushed app.
```bash
docker run -dp 3000:3000 YOUR-USER-NAME/getting-started
```console
$ docker run -dp 3000:3000 YOUR-USER-NAME/getting-started
```
You should see the image get pulled down and eventually start up!

28
get-started/05_persisting_data.md
View File

@ -21,8 +21,8 @@ What you'll see is that the files created in one container aren't available in a
1. Start an `ubuntu` container that will create a file named `/data.txt` with a random number
between 1 and 10000.
```bash
docker run -d ubuntu bash -c "shuf -i 1-10000 -n 1 -o /data.txt && tail -f /dev/null"
```console
$ docker run -d ubuntu bash -c "shuf -i 1-10000 -n 1 -o /data.txt && tail -f /dev/null"
```
In case you're curious about the command, we're starting a bash shell and invoking two
@ -35,15 +35,15 @@ What you'll see is that the files created in one container aren't available in a
You will see a terminal that is running a shell in the ubuntu container. Run the following command to see the content of the `/data.txt` file. Close this terminal afterwards again.
```bash
cat /data.txt
```console
$ cat /data.txt
```
If you prefer the command line you can use the `docker exec` command to do the same. You need to get the
container's ID (use `docker ps` to get it) and get the content with the following command.
```bash
docker exec <container-id> cat /data.txt
```console
$ docker exec <container-id> cat /data.txt
```
You should see a random number!
@ -51,8 +51,8 @@ What you'll see is that the files created in one container aren't available in a
3. Now, let's start another `ubuntu` container (the same image) and we'll see we don't have the same
file.
```bash
docker run -it ubuntu ls /
```console
$ docker run -it ubuntu ls /
```
And look! There's no `data.txt` file there! That's because it was written to the scratch space for
@ -91,8 +91,8 @@ Every time you use the volume, Docker will make sure the correct data is provide
1. Create a volume by using the `docker volume create` command.
```bash
docker volume create todo-db
```console
$ docker volume create todo-db
```
2. Stop and remove the todo app container once again in the Dashboard (or with `docker rm -f <id>`), as it is still running without using the persistent volume.
@ -100,8 +100,8 @@ Every time you use the volume, Docker will make sure the correct data is provide
3. Start the todo app container, but add the `-v` flag to specify a volume mount. We will use the named volume and mount
it to `/etc/todos`, which will capture all files created at the path.
```bash
docker run -dp 3000:3000 -v todo-db:/etc/todos getting-started
```console
$ docker run -dp 3000:3000 -v todo-db:/etc/todos getting-started
```
4. Once the container starts up, open the app and add a few items to your todo list.
@ -132,8 +132,8 @@ Hooray! You've now learned how to persist data!
A lot of people frequently ask "Where is Docker _actually_ storing my data when I use a named volume?" If you want to know,
you can use the `docker volume inspect` command.
```bash
docker volume inspect todo-db
```console
$ docker volume inspect todo-db
[
{
"CreatedAt": "2019-09-26T02:18:36Z",

10
get-started/06_bind_mounts.md
View File

@ -42,8 +42,8 @@ So, let's do it!
2. Run the following command. We'll explain what's going on afterwards:
```bash
docker run -dp 3000:3000 \
```console
$ docker run -dp 3000:3000 \
-w /app -v "$(pwd):/app" \
node:12-alpine \
sh -c "yarn install && yarn run dev"
@ -68,9 +68,9 @@ So, let's do it!
3. You can watch the logs using `docker logs -f <container-id>`. You'll know you're ready to go when you see this:
```bash
docker logs -f <container-id>
$ nodemon src/index.js
```console
$ docker logs -f <container-id>
nodemon src/index.js
[nodemon] 1.19.2
[nodemon] to restart at any time, enter `rs`
[nodemon] watching dir(s): *.*

28
get-started/07_multi_container.md
View File

@ -38,15 +38,15 @@ For now, we will create the network first and attach the MySQL container at star
1. Create the network.
```bash
docker network create todo-app
```console
$ docker network create todo-app
```
2. Start a MySQL container and attach it to the network. We're also going to define a few environment variables that the
database will use to initialize the database (see the "Environment Variables" section in the [MySQL Docker Hub listing](https://hub.docker.com/_/mysql/)).
```bash
docker run -d \
```console
$ docker run -d \
--network todo-app --network-alias mysql \
-v todo-mysql-data:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=secret \
@ -73,8 +73,8 @@ For now, we will create the network first and attach the MySQL container at star
3. To confirm we have the database up and running, connect to the database and verify it connects.
```bash
docker exec -it <mysql-container-id> mysql -u root -p
```console
$ docker exec -it <mysql-container-id> mysql -u root -p
```
When the password prompt comes up, type in **secret**. In the MySQL shell, list the databases and verify
@ -112,15 +112,15 @@ which ships with a _lot_ of tools that are useful for troubleshooting or debuggi
1. Start a new container using the nicolaka/netshoot image. Make sure to connect it to the same network.
```bash
docker run -it --network todo-app nicolaka/netshoot
```console
$ docker run -it --network todo-app nicolaka/netshoot
```
2. Inside the container, we're going to use the `dig` command, which is a useful DNS tool. We're going to look up
the IP address for the hostname `mysql`.
```bash
dig mysql
```console
$ dig mysql
```
And you'll get an output like this...
@ -180,8 +180,8 @@ With all of that explained, let's start our dev-ready container!
1. We'll specify each of the environment variables above, as well as connect the container to our app network.
```bash
docker run -dp 3000:3000 \
```console
$ docker run -dp 3000:3000 \
-w /app -v "$(pwd):/app" \
--network todo-app \
-e MYSQL_HOST=mysql \
@ -225,8 +225,8 @@ With all of that explained, let's start our dev-ready container!
4. Connect to the mysql database and prove that the items are being written to the database. Remember, the password
is **secret**.
```bash
docker exec -it <mysql-container-id> mysql -p todos
```console
$ docker exec -it <mysql-container-id> mysql -p todos
```
And in the mysql shell, run the following:

16
get-started/08_using_compose.md
View File

@ -23,8 +23,8 @@ a Linux machine, you will need to [install Docker Compose](../compose/install.md
After installation, you should be able to run the following and see version information.
```bash
docker-compose version
```console
$ docker-compose version
```
## Create the Compose file
@ -53,8 +53,8 @@ And now, we'll start migrating a service at a time into the compose file.
To remember, this was the command we were using to define our app container.
```bash
docker run -dp 3000:3000 \
```console
$ docker run -dp 3000:3000 \
-w /app -v "$(pwd):/app" \
--network todo-app \
-e MYSQL_HOST=mysql \
@ -161,8 +161,8 @@ docker run -dp 3000:3000 `
Now, it's time to define the MySQL service. The command that we used for that container was the following:
```bash
docker run -d \
```console
$ docker run -d \
--network todo-app --network-alias mysql \
-v todo-mysql-data:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=secret \
@ -276,8 +276,8 @@ Now that we have our `docker-compose.yml` file, we can start it up!
2. Start up the application stack using the `docker-compose up` command. We'll add the `-d` flag to run everything in the
background.
```bash
docker-compose up -d
```console
$ docker-compose up -d
```
When we run this, we should see output like this:

16
get-started/09_image_best.md
View File

@ -11,8 +11,8 @@ Docker has partnered with [Snyk](http://snyk.io){:target="_blank" rel="noopener"
For example, to scan the `getting-started` image you created earlier in the tutorial, you can just type
```bash
docker scan getting-started
```console
$ docker scan getting-started
```
The scan uses a constantly updated database of vulnerabilities, so the output you see will vary as new
@ -56,8 +56,8 @@ command, you can see the command that was used to create each layer within an im
1. Use the `docker image history` command to see the layers in the `getting-started` image you
created earlier in the tutorial.
```bash
docker image history getting-started
```console
$ docker image history getting-started
```
You should get output that looks something like this (dates/IDs may be different).
@ -86,8 +86,8 @@ command, you can see the command that was used to create each layer within an im
2. You'll notice that several of the lines are truncated. If you add the `--no-trunc` flag, you'll get the
full output (yes... funny how you use a truncated flag to get untruncated output, huh?)
```bash
docker image history --no-trunc getting-started
```console
$ docker image history --no-trunc getting-started
```
## Layer caching
@ -146,8 +146,8 @@ a change to the `package.json`. Make sense?
3. Build a new image using `docker build`.
```bash
docker build -t getting-started .
```console
$ docker build -t getting-started .
```
You should see output like this...

16
get-started/kube-deploy.md
View File

@ -75,8 +75,8 @@ All containers in Kubernetes are scheduled as _pods_, which are groups of co-loc
1. In a terminal, navigate to where you created `bb.yaml` and deploy your application to Kubernetes:
```shell
kubectl apply -f bb.yaml
```console
$ kubectl apply -f bb.yaml
```
you should see output that looks like the following, indicating your Kubernetes objects were created successfully:
@ -88,8 +88,8 @@ All containers in Kubernetes are scheduled as _pods_, which are groups of co-loc
2. Make sure everything worked by listing your deployments:
```shell
kubectl get deployments
```console
$ kubectl get deployments
```
if all is well, your deployment should be listed as follows:
@ -101,8 +101,8 @@ All containers in Kubernetes are scheduled as _pods_, which are groups of co-loc
This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services:
```shell
kubectl get services
```console
$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
bb-entrypoint NodePort 10.106.145.116 <none> 8080:30001/TCP 53s
@ -115,8 +115,8 @@ All containers in Kubernetes are scheduled as _pods_, which are groups of co-loc
4. Once satisfied, tear down your application:
```shell
kubectl delete -f bb.yaml
```console
$ kubectl delete -f bb.yaml
```
## Conclusion

72
get-started/orchestration.md
View File

@ -51,14 +51,14 @@ Docker Desktop will set up Kubernetes for you quickly and easily. Follow the set
4. In a terminal, navigate to where you created `pod.yaml` and create your pod:
```shell
kubectl apply -f pod.yaml
```console
$ kubectl apply -f pod.yaml
```
5. Check that your pod is up and running:
```shell
kubectl get pods
```console
$ kubectl get pods
```
You should see something like:
@ -70,8 +70,8 @@ Docker Desktop will set up Kubernetes for you quickly and easily. Follow the set
6. Check that you get the logs you'd expect for a ping process:
```shell
kubectl logs demo
```console
$ kubectl logs demo
```
You should see the output of a healthy ping process:
@ -86,8 +86,8 @@ Docker Desktop will set up Kubernetes for you quickly and easily. Follow the set
7. Finally, tear down your test pod:
```shell
kubectl delete -f pod.yaml
```console
$ kubectl delete -f pod.yaml
```
{% endcapture %}
@ -121,14 +121,14 @@ Docker Desktop will set up Kubernetes for you quickly and easily. Follow the set
4. In PowerShell, navigate to where you created `pod.yaml` and create your pod:
```shell
kubectl apply -f pod.yaml
```console
$ kubectl apply -f pod.yaml
```
5. Check that your pod is up and running:
```shell
kubectl get pods
```console
$ kubectl get pods
```
You should see something like:
@ -140,8 +140,8 @@ Docker Desktop will set up Kubernetes for you quickly and easily. Follow the set
6. Check that you get the logs you'd expect for a ping process:
```shell
kubectl logs demo
```console
$ kubectl logs demo
```
You should see the output of a healthy ping process:
@ -156,8 +156,8 @@ Docker Desktop will set up Kubernetes for you quickly and easily. Follow the set
7. Finally, tear down your test pod:
```shell
kubectl delete -f pod.yaml
```console
$ kubectl delete -f pod.yaml
```
{% endcapture %}
@ -182,8 +182,8 @@ Docker Desktop runs primarily on Docker Engine, which has everything you need to
1. Open a terminal, and initialize Docker Swarm mode:
```shell
docker swarm init
```console
$ docker swarm init
```
If all goes well, you should see a message similar to the following:
@ -200,14 +200,14 @@ Docker Desktop runs primarily on Docker Engine, which has everything you need to
2. Run a simple Docker service that uses an alpine-based filesystem, and isolates a ping to 8.8.8.8:
```shell
docker service create --name demo alpine:3.5 ping 8.8.8.8
```console
$ docker service create --name demo alpine:3.5 ping 8.8.8.8
```
3. Check that your service created one running container:
```shell
docker service ps demo
```console
$ docker service ps demo
```
You should see something like:
@ -219,8 +219,8 @@ Docker Desktop runs primarily on Docker Engine, which has everything you need to
4. Check that you get the logs you'd expect for a ping process:
```shell
docker service logs demo
```console
$ docker service logs demo
```
You should see the output of a healthy ping process:
@ -235,8 +235,8 @@ Docker Desktop runs primarily on Docker Engine, which has everything you need to
5. Finally, tear down your test service:
```shell
docker service rm demo
```console
$ docker service rm demo
```
{% endcapture %}
@ -250,8 +250,8 @@ Docker Desktop runs primarily on Docker Engine, which has everything you need to
1. Open a powershell, and initialize Docker Swarm mode:
```shell
docker swarm init
```console
$ docker swarm init
```
If all goes well, you should see a message similar to the following:
@ -268,14 +268,14 @@ Docker Desktop runs primarily on Docker Engine, which has everything you need to
2. Run a simple Docker service that uses an alpine-based filesystem, and isolates a ping to 8.8.8.8:
```shell
docker service create --name demo alpine:3.5 ping 8.8.8.8
```console
$ docker service create --name demo alpine:3.5 ping 8.8.8.8
```
3. Check that your service created one running container:
```shell
docker service ps demo
```console
$ docker service ps demo
```
You should see something like:
@ -287,8 +287,8 @@ Docker Desktop runs primarily on Docker Engine, which has everything you need to
4. Check that you get the logs you'd expect for a ping process:
```shell
docker service logs demo
```console
$ docker service logs demo
```
You should see the output of a healthy ping process:
@ -303,8 +303,8 @@ Docker Desktop runs primarily on Docker Engine, which has everything you need to
5. Finally, tear down your test service:
```shell
docker service rm demo
```console
$ docker service rm demo
```
{% endcapture %}

2
get-started/overview.md
View File

@ -152,7 +152,7 @@ its state that are not stored in persistent storage disappear.
The following command runs an `ubuntu` container, attaches interactively to your
local command-line session, and runs `/bin/bash`.
```bash
```console
$ docker run -i -t ubuntu /bin/bash
```

12
get-started/swarm-deploy.md
View File

@ -44,8 +44,8 @@ In this Swarm YAML file, we have just one object: a `service`, describing a scal
1. Deploy your application to Swarm:
```shell
docker stack deploy -c bb-stack.yaml demo
```console
$ docker stack deploy -c bb-stack.yaml demo
```
If all goes well, Swarm will report creating all your stack objects with no complaints:
@ -59,8 +59,8 @@ In this Swarm YAML file, we have just one object: a `service`, describing a scal
2. Make sure everything worked by listing your service:
```shell
docker service ls
```console
$ docker service ls
```
If all has gone well, your service will report with 1/1 of its replicas created:
@ -76,8 +76,8 @@ In this Swarm YAML file, we have just one object: a `service`, describing a scal
4. Once satisfied, tear down your application:
```shell
docker stack rm demo
```console
$ docker stack rm demo
```
## Conclusion

22
language/golang/build-images.md
View File

@ -37,7 +37,7 @@ The source code for the application is in the [olliefr/docker-gs-ping](https://g
For our present study, we clone it to our local machine:
```shell
```console
$ git clone https://github.com/olliefr/docker-gs-ping
```
@ -84,7 +84,7 @@ func main() {
Let’s start our application and make sure it’s running properly. Open your terminal and navigate to the directory into which you cloned the project's repo. From now on, we'll refer to this directory as the **working directory**.
```shell
```console
$ go run main.go
```
@ -104,7 +104,7 @@ ____________________________________O/_______
Let's run a quick _smoke test_ on the application. **In a new terminal**, run a request using `curl`. Alternatively, you can use your favourite web browser as well.
```shell
```console
$ curl http://localhost:8080/
Hello, Docker! <3
```
@ -234,7 +234,7 @@ The build command optionally takes a `--tag` flag. This flag is used to label th
Let's build our first Docker image!
```shell
```console
$ docker build --tag docker-gs-ping .
```
@ -271,7 +271,7 @@ To see the list of images we have on our local machine, we have two options. One
To list images, simply run the `images` command:
```shell
```console
$ docker images
```
@ -291,7 +291,7 @@ An image is made up of a manifest and a list of layers. In simple terms, a “ta
To create a new tag for our image, run the following command.
```shell
```console
$ docker tag docker-gs-ping:latest docker-gs-ping:v1.0
```
@ -299,7 +299,7 @@ The Docker `tag` command creates a new tag for the image. It does not create a n
Now run the `docker images` command to see the updated list of local images:
```shell
```console
$ docker images
```
@ -314,14 +314,14 @@ You can see that we have two images that start with `docker-gs-ping`. We know th
Let’s remove the tag that we had just created. To do this, we’ll use the `rmi` command, which stands for "remove image":
```shell
```console
$ docker rmi docker-gs-ping:v1.0
Untagged: docker-gs-ping:v1.0
```
Notice that the response from Docker tells us that the image has not been removed but only "untagged". Verify this by running the images command:
```shell
```console
$ docker images
```
@ -379,8 +379,8 @@ ENTRYPOINT ["/docker-gs-ping"]
Since we have two dockerfiles now, we have to tell Docker that we want to build using our new Dockerfile. We also tag the new image with `multistage` but this word has no special meaning, we only do so that we could compare this new image to the one we've built previously, that is the one we tagged with `latest`:
```shell
docker build -t docker-gs-ping:multistage -f Dockerfile.multistage .
```console
$ docker build -t docker-gs-ping:multistage -f Dockerfile.multistage .
```
Comparing the sizes of `docker-gs-ping:multistage` and `docker-gs-ping:latest` we see an order-of-magnitude difference!

8
language/golang/configure-ci-cd.md
View File

@ -211,7 +211,7 @@ This workflow is similar to the CI workflow, with the following changes:
Let's save this workflow and check the _Actions_ page for the repository on GitHub. Unlike the CI workflow, this new workflow cannot be triggered manually - this is how we set it up. So, in order to test it, we have to tag some commit. Let's tag the `HEAD` of the `main` branch:
```shell
```console
$ git tag -a 0.0.1 -m "Test release workflow"
$ git push --tags
@ -235,7 +235,7 @@ That's easy to fix. We follow our own guide and add the secrets to the repositor
To remove the tag on the `remote`:
```shell
```console
$ git push origin :refs/tags/0.0.1
To https://github.com/olliefr/docker-gs-ping.git
- [deleted] 0.0.1
@ -243,7 +243,7 @@ To https://github.com/olliefr/docker-gs-ping.git
And to re-apply it locally and push:
```shell
```console
$ git tag -fa 0.0.1 -m "Test release workflow"
Updated tag '0.0.1' (was d7d3edc)
$ git push origin --tags
@ -261,7 +261,7 @@ And the workflow is triggered again. This time it completes without issues:
Since the image we've just pushed to Docker Hub is public, now it can be pulled by anyone, from anywhere:
```shell
```console
$ docker pull olliefr/docker-gs-ping
Using default tag: latest
latest: Pulling from olliefr/docker-gs-ping

60
language/golang/develop.md
View File

@ -32,14 +32,14 @@ The point of a database is to have a persistent store of data. [Volumes](../../s
To create a managed volume, run :
```shell
```console
$ docker volume create roach
roach
```
We can view the list of all managed volumes in our Docker instance with the following command:
```shell
```console
$ docker volume list
DRIVER VOLUME NAME
local roach
@ -51,14 +51,14 @@ The example application and the database engine are going to talk to one another
The following command creates a new bridge network named `mynet`:
```shell
```console
$ docker network create -d bridge mynet
51344edd6430b5acd121822cacc99f8bc39be63dd125a3b3cd517b6485ab7709
```
As it was the case with the managed volumes, there is a command to list all networks set up in your Docker instance:
```shell
```console
$ docker network list
NETWORK ID NAME DRIVER SCOPE
0ac2b1819fa4 bridge bridge local
@ -79,7 +79,7 @@ When choosing a name for a network or a managed volume, it's best to choose a na
Now that the housekeeping chores are done, we can run CockroachDB in a container and attach it to the volume and network we had just created. When you run the folllowing command, Docker will pull the image from Docker Hub and run it for you locally:
```shell
```console
$ docker run -d \
--name roach \
--hostname db \
@ -105,7 +105,7 @@ Now that the database engine is live, there is some configuration to do before o
We can do that with the help of CockroachDB built-in SQL shell. To start the SQL shell in the _same_ container where the database engine is running, type:
```shell
```console
$ docker exec -it roach ./cockroach sql --insecure
```
@ -175,7 +175,7 @@ The example application for this module is an extended version of `docker-gs-pin
To checkout the example application, run:
```shell
```console
$ git clone https://github.com/olliefr/docker-gs-ping-roach.git
# ... output omitted ...
```
@ -347,7 +347,7 @@ Regardless of whether we had updated the old example application, or checked out
We can build the image with the familiar `build` command:
```shell
```console
$ docker build --tag docker-gs-ping-roach .
```
@ -361,7 +361,7 @@ Now, let’s run our container. This time we’ll need to set some environment v
>
> **Don't run in insecure mode in production, though!**
```shell
```console
$ docker run -it --rm -d \
--network mynet \
--name rest-server \
@ -378,14 +378,14 @@ There are a few points to note about this command.
* We map container port `8080` to host port `80` this time. Thus, for `GET` requests we can get away with _literally_ `curl localhost`:
```shell
```console
$ curl localhost
Hello, Docker! (0)
```
Or, if you prefer, a proper URL would work just as well:
```shell
```console
$ curl http://localhost/
Hello, Docker! (0)
```
@ -396,7 +396,7 @@ There are a few points to note about this command.
* The actual password does not matter, but it must be set to something to avoid confusing the example application.
* The container we've just run is named `rest-server`. These names are useful for managing the container lifecycle:
```shell
```console
# Don't do this just yet, it's only an example:
$ docker container rm --force rest-server
```
@ -405,7 +405,7 @@ There are a few points to note about this command.
In the previous section, we have already tested querying our application with `GET` and it returned zero for the stored message counter. Now, let's post some messages to it:
```shell
```console
$ curl --request POST \
--url http://localhost/send \
--header 'content-type: application/json' \
@ -420,7 +420,7 @@ The application responds with the contents of the message, which means it had be
Let's send another message:
```shell
```console
$ curl --request POST \
--url http://localhost/send \
--header 'content-type: application/json' \
@ -429,13 +429,13 @@ $ curl --request POST \
And again, we get the value of the message back:
```shell
```json
{"value":"Hello, Oliver!"}
```
Let's see what the message counter says:
```shell
```console
$ curl localhost
Hello, Docker! (2)
```
@ -444,7 +444,7 @@ Hey, that's exactly right! We sent two messages and the database kept them. Or h
First, let's stop the containers:
```shell
```console
$ docker container stop rest-server roach
rest-server
roach
@ -452,7 +452,7 @@ roach
Then, let's remove them:
```shell
```console
$ docker container rm rest-server roach
rest-server
roach
@ -460,15 +460,15 @@ roach
Verify that they are gone:
```shell
```console
$ docker container list --all
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
```
And start them again, database first:
```shell
docker run -d \
```console
$ docker run -d \
--name roach \
--hostname db \
--network mynet \
@ -481,8 +481,8 @@ docker run -d \
And the service next:
```shell
docker run -it --rm -d \
```console
$ docker run -it --rm -d \
--network mynet \
--name rest-server \
-p 80:8080 \
@ -496,7 +496,7 @@ docker run -it --rm -d \
Lastly, let's query our service:
```shell
```console
$ curl localhost
Hello, Docker! (2)
```
@ -509,7 +509,7 @@ Such is the power of managed volumes. Use it wisely.
Remember, that we are running CockroachDB in "insecure" mode. Now that we had built and tested our application, it's time to wind everything down before moving on. You can list the containers that you are running with the `list` command:
```shell
```console
$ docker container list
```
@ -610,7 +610,7 @@ Other ways of dealing with undefined or empty values exist, as documented in the
Before you apply changes made to a Compose configuration file, there is an opportunity to validate the content of the configuration file with the following command:
```shell
```console
$ docker-compose config
```
@ -620,7 +620,7 @@ When this command is run, Docker Compose would read the file `docker-compose.yml
Let’s start our application and confirm that it is running properly.
```shell
```console
$ docker-compose up --build
```
@ -669,7 +669,7 @@ This is not a big deal. All we have to do is to connect to CockroachDB instance
So we login into the database engine from another terminal:
```shell
```console
$ docker exec -it roach ./cockroach sql --insecure
```
@ -681,7 +681,7 @@ It would have been possible to connect the volume that we had previously used, b
Now let’s test our API endpoint. In the new terminal, run the following command:
```shell
```console
$ curl http://localhost/
```
@ -701,7 +701,7 @@ You can run containers started by the `docker-compose` command in detached mode,
To start the stack, defined by the Compose file in detached mode, run:
```shell
```console
$ docker-compose up --build -d
```

32
language/golang/run-containers.md
View File

@ -20,7 +20,7 @@ A container is a normal operating system process except that this process is iso
To run an image inside of a container, we use the `docker run` command. It requires one parameter and that is the image name. Let’s start our image and make sure it is running correctly. Execute the following command in your terminal.
```shell
```console
$ docker run docker-gs-ping
```
@ -40,7 +40,7 @@ When you run this command, you’ll notice that you were not returned to the com
Let’s make a GET request to the server using the curl command.
```shell
```console
$ curl http://localhost:8080/
curl: (7) Failed to connect to localhost port 8080: Connection refused
```
@ -53,13 +53,13 @@ To publish a port for our container, we’ll use the `--publish` flag (`-p` for
Start the container and expose port `8080` to port `8080` on the host.
```shell
```console
$ docker run --publish 8080:8080 docker-gs-ping
```
Now let’s rerun the curl command from above.
```shell
```console
$ curl http://localhost:8080/
Hello, Docker! <3
```
@ -72,7 +72,7 @@ Press **ctrl-c** to stop the container.
This is great so far, but our sample application is a web server and we should not have to have our terminal connected to the container. Docker can run your container in detached mode, that is in the background. To do this, we can use the `--detach` or `-d` for short. Docker will start your container the same as before but this time will “detach” from the container and return you to the terminal prompt.
```shell
```console
$ docker run -d -p 8080:8080 docker-gs-ping
d75e61fcad1e0c0eca69a3f767be6ba28a66625ce4dc42201a8a323e8313c14e
```
@ -81,7 +81,7 @@ Docker started our container in the background and printed the container ID on t
Again, let’s make sure that our container is running properly. Run the same `curl` command:
```shell
```console
$ curl http://localhost:8080/
Hello, Docker! <3
```
@ -90,7 +90,7 @@ Hello, Docker! <3
Since we ran our container in the background, how do we know if our container is running or what other containers are running on our machine? Well, we can run the `docker ps` command. Just like on Linux, to see a list of processes on your machine we would run the `ps` command. In the same spirit, we can run the `docker ps` command which will show us a list of containers running on our machine.
```shell
```console
$ docker ps
```
@ -103,14 +103,14 @@ The `ps` command tells a bunch of stuff about our running containers. We can see
You are probably wondering where the name of our container is coming from. Since we didn’t provide a name for the container when we started it, Docker generated a random name. We’ll fix this in a minute but first we need to stop the container. To stop the container, run the `docker stop` command which does just that, stops the container. You will need to pass the name of the container or you can use the container ID.
```shell
```console
$ docker stop inspiring_ishizaka
inspiring_ishizaka
```
Now rerun the `docker ps` command to see a list of running containers.
```shell
```console
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
```
@ -119,7 +119,7 @@ CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Docker containers can be started, stopped and restarted. When we stop a container, it is not removed but the status is changed to stopped and the process inside of the container is stopped. When we ran the `docker ps` command, the default output is to only show running containers. If we pass the `--all` or `-a` for short, we will see all containers on our system, that is stopped containers and running containers.
```shell
```console
$ docker ps -a
```
@ -135,13 +135,13 @@ If you’ve been following along, you should see several containers listed. Thes
Let’s restart the container that we have just stopped. Locate the name of the container and replace the name of the container below in the restart command:
```shell
```console
$ docker restart inspiring_ishizaka
```
Now, list all the containers again using the `ps` command:
```shell
```console
$ docker ps --all
```
@ -159,7 +159,7 @@ Let’s stop and remove all of our containers and take a look at fixing the rand
Stop the container we just started. Find the name of your running container and replace the name in the command below with the name of the container on your system:
```shell
```console
$ docker stop inspiring_ishizaka
inspiring_ishizaka
```
@ -170,7 +170,7 @@ To remove a container, run the `docker rm` command passing the container name. Y
Again, make sure you replace the containers names in the below command with the container names from your system:
```shell
```console
$ docker rm inspiring_ishizaka wizardly_joliot magical_carson gifted_mestorf
```
@ -187,12 +187,12 @@ Now let’s address the pesky random name issue. Standard practice is to name yo
To name a container, we must pass the `--name` flag to the `run` command:
```shell
```console
$ docker run -d -p 8080:8080 --name rest-server docker-gs-ping
3bbc6a3102ea368c8b966e1878a5ea9b1fc61187afaac1276c41db22e4b7f48f
```
```shell
```console
$ docker ps
```

15
language/golang/run-tests.md
View File

@ -63,11 +63,8 @@ The second test in `main_test.go` has almost identical structure but it tests _a
In order to run the tests, we must make sure that our application Docker image is up-to-date.
```shell
docker build -t docker-gs-ping:latest .
```
```
```console
$ docker build -t docker-gs-ping:latest .
[+] Building 3.0s (13/13) FINISHED
...
```
@ -78,15 +75,15 @@ Note, that the image is tagged with `latest` which is the same label we've chose
Now that the Docker image for our application had been built, we can run the tests that depend on it:
```shell
go test ./...
```console
$ go test ./...
ok github.com/olliefr/docker-gs-ping 2.564s
```
That was a bit... underwhelming? Let's ask it to print a bit more detail, just to be sure:
```shell
go test -v ./...
```console
$ go test -v ./...
```
```

6
language/java/configure-ci-cd.md
View File

@ -188,9 +188,9 @@ on:
This ensures that the main CI will only trigger if we tag our commits with `V.n.n.n.` Let’s test this. For example, run the following command:
```bash
git tag -a v1.0.2
git push origin v1.0.2
```console
$ git tag -a v1.0.2
$ git push origin v1.0.2
```
Now, go to GitHub and check your Actions

12
language/java/run-tests.md
View File

@ -18,7 +18,7 @@ Testing is an essential part of modern software development. Testing can mean a
The **Spring Pet Clinic** source code has already tests defined in the test directory `src/test/java/org/springframework/samples/petclinic`. You just need to update the JaCoCo version in your `pom.xml` to ensure your tests work with JDK v15 or higher with `<jacoco.version>0.8.6</jacoco.version>`, so we can use the following Docker command to start the container and run tests:
```shell
```console
$ docker run -it --rm --name springboot-test java-docker ./mvnw test
...
[INFO] Results:
@ -68,7 +68,7 @@ We first add a label to the `FROM openjdk:16-alpine3.13` statement. This allows
Now let’s rebuild our image and run our tests. We will run the `docker build` command as above, but this time we will add the `--target test` flag so that we specifically run the test build stage.
```shell
```console
$ docker build -t java-docker --target test .
[+] Building 0.7s (6/6) FINISHED
...
@ -78,7 +78,7 @@ $ docker build -t java-docker --target test .
Now that our test image is built, we can run it as a container and see if our tests pass.
```shell
```console
$ docker run -it --rm --name springboot-test java-docker
[INFO] Scanning for projects...
[INFO]
@ -133,7 +133,7 @@ CMD ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/spring-petclin
Now, to run our tests, we just need to run the `docker build` command as above.
```shell
```console
$ docker build -t java-docker --target test .
[+] Building 27.6s (11/12)
=> CACHED [base 3/6] COPY .mvn/ .mvn
@ -160,7 +160,7 @@ Open the `src/test/java/org/springframework/samples/petclinic/model/ValidatorTes
Now, run the `docker build` command from above and observe that the build fails and the failing testing information is printed to the console.
```shell
```console
$ docker build -t java-docker --target test .
=> [base 6/6] COPY src ./src
=> ERROR [test 1/1] RUN ["./mvnw", "test"]
@ -198,7 +198,7 @@ services:
Now, let's run the Compose application. You should now see that application behaves as previously and you can still debug it.
```shell
```console
$ docker-compose -f docker-compose.dev.yml up --build
```

18
language/nodejs/build-images.md
View File

@ -28,7 +28,7 @@ To complete this tutorial, you need the following:
Let’s create a simple Node.js application that we can use as our example. Create a directory in your local machine named `node-docker` and follow the steps below to create a simple REST API.
```shell
```console
$ cd [path to your node-docker directory]
$ npm init -y
$ npm install ronin-server ronin-mocks
@ -55,13 +55,13 @@ The mocking server is called `Ronin.js` and will listen on port 8000 by default.
Let’s start our application and make sure it’s running properly. Open your terminal and navigate to your working directory you created.
```shell
```console
$ node server.js
```
To test that the application is working properly, we’ll first POST some JSON to the API and then make a GET request to see that the data has been saved. Open a new terminal and run the following curl commands:
```shell
```console
$ curl --request POST \
--url http://localhost:8000/test \
--header 'content-type: application/json' \
@ -199,11 +199,9 @@ The build command optionally takes a `--tag` flag. The tag is used to set the na
Let’s build our first Docker image.
```shell
```console
$ docker build --tag node-docker .
```
```shell
[+] Building 93.8s (11/11) FINISHED
=> [internal] load build definition from dockerfile 0.1s
=> => transferring dockerfile: 617B 0.0s
@ -221,7 +219,7 @@ To see a list of images we have on our local machine, we have two options. One i
To list images, simply run the `images` command.
```shell
```console
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
node-docker latest 3809733582bc About a minute ago 945MB
@ -237,7 +235,7 @@ An image is made up of a manifest and a list of layers. In simple terms, a “ta
To create a new tag for the image we built above, run the following command.
```shell
```console
$ docker tag node-docker:latest node-docker:v1.0.0
```
@ -256,14 +254,14 @@ You can see that we have two images that start with `node-docker`. We know they
Let’s remove the tag that we just created. To do this, we’ll use the rmi command. The rmi command stands for “remove image”.
```shell
```console
$ docker rmi node-docker:v1.0.0
Untagged: node-docker:v1.0.0
```
Notice that the response from Docker tells us that the image has not been removed but only “untagged”. Verify this by running the images command.
```shell
```console
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
node-docker latest 3809733582bc 32 minutes ago 945MB

6
language/nodejs/configure-ci-cd.md
View File

@ -187,9 +187,9 @@ on:
This ensures that the main CI will only trigger if we tag our commits with `V.n.n.n.` Let’s test this. For example, run the following command:
```bash
git tag -a v1.0.2
git push origin v1.0.2
```console
$ git tag -a v1.0.2
$ git push origin v1.0.2
```
Now, go to GitHub and check your Actions

20
language/nodejs/develop.md
View File

@ -26,20 +26,20 @@ Before we run MongoDB in a container, we want to create a couple of volumes that
Let’s create our volumes now. We’ll create one for the data and one for configuration of MongoDB.
```shell
```console
$ docker volume create mongodb
$ docker volume create mongodb_config
```
Now we’ll create a network that our application and database will use to talk with each other. The network is called a user-defined bridge network and gives us a nice DNS lookup service which we can use when creating our connection string.
```shell
```console
$ docker network create mongodb
```
Now we can run MongoDB in a container and attach to the volumes and network we created above. Docker will pull the image from Hub and run it for you locally.
```shell
```console
$ docker run -it --rm -d -v mongodb:/data/db \
-v mongodb_config:/data/configdb -p 27017:27017 \
--network mongodb \
@ -64,19 +64,19 @@ We’ve add the `ronin-database` module and we updated the code to connect to th
First let’s add the `ronin-database` module to our application using npm.
```shell
```console
$ npm install ronin-database
```
Now we can build our image.
```shell
```console
$ docker build --tag node-docker .
```
Now, let’s run our container. But this time we’ll need to set the `CONNECTIONSTRING` environment variable so our application knows what connection string to use to access the database. We’ll do this right in the `docker run` command.
```shell
```console
$ docker run \
-it --rm -d \
--network mongodb \
@ -88,7 +88,7 @@ $ docker run \
Let’s test that our application is connected to the database and is able to add a note.
```shell
```console
$ curl --request POST \
--url http://localhost:8000/notes \
--header 'content-type: application/json' \
@ -162,7 +162,7 @@ $ npm install nodemon
Let’s start our application and confirm that it is running properly.
```shell
```console
$ docker-compose -f docker-compose.dev.yml up --build
```
@ -174,7 +174,7 @@ If all goes will you should see something similar:
Now let’s test our API endpoint. Run the following curl command:
```shell
```console
$ curl --request GET --url http://localhost:8000/notes
```
@ -212,7 +212,7 @@ If you take a look at the terminal where our Compose application is running, you
Navigate back to the Chrome DevTools and set a breakpoint on the line containing the `return res.json({ "foo": "bar" })` statement, and then run the following curl command to trigger the breakpoint.
```shell
```console
$ curl --request GET --url http://localhost:8000/foo
```

Some files were not shown because too many files have changed in this diff Show More