Backporting Devoxx updates

docs/index.html

@@ -125,12 +125,6 @@ on time, it's a good idea to have a breakfast with the attendees
 at e.g. 9am, and start at 9:30.
 -->
 
----
-
-class: in-person
-
-## Agenda
-
 <!--
 - Agenda:
 -->
@@ -517,7 +511,7 @@ You are welcome to use the method that you feel the most comfortable with.
 
 - Engine 17.03
 - Compose 1.11
-- Machine 0.9
+- Machine 0.10
 
 .exercise[
 
@@ -591,7 +585,7 @@ Let's do this.
 
 name: part-1
 
-class: title
+class: title, self-paced
 
 Part 1
 
@@ -1803,11 +1797,11 @@ As we saw earlier, you can only control the Swarm through a manager node.
 
 - Node status icons are displayed left of the node name
 
-- No icon = no Swarm mode detected
+  - No icon = no Swarm mode detected
+  - Solid blue icon = Swarm manager detected
+  - Blue outline icon = Swarm worker detected
 
-- Solid blue icon = Swarm manager detected
-
-- Blue outline icon = Swarm worker detected
+![Play-With-Docker icons](pwd-icons.png)
 
 ---
 
@@ -1915,7 +1909,7 @@ As we saw earlier, you can only control the Swarm through a manager node.
   docker service create alpine ping 8.8.8.8
   ```
 
-- Check where the container was created:
+- Check the result:
   ```bash
   docker service ps <serviceID>
   ```
@@ -1924,16 +1918,29 @@ As we saw earlier, you can only control the Swarm through a manager node.
 
 ---
 
-## Checking container logs
+## Checking service logs
 
-- Right now, there is no direct way to check the logs of our container
-  <br/>(unless it was scheduled on the current node)
+- Docker 1.13/17.03 has `docker service logs`, but it's an experimental feature
+  <br/>(available only when enabling the experimental feature flag)
 
-- Look up the `NODE` on which the container is running
-  <br/>(in the output of the `docker service ps` command)
+- We have to use `docker logs`, which only works on local containers
+
+- We will have to connect to the node running our container
+  <br/>(unless it was scheduled locally, of course)
+
+---
+
+## Looking up where our container is running
+
+- The `docker service ps` command told us where our container was scheduled
 
 .exercise[
 
+- Look up the `NODE` on which the container is running:
+  ```bash
+  docker service ps <serviceID>
+  ```
+
 - If you use Play-With-Docker, switch to that node's tab, or set `DOCKER_HOST`
 
 - Otherwise, `ssh` into tht node or use `$(eval docker-machine env node...)`
@@ -2662,7 +2669,7 @@ Note: if the hash rate goes to zero and doesn't climb back up, try to `rm` and `
 
 - This might change in the future (after all, it was possible in 1.12 RC!)
 
-- As of Docker Engine 1.13, other parameters requiring to `rm`/`create` the service are:
+- As of Docker Engine 17.03, other parameters requiring to `rm`/`create` the service are:
 
   - service name
 
@@ -3257,14 +3264,22 @@ See [this documentation page](https://docs.docker.com/compose/extends/) for more
 
 ---
 
+class: title, in-person
+
+Operating the Swarm
+
+---
+
 name: part-2
 
-class: title
+class: title, self-paced
 
 Part 2
 
 ---
 
+class: self-paced
+
 ## Before we start ...
 
 The following exercises assume that you have a 5-nodes Swarm cluster.
@@ -3285,6 +3300,8 @@ The next slide has a cheat sheet if you need to set that up in a pinch.
 
 ---
 
+class: self-paced
+
 ## Catching up
 
 Assuming you have 5 nodes provided by
@@ -3340,8 +3357,8 @@ You should now be able to connect to port 8000 and see the DockerCoins web UI.
 
 - Start a "do nothing" container using our favorite Swiss-Army distro:
   ```bash
-    docker service create --network dockercoins_default --name debug --mode global \
-           alpine sleep 1000000000
+    docker service create --network dockercoins_default --name debug \
+           --mode global alpine sleep 1000000000
   ```
 
 ]
@@ -3992,6 +4009,8 @@ Note: if you updated the roll-out parallelism, *rollback* will not rollback to t
 
 ---
 
+class: swarmctl
+
 ## Getting task information for a given node
 
 - You can see all the tasks assigned to a node with `docker node ps`
@@ -4006,6 +4025,8 @@ Note: if you updated the roll-out parallelism, *rollback* will not rollback to t
 
 ---
 
+class: swarmctl
+
 ## Getting cluster-wide task information
 
 - The Docker API doesn't expose this directly (yet)
@@ -4023,6 +4044,8 @@ Note: if you updated the roll-out parallelism, *rollback* will not rollback to t
 
 ---
 
+class: swarmctl
+
 ## Building `swarmctl`
 
 - We are going to install a Go compiler, then download SwarmKit source and build it
@@ -4046,6 +4069,8 @@ the build might fail. In that case, just skip the `swarmctl` section.
 
 ---
 
+class: swarmctl
+
 ## Using `swarmctl`
 
 - The Docker Engine places the SwarmKit control socket in a special path
@@ -4066,6 +4091,8 @@ the build might fail. In that case, just skip the `swarmctl` section.
 
 ---
 
+class: swarmctl
+
 ## `swarmctl` in action
 
 - Let's review a few useful `swarmctl` commands
@@ -4086,6 +4113,8 @@ the build might fail. In that case, just skip the `swarmctl` section.
 
 ---
 
+class: swarmctl
+
 ## Caveat
 
 - SwarmKit is vendored into the Docker Engine
@@ -4101,6 +4130,8 @@ Error: grpc: failed to unmarshal the received message proto: wrong wireType = 0
 
 ---
 
+class: secrets
+
 # Secrets management and encryption at rest
 
 (New in Docker Engine 1.13)
@@ -4120,6 +4151,8 @@ Error: grpc: failed to unmarshal the received message proto: wrong wireType = 0
 
 ---
 
+class: secrets
+
 ## Secret management
 
 - Docker has a "secret safe" (secure key→value store)
@@ -4136,6 +4169,8 @@ Error: grpc: failed to unmarshal the received message proto: wrong wireType = 0
 
 ---
 
+class: secrets
+
 ## Creating secrets
 
 - Must specify a name for the secret; and the secret itself
@@ -4155,6 +4190,8 @@ If the secret is in a file, you can simply pass the path to the file.
 
 ---
 
+class: secrets
+
 ## Creating better secrets
 
 - Picking lousy passwords always leads to security breaches
@@ -4172,6 +4209,8 @@ Note: in the latter case, we don't even know the secret at this point. But Swarm
 
 ---
 
+class: secrets
+
 ## Using secrets
 
 - Secrets must be handed explicitly to services
@@ -4192,6 +4231,8 @@ We use a global service to make sure that there will be an instance on the local
 
 ---
 
+class: secrets
+
 ## Accessing secrets
 
 - Secrets are materialized on `/run/secrets` (which is an in-memory filesystem)
@@ -4214,6 +4255,8 @@ We use a global service to make sure that there will be an instance on the local
 
 ---
 
+class: secrets
+
 ## Rotating secrets
 
 - You can't change a secret
@@ -4233,6 +4276,8 @@ We use a global service to make sure that there will be an instance on the local
 
 ---
 
+class: secrets
+
 ## Changing our insecure password
 
 - We want to replace our `hackme` secret with a better one
@@ -4256,6 +4301,8 @@ Wait for the service to be fully updated with e.g. `watch docker service ps dumm
 
 ---
 
+class: secrets
+
 ## Checking that our password is now stronger
 
 - We will use the power of `docker exec`!
@@ -4276,6 +4323,8 @@ Wait for the service to be fully updated with e.g. `watch docker service ps dumm
 
 ---
 
+class: secrets
+
 ## Secrets in practice
 
 - Can be (ab)used to hold whole configuration files if needed
@@ -4343,6 +4392,8 @@ A few solutions, by increasing order of flexibility:
 
 ---
 
+class: encryption-at-rest
+
 ## Encryption at rest
 
 - Swarm data is always encrypted
@@ -4363,6 +4414,8 @@ A few solutions, by increasing order of flexibility:
 
 ---
 
+class: encryption-at-rest
+
 ## Locking a Swarm cluster
 
 - This is achieved through the `docker swarm update` command
@@ -4380,6 +4433,8 @@ This will display the unlock key. Copy-paste it somewhere safe.
 
 ---
 
+class: encryption-at-rest
+
 ## Locked state
 
 - If we restart a manager, it will now be locked
@@ -4398,6 +4453,8 @@ that you [provisioned yourself](https://github.com/jpetazzo/orchestration-worksh
 
 ---
 
+class: encryption-at-rest
+
 ## Checking that our node is locked
 
 - Manager commands (requiring access to crypted data) will fail
@@ -4419,6 +4476,8 @@ that you [provisioned yourself](https://github.com/jpetazzo/orchestration-worksh
 
 ---
 
+class: encryption-at-rest
+
 ## Checking the state of the node programmatically
 
 - The state of the node shows up in the output of `docker info`
@@ -4439,6 +4498,8 @@ that you [provisioned yourself](https://github.com/jpetazzo/orchestration-worksh
 
 ---
 
+class: encryption-at-rest
+
 ## Unlocking a node
 
 - You will need the secret token that we obtained when enabling auto-lock earlier
@@ -4461,6 +4522,8 @@ that you [provisioned yourself](https://github.com/jpetazzo/orchestration-worksh
 
 ---
 
+class: encryption-at-rest
+
 ## Managing the secret key
 
 - If the key is compromised, you can change it and re-encrypt with a new key:
@@ -4480,6 +4543,8 @@ Note: if somebody steals both your disks and your key, .strike[you're doomed! Do
 
 ---
 
+class: encryption-at-rest
+
 ## Unlocking the cluster permanently
 
 - If you want to remove the secret key, disable auto-lock