From ce1dffa58aaa881db0f5b41ee5032f259acaa303 Mon Sep 17 00:00:00 2001 From: Ken Cochrane Date: Wed, 13 Apr 2016 09:44:32 -0400 Subject: [PATCH] Fixed more typos in the docs Signed-off-by: Ken Cochrane --- docs/configure-tls.md | 3 +-- docs/install-manual.md | 2 +- docs/plan-for-production.md | 2 +- docs/swarm_at_scale/04-deploy-app.md | 2 +- 4 files changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/configure-tls.md b/docs/configure-tls.md index 75e8db93ff..83ee7e09f7 100644 --- a/docs/configure-tls.md +++ b/docs/configure-tls.md @@ -72,14 +72,13 @@ LTS. In this step, you configure a Linux server as a CA. You use this CA to create and sign keys. This step included so that readers without access to an existing -CA (external or corpoate) and certificates can follow along and complete the +CA (external or corporate) and certificates can follow along and complete the later steps that require installing and using certificates. It is `not` intended as a model for how to deploy production-worthy CA. 1. Logon to the terminal of your CA server and elevate to root. $ sudo su - # 2. Create a private key called `ca-priv-key.pem` for the CA: diff --git a/docs/install-manual.md b/docs/install-manual.md index a3cd1f2ce1..679d3de81c 100644 --- a/docs/install-manual.md +++ b/docs/install-manual.md @@ -86,7 +86,7 @@ From your AWS home console, do the following: ## Step 2. Create your instances In this step, you create five Linux hosts that are part of your default security -gorup. When complete, the example deployment contains three types of nodes: +group. When complete, the example deployment contains three types of nodes: | Node Description | Name | |--------------------------------------|-------------------------| diff --git a/docs/plan-for-production.md b/docs/plan-for-production.md index efe6a4fbe1..6efc65c355 100644 --- a/docs/plan-for-production.md +++ b/docs/plan-for-production.md @@ -306,7 +306,7 @@ network bandwidth. If your Swarm nodes are balanced across multiple failure domains, the spread strategy evenly balance containers across those failure domains. However, spread on its own is not aware of the roles of any of those containers, so has -no inteligence to spread multiple instances of the same service across failure +no intelligence to spread multiple instances of the same service across failure domains. To achieve this you should use tags and constraints. The **binpack** strategy runs as many containers as possible on a node, diff --git a/docs/swarm_at_scale/04-deploy-app.md b/docs/swarm_at_scale/04-deploy-app.md index 3523016800..4b39e08015 100644 --- a/docs/swarm_at_scale/04-deploy-app.md +++ b/docs/swarm_at_scale/04-deploy-app.md @@ -84,7 +84,7 @@ repository](https://github.com/docker/swarm-microservice-demo-v1). requirements, copies files from the build context into the container, exposes port `80` and tells the container which command to run. -5. Spend time investigating the other parts of the application by viewing the `results-app/Dockefile` and the `vote-worker/Dockerfile` in the application. +5. Spend time investigating the other parts of the application by viewing the `results-app/Dockerfile` and the `vote-worker/Dockerfile` in the application. ## Step 2. Build custom images