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

Backport content from DOD MSP

Browse Source
This commit is contained in:
Jérôme Petazzoni
2017-09-29 23:35:52 +02:00
parent 87cbbd5c35
commit 36f512a3d3
1 changed files with 184 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

198
docs/index.html
View File

@@ -778,6 +778,10 @@ class: extra-details
(instead of e.g. IP address or FQDN)
- Network aliases are automatically namespaced
(i.e. you can have multiple apps declaring and using a service named `database`)
---
## Example in `worker/worker.py`
@@ -1207,18 +1211,6 @@ Scaling out
- It is a plumbing part of the Docker ecosystem
<!--
- SwarmKit comes with two examples:
- `swarmctl` (a CLI tool to "speak" the SwarmKit API)
- `swarmd` (an agent that can federate existing Docker Engines into a Swarm)
-->
- SwarmKit/swarmd/swarmctl → libcontainer/containerd/container-ctr
---
## SwarmKit features
@@ -1841,6 +1833,8 @@ class: docker-machine
---
class: under-the-hood
## Under the hood: docker swarm init
When we do `docker swarm init`:
@@ -1855,6 +1849,8 @@ When we do `docker swarm init`:
---
class: under-the-hood
## Under the hood: join tokens
There is one token to *join as a worker*, and another to *join as a manager*.
@@ -1872,6 +1868,8 @@ docker swarm join-token --rotate <worker|manager>
---
class: under-the-hood
## Under the hood: docker swarm join
When a node joins the Swarm:
@@ -1890,6 +1888,8 @@ When a node joins the Swarm:
---
class: under-the-hood
## Under the hood: cluster communication
- The *control plane* is encrypted with AES-GCM; keys are rotated every 12 hours
@@ -1905,6 +1905,8 @@ When a node joins the Swarm:
---
class: under-the-hood
## Under the hood: I want to know more!
Revisit SwarmKit concepts:
@@ -2162,6 +2164,24 @@ class: self-paced
---
## Real-life deployment methods
-- Running commands manually over SSH
--
(lol jk)
--
- Using your favorite configuration management tool
- [Docker for AWS](https://docs.docker.com/docker-for-aws/#quickstart)
- [Docker for Azure](https://docs.docker.com/docker-for-azure/)
---
# Running our first Swarm service
- How do we run services? Simplified version:
@@ -2222,6 +2242,8 @@ Note: by default, when a container is destroyed (e.g. when scaling down), its lo
---
class: extra-details
## Before Docker Engine 17.05
- Docker 1.13/17.03/17.04 have `docker service logs` as an experimental feature
@@ -2470,6 +2492,8 @@ There are many ways to deal with inbound traffic on a Swarm cluster.
---
class: btw-labels
## Managing HTTP traffic
- The TCP routing mesh doesn't parse HTTP headers
@@ -2487,6 +2511,8 @@ There are many ways to deal with inbound traffic on a Swarm cluster.
---
class: btw-labels
## You should use labels
- Labels are a great way to attach arbitrary information to services
@@ -2751,6 +2777,8 @@ class: extra-details
---
class: manual-btp
# Deploying a local registry
- We will create a single-instance service, publishing its port
@@ -2774,6 +2802,8 @@ class: extra-details
---
class: manual-btp
## Testing our local registry
- We can retag a small image, and push it to the registry
@@ -2795,6 +2825,8 @@ class: extra-details
---
class: manual-btp
## Checking what's on our local registry
- The registry API has endpoints to query what's there
@@ -3028,6 +3060,8 @@ It has been replaced by the new version, with port 80 accessible from outside.
---
class: manual-btp
## Connect to the web UI
- The web UI is now available on port 8000, *on all the nodes of the cluster*
@@ -3063,6 +3097,8 @@ You should see the performance peaking at 10 hashes/s (like before).
---
class: manual-btp
# Global scheduling
- We want to utilize as best as we can the entropy generators
@@ -3078,6 +3114,8 @@ You should see the performance peaking at 10 hashes/s (like before).
---
class: manual-btp
## Scaling the `rng` service
.exercise[
@@ -3099,7 +3137,7 @@ You should see the performance peaking at 10 hashes/s (like before).
---
class: extra-details
class: extra-details, manual-btp
## Why do we have to re-create the service to enable global scheduling?
@@ -3117,6 +3155,8 @@ class: extra-details
---
class: swarm-ready
## How did we make our app "Swarm-ready"?
This app was written in June 2015. (One year before Swarm mode was released.)
@@ -3141,6 +3181,8 @@ What did we change to make it compatible with Swarm mode?
---
class: swarm-ready
## What did we change in our app since its inception?
- Compose files
@@ -3153,10 +3195,14 @@ What did we change to make it compatible with Swarm mode?
--
class: swarm-ready
*We didn't change a single line of code in this app since it was written.*
--
class: swarm-ready
*The images that were [built in June 2015](
https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/)
(when the app was written) can still run today ...
@@ -3165,6 +3211,8 @@ https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/)
---
class: swarm-ready
## How did we design our app in the first place?
- [Twelve-Factor App](https://12factor.net/) principles
@@ -3181,6 +3229,8 @@ https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/)
---
class: manual-btp
# Integration with Compose
- The previous section showed us how to streamline image build and push
@@ -3211,6 +3261,8 @@ https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/)
---
class: manual-btp
## Removing everything
- Before deploying using "stacks," let's get a clean slate
@@ -3230,7 +3282,7 @@ https://hub.docker.com/r/jpetazzo/dockercoins_worker/tags/)
We need a registry to move images around.
Before, we deployed it with the following command:
Without a stack file, it would be deployed with the following command:
```bash
docker service create --publish 5000:5000 registry:2
@@ -3311,6 +3363,8 @@ services:
---
class: manual-btp
## Specifics of stack deployment
Our registry is not *exactly* identical to the one deployed with `docker service create`!
@@ -3329,6 +3383,72 @@ Our registry is not *exactly* identical to the one deployed with `docker service
---
## Testing our local registry
- Connecting to port 5000 *on any node of the cluster* routes us to the registry
- Therefore, we can use `localhost:5000` or `127.0.0.1:5000` as our registry
.exercise[
- Issue the following API request to the registry:
```bash
curl 127.0.0.1:5000/v2/_catalog
```
]
It should return:
```json
{"repositories":[]}
```
If that doesn't work, retry a few times; perhaps the container is still starting.
---
## Pushing an image to our local registry
- We can retag a small image, and push it to the registry
.exercise[
- Make sure we have the busybox image, and retag it:
```bash
docker pull busybox
docker tag busybox 127.0.0.1:5000/busybox
```
- Push it:
```bash
docker push 127.0.0.1:5000/busybox
```
]
---
## Checking what's on our local registry
- The registry API has endpoints to query what's there
.exercise[
- Ensure that our busybox image is now in the local registry:
```bash
curl http://127.0.0.1:5000/v2/_catalog
```
]
The curl command should now output:
```json
"repositories":["busybox"]}
```
---
## Building and pushing stack services
- When using Compose file version 2 and above, you can specify *both* `build` and `image`
@@ -5093,6 +5213,56 @@ class: secrets
---
# Least privilege model
- All the important data is stored in the "Raft log"
- Managers nodes have read/write access to this data
- Workers nodes have no access to this data
- Workers only receive the minimum amount of data that they need:
- which services to run
- network configuration information for these services
- credentials for these services
- Compromising a worker node does not give access to the full cluster
---
## What can I do if I compromise a worker node?
- I can enter the containers running on that node
- I can access the configuration and credentials used by these containers
- I can inspect the network traffic of these containers
- I cannot inspect or disrupt the network traffic of other containers
(network information is provided by manager nodes; ARP spoofing is not possible)
- I cannot infer the topology of the cluster and its number of nodes
- I can only learn the IP addresses of the manager nodes
---
## Guidelines for workload isolation leveraging least privilege model
- Define security levels
- Define security zones
- Put managers in the highest security zone
- Enforce workloads of a given security level to run in a given zone
- Enforcement can be done with [Authorization Plugins](https://docs.docker.com/engine/extend/plugins_authorization/)
---
class: namespaces
name: namespaces