mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-18 12:29:18 +00:00
First round of updates for LISA
This commit is contained in:
Jerome Petazzoni
185
docs/index.html
185
docs/index.html
@@ -1213,11 +1213,11 @@ You should see your 5 nodes.
|
||||
|
||||
## Using Docker Machine to communicate with a node
|
||||
|
||||
- To select a node, use `eval $(docker-machine nodeX)`
|
||||
- To select a node, use `eval $(docker-machine env nodeX)`
|
||||
|
||||
- This sets a number of environment variables
|
||||
|
||||
- To unset these variables, use `eval $(docker-machine -u)`
|
||||
- To unset these variables, use `eval $(docker-machine env -u)`
|
||||
|
||||
.exercise[
|
||||
|
||||
@@ -1268,6 +1268,10 @@ You should see your 5 nodes.
|
||||
|
||||
]
|
||||
|
||||
Note: it can be useful to use a [custom shell prompt](
|
||||
https://github.com/jpetazzo/orchestration-workshop/blob/master/prepare-vms/scripts/postprep.rc#L68)
|
||||
reflecting the `DOCKER_HOST` variable.
|
||||
|
||||
---
|
||||
|
||||
## Checking that our node is here
|
||||
@@ -1290,16 +1294,88 @@ You should see your 5 nodes.
|
||||
|
||||
---
|
||||
|
||||
## Under the hood
|
||||
## Under the hood: docker swarm init
|
||||
|
||||
When we do `docker swarm init`, a TLS root CA is created. Then a keypair is issued for the first node, and signed by the root CA.
|
||||
When we do `docker swarm init`:
|
||||
|
||||
When further nodes join the Swarm, they are issued their own keypair, signed by the root CA, and they also receive the root CA public key and certificate.
|
||||
- a keypair is created for the root CA of our Swarm
|
||||
|
||||
All communication is encrypted over TLS.
|
||||
- a keypair is created for the first node
|
||||
|
||||
The node keys and certificates are automatically renewed on regular intervals
|
||||
<br/>(by default, 90 days; this is tunable with `docker swarm update`).
|
||||
- a certificate is issued for this node
|
||||
|
||||
- the join tokens are created
|
||||
|
||||
---
|
||||
|
||||
## Under the hood: join tokens
|
||||
|
||||
There is one token to *join as a worker*, and another to *join as a manager*.
|
||||
|
||||
The join tokens have two parts:
|
||||
|
||||
- a secret key (preventing unauthorized nodes from joining)
|
||||
|
||||
- a fingerprint of the root CA certificate (preventing MITM attacks)
|
||||
|
||||
If a token is compromised, it can be rotated instantly with:
|
||||
```
|
||||
docker swarm join-token --rotate <worker|manager>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Under the hood: docker swarm join
|
||||
|
||||
When a node joins the Swarm:
|
||||
|
||||
- it is issued its own keypair, signed by the root CA
|
||||
|
||||
- if the node is a manager:
|
||||
|
||||
- it joins the Raft consensus
|
||||
- it connects to the current leader
|
||||
- it accepts connections from worker nodes
|
||||
|
||||
- if the node is a worker:
|
||||
|
||||
- it connects to one of the managers (leader or follower)
|
||||
|
||||
---
|
||||
|
||||
## Under the hood: cluster communication
|
||||
|
||||
- The *control plane* is encrypted over TLS
|
||||
|
||||
- Keys and certificates are automatically renewed on regular intervals
|
||||
|
||||
(90 days by default; tunable with `docker swarm update`)
|
||||
|
||||
- The *data plane* (communication between containers) is not encrypted by default
|
||||
|
||||
(but this can be activated on a by-network basis, using IPSEC,
|
||||
leveraging hardware crypto if available)
|
||||
|
||||
---
|
||||
|
||||
## Under the hood: I want to know more!
|
||||
|
||||
Revisit SwarmKit concepts:
|
||||
|
||||
- Docker 1.12 Swarm Mode Deep Dive Part 1: Topology
|
||||
([video](https://www.youtube.com/watch?v=dooPhkXT9yI))
|
||||
|
||||
- Docker 1.12 Swarm Mode Deep Dive Part 2: Orchestration
|
||||
([video](https://www.youtube.com/watch?v=_F6PSP-qhdA))
|
||||
|
||||
Some presentations from the Docker Distributed Systems Summit in Berlin:
|
||||
|
||||
- Heart of the SwarmKit: Topology Management
|
||||
([slides](https://speakerdeck.com/aluzzardi/heart-of-the-swarmkit-topology-management))
|
||||
|
||||
- Heart of the SwarmKit: Store, Topology & Object Model
|
||||
([slides](http://www.slideshare.net/Docker/heart-of-the-swarmkit-store-topology-object-model))
|
||||
([video](https://www.youtube.com/watch?v=EmePhjGnCXY))
|
||||
|
||||
---
|
||||
|
||||
@@ -1403,10 +1479,13 @@ As we saw earlier, you can only control the Swarm through a manager node.
|
||||
|
||||
.exercise[
|
||||
|
||||
- Log into the node:
|
||||
- Log into the node *or* use Docker Machine to talk to it:
|
||||
```bash
|
||||
ssh nodeX
|
||||
```
|
||||
```bash
|
||||
eval $(docker-machine env nodeX)
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
@@ -1414,8 +1493,6 @@ As we saw earlier, you can only control the Swarm through a manager node.
|
||||
|
||||
## Viewing the logs of the container
|
||||
|
||||
- We need to be logged into the node running the container
|
||||
|
||||
.exercise[
|
||||
|
||||
- See that the container is running and check its ID:
|
||||
@@ -1428,9 +1505,12 @@ As we saw earlier, you can only control the Swarm through a manager node.
|
||||
docker logs <containerID>
|
||||
```
|
||||
|
||||
]
|
||||
- Go back to `node1` afterwards by logging out of SSH, or by running:
|
||||
```bash
|
||||
eval $(docker-machine env -u)
|
||||
```
|
||||
|
||||
Go back to `node1` afterwards.
|
||||
]
|
||||
|
||||
---
|
||||
|
||||
@@ -1483,7 +1563,7 @@ Go back to `node1` afterwards.
|
||||
- Create an ElasticSearch service (and give it a name while we're at it):
|
||||
```bash
|
||||
docker service create --name search --publish 9200:9200 --replicas 7 \
|
||||
elasticsearch
|
||||
elasticsearch:2
|
||||
```
|
||||
|
||||
- Check what's going on:
|
||||
@@ -1850,20 +1930,19 @@ Can you see how?
|
||||
|
||||
## Caveats
|
||||
|
||||
.warning[It is currently not possible to join an overlay network with `docker run --net ...`;
|
||||
this might or might not change in the future. We will see how to cope
|
||||
with this limitation.]
|
||||
.warning[In Docker 1.12, you cannot join an overlay network with `docker run --net ...`.]
|
||||
|
||||
Starting with version 1.13, you can, if the network was created with the `--attachable` flag.
|
||||
|
||||
*Why is that?*
|
||||
|
||||
Placing a container on a network requires allocating an IP address for this container.
|
||||
|
||||
The allocation must be done by a manager node (worker nodes cannot update Raft's data structures).
|
||||
The allocation must be done by a manager node (worker nodes cannot update Raft data).
|
||||
|
||||
As a result, `docker run --net ...` would only work on manager nodes.
|
||||
As a result, `docker run --net ...` requires collaboration with manager nodes.
|
||||
|
||||
Moreover, it would significantly alter the code path for `docker run`, even in classic mode.
|
||||
<br/>(That could be a bad thing if it's not done very carefully!)
|
||||
It alters the code path for `docker run`, so it is allowed only under strict circumstances.
|
||||
|
||||
---
|
||||
|
||||
@@ -2075,9 +2154,13 @@ class: title
|
||||
|
||||
- We want to run tools like `ab` or `httping` on the internal network
|
||||
|
||||
- .warning[This will be very hackish]
|
||||
--
|
||||
|
||||
(Better techniques and tools might become available in the future!)
|
||||
- Ah, if only we had created our overlay network with the `--attachable` flag ...
|
||||
|
||||
--
|
||||
|
||||
- Oh well, let's use this as an excuse to introduce New Ways To Do Things
|
||||
|
||||
---
|
||||
|
||||
@@ -2405,6 +2488,23 @@ WHY?!?
|
||||
|
||||
---
|
||||
|
||||
## Global scheduling → global debugging
|
||||
|
||||
- Traditional approach:
|
||||
|
||||
- log into a node
|
||||
- install our Swiss Army Knife (if necessary)
|
||||
- troubleshoot things
|
||||
|
||||
- Proposed alternative:
|
||||
|
||||
- put our Swiss Army Knife in a container (e.g. [nicolaka/netshoot](https://hub.docker.com/r/nicolaka/netshoot/))
|
||||
- run tests from multiple locations at the same time
|
||||
|
||||
(This becomes practical with the `docker service log` command, available by enabling experimental features.)
|
||||
|
||||
---
|
||||
|
||||
# Rolling updates
|
||||
|
||||
- We want to release a new version of the worker
|
||||
@@ -2484,7 +2584,7 @@ Note how the build and push were fast (because caching).
|
||||
|
||||
- Look at our service status:
|
||||
```bash
|
||||
watch -n1 "docker service ps worker | grep -v Shutdown.*Shutdown"
|
||||
watch -n1 "docker service ps worker -a | grep -v Shutdown.*Shutdown"
|
||||
```
|
||||
|
||||
]
|
||||
@@ -2528,11 +2628,28 @@ By default, SwarmKit does a rolling upgrade, one instance at a time.
|
||||
docker service update worker --update-parallelism 2 --update-delay 5s
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
The current upgrade will continue at a faster pace.
|
||||
|
||||
---
|
||||
|
||||
## Rolling back
|
||||
|
||||
- At any time (e.g. before the upgrade is complete), we can rollback
|
||||
|
||||
.exercise[
|
||||
|
||||
- Rollback to the previous image:
|
||||
```bash
|
||||
docker service update worker --image $DOCKER_REGISTRY/dockercoins_worker:v0.1
|
||||
```
|
||||
|
||||
- With Docker 1.13, we can also revert to the previous service specification:
|
||||
```bash
|
||||
docker service update worker --rollback
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
---
|
||||
@@ -2556,6 +2673,20 @@ By default, SwarmKit does a rolling upgrade, one instance at a time.
|
||||
|
||||
---
|
||||
|
||||
## Getting task information for a given node
|
||||
|
||||
- You can see all the tasks assigned to a node with `docker node ps`
|
||||
|
||||
- It shows the *desired state* and *current state* of each task
|
||||
|
||||
- `docker node ps` shows info about the current node
|
||||
|
||||
- `docker node ps <node_name_or_id>` shows info for another node
|
||||
|
||||
- `docker node ps -a` includes stopped and failed tasks
|
||||
|
||||
---
|
||||
|
||||
## Getting cluster-wide task information
|
||||
|
||||
- The Docker API doesn't expose this directly (yet)
|
||||
@@ -2606,11 +2737,13 @@ Shameless promo: for more Go and Docker love, check
|
||||
- Set an alias so that swarmctl can run as root and use the right control socket:
|
||||
```bash
|
||||
alias \
|
||||
swarmctl='sudo swarmctl --socket /var/lib/docker/swarm/control.sock'
|
||||
swarmctl='sudo swarmctl --socket /var/run/docker/swarm/control.sock'
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
(Note: with Docker 1.12, that control socket is in `/var/lib/docker/swarm/control.sock`)
|
||||
|
||||
---
|
||||
|
||||
## `swarmctl` in action
|
||||
@@ -3119,7 +3252,7 @@ curl -sSL $RELEASEURL/snap-plugins-$SNAPVER-linux-amd64.tar.gz |
|
||||
tar -C /opt -zxf-
|
||||
ln -s snap-$SNAPVER /opt/snap
|
||||
for BIN in snapd snapctl; do ln -s /opt/snap/bin/$BIN /usr/local/bin/$BIN; done
|
||||
' If you copy-paste that block, don't forget that final quote :-)
|
||||
' If you copy-paste that block, do not forget that final quote ☺
|
||||
```
|
||||
|
||||
]
|
||||
|
||||
@@ -30,6 +30,6 @@ footer: >
|
||||
url: http://container.training/
|
||||
|
||||
engine_version: test.docker.com
|
||||
compose_version: 1.8.1
|
||||
machine_version: 0.8.2
|
||||
compose_version: 1.9.0
|
||||
machine_version: 0.9.0-rc1
|
||||
swarm_version: latest
|
||||
|
||||
Reference in New Issue
Block a user