Advisory: See Swarm mode overview for the orchestration features introduced in Docker Engine 1.12. Only refer to the Docker Swarm documents below for information on the standalone Swarm product.
Prerequisite: Before using
manage to create a Swarm manager, establish a discovery backend as described in this discovery topic.
manage command creates a Swarm manager whose purpose is to receive commands on behalf of the cluster and assign containers to Swarm nodes. You can create multiple Swarm managers as part of a high-availability cluster.
To create a Swarm manager, use the following syntax:
$ docker run swarm manage [OPTIONS] <discovery>
For example, you can use
manage to create a Swarm manager in a high-availability cluster with other managers:
$ docker run -d -p 4000:4000 swarm manage -H :4000 --replication --advertise 172.30.0.161:4000 consul://172.30.0.165:8500
Or, for example, you can use it to create a Swarm manager that uses Transport Layer Security (TLS) to authenticate the Docker Client and Swarm nodes:
$ docker run -d -p 3376:3376 -v /home/ubuntu/.certs:/certs:ro swarm manage --tlsverify --tlscacert=/certs/ca.pem --tlscert=/certs/cert.pem --tlskey=/certs/key.pem --host=0.0.0.0:3376 token://$TOKEN
manage command has only one argument:
<discovery>— Discovery backend
When you create the swarm node, use the
<discovery> argument to specify one of the following discovery backends:
<token> is a discovery token generated by Docker Hub’s hosted discovery service. To generate this discovery token, use the
> Warning: Docker Hub’s hosted discovery backend is not recommended for production use. It’s intended only for testing/development.
ip3 are each the IP address and port numbers of a discovery backend node.
path (optional) is a path to a key-value store on the discovery backend. When you use a single backend to service multiple clusters, you use paths to maintain separate key-value stores for each cluster.
path/to/file is the path to a file that contains a static list of the Swarm managers and nodes that are members the cluster.
iprange is an IP address or a range of IP addresses followed by a port number.
Here are a pair of
<discovery> argument examples:
The environment variable for
For more information and examples, see the Docker Swarm Discovery topic.
manage command has the following options:
--strategy— Scheduler placement strategy
--strategy "<value>" to tell the Docker Swarm scheduler which placement strategy to use.
spread— Assign each container to the Swarm node with the most available resources.
binpack- Assign containers to one Swarm node until it is full before assigning them to another one.
random- Assign each container to a random Swarm node.
By default, the scheduler applies the
For more information and examples, see Docker Swarm strategies.
-f— Scheduler filter
--filter <value> or
-f <value> to tell the Docker Swarm scheduler which nodes to use when creating and running a container.
health— Use nodes that are running and communicating with the discovery backend.
port— For containers that have a static port mapping, use nodes whose corresponding port number is available (i.e., not occupied by another container or process).
dependency— For containers that have a declared dependency, use nodes that already have a container with the same dependency.
affinity— For containers that have a declared affinity, use nodes that already have a container with the same affinity.
constraint— For containers that have a declared constraint, use nodes that already have a container with the same constraint.
You can use multiple scheduler filters, like this:
--filter <value> --filter <value>
For more information and examples, see Swarm filters.
-H— Listen to IP/port
--host <ip>:<port> or
-H <ip>:<port> to specify the IP address and port number to which the manager listens for incoming messages. If you replace
<ip> with zeros or omit it altogether, the manager uses the default host IP. For example,
The environment variable for
--replication— Enable Swarm manager replication
Enable Swarm manager replication between the primary and secondary managers in a high-availability cluster. Replication mirrors cluster information from the primary to the secondary managers so that, if the primary manager fails, a secondary can become the primary manager.
--replication-ttl— Leader lock release time on failure
--replication-ttl "<delay>s" to specify the delay, in seconds, before notifying secondary managers that the primary manager is down or unreachable. This notification triggers an election in which one of the secondary managers becomes the primary manager. By default, the delay is 15 seconds.
--addr— Advertise Docker Engine’s IP and port number
--advertise <ip>:<port> or
--addr <ip>:<port> to advertise the IP address and port number of the Docker Engine. For example,
--advertise 172.30.0.161:4000. Other Swarm managers MUST be able to reach this Swarm manager at this address.
The environment variable for
--tls— Enable transport layer security (TLS)
--tls to enable transport layer security (TLS). If you use
--tlsverify, you do not need to use
--tlscacert— Path to a CA’s public key file
--tlscacert=<path/file> to specify the path and filename of the public key (certificate) from a Certificate Authority (CA). For example,
--tlscacert=/certs/ca.pem. When specified, the manager trusts only remotes that provide a certificate signed by the same CA.
--tlscert— Path to the node’s TLS certificate file
--tlscert to specify the path and filename of the manager’s certificate (signed by the CA). For example,
--tlskey— Path to the node’s TLS key file
--tlskey to specify the path and filename of the manager’s private key (signed by the CA). For example,
--tlsverify— Use TLS and verify the remote
--tlsverify to enable transport layer security (TLS) and accept connections from only those managers, nodes, and clients that have a certificate signed by the same CA. If you use
--tlsverify, you do not need to use
--engine-refresh-min-interval— Set engine refresh minimum interval
--engine-refresh-min-interval "<interval>s" to specify the minimum interval, in seconds, between Engine refreshes. By default, the interval is 30 seconds.
When the primary manager in performs an Engine refresh, it gets updated information about an Engine in the cluster. The manager uses this information to, among other things, determine whether the Engine is healthy. If there is a connection failure, the manager determines that the node is unhealthy. The manager retries an Engine refresh a specified number of times. If the Engine responds to one of the retries, the manager determines that the Engine is healthy again. Otherwise, the manager stops retrying and ignores the Engine.
--engine-refresh-max-interval— Set engine refresh maximum interval
--engine-refresh-max-interval "<interval>s" to specify the minimum interval, in seconds, between Engine refresh. By default, the interval is 60 seconds.
--engine-failure-retry— Set engine failure retry count
--engine-failure-retry "<number>" to specify the number of retries to attempt if the engine fails. By default, the number is 3 retries.
--engine-failure-retry instead of
--engine-refresh-retry "<number>". The default number is 3 retries.
--heartbeat— Period between each heartbeat
--heartbeat "<interval>s" to specify the interval, in seconds, between heartbeats the manager sends to the primary manager. These heartbeats indicate that the manager is healthy and reachable. By default, the interval is 60 seconds.
--cors— Enable CORS headers in the remote API
--cors to enable cross-origin resource sharing (CORS) headers in the remote API.
-c— Cluster driver to use
-c "<driver>" to specify a cluster driver to use. Where
<driver> is one of the following:
swarmis the Docker Swarm driver.
mesos-experimentalis the Mesos cluster driver.
By default, the driver is
For more information about using Mesos driver, see Using Docker Swarm and Mesos.
--cluster-opt— Cluster driver options
You can enter multiple cluster driver options, like this:
--cluster-opt <value> --cluster-opt <value>
<value> is one of the following:
swarm.overcommit=0.05— Set the fractional percentage by which to overcommit resources. The default value is
0.05, or 5 percent.
swarm.createretry=0— Specify the number of retries to attempt when creating a container fails. The default value is
mesos.address=— Specify the Mesos address to bind on. The environment variable for this option is
mesos.checkpointfailover=false— Enable Mesos checkpointing, which allows a restarted slave to reconnect with old executors and recover status updates, at the cost of disk I/O. The environment variable for this option is
$SWARM_MESOS_CHECKPOINT_FAILOVER. The default value is
mesos.port=— Specify the Mesos port to bind on. The environment variable for this option is
mesos.offertimeout=30s— Specify the Mesos timeout for offers, in seconds. The environment variable for this option is
$SWARM_MESOS_OFFER_TIMEOUT. The default value is
mesos.offerrefusetimeout=5s— Specify timeout for Mesos to consider unused resources refused, in seconds. The environment variable for this option is
$SWARM_MESOS_OFFER_REFUSE_TIMEOUT. The default value is
mesos.tasktimeout=5s— Specify the timeout for Mesos task creation, in seconds. The environment variable for this option is
$SWARM_MESOS_TASK_TIMEOUT. The default value is
mesos.user=— Specify the Mesos framework user name. The environment variable for this option is
--discovery-opt— Discovery options
--discovery-opt <value> to discovery options, such as paths to the TLS files; the CA’s public key certificate, the certificate, and the private key of the distributed K/V store on a Consul or etcd discovery backend. You can enter multiple discovery options. For example:
--discovery-opt kv.cacertfile=/path/to/mycacert.pem \ --discovery-opt kv.certfile=/path/to/mycert.pem \ --discovery-opt kv.keyfile=/path/to/mykey.pem \
For more information, see Use TLS with distributed key/value discovery