github/container.training
1
0
Fork 0
mirror of https://github.com/jpetazzo/container.training.git synced 2026-07-28 09:11:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix long titles and long slides in Swarm content

Browse Source
This commit is contained in:
Jérôme Petazzoni
2017-11-09 19:58:55 -08:00
parent 77befc1092
commit 9df543a6bb
18 changed files with 65 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
slides/common/prereqs.md
View File

@@ -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

4
slides/swarm/btp-manual.md
View File

@@ -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*

10
slides/swarm/creatingswarm.md
View File

@@ -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

2
slides/swarm/encryptionatrest.md
View File

@@ -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`

8
slides/swarm/extratips.md
View File

@@ -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

16
slides/swarm/firstservice.md
View File

@@ -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
- see [this guide](
https://docs.docker.com/engine/userguide/networking/get-started-macvlan/
) to get started on `macvlan`
(IP allocation may have to be coordinated between nodes)
- see [this PR](https://github.com/moby/moby/pull/32981) for more information about local network drivers in Swarm mode
- 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
---

11
slides/swarm/healthchecks.md
View File

@@ -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!

2
slides/swarm/ipsec.md
View File

@@ -36,7 +36,7 @@
---
## Deploying a web server sitting on both networks
## Deploying a dual-homed web server
- Let's use good old NGINX

2
slides/swarm/leastprivilege.md
View File

@@ -34,7 +34,7 @@
---
## Guidelines for workload isolation leveraging least privilege model
## Guidelines for workload isolation
- Define security levels

2
slides/swarm/machine.md
View File

@@ -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)`

20
slides/swarm/metrics.md
View File

@@ -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[

2
slides/swarm/morenodes.md
View File

@@ -83,7 +83,7 @@ class: in-person
---
## You can control the Swarm from any manager node
## Controlling the Swarm from other nodes
.exercise[

2
slides/swarm/netshoot.md
View File

@@ -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...)

4
slides/swarm/stateful.md
View File

@@ -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[

10
slides/swarm/swarmmode.md
View File

@@ -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[

2
slides/swarm/swarmnbt.md
View File

@@ -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

2
slides/swarm/swarmready.md
View File

@@ -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

17
slides/swarm/updatingservices.md
View File

@@ -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