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

Merge pull request #11620 from thaJeztah/old_engines 

Remove references to obsolete engine versions
This commit is contained in:
Usha Mandya 2020-10-26 14:49:51 +00:00 committed by GitHub
parent 9318adf078 2ce808edc0
commit cb4a1293a7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
42 changed files with 252 additions and 333 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/ISSUE_TEMPLATE.md vendored
View File

@ -17,7 +17,7 @@
### Project version(s) affected ### Project version(s) affected
<!-- If this problem only affects specific versions of a project (like Docker <!-- If this problem only affects specific versions of a project (like Docker
Engine 1.13), tell us here. The fix may need to take that into account. --> Engine 19.03), tell us here. The fix may need to take that into account. -->
### Suggestions for a fix ### Suggestions for a fix

6
_includes/content/compose-extfields-sub.md
View File

@ -9,7 +9,7 @@ your Compose file and their name start with the `x-` character sequence.
> of service, volume, network, config and secret definitions. > of service, volume, network, config and secret definitions.
```yaml ```yaml
version: '3.4' version: "{{ site.compose_file_v3 }}"
x-custom: x-custom:
items: items:
- a - a
@ -35,7 +35,7 @@ logging:
You may write your Compose file as follows: You may write your Compose file as follows:
```yaml ```yaml
version: '3.4' version: "{{ site.compose_file_v3 }}"
x-logging: x-logging:
&default-logging &default-logging
options: options:
@ -56,7 +56,7 @@ It is also possible to partially override values in extension fields using
the [YAML merge type](https://yaml.org/type/merge.html). For example: the [YAML merge type](https://yaml.org/type/merge.html). For example:
```yaml ```yaml
version: '3.4' version: "{{ site.compose_file_v3 }}"
x-volumes: x-volumes:
&default-volume &default-volume
driver: foobar-storage driver: foobar-storage

2
_includes/kubernetes-mac-win.md
View File

@ -141,7 +141,7 @@ Docker has created the following demo app that you can deploy to swarm mode or
to Kubernetes using the `docker stack deploy` command. to Kubernetes using the `docker stack deploy` command.
```yaml ```yaml
version: '3.3' version: "{{ site.compose_file_v3 }}"
services: services:
web: web:

2
compose/aspnet-mssql-compose.md
View File

@ -95,7 +95,7 @@ configure this app to use our SQL Server database, and then create a
> base 10 digits and/or non-alphanumeric symbols. > base 10 digits and/or non-alphanumeric symbols.
```yaml ```yaml
version: "3" version: "{{ site.compose_file_v3 }}"
services: services:
web: web:
build: . build: .

26
compose/networking.md
View File

@ -12,23 +12,27 @@ container for a service joins the default network and is both *reachable* by
other containers on that network, and *discoverable* by them at a hostname other containers on that network, and *discoverable* by them at a hostname
identical to the container name. identical to the container name.
> **Note**: Your app's network is given a name based on the "project name", > **Note**
>
> Your app's network is given a name based on the "project name",
> which is based on the name of the directory it lives in. You can override the > which is based on the name of the directory it lives in. You can override the
> project name with either the [`--project-name` flag](reference/overview.md) > project name with either the [`--project-name` flag](reference/overview.md)
> or the [`COMPOSE_PROJECT_NAME` environment variable](reference/envvars.md#compose_project_name). > or the [`COMPOSE_PROJECT_NAME` environment variable](reference/envvars.md#compose_project_name).
For example, suppose your app is in a directory called `myapp`, and your `docker-compose.yml` looks like this: For example, suppose your app is in a directory called `myapp`, and your `docker-compose.yml` looks like this:
version: "3" ```yaml
services: version: "{{ site.compose_file_v3 }}"
web: services:
build: . web:
ports: build: .
- "8000:8000" ports:
db: - "8000:8000"
image: postgres db:
ports: image: postgres
- "8001:5432" ports:
- "8001:5432"
```
When you run `docker-compose up`, the following happens: When you run `docker-compose up`, the following happens:

40
compose/rails.md
View File

@ -68,25 +68,29 @@ one's Docker image (the database just runs on a pre-made PostgreSQL image, and
the web app is built from the current directory), and the configuration needed the web app is built from the current directory), and the configuration needed
to link them together and expose the web app's port. to link them together and expose the web app's port.
version: '3' ```yaml
services: version: "{{ site.compose_file_v3 }}"
db: services:
image: postgres db:
volumes: image: postgres
- ./tmp/db:/var/lib/postgresql/data volumes:
environment: - ./tmp/db:/var/lib/postgresql/data
POSTGRES_PASSWORD: password environment:
web: POSTGRES_PASSWORD: password
build: . web:
command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" build: .
volumes: command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
- .:/myapp volumes:
ports: - .:/myapp
- "3000:3000" ports:
depends_on: - "3000:3000"
- db depends_on:
- db
```
>**Tip**: You can use either a `.yml` or `.yaml` extension for this file. > **Tip**
>
> You can use either a `.yml` or `.yaml` extension for this file.
### Build the project ### Build the project

8
config/containers/live-restore.md
View File

@ -7,10 +7,10 @@ redirect_from:
--- ---
By default, when the Docker daemon terminates, it shuts down running containers. By default, when the Docker daemon terminates, it shuts down running containers.
Starting with Docker Engine 1.12, you can configure the daemon so that You can configure the daemon so that containers remain running if the daemon
containers remain running if the daemon becomes unavailable. This functionality becomes unavailable. This functionality is called _live restore_. The live restore
is called _live restore_. The live restore option helps reduce container option helps reduce container downtime due to daemon crashes, planned outages,
downtime due to daemon crashes, planned outages, or upgrades. or upgrades.
> **Note** > **Note**
> >

20
config/containers/resource_constraints.md
View File

