diff --git a/www/htdocs/dragons.jpg b/www/htdocs/dragons.jpg new file mode 100644 index 00000000..1e6dec53 Binary files /dev/null and b/www/htdocs/dragons.jpg differ diff --git a/www/htdocs/index.html b/www/htdocs/index.html index c4091acf..785da482 100644 --- a/www/htdocs/index.html +++ b/www/htdocs/index.html @@ -116,11 +116,12 @@ class: title - Logs - Security upgrades - Network traffic analysis -- Introducing Swarm +- Dynamic orchestration +- Introducing Mesos, Kubernetes, Swarm +- PAAS and other tools - Setting up our Swarm cluster - Running on Swarm - Network plumbing on Swarm -- Last words --- @@ -169,7 +170,7 @@ to be done from the first VM, `node1`. - Docker 1.7 -- Compose 1.3.1 +- Compose 1.3.2 - Swarm 0.3 @@ -826,6 +827,7 @@ those files are only present locally, not on the remote nodes. .exercise[ - Open the Web UI +
(on a node where it's deployed) - Deploy one instance of the stack on each node @@ -902,7 +904,7 @@ those files are only present locally, not on the remote nodes. ``` redis: image: jpetazzo/hamba - command: 6379 52.26.10.3 32785 + command: 6379 AA.BB.CC.DD EEEEE ``` ] @@ -926,7 +928,7 @@ those files are only present locally, not on the remote nodes. ## Discussion -- `jpetazzo/hamba` is stack and stupid +- `jpetazzo/hamba` is simple and stupid - It could be replaced with something dynamic: @@ -970,11 +972,11 @@ those files are only present locally, not on the remote nodes. -ti ubuntu ``` -- Look in `/data` in the container. -
(It should be empty.) +- Look in `/data` in the container +
(That's where Redis puts its data dumps) ] -- We need to tell Redis to perform a data dump +- We need to tell Redis to perform a data dump *now* --- @@ -992,7 +994,7 @@ those files are only present locally, not on the remote nodes. ] -- There should be a dump file now +- There should be a recent dump file now --- @@ -1129,7 +1131,7 @@ those files are only present locally, not on the remote nodes. - rebuild - - restart containres + - restart containers (The procedure is simple and plain, just follow it!) @@ -1169,27 +1171,188 @@ those files are only present locally, not on the remote nodes. --- -# Introducing Swarm +class: title -![Swarm Logo](swarm.png) +# Dynamic orchestration --- -## Overview +# Static vs Dynamic -- Swarm consolidates multiple Docker hosts into a single one +- Static -- Swarm "looks like" a Docker daemon, but it dispatches (schedules) + - you decide what goes where + + - simple to describe and implement + + - seems easy at first but doesn't scale efficiently + +- Dynamic + + - the system decides what goes where + + - requires extra components (HA KV...) + + - scaling can be finer-grained, more efficient + +--- + +# Mesos (overview) + +- First presented in 2009 + +- Initial goal: resource scheduler +
(two-level/pessimistic) + + - top-level "master" knows the global cluster state + + - "slave" nodes report status and resources to master + + - master allocates resources to "frameworks" + +- Container support added recently +
(had to fit existing model) + +- Network and service discovery is complex + +--- + +# Mesos (in practice) + +- Easy to setup a test cluster (in containers!) + +- Great to accommodate mixed workloads +
(see Marathon, Chronos, Aurora, and many more) + +- "Meh" if you only want to run Docker containers + +- In production on clusters of thousands of nodes + +- Open source project; commercial support available + +--- + +# Kubernetes (overview) + +- 1 year old + +- Designed specifically as a platform for containers +
("greenfield" design) + + - "pods" = groups of containers sharing network/storage + + - Scaling and HA managed by "replication controllers" + + - extensive use of "tags" instead of e.g. tree hierarchy + +- Initially designed around Docker, +
but doesn't hesitate to diverge in a few places + +--- + +# Kubernetes (in practice) + +- Network and service discovery is powerful, but complex +
.small[(different mechanisms within pod, between pods, for inbound traffic...)] + +- Initially designed around GCE +
.small[(currently relies on "native" features for fast networking and persistence)] + +- Adaptation is needed when it differs from Docker +
.small[(need to learn new API, new tooling, new concepts)] + +- Great deployment platform ... +
but no developer experience yet + +--- + +# Swarm (in theory) + +- Consolidates multiple Docker hosts into a single one + +- "Looks like" a Docker daemon, but it dispatches (schedules) your containers on multiple daemons -- Swarm talks the Docker API front and back +- Talks the Docker API front and back +
(leverages the Docker API and ecosystem) -- Swarm is open source and written in Go (like Docker) +- Open source and written in Go (like Docker) -- Swarm was started by two of the original Docker authors +- Started by two of the original Docker authors
([@aluzzardi](https://twitter.com/aluzzardi) and [@vieux](https://twitter.com/vieux)) -- Swarm is not stable yet (version 0.3 right now) +--- + +# Swarm (in practice) + +- Not stable yet (version 0.3 right now) + +- OK for some scenarios (Jenkins, grid...) + +- Not OK (yet) for Compose build, links... + +- We'll see it (briefly) in action + +--- + +# PAAS on Docker + +- The PAAS workflow: *just push code* +
(inspired by Heroku, dotCloud...) + +- TL,DR: easier for devs, harder for ops, +
some very opinionated choices + +- A few examples: +
(Non-exhaustive list!!!) + + - Cloud Foundry + - Deis + - Dokku + - Flynn + - Tsuru + +--- + +# A few other tools + +- Flocker + + - manage/migrate stateful containers + +- Powerstrip + + - sits in front of the Docker API + + - great to implement your own experiments + +- Weave + + - overlay network so that containers can ping each other + +... And many more! + +--- + +class: pic + +![Here Be Dragons](dragons.jpg) + +--- + +# Warning: here be dragons + +- So far, we've used stable products (versions 1.X) + +- We're going to expore experimental software + +- **Use at your own risk** + +--- + +# Introducing Swarm + +![Swarm Logo](swarm.png) --- @@ -1467,17 +1630,17 @@ Some Redis commands: `"SET key value"` `"GET key"` - Replace all `links` with static `/etc/hosts` entries -- Those entries will map to `127.0.0.X` +- Those entries will map to `127.127.0.X`
(with different `X` for each service) -- Example: `redis` will point to `127.0.0.2` +- Example: `redis` will point to `127.127.0.2`
(instead of a container address) - Start all services; scale them if we want
(at this point, they will all fail to connect) - Start ambassadors in the services' namespace; -
each ambassador will listen on the right `127.0.0.X` +
each ambassador will listen on the right `127.127.0.X` .icon[![Warning](warning.png)] Services should try to reconnect! @@ -1557,18 +1720,6 @@ Some Redis commands: `"SET key value"` `"GET key"` --- -# Last words - -- Kubernetes - -- Mesos - -- Powerstrip - -- Weave - ---- - class: title # Thanks!
Questions?