beenull/moby
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge pull request #25114 from SvenDowideit/bump_v1.12.0-docs

Browse source 
Bump v1.12.0 docs
This commit is contained in:
Tibor Vass 2016-07-27 11:14:01 -07:00 committed by GitHub
commit 69080f423d
52 changed files with 750 additions and 384 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/admin/ambassador_pattern_linking.md
View file

@ -6,7 +6,7 @@ description = "Using the Ambassador pattern to abstract (network) services"
keywords = ["Examples, Usage, links, docker, documentation, examples, names, name, container naming"]
[menu.main]
parent = "engine_admin"
weight = 6
weight = 15
+++
<![end-metadata]-->

1
docs/admin/chef.md
View file

@ -6,6 +6,7 @@ description = "Installation and using Docker via Chef"
keywords = ["chef, installation, usage, docker, documentation"]
[menu.main]
parent = "engine_admin"
weight="11"
+++
<![end-metadata]-->

293
docs/admin/configuring.md
View file

@ -1,293 +0,0 @@
<!--[metadata]>
+++
aliases = ["/engine/articles/configuring/"]
title = "Configuring and running Docker"
description = "Configuring and running the Docker daemon on various distributions"
keywords = ["docker, daemon, configuration, running, process managers"]
[menu.main]
parent = "engine_admin"
weight = 3
+++
<![end-metadata]-->
# Configuring and running Docker on various distributions
After successfully installing Docker, the `docker` daemon runs with its default
configuration.
In a production environment, system administrators typically configure the
`docker` daemon to start and stop according to an organization's requirements. In most
cases, the system administrator configures a process manager such as `SysVinit`, `Upstart`,
or `systemd` to manage the `docker` daemon's start and stop.
### Running the docker daemon directly
The `docker` daemon can be run directly using the `dockerd` command. By default it listens on
the Unix socket `unix:///var/run/docker.sock`
$ dockerd
INFO[0000] +job init_networkdriver()
INFO[0000] +job serveapi(unix:///var/run/docker.sock)
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
...
...
### Configuring the docker daemon directly
If you're running the `docker` daemon directly by running `docker daemon` instead
of using a process manager, you can append the configuration options to the `docker` run
command directly. Other options can be passed to the `docker` daemon to configure it.
Some of the daemon's options are:
| Flag | Description |
|-----------------------|-----------------------------------------------------------|
| `-D`, `--debug=false` | Enable or disable debug mode. By default, this is false. |
| `-H`,`--host=[]` | Daemon socket(s) to connect to. |
| `--tls=false` | Enable or disable TLS. By default, this is false. |
Here is an example of running the `docker` daemon with configuration options:
$ dockerd -D --tls=true --tlscert=/var/docker/server.pem --tlskey=/var/docker/serverkey.pem -H tcp://192.168.59.3:2376
These options :
- Enable `-D` (debug) mode
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
- Listen for connections on `tcp://192.168.59.3:2376`
The command line reference has the [complete list of daemon flags](../reference/commandline/dockerd.md)
with explanations.
### Daemon debugging
As noted above, setting the log level of the daemon to "debug" or enabling debug mode
with `-D` allows the administrator or operator to gain much more knowledge about the
runtime activity of the daemon. If faced with a non-responsive daemon, the administrator
can force a full stack trace of all threads to be added to the daemon log by sending the
`SIGUSR1` signal to the Docker daemon. A common way to send this signal is using the `kill`
command on Linux systems. For example, `kill -USR1 <daemon-pid>` sends the `SIGUSR1`
signal to the daemon process, causing the stack dump to be added to the daemon log.
> **Note:** The log level setting of the daemon must be at least "info" level and above for
> the stack trace to be saved to the logfile. By default the daemon's log level is set to
> "info".
The daemon will continue operating after handling the `SIGUSR1` signal and dumping the stack
traces to the log. The stack traces can be used to determine the state of all goroutines and
threads within the daemon.
## Ubuntu
As of `14.04`, Ubuntu uses Upstart as a process manager. By default, Upstart jobs
are located in `/etc/init` and the `docker` Upstart job can be found at `/etc/init/docker.conf`.
After successfully [installing Docker for Ubuntu](../installation/linux/ubuntulinux.md),
you can check the running status using Upstart in this way:
$ sudo status docker
docker start/running, process 989
### Running Docker
You can start/stop/restart the `docker` daemon using
$ sudo start docker
$ sudo stop docker
$ sudo restart docker
### Configuring Docker
The instructions below depict configuring Docker on a system that uses `upstart`
as the process manager. As of Ubuntu 15.04, Ubuntu uses `systemd` as its process
manager. For Ubuntu 15.04 and higher, refer to [control and configure Docker with systemd](systemd.md).
You configure the `docker` daemon in the `/etc/default/docker` file on your
system. You do this by specifying values in a `DOCKER_OPTS` variable.
To configure Docker options:
1. Log into your host as a user with `sudo` or `root` privileges.
2. If you don't have one, create the `/etc/default/docker` file on your host. Depending on how
you installed Docker, you may already have this file.
3. Open the file with your favorite editor.
```
$ sudo vi /etc/default/docker
```
4. Add a `DOCKER_OPTS` variable with the following options. These options are appended to the
`docker` daemon's run command.
```
DOCKER_OPTS="-D --tls=true --tlscert=/var/docker/server.pem --tlskey=/var/docker/serverkey.pem -H tcp://192.168.59.3:2376"
```
These options :
- Enable `-D` (debug) mode
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
- Listen for connections on `tcp://192.168.59.3:2376`
The command line reference has the [complete list of daemon flags](../reference/commandline/dockerd.md)
with explanations.
5. Save and close the file.
6. Restart the `docker` daemon.
```
$ sudo restart docker
```
7. Verify that the `docker` daemon is running as specified with the `ps` command.
```
$ ps aux | grep docker | grep -v grep
```
### Logs
By default logs for Upstart jobs are located in `/var/log/upstart` and the logs for `docker` daemon
can be located at `/var/log/upstart/docker.log`
$ tail -f /var/log/upstart/docker.log
INFO[0000] Loading containers: done.
INFO[0000] Docker daemon commit=1b09a95-unsupported graphdriver=aufs version=1.11.0-dev
INFO[0000] +job acceptconnections()
INFO[0000] -job acceptconnections() = OK (0)
INFO[0000] Daemon has completed initialization
## CentOS / Red Hat Enterprise Linux / Fedora
As of `7.x`, CentOS and RHEL use `systemd` as the process manager. As of `21`, Fedora uses
`systemd` as its process manager.
After successfully installing Docker for [CentOS](../installation/linux/centos.md)/[Red Hat Enterprise Linux](../installation/linux/rhel.md)/[Fedora](../installation/linux/fedora.md), you can check the running status in this way:
$ sudo systemctl status docker
### Running Docker
You can start/stop/restart the `docker` daemon using
$ sudo systemctl start docker
$ sudo systemctl stop docker
$ sudo systemctl restart docker
If you want Docker to start at boot, you should also:
$ sudo systemctl enable docker
### Configuring Docker
For CentOS 7.x and RHEL 7.x you can [control and configure Docker with systemd](systemd.md).
Previously, for CentOS 6.x and RHEL 6.x you would configure the `docker` daemon in
the `/etc/sysconfig/docker` file on your system. You would do this by specifying
values in a `other_args` variable. For a short time in CentOS 7.x and RHEL 7.x you
would specify values in a `OPTIONS` variable. This is no longer recommended in favor
of using systemd directly.
For this section, we will use CentOS 7.x as an example to configure the `docker` daemon.
To configure Docker options:
1. Log into your host as a user with `sudo` or `root` privileges.
2. Create the `/etc/systemd/system/docker.service.d` directory.
```
$ sudo mkdir /etc/systemd/system/docker.service.d
```
3. Create a `/etc/systemd/system/docker.service.d/docker.conf` file.
4. Open the file with your favorite editor.
```
$ sudo vi /etc/systemd/system/docker.service.d/docker.conf
```
5. Override the `ExecStart` configuration from your `docker.service` file to customize
the `docker` daemon. To modify the `ExecStart` configuration you have to specify
an empty configuration followed by a new one as follows:
```
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -D --tls=true --tlscert=/var/docker/server.pem --tlskey=/var/docker/serverkey.pem -H tcp://192.168.59.3:2376
```
These options :
- Enable `-D` (debug) mode
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
- Listen for connections on `tcp://192.168.59.3:2376`
The command line reference has the [complete list of daemon flags](../reference/commandline/dockerd.md)
with explanations.
6. Save and close the file.
7. Flush changes.
```
$ sudo systemctl daemon-reload
```
8. Restart the `docker` daemon.
```
$ sudo systemctl restart docker
```
9. Verify that the `docker` daemon is running as specified with the `ps` command.
```
$ ps aux | grep docker | grep -v grep
```
### Logs
systemd has its own logging system called the journal. The logs for the `docker` daemon can
be viewed using `journalctl -u docker`
$ sudo journalctl -u docker
May 06 00:22:05 localhost.localdomain systemd[1]: Starting Docker Application Container Engine...
May 06 00:22:05 localhost.localdomain docker[2495]: time="2015-05-06T00:22:05Z" level="info" msg="+job serveapi(unix:///var/run/docker.sock)"
May 06 00:22:05 localhost.localdomain docker[2495]: time="2015-05-06T00:22:05Z" level="info" msg="Listening for HTTP on unix (/var/run/docker.sock)"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="+job init_networkdriver()"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="-job init_networkdriver() = OK (0)"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Loading containers: start."
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Loading containers: done."
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Docker daemon commit=1b09a95-unsupported graphdriver=aufs version=1.11.0-dev"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="+job acceptconnections()"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="-job acceptconnections() = OK (0)"
_Note: Using and configuring journal is an advanced topic and is beyond the scope of this article._
### Daemonless Containers
Starting with Docker 1.12 containers can run without Docker or containerd running. This allows the
Docker daemon to exit, be upgraded, or recover from a crash without affecting running containers
on the system. To enable this functionality you need to add the `--live-restore` flag when
launching `dockerd`. This will ensure that Docker does not kill containers on graceful shutdown or
on restart leaving the containers running.
While the Docker daemon is down logging will still be captured, however, it will be capped at the kernel's pipe buffer size before the buffer fills up, blocking the process.
Docker will need to be restarted to flush these buffers.
You can modify the kernel's buffer size by changing `/proc/sys/fs/pipe-max-size`.

1
docs/admin/dsc.md
View file

@ -6,6 +6,7 @@ description = "Using DSC to configure a new Docker host"
keywords = ["powershell, dsc, installation, usage, docker, documentation"]
[menu.main]
parent = "engine_admin"
weight="10"
+++
<![end-metadata]-->

2
docs/admin/formatting.md
View file

@ -5,7 +5,7 @@ description = "CLI and log output formatting reference"
keywords = ["format, formatting, output, templates, log"]
[menu.main]
parent = "engine_admin"
weight=-90
weight=7
+++
<![end-metadata]-->

1
docs/admin/host_integration.md
View file

@ -6,6 +6,7 @@ description = "How to generate scripts for upstart, systemd, etc."
keywords = ["systemd, upstart, supervisor, docker, documentation, host integration"]
[menu.main]
parent = "engine_admin"
weight="5"
+++
<![end-metadata]-->

286
docs/admin/index.md
View file

@ -1,11 +1,283 @@
<!-- [metadata]>
<!--[metadata]>
+++
title = "Administrate"
description = "Administrate"
keywords = ["Administrate"]
aliases = [
"/engine/articles/configuring/",
"/engine/admin/configuring/"
]
title = "Configuring and running Docker"
description = "Configuring and running the Docker daemon on various distributions"
keywords = ["docker, daemon, configuration, running, process managers"]
[menu.main]
parent="engine_use"
identifier="engine_admin"
weight="-70"
parent = "engine_admin"
weight = 0
+++
<![end-metadata]-->
# Configuring and running Docker on various distributions
After successfully installing Docker, the `docker` daemon runs with its default
configuration.
In a production environment, system administrators typically configure the
`docker` daemon to start and stop according to an organization's requirements. In most
cases, the system administrator configures a process manager such as `SysVinit`, `Upstart`,
or `systemd` to manage the `docker` daemon's start and stop.
### Running the docker daemon directly
The `docker` daemon can be run directly using the `dockerd` command. By default it listens on
the Unix socket `unix:///var/run/docker.sock`
$ dockerd
INFO[0000] +job init_networkdriver()
INFO[0000] +job serveapi(unix:///var/run/docker.sock)
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
...
...
### Configuring the docker daemon directly
If you're running the `docker` daemon directly by running `docker daemon` instead
of using a process manager, you can append the configuration options to the `docker` run
command directly. Other options can be passed to the `docker` daemon to configure it.
Some of the daemon's options are:
| Flag | Description |
|-----------------------|-----------------------------------------------------------|
| `-D`, `--debug=false` | Enable or disable debug mode. By default, this is false. |
| `-H`,`--host=[]` | Daemon socket(s) to connect to. |
| `--tls=false` | Enable or disable TLS. By default, this is false. |
Here is an example of running the `docker` daemon with configuration options:
$ dockerd -D --tls=true --tlscert=/var/docker/server.pem --tlskey=/var/docker/serverkey.pem -H tcp://192.168.59.3:2376
These options :
- Enable `-D` (debug) mode
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
- Listen for connections on `tcp://192.168.59.3:2376`
The command line reference has the [complete list of daemon flags](../reference/commandline/dockerd.md)
with explanations.
### Daemon debugging
As noted above, setting the log level of the daemon to "debug" or enabling debug mode
with `-D` allows the administrator or operator to gain much more knowledge about the
runtime activity of the daemon. If faced with a non-responsive daemon, the administrator
can force a full stack trace of all threads to be added to the daemon log by sending the
`SIGUSR1` signal to the Docker daemon. A common way to send this signal is using the `kill`
command on Linux systems. For example, `kill -USR1 <daemon-pid>` sends the `SIGUSR1`
signal to the daemon process, causing the stack dump to be added to the daemon log.
> **Note:** The log level setting of the daemon must be at least "info" level and above for
> the stack trace to be saved to the logfile. By default the daemon's log level is set to
> "info".
The daemon will continue operating after handling the `SIGUSR1` signal and dumping the stack
traces to the log. The stack traces can be used to determine the state of all goroutines and
threads within the daemon.
## Ubuntu
As of `14.04`, Ubuntu uses Upstart as a process manager. By default, Upstart jobs
are located in `/etc/init` and the `docker` Upstart job can be found at `/etc/init/docker.conf`.
After successfully [installing Docker for Ubuntu](../installation/linux/ubuntulinux.md),
you can check the running status using Upstart in this way:
$ sudo status docker
docker start/running, process 989
### Running Docker
You can start/stop/restart the `docker` daemon using
$ sudo start docker
$ sudo stop docker
$ sudo restart docker
### Configuring Docker
The instructions below depict configuring Docker on a system that uses `upstart`
as the process manager. As of Ubuntu 15.04, Ubuntu uses `systemd` as its process
manager. For Ubuntu 15.04 and higher, refer to [control and configure Docker with systemd](systemd.md).
You configure the `docker` daemon in the `/etc/default/docker` file on your
system. You do this by specifying values in a `DOCKER_OPTS` variable.
To configure Docker options:
1. Log into your host as a user with `sudo` or `root` privileges.
2. If you don't have one, create the `/etc/default/docker` file on your host. Depending on how
you installed Docker, you may already have this file.
3. Open the file with your favorite editor.
```
$ sudo vi /etc/default/docker
```
4. Add a `DOCKER_OPTS` variable with the following options. These options are appended to the
`docker` daemon's run command.
```
DOCKER_OPTS="-D --tls=true --tlscert=/var/docker/server.pem --tlskey=/var/docker/serverkey.pem -H tcp://192.168.59.3:2376"
```
These options :
- Enable `-D` (debug) mode
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
- Listen for connections on `tcp://192.168.59.3:2376`
The command line reference has the [complete list of daemon flags](../reference/commandline/dockerd.md)
with explanations.
5. Save and close the file.
6. Restart the `docker` daemon.
```
$ sudo restart docker
```
7. Verify that the `docker` daemon is running as specified with the `ps` command.
```
$ ps aux | grep docker | grep -v grep
```
### Logs
By default logs for Upstart jobs are located in `/var/log/upstart` and the logs for `docker` daemon
can be located at `/var/log/upstart/docker.log`
$ tail -f /var/log/upstart/docker.log
INFO[0000] Loading containers: done.
INFO[0000] Docker daemon commit=1b09a95-unsupported graphdriver=aufs version=1.11.0-dev
INFO[0000] +job acceptconnections()
INFO[0000] -job acceptconnections() = OK (0)
INFO[0000] Daemon has completed initialization
## CentOS / Red Hat Enterprise Linux / Fedora
As of `7.x`, CentOS and RHEL use `systemd` as the process manager. As of `21`, Fedora uses
`systemd` as its process manager.
After successfully installing Docker for [CentOS](../installation/linux/centos.md)/[Red Hat Enterprise Linux](../installation/linux/rhel.md)/[Fedora](../installation/linux/fedora.md), you can check the running status in this way:
$ sudo systemctl status docker
### Running Docker
You can start/stop/restart the `docker` daemon using
$ sudo systemctl start docker
$ sudo systemctl stop docker
$ sudo systemctl restart docker
If you want Docker to start at boot, you should also:
$ sudo systemctl enable docker
### Configuring Docker
For CentOS 7.x and RHEL 7.x you can [control and configure Docker with systemd](systemd.md).
Previously, for CentOS 6.x and RHEL 6.x you would configure the `docker` daemon in
the `/etc/sysconfig/docker` file on your system. You would do this by specifying
values in a `other_args` variable. For a short time in CentOS 7.x and RHEL 7.x you
would specify values in a `OPTIONS` variable. This is no longer recommended in favor
of using systemd directly.
For this section, we will use CentOS 7.x as an example to configure the `docker` daemon.
To configure Docker options:
1. Log into your host as a user with `sudo` or `root` privileges.
2. Create the `/etc/systemd/system/docker.service.d` directory.
```
$ sudo mkdir /etc/systemd/system/docker.service.d
```
3. Create a `/etc/systemd/system/docker.service.d/docker.conf` file.
4. Open the file with your favorite editor.
```
$ sudo vi /etc/systemd/system/docker.service.d/docker.conf
```
5. Override the `ExecStart` configuration from your `docker.service` file to customize
the `docker` daemon. To modify the `ExecStart` configuration you have to specify
an empty configuration followed by a new one as follows:
```
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -D --tls=true --tlscert=/var/docker/server.pem --tlskey=/var/docker/serverkey.pem -H tcp://192.168.59.3:2376
```
These options :
- Enable `-D` (debug) mode
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
- Listen for connections on `tcp://192.168.59.3:2376`
The command line reference has the [complete list of daemon flags](../reference/commandline/dockerd.md)
with explanations.
6. Save and close the file.
7. Flush changes.
```
$ sudo systemctl daemon-reload
```
8. Restart the `docker` daemon.
```
$ sudo systemctl restart docker
```
9. Verify that the `docker` daemon is running as specified with the `ps` command.
```
$ ps aux | grep docker | grep -v grep
```
### Logs
systemd has its own logging system called the journal. The logs for the `docker` daemon can
be viewed using `journalctl -u docker`
$ sudo journalctl -u docker
May 06 00:22:05 localhost.localdomain systemd[1]: Starting Docker Application Container Engine...
May 06 00:22:05 localhost.localdomain docker[2495]: time="2015-05-06T00:22:05Z" level="info" msg="+job serveapi(unix:///var/run/docker.sock)"
May 06 00:22:05 localhost.localdomain docker[2495]: time="2015-05-06T00:22:05Z" level="info" msg="Listening for HTTP on unix (/var/run/docker.sock)"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="+job init_networkdriver()"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="-job init_networkdriver() = OK (0)"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Loading containers: start."
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Loading containers: done."
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="Docker daemon commit=1b09a95-unsupported graphdriver=aufs version=1.11.0-dev"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="+job acceptconnections()"
May 06 00:22:06 localhost.localdomain docker[2495]: time="2015-05-06T00:22:06Z" level="info" msg="-job acceptconnections() = OK (0)"
_Note: Using and configuring journal is an advanced topic and is beyond the scope of this article._

80
docs/admin/live-restore.md Normal file
View file

@ -0,0 +1,80 @@
<!--[metadata]>
+++
title = "Keep containers alive during daemon downtime"
description = "How to keep containers running when the daemon isn't available."
keywords = ["docker, upgrade, daemon, dockerd, live-restore, daemonless container"]
[menu.main]
parent = "engine_admin"
weight="6"
+++
<![end-metadata]-->
# Keep containers alive during daemon downtime
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 containers remain
running if the daemon becomes unavailable. The live restore option helps reduce
container downtime due to daemon crashes, planned outages, or upgrades.
## Enable the live restore option
There are two ways to enable the live restore setting to keep containers alive
when the daemon becomes unavailable:
* If the daemon is already running and you don't want to stop it, you can add
the configuration to the daemon configuration file. For example, on a linux
system the default configuration file is `/etc/docker/daemon.json`.
Use your favorite editor to enable the `live-restore` option in the
`daemon.json`.
```bash
{
"live-restore": true
}
```
You have to send a `SIGHUP` signal to the daemon process for it to reload the
configuration. For more information on how to configure the Docker daemon using
config.json, see [daemon configuration file](../reference/commandline/dockerd.md#daemon-configuration-file)
* When you start the Docker daemon, pass the `--live-restore` flag:
```bash
$ sudo dockerd --live-restore
```
## Live restore during upgrades
The live restore feature supports restoring containers to the daemon for
upgrades from one minor release to the next. For example from Docker Engine
1.12.1 to 1.13.2.
If you skip releases during an upgrade, the daemon may not restore connection
the containers. If the daemon is unable restore connection, it ignores the
running containers and you must manage them manually. The daemon won't shut down
the disconnected containers.
## Live restore upon restart
The live restore option only works to restore the same set of daemon options
as the daemon had before it stopped. For example, live restore may not work if
the daemon restarts with a different bridge IP or a different graphdriver.
## Impact of live restore on running containers
A lengthy absence of the daemon can impact running containers. The containers
process writes to FIFO logs for daemon consumption. If the daemon is unavailable
to consume the output, the buffer will fill up and block further writes to the
log. A full log blocks the process until further space is available. The default
buffer size is typically 64K.
You must restart Docker to flush the buffers.
You can modify the kernel's buffer size by changing `/proc/sys/fs/pipe-max-size`.
## Live restore and swarm mode
The live restore option is not compatible with Docker Engine swarm mode. When
the Docker Engine runs in swarm mode, the orchestration feature manages tasks
and keeps containers running according to a service specification.

2
docs/admin/logging/index.md
View file

@ -7,7 +7,7 @@ keywords = [" docker, logging, driver"]
[menu.main]
parent = "engine_admin"
identifier = "smn_logging"
weight=8
weight=9
+++
<![end-metadata]-->

27
docs/admin/menu.md Normal file
View file

@ -0,0 +1,27 @@
<!-- [metadata]>
+++
title = "Admin Guide"
description = "Administer Docker"
keywords = ["Administer"]
type="menu"
[menu.main]
parent="engine_use"
identifier="engine_admin"
weight="-70"
+++
<![end-metadata]-->
# Admin Topics
* [Configuring and running Docker](index.md)
* [Automatically start containers](host_integration.md)
* [Keep containers alive during daemon downtime](live-restore.md)
* [Control and configure Docker with systemd](systemd.md)
* [Format command and log output](formatting.md)
* [Run a local registry mirror](registry_mirror.md)
* [PowerShell DSC Usage](dsc.md)
* [Using Chef](chef.md)
* [Using Puppet](puppet.md)
* [Using Supervisor with Docker](using_supervisord.md)
* [Runtime metrics](runmetrics.md)
* [Link via an ambassador container](ambassador_pattern_linking.md)

1
docs/admin/puppet.md
View file

@ -6,6 +6,7 @@ description = "Installing and using Puppet"
keywords = ["puppet, installation, usage, docker, documentation"]
[menu.main]
parent = "engine_admin"
weight="12"
+++
<![end-metadata]-->

2
docs/admin/runmetrics.md
View file

@ -6,7 +6,7 @@ description = "Measure the behavior of running containers"
keywords = ["docker, metrics, CPU, memory, disk, IO, run, runtime, stats"]
[menu.main]
parent = "engine_admin"
weight = 4
weight = 14
+++
<![end-metadata]-->

1
docs/admin/systemd.md
View file

@ -6,6 +6,7 @@ description = "Controlling and configuring Docker using systemd"
keywords = ["docker, daemon, systemd, configuration"]
[menu.main]
parent = "engine_admin"
weight="7"
+++
<![end-metadata]-->

1
docs/admin/using_supervisord.md
View file

@ -6,6 +6,7 @@ description = "How to use Supervisor process management with Docker"
keywords = ["docker, supervisor, process management"]
[menu.main]
parent = "engine_admin"
weight="13"
+++
<![end-metadata]-->

20
docs/deprecated.md
View file

@ -20,13 +20,13 @@ see [Feature Deprecation Policy](index.md#feature-deprecation-policy).
### Three argument form in `docker import`
**Deprecated In Release: [v0.6.7](https://github.com/docker/docker/releases/tag/v0.6.7)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
The `docker import` command format 'file|URL|- [REPOSITORY [TAG]]' is deprecated since November 2013. It's no more supported.
### `-h` shorthand for `--help`
**Deprecated In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Deprecated In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
**Target For Removal In Release: v1.15**
@ -53,7 +53,7 @@ The flag `--security-opt` doesn't use the colon separator(`:`) anymore to divide
**Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
The endpoint `/containers/(id or name)/copy` is deprecated in favor of `/containers/(id or name)/archive`.
@ -66,14 +66,14 @@ See the events API documentation for the new format.
### `-f` flag on `docker tag`
**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
To make tagging consistent across the various `docker` commands, the `-f` flag on the `docker tag` command is deprecated. It is not longer necessary to specify `-f` to move a tag from one image to another. Nor will `docker` generate an error if the `-f` flag is missing and the specified tag is already in use.
### HostConfig at API container start
**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
Passing an `HostConfig` to `POST /containers/{name}/start` is deprecated in favor of
defining it at container creation (`POST /containers/create`).
@ -82,14 +82,14 @@ defining it at container creation (`POST /containers/create`).
**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
The `docker ps --before` and `docker ps --since` options are deprecated.
Use `docker ps --filter=before=...` and `docker ps --filter=since=...` instead.
### Docker search 'automated' and 'stars' options
**Deprecated in Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Deprecated in Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
**Target For Removal In Release: v1.15**
@ -99,7 +99,7 @@ Use `docker search --filter=is-automated=...` and `docker search --filter=stars=
### Driver Specific Log Tags
**Deprecated In Release: [v1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
Log tags are now generated in a standard way across different logging drivers.
Because of which, the driver specific log tag options `syslog-tag`, `gelf-tag` and
@ -165,7 +165,7 @@ The following double-dash options are deprecated and have no replacement:
**Deprecated In Release: [v1.5.0](https://github.com/docker/docker/releases/tag/v1.5.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
The single-dash (`-help`) was removed, in favor of the double-dash `--help`
@ -180,7 +180,7 @@ Version 1.9 adds a flag (`--disable-legacy-registry=false`) which prevents the d
### Docker Content Trust ENV passphrase variables name change
**Deprecated In Release: [v1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
Since 1.9, Docker Content Trust Offline key has been renamed to Root key and the Tagging key has been renamed to Repository key. Due to this renaming, we're also changing the corresponding environment variables

4
docs/installation/binaries.md
View file

@ -118,7 +118,7 @@ For example:
> **Note** These instructions are for Docker Engine 1.11 and up. Engine 1.10 and
> under consists of a single binary, and instructions for those versions are
> different. To install version 1.10 or below, follow the instructions in the
> <a href="/v1.10/engine/installation/binaries/" target="_blank">1.10 documentation</a>.
> <a href="https://docs.docker.com/v1.10/engine/installation/binaries/" target="_blank">1.10 documentation</a>.
#### Install the Linux binaries
@ -217,7 +217,7 @@ For example:
> **Note** These instructions are for Engine 1.11 and up. Instructions for older
> versions are slightly different. To install version 1.10 or below, follow the
> instructions in the <a href="/v1.10/engine/installation/binaries/" target="_blank">1.10 documentation</a>.
> instructions in the <a href="https://docs.docker.com/v1.10/engine/installation/binaries/" target="_blank">1.10 documentation</a>.
## Giving non-root access

1
docs/reference/api/docker_remote_api_v1.22.md
View file

@ -507,7 +507,6 @@ Return low-level information on the container `id`
},
"Created": "2015-01-06T15:47:31.485331387Z",
"Driver": "devicemapper",
"ExecDriver": "native-0.2",
"ExecIDs": null,
"HostConfig": {
"Binds": null,

1
docs/reference/api/docker_remote_api_v1.23.md
View file

@ -530,7 +530,6 @@ Return low-level information on the container `id`
},
"Created": "2015-01-06T15:47:31.485331387Z",
"Driver": "devicemapper",
"ExecDriver": "native-0.2",
"ExecIDs": null,
"HostConfig": {
"Binds": null,

27
docs/reference/api/docker_remote_api_v1.24.md
View file

@ -553,7 +553,6 @@ Return low-level information on the container `id`
},
"Created": "2015-01-06T15:47:31.485331387Z",
"Driver": "devicemapper",
"ExecDriver": "native-0.2",
"ExecIDs": null,
"HostConfig": {
"Binds": null,
@ -3328,8 +3327,6 @@ Instruct the driver to remove the network (`id`).
### List nodes
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`GET /nodes`
@ -3458,8 +3455,6 @@ List nodes
### Inspect a node
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`GET /nodes/<id>`
@ -3580,8 +3575,6 @@ Return low-level information on the node `id`
### Initialize a new Swarm
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`POST /swarm/init`
@ -3654,8 +3647,6 @@ JSON Parameters:
### Join an existing Swarm
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`POST /swarm/join`
@ -3699,8 +3690,6 @@ JSON Parameters:
### Leave a Swarm
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`POST /swarm/leave`
@ -3723,8 +3712,6 @@ Leave a Swarm
### Update a Swarm
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`POST /swarm/update`
@ -3810,8 +3797,6 @@ JSON Parameters:
### List services
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`GET /services`
@ -3905,8 +3890,6 @@ List services
### Create a service
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`POST /services/create`
@ -4071,8 +4054,6 @@ JSON Parameters:
### Remove a service
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`DELETE /services/(id or name)`
@ -4094,8 +4075,6 @@ Stop and remove the service `id`
### Inspect one or more services
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`GET /services/(id or name)`
@ -4174,8 +4153,6 @@ Return information on the service `id`.
### Update a service
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`POST /services/(id or name)/update`
@ -4304,8 +4281,6 @@ Update the service `id`.
### List tasks
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`GET /tasks`
@ -4537,8 +4512,6 @@ List tasks
### Inspect a task
**Warning**: this endpoint is part of the Swarm management feature introduced in Docker 1.12, and
might be subject to non backward-compatible changes.
`GET /tasks/(task id)`

15
docs/reference/commandline/dockerd.md
View file

@ -56,7 +56,7 @@ Options:
--ipv6 Enable IPv6 networking
-l, --log-level=info Set the logging level
--label=[] Set key=value labels to the daemon
--live-restore Enable live restore of docker when containers are still running
--live-restore Enables keeping containers alive during daemon downtime
--log-driver=json-file Default driver for container logs
--log-opt=map[] Default log driver options for containers
--max-concurrent-downloads=3 Set the max concurrent downloads for each pull
@ -1003,14 +1003,14 @@ via flags. The docker daemon fails to start if an option is duplicated between
the file and the flags, regardless their value. We do this to avoid
silently ignore changes introduced in configuration reloads.
For example, the daemon fails to start if you set daemon labels
in the configuration file and also set daemon labels via the `--label` flag.
in the configuration file and also set daemon labels via the `--label` flag.
Options that are not present in the file are ignored when the daemon starts.
### Linux configuration file
The default location of the configuration file on Linux is
The default location of the configuration file on Linux is
`/etc/docker/daemon.json`. The `--config-file` flag can be used to specify a
non-default location.
non-default location.
This is a full example of the allowed configuration options on Linux:
@ -1025,6 +1025,7 @@ This is a full example of the allowed configuration options on Linux:
"storage-driver": "",
"storage-opts": [],
"labels": [],
"live-restore": true,
"log-driver": "",
"log-opts": [],
"mtu": 0,
@ -1087,7 +1088,7 @@ This is a full example of the allowed configuration options on Linux:
The default location of the configuration file on Windows is
`%programdata%\docker\config\daemon.json`. The `--config-file` flag can be
used to specify a non-default location.
used to specify a non-default location.
This is a full example of the allowed configuration options on Windows:
@ -1101,7 +1102,8 @@ This is a full example of the allowed configuration options on Windows:
"storage-driver": "",
"storage-opts": [],
"labels": [],
"log-driver": "",
"live-restore": true,
"log-driver": "",
"mtu": 0,
"pidfile": "",
"graph": "",
@ -1142,6 +1144,7 @@ The list of currently supported options that can be reconfigured is this:
- `cluster-store-opts`: it uses the new options to reload the discovery store.
- `cluster-advertise`: it modifies the address advertised after reloading.
- `labels`: it replaces the daemon labels with a new set of labels.
- `live-restore`: Enables [keeping containers alive during daemon downtime](../../admin/live-restore.md).
- `max-concurrent-downloads`: it updates the max concurrent downloads for each pull.
- `max-concurrent-uploads`: it updates the max concurrent uploads for each push.
- `default-runtime`: it updates the runtime to be used if not is

1
docs/reference/commandline/service_create.md
View file

@ -3,7 +3,6 @@
title = "service create"
description = "The service create command description and usage"
keywords = ["service, create"]
[menu.main]
parent = "smn_cli"
+++

1
docs/reference/commandline/swarm_join_token.md
View file

@ -3,7 +3,6 @@
title = "swarm join-token"
description = "The swarm join-token command description and usage"
keywords = ["swarm, join-token"]
advisory = "rc"
[menu.main]
parent = "smn_cli"
+++

11
docs/swarm/admin_guide.md
View file

@ -3,23 +3,22 @@
aliases = [
"/engine/swarm/manager-administration-guide/"
]
title = "Swarm Manager Administration Guide"
title = "Swarm administration guide"
description = "Manager administration guide"
keywords = ["docker, container, cluster, swarm, manager, raft"]
advisory = "rc"
[menu.main]
identifier="manager_admin_guide"
parent="engine_swarm"
weight="12"
weight="20"
+++
<![end-metadata]-->
# Administer and maintain a swarm of Docker Engines
When you run a swarm of Docker Engines, **manager nodes** are the key components
for managing the cluster and storing the cluster state. It is important to understand
some key features of manager nodes in order to properly deploy and maintain the
swarm.
for managing the cluster and storing the cluster state. It is important to
understand some key features of manager nodes in order to properly deploy and
maintain the swarm.
This article covers the following swarm administration tasks:

1
docs/swarm/how-swarm-mode-works/menu.md
View file

@ -3,7 +3,6 @@
title = "How swarm mode works"
description = "How the components of swarm mode work"
keywords = ["cluster, swarm"]
advisory = "rc"
[menu.main]
identifier="how-swarm-works"
parent="engine_swarm"

4
docs/swarm/how-swarm-mode-works/nodes.md
View file

@ -6,7 +6,6 @@ aliases = [
title = "How nodes work"
description = "How swarm nodes work"
keywords = ["docker, container, cluster, swarm mode, node"]
advisory = "rc"
[menu.main]
identifier="how-nodes-work"
parent="how-swarm-works"
@ -86,8 +85,7 @@ take a manager node offline for maintenance. See [node promote](../../reference/
You can also demote a manager node to a worker node. See
[node demote](../../reference/commandline/node_demote.md).
<!-- TODO For when How services work guide is ready
## What's Next
* Read about how swarm mode [services](services.md) work.
-->

97
docs/swarm/how-swarm-mode-works/services.md Normal file
View file

@ -0,0 +1,97 @@
<!--[metadata]>
+++
title = "How services work"
description = "How swarm mode services work"
keywords = ["docker, container, cluster, swarm mode, node"]
[menu.main]
identifier="how-services-work"
parent="how-swarm-works"
weight="4"
+++
<![end-metadata]-->
# How services work
To deploy an application image when Docker Engine is in swarm mode, you create a
service. Frequently a service will be the image for a microservice within the
context of some larger application. Examples of services might include an HTTP
server, a database, or any other type of executable program that you wish to run
in a distributed environment.
When you create a service, you specify which container image to use and which
commands to execute inside running containers. You also define options for the
service including:
* the port where the swarm will make the service available outside the swarm
* an overlay network for the service to connect to other services in the swarm
* CPU and memory limits and reservations
* a rolling update policy
* the number of replicas of the image to run in the swarm
## Services, tasks, and containers
When you deploy the service to the swarm, the swarm manager accepts your service
definition as the desired state for the service. Then it schedules the service
on nodes in the swarm as one or more replica tasks. The tasks run independently
of each other on nodes in the swarm.
For example, imagine you want to load balance between three instances of an HTTP
listener. The diagram below shows an HTTP listener service with three replicas.
Each of the three instances of the listener is a task in the swarm.
![services diagram](../images/services-diagram.png)
A container is an isolated process. In the swarm mode model, each task invokes
exactly one container. A task is analogous to a “slot” where the scheduler
places a container. Once the container is live, the scheduler recognizes that
the task is in a running state. If the container fails health checks or
terminates, the task terminates.
## Tasks and scheduling
A task is the atomic unit of scheduling within a swarm. When you declare a
desired service state by creating or updating a service, the orchestrator
realizes the desired state by scheduling tasks. For instance, the you define a
service that instructs the orchestrator to keep three instances of a HTTP
listener running at all times. The orchestrator responds by creating three
tasks. Each task is a slot that the scheduler fills by spawning a container. The
container is the instantiation of the task. If a HTTP listener task subsequently
fails its health check or crashes, the orchestrator creates a new replica task
that spawns a new container.
A task is a one-directional mechanism. It progresses monotonically through a
series of states: assigned, prepared, running, etc. If the task fails the
scheduler removes the task and its container and then creates a new task to
replace it according to the desired state specified by the service.
The underlying logic of Docker swarm mode is a general purpose scheduler and
orchestrator. The service and task abstractions themselves are unaware of the
containers they implement. Hypothetically, you could implement other types of
tasks such as virtual machine tasks or non-containerized process tasks. The
scheduler and orchestrator are agnostic about they type of task. However, the
current version of Docker only supports container tasks.
The diagram below shows how swarm mode accepts service create requests and
schedules tasks to worker nodes.
![services flow](../images/service-lifecycle.png)
## Replicated and global services
There are two types of service deployments, replicated and global.
For a replicated service, you specify the number of identical tasks you want to
run. For example, you decide to deploy an HTTP service with three replicas, each
serving the same content.
A global service is a service that runs one task on every node. There is no
pre-specified number of tasks. Each time you add a node to the swarm, the
orchestrator creates a task and the scheduler assigns the task to the new node.
Good candidates for global services are monitoring agents, an anti-virus
scanners or other types of containers that you want to run on every node in the
swarm.
The diagram below shows a three-service replica in yellow and a global service
in gray.
![global vs replicated services](../images/replicated-vs-global.png)

BIN
docs/swarm/images/replicated-vs-global.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 87 KiB

BIN
docs/swarm/images/service-lifecycle.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 136 KiB

BIN
docs/swarm/images/services-diagram.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 119 KiB

1
docs/swarm/images/src/replicated-vs-global.svg Normal file
View file

File diff suppressed because one or more lines are too long
Side by side

After

Width:  |  Height:  |  Size: 87 KiB

1
docs/swarm/images/src/service-lifecycle.svg Normal file
View file

File diff suppressed because one or more lines are too long
Side by side

After

Width:  |  Height:  |  Size: 66 KiB

1
docs/swarm/images/src/services-diagram.svg Normal file
View file

File diff suppressed because one or more lines are too long
Side by side

After

Width:  |  Height:  |  Size: 43 KiB

1
docs/swarm/images/src/simple-cluster.svg Normal file
View file

File diff suppressed because one or more lines are too long
Side by side

After

Width:  |  Height:  |  Size: 105 KiB

BIN
docs/swarm/images/swarm-diagram.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 126 KiB

After

Width:  |  Height:  |  Size: 179 KiB

1
docs/swarm/index.md
View file

@ -3,7 +3,6 @@
title = "Swarm mode overview"
description = "Docker Engine swarm mode overview"
keywords = ["docker, container, cluster, swarm"]
advisory = "rc"
[menu.main]
identifier="swarm_overview"
parent="engine_swarm"

1
docs/swarm/join-nodes.md
View file

@ -3,7 +3,6 @@
title = "Join nodes to a swarm"
description = "Add worker and manager nodes to a swarm"
keywords = ["guide, swarm mode, node"]
advisory = "rc"
[menu.main]
identifier="join-nodes-guide"
parent="engine_swarm"

1
docs/swarm/key-concepts.md
View file

@ -3,7 +3,6 @@
title = "Swarm mode key concepts"
description = "Introducing key concepts for Docker Engine swarm mode"
keywords = ["docker, container, cluster, swarm mode"]
advisory = "rc"
[menu.main]
identifier="swarm-mode-concepts"
parent="engine_swarm"

219
docs/swarm/manage-nodes.md Normal file
View file

@ -0,0 +1,219 @@
<!--[metadata]>
+++
title = "Manage nodes in a swarm"
description = "Manage existing nodes in a swarm"
keywords = ["guide, swarm mode, node"]
[menu.main]
identifier="manage-nodes-guide"
parent="engine_swarm"
weight=14
+++
<![end-metadata]-->
# Manage nodes in a swarm
As part of the swarm management lifecycle, you may need to view or update a node as follows:
* [list nodes in the swarm](#list-nodes)
* [inspect an individual node](#inspect-an-individual-node)
* [update a node](#update-a-node)
* [leave the swarm](#leave-the-swarm)
## List nodes
To view a list of nodes in the swarm run `docker node ls` from a manager node:
```bash
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
46aqrk4e473hjbt745z53cr3t node-5 Ready Active Reachable
61pi3d91s0w3b90ijw3deeb2q node-4 Ready Active Reachable
a5b2m3oghd48m8eu391pefq5u node-3 Ready Active
e7p8btxeu3ioshyuj6lxiv6g0 node-2 Ready Active
ehkv3bcimagdese79dn78otj5 * node-1 Ready Active Leader
```
The `AVAILABILITY` column shows whether or not the scheduler can assign tasks to
the node:
* `Active` means that the scheduler can assign tasks to a node.
* `Pause` means the scheduler doesn't assign new tasks to the node, but existing
tasks remain running.
* `Drain` means the scheduler doesn't assign new tasks to the node. The
scheduler shuts down any existing tasks and schedules them on an available
node.
The `MANAGER STATUS` column shows node participation in the Raft consensus:
* No value indicates a worker node that does not participate in swarm
management.
* `Leader` means the node is the primary manager node that makes all swarm
management and orchestration decisions for the swarm.
* `Reachable` means the node is a manager node is participating in the Raft
consensus. If the leader node becomes unavailable, the node is eligible for
election as the new leader.
* `Unavailable` means the node is a manager that is not able to communicate with
other managers. If a manager node becomes unavailable, you should either join a
new manager node to the swarm or promote a worker node to be a
manager.
For more information on swarm administration refer to the [Swarm administration guide](admin_guide.md).
## Inspect an individual node
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
docker node inspect self --pretty
ID: ehkv3bcimagdese79dn78otj5
Hostname: node-1
Status:
State: Ready
Availability: Active
Manager Status:
Address: 172.17.0.2:2377
Raft Status: Reachable
Leader: Yes
Platform:
Operating System: linux
Architecture: x86_64
Resources:
CPUs: 2
Memory: 1.954 GiB
Plugins:
Network: overlay, host, bridge, overlay, null
Volume: local
Engine Version: 1.12.0-dev
```
## Update a node
You can modify node attributes as follows:
* [change node availability](#change-node-availability)
* [add or remove label metadata](#add-or-remove-label-metadata)
* [change a node role](#promote-or-demote-a-node)
### Change node availability
Changing node availability lets you:
* drain a manager node so that only performs swarm management tasks and is
unavailable for task assignment.
* drain a node so you can take it down for maintenance.
* pause a node so it is unavailable to receive new tasks.
* restore unavailable or paused nodes available status.
For example, to change a manager node to `Drain` availability:
```bash
$ docker node update --availability drain node-1
node-1
```
See [list nodes](#list-nodes) for descriptions of the different availability
options.
### Add or remove label metadata
Node labels provide a flexible method of node organization. You can also use
node labels in service constraints. Apply constraints when you create a service
to limit the nodes where the scheduler assigns tasks for the service.
Run `docker node update --label-add` on a manager node to add label metadata to
a node. The `--label-add` flag supports either a `<key>` or a `<key>=<value>`
pair.
Pass the `--label-add` flag once for each node label you want to add:
```bash
$ docker node update --label-add foo --label-add bar=baz node-1
node-1
```
The labels you set for nodes using docker node update apply only to the node
entity within the swarm. Do not confuse them with the docker daemon labels for
[dockerd](../userguide/labels-custom-metadata.md#daemon-labels).
Refer to the `docker service create` [CLI reference](../reference/commandline/service_create.md)
for more information about service constraints.
### Promote or demote a node
You can promote a worker node to the manager role. This is useful when a
manager node becomes unavailable or if you want to take a manager offline for
maintenance. Similarly, you can demote a manager node to the worker role.
Regardless of your reason to promote or demote a node, you should always
maintain an odd number of manager nodes in the swarm. For more information refer
to the [Swarm administration guide](admin_guide.md).
To promote a node or set of nodes, run `docker node promote` from a manager
node:
```bash
$ docker node promote node-3 node-2
Node node-3 promoted to a manager in the swarm.
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
$ docker node demote node-3 node-2
Manager node-3 demoted in the swarm.
Manager node-2 demoted in the swarm.
```
`docker node promote` and `docker node demote` are convenience commands for
`docker node update --role manager` and `docker node update --role worker`
respectively.
## Leave the swarm
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
$ docker swarm leave
Node left the swarm.
```
When a node leaves the swarm, the Docker Engine stops running in swarm
mode. The orchestrator no longer schedules tasks to the node.
If the node is a manager node, you will receive a warning about maintaining the
quorum. To override the warning, pass the `--force` flag. If the last manager
node leaves the swarm, the swarm becomes unavailable requiring you to take
disaster recovery measures.
For information about maintaining a quorum and disaster recovery, refer to the
[Swarm administration guide](admin_guide.md).
After a node leaves the swarm, you can run the `docker node rm` command on a
manager node to remove the node from the node list.
For instance:
```bash
docker node rm node-2
node-2
```
## Learn More
* [Swarm administration guide](admin_guide.md)
* [Docker Engine command line reference](../reference/commandline/index.md)
* [Swarm mode tutorial](swarm-tutorial/index.md)

8
docs/swarm/menu.md
View file

@ -1,9 +1,9 @@
<!--[metadata]>
+++
title = "Manage a Swarm (1.12 RC)"
description = "How to use Docker Swarm to create and manage Docker Engine clusters"
title = "Manage a swarm"
description = "How to use Docker Engine swarm mode"
keywords = [" docker, documentation, developer, "]
advisory = "rc"
type = "menu"
[menu.main]
identifier = "engine_swarm"
parent = "engine_use"
@ -12,7 +12,7 @@ weight = 0
<![end-metadata]-->
## Use Docker Swarm to create and manage clusters of Docker Engine called Swarms
## Use Docker Engine to create and manage a swarm
This section contains the following topics:

3
docs/swarm/raft.md
View file

@ -3,11 +3,10 @@
title = "Raft consensus in swarm mode"
description = "Raft consensus algorithm in swarm mode"
keywords = ["docker, container, cluster, swarm, raft"]
advisory = "rc"
[menu.main]
identifier="raft"
parent="engine_swarm"
weight="13"
weight="21"
+++
<![end-metadata]-->

1
docs/swarm/swarm-mode.md
View file

@ -3,7 +3,6 @@
title = "Run Docker Engine in swarm mode"
description = "Run Docker Engine in swarm mode"
keywords = ["guide, swarm mode, node"]
advisory = "rc"
[menu.main]
identifier="initialize-swarm-guide"
parent="engine_swarm"

1
docs/swarm/swarm-tutorial/add-nodes.md
View file

@ -3,7 +3,6 @@
title = "Add nodes to the swarm"
description = "Add nodes to the swarm"
keywords = ["tutorial, cluster management, swarm"]
advisory = "rc"
[menu.main]
identifier="add-nodes"
parent="swarm-tutorial"

1
docs/swarm/swarm-tutorial/create-swarm.md
View file

@ -3,7 +3,6 @@
title = "Create a swarm"
description = "Initialize the swarm"
keywords = ["tutorial, cluster management, swarm mode"]
advisory = "rc"
[menu.main]
identifier="initialize-swarm"
parent="swarm-tutorial"

1
docs/swarm/swarm-tutorial/delete-service.md
View file

@ -3,7 +3,6 @@
title = "Delete the service"
description = "Remove the service from the swarm"
keywords = ["tutorial, cluster management, swarm, service"]
advisory = "rc"
[menu.main]
identifier="swarm-tutorial-delete-service"
parent="swarm-tutorial"

1
docs/swarm/swarm-tutorial/deploy-service.md
View file

@ -3,7 +3,6 @@
title = "Deploy a service"
description = "Deploy a service to the swarm"
keywords = ["tutorial, cluster management, swarm mode"]
advisory = "rc"
[menu.main]
identifier="deploy-application"
parent="swarm-tutorial"

1
docs/swarm/swarm-tutorial/drain-node.md
View file

@ -3,7 +3,6 @@
title = "Drain a node"
description = "Drain nodes on the Swarm"
keywords = ["tutorial, cluster management, swarm, service, drain"]
advisory="rc"
[menu.main]
identifier="swarm-tutorial-drain-node"
parent="swarm-tutorial"

1
docs/swarm/swarm-tutorial/index.md
View file

@ -3,7 +3,6 @@
title = "Set up for the tutorial"
description = "Getting Started tutorial for Docker Engine swarm mode"
keywords = ["tutorial, cluster management, swarm mode"]
advisory = "rc"
[menu.main]
identifier="tutorial-setup"
parent="swarm-tutorial"

1
docs/swarm/swarm-tutorial/inspect-service.md
View file

@ -3,7 +3,6 @@
title = "Inspect the service"
description = "Inspect the application"
keywords = ["tutorial, cluster management, swarm mode"]
advisory = "rc"
[menu.main]
identifier="inspect-application"
parent="swarm-tutorial"

2
docs/swarm/swarm-tutorial/menu.md
View file

@ -3,7 +3,7 @@
title = "Get started with swarm mode"
description = "Getting started tutorial for Docker swarm mode"
keywords = ["cluster, swarm, tutorial"]
advisory = "rc"
type="menu"
[menu.main]
identifier="swarm-tutorial"
parent="engine_swarm"

1
docs/swarm/swarm-tutorial/rolling-update.md
View file

@ -3,7 +3,6 @@
title = "Apply rolling updates"
description = "Apply rolling updates to a service on the Swarm"
keywords = ["tutorial, cluster management, swarm, service, rolling-update"]
advisory = "rc"
[menu.main]
identifier="swarm-tutorial-rolling-update"
parent="swarm-tutorial"

1
docs/swarm/swarm-tutorial/scale-service.md
View file

@ -3,7 +3,6 @@
title = "Scale the service"
description = "Scale the service running in the swarm"
keywords = ["tutorial, cluster management, swarm mode, scale"]
advisory = "rc"
[menu.main]
identifier="swarm-tutorial-scale-service"
parent="swarm-tutorial"

2
docs/userguide/networking/default_network/custom-docker0.md
View file

@ -20,7 +20,7 @@ Docker configures `docker0` with an IP address, netmask and IP allocation range.
- `--bip=CIDR` -- supply a specific IP address and netmask for the `docker0` bridge, using standard CIDR notation like `192.168.1.5/24`.
- `--fixed-cidr=CIDR` -- restrict the IP range from the `docker0` subnet, using the standard CIDR notation like `172.167.1.0/28`. This range must be an IPv4 range for fixed IPs (ex: 10.20.0.0/16) and must be a subset of the bridge IP range (`docker0` or set using `--bridge`). For example with `--fixed-cidr=192.168.1.0/25`, IPs for your containers will be chosen from the first half of `192.168.1.0/24` subnet.
- `--fixed-cidr=CIDR` -- restrict the IP range from the `docker0` subnet, using the standard CIDR notation like `172.16.1.0/28`. This range must be an IPv4 range for fixed IPs (ex: 10.20.0.0/16) and must be a subset of the bridge IP range (`docker0` or set using `--bridge`). For example with `--fixed-cidr=192.168.1.0/25`, IPs for your containers will be chosen from the first half of `192.168.1.0/24` subnet.
- `--mtu=BYTES` -- override the maximum packet length on `docker0`.