@ -167,9 +167,8 @@ by viewing `/proc/<PID>/status` on the host machine.
By default, each container's access to the host machine's CPU cycles is unlimited. By default, each container's access to the host machine's CPU cycles is unlimited.
You can set various constraints to limit a given container's access to the host You can set various constraints to limit a given container's access to the host
machine's CPU cycles. Most users use and configure the machine's CPU cycles. Most users use and configure the
[default CFS scheduler](#configure-the-default-cfs-scheduler). In Docker 1.13 [default CFS scheduler](#configure-the-default-cfs-scheduler). You can also
and higher, you can also configure the configure the [realtime scheduler](#configure-the-realtime-scheduler).
[realtime scheduler](#configure-the-realtime-scheduler).
### Configure the default CFS scheduler ### Configure the default CFS scheduler
@ -180,22 +179,19 @@ the container's cgroup on the host machine.
| Option | Description | | Option | Description |
|:-----------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |:-----------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `--cpus=<value>` | Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set `--cpus="1.5"`, the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting `--cpu-period="100000"` and `--cpu-quota="150000"`. Available in Docker 1.13 and higher. | | `--cpus=<value>` | Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set `--cpus="1.5"`, the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting `--cpu-period="100000"` and `--cpu-quota="150000"`. |
| `--cpu-period=<value>` | Specify the CPU CFS scheduler period, which is used alongside `--cpu-quota`. Defaults to 100000 microseconds (100 milliseconds). Most users do not change this from the default. If you use Docker 1.13 or higher, use `--cpus` instead. | | `--cpu-period=<value>` | Specify the CPU CFS scheduler period, which is used alongside `--cpu-quota`. Defaults to 100000 microseconds (100 milliseconds). Most users do not change this from the default. For most use-cases, `--cpus` is a more convenient alternative. |
| `--cpu-quota=<value>` | Impose a CPU CFS quota on the container. The number of microseconds per `--cpu-period` that the container is limited to before throttled. As such acting as the effective ceiling. If you use Docker 1.13 or higher, use `--cpus` instead. | | `--cpu-quota=<value>` | Impose a CPU CFS quota on the container. The number of microseconds per `--cpu-period` that the container is limited to before throttled. As such acting as the effective ceiling. For most use-cases, `--cpus` is a more convenient alternative. |
| `--cpuset-cpus` | Limit the specific CPUs or cores a container can use. A comma-separated list or hyphen-separated range of CPUs a container can use, if you have more than one CPU. The first CPU is numbered 0. A valid value might be `0-3` (to use the first, second, third, and fourth CPU) or `1,3` (to use the second and fourth CPU). | | `--cpuset-cpus` | Limit the specific CPUs or cores a container can use. A comma-separated list or hyphen-separated range of CPUs a container can use, if you have more than one CPU. The first CPU is numbered 0. A valid value might be `0-3` (to use the first, second, third, and fourth CPU) or `1,3` (to use the second and fourth CPU). |
| `--cpu-shares` | Set this flag to a value greater or less than the default of 1024 to increase or reduce the container's weight, and give it access to a greater or lesser proportion of the host machine's CPU cycles. This is only enforced when CPU cycles are constrained. When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. `--cpu-shares` does not prevent containers from being scheduled in swarm mode. It prioritizes container CPU resources for the available CPU cycles. It does not guarantee or reserve any specific CPU access. | | `--cpu-shares` | Set this flag to a value greater or less than the default of 1024 to increase or reduce the container's weight, and give it access to a greater or lesser proportion of the host machine's CPU cycles. This is only enforced when CPU cycles are constrained. When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. `--cpu-shares` does not prevent containers from being scheduled in swarm mode. It prioritizes container CPU resources for the available CPU cycles. It does not guarantee or reserve any specific CPU access. |
If you have 1 CPU, each of the following commands guarantees the container at If you have 1 CPU, each of the following commands guarantees the container at
most 50% of the CPU every second. most 50% of the CPU every second.
**Docker 1.13 and higher**:
```bash ```bash
docker run -it --cpus=".5" ubuntu /bin/bash docker run -it --cpus=".5" ubuntu /bin/bash
``` ```
Which is the equivalent to manually specifying `--cpu-period` and `--cpu-quota`;
**Docker 1.12 and lower**:
```bash ```bash
$ docker run -it --cpu-period=100000 --cpu-quota=50000 ubuntu /bin/bash $ docker run -it --cpu-period=100000 --cpu-quota=50000 ubuntu /bin/bash
@ -203,8 +199,8 @@ $ docker run -it --cpu-period=100000 --cpu-quota=50000 ubuntu /bin/bash
### Configure the realtime scheduler ### Configure the realtime scheduler
In Docker 1.13 and higher, you can configure your container to use the You can configure your container to use the realtime scheduler, for tasks which
realtime scheduler, for tasks which cannot use the CFS scheduler. You need to cannot use the CFS scheduler. You need to
[make sure the host machine's kernel is configured correctly](#configure-the-host-machines-kernel) [make sure the host machine's kernel is configured correctly](#configure-the-host-machines-kernel)
before you can [configure the Docker daemon](#configure-the-docker-daemon) or before you can [configure the Docker daemon](#configure-the-docker-daemon) or
[configure individual containers](#configure-individual-containers). [configure individual containers](#configure-individual-containers).

8
config/pruning.md
View File

@ -144,9 +144,8 @@ for more examples.
## Prune everything ## Prune everything
The `docker system prune` command is a shortcut that prunes images, containers, The `docker system prune` command is a shortcut that prunes images, containers,
and networks. In Docker 17.06.0 and earlier, volumes are also pruned. In Docker and networks. Volumes are not pruned by default, and you must specify the
17.06.1 and higher, you must specify the `--volumes` flag for `--volumes` flag for `docker system prune` to prune volumes.
`docker system prune` to prune volumes.
```bash ```bash
$ docker system prune $ docker system prune
@ -159,8 +158,7 @@ WARNING! This will remove:
Are you sure you want to continue? [y/N] y Are you sure you want to continue? [y/N] y
``` ```
If you are on Docker 17.06.1 or higher and want to also prune volumes, add To also prune volumes, add the `--volumes` flag:
the `--volumes` flag:
```bash ```bash
$ docker system prune --volumes $ docker system prune --volumes

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

@ -6,9 +6,8 @@ redirect_from:
- /engine/userguide/eng-image/multistage-build/ - /engine/userguide/eng-image/multistage-build/
--- ---
Multi-stage builds are a new feature requiring Docker 17.05 or higher on the Multistage builds are useful to anyone who has struggled to optimize Dockerfiles
daemon and client. Multistage builds are useful to anyone who has struggled to while keeping them easy to read and maintain.
optimize Dockerfiles while keeping them easy to read and maintain.
> **Acknowledgment**: > **Acknowledgment**:
> Special thanks to [Alex Ellis](https://twitter.com/alexellisuk) for granting > Special thanks to [Alex Ellis](https://twitter.com/alexellisuk) for granting

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

@ -481,5 +481,4 @@ After you have successfully authenticated, you can access your organizations and
[Docker CLI Reference Guide](../engine/api/index.md){: target="_blank" rel="noopener" class="_"}. [Docker CLI Reference Guide](../engine/api/index.md){: target="_blank" rel="noopener" class="_"}.
* Check out the blog post, [What’s New in Docker 17.06 Community Edition * Check out the blog post, [What’s New in Docker 17.06 Community Edition
(CE)](https://blog.docker.com/2017/07/whats-new-docker-17-06-community-edition-ce/){: (CE)](https://blog.docker.com/2017/07/whats-new-docker-17-06-community-edition-ce/){: target="_blank" rel="noopener" class="_"}.
target="_blank" rel="noopener" class="_"}.

12
engine/install/index.md
View File

@ -88,10 +88,10 @@ and **nightly**:
Year-month releases are made from a release branch diverged from the master Year-month releases are made from a release branch diverged from the master
branch. The branch is created with format `<year>.<month>`, for example branch. The branch is created with format `<year>.<month>`, for example
`18.09`. The year-month name indicates the earliest possible calendar `19.03`. The year-month name indicates the earliest possible calendar
month to expect the release to be generally available. All further patch month to expect the release to be generally available. All further patch
releases are performed from that branch. For example, once `v18.09.0` is releases are performed from that branch. For example, once `v19.03.0` is
released, all subsequent patch releases are built from the `18.09` branch. released, all subsequent patch releases are built from the `19.03` branch.
### Test ### Test
@ -113,10 +113,8 @@ format:
where the time is the commit time in UTC and the final suffix is the prefix where the time is the commit time in UTC and the final suffix is the prefix
of the commit hash, for example `0.0.0-20180720214833-f61e0f7`. of the commit hash, for example `0.0.0-20180720214833-f61e0f7`.
These builds allow for testing from the latest code on the master branch. These builds allow for testing from the latest code on the master branch. No
qualifications or guarantees are made for the nightly builds.
> **Note:**
> No qualifications or guarantees are made for the nightly builds.
## Support ## Support

6
engine/security/apparmor.md
View File

@ -10,10 +10,8 @@ administrator associates an AppArmor security profile with each program. Docker
expects to find an AppArmor policy loaded and enforced. expects to find an AppArmor policy loaded and enforced.
Docker automatically generates and loads a default profile for containers named Docker automatically generates and loads a default profile for containers named
`docker-default`. On Docker versions `1.13.0` and later, the Docker binary generates `docker-default`. The Docker binary generates this profile in `tmpfs` and then
this profile in `tmpfs` and then loads it into the kernel. On Docker versions loads it into the kernel.
earlier than `1.13.0`, this profile is generated in `/etc/apparmor.d/docker`
instead.
> **Note**: This profile is used on containers, _not_ on the Docker Daemon. > **Note**: This profile is used on containers, _not_ on the Docker Daemon.

12
engine/security/certificates.md
View File

@ -23,12 +23,12 @@ A custom certificate is configured by creating a directory under
`/etc/docker/certs.d` using the same name as the registry's hostname, such as `/etc/docker/certs.d` using the same name as the registry's hostname, such as
`localhost`. All `*.crt` files are added to this directory as CA roots. `localhost`. All `*.crt` files are added to this directory as CA roots.
> **Note**: > **Note**
> As of Docker 1.13, on Linux any root certificates authorities are merged >
> with the system defaults, including as the host's root CA set. On prior > On Linux any root certificates authorities are merged with the system defaults,
versions of Docker, and on Docker Enterprise Edition for Windows Server, > including the host's root CA set. If you are running Docker on Windows Server,
> the system default certificates are only used when no custom root certificates > or Docker Desktop for Windows with Windows containers, the system default
> are configured. > certificates are only used when no custom root certificates are configured.
The presence of one or more `<filename>.key/cert` pairs indicates to Docker The presence of one or more `<filename>.key/cert` pairs indicates to Docker
that there are custom certificates required for access to the desired that there are custom certificates required for access to the desired

14
engine/security/trust/index.md
View File

@ -86,12 +86,13 @@ The following image depicts the various signing keys and their relationships:
![Content Trust components](images/trust_components.png) ![Content Trust components](images/trust_components.png)
> **WARNING**: > **WARNING**
>
> Loss of the root key is **very difficult** to recover from. > Loss of the root key is **very difficult** to recover from.
>Correcting this loss requires intervention from [Docker > Correcting this loss requires intervention from [Docker
>Support](https://support.docker.com) to reset the repository state. This loss > Support](https://support.docker.com) to reset the repository state. This loss
>also requires **manual intervention** from every consumer that used a signed > also requires **manual intervention** from every consumer that used a signed
>tag from this repository prior to the loss. > tag from this repository prior to the loss.
{:.warning} {:.warning}
You should back up the root key somewhere safe. Given that it is only required You should back up the root key somewhere safe. Given that it is only required
@ -101,9 +102,6 @@ read how to [manage keys for DCT](trust_key_mng.md).
## Signing Images with Docker Content Trust ## Signing Images with Docker Content Trust
> **Note:**
> This applies to Docker Community Engine 17.12 and newer.
Within the Docker CLI we can sign and push a container image with the Within the Docker CLI we can sign and push a container image with the
`$ docker trust` command syntax. This is built on top of the Notary feature `$ docker trust` command syntax. This is built on top of the Notary feature
set, more information on Notary can be found [here](/notary/getting_started/). set, more information on Notary can be found [here](/notary/getting_started/).

14
engine/swarm/admin_guide.md
View File

@ -239,9 +239,8 @@ you demote or remove a manager.
## Back up the swarm ## Back up the swarm
Docker manager nodes store the swarm state and manager logs in the Docker manager nodes store the swarm state and manager logs in the
`/var/lib/docker/swarm/` directory. In 1.13 and higher, this data includes the `/var/lib/docker/swarm/` directory. This data includes the keys used to encrypt
keys used to encrypt the Raft logs. Without these keys, you cannot restore the the Raft logs. Without these keys, you cannot restore the swarm.
swarm.
You can back up the swarm using any manager. Use the following procedure. You can back up the swarm using any manager. Use the following procedure.
@ -377,11 +376,10 @@ balance across the swarm. When new tasks start, or when a node with running
tasks becomes unavailable, those tasks are given to less busy nodes. The goal tasks becomes unavailable, those tasks are given to less busy nodes. The goal
is eventual balance, with minimal disruption to the end user. is eventual balance, with minimal disruption to the end user.
In Docker 1.13 and higher, you can use the `--force` or `-f` flag with the You can use the `--force` or `-f` flag with the `docker service update` command
`docker service update` command to force the service to redistribute its tasks to force the service to redistribute its tasks across the available worker nodes.
across the available worker nodes. This causes the service tasks to restart. This causes the service tasks to restart. Client applications may be disrupted.
Client applications may be disrupted. If you have configured it, your service If you have configured it, your service uses a [rolling update](swarm-tutorial/rolling-update.md).
uses a [rolling update](swarm-tutorial/rolling-update.md).
If you use an earlier version and you want to achieve an even balance of load If you use an earlier version and you want to achieve an even balance of load
across workers and don't mind disrupting running tasks, you can force your swarm across workers and don't mind disrupting running tasks, you can force your swarm

25
engine/swarm/configs.md
View File

@ -6,11 +6,10 @@ keywords: swarm, configuration, configs
## About configs ## About configs
Docker 17.06 introduces swarm service configs, which allow you to store Docker swarm service configs allow you to store non-sensitive information,
non-sensitive information, such as configuration files, outside a service's such as configuration files, outside a service's image or running containers.
image or running containers. This allows you to keep your images as generic This allows you to keep your images as generic as possible, without the need to
as possible, without the need to bind-mount configuration files into the bind-mount configuration files into the containers or use environment variables.
containers or use environment variables.
Configs operate in a similar way to [secrets](secrets.md), except that they are Configs operate in a similar way to [secrets](secrets.md), except that they are
not encrypted at rest and are mounted directly into the container's filesystem not encrypted at rest and are mounted directly into the container's filesystem
@ -27,9 +26,9 @@ Configs are supported on both Linux and Windows services.
### Windows support ### Windows support
Docker 17.06 and higher include support for configs on Windows containers. Docker includes support for configs on Windows containers, but there are differences
Where there are differences in the implementations, they are called out in the in the implementations, which are called out in the examples below. Keep the
examples below. Keep the following notable differences in mind: following notable differences in mind:
- Config files with custom targets are not directly bind-mounted into Windows - Config files with custom targets are not directly bind-mounted into Windows
containers, since Windows does not support non-directory file bind-mounts. containers, since Windows does not support non-directory file bind-mounts.
@ -230,15 +229,15 @@ real-world example, continue to
### Simple example: Use configs in a Windows service ### Simple example: Use configs in a Windows service
This is a very simple example which shows how to use configs with a Microsoft This is a very simple example which shows how to use configs with a Microsoft
IIS service running on Docker 17.06 EE on Microsoft Windows Server 2016 or Docker IIS service running on Docker for Windows running Windows containers on
for Windows 17.06 CE on Microsoft Windows 10. It stores the webpage in a config. Microsoft Windows 10. It is a naive example that stores the webpage in a config.
This example assumes that you have PowerShell installed. This example assumes that you have PowerShell installed.
1. Save the following into a new file `index.html`. 1. Save the following into a new file `index.html`.
```html ```html
<html> <html lang="en">
<head><title>Hello Docker</title></head> <head><title>Hello Docker</title></head>
<body> <body>
<p>Hello Docker! You have deployed a HTML page.</p> <p>Hello Docker! You have deployed a HTML page.</p>
@ -287,7 +286,7 @@ name as its argument. The template will be rendered when container is created.
1. Save the following into a new file `index.html.tmpl`. 1. Save the following into a new file `index.html.tmpl`.
```html ```html
<html> <html lang="en">
<head><title>Hello Docker</title></head> <head><title>Hello Docker</title></head>
<body> <body>
<p>Hello {% raw %}{{ env "HELLO" }}{% endraw %}! I'm service {% raw %}{{ .Service.Name }}{% endraw %}.</p> <p>Hello {% raw %}{{ env "HELLO" }}{% endraw %}! I'm service {% raw %}{{ .Service.Name }}{% endraw %}.</p>
@ -320,7 +319,7 @@ name as its argument. The template will be rendered when container is created.
```bash ```bash
$ curl http://0.0.0.0:3000 $ curl http://0.0.0.0:3000
<html> <html lang="en">
<head><title>Hello Docker</title></head> <head><title>Hello Docker</title></head>
<body> <body>
<p>Hello Docker! I'm service hello-template.</p> <p>Hello Docker! I'm service hello-template.</p>

15
engine/swarm/how-swarm-mode-works/pki.md
View File

@ -79,18 +79,9 @@ happen in sequence:
new node certificates. This ensures that nodes that still trust the old root new node certificates. This ensures that nodes that still trust the old root
CA can still validate a certificate signed by the new CA. CA can still validate a certificate signed by the new CA.
2. In Docker 17.06 and higher, Docker also tells all nodes to immediately 2. Docker also tells all nodes to immediately renew their TLS certificates.
renew their TLS certificates. This process may take several minutes, This process may take several minutes, depending on the number of nodes in
depending on the number of nodes in the swarm. the swarm.
> **Note**: If your swarm has nodes with different Docker versions, the
> following two things are true:
> - Only a manager that is running as the leader **and** running Docker 17.06
> or higher tells nodes to renew their TLS certificates.
> - Only nodes running Docker 17.06 or higher obey this directive.
>
> For the most predictable behavior, ensure that all swarm nodes are running
> Docker 17.06 or higher.
3. After every node in the swarm has a new TLS certificate signed by the new CA, 3. After every node in the swarm has a new TLS certificate signed by the new CA,
Docker forgets about the old CA certificate and key material, and tells Docker forgets about the old CA certificate and key material, and tells

4
engine/swarm/ingress.md
View File

@ -98,8 +98,8 @@ The output shows the `<CONTAINER-PORT>` (labeled `TargetPort`) from the containe
By default, when you publish a port, it is a TCP port. You can By default, when you publish a port, it is a TCP port. You can
specifically publish a UDP port instead of or in addition to a TCP port. When specifically publish a UDP port instead of or in addition to a TCP port. When
you publish both TCP and UDP ports, If you omit the protocol specifier, you publish both TCP and UDP ports, If you omit the protocol specifier,
the port is published as a TCP port. If you use the longer syntax (recommended the port is published as a TCP port. If you use the longer syntax (recommended),
for Docker 1.13 and higher), set the `protocol` key to either `tcp` or `udp`. set the `protocol` key to either `tcp` or `udp`.
#### TCP only #### TCP only

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

@ -18,18 +18,11 @@ goes down, the remaining manager nodes elect a new leader and resume
orchestration and maintenance of the swarm state. By default, manager nodes orchestration and maintenance of the swarm state. By default, manager nodes
also run tasks. also run tasks.
Before you add nodes to a swarm you must install Docker Engine 1.12 or later on
the host machine.
The Docker Engine joins the swarm depending on the **join-token** you provide to The Docker Engine joins the swarm depending on the **join-token** you provide to
the `docker swarm join` command. The node only uses the token at join time. If the `docker swarm join` command. The node only uses the token at join time. If
you subsequently rotate the token, it doesn't affect existing swarm nodes. Refer you subsequently rotate the token, it doesn't affect existing swarm nodes. Refer
to [Run Docker Engine in swarm mode](swarm-mode.md#view-the-join-command-or-update-a-swarm-join-token). to [Run Docker Engine in swarm mode](swarm-mode.md#view-the-join-command-or-update-a-swarm-join-token).
> **Note**: Docker engine allows a non-FIPS node to join a FIPS-enabled swarm cluster.
While a mixed FIPS environment makes upgrading or changing status easier, Docker recommends not running a mixed FIPS environment in production.
## Join as a worker node ## Join as a worker node
To retrieve the join command including the join token for worker nodes, run the To retrieve the join command including the join token for worker nodes, run the

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

@ -189,11 +189,13 @@ respectively.
If your swarm service relies on one or more If your swarm service relies on one or more
[plugins](/engine/extend/plugin_api/), these plugins need to be available on [plugins](/engine/extend/plugin_api/), these plugins need to be available on
every node where the service could potentially be deployed. You can manually every node where the service could potentially be deployed. You can manually
install the plugin on each node or script the installation. In Docker 17.07 and install the plugin on each node or script the installation. You can also deploy
higher, you can also deploy the plugin in a similar way as a global service the plugin in a similar way as a global service using the Docker API, by specifying
using the Docker API, by specifying a `PluginSpec` instead of a `ContainerSpec`. a `PluginSpec` instead of a `ContainerSpec`.
> **Note**: There is currently no way to deploy a plugin to a swarm using the > **Note**
>
> There is currently no way to deploy a plugin to a swarm using the
> Docker CLI or Docker Compose. In addition, it is not possible to install > Docker CLI or Docker Compose. In addition, it is not possible to install
> plugins from a private repository. > plugins from a private repository.

10
engine/swarm/networking.md
View File

@ -34,8 +34,8 @@ The following three network concepts are important to swarm services:
`ingress` network. `ingress` network.
The `ingress` network is created automatically when you initialize or join a The `ingress` network is created automatically when you initialize or join a
swarm. Most users do not need to customize its configuration, but Docker 17.05 swarm. Most users do not need to customize its configuration, but Docker allows
and higher allows you to do so. you to do so.
- The **docker_gwbridge** is a bridge network that connects the overlay - The **docker_gwbridge** is a bridge network that connects the overlay
networks (including the `ingress` network) to an individual Docker daemon's networks (including the `ingress` network) to an individual Docker daemon's
@ -288,8 +288,8 @@ round robin (DNSRR). You can configure this per service.
## Customize the ingress network ## Customize the ingress network
Most users never need to configure the `ingress` network, but Docker 17.05 and Most users never need to configure the `ingress` network, but Docker allows you
higher allow you to do so. This can be useful if the automatically-chosen subnet to do so. This can be useful if the automatically-chosen subnet
conflicts with one that already exists on your network, or you need to customize conflicts with one that already exists on your network, or you need to customize
other low-level network settings such as the MTU. other low-level network settings such as the MTU.
@ -382,7 +382,7 @@ By default, all swarm traffic is sent over the same interface, including control
and management traffic for maintaining the swarm itself and data traffic to and and management traffic for maintaining the swarm itself and data traffic to and
from the service containers. from the service containers.
In Docker 17.06 and higher, it is possible to separate this traffic by passing You can separate this traffic by passing
the `--data-path-addr` flag when initializing or joining the swarm. If there are the `--data-path-addr` flag when initializing or joining the swarm. If there are
multiple interfaces, `--advertise-addr` must be specified explicitly, and multiple interfaces, `--advertise-addr` must be specified explicitly, and
`--data-path-addr` defaults to `--advertise-addr` if not specified. Traffic about `--data-path-addr` defaults to `--advertise-addr` if not specified. Traffic about

121
engine/swarm/secrets.md
View File

@ -9,12 +9,11 @@ keywords: swarm, secrets, credentials, sensitive strings, sensitive data, securi
In terms of Docker Swarm services, a _secret_ is a blob of data, such as a In terms of Docker Swarm services, a _secret_ is a blob of data, such as a
password, SSH private key, SSL certificate, or another piece of data that should password, SSH private key, SSL certificate, or another piece of data that should
not be transmitted over a network or stored unencrypted in a Dockerfile or in not be transmitted over a network or stored unencrypted in a Dockerfile or in
your application's source code. In Docker 1.13 and higher, you can use Docker your application's source code. You can use Docker _secrets_ to centrally manage
_secrets_ to centrally manage this data and securely transmit it to only those this data and securely transmit it to only those containers that need access to
containers that need access to it. Secrets are encrypted during transit and at it. Secrets are encrypted during transit and at rest in a Docker swarm. A given
rest in a Docker swarm. A given secret is only accessible to those services secret is only accessible to those services which have been granted explicit
which have been granted explicit access to it, and only while those service access to it, and only while those service tasks are running.
tasks are running.
You can use secrets to manage any sensitive data which a container needs at You can use secrets to manage any sensitive data which a container needs at
runtime but you don't want to store in the image or in source control, such as: runtime but you don't want to store in the image or in source control, such as:
@ -39,14 +38,14 @@ containers only need to know the name of the secret to function in all
three environments. three environments.
You can also use secrets to manage non-sensitive data, such as configuration You can also use secrets to manage non-sensitive data, such as configuration
files. However, Docker 17.06 and higher support the use of [configs](configs.md) files. However, Docker supports the use of [configs](configs.md)
for storing non-sensitive data. Configs are mounted into the container's for storing non-sensitive data. Configs are mounted into the container's
filesystem directly, without the use of a RAM disk. filesystem directly, without the use of a RAM disk.
### Windows support ### Windows support
Docker 17.06 and higher include support for secrets on Windows containers. Docker includes support for secrets on Windows containers. Where there are
Where there are differences in the implementations, they are called out in the differences in the implementations, they are called out in the
examples below. Keep the following notable differences in mind: examples below. Keep the following notable differences in mind:
- Microsoft Windows has no built-in driver for managing RAM disks, so within - Microsoft Windows has no built-in driver for managing RAM disks, so within
@ -81,20 +80,12 @@ encrypted. The entire Raft log is replicated across the other managers, ensuring
the same high availability guarantees for secrets as for the rest of the swarm the same high availability guarantees for secrets as for the rest of the swarm
management data. management data.
> **Warning**: Raft data is encrypted in Docker 1.13 and higher. If any of your
> Swarm managers run an earlier version, and one of those managers becomes the
> manager of the swarm, the secrets are stored unencrypted in that node's
> Raft logs. Before adding any secrets, update all of your manager nodes to
> Docker 1.13 or higher to prevent secrets from being written to plain-text Raft
> logs.
{:.warning}
When you grant a newly-created or running service access to a secret, the When you grant a newly-created or running service access to a secret, the
decrypted secret is mounted into the container in an in-memory filesystem. The decrypted secret is mounted into the container in an in-memory filesystem. The
location of the mount point within the container defaults to location of the mount point within the container defaults to
`/run/secrets/<secret_name>` in Linux containers, or `/run/secrets/<secret_name>` in Linux containers, or
`C:\ProgramData\Docker\secrets` in Windows containers. You can specify a custom `C:\ProgramData\Docker\secrets` in Windows containers. You can also specify a
location in Docker 17.06 and higher. custom location.
You can update a service to grant it access to additional secrets or revoke its You can update a service to grant it access to additional secrets or revoke its
access to a given secret at any time. access to a given secret at any time.
@ -140,8 +131,7 @@ a similar way, see
> **Note**: These examples use a single-Engine swarm and unscaled services for > **Note**: These examples use a single-Engine swarm and unscaled services for
> simplicity. The examples use Linux containers, but Windows containers also > simplicity. The examples use Linux containers, but Windows containers also
> support secrets in Docker 17.06 and higher. > support secrets. See [Windows support](#windows-support).
> See [Windows support](#windows-support).
### Defining and using secrets in compose files ### Defining and using secrets in compose files
@ -272,16 +262,15 @@ real-world example, continue to
### Simple example: Use secrets in a Windows service ### Simple example: Use secrets in a Windows service
This is a very simple example which shows how to use secrets with a Microsoft This is a very simple example which shows how to use secrets with a Microsoft
IIS service running on Docker 17.06 EE on Microsoft Windows Server 2016 or Docker IIS service running on Docker for Windows running Windows containers on
Desktop for Mac 17.06 on Microsoft Windows 10. It is a naive example that stores the Microsoft Windows 10. It is a naive example that stores the webpage in a secret.
webpage in a secret.
This example assumes that you have PowerShell installed. This example assumes that you have PowerShell installed.
1. Save the following into a new file `index.html`. 1. Save the following into a new file `index.html`.
```html ```html
<html> <html lang="en">
<head><title>Hello Docker</title></head> <head><title>Hello Docker</title></head>
<body> <body>
<p>Hello Docker! You have deployed a HTML page.</p> <p>Hello Docker! You have deployed a HTML page.</p>
@ -311,8 +300,8 @@ This example assumes that you have PowerShell installed.
``` ```
> **Note**: There is technically no reason to use secrets for this > **Note**: There is technically no reason to use secrets for this
> example. With Docker 17.06 and higher, [configs](configs.md) are > example; [configs](configs.md) are a better fit. This example is
> a better fit. This example is for illustration only. > for illustration only.
5. Access the IIS service at `http://localhost:8000/`. It should serve 5. Access the IIS service at `http://localhost:8000/`. It should serve
the HTML content from the first step. the HTML content from the first step.
@ -480,48 +469,46 @@ generate the site key and certificate, name the files `site.key` and
> This example does not require a custom image. It puts the `site.conf` > This example does not require a custom image. It puts the `site.conf`
> into place and runs the container all in one step. > into place and runs the container all in one step.
In Docker 17.05 and earlier, secrets are always located within the Secrets are located within the `/run/secrets/` directory in the container
`/run/secrets/` directory. Docker 17.06 and higher allow you to specify a by default, which may require extra steps in the container to make the
custom location for a secret within the container. The two examples below secret available in a different path. The example below creates a symbolic
illustrate the difference. The older version of this command requires you to link to the true location of the `site.conf` file so that Nginx can read it:
create a symbolic link to the true location of the `site.conf` file so that
Nginx can read it, but the newer version does not require this. The older
example is preserved so that you can see the difference.
- **Docker 17.06 and higher**: ```bash
$ docker service create \
--name nginx \
--secret site.key \
--secret site.crt \
--secret site.conf \
--publish published=3000,target=443 \
nginx:latest \
sh -c "ln -s /run/secrets/site.conf /etc/nginx/conf.d/site.conf && exec nginx -g 'daemon off;'"
```
```bash Instead of creating symlinks, secrets allow you to specify a custom location
$ docker service create \ using the `target` option. The example below illustrates how the `site.conf`
--name nginx \ secret is made available at `/etc/nginx/conf.d/site.conf` inside the container
--secret site.key \ without the use of symbolic links:
--secret site.crt \
--secret source=site.conf,target=/etc/nginx/conf.d/site.conf \
--publish published=3000,target=443 \
nginx:latest \
sh -c "exec nginx -g 'daemon off;'"
```
- **Docker 17.05 and earlier**: ```bash
$ docker service create \
--name nginx \
--secret site.key \
--secret site.crt \
--secret source=site.conf,target=/etc/nginx/conf.d/site.conf \
--publish published=3000,target=443 \
nginx:latest \
sh -c "exec nginx -g 'daemon off;'"
```
```bash The `site.key` and `site.crt` secrets use the short-hand syntax, without a
$ docker service create \ custom `target` location set. The short syntax mounts the secrets in `/run/secrets/
--name nginx \ with the same name as the secret. Within the running containers, the following
--secret site.key \ three files now exist:
--secret site.crt \
--secret site.conf \
--publish published=3000,target=443 \
nginx:latest \
sh -c "ln -s /run/secrets/site.conf /etc/nginx/conf.d/site.conf && exec nginx -g 'daemon off;'"
```
The first example shows both the short and long syntax for secrets, and the
second example shows only the short syntax. The short syntax creates files in
`/run/secrets/` with the same name as the secret. Within the running
containers, the following three files now exist:
- `/run/secrets/site.key` - `/run/secrets/site.key`
- `/run/secrets/site.crt` - `/run/secrets/site.crt`
- `/etc/nginx/conf.d/site.conf` (or `/run/secrets/site.conf` if you used the second example) - `/etc/nginx/conf.d/site.conf`
5. Verify that the Nginx service is running. 5. Verify that the Nginx service is running.
@ -974,14 +961,16 @@ their values from a file (`WORDPRESS_DB_PASSWORD_FILE`). This strategy ensures
that backward compatibility is preserved, while allowing your container to read that backward compatibility is preserved, while allowing your container to read
the information from a Docker-managed secret instead of being passed directly. the information from a Docker-managed secret instead of being passed directly.
>**Note**: Docker secrets do not set environment variables directly. This was a > **Note**
conscious decision, because environment variables can unintentionally be leaked >
between containers (for instance, if you use `--link`). > Docker secrets do not set environment variables directly. This was a
> conscious decision, because environment variables can unintentionally be leaked
> between containers (for instance, if you use `--link`).
## Use Secrets in Compose ## Use Secrets in Compose
```yaml ```yaml
version: '3.1' version: "{{ site.compose_file_v3 }}"
services: services:
db: db:

35
engine/swarm/services.md
View File

@ -339,11 +339,9 @@ service's image.
Each tag represents a digest, similar to a Git hash. Some tags, such as Each tag represents a digest, similar to a Git hash. Some tags, such as
`latest`, are updated often to point to a new digest. Others, such as `latest`, are updated often to point to a new digest. Others, such as
`ubuntu:16.04`, represent a released software version and are not expected to `ubuntu:16.04`, represent a released software version and are not expected to
update to point to a new digest often if at all. In Docker 1.13 and higher, when update to point to a new digest often if at all. When you create a service, it
you create a service, it is constrained to create tasks using a specific digest is constrained to create tasks using a specific digest of an image until you
of an image until you update the service using `service update` with the update the service using `service update` with the `--image` flag.
`--image` flag. If you use an older version of Docker Engine, you must remove
and re-create the service to update its image.
When you run `service update` with the `--image` flag, the swarm manager queries When you run `service update` with the `--image` flag, the swarm manager queries
Docker Hub or your private Docker registry for the digest the tag currently Docker Hub or your private Docker registry for the digest the tag currently
@ -404,11 +402,10 @@ outside the swarm in two ways:
choice for many types of services. choice for many types of services.
- [You can publish a service task's port directly on the swarm node](#publish-a-services-ports-directly-on-the-swarm-node) - [You can publish a service task's port directly on the swarm node](#publish-a-services-ports-directly-on-the-swarm-node)
where that service is running. This feature is available in Docker 1.13 and where that service is running. This bypasses the routing mesh and provides the
higher. This bypasses the routing mesh and provides the maximum flexibility, maximum flexibility, including the ability for you to develop your own routing
including the ability for you to develop your own routing framework. However, framework. However, you are responsible for keeping track of where each task is
you are responsible for keeping track of where each task is running and running and routing requests to the tasks, and load-balancing across the nodes.
routing requests to the tasks, and load-balancing across the nodes.
Keep reading for more information and use cases for each of these methods. Keep reading for more information and use cases for each of these methods.
@ -554,7 +551,7 @@ flag. For more information, see
### Customize a service's isolation mode ### Customize a service's isolation mode
Docker 17.12 CE and higher allow you to specify a swarm service's isolation Docker allows you to specify a swarm service's isolation
mode. **This setting applies to Windows hosts only and is ignored for Linux mode. **This setting applies to Windows hosts only and is ignored for Linux
hosts.** The isolation mode can be one of the following: hosts.** The isolation mode can be one of the following:
@ -850,18 +847,12 @@ $ docker service update \
my_web my_web
``` ```
In Docker 17.04 and higher, you can configure a service to roll back You can configure a service to roll back automatically if a service update fails
automatically if a service update fails to deploy. See to deploy. See [Automatically roll back if an update fails](#automatically-roll-back-if-an-update-fails).
[Automatically roll back if an update fails](#automatically-roll-back-if-an-update-fails).
Related to the new automatic rollback feature, in Docker 17.04 and higher, Manual rollback is handled at the server side, which allows manually-initiated
manual rollback is handled at the server side, rather than the client, if the rollbacks to respect the new rollback parameters. Note that `--rollback` cannot
daemon is running Docker 17.04 or higher. This allows manually-initiated be used in conjunction with other flags to `docker service update`.
rollbacks to respect the new rollback parameters. The client is version-aware,
so it still uses the old method against an older daemon.
Finally, in Docker 17.04 and higher, `--rollback` cannot be used in conjunction
with other flags to `docker service update`.
### Automatically roll back if an update fails ### Automatically roll back if an update fails

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

@ -13,19 +13,21 @@ above. If you have an older version, see the [upgrade guide](../../compose/compo
To run through this tutorial, you need: To run through this tutorial, you need:
1. A Docker Engine of version 1.13.0 or later, running in [swarm mode](swarm-mode.md). 1. A Docker Engine running in [swarm mode](swarm-mode.md).
If you're not familiar with swarm mode, you might want to read If you're not familiar with swarm mode, you might want to read
[Swarm mode key concepts](key-concepts.md) [Swarm mode key concepts](key-concepts.md)
and [How services work](how-swarm-mode-works/services.md). and [How services work](how-swarm-mode-works/services.md).
> **Note**: If you're trying things out on a local development environment, > **Note**
>
> If you're trying things out on a local development environment,
> you can put your engine into swarm mode with `docker swarm init`. > you can put your engine into swarm mode with `docker swarm init`.
> >
> If you've already got a multi-node swarm running, keep in mind that all > If you've already got a multi-node swarm running, keep in mind that all
> `docker stack` and `docker service` commands must be run from a manager > `docker stack` and `docker service` commands must be run from a manager
> node. > node.
2. [Docker Compose](../../compose/install.md) version 1.10 or later. 2. A current version of [Docker Compose](../../compose/install.md).
## Set up a Docker registry ## Set up a Docker registry
@ -113,7 +115,7 @@ counter whenever you visit it.
5. Create a file called `docker-compose.yml` and paste this in: 5. Create a file called `docker-compose.yml` and paste this in:
```none ```none
version: '3' version: "{{ site.compose_file_v3 }}"
services: services:
web: web:

26
engine/swarm/swarm-tutorial/index.md
View File

@ -26,7 +26,6 @@ If you are brand new to Docker, see [About Docker Engine](../../index.md).
To run this tutorial, you need the following: To run this tutorial, you need the following:
* [three Linux hosts which can communicate over a network, with Docker installed](#three-networked-host-machines) * [three Linux hosts which can communicate over a network, with Docker installed](#three-networked-host-machines)
* [Docker Engine 1.12 or later installed](#docker-engine-112-or-newer)
* [the IP address of the manager machine](#the-ip-address-of-the-manager-machine) * [the IP address of the manager machine](#the-ip-address-of-the-manager-machine)
* [open ports between the hosts](#open-protocols-and-ports-between-the-hosts) * [open ports between the hosts](#open-protocols-and-ports-between-the-hosts)
@ -47,16 +46,6 @@ workers (`worker1` and `worker2`).
as well, in which case you need only one host. Multi-node commands do not as well, in which case you need only one host. Multi-node commands do not
work, but you can initialize a swarm, create services, and scale them. work, but you can initialize a swarm, create services, and scale them.
### Docker Engine 1.12 or newer
This tutorial requires Docker Engine 1.12 or newer on each of the host machines.
Install Docker Engine and verify that the Docker Engine daemon is running on
each of the machines. You can get the latest version of Docker Engine as
follows:
* [install Docker Engine on Linux machines](#install-docker-engine-on-linux-machines)
* [use Docker Desktop for Mac or Docker Desktop for Windows](#use-docker-desktop-for-mac-or-docker-desktop-for-windows)
#### Install Docker Engine on Linux machines #### Install Docker Engine on Linux machines
@ -72,15 +61,12 @@ Alternatively, install the latest [Docker Desktop for Mac](../../../docker-for-m
computer. You can test both single-node and multi-node swarm from this computer, computer. You can test both single-node and multi-node swarm from this computer,
but you need to use Docker Machine to test the multi-node scenarios. but you need to use Docker Machine to test the multi-node scenarios.
* You can use Docker Desktop for Mac or Windows to test _single-node_ features of swarm * You can use Docker Desktop for Mac or Windows to test _single-node_ features
mode, including initializing a swarm with a single node, creating services, of swarm mode, including initializing a swarm with a single node, creating
and scaling services. Docker "Moby" on Hyperkit (Mac) or Hyper-V (Windows) services, and scaling services.
serve as the single swarm node. * Currently, you cannot use Docker Desktop for Mac or Docker Desktop for Windows
alone to test a _multi-node_ swarm, but many examples are applicable to a
<p /> single-node Swarm setup.
* Currently, you cannot use Docker Desktop for Mac or Docker Desktop for Windows alone to test a
_multi-node_ swarm, but many examples are applicable to a single-node Swarm setup.
### The IP address of the manager machine ### The IP address of the manager machine

17
engine/swarm/swarm_manager_locking.md
View File

@ -4,18 +4,17 @@ keywords: swarm, manager, lock, unlock, autolock, encryption
title: Lock your swarm to protect its encryption key title: Lock your swarm to protect its encryption key
--- ---
In Docker 1.13 and higher, the Raft logs used by swarm managers are encrypted on The Raft logs used by swarm managers are encrypted on disk by default. This at-rest
disk by default. This at-rest encryption protects your service's configuration encryption protects your service's configuration and data from attackers who gain
and data from attackers who gain access to the encrypted Raft logs. One of the access to the encrypted Raft logs. One of the reasons this feature was introduced
reasons this feature was introduced was in support of the [Docker secrets](secrets.md) was in support of the [Docker secrets](secrets.md) feature.
feature.
When Docker restarts, both the TLS key used to encrypt communication among swarm When Docker restarts, both the TLS key used to encrypt communication among swarm
nodes, and the key used to encrypt and decrypt Raft logs on disk, are loaded nodes, and the key used to encrypt and decrypt Raft logs on disk, are loaded
into each manager node's memory. Docker 1.13 introduces the ability to protect into each manager node's memory. Docker has the ability to protect the mutual TLS
the mutual TLS encryption key and the key used to encrypt and decrypt Raft logs encryption key and the key used to encrypt and decrypt Raft logs at rest, by
at rest, by allowing you to take ownership of these keys and to require manual allowing you to take ownership of these keys and to require manual unlocking of
unlocking of your managers. This feature is called _autolock_. your managers. This feature is called _autolock_.
When Docker restarts, you must When Docker restarts, you must
[unlock the swarm](#unlock-a-swarm) first, using a [unlock the swarm](#unlock-a-swarm) first, using a

4
machine/reference/scp.md
View File

@ -68,8 +68,8 @@ $ docker-machine scp -r /Users/<username>/webapp MACHINE-NAME:/home/ubuntu/webap
Then write a docker-compose file that bind mounts it in: Then write a docker-compose file that bind mounts it in:
```none ```yaml
version: "3.1" version: "{{ site.compose_file_v3 }}"
services: services:
webapp: webapp:
image: alpine image: alpine

3
network/index.md
View File

@ -42,8 +42,7 @@ exist by default, and provide core networking functionality:
[bridge networks](bridge.md). [bridge networks](bridge.md).
- `host`: For standalone containers, remove network isolation between the - `host`: For standalone containers, remove network isolation between the
container and the Docker host, and use the host's networking directly. `host` container and the Docker host, and use the host's networking directly. See
is only available for swarm services on Docker 17.06 and higher. See
[use the host network](host.md). [use the host network](host.md).
- `overlay`: Overlay networks connect multiple Docker daemons together and - `overlay`: Overlay networks connect multiple Docker daemons together and

24
network/network-tutorial-overlay.md
View File

@ -30,17 +30,14 @@ host running elsewhere.
- [Communicate between a container and a swarm service](#communicate-between-a-container-and-a-swarm-service) - [Communicate between a container and a swarm service](#communicate-between-a-container-and-a-swarm-service)
sets up communication between a standalone container and a swarm service, sets up communication between a standalone container and a swarm service,
using an attachable overlay network. This is supported in Docker 17.06 and using an attachable overlay network.
higher.
## Prerequisites ## Prerequisites
These requires you to have at least a single-node swarm, which means that These require you to have at least a single-node swarm, which means that
you have started Docker and run `docker swarm init` on the host. You can run you have started Docker and run `docker swarm init` on the host. You can run
the examples on a multi-node swarm as well. the examples on a multi-node swarm as well.
The last example requires Docker 17.06 or higher.
## Use the default overlay network ## Use the default overlay network
In this example, you start an `alpine` service and examine the characteristics In this example, you start an `alpine` service and examine the characteristics
@ -53,9 +50,8 @@ the point of view of a service.
### Prerequisites ### Prerequisites
This tutorial requires three physical or virtual Docker hosts which can all This tutorial requires three physical or virtual Docker hosts which can all
communicate with one another, all running new installations of Docker 17.03 or communicate with one another. This tutorial assumes that the three hosts are
higher. This tutorial assumes that the three hosts are running on the same running on the same network with no firewall involved.
network with no firewall involved.
These hosts will be referred to as `manager`, `worker-1`, and `worker-2`. The These hosts will be referred to as `manager`, `worker-1`, and `worker-2`. The
`manager` host will function as both a manager and a worker, which means it can `manager` host will function as both a manager and a worker, which means it can
@ -290,8 +286,8 @@ overlay network. Steps are:
### Prerequisites ### Prerequisites
For this test, you need two different Docker hosts that can communicate with For this test, you need two different Docker hosts that can communicate with
each other. Each host must have Docker 17.06 or higher with the following ports each other. Each host must have the following ports open between the two Docker
open between the two Docker hosts: hosts:
- TCP port 2377 - TCP port 2377
- TCP and UDP port 7946 - TCP and UDP port 7946
@ -437,12 +433,6 @@ example also uses Linux hosts, but the same commands work on Windows.
## Communicate between a container and a swarm service ## Communicate between a container and a swarm service
### Prerequisites
You need Docker 17.06 or higher for this example.
### Walkthrough
In this example, you start two different `alpine` containers on the same Docker In this example, you start two different `alpine` containers on the same Docker
host and do some tests to understand how they communicate with each other. You host and do some tests to understand how they communicate with each other. You
need to have Docker installed and running. need to have Docker installed and running.
@ -639,7 +629,7 @@ need to have Docker installed and running.
Remember, the default `bridge` network is not recommended for production. To Remember, the default `bridge` network is not recommended for production. To
learn about user-defined bridge networks, continue to the learn about user-defined bridge networks, continue to the
[next tutorial](#use-user-defined-bridge-networks). [next tutorial](network-tutorial-standalone.md#use-user-defined-bridge-networks).
## Other networking tutorials ## Other networking tutorials

5
network/network-tutorial-standalone.md
View File

@ -23,9 +23,8 @@ host running elsewhere.
running in production. running in production.
Although [overlay networks](overlay.md) are generally used for swarm services, Although [overlay networks](overlay.md) are generally used for swarm services,
Docker 17.06 and higher allow you to use an overlay network for standalone you can also use an overlay network for standalone containers. That's covered as
containers. That's covered as part of the part of the [tutorial on using overlay networks](network-tutorial-overlay.md#use-an-overlay-network-for-standalone-containers).
[tutorial on using overlay networks](network-tutorial-overlay.md#use-an-overlay-network-for-standalone-containers).
## Use the default bridge network ## Use the default bridge network

8
network/overlay.md
View File

@ -111,10 +111,10 @@ $ docker network create --opt encrypted --driver overlay --attachable my-attacha
### Customize the default ingress network ### Customize the default ingress network
Most users never need to configure the `ingress` network, but Docker 17.05 and Most users never need to configure the `ingress` network, but Docker allows you
higher allow you to do so. This can be useful if the automatically-chosen subnet to do so. This can be useful if the automatically-chosen subnet conflicts with
conflicts with one that already exists on your network, or you need to customize one that already exists on your network, or you need to customize other low-level
other low-level network settings such as the MTU. network settings such as the MTU.
Customizing the `ingress` network involves removing and recreating it. This is Customizing the `ingress` network involves removing and recreating it. This is
usually done before you create any services in the swarm. If you have existing usually done before you create any services in the swarm. If you have existing

4
registry/deploying.md
View File

@ -520,8 +520,8 @@ following:
pushed, but are always fetched from their authorized location. This is fine pushed, but are always fetched from their authorized location. This is fine
for internet-connected hosts, but not in an air-gapped set-up. for internet-connected hosts, but not in an air-gapped set-up.
In Docker 17.06 and higher, you can configure the Docker daemon to allow You can configure the Docker daemon to allow pushing non-distributable layers
pushing non-distributable layers to private registries, in this scenario. to private registries.
**This is only useful in air-gapped set-ups in the presence of **This is only useful in air-gapped set-ups in the presence of
non-distributable images, or in extremely bandwidth-limited situations.** non-distributable images, or in extremely bandwidth-limited situations.**
You are responsible for ensuring that you are in compliance with the terms of You are responsible for ensuring that you are in compliance with the terms of

7
storage/bind-mounts.md
View File

@ -25,11 +25,8 @@ manage bind mounts.
## Choose the -v or --mount flag ## Choose the -v or --mount flag
Originally, the `-v` or `--volume` flag was used for standalone containers and In general, `--mount` is more explicit and verbose. The biggest difference is that
the `--mount` flag was used for swarm services. However, starting with Docker the `-v` syntax combines all the options together in one field, while the `--mount`
17.06, you can also use `--mount` with standalone containers. In general,
`--mount` is more explicit and verbose. The biggest difference is that the `-v`
syntax combines all the options together in one field, while the `--mount`
syntax separates them. Here is a comparison of the syntax for each flag. syntax separates them. Here is a comparison of the syntax for each flag.
> **Tip**: New users should use the `--mount` syntax. Experienced users may > **Tip**: New users should use the `--mount` syntax. Experienced users may

6
storage/index.md
View File

@ -107,9 +107,9 @@ mounts is to think about where the data lives on the Docker host.
Bind mounts and volumes can both be mounted into containers using the `-v` or Bind mounts and volumes can both be mounted into containers using the `-v` or
`--volume` flag, but the syntax for each is slightly different. For `tmpfs` `--volume` flag, but the syntax for each is slightly different. For `tmpfs`
mounts, you can use the `--tmpfs` flag. However, in Docker 17.06 and higher, mounts, you can use the `--tmpfs` flag. We recommend using the `--mount` flag
we recommend using the `--mount` flag for both containers and services, for for both containers and services, for bind mounts, volumes, or `tmpfs` mounts,
bind mounts, volumes, or `tmpfs` mounts, as the syntax is more clear. as the syntax is more clear.
## Good use cases for volumes ## Good use cases for volumes

11
storage/storagedriver/device-mapper-driver.md
View File

@ -144,12 +144,11 @@ below to configure Docker to use the `devicemapper` storage driver in
#### Allow Docker to configure direct-lvm mode #### Allow Docker to configure direct-lvm mode
With Docker `17.06` and higher, Docker can manage the block device for you, Docker can manage the block device for you, simplifying configuration of `direct-lvm`
simplifying configuration of `direct-lvm` mode. **This is appropriate for fresh mode. **This is appropriate for fresh Docker setups only.** You can only use a
Docker setups only.** You can only use a single block device. If you need to single block device. If you need to use multiple block devices,
use multiple block devices, [configure direct-lvm mode [configure direct-lvm mode manually](#configure-direct-lvm-mode-manually) instead.
manually](#configure-direct-lvm-mode-manually) instead. The following new The following new configuration options are available:
configuration options have been added:
| Option | Description | Required? | Default | Example | | Option | Description | Required? | Default | Example |
|:--------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------|:--------|:-----------------------------------| |:--------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------|:--------|:-----------------------------------|

5
storage/storagedriver/overlayfs-driver.md
View File

@ -23,10 +23,9 @@ storage driver as `overlay` or `overlay2`.
## Prerequisites ## Prerequisites
OverlayFS is supported if you meet the following prerequisites: OverlayFS is the recommended storage driver, and supported if you meet the following
prerequisites:
- The `overlay2` driver is supported on Docker Engine - Community, and Docker EE 17.06.02-ee5 and
up, and is the recommended storage driver.
- Version 4.0 or higher of the Linux kernel, or RHEL or CentOS using - Version 4.0 or higher of the Linux kernel, or RHEL or CentOS using
version 3.10.0-514 of the kernel or higher. If you use an older kernel, you need version 3.10.0-514 of the kernel or higher. If you use an older kernel, you need
to use the `overlay` driver, which is not recommended. to use the `overlay` driver, which is not recommended.

17
storage/storagedriver/select-storage-driver.md
View File

@ -32,8 +32,8 @@ Docker supports the following storage drivers:
* `overlay2` is the preferred storage driver, for all currently supported * `overlay2` is the preferred storage driver, for all currently supported
Linux distributions, and requires no extra configuration. Linux distributions, and requires no extra configuration.
* `aufs` is the preferred storage driver for Docker 18.06 and older, when * `aufs` was the preferred storage driver for Docker 18.06 and older, when
running on Ubuntu 14.04 on kernel 3.13 which has no support for `overlay2`. running on Ubuntu 14.04 on kernel 3.13 which had no support for `overlay2`.
* `devicemapper` is supported, but requires `direct-lvm` for production * `devicemapper` is supported, but requires `direct-lvm` for production
environments, because `loopback-lvm`, while zero-configuration, has very environments, because `loopback-lvm`, while zero-configuration, has very
poor performance. `devicemapper` was the recommended storage driver for poor performance. `devicemapper` was the recommended storage driver for
@ -62,7 +62,7 @@ After you have narrowed down which storage drivers you can choose from, your cho
characteristics of your workload and the level of stability you need. See [Other considerations](#other-considerations) characteristics of your workload and the level of stability you need. See [Other considerations](#other-considerations)
for help in making the final decision. for help in making the final decision.
> ***NOTE***: Your choice may be limited by your Docker edition, operating system, and distribution. > ***NOTE***: Your choice may be limited by your operating system and distribution.
> For instance, `aufs` is only supported on Ubuntu and Debian, and may require extra packages > For instance, `aufs` is only supported on Ubuntu and Debian, and may require extra packages
> to be installed, while `btrfs` is only supported on SLES, which is only supported with Docker > to be installed, while `btrfs` is only supported on SLES, which is only supported with Docker
> Enterprise. See [Support storage drivers per Linux distribution](#supported-storage-drivers-per-linux-distribution) > Enterprise. See [Support storage drivers per Linux distribution](#supported-storage-drivers-per-linux-distribution)
@ -91,13 +91,12 @@ configurations work on recent versions of the Linux distribution:
| Docker Engine - Community on CentOS | `overlay2` | `overlay`¹, `devicemapper`², `zfs`, `vfs` | | Docker Engine - Community on CentOS | `overlay2` | `overlay`¹, `devicemapper`², `zfs`, `vfs` |
| Docker Engine - Community on Fedora | `overlay2` | `overlay`¹, `devicemapper`², `zfs`, `vfs` | | Docker Engine - Community on Fedora | `overlay2` | `overlay`¹, `devicemapper`², `zfs`, `vfs` |
¹) The `overlay` storage driver is deprecated in Docker Engine - Enterprise 18.09, and will be ¹) The `overlay` storage driver is deprecated, and will be removed in a future
removed in a future release. It is recommended that users of the `overlay` storage driver release. It is recommended that users of the `overlay` storage driver migrate to `overlay2`.
migrate to `overlay2`.
²) The `devicemapper` storage driver is deprecated in Docker Engine 18.09, and will be ²) The `devicemapper` storage driver is deprecated, and will be removed in a future
removed in a future release. It is recommended that users of the `devicemapper` storage driver release. It is recommended that users of the `devicemapper` storage driver migrate
migrate to `overlay2`. to `overlay2`.
When possible, `overlay2` is the recommended storage driver. When installing When possible, `overlay2` is the recommended storage driver. When installing

3
storage/storagedriver/vfs-driver.md
View File

@ -31,8 +31,7 @@ mechanism to verify other storage back-ends against, in a testing environment.
``` ```
If you want to set a quota to control the maximum size the VFS storage If you want to set a quota to control the maximum size the VFS storage
driver can use, set the `size` option on the `storage-opts` key. Quotas driver can use, set the `size` option on the `storage-opts` key.
are only supported in Docker 17.12 and higher.
```json ```json
{ {

4
storage/storagedriver/zfs-driver.md
View File

@ -44,7 +44,9 @@ use unless you have substantial experience with ZFS on Linux.
and push existing images to Docker Hub or a private repository, so that you and push existing images to Docker Hub or a private repository, so that you
do not need to re-create them later. do not need to re-create them later.
> **Note**: There is no need to use `MountFlags=slave` with Docker Engine 18.09 or > **Note**
>
> There is no need to use `MountFlags=slave` with Docker Engine 18.09 or
> later because `dockerd` and `containerd` are in different mount namespaces. > later because `dockerd` and `containerd` are in different mount namespaces.
## Configure Docker with the `zfs` storage driver ## Configure Docker with the `zfs` storage driver

7
storage/tmpfs.md
View File

@ -31,11 +31,8 @@ containers.
## Choose the --tmpfs or --mount flag ## Choose the --tmpfs or --mount flag
Originally, the `--tmpfs` flag was used for standalone containers and In general, `--mount` is more explicit and verbose. The biggest difference is
the `--mount` flag was used for swarm services. However, starting with Docker that the `--tmpfs` flag does not support any configurable options.
17.06, you can also use `--mount` with standalone containers. In general,
`--mount` is more explicit and verbose. The biggest difference is that the
`--tmpfs` flag does not support any configurable options.
- **`--tmpfs`**: Mounts a `tmpfs` mount without allowing you to specify any - **`--tmpfs`**: Mounts a `tmpfs` mount without allowing you to specify any
configurable options, and can only be used with standalone containers. configurable options, and can only be used with standalone containers.

17
storage/volumes.md
View File

@ -41,15 +41,10 @@ configurable for volumes.
## Choose the -v or --mount flag ## Choose the -v or --mount flag
Originally, the `-v` or `--volume` flag was used for standalone containers and In general, `--mount` is more explicit and verbose. The biggest difference is that
the `--mount` flag was used for swarm services. However, starting with Docker the `-v` syntax combines all the options together in one field, while the `--mount`
17.06, you can also use `--mount` with standalone containers. In general,
`--mount` is more explicit and verbose. The biggest difference is that the `-v`
syntax combines all the options together in one field, while the `--mount`
syntax separates them. Here is a comparison of the syntax for each flag. syntax separates them. Here is a comparison of the syntax for each flag.
> New users should try `--mount` syntax which is simpler than `--volume` syntax.
If you need to specify volume driver options, you must use `--mount`. If you need to specify volume driver options, you must use `--mount`.
- **`-v` or `--volume`**: Consists of three fields, separated by colon characters - **`-v` or `--volume`**: Consists of three fields, separated by colon characters
@ -222,8 +217,8 @@ $ docker volume rm myvol2
A single docker compose service with a volume looks like this: A single docker compose service with a volume looks like this:
```yml ```yaml
version: "3.7" version: "{{ site.compose_file_v3 }}"
services: services:
frontend: frontend:
image: node:lts image: node:lts
@ -239,8 +234,8 @@ volume will be reused on following invocations.
A volume may be created directly outside of compose with `docker volume create` and A volume may be created directly outside of compose with `docker volume create` and
then referenced inside `docker-compose.yml` as follows: then referenced inside `docker-compose.yml` as follows:
```yml ```yaml
version: "3.7" version: "{{ site.compose_file_v3 }}"
services: services:
frontend: frontend:
image: node:lts image: node:lts