From 30fd53a3e1a3f5dc7599c87a13199fdac69f7d0f Mon Sep 17 00:00:00 2001 From: AJ Bowen Date: Wed, 25 Oct 2017 21:05:46 +0200 Subject: [PATCH] Setup is a noun; set up is a verb. Fix some more typos. --- docs/concepts-k8s.md | 2 +- docs/daemonset.md | 6 +++--- docs/firstservice.md | 2 +- docs/kubectlrun.md | 4 ++-- docs/kubenet.md | 2 +- docs/metrics.md | 6 +++--- docs/operatingswarm.md | 2 +- docs/setup-k8s.md | 12 ++++++------ docs/whatsnext.md | 6 +++--- 9 files changed, 21 insertions(+), 21 deletions(-) diff --git a/docs/concepts-k8s.md b/docs/concepts-k8s.md index d669f410..65043800 100644 --- a/docs/concepts-k8s.md +++ b/docs/concepts-k8s.md @@ -92,7 +92,7 @@ class: pic (Courtesy of [Yongbok Kim](https://www.yongbok.net/blog/)) -- The second one is an good simplified representation of a Kubernetes cluster +- The second one is a simplified representation of a Kubernetes cluster (Courtesy of [Imesh Gunaratne](https://medium.com/containermind/a-reference-architecture-for-deploying-wso2-middleware-on-kubernetes-d4dee7601e8e)) diff --git a/docs/daemonset.md b/docs/daemonset.md index 62c9ce14..0ba2b4b0 100644 --- a/docs/daemonset.md +++ b/docs/daemonset.md @@ -164,7 +164,7 @@ We have both `deploy/rng` and `ds/rng` now! -- -And one too many pod ... +And one too many pods... --- @@ -215,9 +215,9 @@ It appears that *all the pods* are serving requests at the moment. ## The magic of selectors -- The `rng` *service* is load balancing requests to a set of pod +- The `rng` *service* is load balancing requests to a set of pods -- This set of pod is defined as "pods having the label `run=rng`" +- This set of pods is defined as "pods having the label `run=rng`" .exercise[ diff --git a/docs/firstservice.md b/docs/firstservice.md index 6549be88..f6d29fc5 100644 --- a/docs/firstservice.md +++ b/docs/firstservice.md @@ -316,7 +316,7 @@ class: btw-labels - If you want to place multiple HTTP services on port 80, you need something more -- You can setup NGINX or HAProxy on port 80 to do the virtual host switching +- You can set up NGINX or HAProxy on port 80 to do the virtual host switching - Docker Universal Control Plane provides its own [HTTP routing mesh]( https://docs.docker.com/datacenter/ucp/2.1/guides/admin/configure/use-domain-names-to-access-services/) diff --git a/docs/kubectlrun.md b/docs/kubectlrun.md index bf26b011..405c0057 100644 --- a/docs/kubectlrun.md +++ b/docs/kubectlrun.md @@ -29,7 +29,7 @@ -- -OK, what did just happen? +OK, what just happened? --- @@ -196,7 +196,7 @@ We could! But the *deployment* would notice it right away, and scale back to the ## What if we wanted something different? -- What if we wanted to start a "one-shot" container, that *does not* get restarted? +- What if we wanted to start a "one-shot" container that *doesn't* get restarted? - We could use `kubectl run --restart=OnFailure` or `kubectl run --restart=Never` diff --git a/docs/kubenet.md b/docs/kubenet.md index a75a413d..504a69b3 100644 --- a/docs/kubenet.md +++ b/docs/kubenet.md @@ -63,7 +63,7 @@ ## Kubernetes network model: in practice -- The nodes that we are using have been setup to use Weave +- The nodes that we are using have been set up to use Weave - We don't endorse Weave in a particular way, it just Works For Us diff --git a/docs/metrics.md b/docs/metrics.md index b0a0f7fd..00909ddc 100644 --- a/docs/metrics.md +++ b/docs/metrics.md @@ -902,7 +902,7 @@ class: snap, prom - Leave that tab open! -- We are going to setup *another* metrics system +- We are going to set up *another* metrics system - ... And then compare both graphs side by side @@ -1495,9 +1495,9 @@ class: prom, snap ## Comparing Snap and Prometheus data -- If you haven't setup Snap, InfluxDB, and Grafana, skip this section +- If you haven't set up Snap, InfluxDB, and Grafana, skip this section -- If you have closed the Grafana tab, you might have to re-setup a new dashboard +- If you have closed the Grafana tab, you might have to re-set up a new dashboard (Unless you saved it before navigating it away) diff --git a/docs/operatingswarm.md b/docs/operatingswarm.md index 66567029..8c81c921 100644 --- a/docs/operatingswarm.md +++ b/docs/operatingswarm.md @@ -20,7 +20,7 @@ The following exercises assume that you have a 5-nodes Swarm cluster. If you come here from a previous tutorial and still have your cluster: great! -Otherwise: check [part 1](#part-1) to learn how to setup your own cluster. +Otherwise: check [part 1](#part-1) to learn how to set up your own cluster. We pick up exactly where we left you, so we assume that you have: diff --git a/docs/setup-k8s.md b/docs/setup-k8s.md index ac3fbd0d..1bccce18 100644 --- a/docs/setup-k8s.md +++ b/docs/setup-k8s.md @@ -1,6 +1,6 @@ # Setting up Kubernetes -- How did we setup these Kubernetes clusters that we're using? +- How did we set up these Kubernetes clusters that we're using? -- @@ -12,7 +12,7 @@ 3. Run `kubeadm init` on the master node - 4. Setup Weave (the overlay network) + 4. Set up Weave (the overlay network)
(that step is just one `kubectl apply` command; discussed later) @@ -24,19 +24,19 @@ ## `kubeadm` drawbacks -- Doesn't setup Docker or any other container engine +- Doesn't set up Docker or any other container engine -- Doesn't setup the overlay network +- Doesn't set up the overlay network - Scripting is complex
(because extracting the token requires advanced `kubectl` commands) -- Doesn't setup multi-master (no high availability) +- Doesn't set up multi-master (no high availability) -- -- It's still twice as much steps as setting up a Swarm cluster 😕 +- It's still twice as many steps as setting up a Swarm cluster 😕 --- diff --git a/docs/whatsnext.md b/docs/whatsnext.md index 713cb70b..67734b02 100644 --- a/docs/whatsnext.md +++ b/docs/whatsnext.md @@ -11,9 +11,9 @@ Suggested containerization checklist: - write Dockerfiles for the other (buildable) services - write a Compose file for that whole app - make sure that devs are empowered to run the app in containers -- setup automated builds of container images from the code repo -- setup a CI pipeline using these container images -- setup a CD pipeline (for staging/QA) using these images +- set up automated builds of container images from the code repo +- set up a CI pipeline using these container images +- set up a CD pipeline (for staging/QA) using these images ] And *then* it is time to look at orchestration!