Fix long titles and long slides in Swarm content

dockerbay · Nov 10, 2017 · 9df543a · 9df543a
1 parent 77befc1
commit 9df543a
Show file tree

Hide file tree

Showing 18 changed files with 65 additions and 53 deletions.
diff --git a/slides/common/prereqs.md b/slides/common/prereqs.md
@@ -163,7 +163,7 @@ If anything goes wrong — ask for help!
 
 ---
 
-## If doing or re-doing the workshop on your own ...
+## Doing or re-doing the workshop on your own?
 
 - Use something like
   [Play-With-Docker](http://play-with-docker.com/) or

diff --git a/slides/swarm/btp-manual.md b/slides/swarm/btp-manual.md
@@ -1,4 +1,4 @@
-## Build, tag, and push our application container images
+## Build, tag, and push our container images
 
 - Compose has named our images `dockercoins_XXX` for each service
 
@@ -246,7 +246,7 @@ You should see the performance peaking at 10 hashes/s (like before).
 
 class: extra-details
 
-## Why do we have to re-create the service to enable global scheduling?
+## Why do we have to re-create the service?
 
 - State reconciliation is handled by a *controller*
 

diff --git a/slides/swarm/creatingswarm.md b/slides/swarm/creatingswarm.md
@@ -226,7 +226,7 @@ class: extra-details
   docker node ls
   ```
 
-<!-- Ignore errors: ```wait not a swarm manager``` -->
+<!-- Ignore errors: .dummy[```wait not a swarm manager```] -->
 
 - This is because the node that we added is currently a *worker*
 - Only *managers* can accept Swarm-specific commands
@@ -239,10 +239,9 @@ class: extra-details
 
 .exercise[
 
-- Switch back to `node1`:
-  ```keys
-  ^D
-  ```
+- Switch back to `node1` (with `exit`, `Ctrl-D` ...)
+
+<!-- ```keys ^D``` -->
 
 - View the cluster from `node1`, which is a manager:
   ```bash
@@ -258,7 +257,6 @@ ID             HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
 ehb0...4fvx    node2     Ready   Active
 ```
 
-
 ---
 
 class: under-the-hood

diff --git a/slides/swarm/encryptionatrest.md b/slides/swarm/encryptionatrest.md
@@ -74,7 +74,7 @@ that you [provisioned yourself](https://github.com/jpetazzo/container.training/t
 
 ---
 
-## Checking the state of the node programmatically
+## Checking node state in scripts
 
 - The state of the node shows up in the output of `docker info`
 

diff --git a/slides/swarm/extratips.md b/slides/swarm/extratips.md
@@ -159,7 +159,9 @@ docker node update <node-name> --availability <active|pause|drain>
 
 ---
 
-## Disk space management: `docker system df`
+## Viewing disk usage: `docker system df`
+
+*(New in Docker Engine 1.13)*
 
 - Shows disk usage for images, containers, and volumes
 
@@ -174,11 +176,9 @@ docker node update <node-name> --availability <active|pause|drain>
 
 ]
 
-Note: `docker system` is new in Docker Engine 1.13.
-
 ---
 
-## Reclaiming unused resources: `docker system prune`
+## Cleaning up disk: `docker system prune`
 
 - Removes stopped containers
 

diff --git a/slides/swarm/firstservice.md b/slides/swarm/firstservice.md
@@ -370,19 +370,23 @@ class: btw-labels
 
 class: extra-details
 
-## Using local networks (`host`, `macvlan` ...) with Swarm services
+## Using local networks (`host`, `macvlan` ...)
+
+- It is possible to connect services to local networks
 
 - Using the `host` network is fairly straightforward
 
   (With the caveats described on the previous slide)
 
-- It is also possible to use drivers like `macvlan`
+- Other network drivers are a bit more complicated
+
+  (IP allocation may have to be coordinated between nodes)
 
-  - see [this guide](
-https://docs.docker.com/engine/userguide/networking/get-started-macvlan/
-) to get started on `macvlan`
+- See for instance [this guide](
+  https://docs.docker.com/engine/userguide/networking/get-started-macvlan/
+  ) to get started on `macvlan`
 
-  - see [this PR](https://github.com/moby/moby/pull/32981) for more information about local network drivers in Swarm mode
+- See [this PR](https://github.com/moby/moby/pull/32981) for more information about local network drivers in Swarm mode
 
 ---
 

diff --git a/slides/swarm/healthchecks.md b/slides/swarm/healthchecks.md
@@ -65,6 +65,7 @@ name: healthchecks
 
 Here is a comprehensive example using the CLI:
 
+.sall[
 ```bash
 docker service update \
   --update-delay 5s \
@@ -80,9 +81,9 @@ docker service update \
   --health-cmd "curl -f http://localhost/ || exit 1" \
   --health-interval 2s \
   --health-retries 1 \
-  --image yourimage:newversion \
-  yourservice
+  --image yourimage:newversion yourservice
 ```
+]
 
 ---
 
@@ -176,9 +177,7 @@ And now, a breaking change that will cause the health check to fail:
 
 ---
 
-## Command-line options available for health checks, rollbacks, etc.
-
-Batteries included, but swappable
+## CLI flags for health checks and rollbacks
 
 .small[
 ```
@@ -207,5 +206,3 @@ Batteries included, but swappable
 --update-parallelism uint            Maximum number of tasks updated simultaneously (0 to update all at once)
 ```
 ]
-
-Yup ... That's a lot of batteries!
diff --git a/slides/swarm/ipsec.md b/slides/swarm/ipsec.md
@@ -36,7 +36,7 @@
 
 ---
 
-## Deploying a web server sitting on both networks
+## Deploying a dual-homed web server
 
 - Let's use good old NGINX
 

diff --git a/slides/swarm/leastprivilege.md b/slides/swarm/leastprivilege.md
@@ -34,7 +34,7 @@
 
 ---
 
-## Guidelines for workload isolation leveraging least privilege model
+## Guidelines for workload isolation
 
 - Define security levels
 

diff --git a/slides/swarm/machine.md b/slides/swarm/machine.md
@@ -90,7 +90,7 @@ class: in-person
 
 ---
 
-## Using Docker Machine to communicate with a node
+## Selecting a node with Docker Machine
 
 - To select a node, use `eval $(docker-machine env nodeX)`
 

diff --git a/slides/swarm/metrics.md b/slides/swarm/metrics.md
@@ -1053,10 +1053,11 @@ class: prom-manual
 
 class: prom-manual
 
-## Configuring the Prometheus server
+## Prometheus server configuration
 
 This will be our configuration file for Prometheus:
 
+.small[
 ```yaml
 global:
   scrape_interval: 10s
@@ -1075,14 +1076,13 @@ scrape_configs:
         type: 'A'
         port: 8080
 ```
+]
 
 ---
 
 class: prom-manual
 
-## Passing the configuration to the Prometheus server
-
-- We need to provide our custom configuration to the Prometheus server
+## Passing the configuration to Prometheus
 
 - The easiest solution is to create a custom image bundling this configuration
 
@@ -1237,9 +1237,9 @@ class: prom-auto, config
 
 ## Deploying Prometheus with a `config`
 
-- The `config` can be created manually or declared in the Compose file
-
-- This is what our new Compose file looks like:
+The following Compose file (`prometheus+config.yml`) achieves
+the same result, but by using a `config` instead of baking the
+configuration into the image.
 
 .small[
 ```yaml
@@ -1263,8 +1263,6 @@ configs:
 ```
 ]
 
-(This is from `prometheus+config.yml`)
-
 ---
 
 class: prom-auto, config
@@ -1312,9 +1310,9 @@ class: prom-auto, config
 
 class: prom-auto, config
 
-## Accessing the config object from the Docker CLI
+## Accessing the config object from the CLI
 
-- Config objects can be viewed from the CLI (or API)
+- Config objects can be viewed from the Docker CLI (or API)
 
 .exercise[
 

diff --git a/slides/swarm/morenodes.md b/slides/swarm/morenodes.md
@@ -83,7 +83,7 @@ class: in-person
 
 ---
 
-## You can control the Swarm from any manager node
+## Controlling the Swarm from other nodes
 
 .exercise[
 

diff --git a/slides/swarm/netshoot.md b/slides/swarm/netshoot.md
@@ -334,7 +334,7 @@ WHY?!?
 
 class: extra-details, benchmarking
 
-## Why did we sprinkle this sample app with sleeps?
+## Why did we sprinkle the code with sleeps?
 
 - Deterministic performance
   <br/>(regardless of instance speed, CPUs, I/O...)

diff --git a/slides/swarm/stateful.md b/slides/swarm/stateful.md
@@ -162,7 +162,7 @@ This ensures consistent behavior.
 
 ---
 
-## Service updates cause containers to be replaced
+## Updating a service recreates its containers
 
 - Let's try to make a trivial update to the service and see what happens
 
@@ -247,7 +247,7 @@ Note: the `local` volume driver automatically creates volumes.
 
 ---
 
-## Checking that persistence actually works across service updates
+## Checking that data is now persisted correctly
 
 .exercise[
 

diff --git a/slides/swarm/swarmmode.md b/slides/swarm/swarmmode.md
@@ -1,8 +1,8 @@
-# Swarm Mode
+# Swarm mode
 
-- Since version 1.12, Docker Engine embeds SwarmKit
+- Since version 1.12, the Docker Engine embeds SwarmKit
 
-- All the SwarmKit features are "asleep" until you enable "Swarm Mode"
+- All the SwarmKit features are "asleep" until you enable "Swarm mode"
 
 - Examples of Swarm Mode commands:
 
@@ -20,11 +20,11 @@
 
 ---
 
-## You need to enable Swarm mode to use the new stuff
+## Swarm mode needs to be explicitly activated
 
 - By default, all this new code is inactive
 
-- Swarm Mode can be enabled, "unlocking" SwarmKit functions
+- Swarm mode can be enabled, "unlocking" SwarmKit functions
   <br/>(services, out-of-the-box overlay networks, etc.)
 
 .exercise[

diff --git a/slides/swarm/swarmnbt.md b/slides/swarm/swarmnbt.md
@@ -1,6 +1,6 @@
 class: nbt, extra-details
 
-## Measuring network conditions on the whole cluster
+## Measuring cluster-wide network conditions
 
 - Since we have built-in, cluster-wide discovery, it's relatively straightforward
   to monitor the whole cluster automatically

diff --git a/slides/swarm/swarmready.md b/slides/swarm/swarmready.md
@@ -25,7 +25,7 @@ What did we change to make it compatible with Swarm mode?
 
 ---
 
-## What did we change in our app since its inception?
+## Which files have been changed since then?
 
 - Compose files
 

diff --git a/slides/swarm/updatingservices.md b/slides/swarm/updatingservices.md
@@ -49,7 +49,7 @@
 
 ---
 
-## Updating the web UI
+## Changing the code
 
 - Let's make the numbers on the Y axis bigger!
 
@@ -75,6 +75,21 @@
 
 - Save and exit
 
+]
+
+---
+
+## Build, ship, and run our changes
+
+- Four steps:
+
+  1. Set (and export!) the `TAG` environment variable
+  2. `docker-compose build`
+  3. `docker-compose push`
+  4. `docker stack deploy`
+
+.exercise[
+
 - Build, ship, and run:
   ```bash
   export TAG=v0.3