diff --git a/engine/swarm/admin_guide.md b/engine/swarm/admin_guide.md index f7b4396109..1f7314bdec 100644 --- a/engine/swarm/admin_guide.md +++ b/engine/swarm/admin_guide.md @@ -185,7 +185,7 @@ manager: - Restart the daemon and see if the manager comes back as reachable. - Reboot the machine. -- If neither restarting or rebooting work, you should add another manager node or promote a worker to be a manager node. You also need to cleanly remove the failed node entry from the manager set with `docker node demote ` and `docker node rm `. +- If neither restarting nor rebooting works, you should add another manager node or promote a worker to be a manager node. You also need to cleanly remove the failed node entry from the manager set with `docker node demote ` and `docker node rm `. Alternatively you can also get an overview of the swarm health from a manager node with `docker node ls`: @@ -207,8 +207,8 @@ You should never restart a manager node by copying the `raft` directory from ano To cleanly re-join a manager node to a cluster: -1. To demote the node to a worker, run `docker node demote `. -2. To remove the node from the swarm, run `docker node rm `. +1. Demote the node to a worker using `docker node demote `. +2. Remove the node from the swarm using `docker node rm `. 3. Re-join the node to the swarm with a fresh state using `docker swarm join`. For more information on joining a manager node to a swarm, refer to @@ -318,7 +318,7 @@ restore the data to a new swarm. ### Recover from losing the quorum -Swarm is resilient to failures and the swarm can recover from any number +Swarm is resilient to failures and can recover from any number of temporary node failures (machine reboots or crash with restart) or other transient errors. However, a swarm cannot automatically recover if it loses a quorum. Tasks on existing worker nodes continue to run, but administrative diff --git a/engine/swarm/how-swarm-mode-works/services.md b/engine/swarm/how-swarm-mode-works/services.md index 7236a3011f..7365e00451 100644 --- a/engine/swarm/how-swarm-mode-works/services.md +++ b/engine/swarm/how-swarm-mode-works/services.md @@ -52,7 +52,7 @@ 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 +series of states: assigned, prepared, running, etc. If the task fails, the orchestrator removes the task and its container and then creates a new task to replace it according to the desired state specified by the service. @@ -60,7 +60,7 @@ 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 the type of task. However, the +scheduler and orchestrator are agnostic about the type of the task. However, the current version of Docker only supports container tasks. The diagram below shows how swarm mode accepts service create requests and @@ -109,9 +109,8 @@ 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. +Good candidates for global services are monitoring agents, 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. diff --git a/engine/swarm/index.md b/engine/swarm/index.md index d06c92fa04..88f022eda3 100644 --- a/engine/swarm/index.md +++ b/engine/swarm/index.md @@ -91,7 +91,7 @@ services. The swarm manager automatically assigns addresses to the containers on the overlay network when it initializes or updates the application. * **Service discovery:** Swarm manager nodes assign each service in the swarm a -unique DNS name and load balances running containers. You can query every +unique DNS name and load balance running containers. You can query every container running in the swarm through a DNS server embedded in the swarm. * **Load balancing:** You can expose the ports for services to an diff --git a/engine/swarm/key-concepts.md b/engine/swarm/key-concepts.md index 41c110f775..0942f4fd33 100644 --- a/engine/swarm/key-concepts.md +++ b/engine/swarm/key-concepts.md @@ -22,13 +22,13 @@ define its optimal state (number of replicas, network and storage resources available to it, ports the service exposes to the outside world, and more). Docker works to maintain that desired state. For instance, if a worker node becomes unavailable, Docker schedules that node's tasks on other nodes. A _task_ -is a running container which is part of a swarm service and managed by a swarm -manager, as opposed to a standalone container. +is a running container which is part of a swarm service and is managed by a +swarm manager, as opposed to a standalone container. One of the key advantages of swarm services over standalone containers is that you can modify a service's configuration, including the networks and volumes it is connected to, without the need to manually restart the service. Docker will -update the configuration, stop the service tasks with the out of date +update the configuration, stop the service tasks with out of date configuration, and create new ones matching the desired configuration. When Docker is running in swarm mode, you can still run standalone containers @@ -41,7 +41,7 @@ workers, or both. In the same way that you can use [Docker Compose](../../compose/index.md) to define and run containers, you can define and run [Swarm service](services.md) stacks. -Keep reading for details about concepts relating to Docker swarm services, +Keep reading for details about concepts related to Docker swarm services, including nodes, services, tasks, and load balancing. ## Nodes diff --git a/engine/swarm/networking.md b/engine/swarm/networking.md index 274a09470c..f488b1618d 100644 --- a/engine/swarm/networking.md +++ b/engine/swarm/networking.md @@ -220,12 +220,12 @@ The default mask length can be configured and is the same for all networks. It i ##### Overlay network size limitations -Docker recommends creating overlay networks with `/24` blocks. The `/24` overlay network blocks, which limits the network to 256 IP addresses. +Docker recommends creating overlay networks with `/24` blocks. The `/24` overlay network blocks limit the network to 256 IP addresses. This recommendation addresses [limitations with swarm mode](https://github.com/moby/moby/issues/30820). If you need more than 256 IP addresses, do not increase the IP block size. You can either use `dnsrr` endpoint mode with an external load balancer, or use multiple smaller overlay networks. See -[Configure service discovery](#configure-service-discovery) or more information about different endpoint modes. +[Configure service discovery](#configure-service-discovery) for more information about different endpoint modes. #### Configure encryption of application data diff --git a/engine/swarm/raft.md b/engine/swarm/raft.md index f28f1b0518..494e7addc7 100644 --- a/engine/swarm/raft.md +++ b/engine/swarm/raft.md @@ -8,7 +8,7 @@ When the Docker Engine runs in swarm mode, manager nodes implement the [Raft Consensus Algorithm](http://thesecretlivesofdata.com/raft/) to manage the global cluster state. The reason why *Docker swarm mode* is using a consensus algorithm is to make sure that -all the manager nodes that are in charge of managing and scheduling tasks in the cluster, +all the manager nodes that are in charge of managing and scheduling tasks in the cluster are storing the same consistent state. Having the same consistent state across the cluster means that in case of a failure, diff --git a/engine/swarm/secrets.md b/engine/swarm/secrets.md index d82b1237ee..ce6e8fe16e 100644 --- a/engine/swarm/secrets.md +++ b/engine/swarm/secrets.md @@ -926,10 +926,8 @@ use it, then remove the old secret. ``` -7. If you want to try the running all of these examples again or just want to - clean up after running through them, use these commands to remove the - WordPress service, the MySQL container, the `mydata` and `wpdata` volumes, - and the Docker secrets. +7. Run the following commands to remove the WordPress service, the MySQL container, + the `mydata` and `wpdata` volumes, and the Docker secrets: ```console $ docker service rm wordpress mysql @@ -1021,7 +1019,7 @@ content from the file specified in the compose file. The db service uses both secrets, and the wordpress is using one. When you deploy, Docker mounts a file under `/run/secrets/` in the -services. These files are never persisted in disk, but are managed in memory. +services. These files are never persisted on disk, but are managed in memory. Each service uses environment variables to specify where the service should look for that secret data. diff --git a/engine/swarm/services.md b/engine/swarm/services.md index ce4785ddfc..a6dc1d71e7 100644 --- a/engine/swarm/services.md +++ b/engine/swarm/services.md @@ -45,7 +45,7 @@ a3iixnklxuem quizzical_lamarr replicated 1/1 Created services do not always run right away. A service can be in a pending state if its image is unavailable, if no node meets the requirements you -configure for the service, or other reasons. See +configure for the service, or for other reasons. See [Pending services](how-swarm-mode-works/services.md#pending-services) for more information. @@ -125,7 +125,7 @@ nodes are able to log into the registry and pull the image. Credential spec files are applied at runtime, eliminating the need for host-based credential spec files or registry entries - no gMSA credentials are written to disk on worker nodes. You can make credential specs available to Docker Engine running swarm kit worker nodes before a container starts. When deploying a service using a gMSA-based config, the credential spec is passed directly to the runtime of containers in that service. - The `--credential-spec` must be one of the following formats: + The `--credential-spec` must be in one of the following formats: - `file://`: The referenced file must be present in the `CredentialSpecs` subdirectory in the docker data directory, which defaults to `C:\ProgramData\Docker\` on Windows. For example, specifying `file://spec.json` loads `C:\ProgramData\Docker\CredentialSpecs\spec.json`. - `registry://`: The credential spec is read from the Windows registry on the daemon’s host. @@ -804,7 +804,7 @@ that the scheduler updates simultaneously. When an update to an individual task returns a state of `RUNNING`, the scheduler continues the update by continuing to another task until all tasks are updated. -If, at any time during an update a task returns `FAILED`, the scheduler pauses +If at any time during an update a task returns `FAILED`, the scheduler pauses the update. You can control the behavior using the `--update-failure-action` flag for `docker service create` or `docker service update`. @@ -830,7 +830,7 @@ after 10% of the tasks being updated fail, the update is paused. An individual task update is considered to have failed if the task doesn't start up, or if it stops running within the monitoring period specified with the `--update-monitor` flag. The default value for `--update-monitor` is 30 -seconds, which means that a task failing in the first 30 seconds after its +seconds, which means that a task failing in the first 30 seconds after it's started counts towards the service update failure threshold, and a failure after that is not counted. @@ -843,7 +843,7 @@ to the configuration that was in place before the most recent `docker service update` command. Other options can be combined with `--rollback`; for example, -`--update-delay 0s` to execute the rollback without a delay between tasks: +`--update-delay 0s`, to execute the rollback without a delay between tasks: ```console $ docker service update \ @@ -893,8 +893,8 @@ $ docker service create --name=my_redis \ ### Give a service access to volumes or bind mounts For best performance and portability, you should avoid writing important data -directly into a container's writable layer, instead using data volumes or bind -mounts. This principle also applies to services. +directly into a container's writable layer. You should instead use data volumes +or bind mounts. This principle also applies to services. You can create two types of mounts for services in a swarm, `volume` mounts or `bind` mounts. Regardless of which type of mount you use, configure it using the @@ -920,7 +920,7 @@ $ docker service create \ ``` -If a volume with the same `` does not exist when a task is +If a volume with the name `` doesn't exist when a task is scheduled to a particular host, then one is created. The default volume driver is `local`. To use a different volume driver with this create-on-demand pattern, specify the driver and its options with the `--mount` flag: diff --git a/engine/swarm/swarm-mode.md b/engine/swarm/swarm-mode.md index d9c8ee3a2c..d9952bdec0 100644 --- a/engine/swarm/swarm-mode.md +++ b/engine/swarm/swarm-mode.md @@ -88,13 +88,13 @@ The format of the command is: $ docker swarm init --default-addr-pool [--default-addr-pool --default-addr-pool-mask-length ] ``` -To create a default IP address pool with a /16 (class B) for the 10.20.0.0 network looks like this: +The command to create a default IP address pool with a /16 (class B) for the 10.20.0.0 network looks like this: ```console $ docker swarm init --default-addr-pool 10.20.0.0/16 ``` -To create a default IP address pool with a `/16` (class B) for the `10.20.0.0` and `10.30.0.0` networks, and to +The command to create a default IP address pool with a `/16` (class B) for the `10.20.0.0` and `10.30.0.0` networks, and to create a subnet mask of `/26` for each network looks like this: ```console diff --git a/engine/swarm/swarm-tutorial/create-swarm.md b/engine/swarm/swarm-tutorial/create-swarm.md index 5c69c26b5e..6c0b490e18 100644 --- a/engine/swarm/swarm-tutorial/create-swarm.md +++ b/engine/swarm/swarm-tutorial/create-swarm.md @@ -73,7 +73,7 @@ machines. The `*` next to the node ID indicates that you're currently connected on this node. - Docker Engine swarm mode automatically names the node for the machine host + Docker Engine swarm mode automatically names the node with the machine host name. The tutorial covers other columns in later steps. ## What's next? diff --git a/engine/swarm/swarm-tutorial/rolling-update.md b/engine/swarm/swarm-tutorial/rolling-update.md index b3c28c2f46..867ba1f5fc 100644 --- a/engine/swarm/swarm-tutorial/rolling-update.md +++ b/engine/swarm/swarm-tutorial/rolling-update.md @@ -40,7 +40,7 @@ Redis 3.0.7 container image using rolling updates. By default, when an update to an individual task returns a state of `RUNNING`, the scheduler schedules another task to update until all tasks - are updated. If, at any time during an update a task returns `FAILED`, the + are updated. If at any time during an update a task returns `FAILED`, the scheduler pauses the update. You can control the behavior using the `--update-failure-action` flag for `docker service create` or `docker service update`. diff --git a/engine/swarm/swarm_manager_locking.md b/engine/swarm/swarm_manager_locking.md index 5b9c7467a9..2647f43711 100644 --- a/engine/swarm/swarm_manager_locking.md +++ b/engine/swarm/swarm_manager_locking.md @@ -10,7 +10,7 @@ access to the encrypted Raft logs. One of the reasons this feature was introduce was in support of the [Docker secrets](secrets.md) feature. 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 has the ability to protect the mutual TLS encryption key and the key used to encrypt and decrypt Raft logs at rest, by allowing you to take ownership of these keys and to require manual unlocking of