diff --git a/slides/intro-container-security.yml.html b/slides/intro-container-security.yml.html
index 1a0d8f7..3a9b0c7 100644
--- a/slides/intro-container-security.yml.html
+++ b/slides/intro-container-security.yml.html
@@ -31,10 +31,13 @@ i share: Introduction Container Security and Hardening<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-container-security.yml.html
+ M slides/swarm-halfday.yml.html
+ M slides/swarm-selfpaced.yml.html
+ M slides/swarm-video.yml.html
 
 ```
 
-These slides have been built from commit: 03e6aa0
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-fd-docker.yml.html b/slides/intro-fd-docker.yml.html
index 377fb1e..3c602c8 100644
--- a/slides/intro-fd-docker.yml.html
+++ b/slides/intro-fd-docker.yml.html
@@ -32,10 +32,13 @@ Introduction to Containers in an Airgapped Environment<br/>
  M slides/airgapped/Importing_Images.md
  M slides/intro-container-security.yml.html
  M slides/intro-fd-docker.yml.html
+ M slides/swarm-halfday.yml.html
+ M slides/swarm-selfpaced.yml.html
+ M slides/swarm-video.yml.html
 
 ```
 
-These slides have been built from commit: 03e6aa0
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
@@ -2866,7 +2869,7 @@ node1:443/python    latest    0a6cd0db41a4   2 weeks ago   919MB
 ubuntu              22.04     1f6ddc1b2547   2 weeks ago   77.8MB
 registry            latest    65f3b3441f04   3 weeks ago   24MB
 
-$ docker push node1:5000/python
+$ docker push node1:443/python
 Using default tag: latest
 The push refers to repository [node1:443/python]
 30563becc00e: Pushed
diff --git a/slides/intro-fd-k8s-deployments.yml.html b/slides/intro-fd-k8s-deployments.yml.html
index af5f985..d2f32d0 100644
--- a/slides/intro-fd-k8s-deployments.yml.html
+++ b/slides/intro-fd-k8s-deployments.yml.html
@@ -33,10 +33,13 @@ Introduction to Helm and friends<br/>
  M slides/intro-container-security.yml.html
  M slides/intro-fd-docker.yml.html
  M slides/intro-fd-k8s-deployments.yml.html
+ M slides/swarm-halfday.yml.html
+ M slides/swarm-selfpaced.yml.html
+ M slides/swarm-video.yml.html
 
 ```
 
-These slides have been built from commit: 03e6aa0
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-fd-k8s.yml.html b/slides/intro-fd-k8s.yml.html
index 162e700..ca869c9 100644
--- a/slides/intro-fd-k8s.yml.html
+++ b/slides/intro-fd-k8s.yml.html
@@ -34,10 +34,13 @@ Introduction to Kubernetes<br/>
  M slides/intro-fd-docker.yml.html
  M slides/intro-fd-k8s-deployments.yml.html
  M slides/intro-fd-k8s.yml.html
+ M slides/swarm-halfday.yml.html
+ M slides/swarm-selfpaced.yml.html
+ M slides/swarm-video.yml.html
 
 ```
 
-These slides have been built from commit: 03e6aa0
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-fullday.yml.html b/slides/intro-fullday.yml.html
index a879f93..f01feaf 100644
--- a/slides/intro-fullday.yml.html
+++ b/slides/intro-fullday.yml.html
@@ -35,10 +35,13 @@ Introduction<br/>to Containers<br/>
  M slides/intro-fd-k8s-deployments.yml.html
  M slides/intro-fd-k8s.yml.html
  M slides/intro-fullday.yml.html
+ M slides/swarm-halfday.yml.html
+ M slides/swarm-selfpaced.yml.html
+ M slides/swarm-video.yml.html
 
 ```
 
-These slides have been built from commit: 03e6aa0
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-selfpaced.yml.html b/slides/intro-selfpaced.yml.html
index 96fc903..de9e834 100644
--- a/slides/intro-selfpaced.yml.html
+++ b/slides/intro-selfpaced.yml.html
@@ -36,10 +36,13 @@ Introduction<br/>to Containers<br/>
  M slides/intro-fd-k8s.yml.html
  M slides/intro-fullday.yml.html
  M slides/intro-selfpaced.yml.html
+ M slides/swarm-halfday.yml.html
+ M slides/swarm-selfpaced.yml.html
+ M slides/swarm-video.yml.html
 
 ```
 
-These slides have been built from commit: 03e6aa0
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-triodos-1-day.yml.html b/slides/intro-triodos-1-day.yml.html
index 0b2bee5..34d050a 100644
--- a/slides/intro-triodos-1-day.yml.html
+++ b/slides/intro-triodos-1-day.yml.html
@@ -37,10 +37,13 @@ Triodos Introduction to <br/>Containers and orchestration <br/>with Kubernetes
  M slides/intro-fullday.yml.html
  M slides/intro-selfpaced.yml.html
  M slides/intro-triodos-1-day.yml.html
+ M slides/swarm-halfday.yml.html
+ M slides/swarm-selfpaced.yml.html
+ M slides/swarm-video.yml.html
 
 ```
 
-These slides have been built from commit: 03e6aa0
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-twodays.yml.html b/slides/intro-twodays.yml.html
index 5510175..e69de29 100644
--- a/slides/intro-twodays.yml.html
+++ b/slides/intro-twodays.yml.html
@@ -1,11367 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>Introduction to Containers </title>
-    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
-    <link rel="stylesheet" href="workshop.css">
-  </head>
-  <body>
-    <!--
-    <div style="position: absolute; left: 20%; right: 20%; top: 30%;">
-      <h1 style="font-size: 3em;">Loading ...</h1>
-      The slides should show up here. If they don't, it might be
-      because you are accessing this file directly from your filesystem.
-      It needs to be served from a web server. You can try this:
-      <pre>
-        docker-compose up -d
-        open http://localhost:8888/workshop.html # on MacOS
-        xdg-open http://localhost:8888/workshop.html # on Linux
-      </pre>
-      Once the slides are loaded, this notice disappears when you
-      go full screen (e.g. by hitting "f").
-    </div>
-    -->
-    <textarea id="source">class: title, self-paced
-
-Introduction<br/>to Containers<br/>
-
-<!-- .nav[*Self-paced version*] -->
-
-.debug[
-```
- M slides/airgapped/Importing_Images.md
-
-```
-
-These slides have been built from commit: 03e6aa0
-
-
-[shared/title.md](""/tree/main/slides/shared/title.md)]
----
-
-class: title, in-person
-
-Introduction<br/>to Containers<br/><br/></br>
-
-.footnote[
-**Slides[:](https://www.youtube.com/watch?v=h16zyxiwDLY) https://container.training/**
-]
-
-<!--
-WiFi: **Something**<br/>
-Password: **Something**
-
-**Be kind to the WiFi!**<br/>
-*Use the 5G network.*
-*Don't use your hotspot.*<br/>
-*Don't stream videos or download big files during the workshop*<br/>
-*Thank you!*
--->
-
-.debug[[shared/title.md](""/tree/main/slides/shared/title.md)]
----
-## Introductions
-
-- Let's do a quick intro.
-
-- I am:
-
-  - 👨🏽‍🦲 Marco Verleun, container adept.
-
-- Who are you and what do you want to learn?
-
-
-<!-- ⚠️ This slide should be customized by the tutorial instructor(s). -->
-
-<!--
-
-- Hello! We are:
-
-   - 👷🏻‍♀️ AJ ([@s0ulshake], [EphemeraSearch], [Quantgene])
-
-   - 🚁 Alexandre ([@alexbuisine], Enix SAS)
-
-   - 🐳 Jérôme ([@jpetazzo], Ardan Labs)
-
-   - 🐳 Jérôme ([@jpetazzo], Enix SAS)
-
-   - 🐳 Jérôme ([@jpetazzo], Tiny Shell Script LLC)
-
--->
-
-<!--
-
-- The training will run for 4 hours, with a 10 minutes break every hour
-
-  (the middle break will be a bit longer)
-
--->
-
-<!--
-
-- The workshop will run from XXX to YYY
-
-- There will be a lunch break at ZZZ
-
-  (And coffee breaks!)
-
--->
-
-<!--
-
-- Feel free to interrupt for questions at any time
-
-- *Especially when you see full screen container pictures!*
-
-- Live feedback, questions, help: [Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)
-
--->
-
-<!--
-
-- You ~~should~~ must ask questions! Lots of questions!
-
-  (especially when you see full screen container pictures)
-
-- Use [Slack](https://dockercommunity.slack.com/messages/C7GKACWDV) to ask questions, get help, etc.
-
--->
-
-<!-- -->
-
-[@alexbuisine]: https://twitter.com/alexbuisine
-[EphemeraSearch]: https://ephemerasearch.com/
-[@jpetazzo]: https://twitter.com/jpetazzo
-[@s0ulshake]: https://twitter.com/s0ulshake
-[Quantgene]: https://www.quantgene.com/
-
-.debug[[logistics.md](""/tree/main/slides/logistics.md)]
----
-
-## Exercises
-
-- There is a series of exercises
-
-- To make the most out of the training, please try the exercises!
-
-  (it will help to practice and memorize the content of the day)
-
-- There is a git repo that you have to clone first
-.debug[[logistics.md](""/tree/main/slides/logistics.md)]
----
-## A brief introduction
-
-- This was initially written to support in-person, instructor-led workshops and tutorials
-
-- These materials are maintained by [Jérôme Petazzoni](https://twitter.com/jpetazzo) and [multiple contributors](https://github.com/jpetazzo/container.training/graphs/contributors)
-
-- You can also follow along on your own, at your own pace
-
-- We included as much information as possible in these slides
-
-- We recommend having a mentor to help you ...
-
-- ... Or be comfortable spending some time reading the Docker
- [documentation](https://docs.docker.com/) ...
-
-- ... And looking for answers in the [Docker forums](https://forums.docker.com),
-  [StackOverflow](http://stackoverflow.com/questions/tagged/docker),
-  and other outlets
-
-.debug[[containers/intro.md](""/tree/main/slides/containers/intro.md)]
----
-
-class: self-paced
-
-## Hands on, you shall practice
-
-- Nobody ever became a Jedi by spending their lives reading Wookiepedia
-
-- Likewise, it will take more than merely *reading* these slides
-  to make you an expert
-
-- These slides include *tons* of demos, exercises, and examples
-
-- They assume that you have access to a machine running Docker
-
-- If you are attending a workshop or tutorial:
-  <br/>you will be given specific instructions to access a cloud VM
-
-- If you are doing this on your own:
-  <br/>we will tell you how to install Docker or access a Docker environment
-
-.debug[[containers/intro.md](""/tree/main/slides/containers/intro.md)]
----
-## Accessing these slides now
-
-- We recommend that you open these slides in your browser:
-
-  https://container.training/
-
-- Use arrows to move to next/previous slide
-
-  (up, down, left, right, page up, page down)
-
-- Type a slide number + ENTER to go to that slide
-
-- The slide number is also visible in the URL bar
-
-  (e.g. .../#123 for slide 123)
-
-.debug[[shared/about-slides.md](""/tree/main/slides/shared/about-slides.md)]
----
-
-## Accessing these slides later
-
-- Slides will remain online so you can review them later if needed
-
-  (let's say we'll keep them online at least 1 year, how about that?)
-
-- You can download the slides using that URL:
-
-  https://container.training/slides.zip
-
-  (then open the file `intro-twodays.yml.html`)
-
-- You will find new versions of these slides on:
-
-  https://container.training/
-
-.debug[[shared/about-slides.md](""/tree/main/slides/shared/about-slides.md)]
----
-
-## These slides are open source
-
-- You are welcome to use, re-use, share these slides
-
-- These slides are written in Markdown
-
-- The sources of these slides are available in a public GitHub repository:
-
-  https://github.com/jpetazzo/container.training
-
-- Typos? Mistakes? Questions? Feel free to hover over the bottom of the slide ...
-
-.footnote[👇 Try it! The source file will be shown and you can view it on GitHub and fork and edit it.]
-
-<!--
-.lab[
-```open https://github.com/jpetazzo/container.training/tree/master/slides/common/about-slides.md```
-]
--->
-
-.debug[[shared/about-slides.md](""/tree/main/slides/shared/about-slides.md)]
----
-
-class: extra-details
-
-## Extra details
-
-- This slide has a little magnifying glass in the top left corner
-
-- This magnifying glass indicates slides that provide extra details
-
-- Feel free to skip them if:
-
-  - you are in a hurry
-
-  - you are new to this and want to avoid cognitive overload
-
-  - you want only the most essential information
-
-- You can review these slides another time if you want, they'll be waiting for you ☺
-
-.debug[[shared/about-slides.md](""/tree/main/slides/shared/about-slides.md)]
----
-## Chat room
-
-- We've set up a chat room that we will monitor during the workshop
-
-- Don't hesitate to use it to ask questions, or get help, or share feedback
-
-- The chat room will also be available after the workshop
-
-- Join the chat room: [Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)
-
-- Say hi in the chat room!
-
-.debug[[shared/chat-room-im.md](""/tree/main/slides/shared/chat-room-im.md)]
----
-
-name: toc-part-1
-
-## Part 1
-
-- [Docker 30,000ft overview](#toc-docker-ft-overview)
-
-- [Our training environment](#toc-our-training-environment)
-
-- [Our first containers](#toc-our-first-containers)
-
-- [Background containers](#toc-background-containers)
-
-- [Understanding Docker images](#toc-understanding-docker-images)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-2
-
-## Part 2
-
-- [Building images interactively](#toc-building-images-interactively)
-
-- [Building Docker images with a Dockerfile](#toc-building-docker-images-with-a-dockerfile)
-
-- [`CMD` and `ENTRYPOINT`](#toc-cmd-and-entrypoint)
-
-- [Copying files during the build](#toc-copying-files-during-the-build)
-
-- [Exercise — writing Dockerfiles](#toc-exercise--writing-dockerfiles)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-3
-
-## Part 3
-
-- [Tips for efficient Dockerfiles](#toc-tips-for-efficient-dockerfiles)
-
-- [Dockerfile examples](#toc-dockerfile-examples)
-
-- [Reducing image size](#toc-reducing-image-size)
-
-- [Multi-stage builds](#toc-multi-stage-builds)
-
-- [Publishing images to the Docker Hub](#toc-publishing-images-to-the-docker-hub)
-
-- [Exercise — writing better Dockerfiles](#toc-exercise--writing-better-dockerfiles)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-4
-
-## Part 4
-
-- [Naming and inspecting containers](#toc-naming-and-inspecting-containers)
-
-- [Labels](#toc-labels)
-
-- [Restarting and attaching to containers](#toc-restarting-and-attaching-to-containers)
-
-- [Getting inside a container](#toc-getting-inside-a-container)
-
-- [Limiting resources](#toc-limiting-resources)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-5
-
-## Part 5
-
-- [Container networking basics](#toc-container-networking-basics)
-
-- [Container network drivers](#toc-container-network-drivers)
-
-- [The Container Network Model](#toc-the-container-network-model)
-
-- [Service discovery with containers](#toc-service-discovery-with-containers)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-6
-
-## Part 6
-
-- [Local development workflow with Docker](#toc-local-development-workflow-with-docker)
-
-- [Working with volumes](#toc-working-with-volumes)
-
-- [Compose for development stacks](#toc-compose-for-development-stacks)
-
-- [Exercise — writing a Compose file](#toc-exercise--writing-a-compose-file)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-7
-
-## Part 7
-
-- [Installing Docker](#toc-installing-docker)
-
-- [Docker Engine and other container engines](#toc-docker-engine-and-other-container-engines)
-
-- [Init systems and PID 1](#toc-init-systems-and-pid-)
-
-- [Advanced Dockerfile Syntax](#toc-advanced-dockerfile-syntax)
-
-- [Buildkit](#toc-buildkit)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-8
-
-## Part 8
-
-- [Application Configuration](#toc-application-configuration)
-
-- [Logging](#toc-logging)
-
-- [Orchestration, an overview](#toc-orchestration-an-overview)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-9
-
-## Part 9
-
-- [Links and resources](#toc-links-and-resources)
-
-
-.debug[(auto-generated TOC)]
-
-
-
-.debug[[shared/toc.md](""/tree/main/slides/shared/toc.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]
-
----
-
-name: toc-docker-ft-overview
-class: title
-
- Docker 30,000ft overview
-
-.nav[
-[Previous part](#toc-)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-our-training-environment)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Docker 30,000ft overview
-
-In this lesson, we will learn about:
-
-* Why containers (non-technical elevator pitch)
-
-* Why containers (technical elevator pitch)
-
-* How Docker helps us to build, ship, and run
-
-* The history of containers
-
-We won't actually run Docker or containers in this chapter (yet!).
-
-Don't worry, we will get to that fast enough!
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-## Elevator pitch
-
-### (for your manager, your boss...)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-## OK... Why the buzz around containers?
-
-* The software industry has changed
-
-* Before:
-  * monolithic applications
-  * long development cycles
-  * single environment
-  * slowly scaling up
-
-* Now:
-  * decoupled services
-  * fast, iterative improvements
-  * multiple environments
-  * quickly scaling out
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-## Deployment becomes very complex
-
-* Many different stacks:
-  * languages
-  * frameworks
-  * databases
-
-* Many different targets:
-  * individual development environments
-  * pre-production, QA, staging...
-  * production: on prem, cloud, hybrid
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: pic
-
-## The deployment problem
-
-![problem](images/shipping-software-problem.png)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: pic
-
-## The matrix from hell
-
-![matrix](images/shipping-matrix-from-hell.png)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: pic
-
-## The parallel with the shipping industry
-
-![history](images/shipping-industry-problem.png)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: pic
-
-## Intermodal shipping containers
-
-![shipping](images/shipping-industry-solution.png)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: pic
-
-## A new shipping ecosystem
-
-![shipeco](images/shipping-indsutry-results.png)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: pic
-
-## A shipping container system for applications
-
-![shipapp](images/shipping-software-solution.png)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: pic
-
-## Eliminate the matrix from hell
-
-![elimatrix](images/shipping-matrix-solved.png)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-## Results
-
-* [Dev-to-prod reduced from 9 months to 15 minutes (ING)](
-  https://www.docker.com/sites/default/files/CS_ING_01.25.2015_1.pdf)
-
-* [Continuous integration job time reduced by more than 60% (BBC)](
-  https://www.docker.com/sites/default/files/CS_BBCNews_01.25.2015_1.pdf)
-
-* [Deploy 100 times a day instead of once a week (GILT)](
-  https://www.docker.com/sites/default/files/CS_Gilt%20Groupe_03.18.2015_0.pdf)
-
-* [70% infrastructure consolidation (MetLife)](
-  https://www.docker.com/customers/metlife-transforms-customer-experience-legacy-and-microservices-mashup)
-
-* [60% infrastructure consolidation (Intesa Sanpaolo)](
-  https://blog.docker.com/2017/11/intesa-sanpaolo-builds-resilient-foundation-banking-docker-enterprise-edition/)
-
-* [14x application density; 60% of legacy datacenter migrated in 4 months (GE Appliances)](
-  https://www.docker.com/customers/ge-uses-docker-enable-self-service-their-developers)
-
-* etc.
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-## Elevator pitch
-
-### (for your fellow devs and ops)
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-## Escape dependency hell
-
-1. Write installation instructions into an `INSTALL.txt` file
-
-2. Using this file, write an `install.sh` script that works *for you*
-
-3. Turn this file into a `Dockerfile`, test it on your machine
-
-4. If the Dockerfile builds on your machine, it will build *anywhere*
-
-5. Rejoice as you escape dependency hell and "works on my machine"
-
-Never again "worked in dev - ops problem now!"
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-## On-board developers and contributors rapidly
-
-1. Write Dockerfiles for your application components
-
-2. Use pre-made images from the Docker Hub (mysql, redis...)
-
-3. Describe your stack with a Compose file
-
-4. On-board somebody with two commands:
-
-```bash
-git clone ...
-docker-compose up
-```
-
-With this, you can create development, integration, QA environments in minutes!
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Implement reliable CI easily
-
-1. Build test environment with a Dockerfile or Compose file
-
-2. For each test run, stage up a new container or stack
-
-3. Each run is now in a clean environment
-
-4. No pollution from previous tests
-
-Way faster and cheaper than creating VMs each time!
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Use container images as build artefacts
-
-1. Build your app from Dockerfiles
-
-2. Store the resulting images in a registry
-
-3. Keep them forever (or as long as necessary)
-
-4. Test those images in QA, CI, integration...
-
-5. Run the same images in production
-
-6. Something goes wrong? Rollback to previous image
-
-7. Investigating old regression? Old image has your back!
-
-Images contain all the libraries, dependencies, etc. needed to run the app.
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Decouple "plumbing" from application logic
-
-1. Write your code to connect to named services ("db", "api"...)
-
-2. Use Compose to start your stack
-
-3. Docker will setup per-container DNS resolver for those names
-
-4. You can now scale, add load balancers, replication ... without changing your code
-
-Note: this is not covered in this intro level workshop!
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## What did Docker bring to the table?
-
-### Docker before/after
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Formats and APIs, before Docker
-
-* No standardized exchange format.
-  <br/>(No, a rootfs tarball is *not* a format!)
-
-* Containers are hard to use for developers.
-  <br/>(Where's the equivalent of `docker run debian`?)
-
-* As a result, they are *hidden* from the end users.
-
-* No re-usable components, APIs, tools.
-  <br/>(At best: VM abstractions, e.g. libvirt.)
-
-Analogy: 
-
-* Shipping containers are not just steel boxes.
-* They are steel boxes that are a standard size, with the same hooks and holes.
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Formats and APIs, after Docker
-
-* Standardize the container format, because containers were not portable.
-
-* Make containers easy to use for developers.
-
-* Emphasis on re-usable components, APIs, ecosystem of standard tools.
-
-* Improvement over ad-hoc, in-house, specific tools.
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Shipping, before Docker
-
-* Ship packages: deb, rpm, gem, jar, homebrew...
-
-* Dependency hell.
-
-* "Works on my machine."
-
-* Base deployment often done from scratch (debootstrap...) and unreliable.
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Shipping, after Docker
-
-* Ship container images with all their dependencies.
-
-* Images are bigger, but they are broken down into layers.
-
-* Only ship layers that have changed.
-
-* Save disk, network, memory usage.
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Example
-
-Layers:
-
-* CentOS
-* JRE
-* Tomcat
-* Dependencies
-* Application JAR
-* Configuration
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Devs vs Ops, before Docker
-
-* Drop a tarball (or a commit hash) with instructions.
-
-* Dev environment very different from production.
-
-* Ops don't always have a dev environment themselves ...
-
-* ... and when they do, it can differ from the devs'.
-
-* Ops have to sort out differences and make it work ...
-
-* ... or bounce it back to devs.
-
-* Shipping code causes frictions and delays.
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: extra-details
-
-## Devs vs Ops, after Docker
-
-* Drop a container image or a Compose file.
-
-* Ops can always run that container image.
-
-* Ops can always run that Compose file.
-
-* Ops still have to adapt to prod environment,
-  but at least they have a reference point.
-
-* Ops have tools allowing to use the same image
-  in dev and prod.
-
-* Devs can be empowered to make releases themselves
-  more easily.
-
-.debug[[containers/Docker_Overview.md](""/tree/main/slides/containers/Docker_Overview.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]
-
----
-
-name: toc-our-training-environment
-class: title
-
- Our training environment
-
-.nav[
-[Previous part](#toc-docker-ft-overview)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-our-first-containers)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Our training environment
-
-![SSH terminal](images/title-our-training-environment.jpg)
-
-.debug[[containers/Training_Environment.md](""/tree/main/slides/containers/Training_Environment.md)]
----
-
-## Our training environment
-
-- If you are attending a tutorial or workshop:
-
-  - a VM has been provisioned for each student
-
-- If you are doing or re-doing this course on your own, you can:
-
-  - install Docker locally (as explained in the chapter "Installing Docker")
-
-  - install Docker on e.g. a cloud VM
-
-  - use https://www.play-with-docker.com/ to instantly get a training environment
-
-.debug[[containers/Training_Environment.md](""/tree/main/slides/containers/Training_Environment.md)]
----
-
-## Our Docker VM
-
-*This section assumes that you are following this course as part of
-a tutorial, training or workshop, where each student is given an
-individual Docker VM.*
-
-- The VM is created just before the training.
-
-- It will stay up during the whole training.
-
-- It will be destroyed shortly after the training.
-
-- It comes pre-loaded with Docker and some other useful tools.
-
-.debug[[containers/Training_Environment.md](""/tree/main/slides/containers/Training_Environment.md)]
----
-
-## What *is* Docker?
-
-- "Installing Docker" really means "Installing the Docker Engine and CLI".
-
-- The Docker Engine is a daemon (a service running in the background).
-
-- This daemon manages containers, the same way that a hypervisor manages VMs.
-
-- We interact with the Docker Engine by using the Docker CLI.
-
-- The Docker CLI and the Docker Engine communicate through an API.
-
-- There are many other programs and client libraries which use that API.
-
-.debug[[containers/Training_Environment.md](""/tree/main/slides/containers/Training_Environment.md)]
----
-
-## Why don't we run Docker locally?
-
-- We are going to download container images and distribution packages.
-
-- This could put a bit of stress on the local WiFi and slow us down.
-
-- Instead, we use a remote VM that has a good connectivity
-
-- In some rare cases, installing Docker locally is challenging:
-
-  - no administrator/root access (computer managed by strict corp IT)
-
-  - 32-bit CPU or OS
-
-  - old OS version (e.g. CentOS 6, OSX pre-Yosemite, Windows 7)
-
-- It's better to spend time learning containers than fiddling with the installer!
-
-.debug[[containers/Training_Environment.md](""/tree/main/slides/containers/Training_Environment.md)]
----
-
-## Connecting to your Virtual Machine
-
-You need an SSH client.
-
-* On OS X, Linux, and other UNIX systems, just use `ssh`:
-
-```bash
-$ ssh <login>@<ip-address>
-```
-
-* On Windows, if you don't have an SSH client, you can download:
-
-  * Putty (www.putty.org)
-
-  * Git BASH (https://git-for-windows.github.io/)
-
-  * MobaXterm (https://mobaxterm.mobatek.net/)
-
-.debug[[containers/Training_Environment.md](""/tree/main/slides/containers/Training_Environment.md)]
----
-
-class: in-person
-
-## `tailhist`
-
-The shell history of the instructor is available online in real time.
-
-Note the IP address of the instructor's virtual machine (A.B.C.D).
-
-Open http://A.B.C.D:1088 in your browser and you should see the history.
-
-The history is updated in real time (using a WebSocket connection).
-
-It should be green when the WebSocket is connected.
-
-If it turns red, reloading the page should fix it.
-
-.debug[[containers/Training_Environment.md](""/tree/main/slides/containers/Training_Environment.md)]
----
-
-## Checking your Virtual Machine
-
-Once logged in, make sure that you can run a basic Docker command:
-
-.small[
-```bash
-$ docker version
-Client:
- Version:       18.03.0-ce
- API version:   1.37
- Go version:    go1.9.4
- Git commit:    0520e24
- Built:         Wed Mar 21 23:10:06 2018
- OS/Arch:       linux/amd64
- Experimental:  false
- Orchestrator:  swarm
-
-Server:
- Engine:
-  Version:      18.03.0-ce
-  API version:  1.37 (minimum version 1.12)
-  Go version:   go1.9.4
-  Git commit:   0520e24
-  Built:        Wed Mar 21 23:08:35 2018
-  OS/Arch:      linux/amd64
-  Experimental: false
-```
-]
-
-If this doesn't work, raise your hand so that an instructor can assist you!
-
-???
-
-:EN:Container concepts
-:FR:Premier contact avec les conteneurs
-
-:EN:- What's a container engine?
-:FR:- Qu'est-ce qu'un *container engine* ?
-
-.debug[[containers/Training_Environment.md](""/tree/main/slides/containers/Training_Environment.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg)]
-
----
-
-name: toc-our-first-containers
-class: title
-
- Our first containers
-
-.nav[
-[Previous part](#toc-our-training-environment)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-background-containers)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Our first containers
-
-![Colorful plastic tubs](images/title-our-first-containers.jpg)
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Objectives
-
-At the end of this lesson, you will have:
-
-* Seen Docker in action.
-
-* Started your first containers.
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Hello World
-
-In your Docker environment, just run the following command:
-
-```bash
-$ docker run busybox echo hello world
-hello world
-```
-
-(If your Docker install is brand new, you will also see a few extra lines,
-corresponding to the download of the `busybox` image.)
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## That was our first container!
-
-* We used one of the smallest, simplest images available: `busybox`.
-
-* `busybox` is typically used in embedded systems (phones, routers...)
-
-* We ran a single process and echo'ed `hello world`.
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## A more useful container
-
-Let's run a more exciting container:
-
-```bash
-$ docker run -it ubuntu
-root@04c0bb0a6c07:/#
-```
-
-* This is a brand new container.
-
-* It runs a bare-bones, no-frills `ubuntu` system.
-
-* `-it` is shorthand for `-i -t`.
-
-  * `-i` tells Docker to connect us to the container's stdin.
-
-  * `-t` tells Docker that we want a pseudo-terminal.
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Do something in our container
-
-Try to run `figlet` in our container.
-
-```bash
-root@04c0bb0a6c07:/# figlet hello
-bash: figlet: command not found
-```
-
-Alright, we need to install it.
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Install a package in our container
-
-We want `figlet`, so let's install it:
-
-```bash
-root@04c0bb0a6c07:/# apt-get update
-...
-Fetched 1514 kB in 14s (103 kB/s)
-Reading package lists... Done
-root@04c0bb0a6c07:/# apt-get install figlet
-Reading package lists... Done
-...
-```
-
-One minute later, `figlet` is installed!
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Try to run our freshly installed program
-
-The `figlet` program takes a message as parameter.
-
-```bash
-root@04c0bb0a6c07:/# figlet hello
- _          _ _       
-| |__   ___| | | ___  
-| '_ \ / _ \ | |/ _ \ 
-| | | |  __/ | | (_) |
-|_| |_|\___|_|_|\___/ 
-```
-
-Beautiful! 😍
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-class: in-person
-
-## Counting packages in the container
-
-Let's check how many packages are installed there.
-
-```bash
-root@04c0bb0a6c07:/# dpkg -l | wc -l
-97
-```
-
-* `dpkg -l` lists the packages installed in our container
-
-* `wc -l` counts them
-
-How many packages do we have on our host?
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-class: in-person
-
-## Counting packages on the host
-
-Exit the container by logging out of the shell, like you would usually do.
-
-(E.g. with `^D` or `exit`)
-
-```bash
-root@04c0bb0a6c07:/# exit
-```
-
-Now, try to:
-
-* run `dpkg -l | wc -l`. How many packages are installed?
-
-* run `figlet`. Does that work?
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-class: self-paced
-
-## Comparing the container and the host
-
-Exit the container by logging out of the shell, with `^D` or `exit`.
-
-Now try to run `figlet`. Does that work?
-
-(It shouldn't; except if, by coincidence, you are running on a machine where figlet was installed before.)
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Host and containers are independent things
-
-* We ran an `ubuntu` container on an Linux/Windows/macOS host.
-
-* They have different, independent packages.
-
-* Installing something on the host doesn't expose it to the container.
-
-* And vice-versa.
-
-* Even if both the host and the container have the same Linux distro!
-
-* We can run *any container* on *any host*.
-
-  (One exception: Windows containers can only run on Windows hosts; at least for now.)
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Where's our container?
-
-* Our container is now in a *stopped* state.
-
-* It still exists on disk, but all compute resources have been freed up.
-
-* We will see later how to get back to that container.
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Starting another container
-
-What if we start a new container, and try to run `figlet` again?
- 
-```bash
-$ docker run -it ubuntu
-root@b13c164401fb:/# figlet
-bash: figlet: command not found
-```
-
-* We started a *brand new container*.
-
-* The basic Ubuntu image was used, and `figlet` is not here.
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Where's my container?
-
-* Can we reuse that container that we took time to customize?
-
-  *We can, but that's not the default workflow with Docker.*
-
-* What's the default workflow, then?
-
-  *Always start with a fresh container.*
-  <br/>
-  *If we need something installed in our container, build a custom image.*
-
-* That seems complicated!
-
-  *We'll see that it's actually pretty easy!*
-
-* And what's the point?
-
-  *This puts a strong emphasis on automation and repeatability. Let's see why ...*
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Pets vs. Cattle
-
-* In the "pets vs. cattle" metaphor, there are two kinds of servers.
-
-* Pets:
-
-  * have distinctive names and unique configurations
-
-  * when they have an outage, we do everything we can to fix them
-
-* Cattle:
-
-  * have generic names (e.g. with numbers) and generic configuration
-
-  * configuration is enforced by configuration management, golden images ...
-
-  * when they have an outage, we can replace them immediately with a new server
-
-* What's the connection with Docker and containers?
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Local development environments
-
-* When we use local VMs (with e.g. VirtualBox or VMware), our workflow looks like this:
-
-  * create VM from base template (Ubuntu, CentOS...)
-
-  * install packages, set up environment
-
-  * work on project
-
-  * when done, shut down VM
-
-  * next time we need to work on project, restart VM as we left it
-
-  * if we need to tweak the environment, we do it live
-
-* Over time, the VM configuration evolves, diverges.
-
-* We don't have a clean, reliable, deterministic way to provision that environment.
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-## Local development with Docker
-
-* With Docker, the workflow looks like this:
-
-  * create container image with our dev environment
-
-  * run container with that image
-
-  * work on project
-
-  * when done, shut down container
-
-  * next time we need to work on project, start a new container
-
-  * if we need to tweak the environment, we create a new image
-
-* We have a clear definition of our environment, and can share it reliably with others.
-
-* Let's see in the next chapters how to bake a custom image with `figlet`!
-
-???
-
-:EN:- Running our first container
-:FR:- Lancer nos premiers conteneurs
-
-.debug[[containers/First_Containers.md](""/tree/main/slides/containers/First_Containers.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg)]
-
----
-
-name: toc-background-containers
-class: title
-
- Background containers
-
-.nav[
-[Previous part](#toc-our-first-containers)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-understanding-docker-images)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Background containers
-
-![Background containers](images/title-background-containers.jpg)
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Objectives
-
-Our first containers were *interactive*.
-
-We will now see how to:
-
-* Run a non-interactive container.
-* Run a container in the background.
-* List running containers.
-* Check the logs of a container.
-* Stop a container.
-* List stopped containers.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## A non-interactive container
-
-We will run a small custom container.
-
-This container just displays the time every second.
-
-```bash
-$ docker run jpetazzo/clock
-Fri Feb 20 00:28:53 UTC 2015
-Fri Feb 20 00:28:54 UTC 2015
-Fri Feb 20 00:28:55 UTC 2015
-...
-```
-
-* This container will run forever.
-* To stop it, press `^C`.
-* Docker has automatically downloaded the image `jpetazzo/clock`.
-* This image is a user image, created by `jpetazzo`.
-* We will hear more about user images (and other types of images) later.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## When `^C` doesn't work...
-
-Sometimes, `^C` won't be enough.
-
-Why? And how can we stop the container in that case?
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## What happens when we hit `^C`
-
-`SIGINT` gets sent to the container, which means:
-
-- `SIGINT` gets sent to PID 1 (default case)
-
-- `SIGINT` gets sent to *foreground processes* when running with `-ti`
-
-But there is a special case for PID 1: it ignores all signals!
-
-- except `SIGKILL` and `SIGSTOP`
-
-- except signals handled explicitly
-
-TL,DR: there are many circumstances when `^C` won't stop the container.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-class: extra-details
-
-## Why is PID 1 special?
-
-- PID 1 has some extra responsibilities:
-
-  - it starts (directly or indirectly) every other process
-
-  - when a process exits, its processes are "reparented" under PID 1
-
-- When PID 1 exits, everything stops:
-
-  - on a "regular" machine, it causes a kernel panic
-
-  - in a container, it kills all the processes
-
-- We don't want PID 1 to stop accidentally
-
-- That's why it has these extra protections
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## How to stop these containers, then?
-
-- Start another terminal and forget about them
-
-  (for now!)
-
-- We'll shortly learn about `docker kill`
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Run a container in the background
-
-Containers can be started in the background, with the `-d` flag (daemon mode):
-
-```bash
-$ docker run -d jpetazzo/clock
-47d677dcfba4277c6cc68fcaa51f932b544cab1a187c853b7d0caf4e8debe5ad
-```
-
-* We don't see the output of the container.
-* But don't worry: Docker collects that output and logs it!
-* Docker gives us the ID of the container.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## List running containers
-
-How can we check that our container is still running?
-
-With `docker ps`, just like the UNIX `ps` command, lists running processes.
-
-```bash
-$ docker ps
-CONTAINER ID  IMAGE           ...  CREATED        STATUS        ...
-47d677dcfba4  jpetazzo/clock  ...  2 minutes ago  Up 2 minutes  ...
-```
-
-Docker tells us:
-
-* The (truncated) ID of our container.
-* The image used to start the container.
-* That our container has been running (`Up`) for a couple of minutes.
-* Other information (COMMAND, PORTS, NAMES) that we will explain later.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Starting more containers
-
-Let's start two more containers.
-
-```bash
-$ docker run -d jpetazzo/clock
-57ad9bdfc06bb4407c47220cf59ce21585dce9a1298d7a67488359aeaea8ae2a
-```
-
-```bash
-$ docker run -d jpetazzo/clock
-068cc994ffd0190bbe025ba74e4c0771a5d8f14734af772ddee8dc1aaf20567d
-```
-
-Check that `docker ps` correctly reports all 3 containers.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Viewing only the last container started
-
-When many containers are already running, it can be useful to
-see only the last container that was started.
-
-This can be achieved with the `-l` ("Last") flag:
-
-```bash
-$ docker ps -l
-CONTAINER ID  IMAGE           ...  CREATED        STATUS        ...
-068cc994ffd0  jpetazzo/clock  ...  2 minutes ago  Up 2 minutes  ...
-```
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## View only the IDs of the containers
-
-Many Docker commands will work on container IDs: `docker stop`, `docker rm`...
-
-If we want to list only the IDs of our containers (without the other columns
-or the header line),
-we can use the `-q` ("Quiet", "Quick") flag:
-
-```bash
-$ docker ps -q
-068cc994ffd0
-57ad9bdfc06b
-47d677dcfba4
-```
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Combining flags
-
-We can combine `-l` and `-q` to see only the ID of the last container started:
-
-```bash
-$ docker ps -lq
-068cc994ffd0
-```
-
-At a first glance, it looks like this would be particularly useful in scripts.
-
-However, if we want to start a container and get its ID in a reliable way,
-it is better to use `docker run -d`, which we will cover in a bit.
-
-(Using `docker ps -lq` is prone to race conditions: what happens if someone
-else, or another program or script, starts another container just before
-we run `docker ps -lq`?)
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## View the logs of a container
-
-We told you that Docker was logging the container output.
-
-Let's see that now.
-
-```bash
-$ docker logs 068
-Fri Feb 20 00:39:52 UTC 2015
-Fri Feb 20 00:39:53 UTC 2015
-...
-```
-
-* We specified a *prefix* of the full container ID.
-* You can, of course, specify the full ID.
-* The `logs` command will output the *entire* logs of the container.
-  <br/>(Sometimes, that will be too much. Let's see how to address that.)
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## View only the tail of the logs
-
-To avoid being spammed with eleventy pages of output,
-we can use the `--tail` option:
-
-```bash
-$ docker logs --tail 3 068
-Fri Feb 20 00:55:35 UTC 2015
-Fri Feb 20 00:55:36 UTC 2015
-Fri Feb 20 00:55:37 UTC 2015
-```
-
-* The parameter is the number of lines that we want to see.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Follow the logs in real time
-
-Just like with the standard UNIX command `tail -f`, we can
-follow the logs of our container:
-
-```bash
-$ docker logs --tail 1 --follow 068
-Fri Feb 20 00:57:12 UTC 2015
-Fri Feb 20 00:57:13 UTC 2015
-^C
-```
-
-* This will display the last line in the log file.
-* Then, it will continue to display the logs in real time.
-* Use `^C` to exit.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Stop our container
-
-There are two ways we can terminate our detached container.
-
-* Killing it using the `docker kill` command.
-* Stopping it using the `docker stop` command.
-
-The first one stops the container immediately, by using the
-`KILL` signal.
-
-The second one is more graceful. It sends a `TERM` signal,
-and after 10 seconds, if the container has not stopped, it
-sends `KILL.`
-
-Reminder: the `KILL` signal cannot be intercepted, and will
-forcibly terminate the container.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Stopping our containers
-
-Let's stop one of those containers:
-
-```bash
-$ docker stop 47d6
-47d6
-```
-
-This will take 10 seconds:
-
-* Docker sends the TERM signal;
-* the container doesn't react to this signal
-  (it's a simple Shell script with no special
-  signal handling);
-* 10 seconds later, since the container is still
-  running, Docker sends the KILL signal;
-* this terminates the container.
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## Killing the remaining containers
-
-Let's be less patient with the two other containers:
-
-```bash
-$ docker kill 068 57ad
-068
-57ad
-```
-
-The `stop` and `kill` commands can take multiple container IDs.
-
-Those containers will be terminated immediately (without
-the 10-second delay).
-
-Let's check that our containers don't show up anymore:
-
-```bash
-$ docker ps
-```
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-## List stopped containers
-
-We can also see stopped containers, with the `-a` (`--all`) option.
-
-```bash
-$ docker ps -a
-CONTAINER ID  IMAGE           ...  CREATED      STATUS
-068cc994ffd0  jpetazzo/clock  ...  21 min. ago  Exited (137) 3 min. ago
-57ad9bdfc06b  jpetazzo/clock  ...  21 min. ago  Exited (137) 3 min. ago
-47d677dcfba4  jpetazzo/clock  ...  23 min. ago  Exited (137) 3 min. ago
-5c1dfd4d81f1  jpetazzo/clock  ...  40 min. ago  Exited (0) 40 min. ago
-b13c164401fb  ubuntu          ...  55 min. ago  Exited (130) 53 min. ago
-```
-
-???
-
-:EN:- Foreground and background containers
-:FR:- Exécution interactive ou en arrière-plan
-
-.debug[[containers/Background_Containers.md](""/tree/main/slides/containers/Background_Containers.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg)]
-
----
-
-name: toc-understanding-docker-images
-class: title
-
- Understanding Docker images
-
-.nav[
-[Previous part](#toc-background-containers)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-building-images-interactively)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Understanding Docker images
-
-![image](images/title-understanding-docker-images.png)
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Objectives
-
-In this section, we will explain:
-
-* What is an image.
-
-* What is a layer.
-
-* The various image namespaces.
-
-* How to search and download images.
-
-* Image tags and when to use them.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## What is an image?
-
-* Image = files + metadata
-
-* These files form the root filesystem of our container.
-
-* The metadata can indicate a number of things, e.g.:
-
-  * the author of the image
-  * the command to execute in the container when starting it
-  * environment variables to be set
-  * etc.
-
-* Images are made of *layers*, conceptually stacked on top of each other.
-
-* Each layer can add, change, and remove files and/or metadata.
-
-* Images can share layers to optimize disk usage, transfer times, and memory use.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Example for a Java webapp
-
-Each of the following items will correspond to one layer:
-
-* CentOS base layer
-* Packages and configuration files added by our local IT
-* JRE
-* Tomcat
-* Our application's dependencies
-* Our application code and assets
-* Our application configuration
-
-(Note: app config is generally added by orchestration facilities.)
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-class: pic
-
-## The read-write layer
-
-![layers](images/container-layers.jpg)
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Differences between containers and images
-
-* An image is a read-only filesystem.
-
-* A container is an encapsulated set of processes,
-
-  running in a read-write copy of that filesystem.
-
-* To optimize container boot time, *copy-on-write* is used
-  instead of regular copy.
-
-* `docker run` starts a container from a given image.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-class: pic
-
-## Multiple containers sharing the same image
-
-![layers](images/sharing-layers.jpg)
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Comparison with object-oriented programming
-
-* Images are conceptually similar to *classes*.
-
-* Layers are conceptually similar to *inheritance*.
-
-* Containers are conceptually similar to *instances*.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Wait a minute...
-
-If an image is read-only, how do we change it?
-
-* We don't.
-
-* We create a new container from that image.
-
-* Then we make changes to that container.
-
-* When we are satisfied with those changes, we transform them into a new layer.
-
-* A new image is created by stacking the new layer on top of the old image.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## A chicken-and-egg problem
-
-* The only way to create an image is by "freezing" a container.
-
-* The only way to create a container is by instantiating an image.
-
-* Help!
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Creating the first images
-
-There is a special empty image called `scratch`.
-
-* It allows to *build from scratch*.
-
-The `docker import` command loads a tarball into Docker.
-
-* The imported tarball becomes a standalone image.
-* That new image has a single layer.
-
-Note: you will probably never have to do this yourself.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Creating other images
-
-`docker commit`
-
-* Saves all the changes made to a container into a new layer.
-* Creates a new image (effectively a copy of the container).
-
-`docker build` **(used 99% of the time)**
-
-* Performs a repeatable build sequence.
-* This is the preferred method!
-
-We will explain both methods in a moment.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Images namespaces
-
-There are three namespaces:
-
-* Official images
-
-    e.g. `ubuntu`, `busybox` ...
-
-* User (and organizations) images
-
-    e.g. `jpetazzo/clock`
-
-* Self-hosted images
-
-    e.g. `registry.example.com:5000/my-private/image`
-
-Let's explain each of them.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Root namespace
-
-The root namespace is for official images.
-
-They are gated by Docker Inc.
-
-They are generally authored and maintained by third parties.
-
-Those images include:
-
-* Small, "swiss-army-knife" images like busybox.
-
-* Distro images to be used as bases for your builds, like ubuntu, fedora...
-
-* Ready-to-use components and services, like redis, postgresql...
-
-* Over 150 at this point!
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## User namespace
-
-The user namespace holds images for Docker Hub users and organizations.
-
-For example:
-
-```bash
-jpetazzo/clock
-```
-
-The Docker Hub user is:
-
-```bash
-jpetazzo
-```
-
-The image name is:
-
-```bash
-clock
-```
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Self-hosted namespace
-
-This namespace holds images which are not hosted on Docker Hub, but on third
-party registries.
-
-They contain the hostname (or IP address), and optionally the port, of the
-registry server.
-
-For example:
-
-```bash
-localhost:5000/wordpress
-```
-
-* `localhost:5000` is the host and port of the registry
-* `wordpress` is the name of the image
-
-Other examples:
-
-```bash
-quay.io/coreos/etcd
-gcr.io/google-containers/hugo
-```
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## How do you store and manage images?
-
-Images can be stored:
-
-* On your Docker host.
-* In a Docker registry.
-
-You can use the Docker client to download (pull) or upload (push) images.
-
-To be more accurate: you can use the Docker client to tell a Docker Engine
-to push and pull images to and from a registry.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Showing current images
-
-Let's look at what images are on our host now.
-
-```bash
-$ docker images
-REPOSITORY       TAG       IMAGE ID       CREATED         SIZE
-fedora           latest    ddd5c9c1d0f2   3 days ago      204.7 MB
-centos           latest    d0e7f81ca65c   3 days ago      196.6 MB
-ubuntu           latest    07c86167cdc4   4 days ago      188 MB
-redis            latest    4f5f397d4b7c   5 days ago      177.6 MB
-postgres         latest    afe2b5e1859b   5 days ago      264.5 MB
-alpine           latest    70c557e50ed6   5 days ago      4.798 MB
-debian           latest    f50f9524513f   6 days ago      125.1 MB
-busybox          latest    3240943c9ea3   2 weeks ago     1.114 MB
-training/namer   latest    902673acc741   9 months ago    289.3 MB
-jpetazzo/clock   latest    12068b93616f   12 months ago   2.433 MB
-```
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Searching for images
-
-We cannot list *all* images on a remote registry, but
-we can search for a specific keyword:
-
-```bash
-$ docker search marathon
-NAME                     DESCRIPTION                     STARS  OFFICIAL  AUTOMATED
-mesosphere/marathon      A cluster-wide init and co...   105              [OK]
-mesoscloud/marathon      Marathon                        31               [OK]
-mesosphere/marathon-lb   Script to update haproxy b...   22               [OK]
-tobilg/mongodb-marathon  A Docker image to start a ...   4                [OK]
-```
-
-
-* "Stars" indicate the popularity of the image.
-
-* "Official" images are those in the root namespace.
-
-* "Automated" images are built automatically by the Docker Hub.
-  <br/>(This means that their build recipe is always available.)
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Downloading images
-
-There are two ways to download images.
-
-* Explicitly, with `docker pull`.
-
-* Implicitly, when executing `docker run` and the image is not found locally.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Pulling an image
-
-```bash
-$ docker pull debian:jessie
-Pulling repository debian
-b164861940b8: Download complete
-b164861940b8: Pulling image (jessie) from debian
-d1881793a057: Download complete
-```
-
-* As seen previously, images are made up of layers.
-
-* Docker has downloaded all the necessary layers.
-
-* In this example, `:jessie` indicates which exact version of Debian
-  we would like.
-
-  It is a *version tag*.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Image and tags
-
-* Images can have tags.
-
-* Tags define image versions or variants.
-
-* `docker pull ubuntu` will refer to `ubuntu:latest`.
-
-* The `:latest` tag is generally updated often.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## When to (not) use tags
-
-Don't specify tags:
-
-* When doing rapid testing and prototyping.
-* When experimenting.
-* When you want the latest version.
-
-Do specify tags:
-
-* When recording a procedure into a script.
-* When going to production.
-* To ensure that the same version will be used everywhere.
-* To ensure repeatability later.
-
-This is similar to what we would do with `pip install`, `npm install`, etc.
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-class: extra-details
-
-## Multi-arch images
-
-- An image can support multiple architectures
-
-- More precisely, a specific *tag* in a given *repository* can have either:
-
-  - a single *manifest* referencing an image for a single architecture
-
-  - a *manifest list* (or *fat manifest*) referencing multiple images
-
-- In a *manifest list*, each image is identified by a combination of:
-
-  - `os` (linux, windows)
-
-  - `architecture` (amd64, arm, arm64...)
-
-  - optional fields like `variant` (for arm and arm64), `os.version` (for windows)
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-class: extra-details
-
-## Working with multi-arch images
-
-- The Docker Engine will pull "native" images when available
-
-  (images matching its own os/architecture/variant)
-
-- We can ask for a specific image platform with `--platform`
-
-- The Docker Engine can run non-native images thanks to QEMU+binfmt
-
-  (automatically on Docker Desktop; with a bit of setup on Linux)
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-## Section summary
-
-We've learned how to:
-
-* Understand images and layers.
-* Understand Docker image namespacing.
-* Search and download images.
-
-???
-
-:EN:Building images
-:EN:- Containers, images, and layers
-:EN:- Image addresses and tags
-:EN:- Finding and transferring images
-
-:FR:Construire des images
-:FR:- La différence entre un conteneur et une image
-:FR:- La notion de *layer* partagé entre images
-
-.debug[[containers/Initial_Images.md](""/tree/main/slides/containers/Initial_Images.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg)]
-
----
-
-name: toc-building-images-interactively
-class: title
-
- Building images interactively
-
-.nav[
-[Previous part](#toc-understanding-docker-images)
-|
-[Back to table of contents](#toc-part-2)
-|
-[Next part](#toc-building-docker-images-with-a-dockerfile)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Building images interactively
-
-In this section, we will create our first container image.
-
-It will be a basic distribution image, but we will pre-install
-the package `figlet`.
-
-We will: 
-
-* Create a container from a base image.
-
-* Install software manually in the container, and turn it
-  into a new image.
-
-* Learn about new commands: `docker commit`, `docker tag`, and `docker diff`.
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-## The plan
-
-1. Create a container (with `docker run`) using our base distro of choice.
-
-2. Run a bunch of commands to install and set up our software in the container.
-
-3. (Optionally) review changes in the container with `docker diff`.
-
-4. Turn the container into a new image with `docker commit`.
-
-5. (Optionally) add tags to the image with `docker tag`.
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-## Setting up our container
-
-Start an Ubuntu container:
-
-```bash
-$ docker run -it ubuntu
-root@<yourContainerId>:#/
-```
-
-Run the command `apt-get update` to refresh the list of packages available to install.
-
-Then run the command `apt-get install figlet` to install the program we are interested in.
-
-```bash
-root@<yourContainerId>:#/ apt-get update && apt-get install figlet
-.... OUTPUT OF APT-GET COMMANDS ....
-```
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-## Inspect the changes
-
-Type `exit` at the container prompt to leave the interactive session.
-
-Now let's run `docker diff` to see the difference between the base image
-and our container.
-
-```bash
-$ docker diff <yourContainerId>
-C /root
-A /root/.bash_history
-C /tmp
-C /usr
-C /usr/bin
-A /usr/bin/figlet
-...
-```
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-class: x-extra-details
-
-## Docker tracks filesystem changes
-
-As explained before:
-
-* An image is read-only.
-
-* When we make changes, they happen in a copy of the image.
-
-* Docker can show the difference between the image, and its copy.
-
-* For performance, Docker uses copy-on-write systems.
-  <br/>(i.e. starting a container based on a big image
-  doesn't incur a huge copy.)
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-## Copy-on-write security benefits
-
-* `docker diff` gives us an easy way to audit changes
-
-  (à la Tripwire)
-
-* Containers can also be started in read-only mode
-
-  (their root filesystem will be read-only, but they can still have read-write data volumes)
-
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-## Commit our changes into a new image
-
-The `docker commit` command will create a new layer with those changes,
-and a new image using this new layer.
-
-```bash
-$ docker commit <yourContainerId>
-<newImageId>
-```
-
-The output of the `docker commit` command will be the ID for your newly created image.
-
-We can use it as an argument to `docker run`.
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-## Testing our new image
-
-Let's run this image:
-
-```bash
-$ docker run -it <newImageId>
-root@fcfb62f0bfde:/# figlet hello
- _          _ _       
-| |__   ___| | | ___  
-| '_ \ / _ \ | |/ _ \ 
-| | | |  __/ | | (_) |
-|_| |_|\___|_|_|\___/ 
-```
-
-It works! 🎉
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-## Tagging images
-
-Referring to an image by its ID is not convenient. Let's tag it instead.
-
-We can use the `tag` command:
-
-```bash
-$ docker tag <newImageId> figlet
-```
-
-But we can also specify the tag as an extra argument to `commit`:
-
-```bash
-$ docker commit <containerId> figlet
-```
-
-And then run it using its tag:
-
-```bash
-$ docker run -it figlet
-```
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-## What's next?
-
-Manual process = bad.
-
-Automated process = good.
-
-In the next chapter, we will learn how to automate the build
-process by writing a `Dockerfile`.
-
-???
-
-:EN:- Building our first images interactively
-:FR:- Fabriquer nos premières images à la main
-
-.debug[[containers/Building_Images_Interactively.md](""/tree/main/slides/containers/Building_Images_Interactively.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-housing.jpg)]
-
----
-
-name: toc-building-docker-images-with-a-dockerfile
-class: title
-
- Building Docker images with a Dockerfile
-
-.nav[
-[Previous part](#toc-building-images-interactively)
-|
-[Back to table of contents](#toc-part-2)
-|
-[Next part](#toc-cmd-and-entrypoint)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Building Docker images with a Dockerfile
-
-![Construction site with containers](images/title-building-docker-images-with-a-dockerfile.jpg)
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Objectives
-
-We will build a container image automatically, with a `Dockerfile`.
-
-At the end of this lesson, you will be able to:
-
-* Write a `Dockerfile`.
-
-* Build an image from a `Dockerfile`.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## `Dockerfile` overview
-
-* A `Dockerfile` is a build recipe for a Docker image.
-
-* It contains a series of instructions telling Docker how an image is constructed.
-
-* The `docker build` command builds an image from a `Dockerfile`.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Writing our first `Dockerfile`
-
-Our Dockerfile must be in a **new, empty directory**.
-
-1. Create a directory to hold our `Dockerfile`.
-
-```bash
-$ mkdir myimage
-```
-
-2. Create a `Dockerfile` inside this directory.
-
-```bash
-$ cd myimage
-$ vim Dockerfile
-```
-
-Of course, you can use any other editor of your choice.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Type this into our Dockerfile...
-
-```dockerfile
-FROM ubuntu
-RUN apt-get update
-RUN apt-get install figlet
-```
-
-* `FROM` indicates the base image for our build.
-
-* Each `RUN` line will be executed by Docker during the build.
-
-* Our `RUN` commands **must be non-interactive.**
-  <br/>(No input can be provided to Docker during the build.)
-
-* In many cases, we will add the `-y` flag to `apt-get`.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Build it!
-
-Save our file, then execute:
-
-```bash
-$ docker build -t figlet .
-```
-
-* `-t` indicates the tag to apply to the image.
-
-* `.` indicates the location of the *build context*.
-
-We will talk more about the build context later.
-
-To keep things simple for now: this is the directory where our Dockerfile is located.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## What happens when we build the image?
-
-It depends if we're using BuildKit or not!
-
-If there are lots of blue lines and the first line looks like this:
-```
-[+] Building 1.8s (4/6)
-```
-... then we're using BuildKit.
-
-If the output is mostly black-and-white and the first line looks like this:
-```
-Sending build context to Docker daemon  2.048kB
-```
-... then we're using the "classic" or "old-style" builder.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## To BuildKit or Not To BuildKit
-
-Classic builder:
-
-- copies the whole "build context" to the Docker Engine
-
-- linear (processes lines one after the other)
-
-- requires a full Docker Engine
-
-BuildKit:
-
-- only transfers parts of the "build context" when needed
-
-- will parallelize operations (when possible)
-
-- can run in non-privileged containers (e.g. on Kubernetes)
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## With the classic builder
-
-The output of `docker build` looks like this:
-
-.small[
-```bash
-docker build -t figlet .
-Sending build context to Docker daemon  2.048kB
-Step 1/3 : FROM ubuntu
- ---> f975c5035748
-Step 2/3 : RUN apt-get update
- ---> Running in e01b294dbffd
-(...output of the RUN command...)
-Removing intermediate container e01b294dbffd
- ---> eb8d9b561b37
-Step 3/3 : RUN apt-get install figlet
- ---> Running in c29230d70f9b
-(...output of the RUN command...)
-Removing intermediate container c29230d70f9b
- ---> 0dfd7a253f21
-Successfully built 0dfd7a253f21
-Successfully tagged figlet:latest
-```
-]
-
-* The output of the `RUN` commands has been omitted.
-* Let's explain what this output means.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Sending the build context to Docker
-
-```bash
-Sending build context to Docker daemon 2.048 kB
-```
-
-* The build context is the `.` directory given to `docker build`.
-
-* It is sent (as an archive) by the Docker client to the Docker daemon.
-
-* This allows to use a remote machine to build using local files.
-
-* Be careful (or patient) if that directory is big and your link is slow.
-
-* You can speed up the process with a [`.dockerignore`](https://docs.docker.com/engine/reference/builder/#dockerignore-file) file
-
-  * It tells docker to ignore specific files in the directory
-
-  * Only ignore files that you won't need in the build context!
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Executing each step
-
-```bash
-Step 2/3 : RUN apt-get update
- ---> Running in e01b294dbffd
-(...output of the RUN command...)
-Removing intermediate container e01b294dbffd
- ---> eb8d9b561b37
-```
-
-* A container (`e01b294dbffd`) is created from the base image.
-
-* The `RUN` command is executed in this container.
-
-* The container is committed into an image (`eb8d9b561b37`).
-
-* The build container (`e01b294dbffd`) is removed.
-
-* The output of this step will be the base image for the next one.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## With BuildKit
-
-.small[
-```bash
-[+] Building 7.9s (7/7) FINISHED
- => [internal] load build definition from Dockerfile                                                 0.0s
- => => transferring dockerfile: 98B                                                                  0.0s
- => [internal] load .dockerignore                                                                    0.0s
- => => transferring context: 2B                                                                      0.0s
- => [internal] load metadata for docker.io/library/ubuntu:latest                                     1.2s
- => [1/3] FROM docker.io/library/ubuntu@sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386  3.2s
- => => resolve docker.io/library/ubuntu@sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386  0.0s
- => => sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386da88eb681d93 1.20kB / 1.20kB       0.0s
- => => sha256:1de4c5e2d8954bf5fa9855f8b4c9d3c3b97d1d380efe19f60f3e4107a66f5cae 943B / 943B           0.0s
- => => sha256:6a98cbe39225dadebcaa04e21dbe5900ad604739b07a9fa351dd10a6ebad4c1b 3.31kB / 3.31kB       0.0s
- => => sha256:80bc30679ac1fd798f3241208c14accd6a364cb8a6224d1127dfb1577d10554f 27.14MB / 27.14MB     2.3s
- => => sha256:9bf18fab4cfbf479fa9f8409ad47e2702c63241304c2cdd4c33f2a1633c5f85e 850B / 850B           0.5s
- => => sha256:5979309c983a2adeff352538937475cf961d49c34194fa2aab142effe19ed9c1 189B / 189B           0.4s
- => => extracting sha256:80bc30679ac1fd798f3241208c14accd6a364cb8a6224d1127dfb1577d10554f            0.7s
- => => extracting sha256:9bf18fab4cfbf479fa9f8409ad47e2702c63241304c2cdd4c33f2a1633c5f85e            0.0s
- => => extracting sha256:5979309c983a2adeff352538937475cf961d49c34194fa2aab142effe19ed9c1            0.0s
- => [2/3] RUN apt-get update                                                                         2.5s
- => [3/3] RUN apt-get install figlet                                                                 0.9s
- => exporting to image                                                                               0.1s
- => => exporting layers                                                                              0.1s
- => => writing image sha256:3b8aee7b444ab775975dfba691a72d8ac24af2756e0a024e056e3858d5a23f7c         0.0s
- => => naming to docker.io/library/figlet                                                            0.0s
- ```
- ]
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Understanding BuildKit output
-
-- BuildKit transfers the Dockerfile and the *build context*
-
-  (these are the first two `[internal]` stages)
-
-- Then it executes the steps defined in the Dockerfile
-
-  (`[1/3]`, `[2/3]`, `[3/3]`)
-
-- Finally, it exports the result of the build
-
-  (image definition + collection of layers)
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-class: extra-details
-
-## BuildKit plain output
-
-- When running BuildKit in e.g. a CI pipeline, its output will be different
-
-- We can see the same output format by using `--progress=plain`
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## The caching system
-
-If you run the same build again, it will be instantaneous. Why?
-
-* After each build step, Docker takes a snapshot of the resulting image.
-
-* Before executing a step, Docker checks if it has already built the same sequence.
-
-* Docker uses the exact strings defined in your Dockerfile, so:
-
-  * `RUN apt-get install figlet cowsay`
-    <br/> is different from
-    <br/> `RUN apt-get install cowsay figlet`
-
-  * `RUN apt-get update` is not re-executed when the mirrors are updated
-
-You can force a rebuild with `docker build --no-cache ...`.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Running the image
-
-The resulting image is not different from the one produced manually.
-
-```bash
-$ docker run -ti figlet
-root@91f3c974c9a1:/# figlet hello
- _          _ _       
-| |__   ___| | | ___  
-| '_ \ / _ \ | |/ _ \ 
-| | | |  __/ | | (_) |
-|_| |_|\___|_|_|\___/ 
-```
-
-
-Yay! 🎉
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Using image and viewing history
-
-The `history` command lists all the layers composing an image.
-
-For each layer, it shows its creation time, size, and creation command.
-
-When an image was built with a Dockerfile, each layer corresponds to
-a line of the Dockerfile.
-
-```bash
-$ docker history figlet
-IMAGE         CREATED            CREATED BY                     SIZE
-f9e8f1642759  About an hour ago  /bin/sh -c apt-get install fi  1.627 MB
-7257c37726a1  About an hour ago  /bin/sh -c apt-get update      21.58 MB
-07c86167cdc4  4 days ago         /bin/sh -c #(nop) CMD ["/bin   0 B
-<missing>     4 days ago         /bin/sh -c sed -i 's/^#\s*\(   1.895 kB
-<missing>     4 days ago         /bin/sh -c echo '#!/bin/sh'    194.5 kB
-<missing>     4 days ago         /bin/sh -c #(nop) ADD file:b   187.8 MB
-```
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-class: extra-details
-
-## Why `sh -c`?
-
-* On UNIX, to start a new program, we need two system calls:
-
-  - `fork()`, to create a new child process;
-
-  - `execve()`, to replace the new child process with the program to run.
-
-* Conceptually, `execve()` works like this:
-
-  `execve(program, [list, of, arguments])`
-
-* When we run a command, e.g. `ls -l /tmp`, something needs to parse the command.
-
-  (i.e. split the program and its arguments into a list.)
-
-* The shell is usually doing that.
-
-  (It also takes care of expanding environment variables and special things like `~`.)
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-class: extra-details
-
-## Why `sh -c`?
-
-* When we do `RUN ls -l /tmp`, the Docker builder needs to parse the command.
-
-* Instead of implementing its own parser, it outsources the job to the shell.
-
-* That's why we see `sh -c ls -l /tmp` in that case.
-
-* But we can also do the parsing jobs ourselves.
-
-* This means passing `RUN` a list of arguments.
-
-* This is called the *exec syntax*.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Shell syntax vs exec syntax
-
-Dockerfile commands that execute something can have two forms:
-
-* plain string, or *shell syntax*:
-  <br/>`RUN apt-get install figlet`
-
-* JSON list, or *exec syntax*:
-  <br/>`RUN ["apt-get", "install", "figlet"]`
-
-We are going to change our Dockerfile to see how it affects the resulting image.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Using exec syntax in our Dockerfile
-
-Let's change our Dockerfile as follows!
-
-```dockerfile
-FROM ubuntu
-RUN apt-get update
-RUN ["apt-get", "install", "figlet"]
-```
-
-Then build the new Dockerfile.
-
-```bash
-$ docker build -t figlet .
-```
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## History with exec syntax
-
-Compare the new history:
-
-```bash
-$ docker history figlet
-IMAGE         CREATED            CREATED BY                     SIZE
-27954bb5faaf  10 seconds ago     apt-get install figlet         1.627 MB
-7257c37726a1  About an hour ago  /bin/sh -c apt-get update      21.58 MB
-07c86167cdc4  4 days ago         /bin/sh -c #(nop) CMD ["/bin   0 B
-<missing>     4 days ago         /bin/sh -c sed -i 's/^#\s*\(   1.895 kB
-<missing>     4 days ago         /bin/sh -c echo '#!/bin/sh'    194.5 kB
-<missing>     4 days ago         /bin/sh -c #(nop) ADD file:b   187.8 MB
-```
-
-* Exec syntax specifies an *exact* command to execute.
-
-* Shell syntax specifies a command to be wrapped within `/bin/sh -c "..."`.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## When to use exec syntax and shell syntax
-
-* shell syntax:
-
-  * is easier to write
-  * interpolates environment variables and other shell expressions
-  * creates an extra process (`/bin/sh -c ...`) to parse the string
-  * requires `/bin/sh` to exist in the container
-
-* exec syntax:
-
-  * is harder to write (and read!)
-  * passes all arguments without extra processing
-  * doesn't create an extra process
-  * doesn't require `/bin/sh` to exist in the container
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Pro-tip: the `exec` shell built-in
-
-POSIX shells have a built-in command named `exec`.
-
-`exec` should be followed by a program and its arguments.
-
-From a user perspective:
-
-- it looks like the shell exits right away after the command execution,
-
-- in fact, the shell exits just *before* command execution;
-
-- or rather, the shell gets *replaced* by the command.
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-## Example using `exec`
-
-```dockerfile
-CMD exec figlet -f script hello
-```
-
-In this example, `sh -c` will still be used, but
-`figlet` will be PID 1 in the container.
-
-The shell gets replaced by `figlet` when `figlet` starts execution.
-
-This allows to run processes as PID 1 without using JSON.
-
-???
-
-:EN:- Towards automated, reproducible builds
-:EN:- Writing our first Dockerfile
-:FR:- Rendre le processus automatique et reproductible
-:FR:- Écrire son premier Dockerfile
-
-.debug[[containers/Building_Images_With_Dockerfiles.md](""/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/containers-by-the-water.jpg)]
-
----
-
-name: toc-cmd-and-entrypoint
-class: title
-
- `CMD` and `ENTRYPOINT`
-
-.nav[
-[Previous part](#toc-building-docker-images-with-a-dockerfile)
-|
-[Back to table of contents](#toc-part-2)
-|
-[Next part](#toc-copying-files-during-the-build)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# `CMD` and `ENTRYPOINT`
-
-![Container entry doors](images/entrypoint.jpg)
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Objectives
-
-In this lesson, we will learn about two important
-Dockerfile commands:
-
-`CMD` and `ENTRYPOINT`.
-
-These commands allow us to set the default command
-to run in a container.
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Defining a default command
-
-When people run our container, we want to greet them with a nice hello message, and using a custom font.
-
-For that, we will execute:
-
-```bash
-figlet -f script hello
-```
-
-* `-f script` tells figlet to use a fancy font.
-
-* `hello` is the message that we want it to display.
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Adding `CMD` to our Dockerfile
-
-Our new Dockerfile will look like this:
-
-```dockerfile
-FROM ubuntu
-RUN apt-get update
-RUN ["apt-get", "install", "figlet"]
-CMD figlet -f script hello
-```
-
-* `CMD` defines a default command to run when none is given.
-
-* It can appear at any point in the file.
-
-* Each `CMD` will replace and override the previous one.
-
-* As a result, while you can have multiple `CMD` lines, it is useless.
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Build and test our image
-
-Let's build it:
-
-```bash
-$ docker build -t figlet .
-...
-Successfully built 042dff3b4a8d
-Successfully tagged figlet:latest
-```
-
-And run it:
-
-```bash
-$ docker run figlet
- _          _   _       
-| |        | | | |      
-| |     _  | | | |  __  
-|/ \   |/  |/  |/  /  \_
-|   |_/|__/|__/|__/\__/ 
-```
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Overriding `CMD`
-
-If we want to get a shell into our container (instead of running
-`figlet`), we just have to specify a different program to run:
-
-```bash
-$ docker run -it figlet bash
-root@7ac86a641116:/# 
-```
-
-* We specified `bash`.
-
-* It replaced the value of `CMD`.
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Using `ENTRYPOINT`
-
-We want to be able to specify a different message on the command line,
-while retaining `figlet` and some default parameters.
-
-In other words, we would like to be able to do this:
-
-```bash
-$ docker run figlet salut
-           _            
-          | |           
- ,   __,  | |       _|_ 
-/ \_/  |  |/  |   |  |  
- \/ \_/|_/|__/ \_/|_/|_/
-```
-
-
-We will use the `ENTRYPOINT` verb in Dockerfile.
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Adding `ENTRYPOINT` to our Dockerfile
-
-Our new Dockerfile will look like this:
-
-```dockerfile
-FROM ubuntu
-RUN apt-get update
-RUN ["apt-get", "install", "figlet"]
-ENTRYPOINT ["figlet", "-f", "script"]
-```
-
-* `ENTRYPOINT` defines a base command (and its parameters) for the container.
-
-* The command line arguments are appended to those parameters.
-
-* Like `CMD`, `ENTRYPOINT` can appear anywhere, and replaces the previous value.
-
-Why did we use JSON syntax for our `ENTRYPOINT`?
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Implications of JSON vs string syntax
-
-* When CMD or ENTRYPOINT use string syntax, they get wrapped in `sh -c`.
-
-* To avoid this wrapping, we can use JSON syntax.
-
-What if we used `ENTRYPOINT` with string syntax?
-
-```bash
-$ docker run figlet salut
-```
-
-This would run the following command in the `figlet` image:
-
-```bash
-sh -c "figlet -f script" salut
-```
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Build and test our image
-
-Let's build it:
-
-```bash
-$ docker build -t figlet .
-...
-Successfully built 36f588918d73
-Successfully tagged figlet:latest
-```
-
-And run it:
-
-```bash
-$ docker run figlet salut
-           _            
-          | |           
- ,   __,  | |       _|_ 
-/ \_/  |  |/  |   |  |  
- \/ \_/|_/|__/ \_/|_/|_/
-```
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Using `CMD` and `ENTRYPOINT` together
-
-What if we want to define a default message for our container?
-
-Then we will use `ENTRYPOINT` and `CMD` together.
-
-* `ENTRYPOINT` will define the base command for our container.
-
-* `CMD` will define the default parameter(s) for this command.
-
-* They *both* have to use JSON syntax.
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## `CMD` and `ENTRYPOINT` together
-
-Our new Dockerfile will look like this:
-
-```dockerfile
-FROM ubuntu
-RUN apt-get update
-RUN ["apt-get", "install", "figlet"]
-ENTRYPOINT ["figlet", "-f", "script"]
-CMD ["hello world"]
-```
-
-* `ENTRYPOINT` defines a base command (and its parameters) for the container.
-
-* If we don't specify extra command-line arguments when starting the container,
-  the value of `CMD` is appended.
-
-* Otherwise, our extra command-line arguments are used instead of `CMD`.
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Build and test our image
-
-Let's build it:
-
-```bash
-$ docker build -t myfiglet .
-...
-Successfully built 6e0b6a048a07
-Successfully tagged myfiglet:latest
-```
-
-Run it without parameters:
-
-```bash
-$ docker run myfiglet
- _          _   _                             _        
-| |        | | | |                           | |    |  
-| |     _  | | | |  __             __   ,_   | |  __|  
-|/ \   |/  |/  |/  /  \_  |  |  |_/  \_/  |  |/  /  |  
-|   |_/|__/|__/|__/\__/    \/ \/  \__/    |_/|__/\_/|_/
-```
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Overriding the image default parameters
-
-Now let's pass extra arguments to the image.
-
-```bash
-$ docker run myfiglet hola mundo
- _           _                                               
-| |         | |                                      |       
-| |     __  | |  __,     _  _  _           _  _    __|   __  
-|/ \   /  \_|/  /  |    / |/ |/ |  |   |  / |/ |  /  |  /  \_
-|   |_/\__/ |__/\_/|_/    |  |  |_/ \_/|_/  |  |_/\_/|_/\__/ 
-```
-
-We overrode `CMD` but still used `ENTRYPOINT`.
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## Overriding `ENTRYPOINT`
-
-What if we want to run a shell in our container?
-
-We cannot just do `docker run myfiglet bash` because
-that would just tell figlet to display the word "bash."
-
-We use the `--entrypoint` parameter:
-
-```bash
-$ docker run -it --entrypoint bash myfiglet
-root@6027e44e2955:/# 
-```
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## `CMD` and `ENTRYPOINT` recap
-
-- `docker run myimage` executes `ENTRYPOINT` + `CMD`
-
-- `docker run myimage args` executes `ENTRYPOINT` + `args` (overriding `CMD`)
-
-- `docker run --entrypoint prog myimage` executes `prog` (overriding both)
-
-.small[
-| Command                         | `ENTRYPOINT`       | `CMD`   | Result
-|---------------------------------|--------------------|---------|-------
-| `docker run figlet`             | none               | none    | Use values from base image (`bash`)
-| `docker run figlet hola`        | none               | none    | Error (executable `hola` not found)
-| `docker run figlet`             | `figlet -f script` | none    | `figlet -f script`
-| `docker run figlet hola`        | `figlet -f script` | none    | `figlet -f script hola`
-| `docker run figlet`             | none    | `figlet -f script` | `figlet -f script`
-| `docker run figlet hola`        | none    | `figlet -f script` | Error (executable `hola` not found)
-| `docker run figlet`             | `figlet -f script` | `hello` | `figlet -f script hello`
-| `docker run figlet hola`        | `figlet -f script` | `hello` | `figlet -f script hola`
-]
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-## When to use `ENTRYPOINT` vs `CMD`
-
-`ENTRYPOINT` is great for "containerized binaries".
-
-Example: `docker run consul --help`
-
-(Pretend that the `docker run` part isn't there!)
-
-`CMD` is great for images with multiple binaries.
-
-Example: `docker run busybox ifconfig`
-
-(It makes sense to indicate *which* program we want to run!)
-
-???
-
-:EN:- CMD and ENTRYPOINT
-:FR:- CMD et ENTRYPOINT
-
-.debug[[containers/Cmd_And_Entrypoint.md](""/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/distillery-containers.jpg)]
-
----
-
-name: toc-copying-files-during-the-build
-class: title
-
- Copying files during the build
-
-.nav[
-[Previous part](#toc-cmd-and-entrypoint)
-|
-[Back to table of contents](#toc-part-2)
-|
-[Next part](#toc-exercise--writing-dockerfiles)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Copying files during the build
-
-![Monks copying books](images/title-copying-files-during-build.jpg)
-
-.debug[[containers/Copying_Files_During_Build.md](""/tree/main/slides/containers/Copying_Files_During_Build.md)]
----
-
-## Objectives
-
-So far, we have installed things in our container images
-by downloading packages.
-
-We can also copy files from the *build context* to the
-container that we are building.
-
-Remember: the *build context* is the directory containing
-the Dockerfile.
-
-In this chapter, we will learn a new Dockerfile keyword: `COPY`.
-
-.debug[[containers/Copying_Files_During_Build.md](""/tree/main/slides/containers/Copying_Files_During_Build.md)]
----
-
-## Build some C code
-
-We want to build a container that compiles a basic "Hello world" program in C.
-
-Here is the program, `hello.c`:
-
-```bash
-int main () {
-  puts("Hello, world!");
-  return 0;
-}
-```
-
-Let's create a new directory, and put this file in there.
-
-Then we will write the Dockerfile.
-
-.debug[[containers/Copying_Files_During_Build.md](""/tree/main/slides/containers/Copying_Files_During_Build.md)]
----
-
-## The Dockerfile
-
-On Debian and Ubuntu, the package `build-essential` will get us a compiler.
-
-When installing it, don't forget to specify the `-y` flag, otherwise the build will fail (since the build cannot be interactive).
-
-Then we will use `COPY` to place the source file into the container.
-
-```bash
-FROM ubuntu
-RUN apt-get update
-RUN apt-get install -y build-essential
-COPY hello.c /
-RUN make hello
-CMD /hello
-```
-
-Create this Dockerfile.
-
-.debug[[containers/Copying_Files_During_Build.md](""/tree/main/slides/containers/Copying_Files_During_Build.md)]
----
-
-## Testing our C program
-
-* Create `hello.c` and `Dockerfile` in the same directory.
-
-* Run `docker build -t hello .` in this directory.
-
-* Run `docker run hello`, you should see `Hello, world!`.
-
-Success!
-
-.debug[[containers/Copying_Files_During_Build.md](""/tree/main/slides/containers/Copying_Files_During_Build.md)]
----
-
-## `COPY` and the build cache
-
-* Run the build again.
-
-* Now, modify `hello.c` and run the build again.
-
-* Docker can cache steps involving `COPY`.
-
-* Those steps will not be executed again if the files haven't been changed.
-
-.debug[[containers/Copying_Files_During_Build.md](""/tree/main/slides/containers/Copying_Files_During_Build.md)]
----
-
-## Details
-
-* We can `COPY` whole directories recursively
-
-* It is possible to do e.g. `COPY . .`
-
-  (but it might require some extra precautions to avoid copying too much)
- 
-* In older Dockerfiles, you might see the `ADD` command; consider it deprecated
-
-  (it is similar to `COPY` but can automatically extract archives)
-
-* If we really wanted to compile C code in a container, we would:
-
-  * place it in a different directory, with the `WORKDIR` instruction
-
-  * even better, use the `gcc` official image
-
-.debug[[containers/Copying_Files_During_Build.md](""/tree/main/slides/containers/Copying_Files_During_Build.md)]
----
-
-class: extra-details
-
-## `.dockerignore`
-
-- We can create a file named `.dockerignore`
-
-  (at the top-level of the build context)
-
-- It can contain file names and globs to ignore
-
-- They won't be sent to the builder
-
-  (and won't end up in the resulting image)
-
-- See the [documentation] for the little details
-
-  (exceptions can be made with `!`, multiple directory levels with `**`...)
-
-[documentation]: https://docs.docker.com/engine/reference/builder/#dockerignore-file
-
-???
-
-:EN:- Leveraging the build cache for faster builds
-:FR:- Tirer parti du cache afin d'optimiser la vitesse de *build*
-
-.debug[[containers/Copying_Files_During_Build.md](""/tree/main/slides/containers/Copying_Files_During_Build.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/lots-of-containers.jpg)]
-
----
-
-name: toc-exercise--writing-dockerfiles
-class: title
-
- Exercise — writing Dockerfiles
-
-.nav[
-[Previous part](#toc-copying-files-during-the-build)
-|
-[Back to table of contents](#toc-part-2)
-|
-[Next part](#toc-tips-for-efficient-dockerfiles)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Exercise — writing Dockerfiles
-
-Let's write Dockerfiles for an existing application!
-
-1. Check out the code repository
-
-2. Read all the instructions
-
-3. Write Dockerfiles
-
-4. Build and test them individually
-
-<!--
-5. Test them together with the provided Compose file
--->
-
-.debug[[containers/Exercise_Dockerfile_Basic.md](""/tree/main/slides/containers/Exercise_Dockerfile_Basic.md)]
----
-
-## Code repository
-
-Clone the repository available at:
-
-https://github.com/jpetazzo/wordsmith
-
-It should look like this:
-```
-├── LICENSE
-├── README
-├── db/
-│   └── words.sql
-├── web/
-│   ├── dispatcher.go
-│   └── static/
-└── words/
-    ├── pom.xml
-    └── src/
-```
-
-.debug[[containers/Exercise_Dockerfile_Basic.md](""/tree/main/slides/containers/Exercise_Dockerfile_Basic.md)]
----
-
-## Instructions
-
-The repository contains instructions in English and French.
-<br/>
-For now, we only care about the first part (about writing Dockerfiles).
-<br/>
-Place each Dockerfile in its own directory, like this:
-```
-├── LICENSE
-├── README
-├── db/
-│   ├── `Dockerfile`
-│   └── words.sql
-├── web/
-│   ├── `Dockerfile`
-│   ├── dispatcher.go
-│   └── static/
-└── words/
-    ├── `Dockerfile`
-    ├── pom.xml
-    └── src/
-```
-
-.debug[[containers/Exercise_Dockerfile_Basic.md](""/tree/main/slides/containers/Exercise_Dockerfile_Basic.md)]
----
-
-## Build and test
-
-Build and run each Dockerfile individually.
-
-For `db`, we should be able to see some messages confirming that the data set
-was loaded successfully (some `INSERT` lines in the container output).
-
-For `web` and `words`, we should be able to see some message looking like
-"server started successfully".
-
-That's all we care about for now!
-
-Bonus question: make sure that each container stops correctly when hitting Ctrl-C.
-
-???
-
-## Test with a Compose file
-
-Place the following Compose file at the root of the repository:
-
-
-```yaml
-version: "3"
-services:
-  db:
-    build: db
-  words:
-    build: words
-  web:
-    build: web
-    ports:
-    - 8888:80
-```
-
-Test the whole app by bringin up the stack and connecting to port 8888.
-
-.debug[[containers/Exercise_Dockerfile_Basic.md](""/tree/main/slides/containers/Exercise_Dockerfile_Basic.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/plastic-containers.JPG)]
-
----
-
-name: toc-tips-for-efficient-dockerfiles
-class: title
-
- Tips for efficient Dockerfiles
-
-.nav[
-[Previous part](#toc-exercise--writing-dockerfiles)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-dockerfile-examples)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Tips for efficient Dockerfiles
-
-We will see how to:
-
-* Reduce the number of layers.
-
-* Leverage the build cache so that builds can be faster.
-
-* Embed unit testing in the build process.
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Reducing the number of layers
-
-* Each line in a `Dockerfile` creates a new layer.
-
-* Build your `Dockerfile` to take advantage of Docker's caching system.
-
-* Combine commands by using `&&` to continue commands and `\` to wrap lines.
-
-Note: it is frequent to build a Dockerfile line by line:
-
-```dockerfile
-RUN apt-get install thisthing
-RUN apt-get install andthatthing andthatotherone
-RUN apt-get install somemorestuff
-```
-
-And then refactor it trivially before shipping:
-
-```dockerfile
-RUN apt-get install thisthing andthatthing andthatotherone somemorestuff
-```
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Avoid re-installing dependencies at each build
-
-* Classic Dockerfile problem:
-
-  "each time I change a line of code, all my dependencies are re-installed!"
-
-* Solution: `COPY` dependency lists (`package.json`, `requirements.txt`, etc.)
-  by themselves to avoid reinstalling unchanged dependencies every time.
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Example "bad" `Dockerfile`
-
-The dependencies are reinstalled every time, because the build system does not know if `requirements.txt` has been updated.
-
-```bash
-FROM python
-WORKDIR /src
-COPY . .
-RUN pip install -qr requirements.txt
-EXPOSE 5000
-CMD ["python", "app.py"]
-```
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Fixed `Dockerfile`
-
-Adding the dependencies as a separate step means that Docker can cache more efficiently and only install them when `requirements.txt` changes.
-
-```bash
-FROM python
-WORKDIR /src
-COPY requirements.txt .
-RUN pip install -qr requirements.txt
-COPY . .
-EXPOSE 5000
-CMD ["python", "app.py"]
-```
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Be careful with `chown`, `chmod`, `mv`
-
-* Layers cannot store efficiently changes in permissions or ownership.
-
-* Layers cannot represent efficiently when a file is moved either.
-
-* As a result, operations like `chown`, `chown`, `mv` can be expensive.
-
-* For instance, in the Dockerfile snippet below, each `RUN` line
-  creates a layer with an entire copy of `some-file`.
-
-  ```dockerfile
-  COPY some-file .
-  RUN chown www-data:www-data some-file
-  RUN chmod 644 some-file
-  RUN mv some-file /var/www
-  ```
-
-* How can we avoid that?
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Put files on the right place
-
-* Instead of using `mv`, directly put files at the right place.
-
-* When extracting archives (tar, zip...), merge operations in a single layer.
-
-  Example:
-
-  ```dockerfile
-    ...
-    RUN wget http://.../foo.tar.gz \
-     && tar -zxf foo.tar.gz \
-     && mv foo/fooctl /usr/local/bin \
-     && rm -rf foo foo.tar.gz
-  ...
-  ```
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Use `COPY --chown`
-
-* The Dockerfile instruction `COPY` can take a `--chown` parameter.
-
-  Examples:
-
-  ```dockerfile
-  ...
-  COPY --chown=1000 some-file .
-  COPY --chown=1000:1000 some-file .
-  COPY --chown=www-data:www-data some-file .
-  ```
-
-* The `--chown` flag can specify a user, or a user:group pair.
-
-* The user and group can be specified as names or numbers.
-
-* When using names, the names must exist in `/etc/passwd` or `/etc/group`.
-
-  *(In the container, not on the host!)*
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Set correct permissions locally
-
-* Instead of using `chmod`, set the right file permissions locally.
-
-* When files are copied with `COPY`, permissions are preserved.
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Embedding unit tests in the build process
-
-```dockerfile
-FROM <baseimage>
-RUN <install dependencies>
-COPY <code>
-RUN <build code>
-RUN <install test dependencies>
-COPY <test data sets and fixtures>
-RUN <unit tests>
-FROM <baseimage>
-RUN <install dependencies>
-COPY <code>
-RUN <build code>
-CMD, EXPOSE ...
-```
-
-* The build fails as soon as an instruction fails
-* If `RUN <unit tests>` fails, the build doesn't produce an image
-* If it succeeds, it produces a clean image (without test libraries and data)
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-1.jpg)]
-
----
-
-name: toc-dockerfile-examples
-class: title
-
- Dockerfile examples
-
-.nav[
-[Previous part](#toc-tips-for-efficient-dockerfiles)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-reducing-image-size)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-# Dockerfile examples
-
-There are a number of tips, tricks, and techniques that we can use in Dockerfiles.
-
-But sometimes, we have to use different (and even opposed) practices depending on:
-
-- the complexity of our project,
-
-- the programming language or framework that we are using,
-
-- the stage of our project (early MVP vs. super-stable production),
-
-- whether we're building a final image or a base for further images,
-
-- etc.
-
-We are going to show a few examples using very different techniques.
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## When to optimize an image
-
-When authoring official images, it is a good idea to reduce as much as possible:
-
-- the number of layers,
-
-- the size of the final image.
-
-This is often done at the expense of build time and convenience for the image maintainer;
-but when an image is downloaded millions of time, saving even a few seconds of pull time
-can be worth it.
-
-.small[
-```dockerfile
-RUN apt-get update && apt-get install -y libpng12-dev libjpeg-dev && rm -rf /var/lib/apt/lists/* \
-	&& docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr \
-	&& docker-php-ext-install gd
-...
-RUN curl -o wordpress.tar.gz -SL https://wordpress.org/wordpress-${WORDPRESS_UPSTREAM_VERSION}.tar.gz \
-	&& echo "$WORDPRESS_SHA1 *wordpress.tar.gz" | sha1sum -c - \
-	&& tar -xzf wordpress.tar.gz -C /usr/src/ \
-	&& rm wordpress.tar.gz \
-	&& chown -R www-data:www-data /usr/src/wordpress
-```
-]
-
-(Source: [Wordpress official image](https://github.com/docker-library/wordpress/blob/618490d4bdff6c5774b84b717979bfe3d6ba8ad1/apache/Dockerfile))
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## When to *not* optimize an image
-
-Sometimes, it is better to prioritize *maintainer convenience*.
-
-In particular, if:
-
-- the image changes a lot,
-
-- the image has very few users (e.g. only 1, the maintainer!),
-
-- the image is built and run on the same machine,
-
-- the image is built and run on machines with a very fast link ...
-
-In these cases, just keep things simple!
-
-(Next slide: a Dockerfile that can be used to preview a Jekyll / github pages site.)
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-```dockerfile
-FROM debian:sid
-
-RUN apt-get update -q
-RUN apt-get install -yq build-essential make
-RUN apt-get install -yq zlib1g-dev
-RUN apt-get install -yq ruby ruby-dev
-RUN apt-get install -yq python-pygments
-RUN apt-get install -yq nodejs
-RUN apt-get install -yq cmake
-RUN gem install --no-rdoc --no-ri github-pages
-
-COPY . /blog
-WORKDIR /blog
-
-VOLUME /blog/_site
-
-EXPOSE 4000
-CMD ["jekyll", "serve", "--host", "0.0.0.0", "--incremental"]
-```
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Multi-dimensional versioning systems
-
-Images can have a tag, indicating the version of the image.
-
-But sometimes, there are multiple important components, and we need to indicate the versions
-for all of them.
-
-This can be done with environment variables:
-
-```dockerfile
-ENV PIP=9.0.3 \
-    ZC_BUILDOUT=2.11.2 \
-    SETUPTOOLS=38.7.0 \
-    PLONE_MAJOR=5.1 \
-    PLONE_VERSION=5.1.0 \
-    PLONE_MD5=76dc6cfc1c749d763c32fff3a9870d8d
-```
-
-(Source: [Plone official image](https://github.com/plone/plone.docker/blob/master/5.1/5.1.0/alpine/Dockerfile))
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Entrypoints and wrappers
-
-It is very common to define a custom entrypoint.
-
-That entrypoint will generally be a script, performing any combination of:
-
-- pre-flights checks (if a required dependency is not available, display
-  a nice error message early instead of an obscure one in a deep log file),
-
-- generation or validation of configuration files,
-
-- dropping privileges (with e.g. `su` or `gosu`, sometimes combined with `chown`),
-
-- and more.
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## A typical entrypoint script
-
-```dockerfile
- #!/bin/sh
- set -e
- 
- # first arg is '-f' or '--some-option'
- # or first arg is 'something.conf'
- if [ "${1#-}" != "$1" ] || [ "${1%.conf}" != "$1" ]; then
- 	set -- redis-server "$@"
- fi
- 
- # allow the container to be started with '--user'
- if [ "$1" = 'redis-server' -a "$(id -u)" = '0' ]; then
- 	chown -R redis .
- 	exec su-exec redis "$0" "$@"
- fi
- 
- exec "$@"
-```
-
-(Source: [Redis official image](https://github.com/docker-library/redis/blob/d24f2be82673ccef6957210cc985e392ebdc65e4/4.0/alpine/docker-entrypoint.sh))
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Factoring information
-
-To facilitate maintenance (and avoid human errors), avoid to repeat information like:
-
-- version numbers,
-
-- remote asset URLs (e.g. source tarballs) ...
-
-Instead, use environment variables.
-
-.small[
-```dockerfile
-ENV NODE_VERSION 10.2.1
-...
-RUN ...
-    && curl -fsSLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION.tar.xz" \
-    && curl -fsSLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \
-    && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \
-    && grep " node-v$NODE_VERSION.tar.xz\$" SHASUMS256.txt | sha256sum -c - \
-    && tar -xf "node-v$NODE_VERSION.tar.xz" \
-    && cd "node-v$NODE_VERSION" \
-...
-```
-]
-
-(Source: [Nodejs official image](https://github.com/nodejs/docker-node/blob/master/10/alpine/Dockerfile))
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Overrides
-
-In theory, development and production images should be the same.
-
-In practice, we often need to enable specific behaviors in development (e.g. debug statements).
-
-One way to reconcile both needs is to use Compose to enable these behaviors.
-
-Let's look at the [trainingwheels](https://github.com/jpetazzo/trainingwheels) demo app for an example.
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Production image
-
-This Dockerfile builds an image leveraging gunicorn:
-
-```dockerfile
-FROM python
-RUN pip install flask
-RUN pip install gunicorn
-RUN pip install redis
-COPY . /src
-WORKDIR /src
-CMD gunicorn --bind 0.0.0.0:5000 --workers 10 counter:app
-EXPOSE 5000
-```
-
-(Source: [trainingwheels Dockerfile](https://github.com/jpetazzo/trainingwheels/blob/master/www/Dockerfile))
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## Development Compose file
-
-This Compose file uses the same image, but with a few overrides for development:
-
-- the Flask development server is used (overriding `CMD`),
-
-- the `DEBUG` environment variable is set,
-
-- a volume is used to provide a faster local development workflow.
-
-.small[
-```yaml
-services:
-  www:
-    build: www
-    ports:
-      - 8000:5000
-    user: nobody
-    environment:
-      DEBUG: 1
-    command: python counter.py
-    volumes:
-      - ./www:/src
-```
-]
-
-(Source: [trainingwheels Compose file](https://github.com/jpetazzo/trainingwheels/blob/master/docker-compose.yml))
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-## How to know which best practices are better?
-
-- The main goal of containers is to make our lives easier.
-
-- In this chapter, we showed many ways to write Dockerfiles.
-
-- These Dockerfiles use sometimes diametrically opposed techniques.
-
-- Yet, they were the "right" ones *for a specific situation.*
-
-- It's OK (and even encouraged) to start simple and evolve as needed.
-
-- Feel free to review this chapter later (after writing a few Dockerfiles) for inspiration!
-
-???
-
-:EN:Optimizing images
-:EN:- Dockerfile tips, tricks, and best practices
-:EN:- Reducing build time
-:EN:- Reducing image size
-
-:FR:Optimiser ses images
-:FR:- Bonnes pratiques, trucs et astuces
-:FR:- Réduire le temps de build
-:FR:- Réduire la taille des images
-
-.debug[[containers/Dockerfile_Tips.md](""/tree/main/slides/containers/Dockerfile_Tips.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-2.jpg)]
-
----
-
-name: toc-reducing-image-size
-class: title
-
- Reducing image size
-
-.nav[
-[Previous part](#toc-dockerfile-examples)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-multi-stage-builds)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Reducing image size
-
-* In the previous example, our final image contained:
-
-  * our `hello` program
-
-  * its source code
-
-  * the compiler
-
-* Only the first one is strictly necessary.
-
-* We are going to see how to obtain an image without the superfluous components.
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Can't we remove superfluous files with `RUN`?
-
-What happens if we do one of the following commands?
-
-- `RUN rm -rf ...`
-
-- `RUN apt-get remove ...`
-
-- `RUN make clean ...`
-
---
-
-This adds a layer which removes a bunch of files.
-
-But the previous layers (which added the files) still exist.
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Removing files with an extra layer
-
-When downloading an image, all the layers must be downloaded.
-
-| Dockerfile instruction | Layer size | Image size |
-| ---------------------- | ---------- | ---------- |
-| `FROM ubuntu` | Size of base image | Size of base image |
-| `...` | ... | Sum of this layer <br/>+ all previous ones |
-| `RUN apt-get install somepackage` | Size of files added <br/>(e.g. a few MB) | Sum of this layer <br/>+ all previous ones |
-| `...` | ... | Sum of this layer <br/>+ all previous ones |
-| `RUN apt-get remove somepackage` | Almost zero <br/>(just metadata) | Same as previous one |
-
-Therefore, `RUN rm` does not reduce the size of the image or free up disk space.
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Removing unnecessary files
-
-Various techniques are available to obtain smaller images:
-
-- collapsing layers,
-
-- adding binaries that are built outside of the Dockerfile,
-
-- squashing the final image,
-
-- multi-stage builds.
-
-Let's review them quickly.
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Collapsing layers
-
-You will frequently see Dockerfiles like this:
-
-```dockerfile
-FROM ubuntu
-RUN apt-get update && apt-get install xxx && ... && apt-get remove xxx && ...
-```
-
-Or the (more readable) variant:
-
-```dockerfile
-FROM ubuntu
-RUN apt-get update \
- && apt-get install xxx \
- && ... \
- && apt-get remove xxx \
- && ...
-```
-
-This `RUN` command gives us a single layer.
-
-The files that are added, then removed in the same layer, do not grow the layer size.
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Collapsing layers: pros and cons
-
-Pros:
-
-- works on all versions of Docker
-
-- doesn't require extra tools
-
-Cons:
-
-- not very readable
-
-- some unnecessary files might still remain if the cleanup is not thorough
-
-- that layer is expensive (slow to build)
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Building binaries outside of the Dockerfile
-
-This results in a Dockerfile looking like this:
-
-```dockerfile
-FROM ubuntu
-COPY xxx /usr/local/bin
-```
-
-Of course, this implies that the file `xxx` exists in the build context.
-
-That file has to exist before you can run `docker build`.
-
-For instance, it can:
-
-- exist in the code repository,
-- be created by another tool (script, Makefile...),
-- be created by another container image and extracted from the image.
-
-See for instance the [busybox official image](https://github.com/docker-library/busybox/blob/fe634680e32659aaf0ee0594805f74f332619a90/musl/Dockerfile) or this [older busybox image](https://github.com/jpetazzo/docker-busybox).
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Building binaries outside: pros and cons
-
-Pros:
-
-- final image can be very small
-
-Cons:
-
-- requires an extra build tool
-
-- we're back in dependency hell and "works on my machine"
-
-Cons, if binary is added to code repository:
-
-- breaks portability across different platforms
-
-- grows repository size a lot if the binary is updated frequently
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Squashing the final image
-
-The idea is to transform the final image into a single-layer image.
-
-This can be done in (at least) two ways.
-
-- Activate experimental features and squash the final image:
-  ```bash
-  docker image build --squash ...
-  ```
-
-- Export/import the final image.
-  ```bash
-  docker build -t temp-image .
-  docker run --entrypoint true --name temp-container temp-image
-  docker export temp-container | docker import - final-image
-  docker rm temp-container
-  docker rmi temp-image
-  ```
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Squashing the image: pros and cons
-
-Pros:
-
-- single-layer images are smaller and faster to download
-
-- removed files no longer take up storage and network resources
-
-Cons:
-
-- we still need to actively remove unnecessary files
-
-- squash operation can take a lot of time (on big images)
-
-- squash operation does not benefit from cache
-  <br/>
-  (even if we change just a tiny file, the whole image needs to be re-squashed)
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Multi-stage builds
-
-Multi-stage builds allow us to have multiple *stages*.
-
-Each stage is a separate image, and can copy files from previous stages.
-
-We're going to see how they work in more detail.
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/two-containers-on-a-truck.jpg)]
-
----
-
-name: toc-multi-stage-builds
-class: title
-
- Multi-stage builds
-
-.nav[
-[Previous part](#toc-reducing-image-size)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-publishing-images-to-the-docker-hub)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-# Multi-stage builds
-
-* At any point in our `Dockerfile`, we can add a new `FROM` line.
-
-* This line starts a new stage of our build.
-
-* Each stage can access the files of the previous stages with `COPY --from=...`.
-
-* When a build is tagged (with `docker build -t ...`), the last stage is tagged.
-
-* Previous stages are not discarded: they will be used for caching, and can be referenced.
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Multi-stage builds in practice
-
-* Each stage is numbered, starting at `0`
-
-* We can copy a file from a previous stage by indicating its number, e.g.:
-
-  ```dockerfile
-  COPY --from=0 /file/from/first/stage /location/in/current/stage
-  ```
-
-* We can also name stages, and reference these names:
-
-  ```dockerfile
-  FROM golang AS builder
-  RUN ...
-  FROM alpine
-  COPY --from=builder /go/bin/mylittlebinary /usr/local/bin/
-  ```
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Multi-stage builds for our C program
-
-We will change our Dockerfile to:
-
-* give a nickname to the first stage: `compiler`
-
-* add a second stage using the same `ubuntu` base image
-
-* add the `hello` binary to the second stage
-
-* make sure that `CMD` is in the second stage 
-
-The resulting Dockerfile is on the next slide.
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Multi-stage build `Dockerfile`
-
-Here is the final Dockerfile:
-
-```dockerfile
-FROM ubuntu AS compiler
-RUN apt-get update
-RUN apt-get install -y build-essential
-COPY hello.c /
-RUN make hello
-FROM ubuntu
-COPY --from=compiler /hello /hello
-CMD /hello
-```
-
-Let's build it, and check that it works correctly:
-
-```bash
-docker build -t hellomultistage .
-docker run hellomultistage
-```
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Comparing single/multi-stage build image sizes
-
-List our images with `docker images`, and check the size of:
-
-- the `ubuntu` base image,
-
-- the single-stage `hello` image,
-
-- the multi-stage `hellomultistage` image.
-
-We can achieve even smaller images if we use smaller base images.
-
-However, if we use common base images (e.g. if we standardize on `ubuntu`),
-these common images will be pulled only once per node, so they are
-virtually "free."
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-## Build targets
-
-* We can also tag an intermediary stage with the following command:
-  ```bash
-  docker build --target STAGE --tag NAME
-  ```
-
-* This will create an image (named `NAME`) corresponding to stage `STAGE`
-
-* This can be used to easily access an intermediary stage for inspection
-
-  (instead of parsing the output of `docker build` to find out the image ID)
-
-* This can also be used to describe multiple images from a single Dockerfile
-
-  (instead of using multiple Dockerfiles, which could go out of sync)
-
-???
-
-:EN:Optimizing our images and their build process
-:EN:- Leveraging multi-stage builds
-
-:FR:Optimiser les images et leur construction
-:FR:- Utilisation d'un *multi-stage build*
-
-.debug[[containers/Multi_Stage_Builds.md](""/tree/main/slides/containers/Multi_Stage_Builds.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/wall-of-containers.jpeg)]
-
----
-
-name: toc-publishing-images-to-the-docker-hub
-class: title
-
- Publishing images to the Docker Hub
-
-.nav[
-[Previous part](#toc-multi-stage-builds)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-exercise--writing-better-dockerfiles)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Publishing images to the Docker Hub
-
-We have built our first images.
-
-We can now publish it to the Docker Hub!
-
-*You don't have to do the exercises in this section,
-because they require an account on the Docker Hub, and we
-don't want to force anyone to create one.*
-
-*Note, however, that creating an account on the Docker Hub
-is free (and doesn't require a credit card), and hosting
-public images is free as well.*
-
-.debug[[containers/Publishing_To_Docker_Hub.md](""/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
----
-
-## Logging into our Docker Hub account
-
-* This can be done from the Docker CLI:
-  ```bash
-  docker login
-  ```
-
-.warning[When running Docker for Mac/Windows, or
-Docker on a Linux workstation, it can (and will when
-possible) integrate with your system's keyring to
-store your credentials securely. However, on most Linux
-servers, it will store your credentials in `~/.docker/config`.]
-
-.debug[[containers/Publishing_To_Docker_Hub.md](""/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
----
-
-## Image tags and registry addresses
-
-* Docker images tags are like Git tags and branches.
-
-* They are like *bookmarks* pointing at a specific image ID.
-
-* Tagging an image doesn't *rename* an image: it adds another tag.
-
-* When pushing an image to a registry, the registry address is in the tag.
-
-  Example: `registry.example.net:5000/image`
-
-* What about Docker Hub images?
-
---
-
-* `jpetazzo/clock` is, in fact, `index.docker.io/jpetazzo/clock`
-
-* `ubuntu` is, in fact, `library/ubuntu`, i.e. `index.docker.io/library/ubuntu`
-
-.debug[[containers/Publishing_To_Docker_Hub.md](""/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
----
-
-## Tagging an image to push it on the Hub
-
-* Let's tag our `figlet` image (or any other to our liking):
-  ```bash
-  docker tag figlet jpetazzo/figlet
-  ```
-
-* And push it to the Hub:
-  ```bash
-  docker push jpetazzo/figlet
-  ```
-
-* That's it!
-
---
-
-* Anybody can now `docker run jpetazzo/figlet` anywhere.
-
-.debug[[containers/Publishing_To_Docker_Hub.md](""/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
----
-
-## The goodness of automated builds
-
-* You can link a Docker Hub repository with a GitHub or BitBucket repository
-
-* Each push to GitHub or BitBucket will trigger a build on Docker Hub
-
-* If the build succeeds, the new image is available on Docker Hub
-
-* You can map tags and branches between source and container images
-
-* If you work with public repositories, this is free
-
-.debug[[containers/Publishing_To_Docker_Hub.md](""/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
----
-
-class: extra-details
-
-## Setting up an automated build
-
-* We need a Dockerized repository!
-* Let's go to https://github.com/jpetazzo/trainingwheels and fork it.
-* Go to the Docker Hub (https://hub.docker.com/) and sign-in. Select "Repositories" in the blue navigation menu.
-* Select "Create" in the top-right bar, and select "Create Repository+".
-* Connect your Docker Hub account to your GitHub account.
-* Click "Create" button.
-* Then go to "Builds" folder.
-* Click on Github icon and select your user and the repository that we just forked.
-* In "Build rules" block near page bottom, put `/www` in "Build Context" column (or whichever directory the Dockerfile is in).
-* Click "Save and Build" to build the repository immediately (without waiting for a git push).
-* Subsequent builds will happen automatically, thanks to GitHub hooks.
-
-.debug[[containers/Publishing_To_Docker_Hub.md](""/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
----
-
-## Building on the fly
-
-- Some services can build images on the fly from a repository
-
-- Example: [ctr.run](https://ctr.run/)
-
-.lab[
-
-- Use ctr.run to automatically build a container image and run it:
-  ```bash
-  docker run ctr.run/github.com/undefinedlabs/hello-world
-  ```
-
-]
-
-There might be a long pause before the first layer is pulled,
-because the API behind `docker pull` doesn't allow to stream build logs, and there is no feedback during the build.
-
-It is possible to view the build logs by setting up an account on [ctr.run](https://ctr.run/).
-
-???
-
-:EN:- Publishing images to the Docker Hub
-:FR:- Publier des images sur le Docker Hub
-
-.debug[[containers/Publishing_To_Docker_Hub.md](""/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/catene-de-conteneurs.jpg)]
-
----
-
-name: toc-exercise--writing-better-dockerfiles
-class: title
-
- Exercise — writing better Dockerfiles
-
-.nav[
-[Previous part](#toc-publishing-images-to-the-docker-hub)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-naming-and-inspecting-containers)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Exercise — writing better Dockerfiles
-
-Let's update our Dockerfiles to leverage multi-stage builds!
-
-The code is at: https://github.com/jpetazzo/wordsmith
-
-Use a different tag for these images, so that we can compare their sizes.
-
-What's the size difference between single-stage and multi-stage builds?
-
-.debug[[containers/Exercise_Dockerfile_Advanced.md](""/tree/main/slides/containers/Exercise_Dockerfile_Advanced.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]
-
----
-
-name: toc-naming-and-inspecting-containers
-class: title
-
- Naming and inspecting containers
-
-.nav[
-[Previous part](#toc-exercise--writing-better-dockerfiles)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-labels)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Naming and inspecting containers
-
-![Markings on container door](images/title-naming-and-inspecting-containers.jpg)
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-## Objectives
-
-In this lesson, we will learn about an important
-Docker concept: container *naming*.
-
-Naming allows us to:
-
-* Reference easily a container.
-
-* Ensure unicity of a specific container.
-
-We will also see the `inspect` command, which gives a lot of details about a container.
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-## Naming our containers
-
-So far, we have referenced containers with their ID.
-
-We have copy-pasted the ID, or used a shortened prefix.
-
-But each container can also be referenced by its name.
-
-If a container is named `thumbnail-worker`, I can do:
-
-```bash
-$ docker logs thumbnail-worker
-$ docker stop thumbnail-worker
-etc.
-```
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-## Default names
-
-When we create a container, if we don't give a specific
-name, Docker will pick one for us.
-
-It will be the concatenation of:
-
-* A mood (furious, goofy, suspicious, boring...)
-
-* The name of a famous inventor (tesla, darwin, wozniak...)
-
-Examples: `happy_curie`, `clever_hopper`, `jovial_lovelace` ...
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-## Specifying a name
-
-You can set the name of the container when you create it.
-
-```bash
-$ docker run --name ticktock jpetazzo/clock
-```
-
-If you specify a name that already exists, Docker will refuse
-to create the container.
-
-This lets us enforce unicity of a given resource.
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-## Renaming containers
-
-* You can rename containers with `docker rename`.
-
-* This allows you to "free up" a name without destroying the associated container.
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-## Inspecting a container
-
-The `docker inspect` command will output a very detailed JSON map.
-
-```bash
-$ docker inspect <containerID>
-[{
-...
-(many pages of JSON here)
-...
-```
-
-There are multiple ways to consume that information.
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-## Parsing JSON with the Shell
-
-* You *could* grep and cut or awk the output of `docker inspect`.
-
-* Please, don't.
-
-* It's painful.
-
-* If you really must parse JSON from the Shell, use JQ! (It's great.)
-
-```bash
-$ docker inspect <containerID> | jq .
-```
-
-* We will see a better solution which doesn't require extra tools.
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-## Using `--format`
-
-You can specify a format string, which will be parsed by 
-Go's text/template package.
-
-```bash
-$ docker inspect --format '{{ json .Created }}' <containerID>
-"2015-02-24T07:21:11.712240394Z"
-```
-
-* The generic syntax is to wrap the expression with double curly braces.
-
-* The expression starts with a dot representing the JSON object.
-
-* Then each field or member can be accessed in dotted notation syntax.
-
-* The optional `json` keyword asks for valid JSON output.
-  <br/>(e.g. here it adds the surrounding double-quotes.)
-
-???
-
-:EN:Managing container lifecycle
-:EN:- Naming and inspecting containers
-
-:FR:Suivre ses conteneurs à la loupe
-:FR:- Obtenir des informations détaillées sur un conteneur
-:FR:- Associer un identifiant unique à un conteneur
-
-.debug[[containers/Naming_And_Inspecting.md](""/tree/main/slides/containers/Naming_And_Inspecting.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]
-
----
-
-name: toc-labels
-class: title
-
- Labels
-
-.nav[
-[Previous part](#toc-naming-and-inspecting-containers)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-restarting-and-attaching-to-containers)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Labels
-
-* Labels allow to attach arbitrary metadata to containers.
-
-* Labels are key/value pairs.
-
-* They are specified at container creation.
-
-* You can query them with `docker inspect`.
-
-* They can also be used as filters with some commands (e.g. `docker ps`).
-
-.debug[[containers/Labels.md](""/tree/main/slides/containers/Labels.md)]
----
-
-## Using labels
-
-Let's create a few containers with a label `owner`.
-
-```bash
-docker run -d -l owner=alice nginx
-docker run -d -l owner=bob nginx
-docker run -d -l owner nginx
-```
-
-We didn't specify a value for the `owner` label in the last example.
-
-This is equivalent to setting the value to be an empty string.
-
-.debug[[containers/Labels.md](""/tree/main/slides/containers/Labels.md)]
----
-
-## Querying labels
-
-We can view the labels with `docker inspect`.
-
-```bash
-$ docker inspect $(docker ps -lq) | grep -A3 Labels
-            "Labels": {
-                "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>",
-                "owner": ""
-            },
-```
-
-We can use the `--format` flag to list the value of a label.
-
-```bash
-$ docker inspect $(docker ps -q) --format 'OWNER={{.Config.Labels.owner}}'
-```
-
-.debug[[containers/Labels.md](""/tree/main/slides/containers/Labels.md)]
----
-
-## Using labels to select containers
-
-We can list containers having a specific label.
-
-```bash
-$ docker ps --filter label=owner
-```
-
-Or we can list containers having a specific label with a specific value.
-
-```bash
-$ docker ps --filter label=owner=alice
-```
-
-.debug[[containers/Labels.md](""/tree/main/slides/containers/Labels.md)]
----
-
-## Use-cases for labels
-
-
-* HTTP vhost of a web app or web service.
-
-  (The label is used to generate the configuration for NGINX, HAProxy, etc.)
-
-* Backup schedule for a stateful service.
-
-  (The label is used by a cron job to determine if/when to backup container data.)
-
-* Service ownership.
-
-  (To determine internal cross-billing, or who to page in case of outage.)
-
-* etc.
-
-???
-
-:EN:- Using labels to identify containers
-:FR:- Étiqueter ses conteneurs avec des méta-données
-
-.debug[[containers/Labels.md](""/tree/main/slides/containers/Labels.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg)]
-
----
-
-name: toc-restarting-and-attaching-to-containers
-class: title
-
- Restarting and attaching to containers
-
-.nav[
-[Previous part](#toc-labels)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-getting-inside-a-container)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Restarting and attaching to containers
-
-We have started containers in the foreground, and in the background.
-
-In this chapter, we will see how to:
-
-* Put a container in the background.
-* Attach to a background container to bring it to the foreground.
-* Restart a stopped container.
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-## Background and foreground
-
-The distinction between foreground and background containers is arbitrary.
-
-From Docker's point of view, all containers are the same.
-
-All containers run the same way, whether there is a client attached to them or not.
-
-It is always possible to detach from a container, and to reattach to a container.
-
-Analogy: attaching to a container is like plugging a keyboard and screen to a physical server.
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-## Detaching from a container (Linux/macOS)
-
-* If you have started an *interactive* container (with option `-it`), you can detach from it.
-
-* The "detach" sequence is `^P^Q`.
-
-* Otherwise you can detach by killing the Docker client.
-  
-  (But not by hitting `^C`, as this would deliver `SIGINT` to the container.)
-
-What does `-it` stand for?
-
-* `-t` means "allocate a terminal."
-* `-i` means "connect stdin to the terminal."
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-## Detaching cont. (Win PowerShell and cmd.exe)
-
-* Docker for Windows has a different detach experience due to shell features.
-
-* `^P^Q` does not work.
-
-* `^C` will detach, rather than stop the container.
-
-* Using Bash, Subsystem for Linux, etc. on Windows behaves like Linux/macOS shells.
-
-* Both PowerShell and Bash work well in Win 10; just be aware of differences.
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-class: extra-details
-
-## Specifying a custom detach sequence
-
-* You don't like `^P^Q`? No problem!
-* You can change the sequence with `docker run --detach-keys`.
-* This can also be passed as a global option to the engine.
-
-Start a container with a custom detach command:
-
-```bash
-$ docker run -ti --detach-keys ctrl-x,x jpetazzo/clock
-```
-
-Detach by hitting `^X x`. (This is ctrl-x then x, not ctrl-x twice!)
-
-Check that our container is still running:
-
-```bash
-$ docker ps -l
-```
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-class: extra-details
-
-## Attaching to a container
-
-You can attach to a container:
-
-```bash
-$ docker attach <containerID>
-```
-
-* The container must be running.
-* There *can* be multiple clients attached to the same container.
-* If you don't specify `--detach-keys` when attaching, it defaults back to `^P^Q`.
-
-Try it on our previous container:
-
-```bash
-$ docker attach $(docker ps -lq)
-```
-
-Check that `^X x` doesn't work, but `^P ^Q` does.
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-## Detaching from non-interactive containers
-
-* **Warning:** if the container was started without `-it`...
-
-  * You won't be able to detach with `^P^Q`.
-  * If you hit `^C`, the signal will be proxied to the container.
-
-* Remember: you can always detach by killing the Docker client.
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-## Checking container output
-
-* Use `docker attach` if you intend to send input to the container.
-
-* If you just want to see the output of a container, use `docker logs`.
-
-```bash
-$ docker logs --tail 1 --follow <containerID>
-```
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-## Restarting a container
-
-When a container has exited, it is in stopped state.
-
-It can then be restarted with the `start` command.
-
-```bash
-$ docker start <yourContainerID>
-```
-
-The container will be restarted using the same options you launched it
-with.
-
-You can re-attach to it if you want to interact with it:
-
-```bash
-$ docker attach <yourContainerID>
-```
-
-Use `docker ps -a` to identify the container ID of a previous `jpetazzo/clock` container,
-and try those commands.
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-## Attaching to a REPL
-
-* REPL = Read Eval Print Loop
-
-* Shells, interpreters, TUI ...
-
-* Symptom: you `docker attach`, and see nothing
-
-* The REPL doesn't know that you just attached, and doesn't print anything
-
-* Try hitting `^L` or `Enter`
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-class: extra-details
-
-## SIGWINCH
-
-* When you `docker attach`, the Docker Engine sends SIGWINCH signals to the container.
-
-* SIGWINCH = WINdow CHange; indicates a change in window size.
-
-* This will cause some CLI and TUI programs to redraw the screen.
-
-* But not all of them.
-
-???
-
-:EN:- Restarting old containers
-:EN:- Detaching and reattaching to container
-:FR:- Redémarrer des anciens conteneurs
-:FR:- Se détacher et rattacher à des conteneurs
-
-.debug[[containers/Start_And_Attach.md](""/tree/main/slides/containers/Start_And_Attach.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg)]
-
----
-
-name: toc-getting-inside-a-container
-class: title
-
- Getting inside a container
-
-.nav[
-[Previous part](#toc-restarting-and-attaching-to-containers)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-limiting-resources)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Getting inside a container
-
-![Person standing inside a container](images/getting-inside.png)
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Objectives
-
-On a traditional server or VM, we sometimes need to:
-
-* log into the machine (with SSH or on the console),
-
-* analyze the disks (by removing them or rebooting with a rescue system).
-
-In this chapter, we will see how to do that with containers.
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Getting a shell
-
-Every once in a while, we want to log into a machine.
-
-In an perfect world, this shouldn't be necessary.
-
-* You need to install or update packages (and their configuration)?
-
-  Use configuration management. (e.g. Ansible, Chef, Puppet, Salt...)
-
-* You need to view logs and metrics?
-
-  Collect and access them through a centralized platform.
-
-In the real world, though ... we often need shell access!
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Not getting a shell
-
-Even without a perfect deployment system, we can do many operations without getting a shell.
-
-* Installing packages can (and should) be done in the container image.
-
-* Configuration can be done at the image level, or when the container starts.
-
-* Dynamic configuration can be stored in a volume (shared with another container).
-
-* Logs written to stdout are automatically collected by the Docker Engine.
-
-* Other logs can be written to a shared volume.
-
-* Process information and metrics are visible from the host.
-
-_Let's save logging, volumes ... for later, but let's have a look at process information!_
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Viewing container processes from the host
-
-If you run Docker on Linux, container processes are visible on the host.
-
-```bash
-$ ps faux | less
-```
-
-* Scroll around the output of this command.
-
-* You should see the `jpetazzo/clock` container.
-
-* A containerized process is just like any other process on the host.
-
-* We can use tools like `lsof`, `strace`, `gdb` ... To analyze them.
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-class: extra-details
-
-## What's the difference between a container process and a host process?
-
-* Each process (containerized or not) belongs to *namespaces* and *cgroups*.
-
-* The namespaces and cgroups determine what a process can "see" and "do".
-
-* Analogy: each process (containerized or not) runs with a specific UID (user ID).
-
-* UID=0 is root, and has elevated privileges. Other UIDs are normal users.
-
-_We will give more details about namespaces and cgroups later._
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Getting a shell in a running container
-
-* Sometimes, we need to get a shell anyway.
-
-* We _could_ run some SSH server in the container ...
-
-* But it is easier to use `docker exec`.
-
-```bash
-$ docker exec -ti ticktock sh
-```
-
-* This creates a new process (running `sh`) _inside_ the container.
-
-* This can also be done "manually" with the tool `nsenter`.
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Caveats
-
-* The tool that you want to run needs to exist in the container.
-
-* Some tools (like `ip netns exec`) let you attach to _one_ namespace at a time.
-
-  (This lets you e.g. setup network interfaces, even if you don't have `ifconfig` or `ip` in the container.)
-
-* Most importantly: the container needs to be running.
-
-* What if the container is stopped or crashed?
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Getting a shell in a stopped container
-
-* A stopped container is only _storage_ (like a disk drive).
-
-* We cannot SSH into a disk drive or USB stick!
-
-* We need to connect the disk to a running machine.
-
-* How does that translate into the container world?
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Analyzing a stopped container
-
-As an exercise, we are going to try to find out what's wrong with `jpetazzo/crashtest`.
-
-```bash
-docker run jpetazzo/crashtest
-```
-
-The container starts, but then stops immediately, without any output.
-
-What would MacGyver&trade; do?
-
-First, let's check the status of that container.
-
-```bash
-docker ps -l
-```
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Viewing filesystem changes
-
-* We can use `docker diff` to see files that were added / changed / removed.
-
-```bash
-docker diff <container_id>
-```
-
-* The container ID was shown by `docker ps -l`.
-
-* We can also see it with `docker ps -lq`.
-
-* The output of `docker diff` shows some interesting log files!
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Accessing files
-
-* We can extract files with `docker cp`.
-
-```bash
-docker cp <container_id>:/var/log/nginx/error.log .
-```
-
-* Then we can look at that log file.
-
-```bash
-cat error.log
-```
-
-(The directory `/run/nginx` doesn't exist.)
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-## Exploring a crashed container
-
-* We can restart a container with `docker start` ...
-
-* ... But it will probably crash again immediately!
-
-* We cannot specify a different program to run with `docker start`
-
-* But we can create a new image from the crashed container
-
-```bash
-docker commit <container_id> debugimage
-```
-
-* Then we can run a new container from that image, with a custom entrypoint
-
-```bash
-docker run -ti --entrypoint sh debugimage
-```
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-class: extra-details
-
-## Obtaining a complete dump
-
-* We can also dump the entire filesystem of a container.
-
-* This is done with `docker export`.
-
-* It generates a tar archive.
-
-```bash
-docker export <container_id> | tar tv
-```
-
-This will give a detailed listing of the content of the container.
-
-???
-
-:EN:- Troubleshooting and getting inside a container
-:FR:- Inspecter un conteneur en détail, en *live* ou *post-mortem*
-
-.debug[[containers/Getting_Inside.md](""/tree/main/slides/containers/Getting_Inside.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg)]
-
----
-
-name: toc-limiting-resources
-class: title
-
- Limiting resources
-
-.nav[
-[Previous part](#toc-getting-inside-a-container)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-container-networking-basics)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Limiting resources
-
-- So far, we have used containers as convenient units of deployment.
-
-- What happens when a container tries to use more resources than available?
-
-  (RAM, CPU, disk usage, disk and network I/O...)
-
-- What happens when multiple containers compete for the same resource?
-
-- Can we limit resources available to a container?
-
-  (Spoiler alert: yes!)
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Container processes are normal processes
-
-- Containers are closer to "fancy processes" than to "lightweight VMs".
-
-- A process running in a container is, in fact, a process running on the host.
-
-- Let's look at the output of `ps` on a container host running 3 containers :
-
-  ```
-       0  2662  0.2  0.3 /usr/bin/dockerd -H fd://
-       0  2766  0.1  0.1  \_ docker-containerd --config /var/run/docker/containe
-       0 23479  0.0  0.0      \_ docker-containerd-shim -namespace moby -workdir
-       0 23497  0.0  0.0      |   \_ `nginx`: master process nginx -g daemon off;
-     101 23543  0.0  0.0      |       \_ `nginx`: worker process
-       0 23565  0.0  0.0      \_ docker-containerd-shim -namespace moby -workdir
-     102 23584  9.4 11.3      |   \_ `/docker-java-home/jre/bin/java` -Xms2g -Xmx2
-       0 23707  0.0  0.0      \_ docker-containerd-shim -namespace moby -workdir
-       0 23725  0.0  0.0          \_ `/bin/sh`
-  ```
-
-- The highlighted processes are containerized processes.
-  <br/>
-  (That host is running nginx, elasticsearch, and alpine.)
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## By default: nothing changes
-
-- What happens when a process uses too much memory on a Linux system?
-
---
-
-- Simplified answer:
-
-  - swap is used (if available);
-
-  - if there is not enough swap space, eventually, the out-of-memory killer is invoked;
-
-  - the OOM killer uses heuristics to kill processes;
-
-  - sometimes, it kills an unrelated process.
-
---
-
-- What happens when a container uses too much memory?
-
-- The same thing!
-
-  (i.e., a process eventually gets killed, possibly in another container.)
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Limiting container resources
-
-- The Linux kernel offers rich mechanisms to limit container resources.
-
-- For memory usage, the mechanism is part of the *cgroup* subsystem.
-
-- This subsystem allows limiting the memory for a process or a group of processes.
-
-- A container engine leverages these mechanisms to limit memory for a container.
-
-- The out-of-memory killer has a new behavior:
-
-  - it runs when a container exceeds its allowed memory usage,
-
-  - in that case, it only kills processes in that container.
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Limiting memory in practice
-
-- The Docker Engine offers multiple flags to limit memory usage.
-
-- The two most useful ones are `--memory` and `--memory-swap`.
-
-- `--memory` limits the amount of physical RAM used by a container.
-
-- `--memory-swap` limits the total amount (RAM+swap) used by a container.
-
-- The memory limit can be expressed in bytes, or with a unit suffix.
-
-  (e.g.: `--memory 100m` = 100 megabytes.)
-
-- We will see two strategies: limiting RAM usage, or limiting both
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Limiting RAM usage
-
-Example:
-
-```bash
-docker run -ti --memory 100m python
-```
-
-If the container tries to use more than 100 MB of RAM, *and* swap is available:
-
-- the container will not be killed,
-
-- memory above 100 MB will be swapped out,
-
-- in most cases, the app in the container will be slowed down (a lot).
-
-If we run out of swap, the global OOM killer still intervenes.
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Limiting both RAM and swap usage
-
-Example:
-
-```bash
-docker run -ti --memory 100m --memory-swap 100m python
-```
-
-If the container tries to use more than 100 MB of memory, it is killed.
-
-On the other hand, the application will never be slowed down because of swap.
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## When to pick which strategy?
-
-- Stateful services (like databases) will lose or corrupt data when killed
-
-- Allow them to use swap space, but monitor swap usage
-
-- Stateless services can usually be killed with little impact
-
-- Limit their mem+swap usage, but monitor if they get killed
-
-- Ultimately, this is no different from "do I want swap, and how much?"
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Limiting CPU usage
-
-- There are no less than 3 ways to limit CPU usage:
-
-  - setting a relative priority with `--cpu-shares`,
-
-  - setting a CPU% limit with `--cpus`,
-
-  - pinning a container to specific CPUs with `--cpuset-cpus`.
-
-- They can be used separately or together.
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Setting relative priority
-
-- Each container has a relative priority used by the Linux scheduler.
-
-- By default, this priority is 1024.
-
-- As long as CPU usage is not maxed out, this has no effect.
-
-- When CPU usage is maxed out, each container receives CPU cycles in proportion of its relative priority.
-
-- In other words: a container with `--cpu-shares 2048` will receive twice as much than the default.
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Setting a CPU% limit
-
-- This setting will make sure that a container doesn't use more than a given % of CPU.
-
-- The value is expressed in CPUs; therefore:
-
-  `--cpus 0.1` means 10% of one CPU,
-
-  `--cpus 1.0` means 100% of one whole CPU,
-
-  `--cpus 10.0` means 10 entire CPUs.
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Pinning containers to CPUs
-
-- On multi-core machines, it is possible to restrict the execution on a set of CPUs.
-
-- Examples:
-
-  `--cpuset-cpus 0` forces the container to run on CPU 0;
-
-  `--cpuset-cpus 3,5,7` restricts the container to CPUs 3, 5, 7;
-
-  `--cpuset-cpus 0-3,8-11` restricts the container to CPUs 0, 1, 2, 3, 8, 9, 10, 11.
-
-- This will not reserve the corresponding CPUs!
-
-  (They might still be used by other containers, or uncontainerized processes.)
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-## Limiting disk usage
-
-- Most storage drivers do not support limiting the disk usage of containers.
-
-  (With the exception of devicemapper, but the limit cannot be set easily.)
- 
-- This means that a single container could exhaust disk space for everyone.
-
-- In practice, however, this is not a concern, because:
-
-  - data files (for stateful services) should reside on volumes,
-
-  - assets (e.g. images, user-generated content...) should reside on object stores or on volume,
-
-  - logs are written on standard output and gathered by the container engine.
-
-- Container disk usage can be audited with `docker ps -s` and `docker diff`.
-
-.debug[[containers/Resource_Limits.md](""/tree/main/slides/containers/Resource_Limits.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg)]
-
----
-
-name: toc-container-networking-basics
-class: title
-
- Container networking basics
-
-.nav[
-[Previous part](#toc-limiting-resources)
-|
-[Back to table of contents](#toc-part-5)
-|
-[Next part](#toc-container-network-drivers)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Container networking basics
-
-![A dense graph network](images/title-container-networking-basics.jpg)
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Objectives
-
-We will now run network services (accepting requests) in containers.
-
-At the end of this section, you will be able to:
-
-* Run a network service in a container.
-
-* Connect to that network service.
-
-* Find a container's IP address.
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Running a very simple service
-
-- We need something small, simple, easy to configure
-
-  (or, even better, that doesn't require any configuration at all)
-
-- Let's use the official NGINX image (named `nginx`)
-
-- It runs a static web server listening on port 80
-
-- It serves a default "Welcome to nginx!" page
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Running an NGINX server
-
-```bash
-$ docker run -d -P nginx
-66b1ce719198711292c8f34f84a7b68c3876cf9f67015e752b94e189d35a204e
-```
-
-- Docker will automatically pull the `nginx` image from the Docker Hub
-
-- `-d` / `--detach` tells Docker to run it in the background
-
-- `P` / `--publish-all` tells Docker to publish all ports
-
-  (publish = make them reachable from other computers)
-
-- ...OK, how do we connect to our web server now?
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Finding our web server port
-
-- First, we need to find the *port number* used by Docker
-
-  (the NGINX container listens on port 80, but this port will be *mapped*)
-
-- We can use `docker ps`:
-  ```bash
-  $ docker ps
-  CONTAINER ID  IMAGE  ...  PORTS                  ...
-  e40ffb406c9e  nginx  ...  0.0.0.0:`12345`->80/tcp  ...
-  ```
-
-- This means:
-
-  *port 12345 on the Docker host is mapped to port 80 in the container*
-
-- Now we need to connect to the Docker host!
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Finding the address of the Docker host
-
-- When running Docker on your Linux workstation:
-
-  *use `localhost`, or any IP address of your machine*
-
-- When running Docker on a remote Linux server:
-
-  *use any IP address of the remote machine*
-
-- When running Docker Desktop on Mac or Windows:
-
-  *use `localhost`*
-
-- In other scenarios (`docker-machine`, local VM...):
-
-  *use the IP address of the Docker VM*
-  
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Connecting to our web server (GUI)
-
-Point your browser to the IP address of your Docker host, on the port
-shown by `docker ps` for container port 80.
-
-![Screenshot](images/welcome-to-nginx.png)
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Connecting to our web server (CLI)
-
-You can also use `curl` directly from the Docker host.
-
-Make sure to use the right port number if it is different
-from the example below:
-
-```bash
-$ curl localhost:12345
-<!DOCTYPE html>
-<html>
-<head>
-<title>Welcome to nginx!</title>
-...
-```
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## How does Docker know which port to map?
-
-* There is metadata in the image telling "this image has something on port 80".
-
-* We can see that metadata with `docker inspect`:
-
-```bash
-$ docker inspect --format '{{.Config.ExposedPorts}}' nginx
-map[80/tcp:{}]
-```
-
-* This metadata was set in the Dockerfile, with the `EXPOSE` keyword.
-
-* We can see that with `docker history`:
-
-```bash
-$ docker history nginx
-IMAGE               CREATED             CREATED BY
-7f70b30f2cc6        11 days ago         /bin/sh -c #(nop)  CMD ["nginx" "-g" "…
-<missing>           11 days ago         /bin/sh -c #(nop)  STOPSIGNAL [SIGTERM]
-<missing>           11 days ago         /bin/sh -c #(nop)  EXPOSE 80/tcp
-```
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Why can't we just connect to port 80?
-
-- Our Docker host has only one port 80
-
-- Therefore, we can only have one container at a time on port 80
-
-- Therefore, if multiple containers want port 80, only one can get it
-
-- By default, containers *do not* get "their" port number, but a random one
-
-  (not "random" as "crypto random", but as "it depends on various factors")
-
-- We'll see later how to force a port number (including port 80!)
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-class: extra-details
-
-## Using multiple IP addresses
-
-*Hey, my network-fu is strong, and I have questions...*
-
-- Can I publish one container on 127.0.0.2:80, and another on 127.0.0.3:80?
-
-- My machine has multiple (public) IP addresses, let's say A.A.A.A and B.B.B.B.
-  <br/>
-  Can I have one container on A.A.A.A:80 and another on B.B.B.B:80?
-
-- I have a whole IPV4 subnet, can I allocate it to my containers?
-
-- What about IPV6?
-
-You can do all these things when running Docker directly on Linux.
-
-(On other platforms, *generally not*, but there are some exceptions.)
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Finding the web server port in a script
-
-Parsing the output of `docker ps` would be painful.
-
-There is a command to help us:
-
-```bash
-$ docker port <containerID> 80
-0.0.0.0:12345
-```
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Manual allocation of port numbers
-
-If you want to set port numbers yourself, no problem:
-
-```bash
-$ docker run -d -p 80:80 nginx
-$ docker run -d -p 8000:80 nginx
-$ docker run -d -p 8080:80 -p 8888:80 nginx
-```
-
-* We are running three NGINX web servers.
-* The first one is exposed on port 80.
-* The second one is exposed on port 8000.
-* The third one is exposed on ports 8080 and 8888.
-
-Note: the convention is `port-on-host:port-on-container`.
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Plumbing containers into your infrastructure
-
-There are many ways to integrate containers in your network.
-
-* Start the container, letting Docker allocate a public port for it.
-  <br/>Then retrieve that port number and feed it to your configuration.
-
-* Pick a fixed port number in advance, when you generate your configuration.
-  <br/>Then start your container by setting the port numbers manually.
-
-* Use an orchestrator like Kubernetes or Swarm.
-  <br/>The orchestrator will provide its own networking facilities.
-
-Orchestrators typically provide mechanisms to enable direct container-to-container
-communication across hosts, and publishing/load balancing for inbound traffic.
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Finding the container's IP address
-
-We can use the `docker inspect` command to find the IP address of the
-container.
-
-```bash
-$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' <yourContainerID>
-172.17.0.3
-```
-
-* `docker inspect` is an advanced command, that can retrieve a ton
-  of information about our containers.
-
-* Here, we provide it with a format string to extract exactly the
-  private IP address of the container.
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Pinging our container
-
-Let's try to ping our container *from another container.*
-
-```bash
-docker run alpine ping `<ipaddress>`
-PING 172.17.0.X (172.17.0.X): 56 data bytes
-64 bytes from 172.17.0.X: seq=0 ttl=64 time=0.106 ms
-64 bytes from 172.17.0.X: seq=1 ttl=64 time=0.250 ms
-64 bytes from 172.17.0.X: seq=2 ttl=64 time=0.188 ms
-```
-
-When running on Linux, we can even ping that IP address directly!
-
-(And connect to a container's ports even if they aren't published.)
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## How often do we use `-p` and `-P` ?
-
-- When running a stack of containers, we will often use Compose
-
-- Compose will take care of exposing containers
-
-  (through a `ports:` section in the `docker-compose.yml` file)
-
-- It is, however, fairly common to use `docker run -P` for a quick test
-
-- Or `docker run -p ...` when an image doesn't `EXPOSE` a port correctly
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-## Section summary
-
-We've learned how to:
-
-* Expose a network port.
-
-* Connect to an application running in a container.
-
-* Find a container's IP address.
-
-???
-
-:EN:- Exposing single containers
-:FR:- Exposer un conteneur isolé
-
-.debug[[containers/Container_Networking_Basics.md](""/tree/main/slides/containers/Container_Networking_Basics.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-housing.jpg)]
-
----
-
-name: toc-container-network-drivers
-class: title
-
- Container network drivers
-
-.nav[
-[Previous part](#toc-container-networking-basics)
-|
-[Back to table of contents](#toc-part-5)
-|
-[Next part](#toc-the-container-network-model)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Container network drivers
-
-The Docker Engine supports different network drivers.
-
-The built-in drivers include:
-
-* `bridge` (default)
-
-* `null` (for the special network called `none`)
-
-* `host` (for the special network called `host`)
-
-* `container` (that one is a bit magic!)
-
-The network is selected with `docker run --net ...`.
-
-Each network is managed by a driver.
-
-The different drivers are explained with more details on the following slides.
-
-.debug[[containers/Network_Drivers.md](""/tree/main/slides/containers/Network_Drivers.md)]
----
-
-## The default bridge
-
-* By default, the container gets a virtual `eth0` interface.
-  <br/>(In addition to its own private `lo` loopback interface.)
-
-* That interface is provided by a `veth` pair.
-
-* It is connected to the Docker bridge.
-  <br/>(Named `docker0` by default; configurable with `--bridge`.)
-
-* Addresses are allocated on a private, internal subnet.
-  <br/>(Docker uses 172.17.0.0/16 by default; configurable with `--bip`.)
-
-* Outbound traffic goes through an iptables MASQUERADE rule.
-
-* Inbound traffic goes through an iptables DNAT rule.
-
-* The container can have its own routes, iptables rules, etc.
-
-.debug[[containers/Network_Drivers.md](""/tree/main/slides/containers/Network_Drivers.md)]
----
-
-## The null driver
-
-* Container is started with `docker run --net none ...`
-
-* It only gets the `lo` loopback interface. No `eth0`.
-
-* It can't send or receive network traffic.
-
-* Useful for isolated/untrusted workloads.
-
-.debug[[containers/Network_Drivers.md](""/tree/main/slides/containers/Network_Drivers.md)]
----
-
-## The host driver
-
-* Container is started with `docker run --net host ...`
-
-* It sees (and can access) the network interfaces of the host.
-
-* It can bind any address, any port (for ill and for good).
-
-* Network traffic doesn't have to go through NAT, bridge, or veth.
-
-* Performance = native!
-
-Use cases:
-
-* Performance sensitive applications (VOIP, gaming, streaming...)
-
-* Peer discovery (e.g. Erlang port mapper, Raft, Serf...)
-
-.debug[[containers/Network_Drivers.md](""/tree/main/slides/containers/Network_Drivers.md)]
----
-
-## The container driver
-
-* Container is started with `docker run --net container:id ...`
-
-* It re-uses the network stack of another container.
-
-* It shares with this other container the same interfaces, IP address(es), routes, iptables rules, etc.
-
-* Those containers can communicate over their `lo` interface.
-  <br/>(i.e. one can bind to 127.0.0.1 and the others can connect to it.)
-
-???
-
-:EN:Advanced container networking
-:EN:- Transparent network access with the "host" driver
-:EN:- Sharing is caring with the "container" driver
-
-:FR:Paramétrage réseau avancé
-:FR:- Accès transparent au réseau avec le mode "host"
-:FR:- Partage de la pile réseau avece le mode "container"
-
-.debug[[containers/Network_Drivers.md](""/tree/main/slides/containers/Network_Drivers.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/containers-by-the-water.jpg)]
-
----
-
-name: toc-the-container-network-model
-class: title
-
- The Container Network Model
-
-.nav[
-[Previous part](#toc-container-network-drivers)
-|
-[Back to table of contents](#toc-part-5)
-|
-[Next part](#toc-service-discovery-with-containers)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# The Container Network Model
-
-![A denser graph network](images/title-the-container-network-model.jpg)
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Objectives
-
-We will learn about the CNM (Container Network Model).
-
-At the end of this lesson, you will be able to:
-
-* Create a private network for a group of containers.
-
-* Use container naming to connect services together.
-
-* Dynamically connect and disconnect containers to networks.
-
-* Set the IP address of a container.
-
-We will also explain the principle of overlay networks and network plugins.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## The Container Network Model
-
-Docker has "networks".
-
-We can manage them with the `docker network` commands; for instance:
-
-```bash
-$ docker network ls
-NETWORK ID          NAME                DRIVER
-6bde79dfcf70        bridge              bridge
-8d9c78725538        none                null
-eb0eeab782f4        host                host
-4c1ff84d6d3f        blog-dev            overlay
-228a4355d548        blog-prod           overlay
-```
-
-New networks can be created (with `docker network create`).
-
-(Note: networks `none` and `host` are special; let's set them aside for now.)
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## What's a network?
-
-- Conceptually, a Docker "network" is a virtual switch
-
-  (we can also think about it like a VLAN, or a WiFi SSID, for instance)
-
-- By default, containers are connected to a single network
-
-  (but they can be connected to zero, or many networks, even dynamically)
-
-- Each network has its own subnet (IP address range)
-
-- A network can be local (to a single Docker Engine) or global (span multiple hosts)
-
-- Containers can have *network aliases* providing DNS-based service discovery
-
-  (and each network has its own "domain", "zone", or "scope")
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Service discovery
-
-- A container can be given a network alias
-
-  (e.g. with `docker run --net some-network --net-alias db ...`)
-
-- The containers running in the same network can resolve that network alias
-
-  (i.e. if they do a DNS lookup on `db`, it will give the container's address)
-
-- We can have a different `db` container in each network
-
-  (this avoids naming conflicts between different stacks)
-
-- When we name a container, it automatically adds the name as a network alias
-
-  (i.e. `docker run --name xyz ...` is like `docker run --net-alias xyz ...`
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Network isolation
-
-- Networks are isolated
-
-- By default, containers in network A cannot reach those in network B
-
-- A container connected to both networks A and B can act as a router or proxy
-
-- Published ports are always reachable through the Docker host address
-
-  (`docker run -P ...` makes a container port available to everyone)
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## How to use networks
-
-- We typically create one network per "stack" or app that we deploy
-
-- More complex apps or stacks might require multiple networks
-
-  (e.g. `frontend`, `backend`, ...)
-
-- Networks allow us to deploy multiple copies of the same stack
-
-  (e.g. `prod`, `dev`, `pr-442`, ....)
-
-- If we use Docker Compose, this is managed automatically for us
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: pic
-
-![Multiple containers on the default bridge network, on a Linux machine](images/docker-networking-default-bridge-linux.png)
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: pic
-
-![Multiple containers in multiple bridge networks, on a Linux machine](images/docker-networking-networks-linux.png)
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: pic
-
-![Multiple containers in multiple bridge networks, on a Mac/Windows machine](images/docker-networking-networks-macwin.png)
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## CNM vs CNI
-
-- CNM is the model used by Docker
-
-- Kubernetes uses a different model, architectured around CNI
-
-  (CNI is a kind of API between a container engine and *CNI plugins*)
-
-- Docker model:
-
-  - multiple isolated networks
-  - per-network service discovery
-  - network interconnection requires extra steps
-
-- Kubernetes model:
-
-  - single flat network
-  - per-namespace service discovery
-  - network isolation requires extra steps (Network Policies)
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Creating a network
-
-Let's create a network called `dev`.
-
-```bash
-$ docker network create dev
-4c1ff84d6d3f1733d3e233ee039cac276f425a9d5228a4355d54878293a889ba
-```
-
-The network is now visible with the `network ls` command:
-
-```bash
-$ docker network ls
-NETWORK ID          NAME                DRIVER
-6bde79dfcf70        bridge              bridge
-8d9c78725538        none                null
-eb0eeab782f4        host                host
-4c1ff84d6d3f        dev                 bridge
-```
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Placing containers on a network
-
-We will create a *named* container on this network.
-
-It will be reachable with its name, `es`.
-
-```bash
-$ docker run -d --name es --net dev elasticsearch:2
-8abb80e229ce8926c7223beb69699f5f34d6f1d438bfc5682db893e798046863
-```
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Communication between containers
-
-Now, create another container on this network.
-
-.small[
-```bash
-$ docker run -ti --net dev alpine sh
-root@0ecccdfa45ef:/#
-```
-]
-
-From this new container, we can resolve and ping the other one, using its assigned name:
-
-.small[
-```bash
-/ # ping es
-PING es (172.18.0.2) 56(84) bytes of data.
-64 bytes from es.dev (172.18.0.2): icmp_seq=1 ttl=64 time=0.221 ms
-64 bytes from es.dev (172.18.0.2): icmp_seq=2 ttl=64 time=0.114 ms
-64 bytes from es.dev (172.18.0.2): icmp_seq=3 ttl=64 time=0.114 ms
-^C
---- es ping statistics ---
-3 packets transmitted, 3 received, 0% packet loss, time 2000ms
-rtt min/avg/max/mdev = 0.114/0.149/0.221/0.052 ms
-root@0ecccdfa45ef:/#
-```
-]
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Resolving container addresses
-
-Since Docker Engine 1.10, name resolution is implemented by a dynamic resolver.
-
-Archeological note: when CNM was intoduced (in Docker Engine 1.9, November 2015)
-name resolution was implemented with `/etc/hosts`, and it was updated each time
-CONTAINERs were added/removed. This could cause interesting race conditions
-since `/etc/hosts` was a bind-mount (and couldn't be updated atomically).
-
-.small[
-```bash
-[root@0ecccdfa45ef /]# cat /etc/hosts
-172.18.0.3  0ecccdfa45ef
-127.0.0.1       localhost
-::1     localhost ip6-localhost ip6-loopback
-fe00::0 ip6-localnet
-ff00::0 ip6-mcastprefix
-ff02::1 ip6-allnodes
-ff02::2 ip6-allrouters
-172.18.0.2      es
-172.18.0.2      es.dev
-```
-]
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/distillery-containers.jpg)]
-
----
-
-name: toc-service-discovery-with-containers
-class: title
-
- Service discovery with containers
-
-.nav[
-[Previous part](#toc-the-container-network-model)
-|
-[Back to table of contents](#toc-part-5)
-|
-[Next part](#toc-local-development-workflow-with-docker)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-# Service discovery with containers
-
-* Let's try to run an application that requires two containers.
-
-* The first container is a web server.
-
-* The other one is a redis data store.
-
-* We will place them both on the `dev` network created before.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Running the web server
-
-* The application is provided by the container image `jpetazzo/trainingwheels`.
-
-* We don't know much about it so we will try to run it and see what happens!
-
-Start the container, exposing all its ports:
-
-```bash
-$ docker run --net dev -d -P jpetazzo/trainingwheels
-```
-
-Check the port that has been allocated to it:
-
-```bash
-$ docker ps -l
-```
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Test the web server
-
-* If we connect to the application now, we will see an error page:
-
-![Trainingwheels error](images/trainingwheels-error.png)
-
-* This is because the Redis service is not running.
-* This container tries to resolve the name `redis`.
-
-Note: we're not using a FQDN or an IP address here; just `redis`.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Start the data store
-
-* We need to start a Redis container.
-
-* That container must be on the same network as the web server.
-
-* It must have the right network alias (`redis`) so the application can find it.
-
-Start the container:
-
-```bash
-$ docker run --net dev --net-alias redis -d redis
-```
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Test the web server again
-
-* If we connect to the application now, we should see that the app is working correctly:
-
-![Trainingwheels OK](images/trainingwheels-ok.png)
-
-* When the app tries to resolve `redis`, instead of getting a DNS error, it gets the IP address of our Redis container.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## A few words on *scope*
-
-- Container names are unique (there can be only one `--name redis`)
-
-- Network aliases are not unique
-
-- We can have the same network alias in different networks:
-  ```bash
-  docker run --net dev --net-alias redis ...
-  docker run --net prod --net-alias redis ...
-  ```
-
-- We can even have multiple containers with the same alias in the same network
-
-  (in that case, we get multiple DNS entries, aka "DNS round robin")
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Names are *local* to each network
-
-Let's try to ping our `es` container from another container, when that other container is *not* on the `dev` network.
-
-```bash
-$ docker run --rm alpine ping es
-ping: bad address 'es'
-```
-
-Names can be resolved only when containers are on the same network.
-
-Containers can contact each other only when they are on the same network (you can try to ping using the IP address to verify).
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Network aliases
-
-We would like to have another network, `prod`, with its own `es` container. But there can be only one container named `es`!
-
-We will use *network aliases*.
-
-A container can have multiple network aliases.
-
-Network aliases are *local* to a given network (only exist in this network).
-
-Multiple containers can have the same network alias (even on the same network).
-
-Since Docker Engine 1.11, resolving a network alias yields the IP addresses of all containers holding this alias.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Creating containers on another network
-
-Create the `prod` network.
-
-```bash
-$ docker network create prod
-5a41562fecf2d8f115bedc16865f7336232a04268bdf2bd816aecca01b68d50c
-```
-
-We can now create multiple containers with the `es` alias on the new `prod` network.
-
-```bash
-$ docker run -d --name prod-es-1 --net-alias es --net prod elasticsearch:2
-38079d21caf0c5533a391700d9e9e920724e89200083df73211081c8a356d771
-$ docker run -d --name prod-es-2 --net-alias es --net prod elasticsearch:2
-1820087a9c600f43159688050dcc164c298183e1d2e62d5694fd46b10ac3bc3d
-```
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Resolving network aliases
-
-Let's try DNS resolution first, using the `nslookup` tool that ships with the `alpine` image.
-
-```bash
-$ docker run --net prod --rm alpine nslookup es
-Name:      es
-Address 1: 172.23.0.3 prod-es-2.prod
-Address 2: 172.23.0.2 prod-es-1.prod
-```
-
-(You can ignore the `can't resolve '(null)'` errors.)
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Connecting to aliased containers
-
-Each ElasticSearch instance has a name (generated when it is started). This name can be seen when we issue a simple HTTP request on the ElasticSearch API endpoint.
-
-Try the following command a few times:
-
-.small[
-```bash
-$ docker run --rm --net dev centos curl -s es:9200
-{
-  "name" : "Tarot",
-...
-}
-```
-]
-
-Then try it a few times by replacing `--net dev` with `--net prod`:
-
-.small[
-```bash
-$ docker run --rm --net prod centos curl -s es:9200
-{
-  "name" : "The Symbiote",
-...
-}
-```
-]
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Good to know ...
-
-* Docker will not create network names and aliases on the default `bridge` network.
-
-* Therefore, if you want to use those features, you have to create a custom network first.
-
-* Network aliases are *not* unique on a given network.
-
-* i.e., multiple containers can have the same alias on the same network.
-
-* In that scenario, the Docker DNS server will return multiple records.
-  <br/>
-  (i.e. you will get DNS round robin out of the box.)
-
-* Enabling *Swarm Mode* gives access to clustering and load balancing with IPVS.
-
-* Creation of networks and network aliases is generally automated with tools like Compose.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## A few words about round robin DNS
-
-Don't rely exclusively on round robin DNS to achieve load balancing.
-
-Many factors can affect DNS resolution, and you might see:
-
-- all traffic going to a single instance;
-- traffic being split (unevenly) between some instances;
-- different behavior depending on your application language;
-- different behavior depending on your base distro;
-- different behavior depending on other factors (sic).
-
-It's OK to use DNS to discover available endpoints, but remember that you have to re-resolve every now and then to discover new endpoints.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Custom networks
-
-When creating a network, extra options can be provided.
-
-* `--internal` disables outbound traffic (the network won't have a default gateway).
-
-* `--gateway` indicates which address to use for the gateway (when outbound traffic is allowed).
-
-* `--subnet` (in CIDR notation) indicates the subnet to use.
-
-* `--ip-range` (in CIDR notation) indicates the subnet to allocate from.
-
-* `--aux-address` allows specifying a list of reserved addresses (which won't be allocated to containers).
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Setting containers' IP address
-
-* It is possible to set a container's address with `--ip`.
-* The IP address has to be within the subnet used for the container.
-
-A full example would look like this.
-
-```bash
-$ docker network create --subnet 10.66.0.0/16 pubnet
-42fb16ec412383db6289a3e39c3c0224f395d7f85bcb1859b279e7a564d4e135
-$ docker run --net pubnet --ip 10.66.66.66 -d nginx
-b2887adeb5578a01fd9c55c435cad56bbbe802350711d2743691f95743680b09
-```
-
-*Note: don't hard code container IP addresses in your code!*
-
-*I repeat: don't hard code container IP addresses in your code!*
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Network drivers
-
-* A network is managed by a *driver*.
-
-* The built-in drivers include:
-
-  * `bridge` (default)
-  * `none`
-  * `host`
-  * `macvlan`
-  * `overlay` (for Swarm clusters)
-
-* More drivers can be provided by plugins (OVS, VLAN...)
-
-* A network can have a custom IPAM (IP allocator).
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Overlay networks
-
-* The features we've seen so far only work when all containers are on a single host.
-
-* If containers span multiple hosts, we need an *overlay* network to connect them together.
-
-* Docker ships with a default network plugin, `overlay`, implementing an overlay network leveraging
-  VXLAN, *enabled with Swarm Mode*.
-
-* Other plugins (Weave, Calico...) can provide overlay networks as well.
-
-* Once you have an overlay network, *all the features that we've used in this chapter work identically
-  across multiple hosts.*
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Multi-host networking (overlay)
-
-Out of the scope for this intro-level workshop!
-
-Very short instructions:
-
-- enable Swarm Mode (`docker swarm init` then `docker swarm join` on other nodes)
-- `docker network create mynet --driver overlay`
-- `docker service create --network mynet myimage`
-
-If you want to learn more about Swarm mode, you can check
-[this video](https://www.youtube.com/watch?v=EuzoEaE6Cqs)
-or [these slides](https://container.training/swarm-selfpaced.yml.html).
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Multi-host networking (plugins)
-
-Out of the scope for this intro-level workshop!
-
-General idea:
-
-- install the plugin (they often ship within containers)
-
-- run the plugin (if it's in a container, it will often require extra parameters; don't just `docker run` it blindly!)
-
-- some plugins require configuration or activation (creating a special file that tells Docker "use the plugin whose control socket is at the following location")
-
-- you can then `docker network create --driver pluginname`
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Connecting and disconnecting dynamically
-
-* So far, we have specified which network to use when starting the container.
-
-* The Docker Engine also allows connecting and disconnecting while the container is running.
-
-* This feature is exposed through the Docker API, and through two Docker CLI commands:
-
-  * `docker network connect <network> <container>`
-
-  * `docker network disconnect <network> <container>`
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Dynamically connecting to a network
-
-* We have a container named `es` connected to a network named `dev`.
-
-* Let's start a simple alpine container on the default network:
-
-  ```bash
-  $ docker run -ti alpine sh
-  / #
-  ```
-
-* In this container, try to ping the `es` container:
-
-  ```bash
-  / # ping es
-  ping: bad address 'es'
-  ```
-
-  This doesn't work, but we will change that by connecting the container.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Finding the container ID and connecting it
-
-* Figure out the ID of our alpine container; here are two methods:
-
-  * looking at `/etc/hostname` in the container,
-
-  * running `docker ps -lq` on the host.
-
-* Run the following command on the host:
-
-  ```bash
-  $ docker network connect dev `<container_id>`
-  ```
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Checking what we did
-
-* Try again to `ping es` from the container.
-
-* It should now work correctly:
-
-  ```bash
-  / # ping es
-  PING es (172.20.0.3): 56 data bytes
-  64 bytes from 172.20.0.3: seq=0 ttl=64 time=0.376 ms
-  64 bytes from 172.20.0.3: seq=1 ttl=64 time=0.130 ms
-  ^C
-  ```
-
-* Interrupt it with Ctrl-C.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Looking at the network setup in the container
-
-We can look at the list of network interfaces with `ifconfig`, `ip a`, or `ip l`:
-
-.small[
-```bash
-/ # ip a
-1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
-    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
-    inet 127.0.0.1/8 scope host lo
-       valid_lft forever preferred_lft forever
-18: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
-    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
-    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
-       valid_lft forever preferred_lft forever
-20: eth1@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
-    link/ether 02:42:ac:14:00:04 brd ff:ff:ff:ff:ff:ff
-    inet 172.20.0.4/16 brd 172.20.255.255 scope global eth1
-       valid_lft forever preferred_lft forever
-/ #
-```
-]
-
-Each network connection is materialized with a virtual network interface.
-
-As we can see, we can be connected to multiple networks at the same time.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-## Disconnecting from a network
-
-* Let's try the symmetrical command to disconnect the container:
-  ```bash
-  $ docker network disconnect dev <container_id>
-  ```
-
-* From now on, if we try to ping `es`, it will not resolve:
-  ```bash
-  / # ping es
-  ping: bad address 'es'
-  ```
-
-* Trying to ping the IP address directly won't work either:
-  ```bash
-  / # ping 172.20.0.3
-  ... (nothing happens until we interrupt it with Ctrl-C)
-  ```
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Network aliases are scoped per network
-
-* Each network has its own set of network aliases.
-
-* We saw this earlier: `es` resolves to different addresses in `dev` and `prod`.
-
-* If we are connected to multiple networks, the resolver looks up names in each of them
-  (as of Docker Engine 18.03, it is the connection order) and stops as soon as the name
-  is found.
-
-* Therefore, if we are connected to both `dev` and `prod`, resolving `es` will **not**
-  give us the addresses of all the `es` services; but only the ones in `dev` or `prod`.
-
-* However, we can lookup `es.dev` or `es.prod` if we need to.
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Finding out about our networks and names
-
-* We can do reverse DNS lookups on containers' IP addresses.
-
-* If the IP address belongs to a network (other than the default bridge), the result will be:
-
-  ```
-  name-or-first-alias-or-container-id.network-name
-  ```
-
-* Example:
-
-.small[
-```bash
-$ docker run -ti --net prod --net-alias hello alpine
-/ # apk add --no-cache drill
-...
-OK: 5 MiB in 13 packages
-/ # ifconfig
-eth0      Link encap:Ethernet  HWaddr 02:42:AC:15:00:03
-          inet addr:`172.21.0.3`  Bcast:172.21.255.255  Mask:255.255.0.0
-          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
-...
-/ # drill -t ptr `3.0.21.172`.in-addr.arpa
-...
-;; ANSWER SECTION:
-3.0.21.172.in-addr.arpa.	600	IN	PTR	`hello.prod`.
-...
-```
-]
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: extra-details
-
-## Building with a custom network
-
-* We can build a Dockerfile with a custom network with `docker build --network NAME`.
-
-* This can be used to check that a build doesn't access the network.
-
-  (But keep in mind that most Dockerfiles will fail,
-  <br/>because they need to install remote packages and dependencies!)
-
-* This may be used to access an internal package repository.
-
-  (But try to use a multi-stage build instead, if possible!)
-
-???
-
-:EN:Container networking essentials
-:EN:- The Container Network Model
-:EN:- Container isolation
-:EN:- Service discovery
-
-:FR:Mettre ses conteneurs en réseau
-:FR:- Le "Container Network Model"
-:FR:- Isolation des conteneurs
-:FR:- *Service discovery*
-
-.debug[[containers/Container_Network_Model.md](""/tree/main/slides/containers/Container_Network_Model.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/lots-of-containers.jpg)]
-
----
-
-name: toc-local-development-workflow-with-docker
-class: title
-
- Local development workflow with Docker
-
-.nav[
-[Previous part](#toc-service-discovery-with-containers)
-|
-[Back to table of contents](#toc-part-6)
-|
-[Next part](#toc-working-with-volumes)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Local development workflow with Docker
-
-![Construction site](images/title-local-development-workflow-with-docker.jpg)
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Objectives
-
-At the end of this section, you will be able to:
-
-* Share code between container and host.
-
-* Use a simple local development workflow.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Local development in a container
-
-We want to solve the following issues:
-
-- "Works on my machine"
-
-- "Not the same version"
-
-- "Missing dependency"
-
-By using Docker containers, we will get a consistent development environment.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Working on the "namer" application
-
-* We have to work on some application whose code is at:
-
-  https://github.com/jpetazzo/namer.
-
-* What is it? We don't know yet!
-
-* Let's download the code.
-
-```bash
-$ git clone https://github.com/jpetazzo/namer
-```
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Looking at the code
-
-```bash
-$ cd namer
-$ ls -1
-company_name_generator.rb
-config.ru
-docker-compose.yml
-Dockerfile
-Gemfile
-```
-
---
-
-Aha, a `Gemfile`! This is Ruby. Probably. We know this. Maybe?
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Looking at the `Dockerfile`
-
-```dockerfile
-FROM ruby
-
-COPY . /src
-WORKDIR /src
-RUN bundler install
-
-CMD ["rackup", "--host", "0.0.0.0"]
-EXPOSE 9292
-```
-
-* This application is using a base `ruby` image.
-* The code is copied in `/src`.
-* Dependencies are installed with `bundler`.
-* The application is started with `rackup`.
-* It is listening on port 9292.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Building and running the "namer" application
-
-* Let's build the application with the `Dockerfile`!
-
---
-
-```bash
-$ docker build -t namer .
-```
-
---
-
-* Then run it. *We need to expose its ports.*
-
---
-
-```bash
-$ docker run -dP namer
-```
-
---
-
-* Check on which port the container is listening.
-
---
-
-```bash
-$ docker ps -l
-```
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Connecting to our application
-
-* Point our browser to our Docker node, on the port allocated to the container.
-
---
-
-* Hit "reload" a few times.
-
---
-
-* This is an enterprise-class, carrier-grade, ISO-compliant company name generator!
-
-  (With 50% more bullshit than the average competition!)
-
-  (Wait, was that 50% more, or 50% less? *Anyway!*)
-
-  ![web application 1](images/webapp-in-blue.png)
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Making changes to the code
-
-Option 1:
-
-* Edit the code locally
-* Rebuild the image
-* Re-run the container
-
-Option 2:
-
-* Enter the container (with `docker exec`)
-* Install an editor
-* Make changes from within the container
-
-Option 3:
-
-* Use a *bind mount* to share local files with the container
-* Make changes locally
-* Changes are reflected in the container
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Our first volume
-
-We will tell Docker to map the current directory to `/src` in the container.
-
-```bash
-$ docker run -d -v $(pwd):/src -P namer
-```
-
-* `-d`: the container should run in detached mode (in the background).
-
-* `-v`: the following host directory should be mounted inside the container.
-
-* `-P`: publish all the ports exposed by this image.
-
-* `namer` is the name of the image we will run.
-
-* We don't specify a command to run because it is already set in the Dockerfile via `CMD`.
-
-Note: on Windows, replace `$(pwd)` with `%cd%` (or `${pwd}` if you use PowerShell).
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Mounting volumes inside containers
-
-The `-v` flag mounts a directory from your host into your Docker container.
-
-The flag structure is:
-
-```bash
-[host-path]:[container-path]:[rw|ro]
-```
-
-* `[host-path]` and `[container-path]` are created if they don't exist.
-
-* You can control the write status of the volume with the `ro` and
-  `rw` options.
-
-* If you don't specify `rw` or `ro`, it will be `rw` by default.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-class: extra-details
-
-## Hold your horses... and your mounts
-
-- The `-v /path/on/host:/path/in/container` syntax is the "old" syntax
-
-- The modern syntax looks like this:
-
-  `--mount type=bind,source=/path/on/host,target=/path/in/container`
-
-- `--mount` is more explicit, but `-v` is quicker to type
-
-- `--mount` supports all mount types; `-v` doesn't support `tmpfs` mounts
-
-- `--mount` fails if the path on the host doesn't exist; `-v` creates it
-
-With the new syntax, our command becomes:
-```bash
-docker run --mount=type=bind,source=$(pwd),target=/src -dP namer
-```
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Testing the development container
-
-* Check the port used by our new container.
-
-```bash
-$ docker ps -l
-CONTAINER ID  IMAGE  COMMAND  CREATED        STATUS  PORTS                   NAMES
-045885b68bc5  namer  rackup   3 seconds ago  Up ...  0.0.0.0:32770->9292/tcp ...
-```
-
-* Open the application in your web browser.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Making a change to our application
-
-Our customer really doesn't like the color of our text. Let's change it.
-
-```bash
-$ vi company_name_generator.rb
-```
-
-And change
-
-```css
-color: royalblue;
-```
-
-To:
-
-```css
-color: red;
-```
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Viewing our changes
-
-* Reload the application in our browser.
-
---
-
-* The color should have changed.
-
-  ![web application 2](images/webapp-in-red.png)
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Understanding volumes
-
-- Volumes are *not* copying or synchronizing files between the host and the container
-
-- Changes made in the host are immediately visible in the container (and vice versa)
-
-- When running on Linux:
-
-  - volumes and bind mounts correspond to directories on the host
-
-  - if Docker runs in a Linux VM, these directories are in the Linux VM
-
-- When running on Docker Desktop:
-
-  - volumes correspond to directories in a small Linux VM running Docker
-
-  - access to bind mounts is translated to host filesystem access
-    <br/>
-    (a bit like a network filesystem)
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-class: extra-details
-
-## Docker Desktop caveats
-
-- When running Docker natively on Linux, accessing a mount = native I/O
-
-- When running Docker Desktop, accessing a bind mount = file access translation
-
-- That file access translation has relatively good performance *in general*
-
-  (watch out, however, for that big `npm install` working on a bind mount!)
-
-- There are some corner cases when watching files (with mechanisms like inotify)
-
-- Features like "live reload" or programs like `entr` don't always behave properly
-
-  (due to e.g. file attribute caching, and other interesting details!)
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Trash your servers and burn your code
-
-*(This is the title of a
-[2013 blog post][immutable-deployments]
-by Chad Fowler, where he explains the concept of immutable infrastructure.)*
-
-[immutable-deployments]: https://web.archive.org/web/20160305073617/http://chadfowler.com/blog/2013/06/23/immutable-deployments/
-
---
-
-* Let's majorly mess up our container.
-
-  (Remove files or whatever.)
-
-* Now, how can we fix this?
-
---
-
-* Our old container (with the blue version of the code) is still running.
-
-* See on which port it is exposed:
-  ```bash
-  docker ps
-  ```
-
-* Point our browser to it to confirm that it still works fine.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Immutable infrastructure in a nutshell
-
-* Instead of *updating* a server, we deploy a new one.
-
-* This might be challenging with classical servers, but it's trivial with containers.
-
-* In fact, with Docker, the most logical workflow is to build a new image and run it.
-
-* If something goes wrong with the new image, we can always restart the old one.
-
-* We can even keep both versions running side by side.
-
-If this pattern sounds interesting, you might want to read about *blue/green deployment*
-and *canary deployments*.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Recap of the development workflow
-
-1. Write a Dockerfile to build an image containing our development environment.
-   <br/>
-   (Rails, Django, ... and all the dependencies for our app)
-
-2. Start a container from that image.
-   <br/>
-   Use the `-v` flag to mount our source code inside the container.
-
-3. Edit the source code outside the container, using familiar tools.
-   <br/>
-   (vim, emacs, textmate...)
-
-4. Test the application.
-   <br/>
-   (Some frameworks pick up changes automatically.
-   <br/>Others require you to Ctrl-C + restart after each modification.)
-
-5. Iterate and repeat steps 3 and 4 until satisfied.
-
-6. When done, commit+push source code changes.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-class: extra-details
-
-## Debugging inside the container
-
-Docker has a command called `docker exec`.
-
-It allows users to run a new process in a container which is already running.
-
-If sometimes you find yourself wishing you could SSH into a container: you can use `docker exec` instead.
-
-You can get a shell prompt inside an existing container this way, or run an arbitrary process for automation.
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-class: extra-details
-
-## `docker exec` example
-
-```bash
-$ # You can run ruby commands in the area the app is running and more!
-$ docker exec -it <yourContainerId> bash
-root@5ca27cf74c2e:/opt/namer# irb
-irb(main):001:0> [0, 1, 2, 3, 4].map {|x| x ** 2}.compact
-=> [0, 1, 4, 9, 16]
-irb(main):002:0> exit
-```
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-class: extra-details
-
-## Stopping the container
-
-Now that we're done let's stop our container.
-
-```bash
-$ docker stop <yourContainerID>
-```
-
-And remove it.
-
-```bash
-$ docker rm <yourContainerID>
-```
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-## Section summary
-
-We've learned how to:
-
-* Share code between container and host.
-
-* Set our working directory.
-
-* Use a simple local development workflow.
-
-???
-
-:EN:Developing with containers
-:EN:- “Containerize” a development environment
-
-:FR:Développer au jour le jour
-:FR:- « Containeriser » son environnement de développement
-
-.debug[[containers/Local_Development_Workflow.md](""/tree/main/slides/containers/Local_Development_Workflow.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/plastic-containers.JPG)]
-
----
-
-name: toc-working-with-volumes
-class: title
-
- Working with volumes
-
-.nav[
-[Previous part](#toc-local-development-workflow-with-docker)
-|
-[Back to table of contents](#toc-part-6)
-|
-[Next part](#toc-compose-for-development-stacks)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Working with volumes
-
-![volume](images/title-working-with-volumes.jpg)
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Objectives
-
-At the end of this section, you will be able to:
-
-* Create containers holding volumes.
-
-* Share volumes across containers.
-
-* Share a host directory with one or many containers.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Working with volumes
-
-Docker volumes can be used to achieve many things, including:
-
-* Bypassing the copy-on-write system to obtain native disk I/O performance.
-
-* Bypassing copy-on-write to leave some files out of `docker commit`.
-
-* Sharing a directory between multiple containers.
-
-* Sharing a directory between the host and a container.
-
-* Sharing a *single file* between the host and a container.
-
-* Using remote storage and custom storage with *volume drivers*.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Volumes are special directories in a container
-
-Volumes can be declared in two different ways:
-
-* Within a `Dockerfile`, with a `VOLUME` instruction.
-
-```dockerfile
-VOLUME /uploads
-```
-
-* On the command-line, with the `-v` flag for `docker run`.
-
-```bash
-$ docker run -d -v /uploads myapp
-```
-
-In both cases, `/uploads` (inside the container) will be a volume.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Volumes bypass the copy-on-write system
-
-Volumes act as passthroughs to the host filesystem.
-
-* The I/O performance on a volume is exactly the same as I/O performance
-  on the Docker host.
-
-* When you `docker commit`, the content of volumes is not brought into
-  the resulting image.
-
-* If a `RUN` instruction in a `Dockerfile` changes the content of a
-  volume, those changes are not recorded neither.
-
-* If a container is started with the `--read-only` flag, the volume
-  will still be writable (unless the volume is a read-only volume).
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Volumes can be shared across containers
-
-You can start a container with *exactly the same volumes* as another one.
-
-The new container will have the same volumes, in the same directories.
-
-They will contain exactly the same thing, and remain in sync.
-
-Under the hood, they are actually the same directories on the host anyway.
-
-This is done using the `--volumes-from` flag for `docker run`.
-
-We will see an example in the following slides.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Sharing app server logs with another container
-
-Let's start a Tomcat container:
-
-```bash
-$ docker run --name webapp -d -p 8080:8080 -v /usr/local/tomcat/logs tomcat
-```
-
-Now, start an `alpine` container accessing the same volume:
-
-```bash
-$ docker run --volumes-from webapp alpine sh -c "tail -f /usr/local/tomcat/logs/*"
-```
-
-Then, from another window, send requests to our Tomcat container:
-```bash
-$ curl localhost:8080
-```
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Volumes exist independently of containers
-
-If a container is stopped or removed, its volumes still exist and are available.
-
-Volumes can be listed and manipulated with `docker volume` subcommands:
-
-```bash
-$ docker volume ls
-DRIVER              VOLUME NAME
-local               5b0b65e4316da67c2d471086640e6005ca2264f3...
-local               pgdata-prod
-local               pgdata-dev
-local               13b59c9936d78d109d094693446e174e5480d973...
-```
-
-Some of those volume names were explicit (pgdata-prod, pgdata-dev).
-
-The others (the hex IDs) were generated automatically by Docker.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Naming volumes
-
-* Volumes can be created without a container, then used in multiple containers.
-
-Let's create a couple of volumes directly.
-
-```bash
-$ docker volume create webapps
-webapps
-```
-
-```bash
-$ docker volume create logs
-logs
-```
-
-Volumes are not anchored to a specific path.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Populating volumes
-
-* When an empty volume is mounted on a non-empty directory, the directory is copied to the volume.
-
-* This makes it easy to "promote" a normal directory to a volume.
-
-* Non-empty volumes are always mounted as-is.
-
-Let's populate the webapps volume with the webapps.dist directory from the Tomcat image.
-
-````bash
-$ docker run -v webapps:/usr/local/tomcat/webapps.dist tomcat true
-```
-
-Note: running `true` will cause the container to exit successfully once the `webapps.dist` directory has been copied to the `webapps` volume, instead of starting tomcat.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Using our named volumes
-
-* Volumes are used with the `-v` option.
-
-* When a host path does not contain a `/`, it is considered a volume name.
-
-Let's start a web server using the two previous volumes.
-
-```bash
-$ docker run -d -p 1234:8080 \
-         -v logs:/usr/local/tomcat/logs \
-         -v webapps:/usr/local/tomcat/webapps \
-         tomcat
-```
-
-Check that it's running correctly:
-
-```bash
-$ curl localhost:1234
-... (Tomcat tells us how happy it is to be up and running) ...
-```
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Using a volume in another container
-
-* We will make changes to the volume from another container.
-
-* In this example, we will run a text editor in the other container.
-
-  (But this could be an FTP server, a WebDAV server, a Git receiver...)
-
-Let's start another container using the `webapps` volume.
-
-```bash
-$ docker run -v webapps:/webapps -w /webapps -ti alpine vi ROOT/index.jsp
-```
-
-Vandalize the page, save, exit.
-
-Then run `curl localhost:1234` again to see your changes.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Using custom "bind-mounts"
-
-In some cases, you want a specific directory on the host to be mapped
-inside the container:
-
-* You want to manage storage and snapshots yourself.
-
-    (With LVM, or a SAN, or ZFS, or anything else!)
-
-* You have a separate disk with better performance (SSD) or resiliency (EBS)
-  than the system disk, and you want to put important data on that disk.
-
-* You want to share your source directory between your host (where the
-  source gets edited) and the container (where it is compiled or executed).
-
-Wait, we already met the last use-case in our example development workflow!
-Nice.
-
-```bash
-$ docker run -d -v /path/on/the/host:/path/in/container image ...
-```
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Migrating data with `--volumes-from`
-
-The `--volumes-from` option tells Docker to re-use all the volumes
-of an existing container.
-
-* Scenario: migrating from Redis 2.8 to Redis 3.0.
-
-* We have a container (`myredis`) running Redis 2.8.
-
-* Stop the `myredis` container.
-
-* Start a new container, using the Redis 3.0 image, and the `--volumes-from` option.
-
-* The new container will inherit the data of the old one.
-
-* Newer containers can use `--volumes-from` too.
-
-* Doesn't work across servers, so not usable in clusters (Swarm, Kubernetes).
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Data migration in practice
-
-Let's create a Redis container.
-
-```bash
-$ docker run -d --name redis28 redis:2.8
-```
-
-Connect to the Redis container and set some data.
-
-```bash
-$ docker run -ti --link redis28:redis busybox telnet redis 6379
-```
-
-Issue the following commands:
-
-```bash
-SET counter 42
-INFO server
-SAVE
-QUIT
-```
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Upgrading Redis
-
-Stop the Redis container.
-
-```bash
-$ docker stop redis28
-```
-
-Start the new Redis container.
-
-```bash
-$ docker run -d --name redis30 --volumes-from redis28 redis:3.0
-```
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Testing the new Redis
-
-Connect to the Redis container and see our data.
-
-```bash
-docker run -ti --link redis30:redis busybox telnet redis 6379
-```
-
-Issue a few commands.
-
-```bash
-GET counter
-INFO server
-QUIT
-```
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Volumes lifecycle
-
-* When you remove a container, its volumes are kept around.
-
-* You can list them with `docker volume ls`.
-
-* You can access them by creating a container with `docker run -v`.
-
-* You can remove them with `docker volume rm` or `docker system prune`.
-
-Ultimately, _you_ are the one responsible for logging,
-monitoring, and backup of your volumes.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Checking volumes defined by an image
-
-Wondering if an image has volumes? Just use `docker inspect`:
-
-```bash
-$ # docker inspect training/datavol
-[{
-  "config": {
-    . . .
-    "Volumes": {
-        "/var/webapp": {}
-    },
-    . . .
-}]
-```
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: extra-details
-
-## Checking volumes used by a container
-
-To look which paths are actually volumes, and to what they are bound,
-use `docker inspect` (again):
-
-```bash
-$ docker inspect <yourContainerID>
-[{
-  "ID": "<yourContainerID>",
-. . .
-  "Volumes": {
-     "/var/webapp": "/var/lib/docker/vfs/dir/f4280c5b6207ed531efd4cc673ff620cef2a7980f747dbbcca001db61de04468"
-  },
-  "VolumesRW": {
-     "/var/webapp": true
-  },
-}]
-```
-
-* We can see that our volume is present on the file system of the Docker host.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Sharing a single file
-
-The same `-v` flag can be used to share a single file (instead of a directory).
-
-One of the most interesting examples is to share the Docker control socket.
-
-```bash
-$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker sh
-```
-
-From that container, you can now run `docker` commands communicating with
-the Docker Engine running on the host. Try `docker ps`!
-
-.warning[Since that container has access to the Docker socket, it
-has root-like access to the host.]
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Volume plugins
-
-You can install plugins to manage volumes backed by particular storage systems,
-or providing extra features. For instance:
-
-* [REX-Ray](https://rexray.io/) - create and manage volumes backed by an enterprise storage system (e.g.
-  SAN or NAS), or by cloud block stores (e.g. EBS, EFS).
-
-* [Portworx](https://portworx.com/) - provides distributed block store for containers.
-
-* [Gluster](https://www.gluster.org/) - open source software-defined distributed storage that can scale
-  to several petabytes. It provides interfaces for object, block and file storage.
-
-* and much more at the [Docker Store](https://store.docker.com/search?category=volume&q=&type=plugin)!
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Volumes vs. Mounts
-
-* Since Docker 17.06, a new options is available: `--mount`.
-
-* It offers a new, richer syntax to manipulate data in containers.
-
-* It makes an explicit difference between:
-
-  - volumes (identified with a unique name, managed by a storage plugin),
-
-  - bind mounts (identified with a host path, not managed).
-
-* The former `-v` / `--volume` option is still usable.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## `--mount` syntax
-
-Binding a host path to a container path:
-
-```bash
-$ docker run \
-  --mount type=bind,source=/path/on/host,target=/path/in/container alpine
-```
-
-Mounting a volume to a container path:
-
-```bash
-$ docker run \
-  --mount source=myvolume,target=/path/in/container alpine
-```
-
-Mounting a tmpfs (in-memory, for temporary files):
-
-```bash
-$ docker run \
-  --mount type=tmpfs,destination=/path/in/container,tmpfs-size=1000000 alpine
-```
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-## Section summary
-
-We've learned how to:
-
-* Create and manage volumes.
-
-* Share volumes across containers.
-
-* Share a host directory with one or many containers.
-
-.debug[[containers/Working_With_Volumes.md](""/tree/main/slides/containers/Working_With_Volumes.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-1.jpg)]
-
----
-
-name: toc-compose-for-development-stacks
-class: title
-
- Compose for development stacks
-
-.nav[
-[Previous part](#toc-working-with-volumes)
-|
-[Back to table of contents](#toc-part-6)
-|
-[Next part](#toc-exercise--writing-a-compose-file)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Compose for development stacks
-
-Dockerfile = great to build *one* container image.
-
-What if we have multiple containers?
-
-What if some of them require particular `docker run` parameters?
-
-How do we connect them all together?
-
-... Compose solves these use-cases (and a few more).
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Life before Compose
-
-Before we had Compose, we would typically write custom scripts to:
-
-- build container images,
-
-- run containers using these images,
-
-- connect the containers together,
-
-- rebuild, restart, update these images and containers.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Life with Compose
-
-Compose enables a simple, powerful onboarding workflow:
-
-1. Checkout our code.
-
-2. Run `docker-compose up`.
-
-3. Our app is up and running!
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-class: pic
-
-![composeup](images/composeup.gif)
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Life after Compose
-
-(Or: when do we need something else?)
-
-- Compose is *not* an orchestrator
-
-- It isn't designed to need to run containers on multiple nodes
-
-  (it can, however, work with Docker Swarm Mode)
-
-- Compose isn't ideal if we want to run containers on Kubernetes
-
-  - it uses different concepts (Compose services ≠ Kubernetes services)
-
-  - it needs a Docker Engine (although containerd support might be coming)
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## First rodeo with Compose
-
-1. Write Dockerfiles
-
-2. Describe our stack of containers in a YAML file called `docker-compose.yml`
-
-3. `docker-compose up` (or `docker-compose up -d` to run in the background)
-
-4. Compose pulls and builds the required images, and starts the containers
-
-5. Compose shows the combined logs of all the containers
-
-   (if running in the background, use `docker-compose logs`)
-
-6. Hit Ctrl-C to stop the whole stack
-
-   (if running in the background, use `docker-compose stop`)
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Iterating
-
-After making changes to our source code, we can:
-
-1. `docker-compose build` to rebuild container images
-
-2. `docker-compose up` to restart the stack with the new images
-
-We can also combine both with `docker-compose up --build`
-
-Compose will be smart, and only recreate the containers that have changed.
-
-When working with interpreted languages:
-
-- don't rebuild each time
-
-- leverage a `volumes` section instead
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Launching Our First Stack with Compose
-
-First step: clone the source code for the app we will be working on.
-
-```bash
-git clone https://github.com/jpetazzo/trainingwheels
-cd trainingwheels
-```
-
-Second step: start the app.
-
-```bash
-docker-compose up
-```
-
-Watch Compose build and run the app.
-
-That Compose stack exposes a web server on port 8000; try connecting to it.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Launching Our First Stack with Compose
-
-We should see a web page like this:
-
-![composeapp](images/composeapp.png)
-
-Each time we reload, the counter should increase.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Stopping the app
-
-When we hit Ctrl-C, Compose tries to gracefully terminate all of the containers.
-
-After ten seconds (or if we press `^C` again) it will forcibly kill them.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## The `docker-compose.yml` file
-
-Here is the file used in the demo:
-
-.small[
-```yaml
-version: "3"
-
-services:
-  www:
-    build: www
-    ports:
-      - ${PORT-8000}:5000
-    user: nobody
-    environment:
-      DEBUG: 1
-    command: python counter.py
-    volumes:
-      - ./www:/src
-
-  redis:
-    image: redis
-```
-]
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Compose file structure
-
-A Compose file has multiple sections:
-
-* `version` is mandatory. (Typically use "3".)
-
-* `services` is mandatory. Each service corresponds to a container.
-
-* `networks` is optional and indicates to which networks containers should be connected.
-  <br/>(By default, containers will be connected on a private, per-compose-file network.)
-
-* `volumes` is optional and can define volumes to be used and/or shared by the containers.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Compose file versions
-
-* Version 1 is legacy and shouldn't be used.
-
-  (If you see a Compose file without `version` and `services`, it's a legacy v1 file.)
-
-* Version 2 added support for networks and volumes.
-
-* Version 3 added support for deployment options (scaling, rolling updates, etc).
-
-* Typically use `version: "3"`.
-
-The [Docker documentation](https://docs.docker.com/compose/compose-file/)
-has excellent information about the Compose file format if you need to know more about versions.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Containers in `docker-compose.yml`
-
-Each service in the YAML file must contain either `build`, or `image`.
-
-* `build` indicates a path containing a Dockerfile.
-
-* `image` indicates an image name (local, or on a registry).
-
-* If both are specified, an image will be built from the `build` directory and named `image`.
-
-The other parameters are optional.
-
-They encode the parameters that you would typically add to `docker run`.
-
-Sometimes they have several minor improvements.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Container parameters
-
-* `command` indicates what to run (like `CMD` in a Dockerfile).
-
-* `ports` translates to one (or multiple) `-p` options to map ports.
-  <br/>You can specify local ports (i.e. `x:y` to expose public port `x`).
-
-* `volumes` translates to one (or multiple) `-v` options.
-  <br/>You can use relative paths here.
-
-For the full list, check: https://docs.docker.com/compose/compose-file/
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Environment variables
-
-- We can use environment variables in Compose files
-
-  (like `$THIS` or `${THAT}`)
-
-- We can provide default values, e.g. `${PORT-8000}`
-
-- Compose will also automatically load the environment file `.env`
-
-  (it should contain `VAR=value`, one per line)
-
-- This is a great way to customize build and run parameters
-
-  (base image versions to use, build and run secrets, port numbers...)
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Configuring a Compose stack
-
-- Follow [12-factor app configuration principles][12factorconfig]
-
-  (configure the app through environment variables)
-
-- Provide (in the repo) a default environment file suitable for development
-
-  (no secret or sensitive value)
-
-- Copy the default environment file to `.env` and tweak it
-
-  (or: provide a script to generate `.env` from a template)
-
-[12factorconfig]: https://12factor.net/config
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Running multiple copies of a stack
-
-- Copy the stack in two different directories, e.g. `front` and `frontcopy`
-
-- Compose prefixes images and containers with the directory name:
-
-  `front_www`, `front_www_1`, `front_db_1`
-
-  `frontcopy_www`, `frontcopy_www_1`, `frontcopy_db_1`
-
-- Alternatively, use `docker-compose -p frontcopy` 
-
-  (to set the `--project-name` of a stack, which default to the dir name)
-
-- Each copy is isolated from the others (runs on a different network)
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Checking stack status
-
-We have `ps`, `docker ps`, and similarly, `docker-compose ps`:
-
-```bash
-$ docker-compose ps
-Name                      Command             State           Ports          
-----------------------------------------------------------------------------
-trainingwheels_redis_1   /entrypoint.sh red   Up      6379/tcp               
-trainingwheels_www_1     python counter.py    Up      0.0.0.0:8000->5000/tcp 
-```
-
-Shows the status of all the containers of our stack.
-
-Doesn't show the other containers.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Cleaning up (1)
-
-If you have started your application in the background with Compose and
-want to stop it easily, you can use the `kill` command:
-
-```bash
-$ docker-compose kill
-```
-
-Likewise, `docker-compose rm` will let you remove containers (after confirmation):
-
-```bash
-$ docker-compose rm
-Going to remove trainingwheels_redis_1, trainingwheels_www_1
-Are you sure? [yN] y
-Removing trainingwheels_redis_1...
-Removing trainingwheels_www_1...
-```
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Cleaning up (2)
-
-Alternatively, `docker-compose down` will stop and remove containers.
-
-It will also remove other resources, like networks that were created for the application.
-
-```bash
-$ docker-compose down
-Stopping trainingwheels_www_1 ... done
-Stopping trainingwheels_redis_1 ... done
-Removing trainingwheels_www_1 ... done
-Removing trainingwheels_redis_1 ... done
-```
-
-Use `docker-compose down -v` to remove everything including volumes.
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Special handling of volumes
-
-- When an image gets updated, Compose automatically creates a new container
-
-- The data in the old container is lost...
-
-- ...Except if the container is using a *volume*
-
-- Compose will then re-attach that volume to the new container
-
-  (and data is then retained across database upgrades)
-
-- All good database images use volumes
-
-  (e.g. all official images)
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Gotchas with volumes
-
-- Unfortunately, Docker volumes don't have labels or metadata
-
-- Compose tracks volumes thanks to their associated container
-
-- If the container is deleted, the volume gets orphaned
-
-- Example: `docker-compose down && docker-compose up`
-
-  - the old volume still exists, detached from its container
-
-  - a new volume gets created
-
-- `docker-compose down -v`/`--volumes` deletes volumes
-
-  (but **not** `docker-compose down && docker-compose down -v`!)
- 
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Managing volumes explicitly
-
-Option 1: *named volumes*
-
-```yaml
-services:
-  app:
-    volumes:
-    - data:/some/path
-volumes:
-  data:
-```
-
-- Volume will be named `<project>_data`
-
-- It won't be orphaned with `docker-compose down`
-
-- It will correctly be removed with `docker-compose down -v`
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Managing volumes explicitly
-
-Option 2: *relative paths*
-
-```yaml
-services:
-  app:
-    volumes:
-    - ./data:/some/path
-```
-
-- Makes it easy to colocate the app and its data
-
-  (for migration, backups, disk usage accounting...)
-
-- Won't be removed by `docker-compose down -v`
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Managing complex stacks
-
-- Compose provides multiple features to manage complex stacks
-
-  (with many containers)
-
-- `-f`/`--file`/`$COMPOSE_FILE` can be a list of Compose files
-
-  (separated by `:` and merged together)
-
-- Services can be assigned to one or more *profiles*
-
-- `--profile`/`$COMPOSE_PROFILE` can be a list of comma-separated profiles
-
-  (see [Using service profiles][profiles] in the Compose documentation)
-
-- These variables can be set in `.env`
-
-[profiles]: https://docs.docker.com/compose/profiles/
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-## Dependencies
-
-- A service can have a `depends_on` section
-
-  (listing one or more other services)
-
-- This is used when bringing up individual services
-
-  (e.g. `docker-compose up blah` or `docker-compose run foo`)
-
-⚠️ It doesn't make a service "wait" for another one to be up!
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-class: extra-details
-
-## A bit of history and trivia
-
-- Compose was initially named "Fig"
-
-- Compose is one of the only components of Docker written in Python
-
-  (almost everything else is in Go)
-
-- In 2020, Docker introduced "Compose CLI":
-
-  - `docker compose` command to deploy Compose stacks to some clouds
-
-  - progressively getting feature parity with `docker-compose`
-
-  - also provides numerous improvements (e.g. leverages BuildKit by default)
-
-???
-
-:EN:- Using compose to describe an environment
-:EN:- Connecting services together with a *Compose file*
-
-:FR:- Utiliser Compose pour décrire son environnement
-:FR:- Écrire un *Compose file* pour connecter les services entre eux
-
-.debug[[containers/Compose_For_Dev_Stacks.md](""/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-2.jpg)]
-
----
-
-name: toc-exercise--writing-a-compose-file
-class: title
-
- Exercise — writing a Compose file
-
-.nav[
-[Previous part](#toc-compose-for-development-stacks)
-|
-[Back to table of contents](#toc-part-6)
-|
-[Next part](#toc-installing-docker)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Exercise — writing a Compose file
-
-Let's write a Compose file for the wordsmith app!
-
-The code is at: https://github.com/jpetazzo/wordsmith
-
-.debug[[containers/Exercise_Composefile.md](""/tree/main/slides/containers/Exercise_Composefile.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/two-containers-on-a-truck.jpg)]
-
----
-
-name: toc-installing-docker
-class: title
-
- Installing Docker
-
-.nav[
-[Previous part](#toc-exercise--writing-a-compose-file)
-|
-[Back to table of contents](#toc-part-7)
-|
-[Next part](#toc-docker-engine-and-other-container-engines)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Installing Docker
-
-![install](images/title-installing-docker.jpg)
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-## Objectives
-
-At the end of this lesson, you will know:
-
-* How to install Docker.
-
-* When to use `sudo` when running Docker commands.
-
-*Note:* if you were provided with a training VM for a hands-on
-tutorial, you can skip this chapter, since that VM already
-has Docker installed, and Docker has already been setup to run
-without `sudo`.
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-## Installing Docker
-
-There are many ways to install Docker.
-
-We can arbitrarily distinguish:
-
-* Installing Docker on an existing Linux machine (physical or VM)
-
-* Installing Docker on macOS or Windows
-
-* Installing Docker on a fleet of cloud VMs
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-## Installing Docker on Linux
-
-* The recommended method is to install the packages supplied by Docker Inc :
-
-  - add Docker Inc.'s package repositories to your system configuration
-
-  - install the Docker Engine
-
-* Detailed installation instructions (distro by distro) are available on:
-
-  https://docs.docker.com/engine/installation/
-
-* You can also install from binaries (if your distro is not supported):
-
-  https://docs.docker.com/engine/installation/linux/docker-ce/binaries/
-
-* To quickly setup a dev environment, Docker provides a convenience install script:
-
-  ```bash
-  curl -fsSL get.docker.com | sh
-  ```
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-class: extra-details
-
-## Docker Inc. packages vs distribution packages
-
-* Docker Inc. releases new versions monthly (edge) and quarterly (stable)
-
-* Releases are immediately available on Docker Inc.'s package repositories
-
-* Linux distros don't always update to the latest Docker version
-
-  (Sometimes, updating would break their guidelines for major/minor upgrades)
-
-* Sometimes, some distros have carried packages with custom patches
-
-* Sometimes, these patches added critical security bugs ☹
-
-* Installing through Docker Inc.'s repositories is a bit of extra work …
-
-  … but it is generally worth it!
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-## Installing Docker on macOS and Windows
-
-* On macOS, the recommended method is to use Docker Desktop for Mac:
-
-  https://docs.docker.com/docker-for-mac/install/
-
-* On Windows 10 Pro, Enterprise, and Education, you can use Docker Desktop for Windows:
-
-  https://docs.docker.com/docker-for-windows/install/
-
-* On older versions of Windows, you can use the Docker Toolbox:
-
-  https://docs.docker.com/toolbox/toolbox_install_windows/
-
-* On Windows Server 2016, you can also install the native engine:
-
-  https://docs.docker.com/install/windows/docker-ee/
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-## Docker Desktop
-
-* Special Docker edition available for Mac and Windows
-
-* Integrates well with the host OS:
-
-  * installed like normal user applications on the host
-
-  * provides user-friendly GUI to edit Docker configuration and settings
-
-* Only support running one Docker VM at a time ...
-
-  ... but we can use `docker-machine`, the Docker Toolbox, VirtualBox, etc. to get a cluster.
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-class: extra-details
-
-## Docker Desktop internals
-
-* Leverages the host OS virtualization subsystem
-
-  (e.g. the [Hypervisor API](https://developer.apple.com/documentation/hypervisor) on macOS)
-
-* Under the hood, runs a tiny VM
-
-  (transparent to our daily use)
-
-* Accesses network resources like normal applications
-
-  (and therefore, plays better with enterprise VPNs and firewalls)
-
-* Supports filesystem sharing through volumes
-
-  (we'll talk about this later)
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-## Running Docker on macOS and Windows
-
-When you execute `docker version` from the terminal:
-
-* the CLI connects to the Docker Engine over a standard socket,
-* the Docker Engine is, in fact, running in a VM,
-* ... but the CLI doesn't know or care about that,
-* the CLI sends a request using the REST API,
-* the Docker Engine in the VM processes the request,
-* the CLI gets the response and displays it to you.
-
-All communication with the Docker Engine happens over the API.
-
-This will also allow to use remote Engines exactly as if they were local.
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-## Important PSA about security
-
-* If you have access to the Docker control socket, you can take over the machine
-
-  (Because you can run containers that will access the machine's resources)
-
-* Therefore, on Linux machines, the `docker` user is equivalent to `root`
-
-* You should restrict access to it like you would protect `root`
-
-* By default, the Docker control socket belongs to the `docker` group
-
-* You can add trusted users to the `docker` group
-
-* Otherwise, you will have to prefix every `docker` command with `sudo`, e.g.:
-
-  ```bash
-  sudo docker version
-  ```
-
-.debug[[containers/Installing_Docker.md](""/tree/main/slides/containers/Installing_Docker.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/wall-of-containers.jpeg)]
-
----
-
-name: toc-docker-engine-and-other-container-engines
-class: title
-
- Docker Engine and other container engines
-
-.nav[
-[Previous part](#toc-installing-docker)
-|
-[Back to table of contents](#toc-part-7)
-|
-[Next part](#toc-init-systems-and-pid-)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Docker Engine and other container engines
-
-* We are going to cover the architecture of the Docker Engine.
-
-* We will also present other container engines.
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-class: pic
-
-## Docker Engine external architecture
-
-![](images/docker-engine-architecture.svg)
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## Docker Engine external architecture
-
-* The Engine is a daemon (service running in the background).
-
-* All interaction is done through a REST API exposed over a socket.
-
-* On Linux, the default socket is a UNIX socket: `/var/run/docker.sock`.
-
-* We can also use a TCP socket, with optional mutual TLS authentication.
-
-* The `docker` CLI communicates with the Engine over the socket.
-
-Note: strictly speaking, the Docker API is not fully REST.
-
-Some operations (e.g. dealing with interactive containers
-and log streaming) don't fit the REST model.
- 
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-class: pic
-
-## Docker Engine internal architecture
-
-![](images/dockerd-and-containerd.png)
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## Docker Engine internal architecture
-
-* Up to Docker 1.10: the Docker Engine is one single monolithic binary.
-
-* Starting with Docker 1.11, the Engine is split into multiple parts:
-
-  - `dockerd` (REST API, auth, networking, storage)
-
-  - `containerd` (container lifecycle, controlled over a gRPC API)
-
-  - `containerd-shim` (per-container; does almost nothing but allows to restart the Engine without restarting the containers)
-
-  - `runc` (per-container; does the actual heavy lifting to start the container)
-
-* Some features (like image and snapshot management) are progressively being pushed from `dockerd` to `containerd`.
-
-For more details, check [this short presentation by Phil Estes](https://www.slideshare.net/PhilEstes/diving-through-the-layers-investigating-runc-containerd-and-the-docker-engine-architecture).
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## Other container engines
-
-The following list is not exhaustive.
-
-Furthermore, we limited the scope to Linux containers.
-
-We can also find containers (or things that look like containers) on other platforms
-like Windows, macOS, Solaris, FreeBSD ...
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## LXC
-
-* The venerable ancestor (first released in 2008).
-
-* Docker initially relied on it to execute containers.
-
-* No daemon; no central API.
-
-* Each container is managed by a `lxc-start` process.
-
-* Each `lxc-start` process exposes a custom API over a local UNIX socket, allowing to interact with the container.
-
-* No notion of image (container filesystems have to be managed manually).
-
-* Networking has to be set up manually.
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## LXD
-
-* Re-uses LXC code (through liblxc).
-
-* Builds on top of LXC to offer a more modern experience.
-
-* Daemon exposing a REST API.
-
-* Can manage images, snapshots, migrations, networking, storage.
-
-* "offers a user experience similar to virtual machines but using Linux containers instead."
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## CRI-O
-
-* Designed to be used with Kubernetes as a simple, basic runtime.
-
-* Compares to `containerd`.
-
-* Daemon exposing a gRPC interface.
-
-* Controlled using the CRI API (Container Runtime Interface defined by Kubernetes).
-
-* Needs an underlying OCI runtime (e.g. runc).
-
-* Handles storage, images, networking (through CNI plugins).
-
-We're not aware of anyone using it directly (i.e. outside of Kubernetes).
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## systemd
-
-* "init" system (PID 1) in most modern Linux distributions.
-
-* Offers tools like `systemd-nspawn` and `machinectl` to manage containers.
-
-* `systemd-nspawn` is "In many ways it is similar to chroot(1), but more powerful".
-
-* `machinectl` can interact with VMs and containers managed by systemd.
-
-* Exposes a DBUS API.
-
-* Basic image support (tar archives and raw disk images).
-
-* Network has to be set up manually.
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## Kata containers
-
-* OCI-compliant runtime.
-
-* Fusion of two projects: Intel Clear Containers and Hyper runV.
-
-* Run each container in a lightweight virtual machine.
-
-* Requires running on bare metal *or* with nested virtualization.
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## gVisor
-
-* OCI-compliant runtime.
-
-* Implements a subset of the Linux kernel system calls.
-
-* Written in go, uses a smaller subset of system calls.
-
-* Can be heavily sandboxed.
-
-* Can run in two modes:
-
-  * KVM (requires bare metal or nested virtualization),
-
-  * ptrace (no requirement, but slower).
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-## Overall ...
-
-* The Docker Engine is very developer-centric:
-
-  - easy to install
-
-  - easy to use
-
-  - no manual setup
-
-  - first-class image build and transfer
-
-* As a result, it is a fantastic tool in development environments.
-
-* On servers:
-
-  - Docker is a good default choice
-
-  - If you use Kubernetes, the engine doesn't matter
-
-.debug[[containers/Container_Engines.md](""/tree/main/slides/containers/Container_Engines.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/catene-de-conteneurs.jpg)]
-
----
-
-name: toc-init-systems-and-pid-
-class: title
-
- Init systems and PID 1
-
-.nav[
-[Previous part](#toc-docker-engine-and-other-container-engines)
-|
-[Back to table of contents](#toc-part-7)
-|
-[Next part](#toc-advanced-dockerfile-syntax)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Init systems and PID 1
-
-In this chapter, we will consider:
-
-- the role of PID 1 in the world of Docker,
-
-- how to avoid some common pitfalls due to the misuse of init systems.
-
-.debug[[containers/Init_Systems.md](""/tree/main/slides/containers/Init_Systems.md)]
----
-
-## What's an init system?
-
-- On UNIX, the "init system" (or "init" in short) is PID 1.
-
-- It is the first process started by the kernel when the system starts.
-
-- It has multiple responsibilities:
-
-  - start every other process on the machine,
-
-  - reap orphaned zombie processes.
-
-.debug[[containers/Init_Systems.md](""/tree/main/slides/containers/Init_Systems.md)]
----
-
-class: extra-details
-
-## Orphaned zombie processes ?!?
-
-- When a process exits (or "dies"), it becomes a "zombie".
-
-  (Zombie processes show up in `ps` or `top` with the status code `Z`.)
-
-- Its parent process must *reap* the zombie process.
-
-  (This is done by calling `waitpid()` to retrieve the process' exit status.)
-
-- When a process exits, if it has child processes, these processes are "orphaned."
-
-- They are then re-parented to PID 1, init.
-
-- Init therefore needs to take care of these orphaned processes when they exit.
-
-.debug[[containers/Init_Systems.md](""/tree/main/slides/containers/Init_Systems.md)]
----
-
-## Don't use init systems in containers
-
-- It's often tempting to use an init system or a process manager.
-
-  (Examples: *systemd*, *supervisord*...)
-
-- Our containers are then called "system containers".
-
-  (By contrast with "application containers".)
-
-- "System containers" are similar to lightweight virtual machines.
-
-- They have multiple downsides:
-
-  - when starting multiple processes, their logs get mixed on stdout,
-
-  - if the application process dies, the container engine doesn't see it.
-
-- Overall, they make it harder to operate troubleshoot containerized apps.
-
-.debug[[containers/Init_Systems.md](""/tree/main/slides/containers/Init_Systems.md)]
----
-
-## Exceptions and workarounds
-
-- Sometimes, it's convenient to run a real init system like *systemd*.
-
-  (Example: a CI system whose goal is precisely to test an init script or unit file.)
-
-- If we need to run multiple processes: can we use multiple containers?
-
-  (Example: [this Compose file](https://github.com/jpetazzo/container.training/blob/master/compose/simple-k8s-control-plane/docker-compose.yaml) runs multiple processes together.)
-
-- When deploying with Kubernetes:
-
-  - a container belong to a pod,
-
-  - a pod can have multiple containers.
-
-.debug[[containers/Init_Systems.md](""/tree/main/slides/containers/Init_Systems.md)]
----
-
-## What about these zombie processes?
-
-- Our application runs as PID 1 in the container.
-
-- Our application may or may not be designed to reap zombie processes.
-
-- If our application uses subprocesses and doesn't reap them ...
-
-  ... this can lead to PID exhaustion!
-
-  (Or, more realistically, to a confusing herd of zombie processes.)
-
-- How can we solve this?
-
-.debug[[containers/Init_Systems.md](""/tree/main/slides/containers/Init_Systems.md)]
----
-
-## Tini to the rescue
-
-- Docker can automatically provide a minimal `init` process.
-
-- This is enabled with `docker run --init ...`
-
-- It uses a small init system ([tini](https://github.com/krallin/tini)) as PID 1:
-
-  - it reaps zombies,
-
-  - it forwards signals,
-
-  - it exits when the child exits.
-
-- It is totally transparent to our application.
-
-- We should use it if our application creates subprocess but doesn't reap them.
-
-.debug[[containers/Init_Systems.md](""/tree/main/slides/containers/Init_Systems.md)]
----
-
-class: extra-details
-
-## What about Kubernetes?
-
-- Kubernetes does not expose that `--init` option.
-
-- However, we can achieve the same result with [Process Namespace Sharing](https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/).
-
-- When Process Namespace Sharing is enabled, PID 1 will be `pause`.
-
-- That `pause` process takes care of reaping zombies.
-
-- Process Namespace Sharing is available since Kubernetes 1.16.
-
-- If you're using an older version of Kubernetes ...
-
-  ... you might have to add `tini` explicitly to your Docker image.
-
-.debug[[containers/Init_Systems.md](""/tree/main/slides/containers/Init_Systems.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]
-
----
-
-name: toc-advanced-dockerfile-syntax
-class: title
-
- Advanced Dockerfile Syntax
-
-.nav[
-[Previous part](#toc-init-systems-and-pid-)
-|
-[Back to table of contents](#toc-part-7)
-|
-[Next part](#toc-buildkit)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: title
-
-# Advanced Dockerfile Syntax
-
-![construction](images/title-advanced-dockerfiles.jpg)
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## Objectives
-
-We have seen simple Dockerfiles to illustrate how Docker build
-container images.
-
-In this section, we will give a recap of the Dockerfile syntax,
-and introduce advanced Dockerfile commands that we might
-come across sometimes; or that we might want to use in some
-specific scenarios.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## `Dockerfile` usage summary
-
-* `Dockerfile` instructions are executed in order.
-
-* Each instruction creates a new layer in the image.
-
-* Docker maintains a cache with the layers of previous builds.
-
-* When there are no changes in the instructions and files making a layer,
-  the builder re-uses the cached layer, without executing the instruction for that layer.
-
-* The `FROM` instruction MUST be the first non-comment instruction.
-
-* Lines starting with `#` are treated as comments.
-
-* Some instructions (like `CMD` or `ENTRYPOINT`) update a piece of metadata.
-
-  (As a result, each call to these instructions makes the previous one useless.)
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## The `RUN` instruction
-
-The `RUN` instruction can be specified in two ways.
-
-With shell wrapping, which runs the specified command inside a shell,
-with `/bin/sh -c`:
-
-```dockerfile
-RUN apt-get update
-```
-
-Or using the `exec` method, which avoids shell string expansion, and
-allows execution in images that don't have `/bin/sh`:
-
-```dockerfile
-RUN [ "apt-get", "update" ]
-```
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## More about the `RUN` instruction
-
-`RUN` will do the following:
-
-* Execute a command.
-* Record changes made to the filesystem.
-* Work great to install libraries, packages, and various files.
-
-`RUN` will NOT do the following:
-
-* Record state of *processes*.
-* Automatically start daemons.
-
-If you want to start something automatically when the container runs,
-you should use `CMD` and/or `ENTRYPOINT`.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## Collapsing layers
-
-It is possible to execute multiple commands in a single step:
-
-```dockerfile
-RUN apt-get update && apt-get install -y wget && apt-get clean
-```
-
-It is also possible to break a command onto multiple lines:
-
-```dockerfile
-RUN apt-get update \
- && apt-get install -y wget \
- && apt-get clean
-```
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## The `EXPOSE` instruction
-
-The `EXPOSE` instruction tells Docker what ports are to be published
-in this image.
-
-```dockerfile
-EXPOSE 8080
-EXPOSE 80 443
-EXPOSE 53/tcp 53/udp
-```
-
-* All ports are private by default.
-
-* Declaring a port with `EXPOSE` is not enough to make it public.
-
-* The `Dockerfile` doesn't control on which port a service gets exposed.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## Exposing ports
-
-* When you `docker run -p <port> ...`, that port becomes public.
-
-    (Even if it was not declared with `EXPOSE`.)
-
-* When you `docker run -P ...` (without port number), all ports
-  declared with `EXPOSE` become public.
-
-A *public port* is reachable from other containers and from outside the host.
-
-A *private port* is not reachable from outside.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## The `COPY` instruction
-
-The `COPY` instruction adds files and content from your host into the
-image.
-
-```dockerfile
-COPY . /src
-```
-
-This will add the contents of the *build context* (the directory
-passed as an argument to `docker build`) to the directory `/src`
-in the container.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## Build context isolation
-
-Note: you can only reference files and directories *inside* the
-build context. Absolute paths are taken as being anchored to
-the build context, so the two following lines are equivalent:
-
-```dockerfile
-COPY . /src
-COPY / /src
-```
-
-Attempts to use `..` to get out of the build context will be
-detected and blocked with Docker, and the build will fail.
-
-Otherwise, a `Dockerfile` could succeed on host A, but fail on host B.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## `ADD`
-
-`ADD` works almost like `COPY`, but has a few extra features.
-
-`ADD` can get remote files:
-
-```dockerfile
-ADD http://www.example.com/webapp.jar /opt/
-```
-
-This would download the `webapp.jar` file and place it in the `/opt`
-directory.
-
-`ADD` will automatically unpack zip files and tar archives:
-
-```dockerfile
-ADD ./assets.zip /var/www/htdocs/assets/
-```
-
-This would unpack `assets.zip` into `/var/www/htdocs/assets`.
-
-*However,* `ADD` will not automatically unpack remote archives.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## `ADD`, `COPY`, and the build cache
-
-* Before creating a new layer, Docker checks its build cache.
-
-* For most Dockerfile instructions, Docker only looks at the
-  `Dockerfile` content to do the cache lookup.
-
-* For `ADD` and `COPY` instructions, Docker also checks if the files
-  to be added to the container have been changed.
-
-* `ADD` always needs to download the remote file before
-  it can check if it has been changed.
-
-  (It cannot use,
-  e.g., ETags or If-Modified-Since headers.)
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## `VOLUME`
-
-The `VOLUME` instruction tells Docker that a specific directory
-should be a *volume*.
-
-```dockerfile
-VOLUME /var/lib/mysql
-```
-
-Filesystem access in volumes bypasses the copy-on-write layer,
-offering native performance to I/O done in those directories.
-
-Volumes can be attached to multiple containers, allowing to
-"port" data over from a container to another, e.g. to
-upgrade a database to a newer version.
-
-It is possible to start a container in "read-only" mode.
-The container filesystem will be made read-only, but volumes
-can still have read/write access if necessary.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## The `WORKDIR` instruction
-
-The `WORKDIR` instruction sets the working directory for subsequent
-instructions.
-
-It also affects `CMD` and `ENTRYPOINT`, since it sets the working
-directory used when starting the container.
-   
-```dockerfile
-WORKDIR /src
-```
-
-You can specify `WORKDIR` again to change the working directory for
-further operations.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## The `ENV` instruction
-
-The `ENV` instruction specifies environment variables that should be
-set in any container launched from the image.
-
-```dockerfile
-ENV WEBAPP_PORT 8080
-```
-
-This will result in an environment variable being created in any
-containers created from this image of
-
-```bash
-WEBAPP_PORT=8080
-```
-
-You can also specify environment variables when you use `docker run`.
-
-```bash
-$ docker run -e WEBAPP_PORT=8000 -e WEBAPP_HOST=www.example.com ...
-```
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## The `USER` instruction
-
-The `USER` instruction sets the user name or UID to use when running
-the image.
-
-It can be used multiple times to change back to root or to another user.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## The `CMD` instruction
-
-The `CMD` instruction is a default command run when a container is
-launched from the image.
-
-```dockerfile
-CMD [ "nginx", "-g", "daemon off;" ]
-```
-
-Means we don't need to specify `nginx -g "daemon off;"` when running the
-container.
-
-Instead of:
-
-```bash
-$ docker run <dockerhubUsername>/web_image nginx -g "daemon off;"
-```
-
-We can just do:
-
-```bash
-$ docker run <dockerhubUsername>/web_image
-```
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## More about the `CMD` instruction
-
-Just like `RUN`, the `CMD` instruction comes in two forms.
-The first executes in a shell:
-
-```dockerfile
-CMD nginx -g "daemon off;"
-```
-
-The second executes directly, without shell processing:
-
-```dockerfile
-CMD [ "nginx", "-g", "daemon off;" ]
-```
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-class: extra-details
-
-## Overriding the `CMD` instruction
-
-The `CMD` can be overridden when you run a container.
-
-```bash
-$ docker run -it <dockerhubUsername>/web_image bash
-```
-
-Will run `bash` instead of `nginx -g "daemon off;"`.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## The `ENTRYPOINT` instruction
-
-The `ENTRYPOINT` instruction is like the `CMD` instruction,
-but arguments given on the command line are *appended* to the
-entry point.
-
-Note: you have to use the "exec" syntax (`[ "..." ]`).
-
-```dockerfile
-ENTRYPOINT [ "/bin/ls" ]
-```
-
-If we were to run:
-
-```bash
-$ docker run training/ls -l
-```
-
-Instead of trying to run `-l`, the container will run `/bin/ls -l`.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-class: extra-details
-
-## Overriding the `ENTRYPOINT` instruction
-
-The entry point can be overridden as well.
-
-```bash
-$ docker run -it training/ls
-bin   dev  home  lib64  mnt  proc  run   srv  tmp  var
-boot  etc  lib   media  opt  root  sbin  sys  usr
-$ docker run -it --entrypoint bash training/ls
-root@d902fb7b1fc7:/#
-```
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## How `CMD` and `ENTRYPOINT` interact
-
-The `CMD` and `ENTRYPOINT` instructions work best when used
-together.
-
-```dockerfile
-ENTRYPOINT [ "nginx" ]
-CMD [ "-g", "daemon off;" ]
-```
-
-The `ENTRYPOINT` specifies the command to be run and the `CMD`
-specifies its options. On the command line we can then potentially
-override the options when needed.
-
-```bash
-$ docker run -d <dockerhubUsername>/web_image -t
-```
-
-This will override the options `CMD` provided with new flags.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-## Advanced Dockerfile instructions
-
-* `ONBUILD` lets you stash instructions that will be executed
-  when this image is used as a base for another one.
-* `LABEL` adds arbitrary metadata to the image.
-* `ARG` defines build-time variables (optional or mandatory).
-* `STOPSIGNAL` sets the signal for `docker stop` (`TERM` by default).
-* `HEALTHCHECK` defines a command assessing the status of the container.
-* `SHELL` sets the default program to use for string-syntax RUN, CMD, etc.
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-class: extra-details
-
-## The `ONBUILD` instruction
-
-The `ONBUILD` instruction is a trigger. It sets instructions that will
-be executed when another image is built from the image being build.
-
-This is useful for building images which will be used as a base
-to build other images.
-
-```dockerfile
-ONBUILD COPY . /src
-```
-
-* You can't chain `ONBUILD` instructions with `ONBUILD`.
-* `ONBUILD` can't be used to trigger `FROM` instructions.
-
-???
-
-:EN:- Advanced Dockerfile syntax
-:FR:- Dockerfile niveau expert
-
-.debug[[containers/Advanced_Dockerfiles.md](""/tree/main/slides/containers/Advanced_Dockerfiles.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]
-
----
-
-name: toc-buildkit
-class: title
-
- Buildkit
-
-.nav[
-[Previous part](#toc-advanced-dockerfile-syntax)
-|
-[Back to table of contents](#toc-part-7)
-|
-[Next part](#toc-application-configuration)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Buildkit
-
-- "New" backend for Docker builds
-
-  - announced in 2017
-
-  - ships with Docker Engine 18.09
-
-  - enabled by default on Docker Desktop in 2021
-
-- Huge improvements in build efficiency
-
-- 100% compatible with existing Dockerfiles
-
-- New features for multi-arch
-
-- Not just for building container images
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Old vs New
-
-- Classic `docker build`:
-
-  - copy whole build context
-  - linear execution
-  - `docker run` + `docker commit` + `docker run` + `docker commit`...
-
-- Buildkit:
-
-  - copy files only when they are needed; cache them
-  - compute dependency graph (dependencies are expressed by `COPY`)
-  - parallel execution
-  - doesn't rely on Docker, but on internal runner/snapshotter
-  - can run in "normal" containers (including in Kubernetes pods)
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Parallel execution
-
-- In multi-stage builds, all stages can be built in parallel
-
-  (example: https://github.com/jpetazzo/shpod; [before] and [after])
-
-- Stages are built only when they are necessary
-
-  (i.e. if their output is tagged or used in another necessary stage)
-
-- Files are copied from context only when needed
-
-- Files are cached in the builder
-
-[before]: https://github.com/jpetazzo/shpod/blob/c6efedad6d6c3dc3120dbc0ae0a6915f85862474/Dockerfile
-[after]: https://github.com/jpetazzo/shpod/blob/d20887bbd56b5fcae2d5d9b0ce06cae8887caabf/Dockerfile
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Turning it on and off
-
-- On recent version of Docker Desktop (since 2021):
-
-  *enabled by default*
-
-- On older versions, or on Docker CE (Linux):
-
-  `export DOCKER_BUILDKIT=1`
-
-- Turning it off:
-
-  `export DOCKER_BUILDKIT=0`
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Multi-arch support
-
-- Historically, Docker only ran on x86_64 / amd64
-
-  (Intel/AMD 64 bits architecture)
-
-- Folks have been running it on 32-bit ARM for ages
-
-  (e.g. Raspberry Pi)
-
-- This required a Go compiler and appropriate base images
-
-  (which means changing/adapting Dockerfiles to use these base images)
-
-- Docker [image manifest v2 schema 2][manifest] introduces multi-arch images
-
-  (`FROM alpine` automatically gets the right image for your architecture)
-
-[manifest]: https://docs.docker.com/registry/spec/manifest-v2-2/
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Why?
-
-- Raspberry Pi (32-bit and 64-bit ARM)
-
-- Other ARM-based embedded systems (ODROID, NVIDIA Jetson...)
-
-- Apple M1
-
-- AWS Graviton
-
-- Ampere Altra (e.g. on Oracle Cloud)
-
-- ...
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Multi-arch builds in a nutshell
-
-Use the `docker buildx build` command:
-
-```bash
-docker buildx build … \
-       --platform linux/amd64,linux/arm64,linux/arm/v7,linux/386 \
-       [--tag jpetazzo/hello --push]
-```
-
-- Requires all base images to be available for these platforms
-
-- Must not use binary downloads with hard-coded architectures!
-
-  (streamlining a Dockerfile for multi-arch: [before], [after])
-
-[before]: https://github.com/jpetazzo/shpod/blob/d20887bbd56b5fcae2d5d9b0ce06cae8887caabf/Dockerfile
-[after]: https://github.com/jpetazzo/shpod/blob/c50789e662417b34fea6f5e1d893721d66d265b7/Dockerfile
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Native vs emulated vs cross
-
-- Native builds:
-
-  *aarch64 machine running aarch64 programs building aarch64 images/binaries*
-
-- Emulated builds:
-
-  *x86_64 machine running aarch64 programs building aarch64 images/binaries*
-
-- Cross builds:
-
-  *x86_64 machine running x86_64 programs building aarch64 images/binaries*
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Native
-
-- Dockerfiles are (relatively) simple to write
-
-  (nothing special to do to handle multi-arch; just avoid hard-coded archs)
-
-- Best performance
-
-- Requires "exotic" machines
-
-- Requires setting up a build farm
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Emulated
-
-- Dockerfiles are (relatively) simple to write
-
-- Emulation performance can vary
-
-  (from "OK" to "ouch this is slow")
-
-- Emulation isn't always perfect
-
-  (weird bugs/crashes are rare but can happen)
-
-- Doesn't require special machines
-
-- Supports arbitrary architectures thanks to QEMU
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Cross
-
-- Dockerfiles are more complicated to write
-
-- Requires cross-compilation toolchains
-
-- Performance is good
-
-- Doesn't require special machines
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Native builds
-
-- Requires base images to be available
-
-- To view available architectures for an image:
-  ```bash
-  regctl manifest get --list <imagename>
-  docker manifest inspect <imagename>
-  ```
-
-- Nothing special to do, *except* when downloading binaries!
-
-  ```
-  https://releases.hashicorp.com/terraform/1.1.5/terraform_1.1.5_linux_`amd64`.zip
-  ```
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Finding the right architecture
-
-`uname -m` → armv7l, aarch64, i686, x86_64
-
-`GOARCH` (from `go env`) → arm, arm64, 386, amd64
-
-In Dockerfile, add `ARG TARGETARCH` (or `ARG TARGETPLATFORM`)
-
-- `TARGETARCH` matches `GOARCH`
-
-- `TARGETPLAFORM` → linux/arm/v7, linux/arm64, linux/386, linux/amd64
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-class: extra-details
-
-## Welp
-
-Sometimes, binary releases be like:
-
-```
-Linux_arm64.tar.gz
-Linux_ppc64le.tar.gz
-Linux_s390x.tar.gz
-Linux_x86_64.tar.gz 
-```
-
-This needs a bit of custom mapping.
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Emulation
-
-- Leverages `binfmt_misc` and QEMU on Linux
-
-- Enabling:
-  ```bash
-  docker run --rm --privileged aptman/qus -s -- -p
-  ```
-
-- Disabling:
-  ```bash
-  docker run --rm --privileged aptman/qus -- -r
-  ```
-
-- Checking status:
-  ```bash
-  ls -l /proc/sys/fs/binfmt_misc
-  ```
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-class: extra-details
-
-## How it works
-
-- `binfmt_misc` lets us register _interpreters_ for binaries, e.g.:
-
-  - [DOSBox][dosbox] for DOS programs
-
-  - [Wine][wine] for Windows programs
-
-  - [QEMU][qemu] for Linux programs for other architectures
-
-- When we try to execute e.g. a SPARC binary on our x86_64 machine:
-
-  - `binfmt_misc` detects the binary format and invokes `qemu-<arch> the-binary ...`
-
-  - QEMU translates SPARC instructions to x86_64 instructions
-
-  - system calls go straight to the kernel
-
-[dosbox]: https://www.dosbox.com/
-[QEMU]: https://www.qemu.org/
-[wine]: https://www.winehq.org/
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-class: extra-details
-
-## QEMU registration
-
-- The `aptman/qus` image mentioned earlier contains static QEMU builds
-
-- It registers all these interpreters with the kernel
-
-- For more details, check:
-
-  - https://github.com/dbhi/qus
-
-  - https://dbhi.github.io/qus/
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Cross-compilation
-
-- Cross-compilation is about 10x faster than emulation
-
-  (non-scientific benchmarks!)
-
-- In Dockerfile, add:
-
-  `ARG BUILDARCH BUILDPLATFORM TARGETARCH TARGETPLATFORM`
-
-- Can use `FROM --platform=$BUILDPLATFORM <image>`
-
-- Then use `$TARGETARCH` or `$TARGETPLATFORM`
-
-  (e.g. for Go, `export GOARCH=$TARGETARCH`)
-
-- Check [tonistiigi/xx][xx] and [Toni's blog][toni] for some amazing cross tools!
-
-[xx]: https://github.com/tonistiigi/xx
-[toni]: https://medium.com/@tonistiigi/faster-multi-platform-builds-dockerfile-cross-compilation-guide-part-1-ec087c719eaf
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## Checking runtime capabilities
-
-Build and run the following Dockerfile:
-
-```dockerfile
-FROM --platform=linux/amd64 busybox AS amd64
-FROM --platform=linux/arm64 busybox AS arm64
-FROM --platform=linux/arm/v7 busybox AS arm32
-FROM --platform=linux/386 busybox AS ia32
-FROM alpine
-RUN apk add file
-WORKDIR /root
-COPY --from=amd64 /bin/busybox /root/amd64/busybox
-COPY --from=arm64 /bin/busybox /root/arm64/busybox
-COPY --from=arm32 /bin/busybox /root/arm32/busybox
-COPY --from=ia32 /bin/busybox /root/ia32/busybox
-CMD for A in *; do echo "$A => $($A/busybox uname -a)"; done
-```
-
-It will indicate which executables can be run on your engine.
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-## More than builds
-
-- Buildkit is also used in other systems:
-
-  - [Earthly] - generic repeatable build pipelines
-
-  - [Dagger] - CICD pipelines that run anywhere
-
-  - and more!
-
-[Earthly]: https://earthly.dev/
-[Dagger]: https://dagger.io/
-
-.debug[[containers/Buildkit.md](""/tree/main/slides/containers/Buildkit.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg)]
-
----
-
-name: toc-application-configuration
-class: title
-
- Application Configuration
-
-.nav[
-[Previous part](#toc-buildkit)
-|
-[Back to table of contents](#toc-part-8)
-|
-[Next part](#toc-logging)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Application Configuration
-
-There are many ways to provide configuration to containerized applications.
-
-There is no "best way" — it depends on factors like:
-
-* configuration size,
-
-* mandatory and optional parameters,
-
-* scope of configuration (per container, per app, per customer, per site, etc),
-
-* frequency of changes in the configuration.
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Command-line parameters
-
-```bash
-docker run jpetazzo/hamba 80 www1:80 www2:80
-```
-
-* Configuration is provided through command-line parameters.
-
-* In the above example, the `ENTRYPOINT` is a script that will:
-
-  - parse the parameters,
-
-  - generate a configuration file,
-
-  - start the actual service.
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Command-line parameters pros and cons
-
-* Appropriate for mandatory parameters (without which the service cannot start).
-
-* Convenient for "toolbelt" services instantiated many times.
-
-  (Because there is no extra step: just run it!)
-
-* Not great for dynamic configurations or bigger configurations.
-
-  (These things are still possible, but more cumbersome.)
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Environment variables
-
-```bash
-docker run -e ELASTICSEARCH_URL=http://es42:9201/ kibana
-```
-
-* Configuration is provided through environment variables.
-
-* The environment variable can be used straight by the program,
-  <br/>or by a script generating a configuration file.
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Environment variables pros and cons
-
-* Appropriate for optional parameters (since the image can provide default values).
-
-* Also convenient for services instantiated many times.
-
-  (It's as easy as command-line parameters.)
-
-* Great for services with lots of parameters, but you only want to specify a few.
-
-  (And use default values for everything else.)
-
-* Ability to introspect possible parameters and their default values.
-
-* Not great for dynamic configurations.
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Baked-in configuration
-
-```
-FROM prometheus
-COPY prometheus.conf /etc
-```
-
-* The configuration is added to the image.
-
-* The image may have a default configuration; the new configuration can:
-
-  - replace the default configuration,
-
-  - extend it (if the code can read multiple configuration files).
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Baked-in configuration pros and cons
-
-* Allows arbitrary customization and complex configuration files.
-
-* Requires writing a configuration file. (Obviously!)
-
-* Requires building an image to start the service.
-
-* Requires rebuilding the image to reconfigure the service.
-
-* Requires rebuilding the image to upgrade the service.
-
-* Configured images can be stored in registries.
-
-  (Which is great, but requires a registry.)
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Configuration volume
-
-```bash
-docker run -v appconfig:/etc/appconfig myapp
-```
-
-* The configuration is stored in a volume.
-
-* The volume is attached to the container.
-
-* The image may have a default configuration.
-
-  (But this results in a less "obvious" setup, that needs more documentation.)
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Configuration volume pros and cons
-
-* Allows arbitrary customization and complex configuration files.
-
-* Requires creating a volume for each different configuration.
-
-* Services with identical configurations can use the same volume.
-
-* Doesn't require building / rebuilding an image when upgrading / reconfiguring.
-
-* Configuration can be generated or edited through another container.
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Dynamic configuration volume
-
-* This is a powerful pattern for dynamic, complex configurations.
-
-* The configuration is stored in a volume.
-
-* The configuration is generated / updated by a special container.
-
-* The application container detects when the configuration is changed.
-
-  (And automatically reloads the configuration when necessary.)
-
-* The configuration can be shared between multiple services if needed.
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Dynamic configuration volume example
-
-In a first terminal, start a load balancer with an initial configuration:
-
-```bash
-$ docker run --name loadbalancer jpetazzo/hamba \
-  80 goo.gl:80
-```
-
-In another terminal, reconfigure that load balancer:
-
-```bash
-$ docker run --rm --volumes-from loadbalancer jpetazzo/hamba reconfigure \
-  80 google.com:80
-```
-
-The configuration could also be updated through e.g. a REST API.
-
-(The REST API being itself served from another container.)
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-## Keeping secrets
-
-.warning[Ideally, you should not put secrets (passwords, tokens...) in:]
-
-* command-line or environment variables (anyone with Docker API access can get them),
-
-* images, especially stored in a registry.
-
-Secrets management is better handled with an orchestrator (like Swarm or Kubernetes).
-
-Orchestrators will allow to pass secrets in a "one-way" manner.
-
-Managing secrets securely without an orchestrator can be contrived.
-
-E.g.:
-
-- read the secret on stdin when the service starts,
-
-- pass the secret using an API endpoint.
-
-.debug[[containers/Application_Configuration.md](""/tree/main/slides/containers/Application_Configuration.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg)]
-
----
-
-name: toc-logging
-class: title
-
- Logging
-
-.nav[
-[Previous part](#toc-application-configuration)
-|
-[Back to table of contents](#toc-part-8)
-|
-[Next part](#toc-orchestration-an-overview)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Logging
-
-In this chapter, we will explain the different ways to send logs from containers.
-
-We will then show one particular method in action, using ELK and Docker's logging drivers.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## There are many ways to send logs
-
-- The simplest method is to write on the standard output and error.
-
-- Applications can write their logs to local files.
-
-  (The files are usually periodically rotated and compressed.)
-
-- It is also very common (on UNIX systems) to use syslog.
-
-  (The logs are collected by syslogd or an equivalent like journald.)
-
-- In large applications with many components, it is common to use a logging service.
-
-  (The code uses a library to send messages to the logging service.)
-
-*All these methods are available with containers.*
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Writing on stdout/stderr
-
-- The standard output and error of containers is managed by the container engine.
-
-- This means that each line written by the container is received by the engine.
-
-- The engine can then do "whatever" with these log lines.
-
-- With Docker, the default configuration is to write the logs to local files.
-
-- The files can then be queried with e.g. `docker logs` (and the equivalent API request).
-
-- This can be customized, as we will see later.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Writing to local files
-
-- If we write to files, it is possible to access them but cumbersome.
-
-  (We have to use `docker exec` or `docker cp`.)
-
-- Furthermore, if the container is stopped, we cannot use `docker exec`.
-
-- If the container is deleted, the logs disappear.
-
-- What should we do for programs who can only log to local files?
-
---
-
-- There are multiple solutions.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Using a volume or bind mount
-
-- Instead of writing logs to a normal directory, we can place them on a volume.
-
-- The volume can be accessed by other containers.
-
-- We can run a program like `filebeat` in another container accessing the same volume.
-
-  (`filebeat` reads local log files continuously, like `tail -f`, and sends them
-  to a centralized system like ElasticSearch.)
-
-- We can also use a bind mount, e.g. `-v /var/log/containers/www:/var/log/tomcat`.
-
-- The container will write log files to a directory mapped to a host directory.
-
-- The log files will appear on the host and be consumable directly from the host.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Using logging services
-
-- We can use logging frameworks (like log4j or the Python `logging` package).
-
-- These frameworks require some code and/or configuration in our application code.
-
-- These mechanisms can be used identically inside or outside of containers.
-
-- Sometimes, we can leverage containerized networking to simplify their setup.
-
-- For instance, our code can send log messages to a server named `log`.
-
-- The name `log` will resolve to different addresses in development, production, etc.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Using syslog
-
-- What if our code (or the program we are running in containers) uses syslog?
-
-- One possibility is to run a syslog daemon in the container.
-
-- Then that daemon can be setup to write to local files or forward to the network.
-
-- Under the hood, syslog clients connect to a local UNIX socket, `/dev/log`.
-
-- We can expose a syslog socket to the container (by using a volume or bind-mount).
-
-- Then just create a symlink from `/dev/log` to the syslog socket.
-
-- Voilà!
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Using logging drivers
-
-- If we log to stdout and stderr, the container engine receives the log messages.
-
-- The Docker Engine has a modular logging system with many plugins, including:
-
-  - json-file (the default one)
-  - syslog
-  - journald
-  - gelf
-  - fluentd
-  - splunk
-  - etc.
-
-- Each plugin can process and forward the logs to another process or system.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## A word of warning about `json-file`
-
-- By default, log file size is unlimited.
-
-- This means that a very verbose container *will* use up all your disk space.
-
-  (Or a less verbose container, but running for a very long time.)
-
-- Log rotation can be enabled by setting a `max-size` option.
-
-- Older log files can be removed by setting a `max-file` option.
-
-- Just like other logging options, these can be set per container, or globally.
-
-Example:
-```bash
-$ docker run --log-opt max-size=10m --log-opt max-file=3 elasticsearch
-```
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Demo: sending logs to ELK
-
-- We are going to deploy an ELK stack.
-
-- It will accept logs over a GELF socket.
-
-- We will run a few containers with the `gelf` logging driver.
-
-- We will then see our logs in Kibana, the web interface provided by ELK.
-
-*Important foreword: this is not an "official" or "recommended"
-setup; it is just an example. We used ELK in this demo because
-it's a popular setup and we keep being asked about it; but you
-will have equal success with Fluent or other logging stacks!*
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## What's in an ELK stack?
-
-- ELK is three components:
-
-  - ElasticSearch (to store and index log entries)
-
-  - Logstash (to receive log entries from various
-    sources, process them, and forward them to various
-    destinations)
-
-  - Kibana (to view/search log entries with a nice UI)
-
-- The only component that we will configure is Logstash
-
-- We will accept log entries using the GELF protocol
-
-- Log entries will be stored in ElasticSearch,
-  <br/>and displayed on Logstash's stdout for debugging
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Running ELK
-
-- We are going to use a Compose file describing the ELK stack.
-
-- The Compose file is in the container.training repository on GitHub.
-
-```bash
-$ git clone https://github.com/jpetazzo/container.training
-$ cd container.training
-$ cd elk
-$ docker-compose up
-```
-
-- Let's have a look at the Compose file while it's deploying.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Our basic ELK deployment
-
-- We are using images from the Docker Hub: `elasticsearch`, `logstash`, `kibana`.
-
-- We don't need to change the configuration of ElasticSearch.
-
-- We need to tell Kibana the address of ElasticSearch:
-
-  - it is set with the `ELASTICSEARCH_URL` environment variable,
-
-  - by default it is `localhost:9200`, we change it to `elasticsearch:9200`.
-
-- We need to configure Logstash:
-
-  - we pass the entire configuration file through command-line arguments,
-
-  - this is a hack so that we don't have to create an image just for the config.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Sending logs to ELK
-
-- The ELK stack accepts log messages through a GELF socket.
-
-- The GELF socket listens on UDP port 12201.
-
-- To send a message, we need to change the logging driver used by Docker.
-
-- This can be done globally (by reconfiguring the Engine) or on a per-container basis.
-
-- Let's override the logging driver for a single container:
-
-```bash
-$ docker run --log-driver=gelf --log-opt=gelf-address=udp://localhost:12201 \
-  alpine echo hello world
-```
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Viewing the logs in ELK
-
-- Connect to the Kibana interface.
-
-- It is exposed on port 5601.
-
-- Browse http://X.X.X.X:5601.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## "Configuring" Kibana
-
-- Kibana should offer you to "Configure an index pattern":
-  <br/>in the "Time-field name" drop down, select "@timestamp", and hit the
-  "Create" button.
-
-- Then:
-
-  - click "Discover" (in the top-left corner),
-  - click "Last 15 minutes" (in the top-right corner),
-  - click "Last 1 hour" (in the list in the middle),
-  - click "Auto-refresh" (top-right corner),
-  - click "5 seconds" (top-left of the list).
-
-- You should see a series of green bars (with one new green bar every minute).
-
-- Our 'hello world' message should be visible there.
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-## Important afterword
-
-**This is not a "production-grade" setup.**
-
-It is just an educational example. Since we have only
-one node , we did set up a single
-ElasticSearch instance and a single Logstash instance.
-
-In a production setup, you need an ElasticSearch cluster
-(both for capacity and availability reasons). You also
-need multiple Logstash instances.
-
-And if you want to withstand
-bursts of logs, you need some kind of message queue:
-Redis if you're cheap, Kafka if you want to make sure
-that you don't drop messages on the floor. Good luck.
-
-If you want to learn more about the GELF driver,
-have a look at [this blog post](
-https://jpetazzo.github.io/2017/01/20/docker-logging-gelf/).
-
-.debug[[containers/Logging.md](""/tree/main/slides/containers/Logging.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg)]
-
----
-
-name: toc-orchestration-an-overview
-class: title
-
- Orchestration, an overview
-
-.nav[
-[Previous part](#toc-logging)
-|
-[Back to table of contents](#toc-part-8)
-|
-[Next part](#toc-links-and-resources)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Orchestration, an overview
-
-In this chapter, we will:
-
-* Explain what is orchestration and why we would need it.
-
-* Present (from a high-level perspective) some orchestrators.
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## What's orchestration?
-
-![Joana Carneiro (orchestra conductor)](images/conductor.jpg)
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## What's orchestration?
-
-According to Wikipedia:
-
-*Orchestration describes the __automated__ arrangement,
-coordination, and management of complex computer systems,
-middleware, and services.*
-
---
-
-*[...] orchestration is often discussed in the context of 
-__service-oriented architecture__, __virtualization__, provisioning, 
-Converged Infrastructure and __dynamic datacenter__ topics.*
-
---
-
-What does that really mean?
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Example 1: dynamic cloud instances
-
---
-
-- Q: do we always use 100% of our servers?
-
---
-
-- A: obviously not!
-
-.center[![Daily variations of traffic](images/traffic-graph.png)]
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Example 1: dynamic cloud instances
-
-- Every night, scale down
-  
-  (by shutting down extraneous replicated instances)
-
-- Every morning, scale up
-  
-  (by deploying new copies)
-
-- "Pay for what you use"
-  
-  (i.e. save big $$$ here)
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Example 1: dynamic cloud instances
-
-How do we implement this?
-
-- Crontab
-  
-- Autoscaling (save even bigger $$$)
-
-That's *relatively* easy.
-
-Now, how are things for our IAAS provider?
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Example 2: dynamic datacenter
-
-- Q: what's the #1 cost in a datacenter?
-
---
-
-- A: electricity!
-
---
-
-- Q: what uses electricity?
-
---
-
-- A: servers, obviously
-
-- A: ... and associated cooling
-
---
-
-- Q: do we always use 100% of our servers?
-
---
-
-- A: obviously not!
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Example 2: dynamic datacenter
-
-- If only we could turn off unused servers during the night...
-
-- Problem: we can only turn off a server if it's totally empty!
-  
-  (i.e. all VMs on it are stopped/moved)
-
-- Solution: *migrate* VMs and shutdown empty servers
-  
-  (e.g. combine two hypervisors with 40% load into 80%+0%,
-  <br/>and shut down the one at 0%)
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Example 2: dynamic datacenter
-
-How do we implement this?
-
-- Shut down empty hosts (but keep some spare capacity)
-
-- Start hosts again when capacity gets low
-
-- Ability to "live migrate" VMs
-  
-  (Xen already did this 10+ years ago)
-
-- Rebalance VMs on a regular basis
-  
-  - what if a VM is stopped while we move it?
-  - should we allow provisioning on hosts involved in a migration?
-
-*Scheduling* becomes more complex.
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## What is scheduling?
-
-According to Wikipedia (again):
-
-*In computing, scheduling is the method by which threads, 
-processes or data flows are given access to system resources.*
-
-The scheduler is concerned mainly with:
-
-- throughput (total amount of work done per time unit);
-- turnaround time (between submission and completion);
-- response time (between submission and start);
-- waiting time (between job readiness and execution);
-- fairness (appropriate times according to priorities).
-
-In practice, these goals often conflict.
-
-**"Scheduling" = decide which resources to use.**
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Exercise 1
-
-- You have:
-
-  - 5 hypervisors (physical machines)
-
-- Each server has:
-
-  - 16 GB RAM, 8 cores, 1 TB disk
-
-- Each week, your team requests:
-
-  - one VM with X RAM, Y CPU, Z disk
-
-Scheduling = deciding which hypervisor to use for each VM.
-
-Difficulty: easy!
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-<!-- Warning, two almost identical slides (for img effect) -->
-
-## Exercise 2
-
-- You have:
-
-  - 1000+ hypervisors (and counting!)
-
-- Each server has different resources:
-
-  - 8-500 GB of RAM, 4-64 cores, 1-100 TB disk
-
-- Multiple times a day, a different team asks for:
-
-  - up to 50 VMs with different characteristics
-
-Scheduling = deciding which hypervisor to use for each VM.
-
-Difficulty: ???
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-<!-- Warning, two almost identical slides (for img effect) -->
-
-## Exercise 2
-
-- You have:
-
-  - 1000+ hypervisors (and counting!)
-
-- Each server has different resources:
-
-  - 8-500 GB of RAM, 4-64 cores, 1-100 TB disk
-
-- Multiple times a day, a different team asks for:
-
-  - up to 50 VMs with different characteristics
-
-Scheduling = deciding which hypervisor to use for each VM.
-
-![Troll face](images/trollface.png)
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Exercise 3
-
-- You have machines (physical and/or virtual)
-
-- You have containers
-
-- You are trying to put the containers on the machines
-
-- Sounds familiar?
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## Scheduling with one resource
-
-.center[![Not-so-good bin packing](images/binpacking-1d-1.gif)]
-
-## We can't fit a job of size 6 :(
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## Scheduling with one resource
-
-.center[![Better bin packing](images/binpacking-1d-2.gif)]
-
-## ... Now we can!
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## Scheduling with two resources
-
-.center[![2D bin packing](images/binpacking-2d.gif)]
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## Scheduling with three resources
-
-.center[![3D bin packing](images/binpacking-3d.gif)]
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## You need to be good at this
-
-.center[![Tangram](images/tangram.gif)]
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## But also, you must be quick!
-
-.center[![Tetris](images/tetris-1.png)]
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## And be web scale!
-
-.center[![Big tetris](images/tetris-2.gif)]
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## And think outside (?) of the box!
-
-.center[![3D tetris](images/tetris-3.png)]
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-class: pic
-
-## Good luck!
-
-.center[![FUUUUUU face](images/fu-face.jpg)]
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## TL,DR
-
-* Scheduling with multiple resources (dimensions) is hard.
-
-* Don't expect to solve the problem with a Tiny Shell Script.
-
-* There are literally tons of research papers written on this.
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## But our orchestrator also needs to manage ...
-
-* Network connectivity (or filtering) between containers.
-
-* Load balancing (external and internal).
-
-* Failure recovery (if a node or a whole datacenter fails).
-
-* Rolling out new versions of our applications.
-
-  (Canary deployments, blue/green deployments...)
-
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Some orchestrators
-
-We are going to present briefly a few orchestrators.
-
-There is no "absolute best" orchestrator.
-
-It depends on:
-
-- your applications,
-
-- your requirements,
-
-- your pre-existing skills...
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Nomad
-
-- Open Source project by Hashicorp.
-
-- Arbitrary scheduler (not just for containers).
-
-- Great if you want to schedule mixed workloads.
-
-  (VMs, containers, processes...)
-
-- Less integration with the rest of the container ecosystem.
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Mesos
-
-- Open Source project in the Apache Foundation.
-
-- Arbitrary scheduler (not just for containers).
-
-- Two-level scheduler.
-
-- Top-level scheduler acts as a resource broker.
-
-- Second-level schedulers (aka "frameworks") obtain resources from top-level.
-
-- Frameworks implement various strategies.
-
-  (Marathon = long running processes; Chronos = run at intervals; ...)
-
-- Commercial offering through DC/OS by Mesosphere.
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Rancher
-
-- Rancher 1 offered a simple interface for Docker hosts.
-
-- Rancher 2 is a complete management platform for Docker and Kubernetes.
-
-- Technically not an orchestrator, but it's a popular option.
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Swarm
-
-- Tightly integrated with the Docker Engine.
-
-- Extremely simple to deploy and setup, even in multi-manager (HA) mode.
-
-- Secure by default.
-
-- Strongly opinionated:
-
-  - smaller set of features,
-
-  - easier to operate.
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-
-## Kubernetes
-
-- Open Source project initiated by Google.
-
-- Contributions from many other actors.
-
-- *De facto* standard for container orchestration.
-
-- Many deployment options; some of them very complex.
-
-- Reputation: steep learning curve.
-
-- Reality:
-
-  - true, if we try to understand *everything*;
-
-  - false, if we focus on what matters.
-
-???
-
-:EN:- Orchestration overview
-:FR:- Survol de techniques d'orchestration 
-
-.debug[[containers/Orchestration_Overview.md](""/tree/main/slides/containers/Orchestration_Overview.md)]
----
-class: title, self-paced
-
-Thank you!
-
-.debug[[shared/thankyou.md](""/tree/main/slides/shared/thankyou.md)]
----
-
-class: title, in-person
-
-That's all, folks! <br/> Questions?
-
-![end](images/end.jpg)
-
-.debug[[shared/thankyou.md](""/tree/main/slides/shared/thankyou.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg)]
-
----
-
-name: toc-links-and-resources
-class: title
-
- Links and resources
-
-.nav[
-[Previous part](#toc-orchestration-an-overview)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Links and resources
-
-- [Docker Community Slack](https://community.docker.com/registrations/groups/4316)
-- [Docker Community Forums](https://forums.docker.com/)
-- [Docker Hub](https://hub.docker.com)
-- [Docker Blog](https://blog.docker.com/)
-- [Docker documentation](https://docs.docker.com/)
-- [Docker on StackOverflow](https://stackoverflow.com/questions/tagged/docker)
-- [Docker on Twitter](https://twitter.com/docker)
-- [Play With Docker Hands-On Labs](https://training.play-with-docker.com/)
-
-.footnote[These slides (and future updates) are on → https://container.training/]
-
-.debug[[containers/links.md](""/tree/main/slides/containers/links.md)]</textarea>
-    <script src="remark.min.js" type="text/javascript">
-    </script>
-    <script type="text/javascript">
-      var slideshow = remark.create({
-        ratio: '16:9',
-        highlightSpans: true,
-        slideNumberFormat: '%current%/%total%',
-        excludedClasses: ["self-paced"]
-      });
-    </script>
-    
-    <!-- 
-    These two scripts will be available only when loading the
-    content using the pub/sub server. Otherwise, they'll just
-    404 and that's OK.
-    -->
-    <script src="/socket.io/socket.io.js">
-    </script>
-    <script src="/remote.js">
-    </script>
-
-  </body>
-</html>
diff --git a/slides/swarm-halfday.yml.html b/slides/swarm-halfday.yml.html
index e69de29..5290b3a 100644
--- a/slides/swarm-halfday.yml.html
+++ b/slides/swarm-halfday.yml.html
@@ -0,0 +1,6368 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Container Orchestration with Docker and Swarm </title>
+    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+    <link rel="stylesheet" href="workshop.css">
+  </head>
+  <body>
+    <!--
+    <div style="position: absolute; left: 20%; right: 20%; top: 30%;">
+      <h1 style="font-size: 3em;">Loading ...</h1>
+      The slides should show up here. If they don't, it might be
+      because you are accessing this file directly from your filesystem.
+      It needs to be served from a web server. You can try this:
+      <pre>
+        docker-compose up -d
+        open http://localhost:8888/workshop.html # on MacOS
+        xdg-open http://localhost:8888/workshop.html # on Linux
+      </pre>
+      Once the slides are loaded, this notice disappears when you
+      go full screen (e.g. by hitting "f").
+    </div>
+    -->
+    <textarea id="source">class: title, self-paced
+
+Container Orchestration<br/>with Docker and Swarm<br/>
+
+<!-- .nav[*Self-paced version*] -->
+
+.debug[
+```
+ M slides/airgapped/Importing_Images.md
+
+```
+
+These slides have been built from commit: 25a1d5a
+
+
+[shared/title.md](""/tree/main/slides/shared/title.md)]
+---
+
+class: title, in-person
+
+Container Orchestration<br/>with Docker and Swarm<br/><br/></br>
+
+.footnote[
+**Slides[:](https://www.youtube.com/watch?v=h16zyxiwDLY) https://container.training/**
+]
+
+<!--
+WiFi: **Something**<br/>
+Password: **Something**
+
+**Be kind to the WiFi!**<br/>
+*Use the 5G network.*
+*Don't use your hotspot.*<br/>
+*Don't stream videos or download big files during the workshop*<br/>
+*Thank you!*
+-->
+
+.debug[[shared/title.md](""/tree/main/slides/shared/title.md)]
+---
+## Introductions
+
+- Let's do a quick intro.
+
+- I am:
+
+  - 👨🏽‍🦲 Marco Verleun, container adept.
+
+- Who are you and what do you want to learn?
+
+
+<!-- ⚠️ This slide should be customized by the tutorial instructor(s). -->
+
+<!--
+
+- Hello! We are:
+
+   - 👷🏻‍♀️ AJ ([@s0ulshake], [EphemeraSearch], [Quantgene])
+
+   - 🚁 Alexandre ([@alexbuisine], Enix SAS)
+
+   - 🐳 Jérôme ([@jpetazzo], Ardan Labs)
+
+   - 🐳 Jérôme ([@jpetazzo], Enix SAS)
+
+   - 🐳 Jérôme ([@jpetazzo], Tiny Shell Script LLC)
+
+-->
+
+<!--
+
+- The training will run for 4 hours, with a 10 minutes break every hour
+
+  (the middle break will be a bit longer)
+
+-->
+
+<!--
+
+- The workshop will run from XXX to YYY
+
+- There will be a lunch break at ZZZ
+
+  (And coffee breaks!)
+
+-->
+
+<!--
+
+- Feel free to interrupt for questions at any time
+
+- *Especially when you see full screen container pictures!*
+
+- Live feedback, questions, help: [Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)
+
+-->
+
+<!--
+
+- You ~~should~~ must ask questions! Lots of questions!
+
+  (especially when you see full screen container pictures)
+
+- Use [Slack](https://dockercommunity.slack.com/messages/C7GKACWDV) to ask questions, get help, etc.
+
+-->
+
+<!-- -->
+
+[@alexbuisine]: https://twitter.com/alexbuisine
+[EphemeraSearch]: https://ephemerasearch.com/
+[@jpetazzo]: https://twitter.com/jpetazzo
+[@s0ulshake]: https://twitter.com/s0ulshake
+[Quantgene]: https://www.quantgene.com/
+
+.debug[[logistics.md](""/tree/main/slides/logistics.md)]
+---
+
+## Exercises
+
+- There is a series of exercises
+
+- To make the most out of the training, please try the exercises!
+
+  (it will help to practice and memorize the content of the day)
+
+- There is a git repo that you have to clone first
+.debug[[logistics.md](""/tree/main/slides/logistics.md)]
+---
+## A brief introduction
+
+- This was initially written by [Jérôme Petazzoni](https://twitter.com/jpetazzo) to support in-person,
+  instructor-led workshops and tutorials
+
+- Over time, [multiple contributors](https://github.com/jpetazzo/container.training/graphs/contributors) also helped to improve these materials — thank you!
+
+- You can also follow along on your own, at your own pace
+
+- We included as much information as possible in these slides
+
+- We recommend having a mentor to help you ...
+
+- ... Or be comfortable spending some time reading the Docker
+ [documentation](https://docs.docker.com/) ...
+
+- ... And looking for answers in the [Docker forums](forums.docker.com),
+  [StackOverflow](https://stackoverflow.com/questions/tagged/docker),
+  and other outlets
+
+.debug[[swarm/intro.md](""/tree/main/slides/swarm/intro.md)]
+---
+
+class: self-paced
+
+## Hands on, you shall practice
+
+- Nobody ever became a Jedi by spending their lives reading Wookiepedia
+
+- Likewise, it will take more than merely *reading* these slides
+  to make you an expert
+
+- These slides include *tons* of demos, exercises, and examples
+
+- They assume that you have access to some Docker nodes
+
+- If you are attending a workshop or tutorial:
+  <br/>you will be given specific instructions to access your cluster
+
+- If you are doing this on your own:
+  <br/>the first chapter will give you various options to get your own cluster
+
+.debug[[swarm/intro.md](""/tree/main/slides/swarm/intro.md)]
+---
+## Accessing these slides now
+
+- We recommend that you open these slides in your browser:
+
+  https://container.training/
+
+- Use arrows to move to next/previous slide
+
+  (up, down, left, right, page up, page down)
+
+- Type a slide number + ENTER to go to that slide
+
+- The slide number is also visible in the URL bar
+
+  (e.g. .../#123 for slide 123)
+
+.debug[[shared/about-slides.md](""/tree/main/slides/shared/about-slides.md)]
+---
+
+## Accessing these slides later
+
+- Slides will remain online so you can review them later if needed
+
+  (let's say we'll keep them online at least 1 year, how about that?)
+
+- You can download the slides using that URL:
+
+  https://container.training/slides.zip
+
+  (then open the file `swarm-halfday.yml.html`)
+
+- You will find new versions of these slides on:
+
+  https://container.training/
+
+.debug[[shared/about-slides.md](""/tree/main/slides/shared/about-slides.md)]
+---
+
+## These slides are open source
+
+- You are welcome to use, re-use, share these slides
+
+- These slides are written in Markdown
+
+- The sources of these slides are available in a public GitHub repository:
+
+  https://github.com/jpetazzo/container.training
+
+- Typos? Mistakes? Questions? Feel free to hover over the bottom of the slide ...
+
+.footnote[👇 Try it! The source file will be shown and you can view it on GitHub and fork and edit it.]
+
+<!--
+.lab[
+```open https://github.com/jpetazzo/container.training/tree/master/slides/common/about-slides.md```
+]
+-->
+
+.debug[[shared/about-slides.md](""/tree/main/slides/shared/about-slides.md)]
+---
+
+class: extra-details
+
+## Extra details
+
+- This slide has a little magnifying glass in the top left corner
+
+- This magnifying glass indicates slides that provide extra details
+
+- Feel free to skip them if:
+
+  - you are in a hurry
+
+  - you are new to this and want to avoid cognitive overload
+
+  - you want only the most essential information
+
+- You can review these slides another time if you want, they'll be waiting for you ☺
+
+.debug[[shared/about-slides.md](""/tree/main/slides/shared/about-slides.md)]
+---
+## Chat room
+
+- We've set up a chat room that we will monitor during the workshop
+
+- Don't hesitate to use it to ask questions, or get help, or share feedback
+
+- The chat room will also be available after the workshop
+
+- Join the chat room: [Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)
+
+- Say hi in the chat room!
+
+.debug[[shared/chat-room-im.md](""/tree/main/slides/shared/chat-room-im.md)]
+---
+
+name: toc-part-1
+
+## Part 1
+
+- [Pre-requirements](#toc-pre-requirements)
+
+- [Our sample application](#toc-our-sample-application)
+
+- [Identifying bottlenecks](#toc-identifying-bottlenecks)
+
+- [SwarmKit](#toc-swarmkit)
+
+- [Declarative vs imperative](#toc-declarative-vs-imperative)
+
+- [Swarm mode](#toc-swarm-mode)
+
+- [Creating our first Swarm](#toc-creating-our-first-swarm)
+
+
+.debug[(auto-generated TOC)]
+---
+name: toc-part-2
+
+## Part 2
+
+- [Running our first Swarm service](#toc-running-our-first-swarm-service)
+
+- [Our app on Swarm](#toc-our-app-on-swarm)
+
+- [Swarm Stacks](#toc-swarm-stacks)
+
+- [CI/CD for Docker and orchestration](#toc-cicd-for-docker-and-orchestration)
+
+- [Updating services](#toc-updating-services)
+
+
+.debug[(auto-generated TOC)]
+---
+name: toc-part-3
+
+## Part 3
+
+- [Secrets management and encryption at rest](#toc-secrets-management-and-encryption-at-rest)
+
+- [Least privilege model](#toc-least-privilege-model)
+
+- [Centralized logging](#toc-centralized-logging)
+
+- [Setting up ELK to store container logs](#toc-setting-up-elk-to-store-container-logs)
+
+- [Metrics collection](#toc-metrics-collection)
+
+- [Links and resources](#toc-links-and-resources)
+
+
+.debug[(auto-generated TOC)]
+
+
+
+.debug[[shared/toc.md](""/tree/main/slides/shared/toc.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]
+
+---
+
+name: toc-pre-requirements
+class: title
+
+ Pre-requirements
+
+.nav[
+[Previous part](#toc-)
+|
+[Back to table of contents](#toc-part-1)
+|
+[Next part](#toc-our-sample-application)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Pre-requirements
+
+- Be comfortable with the UNIX command line
+
+  - navigating directories
+
+  - editing files
+
+  - a little bit of bash-fu (environment variables, loops)
+
+- Some Docker knowledge
+
+  - `docker run`, `docker ps`, `docker build`
+
+  - ideally, you know how to write a Dockerfile and build it
+    <br/>
+    (even if it's a `FROM` line and a couple of `RUN` commands)
+
+- It's totally OK if you are not a Docker expert!
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+class: title
+
+*Tell me and I forget.*
+<br/>
+*Teach me and I remember.*
+<br/>
+*Involve me and I learn.*
+
+Misattributed to Benjamin Franklin
+
+[(Probably inspired by Chinese Confucian philosopher Xunzi)](https://www.barrypopik.com/index.php/new_york_city/entry/tell_me_and_i_forget_teach_me_and_i_may_remember_involve_me_and_i_will_lear/)
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+## Hands-on sections
+
+- The whole workshop is hands-on
+
+- We are going to build, ship, and run containers!
+
+- You are invited to reproduce all the demos
+
+- All hands-on sections are clearly identified, like the gray rectangle below
+
+.lab[
+
+- This is the stuff you're supposed to do!
+
+- Go to https://container.training/ to view these slides
+
+<!-- ```open https://container.training/``` -->
+
+]
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+class: in-person
+
+## Where are we going to run our containers?
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+class: in-person, pic
+
+![You get a cluster](images/you-get-a-cluster.jpg)
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+class: in-person
+
+## You get a cluster of cloud VMs
+
+- Each person gets a private cluster of cloud VMs (not shared with anybody else)
+
+- They'll remain up for the duration of the workshop
+
+- You should have a little card with login+password+IP addresses
+
+- You can automatically SSH from one VM to another
+
+- The nodes have aliases: `node1`, `node2`, etc.
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+class: in-person
+
+## Why don't we run containers locally?
+
+- Installing this stuff can be hard on some machines
+
+  (32 bits CPU or OS... Laptops without administrator access... etc.)
+
+- *"The whole team downloaded all these container images from the WiFi!
+  <br/>... and it went great!"* (Literally no-one ever)
+
+- All you need is a computer (or even a phone or tablet!), with:
+
+  - an Internet connection
+
+  - a web browser
+
+  - an SSH client
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+class: in-person
+
+## SSH clients
+
+- On Linux, OS X, FreeBSD... you are probably all set
+
+- On Windows, get one of these:
+
+  - [putty](http://www.putty.org/)
+  - Microsoft [Win32 OpenSSH](https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH)
+  - [Git BASH](https://git-for-windows.github.io/)
+  - [MobaXterm](http://mobaxterm.mobatek.net/)
+
+- On Android, [JuiceSSH](https://juicessh.com/)
+  ([Play Store](https://play.google.com/store/apps/details?id=com.sonelli.juicessh))
+  works pretty well
+
+- Nice-to-have: [Mosh](https://mosh.org/) instead of SSH, if your Internet connection tends to lose packets
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+class: in-person, extra-details
+
+## What is this Mosh thing?
+
+*You don't have to use Mosh or even know about it to follow along.
+<br/>
+We're just telling you about it because some of us think it's cool!*
+
+- Mosh is "the mobile shell"
+
+- It is essentially SSH over UDP, with roaming features
+
+- It retransmits packets quickly, so it works great even on lossy connections
+
+  (Like hotel or conference WiFi)
+
+- It has intelligent local echo, so it works great even in high-latency connections
+
+  (Like hotel or conference WiFi)
+
+- It supports transparent roaming when your client IP address changes
+
+  (Like when you hop from hotel to conference WiFi)
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+
+class: in-person, extra-details
+
+## Using Mosh
+
+- To install it: `(apt|yum|brew) install mosh`
+
+- It has been pre-installed on the VMs that we are using
+
+- To connect to a remote machine: `mosh user@host`
+
+  (It is going to establish an SSH connection, then hand off to UDP)
+
+- It requires UDP ports to be open
+
+  (By default, it uses a UDP port between 60000 and 61000)
+
+.debug[[shared/prereqs.md](""/tree/main/slides/shared/prereqs.md)]
+---
+class: in-person
+
+## Connecting to our lab environment
+
+.lab[
+
+- Log into the first VM (`node1`) with your SSH client:
+  ```bash
+  ssh `user`@`A.B.C.D`
+  ```
+
+  (Replace `user` and `A.B.C.D` with the user and IP address provided to you)
+
+<!--
+```bash
+for N in $(awk '/\Wnode/{print $2}' /etc/hosts); do
+  ssh -o StrictHostKeyChecking=no $N true
+done
+```
+
+```bash
+### FIXME find a way to reset the cluster, maybe?
+```
+-->
+
+]
+
+You should see a prompt looking like this:
+```
+[A.B.C.D] (...) user@node1 ~
+$
+```
+If anything goes wrong — ask for help!
+
+.debug[[shared/connecting.md](""/tree/main/slides/shared/connecting.md)]
+---
+
+class: in-person
+
+## `tailhist`
+
+- The shell history of the instructor is available online in real time
+
+- Note the IP address of the instructor's virtual machine (A.B.C.D)
+
+- Open http://A.B.C.D:1088 in your browser and you should see the history
+
+- The history is updated in real time
+
+  (using a WebSocket connection)
+
+- It should be green when the WebSocket is connected
+
+  (if it turns red, reloading the page should fix it)
+
+.debug[[shared/connecting.md](""/tree/main/slides/shared/connecting.md)]
+---
+
+## Doing or re-doing the workshop on your own?
+
+- Use something like
+  [Play-With-Docker](http://play-with-docker.com/) or
+  [Play-With-Kubernetes](https://training.play-with-kubernetes.com/)
+
+  Zero setup effort; but environment are short-lived and
+  might have limited resources
+
+- Create your own cluster (local or cloud VMs)
+
+  Small setup effort; small cost; flexible environments
+
+- Create a bunch of clusters for you and your friends
+    ([instructions](https://github.com/jpetazzo/container.training/tree/master/prepare-vms))
+
+  Bigger setup effort; ideal for group training
+
+.debug[[shared/connecting.md](""/tree/main/slides/shared/connecting.md)]
+---
+
+## For a consistent Kubernetes experience ...
+
+- If you are using your own Kubernetes cluster, you can use [jpetazzo/shpod](https://github.com/jpetazzo/shpod)
+
+- `shpod` provides a shell running in a pod on your own cluster
+
+- It comes with many tools pre-installed (helm, stern...)
+
+- These tools are used in many demos and exercises in these slides
+
+- `shpod` also gives you completion and a fancy prompt
+
+- It can also be used as an SSH server if needed
+
+.debug[[shared/connecting.md](""/tree/main/slides/shared/connecting.md)]
+---
+
+class: self-paced
+
+## Get your own Docker nodes
+
+- If you already have some Docker nodes: great!
+
+- If not: let's get some thanks to Play-With-Docker
+
+.lab[
+
+- Go to http://www.play-with-docker.com/
+
+- Log in
+
+- Create your first node
+
+<!-- ```open http://www.play-with-docker.com/``` -->
+
+]
+
+You will need a Docker ID to use Play-With-Docker.
+
+(Creating a Docker ID is free.)
+
+.debug[[shared/connecting.md](""/tree/main/slides/shared/connecting.md)]
+---
+
+## We will (mostly) interact with node1 only
+
+*These remarks apply only when using multiple nodes, of course.*
+
+- Unless instructed, **all commands must be run from the first VM, `node1`**
+
+- We will only check out/copy the code on `node1`
+
+- During normal operations, we do not need access to the other nodes
+
+- If we had to troubleshoot issues, we would use a combination of:
+
+  - SSH (to access system logs, daemon status...)
+
+  - Docker API (to check running containers and container engine status)
+
+.debug[[shared/connecting.md](""/tree/main/slides/shared/connecting.md)]
+---
+
+## Terminals
+
+Once in a while, the instructions will say:
+<br/>"Open a new terminal."
+
+There are multiple ways to do this:
+
+- create a new window or tab on your machine, and SSH into the VM;
+
+- use screen or tmux on the VM and open a new window from there.
+
+You are welcome to use the method that you feel the most comfortable with.
+
+.debug[[shared/connecting.md](""/tree/main/slides/shared/connecting.md)]
+---
+
+## Tmux cheat sheet
+
+[Tmux](https://en.wikipedia.org/wiki/Tmux) is a terminal multiplexer like `screen`.
+
+*You don't have to use it or even know about it to follow along.
+<br/>
+But some of us like to use it to switch between terminals.
+<br/>
+It has been preinstalled on your workshop nodes.*
+
+- Ctrl-b c → creates a new window
+- Ctrl-b n → go to next window
+- Ctrl-b p → go to previous window
+- Ctrl-b " → split window top/bottom
+- Ctrl-b % → split window left/right
+- Ctrl-b Alt-1 → rearrange windows in columns
+- Ctrl-b Alt-2 → rearrange windows in rows
+- Ctrl-b arrows → navigate to other windows
+- Ctrl-b , → rename window
+- Ctrl-b d → detach session
+- tmux attach → re-attach to session
+
+.debug[[shared/connecting.md](""/tree/main/slides/shared/connecting.md)]
+---
+## Brand new versions!
+
+- Engine 18.09
+- Compose 1.23
+- Machine 0.16
+
+.lab[
+
+- Check all installed versions:
+  ```bash
+  docker version
+  docker-compose -v
+  docker-machine -v
+  ```
+
+]
+
+.debug[[swarm/versions.md](""/tree/main/slides/swarm/versions.md)]
+---
+
+## Wait, what, 18.09 ?!?
+
+--
+
+- Docker 1.13 = Docker 17.03 (year.month, like Ubuntu)
+
+- Every month, there is a new "edge" release (with new features)
+
+- Every quarter, there is a new "stable" release
+
+- Docker CE releases are maintained 4+ months
+
+- Docker EE releases are maintained 12+ months
+
+- For more details, check the [Docker EE announcement blog post](https://blog.docker.com/2017/03/docker-enterprise-edition/)
+
+.debug[[swarm/versions.md](""/tree/main/slides/swarm/versions.md)]
+---
+
+class: extra-details
+
+## Docker CE vs Docker EE
+
+- Docker EE:
+
+  - $$$
+  - certification for select distros, clouds, and plugins
+  - advanced management features (fine-grained access control, security scanning...)
+
+- Docker CE:
+
+  - free
+  - available through Docker Mac, Docker Windows, and major Linux distros
+  - perfect for individuals and small organizations
+
+.debug[[swarm/versions.md](""/tree/main/slides/swarm/versions.md)]
+---
+
+class: extra-details
+
+## Why?
+
+- More readable for enterprise users
+
+  (i.e. the very nice folks who are kind enough to pay us big $$$ for our stuff)
+
+- No impact for the community
+
+  (beyond CE/EE suffix and version numbering change)
+
+- Both trains leverage the same open source components
+
+  (containerd, libcontainer, SwarmKit...)
+
+- More predictable release schedule (see next slide)
+
+.debug[[swarm/versions.md](""/tree/main/slides/swarm/versions.md)]
+---
+
+class: pic
+
+![Docker CE/EE release cycle](images/docker-ce-ee-lifecycle.png)
+
+.debug[[swarm/versions.md](""/tree/main/slides/swarm/versions.md)]
+---
+
+## What was added when?
+
+||||
+| ---- | ----- | --- |
+| 2015 |  1.9  | Overlay (multi-host) networking, network/IPAM plugins
+| 2016 |  1.10 | Embedded dynamic DNS
+| 2016 |  1.11 | DNS round robin load balancing
+| 2016 |  1.12 | Swarm mode, routing mesh, encrypted networking, healthchecks
+| 2017 |  1.13 | Stacks, attachable overlays, image squash and compress
+| 2017 |  1.13 | Windows Server 2016 Swarm mode
+| 2017 | 17.03 | Secrets, encrypted Raft
+| 2017 | 17.04 | Update rollback, placement preferences (soft constraints)
+| 2017 | 17.06 | Swarm configs, node/service events, multi-stage build, service logs
+| 2017 | 17.06 | Windows Server 2016 Swarm overlay networks, secrets
+| 2017 | 17.09 | ADD/COPY chown, start\_period, stop-signal, overlay2 default
+| 2017 | 17.12 | containerd, Hyper-V isolation, Windows routing mesh
+| 2018 | 18.03 | Templates for secrets/configs, multi-yaml stacks, LCOW
+| 2018 | 18.03 | Stack deploy to Kubernetes, `docker trust`, tmpfs, manifest CLI
+
+.debug[[swarm/versions.md](""/tree/main/slides/swarm/versions.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]
+
+---
+
+name: toc-our-sample-application
+class: title
+
+ Our sample application
+
+.nav[
+[Previous part](#toc-pre-requirements)
+|
+[Back to table of contents](#toc-part-1)
+|
+[Next part](#toc-identifying-bottlenecks)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Our sample application
+
+- We will clone the GitHub repository onto our `node1`
+
+- The repository also contains scripts and tools that we will use through the workshop
+
+.lab[
+
+<!--
+```bash
+cd ~
+if [ -d container.training ]; then
+  mv container.training container.training.$RANDOM
+fi
+```
+-->
+
+- Clone the repository on `node1`:
+  ```bash
+  git clone https://github.com/jpetazzo/container.training
+  ```
+
+]
+
+(You can also fork the repository on GitHub and clone your fork if you prefer that.)
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## Downloading and running the application
+
+Let's start this before we look around, as downloading will take a little time...
+
+.lab[
+
+- Go to the `dockercoins` directory, in the cloned repository:
+  ```bash
+  cd ~/container.training/dockercoins
+  ```
+
+- Use Compose to build and run all containers:
+  ```bash
+  docker-compose up
+  ```
+
+<!--
+```longwait units of work done```
+-->
+
+]
+
+Compose tells Docker to build all container images (pulling
+the corresponding base images), then starts all containers,
+and displays aggregated logs.
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## What's this application?
+
+--
+
+- It is a DockerCoin miner! 💰🐳📦🚢
+
+--
+
+- No, you can't buy coffee with DockerCoin
+
+--
+
+- How dockercoins works:
+
+  - generate a few random bytes
+
+  - hash these bytes
+
+  - increment a counter (to keep track of speed)
+
+  - repeat forever!
+
+--
+
+- DockerCoin is *not* a cryptocurrency
+
+  (the only common points are "randomness," "hashing," and "coins" in the name)
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## DockerCoin in the microservices era
+
+- The dockercoins app is made of 5 services:
+
+  - `rng` = web service generating random bytes
+
+  - `hasher` = web service computing hash of POSTed data
+
+  - `worker` = background process calling `rng` and `hasher`
+
+  - `webui` = web interface to watch progress
+
+  - `redis` = data store (holds a counter updated by `worker`)
+
+- These 5 services are visible in the application's Compose file,
+  [docker-compose.yml](
+  https://github.com/jpetazzo/container.training/blob/master/dockercoins/docker-compose.yml)
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## How dockercoins works
+
+- `worker` invokes web service `rng` to generate random bytes
+
+- `worker` invokes web service `hasher` to hash these bytes
+
+- `worker` does this in an infinite loop
+
+- every second, `worker` updates `redis` to indicate how many loops were done
+
+- `webui` queries `redis`, and computes and exposes "hashing speed" in our browser
+
+*(See diagram on next slide!)*
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+class: pic
+
+![Diagram showing the 5 containers of the applications](images/dockercoins-diagram.png)
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## Service discovery in container-land
+
+How does each service find out the address of the other ones?
+
+--
+
+- We do not hard-code IP addresses in the code
+
+- We do not hard-code FQDNs in the code, either
+
+- We just connect to a service name, and container-magic does the rest
+
+  (And by container-magic, we mean "a crafty, dynamic, embedded DNS server")
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## Example in `worker/worker.py`
+
+```python
+redis = Redis("`redis`")
+
+
+def get_random_bytes():
+    r = requests.get("http://`rng`/32")
+    return r.content
+
+
+def hash_bytes(data):
+    r = requests.post("http://`hasher`/",
+                      data=data,
+                      headers={"Content-Type": "application/octet-stream"})
+```
+
+(Full source code available [here](
+https://github.com/jpetazzo/container.training/blob/8279a3bce9398f7c1a53bdd95187c53eda4e6435/dockercoins/worker/worker.py#L17
+))
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+class: extra-details
+
+## Links, naming, and service discovery
+
+- Containers can have network aliases (resolvable through DNS)
+
+- Compose file version 2+ makes each container reachable through its service name
+
+- Compose file version 1 required "links" sections to accomplish this
+
+- Network aliases are automatically namespaced
+
+  - you can have multiple apps declaring and using a service named `database`
+
+  - containers in the blue app will resolve `database` to the IP of the blue database
+
+  - containers in the green app will resolve `database` to the IP of the green database
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## Show me the code!
+
+- You can check the GitHub repository with all the materials of this workshop:
+  <br/>https://github.com/jpetazzo/container.training
+
+- The application is in the [dockercoins](
+  https://github.com/jpetazzo/container.training/tree/master/dockercoins)
+  subdirectory
+
+- The Compose file ([docker-compose.yml](
+  https://github.com/jpetazzo/container.training/blob/master/dockercoins/docker-compose.yml))
+  lists all 5 services
+
+- `redis` is using an official image from the Docker Hub
+
+- `hasher`, `rng`, `worker`, `webui` are each built from a Dockerfile
+
+- Each service's Dockerfile and source code is in its own directory
+
+  (`hasher` is in the [hasher](https://github.com/jpetazzo/container.training/blob/master/dockercoins/hasher/) directory,
+  `rng` is in the [rng](https://github.com/jpetazzo/container.training/blob/master/dockercoins/rng/)
+  directory, etc.)
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+class: extra-details
+
+## Compose file format version
+
+*This is relevant only if you have used Compose before 2016...*
+
+- Compose 1.6 introduced support for a new Compose file format (aka "v2")
+
+- Services are no longer at the top level, but under a `services` section
+
+- There has to be a `version` key at the top level, with value `"2"` (as a string, not an integer)
+
+- Containers are placed on a dedicated network, making links unnecessary
+
+- There are other minor differences, but upgrade is easy and straightforward
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## Our application at work
+
+- On the left-hand side, the "rainbow strip" shows the container names
+
+- On the right-hand side, we see the output of our containers
+
+- We can see the `worker` service making requests to `rng` and `hasher`
+
+- For `rng` and `hasher`, we see HTTP access logs
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## Connecting to the web UI
+
+- "Logs are exciting and fun!" (No-one, ever)
+
+- The `webui` container exposes a web dashboard; let's view it
+
+.lab[
+
+- With a web browser, connect to `node1` on port 8000
+
+- Remember: the `nodeX` aliases are valid only on the nodes themselves
+
+- In your browser, you need to enter the IP address of your node
+
+<!-- ```open http://node1:8000``` -->
+
+]
+
+A drawing area should show up, and after a few seconds, a blue
+graph will appear.
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+class: self-paced, extra-details
+
+## If the graph doesn't load
+
+If you just see a `Page not found` error, it might be because your
+Docker Engine is running on a different machine. This can be the case if:
+
+- you are using the Docker Toolbox
+
+- you are using a VM (local or remote) created with Docker Machine
+
+- you are controlling a remote Docker Engine
+
+When you run DockerCoins in development mode, the web UI static files
+are mapped to the container using a volume. Alas, volumes can only
+work on a local environment, or when using Docker Desktop for Mac or Windows.
+
+How to fix this?
+
+Stop the app with `^C`, edit `dockercoins.yml`, comment out the `volumes` section, and try again.
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+class: extra-details
+
+## Why does the speed seem irregular?
+
+- It *looks like* the speed is approximately 4 hashes/second
+
+- Or more precisely: 4 hashes/second, with regular dips down to zero
+
+- Why?
+
+--
+
+class: extra-details
+
+- The app actually has a constant, steady speed: 3.33 hashes/second
+  <br/>
+  (which corresponds to 1 hash every 0.3 seconds, for *reasons*)
+
+- Yes, and?
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+class: extra-details
+
+## The reason why this graph is *not awesome*
+
+- The worker doesn't update the counter after every loop, but up to once per second
+
+- The speed is computed by the browser, checking the counter about once per second
+
+- Between two consecutive updates, the counter will increase either by 4, or by 0
+
+- The perceived speed will therefore be 4 - 4 - 4 - 0 - 4 - 4 - 0 etc.
+
+- What can we conclude from this?
+
+--
+
+class: extra-details
+
+- "I'm clearly incapable of writing good frontend code!" 😀 — Jérôme
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+
+## Stopping the application
+
+- If we interrupt Compose (with `^C`), it will politely ask the Docker Engine to stop the app
+
+- The Docker Engine will send a `TERM` signal to the containers
+
+- If the containers do not exit in a timely manner, the Engine sends a `KILL` signal
+
+.lab[
+
+- Stop the application by hitting `^C`
+
+<!--
+```key ^C```
+-->
+
+]
+
+--
+
+Some containers exit immediately, others take longer.
+
+The containers that do not handle `SIGTERM` end up being killed after a 10s timeout. If we are very impatient, we can hit `^C` a second time!
+
+
+.debug[[shared/sampleapp.md](""/tree/main/slides/shared/sampleapp.md)]
+---
+## Restarting in the background
+
+- Many flags and commands of Compose are modeled after those of `docker`
+
+.lab[
+
+- Start the app in the background with the `-d` option:
+  ```bash
+  docker-compose up -d
+  ```
+
+- Check that our app is running with the `ps` command:
+  ```bash
+  docker-compose ps
+  ```
+
+]
+
+`docker-compose ps` also shows the ports exposed by the application.
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+
+class: extra-details
+
+## Viewing logs
+
+- The `docker-compose logs` command works like `docker logs`
+
+.lab[
+
+- View all logs since container creation and exit when done:
+  ```bash
+  docker-compose logs
+  ```
+
+- Stream container logs, starting at the last 10 lines for each container:
+  ```bash
+  docker-compose logs --tail 10 --follow
+  ```
+
+<!--
+```wait units of work done```
+```key ^C```
+-->
+
+]
+
+Tip: use `^S` and `^Q` to pause/resume log output.
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+
+## Scaling up the application
+
+- Our goal is to make that performance graph go up (without changing a line of code!)
+
+--
+
+- Before trying to scale the application, we'll figure out if we need more resources
+
+  (CPU, RAM...)
+
+- For that, we will use good old UNIX tools on our Docker node
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+
+## Looking at resource usage
+
+- Let's look at CPU, memory, and I/O usage
+
+.lab[
+
+- run `top` to see CPU and memory usage (you should see idle cycles)
+
+<!--
+```bash top```
+
+```wait Tasks```
+```key ^C```
+-->
+
+- run `vmstat 1` to see I/O usage (si/so/bi/bo)
+  <br/>(the 4 numbers should be almost zero, except `bo` for logging)
+
+<!--
+```bash vmstat 1```
+
+```wait memory```
+```key ^C```
+-->
+
+]
+
+We have available resources.
+
+- Why?
+- How can we use them?
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+
+## Scaling workers on a single node
+
+- Docker Compose supports scaling
+- Let's scale `worker` and see what happens!
+
+.lab[
+
+- Start one more `worker` container:
+  ```bash
+  docker-compose up -d --scale worker=2
+  ```
+
+- Look at the performance graph (it should show a x2 improvement)
+
+- Look at the aggregated logs of our containers (`worker_2` should show up)
+
+- Look at the impact on CPU load with e.g. top (it should be negligible)
+
+]
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+
+## Adding more workers
+
+- Great, let's add more workers and call it a day, then!
+
+.lab[
+
+- Start eight more `worker` containers:
+  ```bash
+  docker-compose up -d --scale worker=10
+  ```
+
+- Look at the performance graph: does it show a x10 improvement?
+
+- Look at the aggregated logs of our containers
+
+- Look at the impact on CPU load and memory usage
+
+]
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg)]
+
+---
+
+name: toc-identifying-bottlenecks
+class: title
+
+ Identifying bottlenecks
+
+.nav[
+[Previous part](#toc-our-sample-application)
+|
+[Back to table of contents](#toc-part-1)
+|
+[Next part](#toc-swarmkit)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+
+# Identifying bottlenecks
+
+- You should have seen a 3x speed bump (not 10x)
+
+- Adding workers didn't result in linear improvement
+
+- *Something else* is slowing us down
+
+--
+
+- ... But what?
+
+--
+
+- The code doesn't have instrumentation
+
+- Let's use state-of-the-art HTTP performance analysis!
+  <br/>(i.e. good old tools like `ab`, `httping`...)
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+
+## Accessing internal services
+
+- `rng` and `hasher` are exposed on ports 8001 and 8002
+
+- This is declared in the Compose file:
+
+  ```yaml
+    ...
+    rng:
+      build: rng
+      ports:
+      - "8001:80"
+
+    hasher:
+      build: hasher
+      ports:
+      - "8002:80"
+    ...
+  ```
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+
+## Measuring latency under load
+
+We will use `httping`.
+
+.lab[
+
+- Check the latency of `rng`:
+  ```bash
+  httping -c 3 localhost:8001
+  ```
+
+- Check the latency of `hasher`:
+  ```bash
+  httping -c 3 localhost:8002
+  ```
+
+]
+
+`rng` has a much higher latency than `hasher`.
+
+.debug[[shared/composescale.md](""/tree/main/slides/shared/composescale.md)]
+---
+## Let's draw hasty conclusions
+
+- The bottleneck seems to be `rng`
+
+- *What if* we don't have enough entropy and can't generate enough random numbers?
+
+- We need to scale out the `rng` service on multiple machines!
+
+Note: this is a fiction! We have enough entropy. But we need a pretext to scale out.
+
+(In fact, the code of `rng` uses `/dev/urandom`, which never runs out of entropy...
+<br/>
+...and is [just as good as `/dev/random`](http://www.slideshare.net/PacSecJP/filippo-plain-simple-reality-of-entropy).)
+
+.debug[[shared/hastyconclusions.md](""/tree/main/slides/shared/hastyconclusions.md)]
+---
+## Clean up
+
+- Before moving on, let's remove those containers
+
+.lab[
+
+- Tell Compose to remove everything:
+  ```bash
+  docker-compose down
+  ```
+
+]
+
+.debug[[shared/composedown.md](""/tree/main/slides/shared/composedown.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg)]
+
+---
+
+name: toc-swarmkit
+class: title
+
+ SwarmKit
+
+.nav[
+[Previous part](#toc-identifying-bottlenecks)
+|
+[Back to table of contents](#toc-part-1)
+|
+[Next part](#toc-declarative-vs-imperative)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# SwarmKit
+
+- [SwarmKit](https://github.com/docker/swarmkit) is an open source
+  toolkit to build multi-node systems
+
+- It is a reusable library, like libcontainer, libnetwork, vpnkit ...
+
+- It is a plumbing part of the Docker ecosystem
+
+--
+
+.footnote[🐳 Did you know that кит means "whale" in Russian?]
+
+.debug[[swarm/swarmkit.md](""/tree/main/slides/swarm/swarmkit.md)]
+---
+
+## SwarmKit features
+
+- Highly-available, distributed store based on [Raft](
+  https://en.wikipedia.org/wiki/Raft_%28computer_science%29)
+  <br/>(avoids depending on an external store: easier to deploy; higher performance)
+
+- Dynamic reconfiguration of Raft without interrupting cluster operations
+
+- *Services* managed with a *declarative API*
+  <br/>(implementing *desired state* and *reconciliation loop*)
+
+- Integration with overlay networks and load balancing
+
+- Strong emphasis on security:
+
+  - automatic TLS keying and signing; automatic cert rotation
+  - full encryption of the data plane; automatic key rotation
+  - least privilege architecture (single-node compromise ≠ cluster compromise)
+  - on-disk encryption with optional passphrase
+
+.debug[[swarm/swarmkit.md](""/tree/main/slides/swarm/swarmkit.md)]
+---
+
+class: extra-details
+
+## Where is the key/value store?
+
+- Many orchestration systems use a key/value store backed by a consensus algorithm
+  <br/>
+  (k8s→etcd→Raft, mesos→zookeeper→ZAB, etc.)
+
+- SwarmKit implements the Raft algorithm directly
+  <br/>
+  (Nomad is similar; thanks [@cbednarski](https://twitter.com/@cbednarski),
+  [@diptanu](https://twitter.com/diptanu) and others for pointing it out!)
+
+- Analogy courtesy of [@aluzzardi](https://twitter.com/aluzzardi):
+
+  *It's like B-Trees and RDBMS. They are different layers, often
+  associated. But you don't need to bring up a full SQL server when
+  all you need is to index some data.*
+
+- As a result, the orchestrator has direct access to the data
+  <br/>
+  (the main copy of the data is stored in the orchestrator's memory)
+
+- Simpler, easier to deploy and operate; also faster
+
+.debug[[swarm/swarmkit.md](""/tree/main/slides/swarm/swarmkit.md)]
+---
+
+## SwarmKit concepts (1/2)
+
+- A *cluster* will be at least one *node* (preferably more)
+
+- A *node* can be a *manager* or a *worker*
+
+- A *manager* actively takes part in the Raft consensus, and keeps the Raft log
+
+- You can talk to a *manager* using the SwarmKit API
+
+- One *manager* is elected as the *leader*; other managers merely forward requests to it
+
+- The *workers* get their instructions from the *managers*
+
+- Both *workers* and *managers* can run containers
+
+.debug[[swarm/swarmkit.md](""/tree/main/slides/swarm/swarmkit.md)]
+---
+
+## Illustration
+
+On the next slide:
+
+- whales = nodes (workers and managers)
+
+- monkeys = managers
+
+- purple monkey = leader
+
+- grey monkeys = followers
+
+- dotted triangle = raft protocol
+
+.debug[[swarm/swarmkit.md](""/tree/main/slides/swarm/swarmkit.md)]
+---
+
+class: pic
+
+![Illustration](images/swarm-mode.svg)
+
+.debug[[swarm/swarmkit.md](""/tree/main/slides/swarm/swarmkit.md)]
+---
+
+## SwarmKit concepts (2/2)
+
+- The *managers* expose the SwarmKit API
+
+- Using the API, you can indicate that you want to run a *service*
+
+- A *service* is specified by its *desired state*: which image, how many instances...
+
+- The *leader* uses different subsystems to break down services into *tasks*:
+  <br/>orchestrator, scheduler, allocator, dispatcher
+
+- A *task* corresponds to a specific container, assigned to a specific *node*
+
+- *Nodes* know which *tasks* should be running, and will start or stop containers accordingly (through the Docker Engine API)
+
+You can refer to the [NOMENCLATURE](https://github.com/docker/swarmkit/blob/master/design/nomenclature.md) in the SwarmKit repo for more details.
+
+.debug[[swarm/swarmkit.md](""/tree/main/slides/swarm/swarmkit.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg)]
+
+---
+
+name: toc-declarative-vs-imperative
+class: title
+
+ Declarative vs imperative
+
+.nav[
+[Previous part](#toc-swarmkit)
+|
+[Back to table of contents](#toc-part-1)
+|
+[Next part](#toc-swarm-mode)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Declarative vs imperative
+
+- Our container orchestrator puts a very strong emphasis on being *declarative*
+
+- Declarative:
+
+  *I would like a cup of tea.*
+
+- Imperative:
+
+  *Boil some water. Pour it in a teapot. Add tea leaves. Steep for a while. Serve in a cup.*
+
+--
+
+- Declarative seems simpler at first ... 
+
+--
+
+- ... As long as you know how to brew tea
+
+.debug[[shared/declarative.md](""/tree/main/slides/shared/declarative.md)]
+---
+
+## Declarative vs imperative
+
+- What declarative would really be:
+
+  *I want a cup of tea, obtained by pouring an infusion¹ of tea leaves in a cup.*
+
+--
+
+  *¹An infusion is obtained by letting the object steep a few minutes in hot² water.*
+
+--
+
+  *²Hot liquid is obtained by pouring it in an appropriate container³ and setting it on a stove.*
+
+--
+
+  *³Ah, finally, containers! Something we know about. Let's get to work, shall we?*
+
+--
+
+.footnote[Did you know there was an [ISO standard](https://en.wikipedia.org/wiki/ISO_3103)
+specifying how to brew tea?]
+
+.debug[[shared/declarative.md](""/tree/main/slides/shared/declarative.md)]
+---
+
+## Declarative vs imperative
+
+- Imperative systems:
+
+  - simpler
+
+  - if a task is interrupted, we have to restart from scratch
+
+- Declarative systems:
+
+  - if a task is interrupted (or if we show up to the party half-way through),
+    we can figure out what's missing and do only what's necessary
+
+  - we need to be able to *observe* the system
+
+  - ... and compute a "diff" between *what we have* and *what we want*
+
+.debug[[shared/declarative.md](""/tree/main/slides/shared/declarative.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg)]
+
+---
+
+name: toc-swarm-mode
+class: title
+
+ Swarm mode
+
+.nav[
+[Previous part](#toc-declarative-vs-imperative)
+|
+[Back to table of contents](#toc-part-1)
+|
+[Next part](#toc-creating-our-first-swarm)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Swarm mode
+
+- Since version 1.12, the Docker Engine embeds SwarmKit
+
+- All the SwarmKit features are "asleep" until you enable "Swarm mode"
+
+- Examples of Swarm Mode commands:
+
+  - `docker swarm` (enable Swarm mode; join a Swarm; adjust cluster parameters)
+
+  - `docker node` (view nodes; promote/demote managers; manage nodes)
+
+  - `docker service` (create and manage services)
+
+???
+
+- The Docker API exposes the same concepts
+
+- The SwarmKit API is also exposed (on a separate socket)
+
+.debug[[swarm/swarmmode.md](""/tree/main/slides/swarm/swarmmode.md)]
+---
+
+## Swarm mode needs to be explicitly activated
+
+- By default, all this new code is inactive
+
+- Swarm mode can be enabled, "unlocking" SwarmKit functions
+  <br/>(services, out-of-the-box overlay networks, etc.)
+
+.lab[
+
+- Try a Swarm-specific command:
+  ```bash
+  docker node ls
+  ```
+
+<!-- Ignore errors: ```wait not a swarm manager``` -->
+
+]
+
+--
+
+You will get an error message:
+```
+Error response from daemon: This node is not a swarm manager. [...]
+```
+
+.debug[[swarm/swarmmode.md](""/tree/main/slides/swarm/swarmmode.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-housing.jpg)]
+
+---
+
+name: toc-creating-our-first-swarm
+class: title
+
+ Creating our first Swarm
+
+.nav[
+[Previous part](#toc-swarm-mode)
+|
+[Back to table of contents](#toc-part-1)
+|
+[Next part](#toc-running-our-first-swarm-service)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Creating our first Swarm
+
+- The cluster is initialized with `docker swarm init`
+
+- This should be executed on a first, seed node
+
+- .warning[DO NOT execute `docker swarm init` on multiple nodes!]
+
+  You would have multiple disjoint clusters.
+
+.lab[
+
+- Create our cluster from node1:
+  ```bash
+  docker swarm init
+  ```
+
+]
+
+--
+
+class: advertise-addr
+
+If Docker tells you that it `could not choose an IP address to advertise`, see next slide!
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: advertise-addr
+
+## IP address to advertise
+
+- When running in Swarm mode, each node *advertises* its address to the others
+  <br/>
+  (i.e. it tells them *"you can contact me on 10.1.2.3:2377"*)
+
+- If the node has only one IP address, it is used automatically
+  <br/>
+  (The addresses of the loopback interface and the Docker bridge are ignored)
+
+- If the node has multiple IP addresses, you **must** specify which one to use
+  <br/>
+  (Docker refuses to pick one randomly)
+
+- You can specify an IP address or an interface name
+  <br/>
+  (in the latter case, Docker will read the IP address of the interface and use it)
+
+- You can also specify a port number
+  <br/>
+  (otherwise, the default port 2377 will be used)
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: advertise-addr
+
+## Using a non-default port number
+
+- Changing the *advertised* port does not change the *listening* port
+
+- If you only pass `--advertise-addr eth0:7777`, Swarm will still listen on port 2377
+
+- You will probably need to pass `--listen-addr eth0:7777` as well
+
+- This is to accommodate scenarios where these ports *must* be different
+  <br/>
+  (port mapping, load balancers...)
+
+Example to run Swarm on a different port:
+
+```bash
+docker swarm init --advertise-addr eth0:7777 --listen-addr eth0:7777
+```
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: advertise-addr
+
+## Which IP address should be advertised?
+
+- If your nodes have only one IP address, it's safe to let autodetection do the job
+
+  .small[(Except if your instances have different private and public addresses, e.g.
+  on EC2, and you are building a Swarm involving nodes inside and outside the
+  private network: then you should advertise the public address.)]
+
+- If your nodes have multiple IP addresses, pick an address which is reachable
+  *by every other node* of the Swarm
+
+- If you are using [play-with-docker](http://play-with-docker.com/), use the IP
+  address shown next to the node name
+
+  .small[(This is the address of your node on your private internal overlay network.
+  The other address that you might see is the address of your node on the
+  `docker_gwbridge` network, which is used for outbound traffic.)]
+
+Examples:
+
+```bash
+docker swarm init --advertise-addr 172.24.0.2
+docker swarm init --advertise-addr eth0
+```
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: extra-details
+
+## Using a separate interface for the data path
+
+- You can use different interfaces (or IP addresses) for control and data
+
+- You set the _control plane path_ with `--advertise-addr` and `--listen-addr`
+
+  (This will be used for SwarmKit manager/worker communication, leader election, etc.)
+
+- You set the _data plane path_ with `--data-path-addr`
+
+  (This will be used for traffic between containers)
+
+- Both flags can accept either an IP address, or an interface name
+
+  (When specifying an interface name, Docker will use its first IP address)
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+## Token generation
+
+- In the output of `docker swarm init`, we have a message
+  confirming that our node is now the (single) manager:
+
+  ```
+  Swarm initialized: current node (8jud...) is now a manager.
+  ```
+
+- Docker generated two security tokens (like passphrases or passwords) for our cluster
+
+- The CLI shows us the command to use on other nodes to add them to the cluster using the "worker"
+  security token:
+
+  ```
+    To add a worker to this swarm, run the following command:
+      docker swarm join \
+      --token SWMTKN-1-59fl4ak4nqjmao1ofttrc4eprhrola2l87... \
+      172.31.4.182:2377
+  ```
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: extra-details
+
+## Checking that Swarm mode is enabled
+
+.lab[
+
+- Run the traditional `docker info` command:
+  ```bash
+  docker info
+  ```
+
+]
+
+The output should include:
+
+```
+Swarm: active
+ NodeID: 8jud7o8dax3zxbags3f8yox4b
+ Is Manager: true
+ ClusterID: 2vcw2oa9rjps3a24m91xhvv0c
+ ...
+```
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+## Running our first Swarm mode command
+
+- Let's retry the exact same command as earlier
+
+.lab[
+
+- List the nodes (well, the only node) of our cluster:
+  ```bash
+  docker node ls
+  ```
+
+]
+
+The output should look like the following:
+```
+ID             HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
+8jud...ox4b *  node1     Ready   Active        Leader
+```
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+## Adding nodes to the Swarm
+
+- A cluster with one node is not a lot of fun
+
+- Let's add `node2`!
+
+- We need the token that was shown earlier
+
+--
+
+- You wrote it down, right?
+
+--
+
+- Don't panic, we can easily see it again 😏
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+## Adding nodes to the Swarm
+
+.lab[
+
+- Show the token again:
+  ```bash
+  docker swarm join-token worker
+  ```
+
+- Log into `node2`:
+  ```bash
+  ssh node2
+  ```
+
+- Copy-paste the `docker swarm join ...` command
+  <br/>(that was displayed just before)
+
+<!-- ```copypaste docker swarm join --token SWMTKN.*?:2377``` -->
+
+]
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: extra-details
+
+## Check that the node was added correctly
+
+- Stay on `node2` for now!
+
+.lab[
+
+- We can still use `docker info` to verify that the node is part of the Swarm:
+  ```bash
+  docker info | grep ^Swarm
+  ```
+
+]
+
+- However, Swarm commands will not work; try, for instance:
+  ```bash
+  docker node ls
+  ```
+
+<!-- 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
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+## View our two-node cluster
+
+- Let's go back to `node1` and see what our cluster looks like
+
+.lab[
+
+- Switch back to `node1` (with `exit`, `Ctrl-D` ...)
+
+<!-- ```key ^D``` -->
+
+- View the cluster from `node1`, which is a manager:
+  ```bash
+  docker node ls
+  ```
+
+]
+
+The output should be similar to the following:
+```
+ID             HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
+8jud...ox4b *  node1     Ready   Active        Leader
+ehb0...4fvx    node2     Ready   Active
+```
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: under-the-hood
+
+## Under the hood: docker swarm init
+
+When we do `docker swarm init`:
+
+- a keypair is created for the root CA of our Swarm
+
+- a keypair is created for the first node
+
+- a certificate is issued for this node
+
+- the join tokens are created
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+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*.
+
+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>
+```
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: under-the-hood
+
+## 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)
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: under-the-hood
+
+## Under the hood: cluster communication
+
+- The *control plane* is encrypted with AES-GCM; keys are rotated every 12 hours
+
+- Authentication is done with mutual TLS; certificates are rotated every 90 days
+
+  (`docker swarm update` allows to change this delay or to use an external CA)
+
+- 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)
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+
+class: under-the-hood
+
+## 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](https://www.slideshare.net/Docker/heart-of-the-swarmkit-store-topology-object-model))
+  ([video](https://www.youtube.com/watch?v=EmePhjGnCXY))
+
+And DockerCon Black Belt talks:
+
+.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))]
+
+
+.debug[[swarm/creatingswarm.md](""/tree/main/slides/swarm/creatingswarm.md)]
+---
+## Adding more manager nodes
+
+- Right now, we have only one manager (node1)
+
+- If we lose it, we lose quorum - and that's *very bad!*
+
+- Containers running on other nodes will be fine ...
+
+- But we won't be able to get or set anything related to the cluster
+
+- If the manager is permanently gone, we will have to do a manual repair!
+
+- Nobody wants to do that ... so let's make our cluster highly available
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+class: self-paced
+
+## Adding more managers
+
+With Play-With-Docker:
+
+```bash
+TOKEN=$(docker swarm join-token -q manager)
+for N in $(seq 3 5); do
+  export DOCKER_HOST=tcp://node$N:2375
+  docker swarm join --token $TOKEN node1:2377
+done
+unset DOCKER_HOST
+```
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+class: in-person
+
+## Building our full cluster
+
+- Let's get the token, and use a one-liner for the remaining node with SSH
+
+.lab[
+
+- Obtain the manager token:
+  ```bash
+  TOKEN=$(docker swarm join-token -q manager)
+  ```
+
+- Add the remaining node:
+  ```bash
+    ssh node3 docker swarm join --token $TOKEN node1:2377
+  ```
+
+]
+
+[That was easy.](https://www.youtube.com/watch?v=3YmMNpbFjp0)
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+## Controlling the Swarm from other nodes
+
+.lab[
+
+- Try the following command on a few different nodes:
+  ```bash
+  docker node ls
+  ```
+
+]
+
+On manager nodes:
+<br/>you will see the list of nodes, with a `*` denoting
+the node you're talking to.
+
+On non-manager nodes:
+<br/>you will get an error message telling you that
+the node is not a manager.
+
+As we saw earlier, you can only control the Swarm through a manager node.
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+class: self-paced
+
+## Play-With-Docker node status icon
+
+- If you're using Play-With-Docker, you get node status icons
+
+- Node status icons are displayed left of the node name
+
+  - No icon = no Swarm mode detected
+  - Solid blue icon = Swarm manager detected
+  - Blue outline icon = Swarm worker detected
+
+![Play-With-Docker icons](images/pwd-icons.png)
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+## Dynamically changing the role of a node
+
+- We can change the role of a node on the fly:
+
+  `docker node promote nodeX` → make nodeX a manager
+  <br/>
+  `docker node demote nodeX` → make nodeX a worker
+
+.lab[
+
+- See the current list of nodes:
+  ```
+  docker node ls
+  ```
+
+- Promote any worker node to be a manager:
+  ```
+  docker node promote <node_name_or_id>
+  ```
+
+]
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+## How many managers do we need?
+
+- 2N+1 nodes can (and will) tolerate N failures
+  <br/>(you can have an even number of managers, but there is no point)
+
+--
+
+- 1 manager = no failure
+
+- 3 managers = 1 failure
+
+- 5 managers = 2 failures (or 1 failure during 1 maintenance)
+
+- 7 managers and more = now you might be overdoing it for most designs
+
+.footnote[
+
+ see [Docker's admin guide](https://docs.docker.com/engine/swarm/admin_guide/#add-manager-nodes-for-fault-tolerance) 
+ on node failure and datacenter redundancy
+
+]
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+## Why not have *all* nodes be managers?
+
+- With Raft, writes have to go to (and be acknowledged by) all nodes
+
+- Thus, it's harder to reach consensus in larger groups
+
+- Only one manager is Leader (writable), so more managers ≠ more capacity
+
+- Managers should be &#60; 10ms latency from each other
+
+- These design parameters lead us to recommended designs
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+## What would McGyver do?
+
+- Keep managers in one region (multi-zone/datacenter/rack)
+
+- Groups of 3 or 5 nodes: all are managers. Beyond 5, separate out managers and workers
+
+- Groups of 10-100 nodes: pick 5 "stable" nodes to be managers
+
+- Groups of more than 100 nodes: watch your managers' CPU and RAM
+
+  - 16GB memory or more, 4 CPU's or more, SSD's for Raft I/O
+  - otherwise, break down your nodes in multiple smaller clusters
+
+.footnote[
+
+  Cloud pro-tip: use separate auto-scaling groups for managers and workers
+
+  See docker's "[Running Docker at scale](https://success.docker.com/article/running-docker-ee-at-scale)" document
+]
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+## What's the upper limit?
+
+- We don't know!
+
+- Internal testing at Docker Inc.: 1000-10000 nodes is fine
+
+  - deployed to a single cloud region
+
+  - one of the main take-aways was *"you're gonna need a bigger manager"*
+
+- Testing by the community: [4700 heterogeneous nodes all over the 'net](https://sematext.com/blog/2016/11/14/docker-swarm-lessons-from-swarm3k/)
+
+  - it just works, assuming they have the resources
+
+  - more nodes require manager CPU and networking; more containers require RAM
+
+  - scheduling of large jobs (70,000 containers) is slow, though ([getting better](https://github.com/moby/moby/pull/37372)!)
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+## 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/)
+
+.debug[[swarm/morenodes.md](""/tree/main/slides/swarm/morenodes.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/containers-by-the-water.jpg)]
+
+---
+
+name: toc-running-our-first-swarm-service
+class: title
+
+ Running our first Swarm service
+
+.nav[
+[Previous part](#toc-creating-our-first-swarm)
+|
+[Back to table of contents](#toc-part-2)
+|
+[Next part](#toc-our-app-on-swarm)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Running our first Swarm service
+
+- How do we run services? Simplified version:
+
+  `docker run` → `docker service create`
+
+.lab[
+
+- Create a service featuring an Alpine container pinging Google resolvers:
+  ```bash
+  docker service create --name pingpong alpine ping 8.8.8.8
+  ```
+
+- Check the result:
+  ```bash
+  docker service ps pingpong
+  ```
+
+]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Checking service logs
+
+(New in Docker Engine 17.05)
+
+- Just like `docker logs` shows the output of a specific local container ...
+
+- ... `docker service logs` shows the output of all the containers of a specific service
+
+.lab[
+
+- Check the output of our ping command:
+  ```bash
+  docker service logs pingpong
+  ```
+
+]
+
+Flags `--follow` and `--tail` are available, as well as a few others.
+
+Note: by default, when a container is destroyed (e.g. when scaling down), its logs are lost.
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: extra-details
+
+## Looking up where our container is running
+
+- The `docker service ps` command told us where our container was scheduled
+
+.lab[
+
+- Look up the `NODE` on which the container is running:
+  ```bash
+  docker service ps pingpong
+  ```
+
+- If you use Play-With-Docker, switch to that node's tab, or set `DOCKER_HOST`
+
+- Otherwise, `ssh` into that node or use `$(eval docker-machine env node...)`
+
+]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: extra-details
+
+## Viewing the logs of the container
+
+.lab[
+
+- See that the container is running and check its ID:
+  ```bash
+  docker ps
+  ```
+
+- View its logs:
+  ```bash
+  docker logs containerID
+  ```
+
+  <!-- ```wait No such container: containerID``` -->
+
+- Go back to `node1` afterwards
+
+]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Scale our service
+
+- Services can be scaled in a pinch with the `docker service update` command
+
+.lab[
+
+- Scale the service to ensure 2 copies per node:
+  ```bash
+  docker service update pingpong --replicas 6
+  ```
+
+- Check that we have two containers on the current node:
+  ```bash
+  docker ps
+  ```
+
+]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Monitoring deployment progress with `--detach`
+
+(New in Docker Engine 17.10)
+
+- The CLI monitors commands that create/update/delete services
+
+- In effect, `--detach=false` is the default
+
+  - synchronous operation
+  - the CLI will monitor and display the progress of our request
+  - it exits only when the operation is complete
+  - Ctrl-C to detach at anytime
+
+- `--detach=true`
+
+  - asynchronous operation
+  - the CLI just submits our request
+  - it exits as soon as the request is committed into Raft
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## To `--detach` or not to `--detach`
+
+- `--detach=false`
+
+  - great when experimenting, to see what's going on
+
+  - also great when orchestrating complex deployments
+    <br/>(when you want to wait for a service to be ready before starting another)
+
+- `--detach=true`
+
+  - great for independent operations that can be parallelized
+
+  - great in headless scripts (where nobody's watching anyway)
+
+.warning[`--detach=true` does not complete *faster*. It just *doesn't wait* for completion.]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: extra-details
+
+## `--detach` over time
+
+- Docker Engine 17.10 and later: the default is `--detach=false`
+
+- From Docker Engine 17.05 to 17.09: the default is `--detach=true`
+
+- Prior to Docker 17.05: `--detach` doesn't exist
+
+ (You can watch progress with e.g. `watch docker service ps <serviceID>`)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## `--detach` in action
+
+.lab[
+
+- Scale the service to ensure 3 copies per node:
+  ```bash
+  docker service update pingpong --replicas 9 --detach=false
+  ```
+
+- And then to 4 copies per node:
+  ```bash
+  docker service update pingpong --replicas 12 --detach=true
+  ```
+
+]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Expose a service
+
+- Services can be exposed, with two special properties:
+
+  - the public port is available on *every node of the Swarm*,
+
+  - requests coming on the public port are load balanced across all instances.
+
+- This is achieved with option `-p/--publish`; as an approximation:
+
+  `docker run -p → docker service create -p`
+
+- If you indicate a single port number, it will be mapped on a port
+  starting at 30000
+  <br/>(vs. 32768 for single container mapping)
+
+- You can indicate two port numbers to set the public port number
+  <br/>(just like with `docker run -p`)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Expose ElasticSearch on its default port
+
+.lab[
+
+- Create an ElasticSearch service (and give it a name while we're at it):
+  ```bash
+  docker service create --name search --publish 9200:9200 --replicas 5 \
+         elasticsearch`:2`
+  ```
+
+]
+
+Note: don't forget the **:2**!
+
+The latest version of the ElasticSearch image won't start without mandatory configuration.
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Tasks lifecycle
+
+- During the deployment, you will be able to see multiple states:
+
+  - assigned (the task has been assigned to a specific node)
+
+  - preparing (this mostly means "pulling the image")
+
+  - starting
+
+  - running
+
+- When a task is terminated (stopped, killed...) it cannot be restarted
+
+  (A replacement task will be created)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: extra-details, pic
+
+![diagram showing what happens during docker service create, courtesy of @aluzzardi](images/docker-service-create.svg)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Test our service
+
+- We mapped port 9200 on the nodes, to port 9200 in the containers
+
+- Let's try to reach that port!
+
+.lab[
+
+<!-- Give it a few seconds to be ready ```bash sleep 5``` -->
+
+- Try the following command:
+  ```bash
+  curl localhost:9200
+  ```
+
+]
+
+(If you get `Connection refused`: congratulations, you are very fast indeed! Just try again.)
+
+ElasticSearch serves a little JSON document with some basic information
+about this instance; including a randomly-generated super-hero name.
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Test the load balancing
+
+- If we repeat our `curl` command multiple times, we will see different names
+
+.lab[
+
+- Send 10 requests, and see which instances serve them:
+  ```bash
+    for N in $(seq 1 10); do
+      curl -s localhost:9200 | jq .name
+    done
+  ```
+
+]
+
+Note: if you don't have `jq` on your Play-With-Docker instance, just install it:
+```
+apk add --no-cache jq
+```
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Load balancing results
+
+Traffic is handled by our clusters [routing mesh](
+https://docs.docker.com/engine/swarm/ingress/).
+
+Each request is served by one of the instances, in rotation.
+
+Note: if you try to access the service from your browser,
+you will probably see the same
+instance name over and over, because your browser (unlike curl) will try
+to re-use the same connection.
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: pic
+
+![routing mesh](images/ingress-routing-mesh.png)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Under the hood of the routing mesh
+
+- Load balancing is done by IPVS
+
+- IPVS is a high-performance, in-kernel load balancer
+
+- It's been around for a long time (merged in the kernel since 2.4)
+
+- Each node runs a local load balancer
+
+  (Allowing connections to be routed directly to the destination,
+  without extra hops)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Managing inbound traffic
+
+There are many ways to deal with inbound traffic on a Swarm cluster.
+
+- Put all (or a subset) of your nodes in a DNS `A` record (good for web clients)
+
+- Assign your nodes (or a subset) to an external load balancer (ELB, etc.)
+
+- Use a virtual IP and make sure that it is assigned to an "alive" node
+
+- etc.
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: pic
+
+![external LB](images/ingress-lb.png)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Managing HTTP traffic
+
+- The TCP routing mesh doesn't parse HTTP headers
+
+- If you want to place multiple HTTP services on port 80/443, you need something more
+
+- You can set up NGINX or HAProxy on port 80/443 to route connections to the correct
+  Service, but they need to be "Swarm aware" to dynamically update configs
+
+--
+
+- Docker EE provides its own [Layer 7 routing](https://docs.docker.com/ee/ucp/interlock/)
+
+  - Service labels like `com.docker.lb.hosts=<FQDN>` are detected automatically via Docker 
+  API and dynamically update the configuration
+
+--
+
+- Two common open source options:
+
+  - [Traefik](https://traefik.io/) - popular, many features, requires running on managers, 
+  needs key/value for HA
+  
+  - [Docker Flow Proxy](http://proxy.dockerflow.com/) - uses HAProxy, made for 
+  Swarm by Docker Captain [@vfarcic](https://twitter.com/vfarcic)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: btw-labels
+
+## You should use labels
+
+- Labels are a great way to attach arbitrary information to services
+
+- Examples:
+
+  - HTTP vhost of a web app or web service
+
+  - backup schedule for a stateful service
+
+  - owner of a service (for billing, paging...)
+
+  - correlate Swarm objects together (services, volumes, configs, secrets, etc.)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Pro-tip for ingress traffic management
+
+- It is possible to use *local* networks with Swarm services
+
+- This means that you can do something like this:
+  ```bash
+  docker service create --network host --mode global traefik ...
+  ```
+
+  (This runs the `traefik` load balancer on each node of your cluster, in the `host` network)
+
+- This gives you native performance (no iptables, no proxy, no nothing!)
+
+- The load balancer will "see" the clients' IP addresses
+
+- But: a container cannot simultaneously be in the `host` network and another network
+
+  (You will have to route traffic to containers using exposed ports or UNIX sockets)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: extra-details
+
+## 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)
+
+- Other network drivers are a bit more complicated
+
+  (IP allocation may have to be coordinated between nodes)
+
+- 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
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Visualize container placement
+
+- Let's leverage the Docker API!
+
+.lab[
+
+- Run this simple-yet-beautiful visualization app:
+  ```bash
+  cd ~/container.training/stacks
+  docker-compose -f visualizer.yml up -d
+  ```
+
+  <!-- ```longwait Creating dockerswarmvisualizer_viz_1``` -->
+
+]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Connect to the visualization webapp
+
+- It runs a web server on port 8080
+
+.lab[
+
+- Point your browser to port 8080 of your node1's public ip
+
+  (If you use Play-With-Docker, click on the (8080) badge)
+
+  <!-- ```open http://node1:8080``` -->
+
+]
+
+- The webapp updates the display automatically (you don't need to reload the page)
+
+- It only shows Swarm services (not standalone containers)
+
+- It shows when nodes go down
+
+- It has some glitches (it's not Carrier-Grade Enterprise-Compliant ISO-9001 software)
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Why This Is More Important Than You Think
+
+- The visualizer accesses the Docker API *from within a container*
+
+- This is a common pattern: run container management tools *in containers*
+
+- Instead of viewing your cluster, this could take care of logging, metrics, autoscaling ...
+
+- We can run it within a service, too! We won't do it yet, but the command would look like:
+
+  ```bash
+    docker service create \
+      --mount source=/var/run/docker.sock,type=bind,target=/var/run/docker.sock \
+      --name viz --constraint node.role==manager ...
+  ```
+
+.footnote[
+
+Credits: the visualization code was written by
+[Francisco Miranda](https://github.com/maroshii).
+
+[Mano Marks](https://twitter.com/manomarks) adapted
+it to Swarm and maintains it.
+
+]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+## Terminate our services
+
+- Before moving on, we will remove those services
+
+- `docker service rm` can accept multiple services names or IDs
+
+- `docker service ls` can accept the `-q` flag
+
+- A Shell snippet a day keeps the cruft away
+
+.lab[
+
+- Remove all services with this one liner:
+  ```bash
+  docker service ls -q | xargs docker service rm
+  ```
+
+]
+
+.debug[[swarm/firstservice.md](""/tree/main/slides/swarm/firstservice.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/distillery-containers.jpg)]
+
+---
+
+name: toc-our-app-on-swarm
+class: title
+
+ Our app on Swarm
+
+.nav[
+[Previous part](#toc-running-our-first-swarm-service)
+|
+[Back to table of contents](#toc-part-2)
+|
+[Next part](#toc-swarm-stacks)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Our app on Swarm
+
+In this part, we will:
+
+- **build** images for our app,
+
+- **ship** these images with a registry,
+
+- **run** services using these images.
+
+.debug[[swarm/ourapponswarm.md](""/tree/main/slides/swarm/ourapponswarm.md)]
+---
+
+## Why do we need to ship our images?
+
+- When we do `docker-compose up`, images are built for our services
+
+- These images are present only on the local node
+
+- We need these images to be distributed on the whole Swarm
+
+- The easiest way to achieve that is to use a Docker registry
+
+- Once our images are on a registry, we can reference them when
+  creating our services
+
+.debug[[swarm/ourapponswarm.md](""/tree/main/slides/swarm/ourapponswarm.md)]
+---
+
+class: extra-details
+
+## Build, ship, and run, for a single service
+
+If we had only one service (built from a `Dockerfile` in the
+current directory), our workflow could look like this:
+
+```
+docker build -t jpetazzo/doublerainbow:v0.1 .
+docker push jpetazzo/doublerainbow:v0.1
+docker service create jpetazzo/doublerainbow:v0.1
+```
+
+We just have to adapt this to our application, which has 4 services!
+
+.debug[[swarm/ourapponswarm.md](""/tree/main/slides/swarm/ourapponswarm.md)]
+---
+
+## The plan
+
+- Build on our local node (`node1`)
+
+- Tag images so that they are named `localhost:5000/servicename`
+
+- Upload them to a registry
+
+- Create services using the images
+
+.debug[[swarm/ourapponswarm.md](""/tree/main/slides/swarm/ourapponswarm.md)]
+---
+
+## Which registry do we want to use?
+
+.small[
+
+- **Docker Hub**
+
+  - hosted by Docker Inc.
+  - requires an account (free, no credit card needed)
+  - images will be public (unless you pay)
+  - located in AWS EC2 us-east-1
+
+- **Docker Trusted Registry**
+
+  - self-hosted commercial product
+  - requires a subscription (free 30-day trial available)
+  - images can be public or private
+  - located wherever you want
+
+- **Docker open source registry**
+
+  - self-hosted barebones repository hosting
+  - doesn't require anything
+  - doesn't come with anything either
+  - located wherever you want
+
+- **Lots of 3rd party cloud or self-hosted options**
+
+  - AWS/Azure/Google Container Registry
+  - GitLab, Quay, JFrog
+  
+]
+
+.debug[[swarm/ourapponswarm.md](""/tree/main/slides/swarm/ourapponswarm.md)]
+---
+
+class: extra-details
+
+## Using Docker Hub
+
+*If we wanted to use the Docker Hub...*
+
+- We would log into the Docker Hub:
+  ```bash
+  docker login
+  ```
+
+- And in the following slides, we would use our Docker Hub login
+  (e.g. `jpetazzo`) instead of the registry address (i.e. `127.0.0.1:5000`)
+
+.debug[[swarm/ourapponswarm.md](""/tree/main/slides/swarm/ourapponswarm.md)]
+---
+
+class: extra-details
+
+## Using Docker Trusted Registry
+
+*If we wanted to use DTR, we would...*
+
+- Make sure we have a Docker Hub account
+
+- [Activate a Docker EE subscription](
+  https://hub.docker.com/enterprise/trial/)
+
+- Install DTR on our machines
+
+- Use `dtraddress:port/user` instead of the registry address
+
+*This is out of the scope of this workshop!*
+
+.debug[[swarm/ourapponswarm.md](""/tree/main/slides/swarm/ourapponswarm.md)]
+---
+class: btp-manual
+
+## Integration with Compose
+
+- We saw how to manually build, tag, and push images to a registry
+
+- But ...
+
+--
+
+class: btp-manual
+
+*"I'm so glad that my deployment relies on ten nautic miles of Shell scripts"*
+
+*(No-one, ever)*
+
+--
+
+class: btp-manual
+
+- Let's see how we can streamline this process!
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/lots-of-containers.jpg)]
+
+---
+
+name: toc-swarm-stacks
+class: title
+
+ Swarm Stacks
+
+.nav[
+[Previous part](#toc-our-app-on-swarm)
+|
+[Back to table of contents](#toc-part-2)
+|
+[Next part](#toc-cicd-for-docker-and-orchestration)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+
+# Swarm Stacks
+
+- Compose is great for local development
+
+- It can also be used to manage image lifecycle
+
+  (i.e. build images and push them to a registry)
+
+- Compose files *v2* are great for local development
+
+- Compose files *v3* can also be used for production deployments!
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Compose file version 3
+
+(New in Docker Engine 1.13)
+
+- Almost identical to version 2
+
+- Can be directly used by a Swarm cluster through `docker stack ...` commands
+
+- Introduces a `deploy` section to pass Swarm-specific parameters
+
+- Resource limits are moved to this `deploy` section
+
+- See [here](https://github.com/docker/docker.github.io/blob/master/compose/compose-file/compose-versioning.md#upgrading) for the complete list of changes
+
+- Supersedes *Distributed Application Bundles*
+
+  (JSON payload describing an application; could be generated from a Compose file)
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Our first stack
+
+We need a registry to move images around.
+
+Without a stack file, it would be deployed with the following command:
+
+```bash
+docker service create --publish 5000:5000 registry
+```
+
+Now, we are going to deploy it with the following stack file:
+
+```yaml
+version: "3"
+
+services:
+  registry:
+    image: registry
+    ports:
+      - "5000:5000"
+```
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Checking our stack files
+
+- All the stack files that we will use are in the `stacks` directory
+
+.lab[
+
+- Go to the `stacks` directory:
+  ```bash
+  cd ~/container.training/stacks
+  ```
+
+- Check `registry.yml`:
+  ```bash
+  cat registry.yml
+  ```
+
+]
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Deploying our first stack
+
+- All stack manipulation commands start with `docker stack`
+
+- Under the hood, they map to `docker service` commands
+
+- Stacks have a *name* (which also serves as a namespace)
+
+- Stacks are specified with the aforementioned Compose file format version 3
+
+.lab[
+
+- Deploy our local registry:
+  ```bash
+  docker stack deploy --compose-file registry.yml registry
+  ```
+
+]
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Inspecting stacks
+
+- `docker stack ps` shows the detailed state of all services of a stack
+
+.lab[
+
+- Check that our registry is running correctly:
+  ```bash
+  docker stack ps registry
+  ```
+
+- Confirm that we get the same output with the following command:
+  ```bash
+  docker service ps registry_registry
+  ```
+
+]
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+class: btp-manual
+
+## Specifics of stack deployment
+
+Our registry is not *exactly* identical to the one deployed with `docker service create`!
+
+- Each stack gets its own overlay network
+
+- Services of the stack are connected to this network
+  <br/>(unless specified differently in the Compose file)
+
+- Services get network aliases matching their name in the Compose file
+  <br/>(just like when Compose brings up an app specified in a v2 file)
+
+- Services are explicitly named `<stack_name>_<service_name>`
+
+- Services and tasks also get an internal label indicating which stack they belong to
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+class: btp-auto
+
+## 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
+
+.lab[
+
+- 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.
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+class: btp-auto
+
+## Pushing an image to our local registry
+
+- We can retag a small image, and push it to the registry
+
+.lab[
+
+- 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
+  ```
+
+]
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+class: btp-auto
+
+## Checking what's on our local registry
+
+- The registry API has endpoints to query what's there
+
+.lab[
+
+- 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"]}
+```
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Building and pushing stack services
+
+- When using Compose file version 2 and above, you can specify *both* `build` and `image`
+
+- When both keys are present:
+
+  - Compose does "business as usual" (uses `build`)
+
+  - but the resulting image is named as indicated by the `image` key
+    <br/>
+    (instead of `<projectname>_<servicename>:latest`)
+
+  - it can be pushed to a registry with `docker-compose push`
+
+- Example:
+
+  ```yaml
+    webfront:
+      build: www
+      image: myregistry.company.net:5000/webfront
+  ```
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Using Compose to build and push images
+
+.lab[
+
+- Try it:
+  ```bash
+  docker-compose -f dockercoins.yml build
+  docker-compose -f dockercoins.yml push
+  ```
+
+]
+
+Let's have a look at the `dockercoins.yml` file while this is building and pushing.
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+```yaml
+version: "3"
+
+services:
+  rng:
+    build: dockercoins/rng
+    image: ${REGISTRY-127.0.0.1:5000}/rng:${TAG-latest}
+    deploy:
+      mode: global
+  ...
+  redis:
+    image: redis
+  ...
+  worker:
+    build: dockercoins/worker
+    image: ${REGISTRY-127.0.0.1:5000}/worker:${TAG-latest}
+    ...
+    deploy:
+      replicas: 10
+```
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Deploying the application
+
+- Now that the images are on the registry, we can deploy our application stack
+
+.lab[
+
+- Create the application stack:
+  ```bash
+  docker stack deploy --compose-file dockercoins.yml dockercoins
+  ```
+
+]
+
+We can now connect to any of our nodes on port 8000, and we will see the familiar hashing speed graph.
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Maintaining multiple environments
+
+There are many ways to handle variations between environments.
+
+- Compose loads `docker-compose.yml` and (if it exists) `docker-compose.override.yml`
+
+- Compose can load alternate file(s) by setting the `-f` flag or the `COMPOSE_FILE` environment variable
+
+- Compose files can *extend* other Compose files, selectively including services:
+
+  ```yaml
+    web:
+      extends:
+        file: common-services.yml
+        service: webapp
+  ```
+
+See [this documentation page](https://docs.docker.com/compose/extends/) for more details about these techniques.
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+class: extra-details
+
+## Good to know ...
+
+- Compose file version 3 adds the `deploy` section
+
+- Further versions (3.1, ...) add more features (secrets, configs ...)
+
+- You can re-run `docker stack deploy` to update a stack
+
+- You can make manual changes with `docker service update` ...
+
+- ... But they will be wiped out each time you `docker stack deploy`
+
+  (That's the intended behavior, when one thinks about it!)
+
+- `extends` doesn't work with `docker stack deploy`
+
+  (But you can use `docker-compose config` to "flatten" your configuration)
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+## Summary
+
+- We've seen how to set up a Swarm
+
+- We've used it to host our own registry
+
+- We've built our app container images
+
+- We've used the registry to host those images
+
+- We've deployed and scaled our application
+
+- We've seen how to use Compose to streamline deployments
+
+- Awesome job, team!
+
+.debug[[swarm/stacks.md](""/tree/main/slides/swarm/stacks.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/plastic-containers.JPG)]
+
+---
+
+name: toc-cicd-for-docker-and-orchestration
+class: title
+
+ CI/CD for Docker and orchestration
+
+.nav[
+[Previous part](#toc-swarm-stacks)
+|
+[Back to table of contents](#toc-part-2)
+|
+[Next part](#toc-updating-services)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+name: cicd
+
+# CI/CD for Docker and orchestration
+
+A quick note about continuous integration and deployment
+
+- This lab won't have you building out CI/CD pipelines
+
+- We're cheating a bit by building images on server hosts and not in CI tool
+
+- Docker and orchestration works with all the CI and deployment tools
+
+.debug[[swarm/cicd.md](""/tree/main/slides/swarm/cicd.md)]
+---
+
+## CI/CD general process 
+
+- Have your CI build your images, run tests *in them*, then push to registry
+
+- If you security scan, do it then on your images after tests but before push
+
+- Optionally, have CI do continuous deployment if build/test/push is successful
+
+- CD tool would SSH into nodes, or use docker cli against remote engine
+
+- If supported, it could use docker engine TCP API (swarm API is built-in)
+
+- Docker KBase [Development Pipeline Best Practices](https://success.docker.com/article/dev-pipeline)
+
+- Docker KBase [Continuous Integration with Docker Hub](https://success.docker.com/article/continuous-integration-with-docker-hub)
+
+- Docker KBase [Building a Docker Secure Supply Chain](https://success.docker.com/article/secure-supply-chain)
+
+.debug[[swarm/cicd.md](""/tree/main/slides/swarm/cicd.md)]
+---
+
+class: pic
+
+![CI-CD with Docker](images/ci-cd-with-docker.png)
+
+.debug[[swarm/cicd.md](""/tree/main/slides/swarm/cicd.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-1.jpg)]
+
+---
+
+name: toc-updating-services
+class: title
+
+ Updating services
+
+.nav[
+[Previous part](#toc-cicd-for-docker-and-orchestration)
+|
+[Back to table of contents](#toc-part-2)
+|
+[Next part](#toc-secrets-management-and-encryption-at-rest)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Updating services
+
+- We want to make changes to the web UI
+
+- The process is as follows:
+
+  - edit code
+
+  - build new image
+
+  - ship new image
+
+  - run new image
+
+.debug[[swarm/updatingservices.md](""/tree/main/slides/swarm/updatingservices.md)]
+---
+
+## Updating a single service with `service update`
+
+- To update a single service, we could do the following:
+  ```bash
+  export REGISTRY=127.0.0.1:5000
+  export TAG=v0.2
+  IMAGE=$REGISTRY/dockercoins_webui:$TAG
+  docker build -t $IMAGE webui/
+  docker push $IMAGE
+  docker service update dockercoins_webui --image $IMAGE
+  ```
+
+- Make sure to tag properly your images: update the `TAG` at each iteration
+
+  (When you check which images are running, you want these tags to be uniquely identifiable)
+
+.debug[[swarm/updatingservices.md](""/tree/main/slides/swarm/updatingservices.md)]
+---
+
+## Updating services with `stack deploy`
+
+- With the Compose integration, all we have to do is:
+  ```bash
+  export TAG=v0.2
+  docker-compose -f composefile.yml build
+  docker-compose -f composefile.yml push
+  docker stack deploy -c composefile.yml nameofstack
+  ```
+
+--
+
+- That's exactly what we used earlier to deploy the app
+
+- We don't need to learn new commands!
+
+- It will diff each service and only update ones that changed
+
+.debug[[swarm/updatingservices.md](""/tree/main/slides/swarm/updatingservices.md)]
+---
+
+## Changing the code
+
+- Let's make the numbers on the Y axis bigger!
+
+.lab[
+
+- Update the size of text on our webui:
+  ```bash
+  sed -i "s/15px/50px/" dockercoins/webui/files/index.html
+  ```
+
+]
+
+.debug[[swarm/updatingservices.md](""/tree/main/slides/swarm/updatingservices.md)]
+---
+
+## 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`
+
+.lab[
+
+- Build, ship, and run:
+  ```bash
+  export TAG=v0.2
+  docker-compose -f dockercoins.yml build
+  docker-compose -f dockercoins.yml push
+  docker stack deploy -c dockercoins.yml dockercoins
+  ```
+
+]
+
+- Because we're tagging all images in this demo v0.2, deploy will update all apps, FYI
+
+.debug[[swarm/updatingservices.md](""/tree/main/slides/swarm/updatingservices.md)]
+---
+
+## Viewing our changes
+
+- Wait at least 10 seconds (for the new version to be deployed)
+
+- Then reload the web UI
+
+- Or just mash "reload" frantically
+
+- ... Eventually the legend on the left will be bigger!
+
+.debug[[swarm/updatingservices.md](""/tree/main/slides/swarm/updatingservices.md)]
+---
+class: self-paced
+
+## Before we continue ...
+
+The following section assumes that you have a 5-nodes Swarm cluster.
+
+If you come here from a previous tutorial and still have your cluster: great!
+
+Otherwise: check [part 1](#part-1) to learn how to set up your own cluster.
+
+We pick up exactly where we left you, so we assume that you have:
+
+- a Swarm cluster with at least 3 nodes,
+
+- a self-hosted registry,
+
+- DockerCoins up and running.
+
+The next slide has a cheat sheet if you need to set that up in a pinch.
+
+.debug[[swarm/operatingswarm.md](""/tree/main/slides/swarm/operatingswarm.md)]
+---
+
+class: self-paced
+
+## Catching up
+
+Assuming you have 5 nodes provided by
+[Play-With-Docker](https://www.play-with-docker/), do this from `node1`:
+
+```bash
+docker swarm init --advertise-addr eth0
+TOKEN=$(docker swarm join-token -q manager)
+for N in $(seq 2 5); do
+  DOCKER_HOST=tcp://node$N:2375 docker swarm join --token $TOKEN node1:2377
+done
+git clone https://github.com/jpetazzo/container.training
+cd container.training/stacks
+docker stack deploy --compose-file registry.yml registry
+docker-compose -f dockercoins.yml build
+docker-compose -f dockercoins.yml push
+docker stack deploy --compose-file dockercoins.yml dockercoins
+```
+
+You should now be able to connect to port 8000 and see the DockerCoins web UI.
+
+.debug[[swarm/operatingswarm.md](""/tree/main/slides/swarm/operatingswarm.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-2.jpg)]
+
+---
+
+name: toc-secrets-management-and-encryption-at-rest
+class: title
+
+ Secrets management and encryption at rest
+
+.nav[
+[Previous part](#toc-updating-services)
+|
+[Back to table of contents](#toc-part-3)
+|
+[Next part](#toc-least-privilege-model)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Secrets management and encryption at rest
+
+(New in Docker Engine 1.13)
+
+- Secrets management = selectively and securely bring secrets to services
+
+- Encryption at rest = protect against storage theft or prying
+
+- Remember:
+
+  - control plane is authenticated through mutual TLS, certs rotated every 90 days
+
+  - control plane is encrypted with AES-GCM, keys rotated every 12 hours
+
+  - data plane is not encrypted by default (for performance reasons),
+    <br/>but we saw earlier how to enable that with a single flag
+
+.debug[[swarm/security.md](""/tree/main/slides/swarm/security.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/two-containers-on-a-truck.jpg)]
+
+---
+
+name: toc-least-privilege-model
+class: title
+
+ Least privilege model
+
+.nav[
+[Previous part](#toc-secrets-management-and-encryption-at-rest)
+|
+[Back to table of contents](#toc-part-3)
+|
+[Next part](#toc-centralized-logging)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# 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
+
+.debug[[swarm/leastprivilege.md](""/tree/main/slides/swarm/leastprivilege.md)]
+---
+
+## 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
+
+.debug[[swarm/leastprivilege.md](""/tree/main/slides/swarm/leastprivilege.md)]
+---
+
+## Guidelines for workload isolation
+
+- 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/)
+
+.debug[[swarm/leastprivilege.md](""/tree/main/slides/swarm/leastprivilege.md)]
+---
+
+## Learning more about container security
+
+.blackbelt[DC17US: Securing Containers, One Patch At A Time
+([video](https://www.youtube.com/watch?v=jZSs1RHwcqo&list=PLkA60AVN3hh-biQ6SCtBJ-WVTyBmmYho8&index=4))]
+
+.blackbelt[DC17EU: Container-relevant Upstream Kernel Developments
+([video](https://dockercon.docker.com/watch/7JQBpvHJwjdW6FKXvMfCK1))]
+
+.blackbelt[DC17EU: What Have Syscalls Done for you Lately?
+([video](https://dockercon.docker.com/watch/4ZxNyWuwk9JHSxZxgBBi6J))]
+
+.debug[[swarm/leastprivilege.md](""/tree/main/slides/swarm/leastprivilege.md)]
+---
+## A reminder about *scope*
+
+- Out of the box, Docker API access is "all or nothing"
+
+- When someone has access to the Docker API, they can access *everything*
+
+- If your developers are using the Docker API to deploy on the dev cluster ...
+
+  ... and the dev cluster is the same as the prod cluster ...
+
+  ... it means that your devs have access to your production data, passwords, etc.
+
+- This can easily be avoided
+
+.debug[[swarm/apiscope.md](""/tree/main/slides/swarm/apiscope.md)]
+---
+
+## Fine-grained API access control
+
+A few solutions, by increasing order of flexibility:
+
+- Use separate clusters for different security perimeters
+
+  (And different credentials for each cluster)
+
+--
+
+- Add an extra layer of abstraction (sudo scripts, hooks, or full-blown PAAS)
+
+--
+
+- Enable [authorization plugins]
+
+  - each API request is vetted by your plugin(s)
+
+  - by default, the *subject name* in the client TLS certificate is used as user name
+
+  - example: [user and permission management] in [UCP]
+
+[authorization plugins]: https://docs.docker.com/engine/extend/plugins_authorization/
+[UCP]: https://docs.docker.com/datacenter/ucp/2.1/guides/
+[user and permission management]: https://docs.docker.com/datacenter/ucp/2.1/guides/admin/manage-users/
+
+.debug[[swarm/apiscope.md](""/tree/main/slides/swarm/apiscope.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/wall-of-containers.jpeg)]
+
+---
+
+name: toc-centralized-logging
+class: title
+
+ Centralized logging
+
+.nav[
+[Previous part](#toc-least-privilege-model)
+|
+[Back to table of contents](#toc-part-3)
+|
+[Next part](#toc-setting-up-elk-to-store-container-logs)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+name: logging
+
+# Centralized logging
+
+- We want to send all our container logs to a central place
+
+- If that place could offer a nice web dashboard too, that'd be nice
+
+--
+
+- We are going to deploy an ELK stack
+
+- It will accept logs over a GELF socket
+
+- We will update our services to send logs through the GELF logging driver
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/catene-de-conteneurs.jpg)]
+
+---
+
+name: toc-setting-up-elk-to-store-container-logs
+class: title
+
+ Setting up ELK to store container logs
+
+.nav[
+[Previous part](#toc-centralized-logging)
+|
+[Back to table of contents](#toc-part-3)
+|
+[Next part](#toc-metrics-collection)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+
+# Setting up ELK to store container logs
+
+*Important foreword: this is not an "official" or "recommended"
+setup; it is just an example. We used ELK in this demo because
+it's a popular setup and we keep being asked about it; but you
+will have equal success with Fluent or other logging stacks!*
+
+What we will do:
+
+- Spin up an ELK stack with services
+
+- Gaze at the spiffy Kibana web UI
+
+- Manually send a few log entries using one-shot containers
+
+- Set our containers up to send their logs to Logstash
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## What's in an ELK stack?
+
+- ELK is three components:
+
+  - ElasticSearch (to store and index log entries)
+
+  - Logstash (to receive log entries from various
+    sources, process them, and forward them to various
+    destinations)
+
+  - Kibana (to view/search log entries with a nice UI)
+
+- The only component that we will configure is Logstash
+
+- We will accept log entries using the GELF protocol
+
+- Log entries will be stored in ElasticSearch,
+  <br/>and displayed on Logstash's stdout for debugging
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: elk-manual
+
+## Setting up ELK
+
+- We need three containers: ElasticSearch, Logstash, Kibana
+
+- We will place them on a common network, `logging`
+
+.lab[
+
+- Create the network:
+  ```bash
+  docker network create --driver overlay logging
+  ```
+
+- Create the ElasticSearch service:
+  ```bash
+  docker service create --network logging --name elasticsearch elasticsearch:2.4
+  ```
+
+]
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: elk-manual
+
+## Setting up Kibana
+
+- Kibana exposes the web UI
+
+- Its default port (5601) needs to be published
+
+- It needs a tiny bit of configuration: the address of the ElasticSearch service
+
+- We don't want Kibana logs to show up in Kibana (it would create clutter)
+  <br/>so we tell Logspout to ignore them
+
+.lab[
+
+- Create the Kibana service:
+  ```bash
+  docker service create --network logging --name kibana --publish 5601:5601 \
+         -e ELASTICSEARCH_URL=http://elasticsearch:9200 kibana:4.6
+  ```
+
+]
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: elk-manual
+
+## Setting up Logstash
+
+- Logstash needs some configuration to listen to GELF messages and send them to ElasticSearch
+
+- We could author a custom image bundling this configuration
+
+- We can also pass the [configuration](https://github.com/jpetazzo/container.training/blob/master/elk/logstash.conf) on the command line
+
+.lab[
+
+- Create the Logstash service:
+  ```bash
+    docker service create --network logging --name logstash -p 12201:12201/udp \
+           logstash:2.4 -e "$(cat ~/container.training/elk/logstash.conf)"
+  ```
+
+]
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: elk-manual
+
+## Checking Logstash
+
+- Before proceeding, let's make sure that Logstash started properly
+
+.lab[
+
+- Lookup the node running the Logstash container:
+  ```bash
+  docker service ps logstash
+  ```
+
+- Connect to that node
+
+]
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: elk-manual
+
+## View Logstash logs
+
+.lab[
+
+- View the logs of the logstash service:
+  ```bash
+  docker service logs logstash --follow
+  ```
+
+  <!-- ```wait "message" => "ok"``` -->
+  <!-- ```key ^C``` -->
+
+]
+
+You should see the heartbeat messages:
+.small[
+```json
+{      "message" => "ok",
+          "host" => "1a4cfb063d13",
+      "@version" => "1",
+    "@timestamp" => "2016-06-19T00:45:45.273Z"
+}
+```
+]
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: elk-auto
+
+## Deploying our ELK cluster
+
+- We will use a stack file
+
+.lab[
+
+- Build, ship, and run our ELK stack:
+  ```bash
+  docker-compose -f elk.yml build
+  docker-compose -f elk.yml push
+  docker stack deploy -c elk.yml elk
+  ```
+
+]
+
+Note: the *build* and *push* steps are not strictly necessary, but they don't hurt!
+
+Let's have a look at the [Compose file](
+https://github.com/jpetazzo/container.training/blob/master/stacks/elk.yml).
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: elk-auto
+
+## Checking that our ELK stack works correctly
+
+- Let's view the logs of logstash
+
+  (Who logs the loggers?)
+
+.lab[
+
+- Stream logstash's logs:
+  ```bash
+  docker service logs --follow --tail 1 elk_logstash
+  ```
+
+]
+
+You should see the heartbeat messages:
+
+.small[
+```json
+{      "message" => "ok",
+          "host" => "1a4cfb063d13",
+      "@version" => "1",
+    "@timestamp" => "2016-06-19T00:45:45.273Z"
+}
+```
+]
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## Testing the GELF receiver
+
+- In a new window, we will generate a logging message
+
+- We will use a one-off container, and Docker's GELF logging driver
+
+.lab[
+
+- Send a test message:
+  ```bash
+    docker run --log-driver gelf --log-opt gelf-address=udp://127.0.0.1:12201 \
+           --rm alpine echo hello
+  ```
+]
+
+The test message should show up in the logstash container logs.
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## Sending logs from a service
+
+- We were sending from a "classic" container so far; let's send logs from a service instead
+
+- We're lucky: the parameters (`--log-driver` and `--log-opt`) are exactly the same!
+
+
+.lab[
+
+- Send a test message:
+  ```bash
+    docker service create \
+           --log-driver gelf --log-opt gelf-address=udp://127.0.0.1:12201 \
+           alpine echo hello
+  ```
+
+  <!-- ```wait Detected task failure``` -->
+  <!-- ```key ^C``` -->
+
+]
+
+The test message should show up as well in the logstash container logs.
+
+--
+
+In fact, *multiple messages will show up, and continue to show up every few seconds!*
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## Restart conditions
+
+- By default, if a container exits (or is killed with `docker kill`, or runs out of memory ...),
+  the Swarm will restart it (possibly on a different machine)
+
+- This behavior can be changed by setting the *restart condition* parameter
+
+.lab[
+
+- Change the restart condition so that Swarm doesn't try to restart our container forever:
+  ```bash
+  docker service update `xxx` --restart-condition none
+  ```
+]
+
+Available restart conditions are `none`, `any`, and `on-error`.
+
+You can also set `--restart-delay`, `--restart-max-attempts`, and `--restart-window`.
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## Connect to Kibana
+
+- The Kibana web UI is exposed on cluster port 5601
+
+.lab[
+
+- Connect to port 5601 of your cluster
+
+  - if you're using Play-With-Docker, click on the (5601) badge above the terminal
+
+  - otherwise, open http://(any-node-address):5601/ with your browser
+
+]
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## "Configuring" Kibana
+
+- If you see a status page with a yellow item, wait a minute and reload
+  (Kibana is probably still initializing)
+
+- Kibana should offer you to "Configure an index pattern":
+  <br/>in the "Time-field name" drop down, select "@timestamp", and hit the
+  "Create" button
+
+- Then:
+
+  - click "Discover" (in the top-left corner)
+  - click "Last 15 minutes" (in the top-right corner)
+  - click "Last 1 hour" (in the list in the middle)
+  - click "Auto-refresh" (top-right corner)
+  - click "5 seconds" (top-left of the list)
+
+- You should see a series of green bars (with one new green bar every minute)
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## Updating our services to use GELF
+
+- We will now inform our Swarm to add GELF logging to all our services
+
+- This is done with the `docker service update` command
+
+- The logging flags are the same as before
+
+.lab[
+
+- Enable GELF logging for the `rng` service:
+  ```bash
+    docker service update dockercoins_rng \
+           --log-driver gelf --log-opt gelf-address=udp://127.0.0.1:12201
+  ```
+
+]
+
+After ~15 seconds, you should see the log messages in Kibana.
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## Viewing container logs
+
+- Go back to Kibana
+
+- Container logs should be showing up!
+
+- We can customize the web UI to be more readable
+
+.lab[
+
+- In the left column, move the mouse over the following
+  columns, and click the "Add" button that appears:
+
+  - host
+  - container_name
+  - message
+
+<!--
+  - logsource
+  - program
+  - message
+-->
+
+]
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## .warning[Don't update stateful services!]
+
+- What would have happened if we had updated the Redis service?
+
+- When a service changes, SwarmKit replaces existing container with new ones
+
+- This is fine for stateless services
+
+- But if you update a stateful service, its data will be lost in the process
+
+- If we updated our Redis service, all our DockerCoins would be lost
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+## Important afterword
+
+**This is not a "production-grade" setup.**
+
+It is just an educational example. We did set up a single
+ElasticSearch instance and a single Logstash instance.
+
+In a production setup, you need an ElasticSearch cluster
+(both for capacity and availability reasons). You also
+need multiple Logstash instances.
+
+And if you want to withstand
+bursts of logs, you need some kind of message queue:
+Redis if you're cheap, Kafka if you want to make sure
+that you don't drop messages on the floor. Good luck.
+
+If you want to learn more about the GELF driver,
+have a look at [this blog post](
+https://jpetazzo.github.io/2017/01/20/docker-logging-gelf/).
+
+.debug[[swarm/logging.md](""/tree/main/slides/swarm/logging.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]
+
+---
+
+name: toc-metrics-collection
+class: title
+
+ Metrics collection
+
+.nav[
+[Previous part](#toc-setting-up-elk-to-store-container-logs)
+|
+[Back to table of contents](#toc-part-3)
+|
+[Next part](#toc-links-and-resources)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Metrics collection
+
+- We want to gather metrics in a central place
+
+- We will gather node metrics and container metrics
+
+- We want a nice interface to view them (graphs)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+## Node metrics
+
+- CPU, RAM, disk usage on the whole node
+
+- Total number of processes running, and their states
+
+- Number of open files, sockets, and their states
+
+- I/O activity (disk, network), per operation or volume
+
+- Physical/hardware (when applicable): temperature, fan speed ...
+
+- ... and much more!
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+## Container metrics
+
+- Similar to node metrics, but not totally identical
+
+- RAM breakdown will be different
+
+  - active vs inactive memory
+  - some memory is *shared* between containers, and accounted specially
+
+- I/O activity is also harder to track
+
+  - async writes can cause deferred "charges"
+  - some page-ins are also shared between containers
+
+For details about container metrics, see:
+<br/>
+http://jpetazzo.github.io/2013/10/08/docker-containers-metrics/
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+## Application metrics
+
+- Arbitrary metrics related to your application and business
+
+- System performance: request latency, error rate ...
+
+- Volume information: number of rows in database, message queue size ...
+
+- Business data: inventory, items sold, revenue ...
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap, prom
+
+## Tools
+
+We will build *two* different metrics pipelines:
+
+- One based on Intel Snap,
+
+- Another based on Prometheus.
+
+If you're using Play-With-Docker, skip the commands
+relevant to Intel Snap (we rely on a SSH server to deploy,
+and PWD doesn't have that yet).
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## First metrics pipeline
+
+We will use three open source Go projects for our first metrics pipeline:
+
+- Intel Snap
+
+  Collects, processes, and publishes metrics
+
+- InfluxDB
+
+  Stores metrics
+
+- Grafana
+
+  Displays metrics visually
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Snap
+
+- [github.com/intelsdi-x/snap](https://github.com/intelsdi-x/snap)
+
+- Can collect, process, and publish metric data
+
+- Doesn’t store metrics
+
+- Works as a daemon (snapd) controlled by a CLI (snapctl)
+
+- Offloads collecting, processing, and publishing to plugins
+
+- Does nothing out of the box; configuration required!
+
+- Docs: https://github.com/intelsdi-x/snap/blob/master/docs/
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## InfluxDB
+
+- Snap doesn't store metrics data
+
+- InfluxDB is specifically designed for time-series data
+
+  - CRud vs. CRUD (you rarely if ever update/delete data)
+
+  - orthogonal read and write patterns
+
+  - storage format optimization is key (for disk usage and performance)
+
+- Snap has a plugin allowing to *publish* to InfluxDB
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Grafana
+
+- Snap cannot show graphs
+
+- InfluxDB cannot show graphs
+
+- Grafana will take care of that
+
+- Grafana can read data from InfluxDB and display it as graphs
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Getting and setting up Snap
+
+- We will install Snap directly on the nodes
+
+- Release tarballs are available from GitHub
+
+- We will use a *global service*
+  <br/>(started on all nodes, including nodes added later)
+
+- This service will download and unpack Snap in /opt and /usr/local
+
+- /opt and /usr/local will be bind-mounted from the host
+
+- This service will effectively install Snap on the hosts
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## The Snap installer service
+
+- This will get Snap on all nodes
+
+.lab[
+
+```bash
+docker service create --restart-condition=none --mode global \
+       --mount type=bind,source=/usr/local/bin,target=/usr/local/bin \
+       --mount type=bind,source=/opt,target=/opt centos sh -c '
+SNAPVER=v0.16.1-beta
+RELEASEURL=https://github.com/intelsdi-x/snap/releases/download/$SNAPVER
+curl -sSL $RELEASEURL/snap-$SNAPVER-linux-amd64.tar.gz |
+     tar -C /opt -zxf-
+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, do not forget that final quote ☺
+```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## First contact with `snapd`
+
+- The core of Snap is `snapd`, the Snap daemon
+
+- Application made up of a REST API, control module, and scheduler module
+
+.lab[
+
+- Start `snapd` with plugin trust disabled and log level set to debug:
+  ```bash
+  snapd -t 0 -l 1
+  ```
+
+]
+
+- More resources:
+
+  https://github.com/intelsdi-x/snap/blob/master/docs/SNAPD.md
+  https://github.com/intelsdi-x/snap/blob/master/docs/SNAPD_CONFIGURATION.md
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Using `snapctl` to interact with `snapd`
+
+- Let's load a *collector* and a *publisher* plugins
+
+.lab[
+
+- Open a new terminal
+
+- Load the psutil collector plugin:
+  ```bash
+  snapctl plugin load /opt/snap/plugin/snap-plugin-collector-psutil
+  ```
+
+- Load the file publisher plugin:
+  ```bash
+  snapctl plugin load /opt/snap/plugin/snap-plugin-publisher-mock-file
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Checking what we've done
+
+- Good to know: Docker CLI uses `ls`, Snap CLI uses `list`
+
+.lab[
+
+- See your loaded plugins:
+  ```bash
+  snapctl plugin list
+  ```
+
+- See the metrics you can collect:
+  ```bash
+  snapctl metric list
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Actually collecting metrics: introducing *tasks*
+
+- To start collecting/processing/publishing metric data, you need to create a *task*
+
+- A *task* indicates:
+
+  - *what* to collect (which metrics)
+  - *when* to collect it (e.g. how often)
+  - *how* to process it (e.g. use it directly, or compute moving averages)
+  - *where* to publish it
+
+- Tasks can be defined with manifests written in JSON or YAML
+
+- Some plugins, such as the Docker collector, allow for wildcards (\*) in the metrics "path"
+  <br/>(see snap/docker-influxdb.json)
+
+- More resources:
+  https://github.com/intelsdi-x/snap/blob/master/docs/TASKS.md
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Our first task manifest
+
+```yaml
+  version: 1
+  schedule:
+    type: "simple" # collect on a set interval
+    interval: "1s" # of every 1s
+  max-failures: 10
+  workflow:
+    collect: # first collect
+      metrics: # metrics to collect
+        /intel/psutil/load/load1: {}
+      config: # there is no configuration
+      publish: # after collecting, publish
+        -
+            plugin_name: "file" # use the file publisher
+            config:
+                file: "/tmp/snap-psutil-file.log" # write to this file
+```
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Creating our first task
+
+- The task manifest shown on the previous slide is stored in `snap/psutil-file.yml`.
+
+.lab[
+
+- Create a task using the manifest:
+
+  ```bash
+  cd ~/container.training/snap
+  snapctl task create -t psutil-file.yml
+  ```
+
+]
+
+  The output should look like the following:
+  ```
+    Using task manifest to create task
+    Task created
+    ID: 240435e8-a250-4782-80d0-6fff541facba
+    Name: Task-240435e8-a250-4782-80d0-6fff541facba
+    State: Running
+  ```
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Checking existing tasks
+
+.lab[
+
+- This will confirm that our task is running correctly, and remind us of its task ID
+
+  ```bash
+  snapctl task list
+  ```
+
+]
+
+The output should look like the following:
+  ```
+    ID           NAME              STATE     HIT MISS FAIL CREATED
+    24043...acba Task-24043...acba Running   4   0    0    2:34PM   8-13-2016
+  ```
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Viewing our task dollars at work
+
+- The task is using a very simple publisher, `mock-file`
+
+- That publisher just writes text lines in a file (one line per data point)
+
+.lab[
+
+- Check that the data is flowing indeed:
+  ```bash
+  tail -f /tmp/snap-psutil-file.log
+  ```
+
+]
+
+To exit, hit `^C`
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Debugging tasks
+
+- When a task is not directly writing to a local file, use `snapctl task watch`
+
+- `snapctl task watch` will stream the metrics you are collecting to STDOUT
+
+.lab[
+
+```bash
+snapctl task watch <ID>
+```
+
+]
+
+To exit, hit `^C`
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Stopping snap
+
+- Our Snap deployment has a few flaws:
+
+  - snapd was started manually
+
+  - it is running on a single node
+
+  - the configuration is purely local
+
+--
+
+class: snap
+
+- We want to change that!
+
+--
+
+class: snap
+
+- But first, go back to the terminal where `snapd` is running, and hit `^C`
+
+- All tasks will be stopped; all plugins will be unloaded; Snap will exit
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Snap Tribe Mode
+
+- Tribe is Snap's clustering mechanism
+
+- When tribe mode is enabled, nodes can join *agreements*
+
+- When a node in an *agreement* does something (e.g. load a plugin or run a task),
+  <br/>other nodes of that agreement do the same thing
+
+- We will use it to load the Docker collector and InfluxDB publisher on all nodes,
+  <br/>and run a task to use them
+
+- Without tribe mode, we would have to load plugins and run tasks manually on every node
+
+- More resources:
+  https://github.com/intelsdi-x/snap/blob/master/docs/TRIBE.md
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Running Snap itself on every node
+
+- Snap runs in the foreground, so you need to use `&` or start it in tmux
+
+.lab[
+
+- Run the following command *on every node*:
+  ```bash
+  snapd -t 0 -l 1 --tribe --tribe-seed node1:6000
+  ```
+
+]
+
+If you're *not* using Play-With-Docker, there is another way to start Snap!
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Starting a daemon through SSH
+
+.warning[Hackety hack ahead!]
+
+- We will create a *global service*
+
+- That global service will install a SSH client
+
+- With that SSH client, the service will connect back to its local node
+  <br/>(i.e. "break out" of the container, using the SSH key that we provide)
+
+- Once logged on the node, the service starts snapd with Tribe Mode enabled
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Running Snap itself on every node
+
+- I might go to hell for showing you this, but here it goes ...
+
+.lab[
+
+- Start Snap all over the place:
+  ```bash
+    docker service create --name snapd --mode global \
+           --mount type=bind,source=$HOME/.ssh/id_rsa,target=/sshkey \
+           alpine sh -c "
+                  apk add --no-cache openssh-client &&
+                  ssh -o StrictHostKeyChecking=no -i /sshkey docker@172.17.0.1 \
+                      sudo snapd -t 0 -l 1 --tribe --tribe-seed node1:6000
+           " # If you copy-paste that block, don't forget that final quote :-)
+   ```
+
+]
+
+Remember: this *does not work* with Play-With-Docker (which doesn't have SSH).
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Viewing the members of our tribe
+
+- If everything went fine, Snap is now running in tribe mode
+
+.lab[
+
+- View the members of our tribe:
+  ```bash
+  snapctl member list
+  ```
+
+]
+
+This should show the 5 nodes with their hostnames.
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Create an agreement
+
+- We can now create an *agreement* for our plugins and tasks
+
+.lab[
+
+- Create an agreement; make sure to use the same name all along:
+  ```bash
+  snapctl agreement create docker-influxdb
+  ```
+
+]
+
+The output should look like the following:
+
+```
+  Name             Number of Members       plugins      tasks
+  docker-influxdb  0                       0            0
+```
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Instruct all nodes to join the agreement
+
+- We don't need another fancy global service!
+
+- We can join nodes from any existing node of the cluster
+
+.lab[
+
+- Add all nodes to the agreement:
+  ```bash
+    snapctl member list | tail -n +2 |
+      xargs -n1 snapctl agreement join docker-influxdb
+  ```
+
+]
+
+The last bit of output should look like the following:
+```
+  Name             Number of Members       plugins         tasks
+  docker-influxdb  5                       0               0
+```
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Start a container on every node
+
+- The Docker plugin requires at least one container to be started
+
+- Normally, at this point, you will have at least one container on each node
+
+- But just in case you did things differently, let's create a dummy global service
+
+.lab[
+
+- Create an alpine container on the whole cluster:
+  ```bash
+    docker service create --name ping --mode global alpine ping 8.8.8.8
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Running InfluxDB
+
+- We will create a service for InfluxDB
+
+- We will use the official image
+
+- InfluxDB uses multiple ports:
+
+  - 8086 (HTTP API; we need this)
+
+  - 8083 (admin interface; we need this)
+
+  - 8088 (cluster communication; not needed here)
+
+  - more ports for other protocols (graphite, collectd...)
+
+- We will just publish the first two
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Creating the InfluxDB service
+
+.lab[
+
+- Start an InfluxDB service, publishing ports 8083 and 8086:
+  ```bash
+    docker service create --name influxdb \
+           --publish 8083:8083 \
+           --publish 8086:8086 \
+           influxdb:0.13
+  ```
+
+]
+
+Note: this will allow any node to publish metrics data to `localhost:8086`,
+and it will allow us to access the admin interface by connecting to any node
+on port 8083.
+
+.warning[Make sure to use InfluxDB 0.13; a few things changed in 1.0
+(like, the name of the default retention policy is now "autogen") and
+this breaks a few things.]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Setting up InfluxDB
+
+- We need to create the "snap" database
+
+.lab[
+
+- Open port 8083 with your browser
+
+- Enter the following query in the query box:
+  ```
+  CREATE DATABASE "snap"
+  ```
+
+- In the top-right corner, select "Database: snap"
+
+]
+
+Note: the InfluxDB query language *looks like* SQL but it's not.
+
+???
+
+## Setting a retention policy
+
+- When graduating to 1.0, InfluxDB changed the name of the default policy
+
+- It used to be "default" and it is now "autogen"
+
+- Snap still uses "default" and this results in errors
+
+.lab[
+
+- Create a "default" retention policy by entering the following query in the box:
+  ```
+  CREATE RETENTION POLICY "default" ON "snap" DURATION 1w REPLICATION 1
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Load Docker collector and InfluxDB publisher
+
+- We will load plugins on the local node
+
+- Since our local node is a member of the agreement, all other
+  nodes in the agreement will also load these plugins
+
+.lab[
+
+- Load Docker collector:
+
+  ```bash
+  snapctl plugin load /opt/snap/plugin/snap-plugin-collector-docker
+  ```
+
+- Load InfluxDB publisher:
+
+  ```bash
+  snapctl plugin load /opt/snap/plugin/snap-plugin-publisher-influxdb
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Start a simple collection task
+
+- Again, we will create a task on the local node
+
+- The task will be replicated on other nodes members of the same agreement
+
+.lab[
+
+- Load a task manifest file collecting a couple of metrics on all containers,
+  <br/>and sending them to InfluxDB:
+  ```bash
+  cd ~/container.training/snap
+  snapctl task create -t docker-influxdb.json
+  ```
+
+]
+
+Note: the task description sends metrics to the InfluxDB API endpoint
+located at 127.0.0.1:8086. Since the InfluxDB container is published
+on port 8086, 127.0.0.1:8086 always routes traffic to the InfluxDB
+container.
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## If things go wrong...
+
+Note: if a task runs into a problem (e.g. it's trying to publish
+to a metrics database, but the database is unreachable), the task
+will be stopped.
+
+You will have to restart it manually by running:
+
+```bash
+snapctl task enable <ID>
+snapctl task start <ID>
+```
+
+This must be done *per node*. Alternatively, you can delete+re-create
+the task (it will delete+re-create on all nodes).
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Check that metric data shows up in InfluxDB
+
+- Let's check existing data with a few manual queries in the InfluxDB admin interface
+
+.lab[
+
+- List "measurements":
+  ```
+  SHOW MEASUREMENTS
+  ```
+  (This should show two generic entries corresponding to the two collected metrics.)
+
+- View time series data for one of the metrics:
+  ```
+  SELECT * FROM "intel/docker/stats/cgroups/cpu_stats/cpu_usage/total_usage"
+  ```
+  (This should show a list of data points with **time**, **docker_id**, **source**, and **value**.)
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Deploy Grafana
+
+- We will use an almost-official image, `grafana/grafana`
+
+- We will publish Grafana's web interface on its default port (3000)
+
+.lab[
+
+- Create the Grafana service:
+  ```bash
+  docker service create --name grafana --publish 3000:3000 grafana/grafana:3.1.1
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Set up Grafana
+
+.lab[
+
+- Open port 3000 with your browser
+
+- Identify with "admin" as the username and password
+
+- Click on the Grafana logo (the orange spiral in the top left corner)
+
+- Click on "Data Sources"
+
+- Click on "Add data source" (green button on the right)
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Add InfluxDB as a data source for Grafana
+
+.small[
+
+Fill the form exactly as follows:
+- Name = "snap"
+- Type = "InfluxDB"
+
+In HTTP settings, fill as follows:
+- Url = "http://(IP.address.of.any.node):8086"
+- Access = "direct"
+- Leave HTTP Auth untouched
+
+In InfluxDB details, fill as follows:
+- Database = "snap"
+- Leave user and password blank
+
+Finally, click on "add", you should see a green message saying "Success - Data source is working".
+If you see an orange box (sometimes without a message), it means that you got something wrong. Triple check everything again.
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+![Screenshot showing how to fill the form](images/grafana-add-source.png)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Create a dashboard in Grafana
+
+.lab[
+
+- Click on the Grafana logo again (the orange spiral in the top left corner)
+
+- Hover over "Dashboards"
+
+- Click "+ New"
+
+- Click on the little green rectangle that appeared in the top left
+
+- Hover over "Add Panel"
+
+- Click on "Graph"
+
+]
+
+At this point, you should see a sample graph showing up.
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+## Setting up a graph in Grafana
+
+.lab[
+
+- Panel data source: select snap
+- Click on the SELECT metrics query to expand it
+- Click on "select measurement" and pick CPU usage
+- Click on the "+" right next to "WHERE"
+- Select "docker_id"
+- Select the ID of a container of your choice (e.g. the one running InfluxDB)
+- Click on the "+" on the right of the "SELECT" line
+- Add "derivative"
+- In the "derivative" option, select "1s"
+- In the top right corner, click on the clock, and pick "last 5 minutes"
+
+]
+
+Congratulations, you are viewing the CPU usage of a single container!
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap
+
+![Screenshot showing the end result](images/grafana-add-graph.png)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap, prom
+
+## Before moving on ...
+
+- Leave that tab open!
+
+- We are going to set up *another* metrics system
+
+- ... And then compare both graphs side by side
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: snap, prom
+
+## Prometheus vs. Snap
+
+- Prometheus is another metrics collection system
+
+- Snap *pushes* metrics; Prometheus *pulls* them
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Prometheus components
+
+- The *Prometheus server* pulls, stores, and displays metrics
+
+- Its configuration defines a list of *exporter* endpoints
+  <br/>(that list can be dynamic, using e.g. Consul, DNS, Etcd...)
+
+- The exporters expose metrics over HTTP using a simple line-oriented format
+
+  (An optimized format using protobuf is also possible)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## It's all about the `/metrics`
+
+- This is what the *node exporter* looks like:
+
+  http://demo.robustperception.io:9100/metrics
+
+- Prometheus itself exposes its own internal metrics, too:
+
+  http://demo.robustperception.io:9090/metrics
+
+- A *Prometheus server* will *scrape* URLs like these
+
+  (It can also use protobuf to avoid the overhead of parsing line-oriented formats!)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-manual
+
+## Collecting metrics with Prometheus on Swarm
+
+- We will run two *global services* (i.e. scheduled on all our nodes):
+
+  - the Prometheus *node exporter* to get node metrics
+
+  - Google's cAdvisor to get container metrics
+
+- We will run a Prometheus server to scrape these exporters
+
+- The Prometheus server will be configured to use DNS service discovery
+
+- We will use `tasks.<servicename>` for service discovery
+
+- All these services will be placed on a private internal network
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-manual
+
+## Creating an overlay network for Prometheus
+
+- This is the easiest step ☺
+
+.lab[
+
+- Create an overlay network:
+  ```bash
+  docker network create --driver overlay prom
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-manual
+
+## Running the node exporter
+
+- The node exporter *should* run directly on the hosts
+- However, it can run from a container, if configured properly
+  <br/>
+  (it needs to access the host's filesystems, in particular /proc and /sys)
+
+.lab[
+
+- Start the node exporter:
+  ```bash
+    docker service create --name node --mode global --network prom \
+     --mount type=bind,source=/proc,target=/host/proc \
+     --mount type=bind,source=/sys,target=/host/sys \
+     --mount type=bind,source=/,target=/rootfs \
+     prom/node-exporter \
+      --path.procfs /host/proc \
+      --path.sysfs /host/proc \
+      --collector.filesystem.ignored-mount-points "^/(sys|proc|dev|host|etc)($|/)"
+   ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-manual
+
+## Running cAdvisor
+
+- Likewise, cAdvisor *should* run directly on the hosts
+
+- But it can run in containers, if configured properly
+
+.lab[
+
+- Start the cAdvisor collector:
+  ```bash
+    docker service create --name cadvisor --network prom --mode global \
+      --mount type=bind,source=/,target=/rootfs \
+      --mount type=bind,source=/var/run,target=/var/run \
+      --mount type=bind,source=/sys,target=/sys \
+      --mount type=bind,source=/var/lib/docker,target=/var/lib/docker \
+      google/cadvisor:latest
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-manual
+
+## Prometheus server configuration
+
+This will be our configuration file for Prometheus:
+
+.small[
+```yaml
+global:
+  scrape_interval: 10s
+scrape_configs:
+  - job_name: 'prometheus'
+    static_configs:
+      - targets: ['localhost:9090']
+  - job_name: 'node'
+    dns_sd_configs:
+      - names: ['tasks.node']
+        type: 'A'
+        port: 9100
+  - job_name: 'cadvisor'
+    dns_sd_configs:
+      - names: ['tasks.cadvisor']
+        type: 'A'
+        port: 8080
+```
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-manual
+
+## Passing the configuration to Prometheus
+
+- The easiest solution is to create a custom image bundling this configuration
+
+- We will use a very simple Dockerfile:
+  ```dockerfile
+  FROM prom/prometheus:v1.4.1
+  COPY prometheus.yml /etc/prometheus/prometheus.yml
+  ```
+
+  (The configuration file, and the Dockerfile, are in the `prom` subdirectory)
+
+- We will build this image, and push it to our local registry
+
+- Then we will create a service using this image
+
+Note: it is also possible to use a `config` to inject that configuration file
+without having to create this ad-hoc image.
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-manual
+
+## Building our custom Prometheus image
+
+- We will use the local registry started previously on 127.0.0.1:5000
+
+.lab[
+
+- Build the image using the provided Dockerfile:
+  ```bash
+  docker build -t 127.0.0.1:5000/prometheus ~/container.training/prom
+  ```
+
+- Push the image to our local registry:
+  ```bash
+  docker push 127.0.0.1:5000/prometheus
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-manual
+
+## Running our custom Prometheus image
+
+- That's the only service that needs to be published
+
+  (If we want to access Prometheus from outside!)
+
+.lab[
+
+- Start the Prometheus server:
+  ```bash
+    docker service create --network prom --name prom \
+           --publish 9090:9090 127.0.0.1:5000/prometheus
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-auto
+
+## Deploying Prometheus on our cluster
+
+- We will use a stack definition (once again)
+
+.lab[
+
+- Make sure we are in the stacks directory:
+  ```bash
+  cd ~/container.training/stacks
+  ```
+
+- Build, ship, and run the Prometheus stack:
+  ```bash
+  docker-compose -f prometheus.yml build
+  docker-compose -f prometheus.yml push
+  docker stack deploy -c prometheus.yml prometheus
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Checking our Prometheus server
+
+- First, let's make sure that Prometheus is correctly scraping all metrics
+
+.lab[
+
+- Open port 9090 with your browser
+
+- Click on "status", then "targets"
+
+]
+
+You should see 7 endpoints (3 cadvisor, 3 node, 1 prometheus).
+
+Their state should be "UP".
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-auto, config
+
+## Injecting a configuration file
+
+(New in Docker Engine 17.06)
+
+- We are creating a custom image *just to inject a configuration*
+
+- Instead, we could use the base Prometheus image + a `config` 
+
+- A `config` is a blob (usually, a configuration file) that:
+
+  - is created and managed through the Docker API (and CLI)
+
+  - gets persisted into the Raft log (i.e. safely)
+
+  - can be associated to a service
+    <br/>
+    (this injects the blob as a plain file in the service's containers)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-auto, config
+
+## Differences between `config` and `secret`
+
+The two are very similar, but ...
+
+- `configs`:
+
+  - can be injected to any filesystem location
+
+  - can be viewed and extracted using the Docker API or CLI
+
+- `secrets`:
+
+  - can only be injected into `/run/secrets`
+
+  - are never stored in clear text on disk
+
+  - cannot be viewed or extracted with the Docker API or CLI
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-auto, config
+
+## Deploying Prometheus with a `config`
+
+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
+version: "3.3"
+
+services:
+
+prometheus:
+  image: prom/prometheus:v1.4.1 
+  ports:
+    - "9090:9090"
+  configs:
+    - source: prometheus
+      target: /etc/prometheus/prometheus.yml
+
+...
+
+configs:
+  prometheus:
+    file: ../prom/prometheus.yml
+```
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-auto, config
+
+## Specifying a `config` in a Compose file
+
+- In each service, an optional `configs` section can list as many configs as you want
+
+- Each config can specify:
+
+  - an optional `target` (path to inject the configuration; by default: root of the container)
+
+  - ownership and permissions (by default, the file will be owned by UID 0, i.e. `root`)
+
+- These configs reference top-level `configs` elements
+
+- The top-level configs can be declared as:
+
+  - *external*, meaning that it is supposed to be created before you deploy the stack
+
+  - referencing a file, whose content is used to initialize the config
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-auto, config
+
+## Re-deploying Prometheus with a config
+
+- We will update the existing stack using `prometheus+config.yml`
+
+.lab[
+
+- Redeploy the `prometheus` stack:
+  ```bash
+  docker stack deploy -c prometheus+config.yml prometheus
+  ```
+
+- Check that Prometheus still works as intended
+
+  (By connecting to any node of the cluster, on port 9090)
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-auto, config
+
+## Accessing the config object from the CLI
+
+- Config objects can be viewed from the Docker CLI (or API)
+
+.lab[
+
+- List existing config objects:
+  ```bash
+  docker config ls
+  ```
+
+- View details about our config object:
+  ```bash
+  docker config inspect prometheus_prometheus
+  ```
+
+]
+
+Note: the content of the config blob is shown with BASE64 encoding.
+<br/>
+(It doesn't have to be text; it could be an image or any kind of binary content!)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom-auto, config
+
+## Extracting a config blob
+
+- Let's retrieve that Prometheus configuration!
+
+.lab[
+
+- Extract the BASE64 payload with `jq`:
+  ```bash
+  docker config inspect prometheus_prometheus | jq -r .[0].Spec.Data
+  ```
+
+- Decode it with `base64 -d`:
+  ```bash
+  docker config inspect prometheus_prometheus | jq -r .[0].Spec.Data | base64 -d
+  ```
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Displaying metrics directly from Prometheus
+
+- This is easy ... if you are familiar with PromQL
+
+.lab[
+
+- Click on "Graph", and in "expression", paste the following:
+  ```
+    sum by (container_label_com_docker_swarm_node_id) (
+      irate(
+        container_cpu_usage_seconds_total{
+          container_label_com_docker_swarm_service_name="dockercoins_worker"
+          }[1m]
+      )
+    )
+  ```
+
+- Click on the blue "Execute" button and on the "Graph" tab just below
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Building the query from scratch
+
+- We are going to build the same query from scratch
+
+- This doesn't intend to be a detailed PromQL course
+
+- This is merely so that you (I) can pretend to know how the previous query works
+  <br/>so that your coworkers (you) can be suitably impressed (or not)
+
+  (Or, so that we can build other queries if necessary, or adapt if cAdvisor,
+  Prometheus, or anything else changes and requires editing the query!)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Displaying a raw metric for *all* containers
+
+- Click on the "Graph" tab on top
+
+  *This takes us to a blank dashboard*
+
+- Click on the "Insert metric at cursor" drop down, and select `container_cpu_usage_seconds_total`
+
+  *This puts the metric name in the query box*
+
+- Click on "Execute"
+
+  *This fills a table of measurements below*
+
+- Click on "Graph" (next to "Console")
+
+  *This replaces the table of measurements with a series of graphs (after a few seconds)*
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Selecting metrics for a specific service
+
+- Hover over the lines in the graph
+
+  (Look for the ones that have labels like `container_label_com_docker_...`)
+
+- Edit the query, adding a condition between curly braces:
+
+  .small[`container_cpu_usage_seconds_total{container_label_com_docker_swarm_service_name="dockercoins_worker"}`]
+
+- Click on "Execute"
+
+  *Now we should see one line per CPU per container*
+
+- If you want to select by container ID, you can use a regex match: `id=~"/docker/c4bf.*"`
+
+- You can also specify multiple conditions by separating them with commas
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Turn counters into rates
+
+- What we see is the total amount of CPU used (in seconds)
+
+- We want to see a *rate* (CPU time used / real time)
+
+- To get a moving average over 1 minute periods, enclose the current expression within:
+
+  ```
+  rate ( ... { ... } [1m] )
+  ```
+
+  *This should turn our steadily-increasing CPU counter into a wavy graph*
+
+- To get an instantaneous rate, use `irate` instead of `rate`
+
+  (The time window is then used to limit how far behind to look for data if data points
+  are missing in case of scrape failure; see [here](https://www.robustperception.io/irate-graphs-are-better-graphs/) for more details!)
+
+  *This should show spikes that were previously invisible because they were smoothed out*
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Aggregate multiple data series
+
+- We have one graph per CPU per container; we want to sum them
+
+- Enclose the whole expression within:
+
+  ```
+  sum ( ... )
+  ```
+
+  *We now see a single graph*
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom
+
+## Collapse dimensions
+
+- If we have multiple containers we can also collapse just the CPU dimension:
+
+  ```
+  sum without (cpu) ( ... )
+  ```
+
+  *This shows the same graph, but preserves the other labels*
+
+- Congratulations, you wrote your first PromQL expression from scratch!
+
+  (I'd like to thank [Johannes Ziemke](https://twitter.com/discordianfish) and
+  [Julius Volz](https://twitter.com/juliusvolz) for their help with Prometheus!)
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom, snap
+
+## Comparing Snap and Prometheus data
+
+- If you haven't set up Snap, InfluxDB, and Grafana, skip this section
+
+- If you have closed the Grafana tab, you might have to re-set up a new dashboard
+
+  (Unless you saved it before navigating it away)
+
+- To re-do the setup, just follow again the instructions from the previous chapter
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom, snap
+
+## Add Prometheus as a data source in Grafana
+
+.lab[
+
+- In a new tab, connect to Grafana (port 3000)
+
+- Click on the Grafana logo (the orange spiral in the top-left corner)
+
+- Click on "Data Sources"
+
+- Click on the green "Add data source" button
+
+]
+
+We see the same input form that we filled earlier to connect to InfluxDB.
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom, snap
+
+## Connecting to Prometheus from Grafana
+
+.lab[
+
+- Enter "prom" in the name field
+
+- Select "Prometheus" as the source type
+
+- Enter http://(IP.address.of.any.node):9090 in the Url field
+
+- Select "direct" as the access method
+
+- Click on "Save and test"
+
+]
+
+Again, we should see a green box telling us "Data source is working."
+
+Otherwise, double-check every field and try again!
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom, snap
+
+## Adding the Prometheus data to our dashboard
+
+.lab[
+
+- Go back to the the tab where we had our first Grafana dashboard
+
+- Click on the blue "Add row" button in the lower right corner
+
+- Click on the green tab on the left; select "Add panel" and "Graph"
+
+]
+
+This takes us to the graph editor that we used earlier.
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom, snap
+
+## Querying Prometheus data from Grafana
+
+The editor is a bit less friendly than the one we used for InfluxDB.
+
+.lab[
+
+- Select "prom" as Panel data source
+
+- Paste the query in the query field:
+  ```
+    sum without (cpu, id) ( irate (
+      container_cpu_usage_seconds_total{
+        container_label_com_docker_swarm_service_name="influxdb"}[1m] ) )
+  ```
+
+- Click outside of the query field to confirm
+
+- Close the row editor by clicking the "X" in the top right area
+
+]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+class: prom, snap
+
+## Interpreting results
+
+- The two graphs *should* be similar
+
+- Protip: align the time references!
+
+.lab[
+
+- Click on the clock in the top right corner
+
+- Select "last 30 minutes"
+
+- Click on "Zoom out"
+
+- Now press the right arrow key (hold it down and watch the CPU usage increase!)
+
+]
+
+*Adjusting units is left as an exercise for the reader.*
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+
+## More resources on container metrics
+
+- [Prometheus, a Whirlwind Tour](https://speakerdeck.com/copyconstructor/prometheus-a-whirlwind-tour),
+  an original overview of Prometheus
+
+- [Docker Swarm & Container Overview](https://grafana.net/dashboards/609),
+  a custom dashboard for Grafana
+
+- [Gathering Container Metrics](http://jpetazzo.github.io/2013/10/08/docker-containers-metrics/),
+  a blog post about cgroups
+
+- [The Prometheus Time Series Database](https://www.youtube.com/watch?v=HbnGSNEjhUc),
+  a talk explaining why custom data storage is necessary for metrics
+
+.blackbelt[DC17US: Monitoring, the Prometheus Way
+([video](https://www.youtube.com/watch?v=PDxcEzu62jk&list=PLkA60AVN3hh-biQ6SCtBJ-WVTyBmmYho8&index=5))]
+
+.blackbelt[DC17EU: Prometheus 2.0 Storage Engine
+([video](https://dockercon.docker.com/watch/NNZ8GXHGomouwSXtXnxb8P))]
+
+.debug[[swarm/metrics.md](""/tree/main/slides/swarm/metrics.md)]
+---
+class: title, self-paced
+
+Thank you!
+
+.debug[[shared/thankyou.md](""/tree/main/slides/shared/thankyou.md)]
+---
+
+class: title, in-person
+
+That's all, folks! <br/> Questions?
+
+![end](images/end.jpg)
+
+.debug[[shared/thankyou.md](""/tree/main/slides/shared/thankyou.md)]
+---
+
+class: pic
+
+.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]
+
+---
+
+name: toc-links-and-resources
+class: title
+
+ Links and resources
+
+.nav[
+[Previous part](#toc-metrics-collection)
+|
+[Back to table of contents](#toc-part-3)
+|
+[Next part](#toc-)
+]
+
+.debug[(automatically generated title slide)]
+
+---
+# Links and resources
+
+- [Docker Community Slack](https://community.docker.com/registrations/groups/4316)
+- [Docker Community Forums](https://forums.docker.com/)
+- [Docker Hub](https://hub.docker.com)
+- [Docker Blog](https://blog.docker.com/)
+- [Docker documentation](https://docs.docker.com/)
+- [Docker on StackOverflow](https://stackoverflow.com/questions/tagged/docker)
+- [Docker on Twitter](https://twitter.com/docker)
+- [Play With Docker Hands-On Labs](https://training.play-with-docker.com/)
+
+.footnote[These slides (and future updates) are on → https://container.training/]
+
+.debug[[swarm/links.md](""/tree/main/slides/swarm/links.md)]</textarea>
+    <script src="remark.min.js" type="text/javascript">
+    </script>
+    <script type="text/javascript">
+      var slideshow = remark.create({
+        ratio: '16:9',
+        highlightSpans: true,
+        slideNumberFormat: '%current%/%total%',
+        excludedClasses: ["self-paced","snap","btp-manual","benchmarking","elk-manual","prom-manual"]
+      });
+    </script>
+    
+    <!-- 
+    These two scripts will be available only when loading the
+    content using the pub/sub server. Otherwise, they'll just
+    404 and that's OK.
+    -->
+    <script src="/socket.io/socket.io.js">
+    </script>
+    <script src="/remote.js">
+    </script>
+
+  </body>
+</html>
diff --git a/slides/swarm-selfpaced.yml.html b/slides/swarm-selfpaced.yml.html
index d1164b7..b2f9fc5 100644
--- a/slides/swarm-selfpaced.yml.html
+++ b/slides/swarm-selfpaced.yml.html
@@ -30,21 +30,12 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 .debug[
 ```
  M slides/airgapped/Importing_Images.md
- M slides/intro-twodays.yml.html
- M slides/kadm-fullday.yml.html
- M slides/kadm-twodays.yml.html
- M slides/kube-adv.yml.html
- M slides/kube-fullday.yml.html
- M slides/kube-halfday.yml.html
- M slides/kube-selfpaced.yml.html
- M slides/kube-twodays.yml.html
- M slides/swarm-fullday.yml.html
  M slides/swarm-halfday.yml.html
  M slides/swarm-selfpaced.yml.html
 
 ```
 
-These slides have been built from commit: d650e09
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/swarm-video.yml.html b/slides/swarm-video.yml.html
index 26e8fa4..106cde7 100644
--- a/slides/swarm-video.yml.html
+++ b/slides/swarm-video.yml.html
@@ -30,22 +30,13 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 .debug[
 ```
  M slides/airgapped/Importing_Images.md
- M slides/intro-twodays.yml.html
- M slides/kadm-fullday.yml.html
- M slides/kadm-twodays.yml.html
- M slides/kube-adv.yml.html
- M slides/kube-fullday.yml.html
- M slides/kube-halfday.yml.html
- M slides/kube-selfpaced.yml.html
- M slides/kube-twodays.yml.html
- M slides/swarm-fullday.yml.html
  M slides/swarm-halfday.yml.html
  M slides/swarm-selfpaced.yml.html
  M slides/swarm-video.yml.html
 
 ```
 
-These slides have been built from commit: d650e09
+These slides have been built from commit: 65fec64
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]