mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-28 09:11:18 +00:00
Add LISA tutorial
This commit is contained in:
Jérôme Petazzoni
@@ -347,6 +347,9 @@ Some presentations from the Docker Distributed Systems Summit in Berlin:
|
||||
|
||||
And DockerCon Black Belt talks:
|
||||
|
||||
.blackbelt[[Everything You Thought You Already Knew About Orchestration](https://www.youtube.com/watch?v=Qsv-q8WbIZY&list=PLkA60AVN3hh-biQ6SCtBJ-WVTyBmmYho8&index=6) by Laura Frank (DC17US)]
|
||||
.blackbelt[DC17US: Everything You Thought You Already Knew About Orchestration
|
||||
([video](https://www.youtube.com/watch?v=Qsv-q8WbIZY&list=PLkA60AVN3hh-biQ6SCtBJ-WVTyBmmYho8&index=6))]
|
||||
|
||||
.blackbelt[DC17EU: Container Orchestration from Theory to Practice
|
||||
([video](https://dockercon.docker.com/watch/5fhwnQxW8on1TKxPwwXZ5r))]
|
||||
|
||||
.blackbelt[Container Orchestration from Theory to Practice by Laura Frank and Stephen Day (Wednesday 14:25)]
|
||||
|
||||
@@ -50,8 +50,11 @@
|
||||
|
||||
## Learning more about container security
|
||||
|
||||
.blackbelt[[Securing Containers, One Patch At A Time](https://www.youtube.com/watch?v=jZSs1RHwcqo&list=PLkA60AVN3hh-biQ6SCtBJ-WVTyBmmYho8&index=4) by Michael Crosby (DC17US)]
|
||||
.blackbelt[DC17US: Securing Containers, One Patch At A Time
|
||||
([video](https://www.youtube.com/watch?v=jZSs1RHwcqo&list=PLkA60AVN3hh-biQ6SCtBJ-WVTyBmmYho8&index=4))]
|
||||
|
||||
.blackbelt[Container-relevant Upstream Kernel Developments by Tycho Andersen (Tuesday 14:55)]
|
||||
.blackbelt[DC17EU: Container-relevant Upstream Kernel Developments
|
||||
([video](https://dockercon.docker.com/watch/7JQBpvHJwjdW6FKXvMfCK1))]
|
||||
|
||||
.blackbelt[What Have Syscalls Done for you Lately? by Liz Rice (Tuesday 11:45)]
|
||||
.blackbelt[DC17EU: What Have Syscalls Done for you Lately?
|
||||
([video](https://dockercon.docker.com/watch/4ZxNyWuwk9JHSxZxgBBi6J))]
|
||||
|
||||
136
docs/lisa.yml
Normal file
136
docs/lisa.yml
Normal file
@@ -0,0 +1,136 @@
|
||||
title: "LISA17 T9: Build, Ship, and Run Microservices on a Docker Swarm Cluster"
|
||||
|
||||
chat: "[Slack](https://usenix-lisa.slack.com/messages/C0E6N1NJW)"
|
||||
|
||||
|
||||
exclude:
|
||||
- self-paced
|
||||
- snap
|
||||
- auto-btp
|
||||
- benchmarking
|
||||
- elk-manual
|
||||
- prom-manual
|
||||
|
||||
chapters:
|
||||
- |
|
||||
class: title
|
||||
|
||||
.small[
|
||||
|
||||
LISA17 T9
|
||||
|
||||
Build, Ship, and Run Microservices on a Docker Swarm Cluster
|
||||
|
||||
.small[.small[
|
||||
|
||||
**Be kind to the WiFi!**
|
||||
|
||||
*Use the 5G network*
|
||||
<br/>
|
||||
*Don't use your hotspot*
|
||||
<br/>
|
||||
*Don't stream videos from YouTube, Netflix, etc.
|
||||
<br/>(if you're bored, watch local content instead)*
|
||||
|
||||
<!--
|
||||
Also: share the power outlets
|
||||
<br/>
|
||||
*(with limited power comes limited responsibility?)*
|
||||
<br/>
|
||||
*(or something?)*
|
||||
-->
|
||||
|
||||
Thank you!
|
||||
|
||||
]
|
||||
]
|
||||
]
|
||||
|
||||
---
|
||||
|
||||
## Intros
|
||||
|
||||
- Hello! We are
|
||||
AJ ([@s0ulshake](https://twitter.com/s0ulshake), Travis CI)
|
||||
&
|
||||
Jérôme ([@jpetazzo](https://twitter.com/jpetazzo), Docker Inc.)
|
||||
|
||||
--
|
||||
|
||||
- This is our collective Docker knowledge:
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Logistics
|
||||
|
||||
- The tutorial will run from 1:30pm to 5:00pm
|
||||
|
||||
- This will be fast-paced, but DON'T PANIC!
|
||||
|
||||
- There will be a coffee break at 3:00pm
|
||||
<br/>
|
||||
(please remind us if we forget about it!)
|
||||
|
||||
- Feel free to interrupt for questions at any time
|
||||
|
||||
- All the content is publicly available (slides, code samples, scripts)
|
||||
|
||||
One URL to remember: http://container.training
|
||||
|
||||
- Live feedback, questions, help on @@CHAT@@
|
||||
|
||||
- intro.md
|
||||
- |
|
||||
@@TOC@@
|
||||
- - prereqs.md
|
||||
- versions.md
|
||||
- |
|
||||
class: title
|
||||
|
||||
All right!
|
||||
<br/>
|
||||
We're all set.
|
||||
<br/>
|
||||
Let's do this.
|
||||
- sampleapp.md
|
||||
- swarmkit.md
|
||||
- creatingswarm.md
|
||||
- morenodes.md
|
||||
- - firstservice.md
|
||||
- ourapponswarm.md
|
||||
- updatingservices.md
|
||||
#- rollingupdates.md
|
||||
#- healthchecks.md
|
||||
- - operatingswarm.md
|
||||
#- netshoot.md
|
||||
#- ipsec.md
|
||||
#- swarmtools.md
|
||||
- security.md
|
||||
#- secrets.md
|
||||
#- encryptionatrest.md
|
||||
- leastprivilege.md
|
||||
- apiscope.md
|
||||
- logging.md
|
||||
- metrics.md
|
||||
#- stateful.md
|
||||
#- extratips.md
|
||||
- end.md
|
||||
- |
|
||||
class: title
|
||||
|
||||
That's all folks! <br/> Questions?
|
||||
|
||||
.small[.small[
|
||||
|
||||
AJ ([@s0ulshake](https://twitter.com/s0ulshake)) — [@TravisCI](https://twitter.com/travisci)
|
||||
|
||||
Jérôme ([@jpetazzo](https://twitter.com/jpetazzo)) — [@Docker](https://twitter.com/docker)
|
||||
|
||||
]]
|
||||
|
||||
<!--
|
||||
Tiffany ([@tiffanyfayj](https://twitter.com/tiffanyfayj))
|
||||
AJ ([@s0ulshake](https://twitter.com/s0ulshake))
|
||||
-->
|
||||
@@ -1630,8 +1630,8 @@ class: prom, snap
|
||||
- [The Prometheus Time Series Database](https://www.youtube.com/watch?v=HbnGSNEjhUc),
|
||||
a talk explaining why custom data storage is necessary for metrics
|
||||
|
||||
.blackbelt[[Monitoring, the Prometheus Way
|
||||
](https://www.youtube.com/watch?v=PDxcEzu62jk&list=PLkA60AVN3hh-biQ6SCtBJ-WVTyBmmYho8&index=5) by Julius Volz (DC17US)]
|
||||
.blackbelt[DC17US: Monitoring, the Prometheus Way
|
||||
([video](https://www.youtube.com/watch?v=PDxcEzu62jk&list=PLkA60AVN3hh-biQ6SCtBJ-WVTyBmmYho8&index=5))]
|
||||
|
||||
.blackbelt[How and Why Prometheus' New Storage Engine Pushes the Limits of Time Series Databases
|
||||
by Goutham Veeramachaneni (Tuesday 17:10)]
|
||||
.blackbelt[DC17EU: Prometheus 2.0 Storage Engine
|
||||
([video](https://dockercon.docker.com/watch/NNZ8GXHGomouwSXtXnxb8P))]
|
||||
|
||||
139
docs/rollingupdates.md
Normal file
139
docs/rollingupdates.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# Rolling updates
|
||||
|
||||
- Let's change a scaled service: `worker`
|
||||
|
||||
.exercise[
|
||||
|
||||
- Edit `worker/worker.py`
|
||||
|
||||
- Locate the `sleep` instruction and change the delay
|
||||
|
||||
- Build, ship, and run our changes:
|
||||
```bash
|
||||
export TAG=v0.4
|
||||
docker-compose -f dockercoins.yml build
|
||||
docker-compose -f dockercoins.yml push
|
||||
docker stack deploy -c dockercoins.yml dockercoins
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
---
|
||||
|
||||
## Viewing our update as it rolls out
|
||||
|
||||
.exercise[
|
||||
|
||||
- Check the status of the `dockercoins_worker` service:
|
||||
```bash
|
||||
watch docker service ps dockercoins_worker
|
||||
```
|
||||
|
||||
- Hide the tasks that are shutdown:
|
||||
```bash
|
||||
watch -n1 "docker service ps dockercoins_worker | grep -v Shutdown.*Shutdown"
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
If you had stopped the workers earlier, this will automatically restart them.
|
||||
|
||||
By default, SwarmKit does a rolling upgrade, one instance at a time.
|
||||
|
||||
We should therefore see the workers being updated one my one.
|
||||
|
||||
---
|
||||
|
||||
## Changing the upgrade policy
|
||||
|
||||
- We can set upgrade parallelism (how many instances to update at the same time)
|
||||
|
||||
- And upgrade delay (how long to wait between two batches of instances)
|
||||
|
||||
.exercise[
|
||||
|
||||
- Change the parallelism to 2 and the delay to 5 seconds:
|
||||
```bash
|
||||
docker service update dockercoins_worker \
|
||||
--update-parallelism 2 --update-delay 5s
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
The current upgrade will continue at a faster pace.
|
||||
|
||||
---
|
||||
|
||||
## Changing the policy in the Compose file
|
||||
|
||||
- The policy can also be updated in the Compose file
|
||||
|
||||
- This is done by adding an `update_config` key under the `deploy` key:
|
||||
|
||||
```yaml
|
||||
deploy:
|
||||
replicas: 10
|
||||
update_config:
|
||||
parallelism: 2
|
||||
delay: 10s
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Rolling back
|
||||
|
||||
- At any time (e.g. before the upgrade is complete), we can rollback:
|
||||
|
||||
- by editing the Compose file and redeploying;
|
||||
|
||||
- or with the special `--rollback` flag
|
||||
|
||||
.exercise[
|
||||
|
||||
- Try to rollback the service:
|
||||
```bash
|
||||
docker service update dockercoins_worker --rollback
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
What happens with the web UI graph?
|
||||
|
||||
---
|
||||
|
||||
## The fine print with rollback
|
||||
|
||||
- Rollback reverts to the previous service definition
|
||||
|
||||
- If we visualize successive updates as a stack:
|
||||
|
||||
- it doesn't "pop" the latest update
|
||||
|
||||
- it "pushes" a copy of the previous update on top
|
||||
|
||||
- ergo, rolling back twice does nothing
|
||||
|
||||
- "Service definition" includes rollout cadence
|
||||
|
||||
- Each `docker service update` command = a new service definition
|
||||
|
||||
---
|
||||
|
||||
class: extra-details
|
||||
|
||||
## Timeline of an upgrade
|
||||
|
||||
- SwarmKit will upgrade N instances at a time
|
||||
<br/>(following the `update-parallelism` parameter)
|
||||
|
||||
- New tasks are created, and their desired state is set to `Ready`
|
||||
<br/>.small[(this pulls the image if necessary, ensures resource availability, creates the container ... without starting it)]
|
||||
|
||||
- If the new tasks fail to get to `Ready` state, go back to the previous step
|
||||
<br/>.small[(SwarmKit will try again and again, until the situation is addressed or desired state is updated)]
|
||||
|
||||
- When the new tasks are `Ready`, it sets the old tasks desired state to `Shutdown`
|
||||
|
||||
- When the old tasks are `Shutdown`, it starts the new tasks
|
||||
|
||||
- Then it waits for the `update-delay`, and continues with the next batch of instances
|
||||
@@ -44,6 +44,7 @@ chapters:
|
||||
- swarmnbt.md
|
||||
- ipsec.md
|
||||
- updatingservices.md
|
||||
- rollingupdates.md
|
||||
- healthchecks.md
|
||||
- nodeinfo.md
|
||||
- swarmtools.md
|
||||
|
||||
@@ -82,145 +82,3 @@
|
||||
- Or just mash "reload" frantically
|
||||
|
||||
- ... Eventually the legend on the left will be bigger!
|
||||
|
||||
---
|
||||
|
||||
## Rolling updates
|
||||
|
||||
- Let's change a scaled service: `worker`
|
||||
|
||||
.exercise[
|
||||
|
||||
- Edit `worker/worker.py`
|
||||
|
||||
- Locate the `sleep` instruction and change the delay
|
||||
|
||||
- Build, ship, and run our changes:
|
||||
```bash
|
||||
export TAG=v0.4
|
||||
docker-compose -f dockercoins.yml build
|
||||
docker-compose -f dockercoins.yml push
|
||||
docker stack deploy -c dockercoins.yml dockercoins
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
---
|
||||
|
||||
## Viewing our update as it rolls out
|
||||
|
||||
.exercise[
|
||||
|
||||
- Check the status of the `dockercoins_worker` service:
|
||||
```bash
|
||||
watch docker service ps dockercoins_worker
|
||||
```
|
||||
|
||||
- Hide the tasks that are shutdown:
|
||||
```bash
|
||||
watch -n1 "docker service ps dockercoins_worker | grep -v Shutdown.*Shutdown"
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
If you had stopped the workers earlier, this will automatically restart them.
|
||||
|
||||
By default, SwarmKit does a rolling upgrade, one instance at a time.
|
||||
|
||||
We should therefore see the workers being updated one my one.
|
||||
|
||||
---
|
||||
|
||||
## Changing the upgrade policy
|
||||
|
||||
- We can set upgrade parallelism (how many instances to update at the same time)
|
||||
|
||||
- And upgrade delay (how long to wait between two batches of instances)
|
||||
|
||||
.exercise[
|
||||
|
||||
- Change the parallelism to 2 and the delay to 5 seconds:
|
||||
```bash
|
||||
docker service update dockercoins_worker \
|
||||
--update-parallelism 2 --update-delay 5s
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
The current upgrade will continue at a faster pace.
|
||||
|
||||
---
|
||||
|
||||
## Changing the policy in the Compose file
|
||||
|
||||
- The policy can also be updated in the Compose file
|
||||
|
||||
- This is done by adding an `update_config` key under the `deploy` key:
|
||||
|
||||
```yaml
|
||||
deploy:
|
||||
replicas: 10
|
||||
update_config:
|
||||
parallelism: 2
|
||||
delay: 10s
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Rolling back
|
||||
|
||||
- At any time (e.g. before the upgrade is complete), we can rollback:
|
||||
|
||||
- by editing the Compose file and redeploying;
|
||||
|
||||
- or with the special `--rollback` flag
|
||||
|
||||
.exercise[
|
||||
|
||||
- Try to rollback the service:
|
||||
```bash
|
||||
docker service update dockercoins_worker --rollback
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
What happens with the web UI graph?
|
||||
|
||||
---
|
||||
|
||||
## The fine print with rollback
|
||||
|
||||
- Rollback reverts to the previous service definition
|
||||
|
||||
- If we visualize successive updates as a stack:
|
||||
|
||||
- it doesn't "pop" the latest update
|
||||
|
||||
- it "pushes" a copy of the previous update on top
|
||||
|
||||
- ergo, rolling back twice does nothing
|
||||
|
||||
- "Service definition" includes rollout cadence
|
||||
|
||||
- Each `docker service update` command = a new service definition
|
||||
|
||||
---
|
||||
|
||||
class: extra-details
|
||||
|
||||
## Timeline of an upgrade
|
||||
|
||||
- SwarmKit will upgrade N instances at a time
|
||||
<br/>(following the `update-parallelism` parameter)
|
||||
|
||||
- New tasks are created, and their desired state is set to `Ready`
|
||||
<br/>.small[(this pulls the image if necessary, ensures resource availability, creates the container ... without starting it)]
|
||||
|
||||
- If the new tasks fail to get to `Ready` state, go back to the previous step
|
||||
<br/>.small[(SwarmKit will try again and again, until the situation is addressed or desired state is updated)]
|
||||
|
||||
- When the new tasks are `Ready`, it sets the old tasks desired state to `Shutdown`
|
||||
|
||||
- When the old tasks are `Shutdown`, it starts the new tasks
|
||||
|
||||
- Then it waits for the `update-delay`, and continues with the next batch of instances
|
||||
|
||||
Reference in New Issue
Block a user