diff --git a/slides/intro-container-security.yml.html b/slides/intro-container-security.yml.html
index 8c33f2f..9f6901e 100644
--- a/slides/intro-container-security.yml.html
+++ b/slides/intro-container-security.yml.html
@@ -32,11 +32,23 @@ i share: Introduction Container Security and Hardening<br/>
  M slides/airgapped/Importing_Images.md
  M slides/intro-container-security.yml.html
  M slides/intro-fd-docker.yml
+ 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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: 9e893b5
+These slides have been built from commit: 07d4dae
 
 
 [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 90033bb..794cbb2 100644
--- a/slides/intro-fd-docker.yml.html
+++ b/slides/intro-fd-docker.yml.html
@@ -33,11 +33,23 @@ Introduction to Containers in an Airgapped Environment<br/>
  M slides/intro-container-security.yml.html
  M slides/intro-fd-docker.yml
  M slides/intro-fd-docker.yml.html
+ 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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: 9e893b5
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
@@ -2727,7 +2739,7 @@ ubuntu       22.04     1f6ddc1b2547   2 weeks ago   77.8MB
 
 ## Import image on 'secure' system
 
-Let's pretend that we copied the tar file to this node via secure, approved methodes.
+Let's pretend that we copied the `tar` file to this node via secure, approved methodes.
 Once it is there we can import it.
 
 ```bash
@@ -2750,6 +2762,13 @@ ubuntu       22.04     1f6ddc1b2547   2 weeks ago   77.8MB
 .debug[[airgapped/Importing_Images.md](""/tree/main/slides/airgapped/Importing_Images.md)]
 ---
 
+## Image locally available
+
+The imported image is available on the host where it was imported. The name of the image has not changed.
+This operation can be repeated throughout the organisation and the images could be stored somewhere in a filesystem in `tar` format.
+.debug[[airgapped/Importing_Images.md](""/tree/main/slides/airgapped/Importing_Images.md)]
+---
+
 class: pic
 
 .interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/containers-by-the-water.jpg)]
diff --git a/slides/intro-fd-k8s-deployments.yml.html b/slides/intro-fd-k8s-deployments.yml.html
index 6d0635a..efa333f 100644
--- a/slides/intro-fd-k8s-deployments.yml.html
+++ b/slides/intro-fd-k8s-deployments.yml.html
@@ -34,11 +34,23 @@ Introduction to Helm and friends<br/>
  M slides/intro-fd-docker.yml
  M slides/intro-fd-docker.yml.html
  M slides/intro-fd-k8s-deployments.yml.html
+ 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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: 9e893b5
+These slides have been built from commit: 07d4dae
 
 
 [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 f9b2839..0c0b731 100644
--- a/slides/intro-fd-k8s.yml.html
+++ b/slides/intro-fd-k8s.yml.html
@@ -35,11 +35,23 @@ 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/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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: 9e893b5
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-fullday.yml.html b/slides/intro-fullday.yml.html
index a407e5f..5dfa545 100644
--- a/slides/intro-fullday.yml.html
+++ b/slides/intro-fullday.yml.html
@@ -36,11 +36,23 @@ 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/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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: 9e893b5
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-selfpaced.yml.html b/slides/intro-selfpaced.yml.html
index a46b08d..2c809c7 100644
--- a/slides/intro-selfpaced.yml.html
+++ b/slides/intro-selfpaced.yml.html
@@ -37,11 +37,23 @@ 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/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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: 9e893b5
+These slides have been built from commit: 07d4dae
 
 
 [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 8aed2eb..912c78a 100644
--- a/slides/intro-triodos-1-day.yml.html
+++ b/slides/intro-triodos-1-day.yml.html
@@ -38,11 +38,23 @@ 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/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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: 9e893b5
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/intro-twodays.yml.html b/slides/intro-twodays.yml.html
index e69de29..84e6fe3 100644
--- a/slides/intro-twodays.yml.html
+++ b/slides/intro-twodays.yml.html
@@ -0,0 +1,11387 @@
+<!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
+ M slides/intro-container-security.yml.html
+ M slides/intro-fd-docker.yml
+ M slides/intro-fd-docker.yml.html
+ M slides/intro-fd-k8s-deployments.yml.html
+ M slides/intro-fd-k8s.yml.html
+ M slides/intro-fullday.yml.html
+ M slides/intro-selfpaced.yml.html
+ M slides/intro-triodos-1-day.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
+ M slides/upload.sh
+
+```
+
+These slides have been built from commit: 07d4dae
+
+
+[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/kadm-fullday.yml.html b/slides/kadm-fullday.yml.html
index af2586d..74ff324 100644
--- a/slides/kadm-fullday.yml.html
+++ b/slides/kadm-fullday.yml.html
@@ -30,15 +30,31 @@ Kubernetes<br/>for Admins and Ops<br/>
 .debug[
 ```
  M slides/airgapped/Importing_Images.md
+ M slides/intro-container-security.yml.html
  M slides/intro-fd-docker.yml
+ M slides/intro-fd-docker.yml.html
+ M slides/intro-fd-k8s-deployments.yml.html
+ M slides/intro-fd-k8s.yml.html
+ M slides/intro-fullday.yml.html
+ M slides/intro-selfpaced.yml.html
  M slides/intro-triodos-1-day.yml.html
  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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/kadm-twodays.yml.html b/slides/kadm-twodays.yml.html
index de6c447..b05c1c3 100644
--- a/slides/kadm-twodays.yml.html
+++ b/slides/kadm-twodays.yml.html
@@ -30,16 +30,31 @@ Kubernetes<br/>for administrators<br/>and operators<br/>
 .debug[
 ```
  M slides/airgapped/Importing_Images.md
+ M slides/intro-container-security.yml.html
  M slides/intro-fd-docker.yml
+ M slides/intro-fd-docker.yml.html
+ M slides/intro-fd-k8s-deployments.yml.html
+ M slides/intro-fd-k8s.yml.html
+ M slides/intro-fullday.yml.html
+ M slides/intro-selfpaced.yml.html
  M slides/intro-triodos-1-day.yml.html
  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
  M slides/upload.sh
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/kube-adv.yml.html b/slides/kube-adv.yml.html
index 5018298..e69de29 100644
--- a/slides/kube-adv.yml.html
+++ b/slides/kube-adv.yml.html
@@ -1,18518 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>Advanced Kubernetes </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
-
-Advanced<br/>Kubernetes<br/>
-
-.nav[*Self-paced version*]
-
-.debug[
-```
- M slides/airgapped/Importing_Images.md
- M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
- 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/upload.sh
-
-```
-
-These slides have been built from commit: c830a9d
-
-
-[shared/title.md](""/tree/main/slides/shared/title.md)]
----
-
-class: title, in-person
-
-Advanced<br/>Kubernetes<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
-  
-- Credit is also due to [multiple contributors](https://github.com/jpetazzo/container.training/graphs/contributors) — 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 Kubernetes [documentation](https://kubernetes.io/docs/) ...
-
-- ... And looking for answers on [StackOverflow](http://stackoverflow.com/questions/tagged/kubernetes) and other outlets
-
-.debug[[k8s/intro.md](""/tree/main/slides/k8s/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 Kubernetes cluster
-
-- 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[[k8s/intro.md](""/tree/main/slides/k8s/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 `kube-adv.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)]
----
-
-name: toc-part-1
-
-## Part 1
-
-- [Pre-requirements](#toc-pre-requirements)
-
-- [Kubernetes architecture](#toc-kubernetes-architecture)
-
-- [The Kubernetes API](#toc-the-kubernetes-api)
-
-- [Other control plane components](#toc-other-control-plane-components)
-
-- [Kubernetes Internal APIs](#toc-kubernetes-internal-apis)
-
-- [Building our own cluster](#toc-building-our-own-cluster)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-2
-
-## Part 2
-
-- [Adding nodes to the cluster](#toc-adding-nodes-to-the-cluster)
-
-- [The Container Network Interface](#toc-the-container-network-interface)
-
-- [Interconnecting clusters](#toc-interconnecting-clusters)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-3
-
-## Part 3
-
-- [CNI internals](#toc-cni-internals)
-
-- [API server availability](#toc-api-server-availability)
-
-- [Securing the control plane](#toc-securing-the-control-plane)
-
-- [(Extra content)](#toc-extra-content)
-
-- [Static pods](#toc-static-pods)
-
-- [Upgrading clusters](#toc-upgrading-clusters)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-4
-
-## Part 4
-
-- [Kustomize](#toc-kustomize)
-- [Managing stacks with Helm](#toc-managing-stacks-with-helm)
-- [Helm chart format](#toc-helm-chart-format)
-- [Creating a basic chart](#toc-creating-a-basic-chart)
-- [(Extra content)](#toc-extra-content)
-- [Creating better Helm charts](#toc-creating-better-helm-charts)
-- [Charts using other charts](#toc-charts-using-other-charts)
-- [Helm and invalid values](#toc-helm-and-invalid-values)
-- [Helm secrets](#toc-helm-secrets)
-- [YTT](#toc-ytt)
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-5
-
-## Part 5
-
-- [Extending the Kubernetes API](#toc-extending-the-kubernetes-api)
-
-- [Operators](#toc-operators)
-
-- [Sealed Secrets](#toc-sealed-secrets)
-
-- [Custom Resource Definitions](#toc-custom-resource-definitions)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-6
-
-## Part 6
-
-- [Ingress and TLS certificates](#toc-ingress-and-tls-certificates)
-
-- [cert-manager](#toc-cert-manager)
-
-- [An ElasticSearch Operator](#toc-an-elasticsearch-operator)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-7
-
-## Part 7
-
-- [Dynamic Admission Control](#toc-dynamic-admission-control)
-
-- [Policy Management with Kyverno](#toc-policy-management-with-kyverno)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-8
-
-## Part 8
-
-- [The Aggregation Layer](#toc-the-aggregation-layer)
-
-- [Checking Node and Pod resource usage](#toc-checking-node-and-pod-resource-usage)
-
-- [Collecting metrics with Prometheus](#toc-collecting-metrics-with-prometheus)
-
-- [Prometheus and Grafana](#toc-prometheus-and-grafana)
-
-- [Scaling with custom metrics](#toc-scaling-with-custom-metrics)
-
-
-.debug[(auto-generated TOC)]
----
-name: toc-part-9
-
-## Part 9
-
-- [Designing an operator](#toc-designing-an-operator)
-
-- [Writing a tiny operator](#toc-writing-a-tiny-operator)
-
-- [Kubebuilder](#toc-kubebuilder)
-
-- [Events](#toc-events)
-
-- [Finalizers](#toc-finalizers)
-
-- [(Extra content)](#toc-extra-content)
-
-- [Owners and dependents](#toc-owners-and-dependents)
-
-- [API server internals](#toc-api-server-internals)
-
-
-.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-kubernetes-architecture)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Pre-requirements
-
-- Kubernetes concepts
-
-  (pods, deployments, services, labels, selectors)
-
-- Hands-on experience working with containers
-
-  (building images, running them; doesn't matter how exactly)
-
-- Familiar with the UNIX command-line
-
-  (navigating directories, editing files, using `kubectl`)
-
-.debug[[k8s/prereqs-admin.md](""/tree/main/slides/k8s/prereqs-admin.md)]
----
-
-## Labs and exercises
-
-- We are going to build and break multiple clusters
-
-- Everyone will get their own private environment(s)
-
-- You are invited to reproduce all the demos (but you don't have to)
-
-- 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[[k8s/prereqs-admin.md](""/tree/main/slides/k8s/prereqs-admin.md)]
----
-
-## Private environments
-
-- Each person gets their own private set of VMs
-
-- Each person should have a printed card with connection information
-
-- We will connect to these VMs with SSH
-
-  (if you don't have an SSH client, install one **now!**)
-
-.debug[[k8s/prereqs-admin.md](""/tree/main/slides/k8s/prereqs-admin.md)]
----
-
-## Doing or re-doing this on your own?
-
-- We are using basic cloud VMs with Ubuntu LTS
-
-- Kubernetes [packages] or [binaries] have been installed
-
-  (depending on what we want to accomplish in the lab)
-
-- We disabled IP address checks
-
-  - we want to route pod traffic directly between nodes
-
-  - most cloud providers will treat pod IP addresses as invalid
-
-  - ... and filter them out; so we disable that filter
-
-[packages]: https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl
-
-[binaries]: https://kubernetes.io/docs/setup/release/notes/#server-binaries
-
-.debug[[k8s/prereqs-admin.md](""/tree/main/slides/k8s/prereqs-admin.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]
-
----
-
-name: toc-kubernetes-architecture
-class: title
-
- Kubernetes architecture
-
-.nav[
-[Previous part](#toc-pre-requirements)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-the-kubernetes-api)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Kubernetes architecture
-
-We can arbitrarily split Kubernetes in two parts:
-
-- the *nodes*, a set of machines that run our containerized workloads;
-
-- the *control plane*, a set of processes implementing the Kubernetes APIs.
-
-Kubernetes also relies on underlying infrastructure:
-
-- servers, network connectivity (obviously!),
-
-- optional components like storage systems, load balancers ...
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-![Kubernetes architecture diagram: communication between components](images/k8s-arch4-thanks-luxas.png)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## What runs on a node
-
-- Our containerized workloads
-
-- A container engine like Docker, CRI-O, containerd...
-
-  (in theory, the choice doesn't matter, as the engine is abstracted by Kubernetes)
-
-- kubelet: an agent connecting the node to the cluster
-
-  (it connects to the API server, registers the node, receives instructions)
-
-- kube-proxy: a component used for internal cluster communication
-
-  (note that this is *not* an overlay network or a CNI plugin!)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## What's in the control plane
-
-- Everything is stored in etcd
-
-  (it's the only stateful component)
-
-- Everyone communicates exclusively through the API server:
-
-  - we (users) interact with the cluster through the API server
-
-  - the nodes register and get their instructions through the API server
-
-  - the other control plane components also register with the API server
-
-- API server is the only component that reads/writes from/to etcd
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Communication protocols: API server
-
-- The API server exposes a REST API
-
-  (except for some calls, e.g. to attach interactively to a container)
-
-- Almost all requests and responses are JSON following a strict format
-
-- For performance, the requests and responses can also be done over protobuf
-
-  (see this [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) for details)
-
-- In practice, protobuf is used for all internal communication
-
-  (between control plane components, and with kubelet)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Communication protocols: on the nodes
-
-The kubelet agent uses a number of special-purpose protocols and interfaces, including:
-
-- CRI (Container Runtime Interface)
-
-  - used for communication with the container engine
-  - abstracts the differences between container engines
-  - based on gRPC+protobuf
-
-- [CNI (Container Network Interface)](https://github.com/containernetworking/cni/blob/master/SPEC.md)
-
-  - used for communication with network plugins
-  - network plugins are implemented as executable programs invoked by kubelet
-  - network plugins provide IPAM
-  - network plugins set up network interfaces in pods
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Control plane location
-
-The control plane can run:
-
-- in containers, on the same nodes that run other application workloads
-
-  (default behavior for local clusters like [Minikube](https://github.com/kubernetes/minikube), [kind](https://kind.sigs.k8s.io/)...)
-
-- on a dedicated node
-
-  (default behavior when deploying with kubeadm)
-
-- on a dedicated set of nodes
-
-  ([Kubernetes The Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way); [kops](https://github.com/kubernetes/kops); also kubeadm)
-
-- outside of the cluster
-
-  (most managed clusters like AKS, DOK, EKS, GKE, Kapsule, LKE, OKE...)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-![](images/control-planes/single-node-dev.svg)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-![](images/control-planes/managed-kubernetes.svg)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-![](images/control-planes/single-control-and-workers.svg)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-![](images/control-planes/stacked-control-plane.svg)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-![](images/control-planes/non-dedicated-stacked-nodes.svg)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-![](images/control-planes/advanced-control-plane.svg)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-![](images/control-planes/advanced-control-plane-split-events.svg)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg)]
-
----
-
-name: toc-the-kubernetes-api
-class: title
-
- The Kubernetes API
-
-.nav[
-[Previous part](#toc-kubernetes-architecture)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-other-control-plane-components)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-# The Kubernetes API
-
-[
-*The Kubernetes API server is a "dumb server" which offers storage, versioning, validation, update, and watch semantics on API resources.*
-](
-https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md#proposal-and-motivation
-)
-
-([Clayton Coleman](https://twitter.com/smarterclayton), Kubernetes Architect and Maintainer)
-
-What does that mean?
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## The Kubernetes API is declarative
-
-- We cannot tell the API, "run a pod"
-
-- We can tell the API, "here is the definition for pod X"
-
-- The API server will store that definition (in etcd)
-
-- *Controllers* will then wake up and create a pod matching the definition
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## The core features of the Kubernetes API
-
-- We can create, read, update, and delete objects
-
-- We can also *watch* objects
-
-  (be notified when an object changes, or when an object of a given type is created)
-
-- Objects are strongly typed
-
-- Types are *validated* and *versioned*
-
-- Storage and watch operations are provided by etcd
-
-  (note: the [k3s](https://k3s.io/) project allows us to use sqlite instead of etcd)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Let's experiment a bit!
-
-- For this section, connect to the first node of the `test` cluster
-
-.lab[
-
-- SSH to the first node of the test cluster
-
-- Check that the cluster is operational:
-  ```bash
-  kubectl get nodes
-  ```
-
-- All nodes should be `Ready`
-
-]
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Create
-
-- Let's create a simple object
-
-.lab[
-
-- Create a namespace with the following command:
-  ```bash
-    kubectl create -f- <<EOF
-    apiVersion: v1
-    kind: Namespace
-    metadata:
-      name: hello
-    EOF
-  ```
-
-]
-
-This is equivalent to `kubectl create namespace hello`.
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Read
-
-- Let's retrieve the object we just created
-
-.lab[
-
-- Read back our object:
-  ```bash
-  kubectl get namespace hello -o yaml
-  ```
-
-]
-
-We see a lot of data that wasn't here when we created the object.
-
-Some data was automatically added to the object (like `spec.finalizers`).
-
-Some data is dynamic (typically, the content of `status`.)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## API requests and responses
-
-- Almost every Kubernetes API payload (requests and responses) has the same format:
-  ```yaml
-    apiVersion: xxx
-    kind: yyy
-    metadata:
-      name: zzz
-      (more metadata fields here)
-    (more fields here)
-  ```
-
-- The fields shown above are mandatory, except for some special cases
-
-  (e.g.: in lists of resources, the list itself doesn't have a `metadata.name`)
-
-- We show YAML for convenience, but the API uses JSON
-
-  (with optional protobuf encoding)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: extra-details
-
-## API versions
-
-- The `apiVersion` field corresponds to an *API group*
-
-- It can be either `v1` (aka "core" group or "legacy group"), or `group/versions`; e.g.:
-
-  - `apps/v1`
-  - `rbac.authorization.k8s.io/v1`
-  - `extensions/v1beta1`
-
-- It does not indicate which version of Kubernetes we're talking about
-
-- It *indirectly* indicates the version of the `kind`
-
-  (which fields exist, their format, which ones are mandatory...)
-
-- A single resource type (`kind`) is rarely versioned alone
-
-  (e.g.: the `batch` API group contains `jobs` and `cronjobs`)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: extra-details
-
-## Group-Version-Kind, or GVK
-
-- A particular type will be identified by the combination of:
-
-  - the API group it belongs to (core, `apps`, `metrics.k8s.io`, ...)
-
-  - the version of this API group (`v1`, `v1beta1`, ...)
-
-  - the "Kind" itself (Pod, Role, Job, ...)
-
-- "GVK" appears a lot in the API machinery code
-
-- Conversions are possible between different versions and even between API groups
-
-  (e.g. when Deployments moved from `extensions` to `apps`)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Update
-
-- Let's update our namespace object
-
-- There are many ways to do that, including:
-
-  - `kubectl apply` (and provide an updated YAML file)
-  - `kubectl edit`
-  - `kubectl patch`
-  - many helpers, like `kubectl label`, or `kubectl set`
-
-- In each case, `kubectl` will:
-
-  - get the current definition of the object
-  - compute changes
-  - submit the changes (with `PATCH` requests)
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Adding a label
-
-- For demonstration purposes, let's add a label to the namespace
-
-- The easiest way is to use `kubectl label`
-
-.lab[
-
-- In one terminal, watch namespaces:
-  ```bash
-  kubectl get namespaces --show-labels -w
-  ```
-
-- In the other, update our namespace:
-  ```bash
-  kubectl label namespaces hello color=purple
-  ```
-
-]
-
-We demonstrated *update* and *watch* semantics.
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## What's special about *watch*?
-
-- The API server itself doesn't do anything: it's just a fancy object store
-
-- All the actual logic in Kubernetes is implemented with *controllers*
-
-- A *controller* watches a set of resources, and takes action when they change
-
-- Examples:
-
-  - when a Pod object is created, it gets scheduled and started
-
-  - when a Pod belonging to a ReplicaSet terminates, it gets replaced
-
-  - when a Deployment object is updated, it can trigger a rolling update
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: extra-details
-
-## Watch events
-
-- `kubectl get --watch` shows changes
-
-- If we add `--output-watch-events`, we can also see:
-
-  - the difference between ADDED and MODIFIED resources
-
-  - DELETED resources
-
-.lab[
-
-- In one terminal, watch pods, displaying full events:
-  ```bash
-  kubectl get pods --watch --output-watch-events
-  ```
-
-- In another, run a short-lived pod:
-  ```bash
-  kubectl run pause --image=alpine --rm -ti --restart=Never -- sleep 5
-  ```
-
-]
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg)]
-
----
-
-name: toc-other-control-plane-components
-class: title
-
- Other control plane components
-
-.nav[
-[Previous part](#toc-the-kubernetes-api)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-kubernetes-internal-apis)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-# Other control plane components
-
-- API server ✔️
-
-- etcd ✔️
-
-- Controller manager
-
-- Scheduler
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Controller manager
-
-- This is a collection of loops watching all kinds of objects
-
-- That's where the actual logic of Kubernetes lives
-
-- When we create a Deployment (e.g. with `kubectl create deployment web --image=nginx`),
-
-  - we create a Deployment object
-
-  - the Deployment controller notices it, and creates a ReplicaSet
-
-  - the ReplicaSet controller notices the ReplicaSet, and creates a Pod
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-## Scheduler
-
-- When a pod is created, it is in `Pending` state
-
-- The scheduler (or rather: *a scheduler*) must bind it to a node
-
-  - Kubernetes comes with an efficient scheduler with many features
-
-  - if we have special requirements, we can add another scheduler
-    <br/>
-    (example: this [demo scheduler](https://github.com/kelseyhightower/scheduler) uses the cost of nodes, stored in node annotations)
-
-- A pod might stay in `Pending` state for a long time:
-
-  - if the cluster is full
-
-  - if the pod has special constraints that can't be met
-
-  - if the scheduler is not running (!)
-
-???
-
-:EN:- Kubernetes architecture review
-:FR:- Passage en revue de l'architecture de Kubernetes
-
-.debug[[k8s/architecture.md](""/tree/main/slides/k8s/architecture.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg)]
-
----
-
-name: toc-kubernetes-internal-apis
-class: title
-
- Kubernetes Internal APIs
-
-.nav[
-[Previous part](#toc-other-control-plane-components)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-building-our-own-cluster)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Kubernetes Internal APIs
-
-- Almost every Kubernetes component has some kind of internal API
-
-  (some components even have multiple APIs on different ports!)
-
-- At the very least, these can be used for healthchecks
-
-  (you *should* leverage this if you are deploying and operating Kubernetes yourself!)
-
-- Sometimes, they are used internally by Kubernetes
-
-  (e.g. when the API server retrieves logs from kubelet)
-
-- Let's review some of these APIs!
-
-.debug[[k8s/internal-apis.md](""/tree/main/slides/k8s/internal-apis.md)]
----
-
-## API hunting guide
-
-This is how we found and investigated these APIs:
-
-- look for open ports on Kubernetes nodes
-
-  (worker nodes or control plane nodes)
-
-- check which process owns that port
-
-- probe the port (with `curl` or other tools)
-
-- read the source code of that process
-
-  (in particular when looking for API routes)
-
-OK, now let's see the results!
-
-.debug[[k8s/internal-apis.md](""/tree/main/slides/k8s/internal-apis.md)]
----
-
-## etcd
-
-- 2379/tcp → etcd clients
-
-  - should be HTTPS and require mTLS authentication
-
-- 2380/tcp → etcd peers
-
-  - should be HTTPS and require mTLS authentication
-
-- 2381/tcp → etcd healthcheck
-
-  - HTTP without authentication
-
-  - exposes two API routes: `/health` and `/metrics`
-
-.debug[[k8s/internal-apis.md](""/tree/main/slides/k8s/internal-apis.md)]
----
-
-## kubelet
-
-- 10248/tcp → healthcheck
-
-  - HTTP without authentication
-
-  - exposes a single API route, `/healthz`, that just returns `ok`
-
-- 10250/tcp → internal API
-
-  - should be HTTPS and require mTLS authentication
-
-  - used by the API server to obtain logs, `kubectl exec`, etc.
-
-.debug[[k8s/internal-apis.md](""/tree/main/slides/k8s/internal-apis.md)]
----
-
-class: extra-details
-
-## kubelet API
-
-- We can authenticate with e.g. our TLS admin certificate
-
-- The following routes should be available:
-
-  - `/healthz`
-  - `/configz` (serves kubelet configuration)
-  - `/metrics`
-  - `/pods` (returns *desired state*)
-  - `/runningpods` (returns *current state* from the container runtime)
-  - `/logs` (serves files from `/var/log`)
-  - `/containerLogs/<namespace>/<podname>/<containername>` (can add e.g. `?tail=10`)
-  - `/run`, `/exec`, `/attach`, `/portForward`
-
-- See [kubelet source code](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/server/server.go) for details!
-
-.debug[[k8s/internal-apis.md](""/tree/main/slides/k8s/internal-apis.md)]
----
-
-class: extra-details
-
-## Trying the kubelet API
-
-The following example should work on a cluster deployed with `kubeadm`.
-
-1. Obtain the key and certificate for the `cluster-admin` user.
-
-2. Log into a node.
-
-3. Copy the key and certificate on the node.
-
-4. Find out the name of the `kube-proxy` pod running on that node.
-
-5. Run the following command, updating the pod name:
-   ```bash
-   curl -d cmd=ls -k --cert admin.crt --key admin.key \
-       https://localhost:10250/run/kube-system/`kube-proxy-xy123`/kube-proxy
-   ```
-
-... This should show the content of the root directory in the pod.
-
-.debug[[k8s/internal-apis.md](""/tree/main/slides/k8s/internal-apis.md)]
----
-
-## kube-proxy
-
-- 10249/tcp → healthcheck
-
-  - HTTP, without authentication
-
-  - exposes a few API routes: `/healthz` (just returns `ok`), `/configz`, `/metrics`
-
-- 10256/tcp → another healthcheck
-
-  - HTTP, without authentication
-
-  - also exposes a `/healthz` API route (but this one shows a timestamp)
-
-.debug[[k8s/internal-apis.md](""/tree/main/slides/k8s/internal-apis.md)]
----
-
-## kube-controller and kube-scheduler
-
-- 10257/tcp → kube-controller
-
-  - HTTPS, with optional mTLS authentication
-
-  - `/healthz` doesn't require authentication
-
-  - ... but `/configz` and `/metrics` do (use e.g. admin key and certificate)
-
-- 10259/tcp → kube-scheduler
-
-  - similar to kube-controller, with the same routes
-
-???
-
-:EN:- Kubernetes internal APIs
-:FR:- Les APIs internes de Kubernetes
-.debug[[k8s/internal-apis.md](""/tree/main/slides/k8s/internal-apis.md)]
----
-## 19,000 words
-
-They say, "a picture is worth one thousand words."
-
-The following 19 slides show what really happens when we run:
-
-```bash
-kubectl create deployment web --image=nginx
-```
-
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/01.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/02.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/03.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/04.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/05.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/06.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/07.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/08.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/09.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/10.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/11.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/12.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/13.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/14.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/15.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/16.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/17.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/18.svg)
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-class: pic
-![](images/kubectl-create-deployment-slideshow/19.svg)
-
-.debug[[k8s/deploymentslideshow.md](""/tree/main/slides/k8s/deploymentslideshow.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg)]
-
----
-
-name: toc-building-our-own-cluster
-class: title
-
- Building our own cluster
-
-.nav[
-[Previous part](#toc-kubernetes-internal-apis)
-|
-[Back to table of contents](#toc-part-1)
-|
-[Next part](#toc-adding-nodes-to-the-cluster)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Building our own cluster
-
-- Let's build our own cluster!
-
-  *Perfection is attained not when there is nothing left to add, but when there is nothing left to take away. (Antoine de Saint-Exupery)*
-
-- Our goal is to build a minimal cluster allowing us to:
-
-  - create a Deployment (with `kubectl create deployment`)
-  - expose it with a Service
-  - connect to that service
-
-
-- "Minimal" here means:
-
-  - smaller number of components
-  - smaller number of command-line flags
-  - smaller number of configuration files
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Non-goals
-
-- For now, we don't care about security
-
-- For now, we don't care about scalability
-
-- For now, we don't care about high availability
-
-- All we care about is *simplicity*
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Our environment
-
-- We will use the machine indicated as `dmuc1`
-
-  (this stands for "Dessine Moi Un Cluster" or "Draw Me A Sheep",
-  <br/>in homage to Saint-Exupery's "The Little Prince")
-
-- This machine:
-
-  - runs Ubuntu LTS
-
-  - has Kubernetes, Docker, and etcd binaries installed
-
-  - but nothing is running
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Checking our environment
-
-- Let's make sure we have everything we need first
-
-.lab[
-
-- Log into the `dmuc1` machine
-
-- Get root:
-  ```bash
-  sudo -i
-  ```
-
-- Check available versions:
-  ```bash
-  etcd -version
-  kube-apiserver --version
-  dockerd --version
-  ```
-
-]
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## The plan
-
-1. Start API server
-
-2. Interact with it (create Deployment and Service)
-
-3. See what's broken
-
-4. Fix it and go back to step 2 until it works!
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Dealing with multiple processes
-
-- We are going to start many processes
-
-- Depending on what you're comfortable with, you can:
-
-  - open multiple windows and multiple SSH connections
-
-  - use a terminal multiplexer like screen or tmux
-
-  - put processes in the background with `&`
-    <br/>(warning: log output might get confusing to read!)
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting API server
-
-.lab[
-
-- Try to start the API server:
-  ```bash
-  kube-apiserver
-  # It will fail with "--etcd-servers must be specified"
-  ```
-
-]
-
-Since the API server stores everything in etcd,
-it cannot start without it.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting etcd
-
-.lab[
-
-- Try to start etcd:
-  ```bash
-  etcd
-  ```
-
-]
-
-Success!
-
-Note the last line of output:
-```
-serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!
-```
-
-*Sure, that's discouraged. But thanks for telling us the address!*
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting API server (for real)
-
-- Try again, passing the `--etcd-servers` argument
-
-- That argument should be a comma-separated list of URLs
-
-.lab[
-
-- Start API server:
-  ```bash
-  kube-apiserver --etcd-servers http://127.0.0.1:2379
-  ```
-
-]
-
-Success!
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Interacting with API server
-
-- Let's try a few "classic" commands
-
-.lab[
-
-- List nodes:
-  ```bash
-  kubectl get nodes
-  ```
-
-- List services:
-  ```bash
-  kubectl get services
-  ```
-
-]
-
-We should get `No resources found.` and the `kubernetes` service, respectively.
-
-Note: the API server automatically created the `kubernetes` service entry.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-class: extra-details
-
-## What about `kubeconfig`?
-
-- We didn't need to create a `kubeconfig` file
-
-- By default, the API server is listening on `localhost:8080`
-
-  (without requiring authentication)
-
-- By default, `kubectl` connects to `localhost:8080`
-
-  (without providing authentication)
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Creating a Deployment
-
-- Let's run a web server!
-
-.lab[
-
-- Create a Deployment with NGINX:
-  ```bash
-  kubectl create deployment web --image=nginx
-  ```
-
-]
-
-Success?
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Checking our Deployment status
-
-.lab[
-
-- Look at pods, deployments, etc.:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
-Our Deployment is in bad shape:
-```
-NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
-deployment.apps/web   0/1     0            0           2m26s
-```
-
-And, there is no ReplicaSet, and no Pod.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## What's going on?
-
-- We stored the definition of our Deployment in etcd
-
-  (through the API server)
-
-- But there is no *controller* to do the rest of the work
-
-- We need to start the *controller manager*
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting the controller manager
-
-.lab[
-
-- Try to start the controller manager:
-  ```bash
-  kube-controller-manager
-  ```
-
-]
-
-The final error message is:
-```
-invalid configuration: no configuration has been provided
-```
-
-But the logs include another useful piece of information:
-```
-Neither --kubeconfig nor --master was specified.
-Using the inClusterConfig.  This might not work.
-```
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Reminder: everyone talks to API server
-
-- The controller manager needs to connect to the API server
-
-- It *does not* have a convenient `localhost:8080` default
-
-- We can pass the connection information in two ways:
-
-  - `--master` and a host:port combination (easy)
-
-  - `--kubeconfig` and a `kubeconfig` file
-
-- For simplicity, we'll use the first option
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting the controller manager (for real)
-
-.lab[
-
-- Start the controller manager:
-  ```bash
-  kube-controller-manager --master http://localhost:8080
-  ```
-
-]
-
-Success!
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Checking our Deployment status
-
-.lab[
-
-- Check all our resources again:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
-We now have a ReplicaSet.
-
-But we still don't have a Pod.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## What's going on?
-
-In the controller manager logs, we should see something like this:
-```
-E0404 15:46:25.753376   22847 replica_set.go:450] Sync "default/web-5bc9bd5b8d"
-failed with `No API token found for service account "default"`, retry after the
-token is automatically created and added to the service account
-```
-
-- The service account `default` was automatically added to our Deployment
-
-  (and to its pods)
-
-- The service account `default` exists
-
-- But it doesn't have an associated token
-
-  (the token is a secret; creating it requires signature; therefore a CA)
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Solving the missing token issue
-
-There are many ways to solve that issue.
-
-We are going to list a few (to get an idea of what's happening behind the scenes).
-
-Of course, we don't need to perform *all* the solutions mentioned here.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Option 1: disable service accounts
-
-- Restart the API server with
-  `--disable-admission-plugins=ServiceAccount`
-
-- The API server will no longer add a service account automatically
-
-- Our pods will be created without a service account
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Option 2: do not mount the (missing) token
-
-- Add `automountServiceAccountToken: false` to the Deployment spec
-
-  *or*
-
-- Add `automountServiceAccountToken: false` to the default ServiceAccount
-
-- The ReplicaSet controller will no longer create pods referencing the (missing) token
-
-.lab[
-
-- Programmatically change the `default` ServiceAccount:
-  ```bash
-  kubectl patch sa default -p "automountServiceAccountToken: false"
-  ```
-
-]
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Option 3: set up service accounts properly
-
-- This is the most complex option!
-
-- Generate a key pair
-
-- Pass the private key to the controller manager
-
-  (to generate and sign tokens)
-
-- Pass the public key to the API server
-
-  (to verify these tokens)
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Continuing without service account token
-
-- Once we patch the default service account, the ReplicaSet can create a Pod
-
-.lab[
-
-- Check that we now have a pod:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
-Note: we might have to wait a bit for the ReplicaSet controller to retry.
-
-If we're impatient, we can restart the controller manager.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## What's next?
-
-- Our pod exists, but it is in `Pending` state
-
-- Remember, we don't have a node so far
-
-  (`kubectl get nodes` shows an empty list)
-
-- We need to:
-
-  - start a container engine
-
-  - start kubelet
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting a container engine
-
-- We're going to use Docker (because it's the default option)
-
-.lab[
-
-- Start the Docker Engine:
-  ```bash
-  dockerd
-  ```
-
-]
-
-Success!
-
-Feel free to check that it actually works with e.g.:
-```bash
-docker run alpine echo hello world
-```
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting kubelet
-
-- If we start kubelet without arguments, it *will* start
-
-- But it will not join the cluster!
-
-- It will start in *standalone* mode
-
-- Just like with the controller manager, we need to tell kubelet where the API server is
-
-- Alas, kubelet doesn't have a simple `--master` option
-
-- We have to use `--kubeconfig`
-
-- We need to write a `kubeconfig` file for kubelet
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Writing a kubeconfig file
-
-- We can copy/paste a bunch of YAML
-
-- Or we can generate the file with `kubectl`
-
-.lab[
-
-- Create the file `~/.kube/config` with `kubectl`:
-  ```bash
-    kubectl config \
-            set-cluster localhost --server http://localhost:8080
-    kubectl config \
-            set-context localhost --cluster localhost
-    kubectl config \
-            use-context localhost
-  ```
-
-]
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Our `~/.kube/config` file
-
-The file that we generated looks like the one below.
-
-That one has been slightly simplified (removing extraneous fields), but it is still valid.
-
-```yaml
-apiVersion: v1
-kind: Config
-current-context: localhost
-contexts:
-- name: localhost
-  context:
-    cluster: localhost
-clusters:
-- name: localhost
-  cluster:
-    server: http://localhost:8080
-```
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting kubelet
-
-.lab[
-
-- Start kubelet with that kubeconfig file:
-  ```bash
-  kubelet --kubeconfig ~/.kube/config
-  ```
-
-]
-
-Success!
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Looking at our 1-node cluster
-
-- Let's check that our node registered correctly
-
-.lab[
-
-- List the nodes in our cluster:
-  ```bash
-  kubectl get nodes
-  ```
-
-]
-
-Our node should show up.
-
-Its name will be its hostname (it should be `dmuc1`).
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Are we there yet?
-
-- Let's check if our pod is running
-
-.lab[
-
-- List all resources:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
---
-
-Our pod is still `Pending`. 🤔
-
---
-
-Which is normal: it needs to be *scheduled*.
-
-(i.e., something needs to decide which node it should go on.)
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Scheduling our pod
-
-- Why do we need a scheduling decision, since we have only one node?
-
-- The node might be full, unavailable; the pod might have constraints ...
-
-- The easiest way to schedule our pod is to start the scheduler
-
-  (we could also schedule it manually)
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting the scheduler
-
-- The scheduler also needs to know how to connect to the API server
-
-- Just like for controller manager, we can use `--kubeconfig` or `--master`
-
-.lab[
-
-- Start the scheduler:
-  ```bash
-  kube-scheduler --master http://localhost:8080
-  ```
-
-]
-
-- Our pod should now start correctly
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Checking the status of our pod
-
-- Our pod will go through a short `ContainerCreating` phase
-
-- Then it will be `Running`
-
-.lab[
-
-- Check pod status:
-  ```bash
-  kubectl get pods
-  ```
-
-]
-
-Success!
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-class: extra-details
-
-## Scheduling a pod manually
-
-- We can schedule a pod in `Pending` state by creating a Binding, e.g.:
-  ```bash
-    kubectl create -f- <<EOF
-    apiVersion: v1
-    kind: Binding
-    metadata:
-      name: name-of-the-pod
-    target:
-      apiVersion: v1
-      kind: Node
-      name: name-of-the-node
-    EOF
-  ```
-
-- This is actually how the scheduler works!
-
-- It watches pods, makes scheduling decisions, and creates Binding objects
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Connecting to our pod
-
-- Let's check that our pod correctly runs NGINX
-
-.lab[
-
-- Check our pod's IP address:
-  ```bash
-  kubectl get pods -o wide
-  ```
-
-- Send some HTTP request to the pod:
-  ```bash
-  curl `X.X.X.X`
-  ```
-
-]
-
-We should see the `Welcome to nginx!` page.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Exposing our Deployment
-
-- We can now create a Service associated with this Deployment
-
-.lab[
-
-- Expose the Deployment's port 80:
-  ```bash
-  kubectl expose deployment web --port=80
-  ```
-
-- Check the Service's ClusterIP, and try connecting:
-  ```bash
-  kubectl get service web
-  curl http://`X.X.X.X`
-  ```
-
-]
-
---
-
-This won't work. We need kube-proxy to enable internal communication.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Starting kube-proxy
-
-- kube-proxy also needs to connect to the API server
-
-- It can work with the `--master` flag
-
-  (although that will be deprecated in the future)
-
-.lab[
-
-- Start kube-proxy:
-  ```bash
-  kube-proxy --master http://localhost:8080
-  ```
-
-]
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-## Connecting to our Service
-
-- Now that kube-proxy is running, we should be able to connect
-
-.lab[
-
-- Check the Service's ClusterIP again, and retry connecting:
-  ```bash
-  kubectl get service web
-  curl http://`X.X.X.X`
-  ```
-
-]
-
-Success!
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-class: extra-details
-
-## How kube-proxy works
-
-- kube-proxy watches Service resources
-
-- When a Service is created or updated, kube-proxy creates iptables rules
-
-.lab[
-
-- Check out the `OUTPUT` chain in the `nat` table:
-  ```bash
-  iptables -t nat -L OUTPUT
-  ```
-
-- Traffic is sent to `KUBE-SERVICES`; check that too:
-  ```bash
-  iptables -t nat -L KUBE-SERVICES
-  ```
-
-]
-
-For each Service, there is an entry in that chain.
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-class: extra-details
-
-## Diving into iptables
-
-- The last command showed a chain named `KUBE-SVC-...` corresponding to our service
-
-.lab[
-
-- Check that `KUBE-SVC-...` chain:
-  ```bash
-  iptables -t nat -L `KUBE-SVC-...`
-  ```
-
-- It should show a jump to a `KUBE-SEP-...` chains; check it out too:
-  ```bash
-  iptables -t nat -L `KUBE-SEP-...`
-  ```
-
-]
-
-This is a `DNAT` rule to rewrite the destination address of the connection to our pod.
-
-This is how kube-proxy works!
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-class: extra-details
-
-## kube-router, IPVS
-
-- With recent versions of Kubernetes, it is possible to tell kube-proxy to use IPVS
-
-- IPVS is a more powerful load balancing framework
-
-  (remember: iptables was primarily designed for firewalling, not load balancing!)
-
-- It is also possible to replace kube-proxy with kube-router
-
-- kube-router uses IPVS by default
-
-- kube-router can also perform other functions
-
-  (e.g., we can use it as a CNI plugin to provide pod connectivity)
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-class: extra-details
-
-## What about the `kubernetes` service?
-
-- If we try to connect, it won't work
-
-  (by default, it should be `10.0.0.1`)
-
-- If we look at the Endpoints for this service, we will see one endpoint:
-
-  `host-address:6443`
-
-- By default, the API server expects to be running directly on the nodes
-
-  (it could be as a bare process, or in a container/pod using the host network)
-
-- ... And it expects to be listening on port 6443 with TLS
-
-???
-
-:EN:- Building our own cluster from scratch
-:FR:- Construire son cluster à la main
-
-.debug[[k8s/dmuc.md](""/tree/main/slides/k8s/dmuc.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-housing.jpg)]
-
----
-
-name: toc-adding-nodes-to-the-cluster
-class: title
-
- Adding nodes to the cluster
-
-.nav[
-[Previous part](#toc-building-our-own-cluster)
-|
-[Back to table of contents](#toc-part-2)
-|
-[Next part](#toc-the-container-network-interface)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Adding nodes to the cluster
-
-- So far, our cluster has only 1 node
-
-- Let's see what it takes to add more nodes
-
-- We are going to use another set of machines: `kubenet`
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## The environment
-
-- We have 3 identical machines: `kubenet1`, `kubenet2`, `kubenet3`
-
-- The Docker Engine is installed (and running) on these machines
-
-- The Kubernetes binaries are installed, but nothing is running
-
-- We will use `kubenet1` to run the control plane
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## The plan
-
-- Start the control plane on `kubenet1`
-
-- Join the 3 nodes to the cluster
-
-- Deploy and scale a simple web server
-
-.lab[
-
-- Log into `kubenet1`
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Running the control plane
-
-- We will use a Compose file to start the control plane components
-
-.lab[
-
-- Clone the repository containing the workshop materials:
-  ```bash
-  git clone https://github.com/jpetazzo/container.training
-  ```
-
-- Go to the `compose/simple-k8s-control-plane` directory:
-  ```bash
-  cd container.training/compose/simple-k8s-control-plane
-  ```
-
-- Start the control plane:
-  ```bash
-  docker-compose up
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Checking the control plane status
-
-- Before moving on, verify that the control plane works
-
-.lab[
-
-- Show control plane component statuses:
-  ```bash
-  kubectl get componentstatuses
-  kubectl get cs
-  ```
-
-- Show the (empty) list of nodes:
-  ```bash
-  kubectl get nodes
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-class: extra-details
-
-## Differences from `dmuc`
-
-- Our new control plane listens on `0.0.0.0` instead of the default `127.0.0.1`
-
-- The ServiceAccount admission plugin is disabled
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Joining the nodes
-
-- We need to generate a `kubeconfig` file for kubelet
-
-- This time, we need to put the public IP address of `kubenet1`
-
-  (instead of `localhost` or `127.0.0.1`)
-
-.lab[
-
-- Generate the `kubeconfig` file:
-  ```bash
-    kubectl config set-cluster kubenet --server http://`X.X.X.X`:8080
-    kubectl config set-context kubenet --cluster kubenet
-    kubectl config use-context kubenet
-    cp ~/.kube/config ~/kubeconfig
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Distributing the `kubeconfig` file
-
-- We need that `kubeconfig` file on the other nodes, too
-
-.lab[
-
-- Copy `kubeconfig` to the other nodes:
-  ```bash
-    for N in 2 3; do
-    	scp ~/kubeconfig kubenet$N:
-    done
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Starting kubelet
-
-- Reminder: kubelet needs to run as root; don't forget `sudo`!
-
-.lab[
-
-- Join the first node:
-   ```bash
-   sudo kubelet --kubeconfig ~/kubeconfig
-   ```
-
-- Open more terminals and join the other nodes to the cluster:
-  ```bash
-  ssh kubenet2 sudo kubelet --kubeconfig ~/kubeconfig
-  ssh kubenet3 sudo kubelet --kubeconfig ~/kubeconfig
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Checking cluster status
-
-- We should now see all 3 nodes
-
-- At first, their `STATUS` will be `NotReady`
-
-- They will move to `Ready` state after approximately 10 seconds
-
-.lab[
-
-- Check the list of nodes:
-  ```bash
-  kubectl get nodes
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Deploy a web server
-
-- Let's create a Deployment and scale it
-
-  (so that we have multiple pods on multiple nodes)
-
-.lab[
-
-- Create a Deployment running `jpetazzo/color`:
-  ```bash
-  kubectl create deployment blue --image=jpetazzo/color
-  ```
-
-- Scale it:
-  ```bash
-  kubectl scale deployment blue --replicas=5
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Check our pods
-
-- The pods will be scheduled on the nodes
-
-- The nodes will pull the `jpetazzo/color` image, and start the pods
-
-- What are the IP addresses of our pods?
-
-.lab[
-
-- Check the IP addresses of our pods
-  ```bash
-  kubectl get pods -o wide
-  ```
-
-]
-
---
-
-🤔 Something's not right ... Some pods have the same IP address!
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## What's going on?
-
-- Without the `--network-plugin` flag, kubelet defaults to "no-op" networking
-
-- It lets the container engine use a default network
-
-  (in that case, we end up with the default Docker bridge)
-
-- Our pods are running on independent, disconnected, host-local networks
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## What do we need to do?
-
-- On a normal cluster, kubelet is configured to set up pod networking with CNI plugins
-
-- This requires:
-
-  - installing CNI plugins
-
-  - writing CNI configuration files
-
-  - running kubelet with `--network-plugin=cni`
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Using network plugins
-
-- We need to set up a better network
-
-- Before diving into CNI, we will use the `kubenet` plugin
-
-- This plugin creates a `cbr0` bridge and connects the containers to that bridge
-
-- This plugin allocates IP addresses from a range:
-
-  - either specified to kubelet (e.g. with `--pod-cidr`)
-
-  - or stored in the node's `spec.podCIDR` field
-
-.footnote[See [here][kubenet-plugin] for more details about this `kubenet` plugin.]
-
-[kubenet-plugin]: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## What `kubenet` does and *does not* do
-
-- It allocates IP addresses to pods *locally*
-
-  (each node has its own local subnet)
-
-- It connects the pods to a *local* bridge
-
-  (pods on the same node can communicate together; not with other nodes)
-
-- It doesn't set up routing or tunneling
-
-  (we get pods on separated networks; we need to connect them somehow)
-
-- It doesn't allocate subnets to nodes
-
-  (this can be done manually, or by the controller manager) 
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Setting up routing or tunneling
-
-- *On each node*, we will add routes to the other nodes' pod network
-
-- Of course, this is not convenient or scalable!
-
-- We will see better techniques to do this; but for now, hang on!
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Allocating subnets to nodes
-
-- There are multiple options:
-
-  - passing the subnet to kubelet with the `--pod-cidr` flag
-
-  - manually setting `spec.podCIDR` on each node
-
-  - allocating node CIDRs automatically with the controller manager
-
-- The last option would be implemented by adding these flags to controller manager:
-  ```
-  --allocate-node-cidrs=true --cluster-cidr=<cidr> 
-  ```
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-class: extra-details
-
-## The pod CIDR field is not mandatory
-
-- `kubenet` needs the pod CIDR, but other plugins don't need it
-
-  (e.g. because they allocate addresses in multiple pools, or a single big one)
-
-- The pod CIDR field may eventually be deprecated and replaced by an annotation
-
-  (see [kubernetes/kubernetes#57130](https://github.com/kubernetes/kubernetes/issues/57130))
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Restarting kubelet wih pod CIDR
-
-- We need to stop and restart all our kubelets
-
-- We will add the `--network-plugin` and `--pod-cidr` flags
-
-- We all have a "cluster number" (let's call that `C`) printed on your VM info card
-
-- We will use pod CIDR `10.C.N.0/24` (where `N` is the node number: 1, 2, 3)
-
-.lab[
-
-- Stop all the kubelets (Ctrl-C is fine)
-
-- Restart them all, adding `--network-plugin=kubenet --pod-cidr 10.C.N.0/24`
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## What happens to our pods?
-
-- When we stop (or kill) kubelet, the containers keep running
-
-- When kubelet starts again, it detects the containers
-
-.lab[
-
-- Check that our pods are still here:
-  ```bash
-  kubectl get pods -o wide
-  ```
-
-]
-
-🤔 But our pods still use local IP addresses!
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Recreating the pods
-
-- The IP address of a pod cannot change
-
-- kubelet doesn't automatically kill/restart containers with "invalid" addresses
-  <br/>
-  (in fact, from kubelet's point of view, there is no such thing as an "invalid" address)
-
-- We must delete our pods and recreate them
-
-.lab[
-
-- Delete all the pods, and let the ReplicaSet recreate them:
-  ```bash
-  kubectl delete pods --all
-  ```
-
-- Wait for the pods to be up again:
-  ```bash
-  kubectl get pods -o wide -w
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Adding kube-proxy
-
-- Let's start kube-proxy to provide internal load balancing
-
-- Then see if we can create a Service and use it to contact our pods
-
-.lab[
-
-- Start kube-proxy:
-  ```bash
-  sudo kube-proxy --kubeconfig ~/.kube/config
-  ```
-
-- Expose our Deployment:
-  ```bash
-  kubectl expose deployment blue --port=80
-  ```
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Test internal load balancing
-
-.lab[
-
-- Retrieve the ClusterIP address:
-  ```bash
-  kubectl get svc blue
-  ```
-
-- Send a few requests to the ClusterIP address (with `curl`)
-
-]
-
---
-
-Sometimes it works, sometimes it doesn't. Why?
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Routing traffic
-
-- Our pods have new, distinct IP addresses
-
-- But they are on host-local, isolated networks
-
-- If we try to ping a pod on a different node, it won't work
-
-- kube-proxy merely rewrites the destination IP address
-
-- But we need that IP address to be reachable in the first place
-
-- How do we fix this?
-
-  (hint: check the title of this slide!)
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Important warning
-
-- The technique that we are about to use doesn't work everywhere
-
-- It only works if:
-
-  - all the nodes are directly connected to each other (at layer 2)
-
-  - the underlying network allows the IP addresses of our pods
-
-- If we are on physical machines connected by a switch: OK
-
-- If we are on virtual machines in a public cloud: NOT OK
-
-  - on AWS, we need to disable "source and destination checks" on our instances
-
-  - on OpenStack, we need to disable "port security" on our network ports
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Routing basics
-
-- We need to tell *each* node:
-
-  "The subnet 10.C.N.0/24 is located on node N" (for all values of N)
-
-- This is how we add a route on Linux:
-  ```bash
-  ip route add 10.C.N.0/24 via W.X.Y.Z
-  ```
-
-  (where `W.X.Y.Z` is the internal IP address of node N)
-
-- We can see the internal IP addresses of our nodes with:
-  ```bash
-  kubectl get nodes -o wide
-  ```
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Firewalling
-
-- By default, Docker prevents containers from using arbitrary IP addresses
-
-  (by setting up iptables rules)
-
-- We need to allow our containers to use our pod CIDR
-
-- For simplicity, we will insert a blanket iptables rule allowing all traffic:
-
-  `iptables -I FORWARD -j ACCEPT`
-
-- This has to be done on every node
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## Setting up routing
-
-.lab[
-
-- Create all the routes on all the nodes
-
-- Insert the iptables rule allowing traffic
-
-- Check that you can ping all the pods from one of the nodes
-
-- Check that you can `curl` the ClusterIP of the Service successfully
-
-]
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.md)]
----
-
-## What's next?
-
-- We did a lot of manual operations:
-
-  - allocating subnets to nodes
-
-  - adding command-line flags to kubelet
-
-  - updating the routing tables on our nodes
-
-- We want to automate all these steps
-
-- We want something that works on all networks
-
-???
-
-:EN:- Connecting nodes ands pods
-:FR:- Interconnecter les nœuds et les pods
-
-.debug[[k8s/multinode.md](""/tree/main/slides/k8s/multinode.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-interface
-class: title
-
- The Container Network Interface
-
-.nav[
-[Previous part](#toc-adding-nodes-to-the-cluster)
-|
-[Back to table of contents](#toc-part-2)
-|
-[Next part](#toc-interconnecting-clusters)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# The Container Network Interface
-
-- Allows us to decouple network configuration from Kubernetes
-
-- Implemented by *plugins*
-
-- Plugins are executables that will be invoked by kubelet
-
-- Plugins are responsible for:
-
-  - allocating IP addresses for containers
-
-  - configuring the network for containers
-
-- Plugins can be combined and chained when it makes sense
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Combining plugins
-
-- Interface could be created by e.g. `vlan` or `bridge` plugin
-
-- IP address could be allocated by e.g. `dhcp` or `host-local` plugin
-
-- Interface parameters (MTU, sysctls) could be tweaked by the `tuning` plugin
-
-The reference plugins are available [here][cni-reference-plugins].
-
-Look in each plugin's directory for its documentation.
-
-[cni-reference-plugins]: https://github.com/containernetworking/plugins/tree/master/plugins
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## How does kubelet know which plugins to use?
-
-- The plugin (or list of plugins) is set in the CNI configuration
-
-- The CNI configuration is a *single file* in `/etc/cni/net.d`
-
-- If there are multiple files in that directory, the first one is used
-
-  (in lexicographic order)
-
-- That path can be changed with the `--cni-conf-dir` flag of kubelet
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## CNI configuration in practice
-
-- When we set up the "pod network" (like Calico, Weave...) it ships a CNI configuration
-
-  (and sometimes, custom CNI plugins)
-
-- Very often, that configuration (and plugins) is installed automatically
-
-  (by a DaemonSet featuring an initContainer with hostPath volumes)
-
-- Examples:
-
-  - Calico [CNI config](https://github.com/projectcalico/calico/blob/1372b56e3bfebe2b9c9cbf8105d6a14764f44159/v2.6/getting-started/kubernetes/installation/hosted/calico.yaml#L25)
-    and [volume](https://github.com/projectcalico/calico/blob/1372b56e3bfebe2b9c9cbf8105d6a14764f44159/v2.6/getting-started/kubernetes/installation/hosted/calico.yaml#L219)
-
-  - kube-router [CNI config](https://github.com/cloudnativelabs/kube-router/blob/c2f893f64fd60cf6d2b6d3fee7191266c0fc0fe5/daemonset/generic-kuberouter.yaml#L10)
-    and [volume](https://github.com/cloudnativelabs/kube-router/blob/c2f893f64fd60cf6d2b6d3fee7191266c0fc0fe5/daemonset/generic-kuberouter.yaml#L73)
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## Conf vs conflist
-
-- There are two slightly different configuration formats
-
-- Basic configuration format:
-
-  - holds configuration for a single plugin
-  - typically has a `.conf` name suffix
-  - has a `type` string field in the top-most structure
-  - [examples](https://github.com/containernetworking/cni/blob/master/SPEC.md#example-configurations)
-
-- Configuration list format:
-
-  - can hold configuration for multiple (chained) plugins
-  - typically has a `.conflist` name suffix
-  - has a `plugins` list field in the top-most structure
-  - [examples](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration-lists)
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## How plugins are invoked
-
-- Parameters are given through environment variables, including:
-
-  - CNI_COMMAND: desired operation (ADD, DEL, CHECK, or VERSION)
-
-  - CNI_CONTAINERID: container ID
-
-  - CNI_NETNS: path to network namespace file
-
-  - CNI_IFNAME: what the network interface should be named
-
-- The network configuration must be provided to the plugin on stdin
-
-  (this avoids race conditions that could happen by passing a file path)
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## In practice: kube-router
-
-- We are going to set up a new cluster
-
-- For this new cluster, we will use kube-router
-
-- kube-router will provide the "pod network"
-
-  (connectivity with pods)
-
-- kube-router will also provide internal service connectivity
-
-  (replacing kube-proxy)
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## How kube-router works
-
-- Very simple architecture
-
-- Does not introduce new CNI plugins
-
-  (uses the `bridge` plugin, with `host-local` for IPAM)
-
-- Pod traffic is routed between nodes
-
-  (no tunnel, no new protocol)
-
-- Internal service connectivity is implemented with IPVS
-
-- Can provide pod network and/or internal service connectivity
-
-- kube-router daemon runs on every node
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## What kube-router does
-
-- Connect to the API server
-
-- Obtain the local node's `podCIDR`
-
-- Inject it into the CNI configuration file
-
-  (we'll use `/etc/cni/net.d/10-kuberouter.conflist`)
-
-- Obtain the addresses of all nodes
-
-- Establish a *full mesh* BGP peering with the other nodes
-
-- Exchange routes over BGP
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## What's BGP?
-
-- BGP (Border Gateway Protocol) is the protocol used between internet routers
-
-- It [scales](https://www.cidr-report.org/as2.0/)
-  pretty [well](https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step)
-  (it is used to announce the 700k CIDR prefixes of the internet)
-
-- It is spoken by many hardware routers from many vendors
-
-- It also has many software implementations (Quagga, Bird, FRR...)
-
-- Experienced network folks generally know it (and appreciate it)
-
-- It also used by Calico (another popular network system for Kubernetes)
-
-- Using BGP allows us to interconnect our "pod network" with other systems
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## The plan
-
-- We'll work in a new cluster (named `kuberouter`)
-
-- We will run a simple control plane (like before)
-
-- ... But this time, the controller manager will allocate `podCIDR` subnets
-
-  (so that we don't have to manually assign subnets to individual nodes)
-
-- We will create a DaemonSet for kube-router
-
-- We will join nodes to the cluster
-
-- The DaemonSet will automatically start a kube-router pod on each node
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Logging into the new cluster
-
-.lab[
-
-- Log into node `kuberouter1`
-
-- Clone the workshop repository:
-  ```bash
-  git clone https://github.com/jpetazzo/container.training
-  ```
-
-- Move to this directory:
-  ```bash
-  cd container.training/compose/kube-router-k8s-control-plane
-  ```
-
-]
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## Checking the CNI configuration
-
-- By default, kubelet gets the CNI configuration from `/etc/cni/net.d`
-
-.lab[
-
-- Check the content of `/etc/cni/net.d`
-
-]
-
-(On most machines, at this point, `/etc/cni/net.d` doesn't even exist).)
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Our control plane
-
-- We will use a Compose file to start the control plane
-
-- It is similar to the one we used with the `kubenet` cluster
-
-- The API server is started with `--allow-privileged`
-
-  (because we will start kube-router in privileged pods)
-
-- The controller manager is started with extra flags too:
-
-  `--allocate-node-cidrs` and `--cluster-cidr`
-
-- We need to edit the Compose file to set the Cluster CIDR
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Starting the control plane
-
-- Our cluster CIDR will be `10.C.0.0/16`
-
-  (where `C` is our cluster number)
-
-.lab[
-
-- Edit the Compose file to set the Cluster CIDR:
-  ```bash
-  vim docker-compose.yaml
-  ```
-
-- Start the control plane:
-  ```bash
-  docker-compose up
-  ```
-
-]
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## The kube-router DaemonSet
-
-- In the same directory, there is a `kuberouter.yaml` file
-
-- It contains the definition for a DaemonSet and a ConfigMap
-
-- Before we load it, we also need to edit it
-
-- We need to indicate the address of the API server
-
-  (because kube-router needs to connect to it to retrieve node information)
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Creating the DaemonSet
-
-- The address of the API server will be `http://A.B.C.D:8080`
-
-  (where `A.B.C.D` is the public address of `kuberouter1`, running the control plane)
-
-.lab[
-
-- Edit the YAML file to set the API server address:
-  ```bash
-  vim kuberouter.yaml
-  ```
-
-- Create the DaemonSet:
-  ```bash
-  kubectl create -f kuberouter.yaml
-  ```
-
-]
-
-Note: the DaemonSet won't create any pods (yet) since there are no nodes (yet).
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Generating the kubeconfig for kubelet
-
-- This is similar to what we did for the `kubenet` cluster
-
-.lab[
-
-- Generate the kubeconfig file (replacing `X.X.X.X` with the address of `kuberouter1`):
-  ```bash
-    kubectl config set-cluster cni --server http://`X.X.X.X`:8080
-    kubectl config set-context cni --cluster cni
-    kubectl config use-context cni
-    cp ~/.kube/config ~/kubeconfig
-  ```
-
-]
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Distributing kubeconfig
-
-- We need to copy that kubeconfig file to the other nodes
-
-.lab[
-
-- Copy `kubeconfig` to the other nodes:
-  ```bash
-    for N in 2 3; do
-    	scp ~/kubeconfig kuberouter$N:
-    done
-  ```
-
-]
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Starting kubelet
-
-- We don't need the `--pod-cidr` option anymore
-
-  (the controller manager will allocate these automatically)
-
-- We need to pass `--network-plugin=cni`
-
-.lab[
-
-- Join the first node:
-   ```bash
-   sudo kubelet --kubeconfig ~/kubeconfig --network-plugin=cni
-   ```
-
-- Open more terminals and join the other nodes:
-  ```bash
-  ssh kuberouter2 sudo kubelet --kubeconfig ~/kubeconfig --network-plugin=cni
-  ssh kuberouter3 sudo kubelet --kubeconfig ~/kubeconfig --network-plugin=cni
-  ```
-
-]
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## Checking the CNI configuration
-
-- At this point, kuberouter should have installed its CNI configuration
-
-  (in `/etc/cni/net.d`)
-
-.lab[
-
-- Check the content of `/etc/cni/net.d`
-
-]
-
-- There should be a file created by kuberouter
-
-- The file should contain the node's podCIDR
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Setting up a test
-
-- Let's create a Deployment and expose it with a Service
-
-.lab[
-
-- Create a Deployment running a web server:
-  ```bash
-  kubectl create deployment web --image=jpetazzo/httpenv
-  ```
-
-- Scale it so that it spans multiple nodes:
-  ```bash
-  kubectl scale deployment web --replicas=5
-  ```
-
-- Expose it with a Service:
-  ```bash
-  kubectl expose deployment web --port=8888
-  ```
-
-]
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-## Checking that everything works
-
-.lab[
-
-- Get the ClusterIP address for the service:
-  ```bash
-  kubectl get svc web
-  ```
-
-- Send a few requests there:
-  ```bash
-  curl `X.X.X.X`:8888
-  ```
-
-]
-
-Note that if you send multiple requests, they are load-balanced in a round robin manner.
-
-This shows that we are using IPVS (vs. iptables, which picked random endpoints).
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## Troubleshooting
-
-- What if we need to check that everything is working properly?
-
-.lab[
-
-- Check the IP addresses of our pods:
-  ```bash
-  kubectl get pods -o wide
-  ```
-
-- Check our routing table:
-  ```bash
-  route -n
-  ip route
-  ```
-
-]
-
-We should see the local pod CIDR connected to `kube-bridge`, and the other nodes' pod CIDRs having individual routes, with each node being the gateway.
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## More troubleshooting
-
-- We can also look at the output of the kube-router pods
-
-  (with `kubectl logs`)
-
-- kube-router also comes with a special shell that gives lots of useful info
-
-  (we can access it with `kubectl exec`)
-
-- But with the current setup of the cluster, these options may not work!
-
-- Why?
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## Trying `kubectl logs` / `kubectl exec`
-
-.lab[
-
-- Try to show the logs of a kube-router pod:
-  ```bash
-  kubectl -n kube-system logs ds/kube-router
-  ```
-
-- Or try to exec into one of the kube-router pods:
-  ```bash
-  kubectl -n kube-system exec kube-router-xxxxx bash
-  ```
-
-]
-
-These commands will give an error message that includes:
-```
-dial tcp: lookup kuberouterX on 127.0.0.11:53: no such host
-```
-
-What does that mean?
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## Internal name resolution
-
-- To execute these commands, the API server needs to connect to kubelet
-
-- By default, it creates a connection using the kubelet's name
-
-  (e.g. `http://kuberouter1:...`)
-
-- This requires our nodes names to be in DNS
-
-- We can change that by setting a flag on the API server:
-
-  `--kubelet-preferred-address-types=InternalIP`
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## Another way to check the logs
-
-- We can also ask the logs directly to the container engine
-
-- First, get the container ID, with `docker ps` or like this:
-  ```bash
-  CID=$(docker ps -q \
-        --filter label=io.kubernetes.pod.namespace=kube-system \
-        --filter label=io.kubernetes.container.name=kube-router)
-  ```
-
-- Then view the logs:
-  ```bash
-  docker logs $CID
-  ```
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: extra-details
-
-## Other ways to distribute routing tables
-
-- We don't need kube-router and BGP to distribute routes
-
-- The list of nodes (and associated `podCIDR` subnets) is available through the API
-
-- This shell snippet generates the commands to add all required routes on a node:
-
-```bash
-NODES=$(kubectl get nodes -o name | cut -d/ -f2)
-for DESTNODE in $NODES; do
-  if [ "$DESTNODE" != "$HOSTNAME" ]; then
-    echo $(kubectl get node $DESTNODE -o go-template="
-      route add -net {{.spec.podCIDR}} gw {{(index .status.addresses 0).address}}")
-  fi
-done
-```
-
-- This could be useful for embedded platforms with very limited resources
-
-  (or lab environments for learning purposes)
-
-???
-
-:EN:- Configuring CNI plugins
-:FR:- Configurer des plugins CNI
-
-.debug[[k8s/cni.md](""/tree/main/slides/k8s/cni.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/distillery-containers.jpg)]
-
----
-
-name: toc-interconnecting-clusters
-class: title
-
- Interconnecting clusters
-
-.nav[
-[Previous part](#toc-the-container-network-interface)
-|
-[Back to table of contents](#toc-part-2)
-|
-[Next part](#toc-cni-internals)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Interconnecting clusters
-
-- We assigned different Cluster CIDRs to each cluster
-
-- This allows us to connect our clusters together
-
-- We will leverage kube-router BGP abilities for that
-
-- We will *peer* each kube-router instance with a *route reflector*
-
-- As a result, we will be able to ping each other's pods
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-## Disclaimers
-
-- There are many methods to interconnect clusters
-
-- Depending on your network implementation, you will use different methods
-
-- The method shown here only works for nodes with direct layer 2 connection
-
-- We will often need to use tunnels or other network techniques
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-## The plan
-
-- Someone will start the *route reflector*
-
-  (typically, that will be the person presenting these slides!)
-
-- We will update our kube-router configuration
-
-- We will add a *peering* with the route reflector
-
-  (instructing kube-router to connect to it and exchange route information)
-
-- We should see the routes to other clusters on our nodes
-
-  (in the output of e.g. `route -n` or `ip route show`)
-
-- We should be able to ping pods of other nodes
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-## Starting the route reflector
-
-- Only do this slide if you are doing this on your own
-
-- There is a Compose file in the `compose/frr-route-reflector` directory
-
-- Before continuing, make sure that you have the IP address of the route reflector
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-## Configuring kube-router
-
-- This can be done in two ways:
-
-  - with command-line flags to the `kube-router` process
-
-  - with annotations to Node objects
-
-- We will use the command-line flags
-
-  (because it will automatically propagate to all nodes)
-
-.footnote[Note: with Calico, this is achieved by creating a BGPPeer CRD.]
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-## Updating kube-router configuration
-
-- We need to pass two command-line flags to the kube-router process
-
-.lab[
-
-- Edit the `kuberouter.yaml` file
-
-- Add the following flags to the kube-router arguments:
-  ```
-  - "--peer-router-ips=`X.X.X.X`"
-  - "--peer-router-asns=64512"
-  ```
-  (Replace `X.X.X.X` with the route reflector address)
-
-- Update the DaemonSet definition:
-  ```bash
-  kubectl apply -f kuberouter.yaml
-  ```
-
-]
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-## Restarting kube-router
-
-- The DaemonSet will not update the pods automatically
-
-  (it is using the default `updateStrategy`, which is `OnDelete`)
-
-- We will therefore delete the pods
-
-  (they will be recreated with the updated definition)
-
-.lab[
-
-- Delete all the kube-router pods:
-  ```bash
-  kubectl delete pods -n kube-system -l k8s-app=kube-router
-  ```
-
-]
-
-Note: the other `updateStrategy` for a DaemonSet is RollingUpdate.
-<br/>
-For critical services, we might want to precisely control the update process.
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-## Checking peering status
-
-- We can see informative messages in the output of kube-router:
-  ```
-  time="2019-04-07T15:53:56Z" level=info msg="Peer Up"
-  Key=X.X.X.X State=BGP_FSM_OPENCONFIRM Topic=Peer
-  ```
-
-- We should see the routes of the other clusters show up
-
-- For debugging purposes, the reflector also exports a route to 1.0.0.2/32
-
-- That route will show up like this:
-  ```
-  1.0.0.2     172.31.X.Y    255.255.255.255 UGH   0      0        0 eth0
-  ```
-
-- We should be able to ping the pods of other clusters!
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-## If we wanted to do more ...
-
-- kube-router can also export ClusterIP addresses
-
-  (by adding the flag `--advertise-cluster-ip`)
-
-- They are exported individually (as /32)
-
-- This would allow us to easily access other clusters' services
-
-  (without having to resolve the individual addresses of pods)
-
-- Even better if it's combined with DNS integration
-
-  (to facilitate name → ClusterIP resolution)
-
-???
-
-:EN:- Interconnecting clusters
-:FR:- Interconnexion de clusters
-
-.debug[[k8s/interco.md](""/tree/main/slides/k8s/interco.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/lots-of-containers.jpg)]
-
----
-
-name: toc-cni-internals
-class: title
-
- CNI internals
-
-.nav[
-[Previous part](#toc-interconnecting-clusters)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-api-server-availability)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# CNI internals
-
-- Kubelet looks for a CNI configuration file
-
-  (by default, in `/etc/cni/net.d`)
-
-- Note: if we have multiple files, the first one will be used
-
-  (in lexicographic order)
-
-- If no configuration can be found, kubelet holds off on creating containers
-
-  (except if they are using `hostNetwork`)
-
-- Let's see how exactly plugins are invoked!
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## General principle
-
-- A plugin is an executable program
-
-- It is invoked with by kubelet to set up / tear down networking for a container
-
-- It doesn't take any command-line argument
-
-- However, it uses environment variables to know what to do, which container, etc.
-
-- It reads JSON on stdin, and writes back JSON on stdout
-
-- There will generally be multiple plugins invoked in a row
-
-  (at least IPAM + network setup; possibly more)
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## Environment variables
-
-- `CNI_COMMAND`: `ADD`, `DEL`, `CHECK`, or `VERSION`
-
-- `CNI_CONTAINERID`: opaque identifier
-
-  (container ID of the "sandbox", i.e. the container running the `pause` image)
-
-- `CNI_NETNS`: path to network namespace pseudo-file
-
-  (e.g. `/var/run/netns/cni-0376f625-29b5-7a21-6c45-6a973b3224e5`)
-
-- `CNI_IFNAME`: interface name, usually `eth0`
-
-- `CNI_PATH`: path(s) with plugin executables (e.g. `/opt/cni/bin`)
-
-- `CNI_ARGS`: "extra arguments" (see next slide)
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## `CNI_ARGS`
-
-- Extra key/value pair arguments passed by "the user"
-
-- "The user", here, is "kubelet" (or in an abstract way, "Kubernetes")
-
-- This is used to pass the pod name and namespace to the CNI plugin
-
-- Example:
-  ```
-  IgnoreUnknown=1
-  K8S_POD_NAMESPACE=default
-  K8S_POD_NAME=web-96d5df5c8-jcn72
-  K8S_POD_INFRA_CONTAINER_ID=016493dbff152641d334d9828dab6136c1ff...
-  ```
-
-Note that technically, it's a `;`-separated list, so it really looks like this:
-```
-CNI_ARGS=IgnoreUnknown=1;K8S_POD_NAMESPACE=default;K8S_POD_NAME=web-96d...
-```
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## JSON in, JSON out
-
-- The plugin reads its configuration on stdin
-
-- It writes back results in JSON
-
-  (e.g. allocated address, routes, DNS...)
-
-⚠️ "Plugin configuration" is not always the same as "CNI configuration"!
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## Conf vs Conflist
-
-- The CNI configuration can be a single plugin configuration
-
-  - it will then contain a `type` field in the top-most structure
-
-  - it will be passed "as-is"
-
-- It can also be a "conflist", containing a chain of plugins
-
-  (it will then contain a `plugins` field in the top-most structure)
-
-- Plugins are then invoked in order (reverse order for `DEL` action)
-
-- In that case, the input of the plugin is not the whole configuration
-
-  (see details on next slide)
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## List of plugins
-
-- When invoking a plugin in a list, the JSON input will be:
-
-  - the configuration of the plugin
-
-  - augmented with `name` (matching the conf list `name`)
-
-  - augmented with `prevResult` (which will be the output of the previous plugin)
-
-- Conceptually, a plugin (generally the first one) will do the "main setup"
-
-- Other plugins can do tuning / refinement (firewalling, traffic shaping...)
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## Analyzing plugins
-
-- Let's see what goes in and out of our CNI plugins!
-
-- We will create a fake plugin that:
-
-  - saves its environment and input
-
-  - executes the real plugin with the saved input
-
-  - saves the plugin output
-
-  - passes the saved output
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## Our fake plugin
-
-```bash
-#!/bin/sh
-PLUGIN=$(basename $0)
-cat > /tmp/cni.$$.$PLUGIN.in
-env | sort > /tmp/cni.$$.$PLUGIN.env
-echo "PPID=$PPID, $(readlink /proc/$PPID/exe)" > /tmp/cni.$$.$PLUGIN.parent
-$0.real < /tmp/cni.$$.$PLUGIN.in > /tmp/cni.$$.$PLUGIN.out
-EXITSTATUS=$?
-cat /tmp/cni.$$.$PLUGIN.out
-exit $EXITSTATUS
-```
-
-Save this script as `/opt/cni/bin/debug` and make it executable.
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## Substituting the fake plugin
-
-- For each plugin that we want to instrument:
-
-  - rename the plugin from e.g. `ptp` to `ptp.real`
-
-  - symlink `ptp` to our `debug` plugin
-
-- There is no need to change the CNI configuration or restart kubelet
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-## Create some pods and looks at the results
-
-- Create a pod
-
-- For each instrumented plugin, there will be files in `/tmp`:
-
-  `cni.PID.pluginname.in` (JSON input)
-
-  `cni.PID.pluginname.env` (environment variables)
-
-  `cni.PID.pluginname.parent` (parent process information)
-
-  `cni.PID.pluginname.out` (JSON output)
-
-❓️ What is calling our plugins?
-
-???
-
-:EN:- Deep dive into CNI internals
-:FR:- La Container Network Interface (CNI) en détails
-
-.debug[[k8s/cni-internals.md](""/tree/main/slides/k8s/cni-internals.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/plastic-containers.JPG)]
-
----
-
-name: toc-api-server-availability
-class: title
-
- API server availability
-
-.nav[
-[Previous part](#toc-cni-internals)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-securing-the-control-plane)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# API server availability
-
-- When we set up a node, we need the address of the API server:
-
-  - for kubelet
-
-  - for kube-proxy
-
-  - sometimes for the pod network system (like kube-router)
-
-- How do we ensure the availability of that endpoint?
-
-  (what if the node running the API server goes down?)
-
-.debug[[k8s/apilb.md](""/tree/main/slides/k8s/apilb.md)]
----
-
-## Option 1: external load balancer
-
-- Set up an external load balancer
-
-- Point kubelet (and other components) to that load balancer
-
-- Put the node(s) running the API server behind that load balancer
-
-- Update the load balancer if/when an API server node needs to be replaced
-
-- On cloud infrastructures, some mechanisms provide automation for this
-
-  (e.g. on AWS, an Elastic Load Balancer + Auto Scaling Group)
-
-- [Example in Kubernetes The Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/08-bootstrapping-kubernetes-controllers.md#the-kubernetes-frontend-load-balancer)
-
-.debug[[k8s/apilb.md](""/tree/main/slides/k8s/apilb.md)]
----
-
-## Option 2: local load balancer
-
-- Set up a load balancer (like NGINX, HAProxy...) on *each* node
-
-- Configure that load balancer to send traffic to the API server node(s)
-
-- Point kubelet (and other components) to `localhost`
-
-- Update the load balancer configuration when API server nodes are updated
-
-.debug[[k8s/apilb.md](""/tree/main/slides/k8s/apilb.md)]
----
-
-## Updating the local load balancer config
-
-- Distribute the updated configuration (push)
-
-- Or regularly check for updates (pull)
-
-- The latter requires an external, highly available store
- 
-  (it could be an object store, an HTTP server, or even DNS...)
-
-- Updates can be facilitated by a DaemonSet
-
-  (but remember that it can't be used when installing a new node!)
-
-.debug[[k8s/apilb.md](""/tree/main/slides/k8s/apilb.md)]
----
-
-## Option 3: DNS records
-
-- Put all the API server nodes behind a round-robin DNS
-
-- Point kubelet (and other components) to that name
-
-- Update the records when needed
-
-- Note: this option is not officially supported
-
-  (but since kubelet supports reconnection anyway, it *should* work)
-
-.debug[[k8s/apilb.md](""/tree/main/slides/k8s/apilb.md)]
----
-
-## Option 4: ....................
-
-- Many managed clusters expose a high-availability API endpoint
-
-  (and you don't have to worry about it)
-
-- You can also use HA mechanisms that you're familiar with
-
-  (e.g. virtual IPs)
-
-- Tunnels are also fine
-
-  (e.g. [k3s](https://k3s.io/) uses a tunnel to allow each node to contact the API server)
-
-???
-
-:EN:- Ensuring API server availability
-:FR:- Assurer la disponibilité du serveur API
-
-.debug[[k8s/apilb.md](""/tree/main/slides/k8s/apilb.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-1.jpg)]
-
----
-
-name: toc-securing-the-control-plane
-class: title
-
- Securing the control plane
-
-.nav[
-[Previous part](#toc-api-server-availability)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-extra-content)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Securing the control plane
-
-- Many components accept connections (and requests) from others:
-
-  - API server
-
-  - etcd
-
-  - kubelet
-
-- We must secure these connections:
-
-  - to deny unauthorized requests
-
-  - to prevent eavesdropping secrets, tokens, and other sensitive information
-
-- Disabling authentication and/or authorization is **strongly discouraged**
-
-  (but it's possible to do it, e.g. for learning / troubleshooting purposes)
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## Authentication and authorization
-
-- Authentication (checking "who you are") is done with mutual TLS
-
- (both the client and the server need to hold a valid certificate)
-
-- Authorization (checking "what you can do") is done in different ways
-
-  - the API server implements a sophisticated permission logic (with RBAC)
-  
-  - some services will defer authorization to the API server (through webhooks)
-
-  - some services require a certificate signed by a particular CA / sub-CA
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## In practice
-
-- We will review the various communication channels in the control plane
-
-- We will describe how they are secured
-
-- When TLS certificates are used, we will indicate:
-
-  - which CA signs them
-
-  - what their subject (CN) should be, when applicable
-
-- We will indicate how to configure security (client- and server-side)
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## etcd peers
-
-- Replication and coordination of etcd happens on a dedicated port
-
-  (typically port 2380; the default port for normal client connections is 2379)
-
-- Authentication uses TLS certificates with a separate sub-CA
-
-  (otherwise, anyone with a Kubernetes client certificate could access etcd!)
-
-- The etcd command line flags involved are:
-
-   `--peer-client-cert-auth=true` to activate it
-
-   `--peer-cert-file`, `--peer-key-file`, `--peer-trusted-ca-file`
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## etcd clients
-
-- The only¹ thing that connects to etcd is the API server
-
-- Authentication uses TLS certificates with a separate sub-CA
-
-  (for the same reasons as for etcd inter-peer authentication)
-
-- The etcd command line flags involved are:
-
-  `--client-cert-auth=true` to activate it
-
-  `--trusted-ca-file`, `--cert-file`, `--key-file`
-
-- The API server command line flags involved are:
-
-  `--etcd-cafile`, `--etcd-certfile`, `--etcd-keyfile`
-
-.footnote[¹Technically, there is also the etcd healthcheck. Let's ignore it for now.]
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## etcd authorization
-
-- etcd supports RBAC, but Kubernetes doesn't use it by default
-
-  (note: etcd RBAC is completely different from Kubernetes RBAC!)
-
-- By default, etcd access is "all or nothing"
-
-  (if you have a valid certificate, you get in)
-
-- Be very careful if you use the same root CA for etcd and other things
-
-  (if etcd trusts the root CA, then anyone with a valid cert gets full etcd access)
-
-- For more details, check the following resources:
-
-  - [etcd documentation on authentication](https://etcd.io/docs/current/op-guide/authentication/)
-
-  - [PKI The Wrong Way](https://www.youtube.com/watch?v=gcOLDEzsVHI) at KubeCon NA 2020
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-
-## API server clients
-
-- The API server has a sophisticated authentication and authorization system
-
-- For connections coming from other components of the control plane:
-
-  - authentication uses certificates (trusting the certificates' subject or CN)
-
-  - authorization uses whatever mechanism is enabled (most oftentimes, RBAC)
-
-- The relevant API server flags are:
-
-  `--client-ca-file`, `--tls-cert-file`, `--tls-private-key-file`
-
-- Each component connecting to the API server takes a `--kubeconfig` flag
-
-  (to specify a kubeconfig file containing the CA cert, client key, and client cert)
-
-- Yes, that kubeconfig file follows the same format as our `~/.kube/config` file!
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## Kubelet and API server
-
-- Communication between kubelet and API server can be established both ways
-
-- Kubelet → API server:
-
-  - kubelet registers itself ("hi, I'm node42, do you have work for me?")
-
-  - connection is kept open and re-established if it breaks
-
-  - that's how the kubelet knows which pods to start/stop
-
-- API server → kubelet:
-
-  - used to retrieve logs, exec, attach to containers
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## Kubelet → API server
-
-- Kubelet is started with `--kubeconfig` with API server information
-
-- The client certificate of the kubelet will typically have:
-
-  `CN=system:node:<nodename>` and groups `O=system:nodes`
-
-- Nothing special on the API server side
-
-  (it will authenticate like any other client)
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## API server → kubelet
-
-- Kubelet is started with the flag `--client-ca-file`
-
-  (typically using the same CA as the API server)
-
-- API server will use a dedicated key pair when contacting kubelet
-
-  (specified with `--kubelet-client-certificate` and `--kubelet-client-key`)
-
-- Authorization uses webhooks
-
-  (enabled with `--authorization-mode=Webhook` on kubelet)
-
-- The webhook server is the API server itself
-
-  (the kubelet sends back a request to the API server to ask, "can this person do that?")
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## Scheduler
-
-- The scheduler connects to the API server like an ordinary client
-
-- The certificate of the scheduler will have `CN=system:kube-scheduler`
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## Controller manager
-
-- The controller manager is also a normal client to the API server
-
-- Its certificate will have `CN=system:kube-controller-manager`
-
-- If we use the CSR API, the controller manager needs the CA cert and key
-
-  (passed with flags `--cluster-signing-cert-file` and `--cluster-signing-key-file`)
-
-- We usually want the controller manager to generate tokens for service accounts
-
-- These tokens deserve some details (on the next slide!)
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-class: extra-details
-
-## How are these permissions set up?
-
-- A bunch of roles and bindings are defined as constants in the API server code:
-
-  [auth/authorizer/rbac/bootstrappolicy/policy.go](https://github.com/kubernetes/kubernetes/blob/release-1.19/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/policy.go#L188)
-
-- They are created automatically when the API server starts:
-
-  [registry/rbac/rest/storage_rbac.go](https://github.com/kubernetes/kubernetes/blob/release-1.19/pkg/registry/rbac/rest/storage_rbac.go#L140)
-
-- We must use the correct Common Names (`CN`) for the control plane certificates
-
-  (since the bindings defined above refer to these common names)
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## Service account tokens
-
-- Each time we create a service account, the controller manager generates a token
-
-- These tokens are JWT tokens, signed with a particular key
-
-- These tokens are used for authentication with the API server
-
-  (and therefore, the API server needs to be able to verify their integrity)
-
-- This uses another keypair:
-
-  - the private key (used for signature) is passed to the controller manager
-    <br/>(using flags `--service-account-private-key-file` and `--root-ca-file`)
-
-  - the public key (used for verification) is passed to the API server
-    <br/>(using flag `--service-account-key-file`)
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## kube-proxy
-
-- kube-proxy is "yet another API server client"
-
-- In many clusters, it runs as a Daemon Set
-
-- In that case, it will have its own Service Account and associated permissions
-
-- It will authenticate using the token of that Service Account
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## Webhooks
-
-- We mentioned webhooks earlier; how does that really work?
-
-- The Kubernetes API has special resource types to check permissions
-
-- One of them is SubjectAccessReview
-
-- To check if a particular user can do a particular action on a particular resource:
-
-  - we prepare a SubjectAccessReview object
-
-  - we send that object to the API server
-
-  - the API server responds with allow/deny (and optional explanations)
-
-- Using webhooks for authorization = sending SAR to authorize each request
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-## Subject Access Review
-
-Here is an example showing how to check if `jean.doe` can `get` some `pods` in `kube-system`:
-
-```bash
-kubectl -v9 create -f- <<EOF
-apiVersion: authorization.k8s.io/v1
-kind: SubjectAccessReview
-spec:
-  user: jean.doe
-  groups:
-  - foo
-  - bar
-  resourceAttributes:
-    #group: blah.k8s.io
-    namespace: kube-system
-    resource: pods
-    verb: get
-    #name: web-xyz1234567-pqr89
-EOF
-```
-
-???
-
-:EN:- Control plane authentication
-:FR:- Sécurisation du plan de contrôle
-
-.debug[[k8s/control-plane-auth.md](""/tree/main/slides/k8s/control-plane-auth.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-2.jpg)]
-
----
-
-name: toc-extra-content
-class: title
-
- (Extra content)
-
-.nav[
-[Previous part](#toc-securing-the-control-plane)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-static-pods)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg)]
-
----
-
-name: toc-extra-content
-class: title
-
- (Extra content)
-
-.nav[
-[Previous part](#toc-securing-the-control-plane)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-static-pods)
-]
-
-.debug[(automatically generated title slide)]
-
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-2.jpg)]
-
----
-
-name: toc-extra-content
-class: title
-
- (Extra content)
-
-.nav[
-[Previous part](#toc-securing-the-control-plane)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-static-pods)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# (Extra content)
-
-.debug[[kube-adv.yml](""/tree/main/slides/kube-adv.yml)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/two-containers-on-a-truck.jpg)]
-
----
-
-name: toc-static-pods
-class: title
-
- Static pods
-
-.nav[
-[Previous part](#toc-extra-content)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-upgrading-clusters)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Static pods
-
-- Hosting the Kubernetes control plane on Kubernetes has advantages:
-
-  - we can use Kubernetes' replication and scaling features for the control plane
-
-  - we can leverage rolling updates to upgrade the control plane
-
-- However, there is a catch:
-
-  - deploying on Kubernetes requires the API to be available
-
-  - the API won't be available until the control plane is deployed
-
-- How can we get out of that chicken-and-egg problem?
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## A possible approach
-
-- Since each component of the control plane can be replicated...
-
-- We could set up the control plane outside of the cluster
-
-- Then, once the cluster is fully operational, create replicas running on the cluster
-
-- Finally, remove the replicas that are running outside of the cluster
-
-*What could possibly go wrong?*
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## Sawing off the branch you're sitting on
-
-- What if anything goes wrong?
-
-  (During the setup or at a later point)
-
-- Worst case scenario, we might need to:
-
-  - set up a new control plane (outside of the cluster)
-
-  - restore a backup from the old control plane
-
-  - move the new control plane to the cluster (again)
-
-- This doesn't sound like a great experience
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## Static pods to the rescue
-
-- Pods are started by kubelet (an agent running on every node)
-
-- To know which pods it should run, the kubelet queries the API server
-
-- The kubelet can also get a list of *static pods* from:
-
-  - a directory containing one (or multiple) *manifests*, and/or
-
-  - a URL (serving a *manifest*)
-
-- These "manifests" are basically YAML definitions
-
-  (As produced by `kubectl get pod my-little-pod -o yaml`)
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## Static pods are dynamic
-
-- Kubelet will periodically reload the manifests
-
-- It will start/stop pods accordingly
-
-  (i.e. it is not necessary to restart the kubelet after updating the manifests)
-
-- When connected to the Kubernetes API, the kubelet will create *mirror pods*
-
-- Mirror pods are copies of the static pods
-
-  (so they can be seen with e.g. `kubectl get pods`)
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## Bootstrapping a cluster with static pods
-
-- We can run control plane components with these static pods
-
-- They can start without requiring access to the API server
-
-- Once they are up and running, the API becomes available
-
-- These pods are then visible through the API
-
-  (We cannot upgrade them from the API, though)
-
-*This is how kubeadm has initialized our clusters.*
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## Static pods vs normal pods
-
-- The API only gives us read-only access to static pods
-
-- We can `kubectl delete` a static pod...
-
-  ...But the kubelet will re-mirror it immediately
-
-- Static pods can be selected just like other pods
-
-  (So they can receive service traffic)
-
-- A service can select a mixture of static and other pods
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## From static pods to normal pods
-
-- Once the control plane is up and running, it can be used to create normal pods
-
-- We can then set up a copy of the control plane in normal pods
-
-- Then the static pods can be removed
-
-- The scheduler and the controller manager use leader election
-
-  (Only one is active at a time; removing an instance is seamless)
-
-- Each instance of the API server adds itself to the `kubernetes` service
-
-- Etcd will typically require more work!
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## From normal pods back to static pods
-
-- Alright, but what if the control plane is down and we need to fix it?
-
-- We restart it using static pods!
-
-- This can be done automatically with a “pod checkpointer”
-
-- The pod checkpointer automatically generates manifests of running pods
-
-- The manifests are used to restart these pods if API contact is lost
-
-- This pattern is implemented in [openshift/pod-checkpointer-operator] and [bootkube checkpointer]
-
-- Unfortunately, as of 2021, both seem abandoned / unmaintained 😢
-
-[openshift/pod-checkpointer-operator]: https://github.com/openshift/pod-checkpointer-operator
-[bootkube checkpointer]: https://github.com/kubernetes-retired/bootkube/blob/master/cmd/checkpoint/README.md
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## Where should the control plane run?
-
-*Is it better to run the control plane in static pods, or normal pods?*
-
-- If I'm a *user* of the cluster: I don't care, it makes no difference to me
-
-- What if I'm an *admin*, i.e. the person who installs, upgrades, repairs... the cluster?
-
-- If I'm using a managed Kubernetes cluster (AKS, EKS, GKE...) it's not my problem
-
-  (I'm not the one setting up and managing the control plane)
-
-- If I already picked a tool (kubeadm, kops...) to set up my cluster, the tool decides for me
-
-- What if I haven't picked a tool yet, or if I'm installing from scratch?
-
-  - static pods = easier to set up, easier to troubleshoot, less risk of outage
-
-  - normal pods = easier to upgrade, easier to move (if nodes need to be shut down)
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-## Static pods in action
-
-- On our clusters, the `staticPodPath` is `/etc/kubernetes/manifests`
-
-.lab[
-
-- Have a look at this directory:
-  ```bash
-  ls -l /etc/kubernetes/manifests
-  ```
-
-]
-
-We should see YAML files corresponding to the pods of the control plane.
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-class: static-pods-exercise
-
-## Running a static pod
-
-- We are going to add a pod manifest to the directory, and kubelet will run it
-
-.lab[
-
-- Copy a manifest to the directory:
-  ```bash
-  sudo cp ~/container.training/k8s/just-a-pod.yaml /etc/kubernetes/manifests
-  ```
-
-- Check that it's running:
-  ```bash
-  kubectl get pods
-  ```
-
-]
-
-The output should include a pod named `hello-node1`.
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-class: static-pods-exercise
-
-## Remarks
-
-In the manifest, the pod was named `hello`.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: hello
-  namespace: default
-spec:
-  containers:
-  - name: hello
-    image: nginx
-```
-
-The `-node1` suffix was added automatically by kubelet.
-
-If we delete the pod (with `kubectl delete`), it will be recreated immediately.
-
-To delete the pod, we need to delete (or move) the manifest file.
-
-???
-
-:EN:- Static pods
-:FR:- Les *static pods*
-
-.debug[[k8s/staticpods.md](""/tree/main/slides/k8s/staticpods.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/wall-of-containers.jpeg)]
-
----
-
-name: toc-upgrading-clusters
-class: title
-
- Upgrading clusters
-
-.nav[
-[Previous part](#toc-static-pods)
-|
-[Back to table of contents](#toc-part-3)
-|
-[Next part](#toc-kustomize)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Upgrading clusters
-
-- It's *recommended* to run consistent versions across a cluster
-
-  (mostly to have feature parity and latest security updates)
-
-- It's not *mandatory*
-
-  (otherwise, cluster upgrades would be a nightmare!)
-
-- Components can be upgraded one at a time without problems
-
-<!-- ##VERSION## -->
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Checking what we're running
-
-- It's easy to check the version for the API server
-
-.lab[
-
-- Log into node `oldversion1`
-
-- Check the version of kubectl and of the API server:
-  ```bash
-  kubectl version
-  ```
-
-]
-
-- In a HA setup with multiple API servers, they can have different versions
-
-- Running the command above multiple times can return different values
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Node versions
-
-- It's also easy to check the version of kubelet
-
-.lab[
-
-- Check node versions (includes kubelet, kernel, container engine):
-  ```bash
-  kubectl get nodes -o wide
-  ```
-
-]
-
-- Different nodes can run different kubelet versions
-
-- Different nodes can run different kernel versions
-
-- Different nodes can run different container engines
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Control plane versions
-
-- If the control plane is self-hosted (running in pods), we can check it
-
-.lab[
-
-- Show image versions for all pods in `kube-system` namespace:
-  ```bash
-    kubectl --namespace=kube-system get pods -o json \
-            | jq -r '
-              .items[]
-              | [.spec.nodeName, .metadata.name]
-                + 
-                (.spec.containers[].image | split(":"))
-              | @tsv
-              ' \
-            | column -t
-  ```
-
-]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## What version are we running anyway?
-
-- When I say, "I'm running Kubernetes 1.20", is that the version of:
-
-  - kubectl
-
-  - API server
-
-  - kubelet
-
-  - controller manager
-
-  - something else?
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Other versions that are important
-
-- etcd
-
-- kube-dns or CoreDNS
-
-- CNI plugin(s)
-
-- Network controller, network policy controller
-
-- Container engine
-
-- Linux kernel
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## General guidelines
-
-- To update a component, use whatever was used to install it
-
-- If it's a distro package, update that distro package
-
-- If it's a container or pod, update that container or pod
-
-- If you used configuration management, update with that
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Know where your binaries come from
-
-- Sometimes, we need to upgrade *quickly*
-
-  (when a vulnerability is announced and patched)
-
-- If we are using an installer, we should:
-
-  - make sure it's using upstream packages
-
-  - or make sure that whatever packages it uses are current
-
-  - make sure we can tell it to pin specific component versions
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Important questions
-
-- Should we upgrade the control plane before or after the kubelets?
-
-- Within the control plane, should we upgrade the API server first or last?
-
-- How often should we upgrade?
-
-- How long are versions maintained?
-
-- All the answers are in [the documentation about version skew policy](https://kubernetes.io/docs/setup/release/version-skew-policy/)!
-
-- Let's review the key elements together ...
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Kubernetes uses semantic versioning
-
-- Kubernetes versions look like MAJOR.MINOR.PATCH; e.g. in 1.20.15:
-
-  - MAJOR = 1
-  - MINOR = 20
-  - PATCH = 15
-
-- It's always possible to mix and match different PATCH releases
-
-  (e.g. 1.20.0 and 1.20.15 are compatible)
-
-- It is recommended to run the latest PATCH release
-
-  (but it's mandatory only when there is a security advisory)
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Version skew
-
-- API server must be more recent than its clients (kubelet and control plane)
-
-- ... Which means it must always be upgraded first
-
-- All components support a difference of one¹ MINOR version
-
-- This allows live upgrades (since we can mix e.g. 1.20 and 1.21)
-
-- It also means that going from 1.20 to 1.22 requires going through 1.21
-
-.footnote[¹Except kubelet, which can be up to two MINOR behind API server,
-and kubectl, which can be one MINOR ahead or behind API server.]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Release cycle
-
-- There is a new PATCH relese whenever necessary
-
-  (every few weeks, or "ASAP" when there is a security vulnerability)
-
-- There is a new MINOR release every 3 months (approximately)
-
-- At any given time, three MINOR releases are maintained
-
-- ... Which means that MINOR releases are maintained approximately 9 months
-
-- We should expect to upgrade at least every 3 months (on average)
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## In practice
-
-- We are going to update a few cluster components
-
-- We will change the kubelet version on one node
-
-- We will change the version of the API server
-
-- We will work with cluster `oldversion` (nodes `oldversion1`, `oldversion2`, `oldversion3`)
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Updating the API server
-
-- This cluster has been deployed with kubeadm
-
-- The control plane runs in *static pods*
-
-- These pods are started automatically by kubelet
-
-  (even when kubelet can't contact the API server)
-
-- They are defined in YAML files in `/etc/kubernetes/manifests`
-
-  (this path is set by a kubelet command-line flag)
-
-- kubelet automatically updates the pods when the files are changed
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Changing the API server version
-
-- We will edit the YAML file to use a different image version
-
-.lab[
-
-- Log into node `oldversion1`
-
-- Check API server version:
-  ```bash
-  kubectl version
-  ```
-
-- Edit the API server pod manifest:
-  ```bash
-  sudo vim /etc/kubernetes/manifests/kube-apiserver.yaml
-  ```
-
-- Look for the `image:` line, and update it to e.g. `v1.24.0`
-
-]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Checking what we've done
-
-- The API server will be briefly unavailable while kubelet restarts it
-
-.lab[
-
-- Check the API server version:
-  ```bash
-  kubectl version
-  ```
-
-]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Was that a good idea?
-
---
-
-**No!**
-
---
-
-- Remember the guideline we gave earlier:
-
-  *To update a component, use whatever was used to install it.*
-
-- This control plane was deployed with kubeadm
-
-- We should use kubeadm to upgrade it!
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Updating the whole control plane
-
-- Let's make it right, and use kubeadm to upgrade the entire control plane
-
-  (note: this is possible only because the cluster was installed with kubeadm)
-
-.lab[
-
-- Check what will be upgraded:
-  ```bash
-  sudo kubeadm upgrade plan
-  ```
-
-]
-
-Note 1: kubeadm thinks that our cluster is running 1.24.0.
-<br/>It is confused by our manual upgrade of the API server!
-
-Note 2: kubeadm itself is still version 1.20.15..
-<br/>It doesn't know how to upgrade do 1.21.X.
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Upgrading kubeadm
-
-- First things first: we need to upgrade kubeadm
-
-.lab[
-
-- Upgrade kubeadm:
-  ```
-  sudo apt install kubeadm
-  ```
-
-- Check what kubeadm tells us:
-  ```
-  sudo kubeadm upgrade plan
-  ```
-
-]
-
-Problem: kubeadm doesn't know know how to handle
-upgrades from version 1.20.
-
-This is because we installed version 1.24 (or even later).
-
-We need to install kubeadm version 1.21.X.
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Downgrading kubeadm
-
-- We need to go back to version 1.21.X.
-
-.lab[
-
-- View available versions for package `kubeadm`:
-  ```bash
-  apt show kubeadm -a | grep ^Version | grep 1.21
-  ```
-
-- Downgrade kubeadm:
-  ```
-  sudo apt install kubeadm=1.21.0-00
-  ```
-
-- Check what kubeadm tells us:
-  ```
-  sudo kubeadm upgrade plan
-  ```
-
-]
-
-kubeadm should now agree to upgrade to 1.21.X.
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Upgrading the cluster with kubeadm
-
-- Ideally, we should revert our `image:` change
-
-  (so that kubeadm executes the right migration steps)
-
-- Or we can try the upgrade anyway
-
-.lab[
-
-- Perform the upgrade:
-  ```bash
-  sudo kubeadm upgrade apply v1.19.8
-  ```
-
-]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Updating kubelet
-
-- These nodes have been installed using the official Kubernetes packages
-
-- We can therefore use `apt` or `apt-get`
-
-.lab[
-
-- Log into node `oldversion3`
-
-- View available versions for package `kubelet`:
-  ```bash
-  apt show kubelet -a | grep ^Version
-  ```
-
-- Upgrade kubelet:
-  ```bash
-  sudo apt install kubelet=1.19.8-00
-  ```
-
-]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Checking what we've done
-
-.lab[
-
-- Log into node `oldversion1`
-
-- Check node versions:
-  ```bash
-  kubectl get nodes -o wide
-  ```
-
-- Create a deployment and scale it to make sure that the node still works
-
-]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Was that a good idea?
-
---
-
-**Almost!**
-
---
-
-- Yes, kubelet was installed with distribution packages
-
-- However, kubeadm took care of configuring kubelet
-
-  (when doing `kubeadm join ...`)
-
-- We were supposed to run a special command *before* upgrading kubelet!
-
-- That command should be executed on each node
-
-- It will download the kubelet configuration generated by kubeadm
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Upgrading kubelet the right way
-
-- We need to upgrade kubeadm, upgrade kubelet config, then upgrade kubelet
-
-  (after upgrading the control plane)
-
-.lab[
-
-- Download the configuration on each node, and upgrade kubelet:
-  ```bash
-    for N in 1 2 3; do
-      ssh oldversion$N "
-        sudo apt install kubeadm=1.21.14-00 &&
-        sudo kubeadm upgrade node &&
-        sudo apt install kubelet=1.21.14-00"
-    done
-  ```
-]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-## Checking what we've done
-
-- All our nodes should now be updated to version 1.21.14
-
-.lab[
-
-- Check nodes versions:
-  ```bash
-  kubectl get nodes -o wide
-  ```
-
-]
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-class: extra-details
-
-## Skipping versions
-
-- This example worked because we went from 1.20 to 1.21
-
-- If you are upgrading from e.g. 1.16, you will have to go through 1.17 first
-
-- This means upgrading kubeadm to 1.17.X, then using it to upgrade the cluster
-
-- Then upgrading kubeadm to 1.18.X, etc.
-
-- **Make sure to read the release notes before upgrading!**
-
-???
-
-:EN:- Best practices for cluster upgrades
-:EN:- Example: upgrading a kubeadm cluster
-
-:FR:- Bonnes pratiques pour la mise à jour des clusters
-:FR:- Exemple : mettre à jour un cluster kubeadm
-
-.debug[[k8s/cluster-upgrade.md](""/tree/main/slides/k8s/cluster-upgrade.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/catene-de-conteneurs.jpg)]
-
----
-
-name: toc-kustomize
-class: title
-
- Kustomize
-
-.nav[
-[Previous part](#toc-upgrading-clusters)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-managing-stacks-with-helm)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Kustomize
-
-- Kustomize lets us transform Kubernetes resources:
-
-  *YAML + kustomize → new YAML*
-
-- Starting point = valid resource files
-
-  (i.e. something that we could load with `kubectl apply -f`)
-
-- Recipe = a *kustomization* file
-
-  (describing how to transform the resources)
-
-- Result = new resource files
-
-  (that we can load with `kubectl apply -f`)
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Pros and cons
-
-- Relatively easy to get started
-
-  (just get some existing YAML files)
-
-- Easy to leverage existing "upstream" YAML files
-
-  (or other *kustomizations*)
-
-- Somewhat integrated with `kubectl`
-
-  (but only "somewhat" because of version discrepancies)
-
-- Less complex than e.g. Helm, but also less powerful
-
-- No central index like the Artifact Hub (but is there a need for it?)
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Kustomize in a nutshell
-
-- Get some valid YAML (our "resources")
-
-- Write a *kustomization* (technically, a file named `kustomization.yaml`)
-
-  - reference our resources
-
-  - reference other kustomizations
-
-  - add some *patches*
-
-  - ...
-
-- Use that kustomization either with `kustomize build` or `kubectl apply -k`
-
-- Write new kustomizations referencing the first one to handle minor differences
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## A simple kustomization
-
-This features a Deployment, Service, and Ingress (in separate files),
-and a couple of patches (to change the number of replicas and the hostname
-used in the Ingress).
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-patchesStrategicMerge:
-- scale-deployment.yaml
-- ingress-hostname.yaml
-resources:
-- deployment.yaml
-- service.yaml
-- ingress.yaml
-```
-
-On the next slide, let's see a more complex example ...
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## A more complex Kustomization
-
-.small[
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-commonAnnotations:
-  mood: 😎
-commonLabels:
-  add-this-to-all-my-resources: please
-namePrefix: prod-
-patchesStrategicMerge:
-- prod-scaling.yaml
-- prod-healthchecks.yaml
-bases:
-- api/
-- frontend/
-- db/
-- github.com/example/app?ref=tag-or-branch
-resources:
-- ingress.yaml
-- permissions.yaml
-configMapGenerator:
-- name: appconfig
-  files:
-  - global.conf
-  - local.conf=prod.conf
-```
-]
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Glossary
-
-- A *base* is a kustomization that is referred to by other kustomizations
-
-- An *overlay* is a kustomization that refers to other kustomizations
-
-- A kustomization can be both a base and an overlay at the same time
-
-  (a kustomization can refer to another, which can refer to a third)
-
-- A *patch* describes how to alter an existing resource
-
-  (e.g. to change the image in a Deployment; or scaling parameters; etc.)
-
-- A *variant* is the final outcome of applying bases + overlays
-
-(See the [kustomize glossary](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md) for more definitions!)
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## What Kustomize *cannot* do
-
-- By design, there are a number of things that Kustomize won't do
-
-- For instance:
-
-  - using command-line arguments or environment variables to generate a variant
-
-  - overlays can only *add* resources, not *remove* them
-
-- See the full list of [eschewed features](https://kubectl.docs.kubernetes.io/faq/kustomize/eschewedfeatures/) for more details
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Kustomize workflows
-
-- The Kustomize documentation proposes two different workflows
-
-- *Bespoke configuration*
-
-   - base and overlays managed by the same team
-
-- *Off-the-shelf configuration* (OTS)
-
-  - base and overlays managed by different teams
-
-  - base is regularly updated by "upstream" (e.g. a vendor)
-
-  - our overlays and patches should (hopefully!) apply cleanly
-
-  - we may regularly update the base, or use a remote base
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Remote bases
-
-- Kustomize can also use bases that are remote git repositories
-
-- Examples:
-
-  github.com/jpetazzo/kubercoins (remote git repository)
-
-  github.com/jpetazzo/kubercoins?ref=kustomize (specific tag or branch)
-
-- Note that this only works for kustomizations, not individual resources
-
-  (the specified repository or directory must contain a `kustomization.yaml` file)
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-class: extra-details
-
-## Hashicorp go-getter
-
-- Some versions of Kustomize support additional forms for remote resources
-
-- Examples:
-
-  https://releases.hello.io/k/1.0.zip (remote archive)
-
-  https://releases.hello.io/k/1.0.zip//some-subdir (subdirectory in archive)
-
-- This relies on [hashicorp/go-getter](https://github.com/hashicorp/go-getter#url-format)
-
-- ... But it prevents Kustomize inclusion in `kubectl`
-
-- Avoid them!
-
-- See [kustomize#3578](https://github.com/kubernetes-sigs/kustomize/issues/3578) for details
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Managing `kustomization.yaml`
-
-- There are many ways to manage `kustomization.yaml` files, including:
-
-  - web wizards like [Replicated Ship](https://www.replicated.com/ship/)
-
-  - the `kustomize` CLI
-
-  - opening the file with our favorite text editor
-
-- Let's see these in action!
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## An easy way to get started with Kustomize
-
-- We are going to use [Replicated Ship](https://www.replicated.com/ship/) to experiment with Kustomize
-
-- The [Replicated Ship CLI](https://github.com/replicatedhq/ship/releases) has been installed on our clusters
-
-- Replicated Ship has multiple workflows; here is what we will do:
-
-  - initialize a Kustomize overlay from a remote GitHub repository
-
-  - customize some values using the web UI provided by Ship
-
-  - look at the resulting files and apply them to the cluster
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Getting started with Ship
-
-- We need to run `ship init` in a new directory
-
-- `ship init` requires a URL to a remote repository containing Kubernetes YAML
-
-- It will clone that repository and start a web UI
-
-- Later, it can watch that repository and/or update from it
-
-- We will use the [jpetazzo/kubercoins](https://github.com/jpetazzo/kubercoins) repository
-
-  (it contains all the DockerCoins resources as YAML files)
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## `ship init`
-
-.lab[
-
-- Change to a new directory:
-  ```bash
-  mkdir ~/kustomcoins
-  cd ~/kustomcoins
-  ```
-
-- Run `ship init` with the kustomcoins repository:
-  ```bash
-  ship init https://github.com/jpetazzo/kubercoins
-  ```
-
-<!-- ```wait Open browser``` -->
-
-]
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Access the web UI
-
-- `ship init` tells us to connect on `localhost:8800`
-
-- We need to replace `localhost` with the address of our node
-
-  (since we run on a remote machine)
-
-- Follow the steps in the web UI, and change one parameter
-
-  (e.g. set the number of replicas in the worker Deployment)
-
-- Complete the web workflow, and go back to the CLI
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Inspect the results
-
-- Look at the content of our directory
-
-- `base` contains the kubercoins repository + a `kustomization.yaml` file
-
-- `overlays/ship` contains the Kustomize overlay referencing the base + our patch(es)
-
-- `rendered.yaml` is a YAML bundle containing the patched application
-
-- `.ship` contains a state file used by Ship
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Using the results
-
-- We can `kubectl apply -f rendered.yaml`
-
-  (on any version of Kubernetes)
-
-- Starting with Kubernetes 1.14, we can apply the overlay directly with:
-  ```bash
-  kubectl apply -k overlays/ship
-  ```
-
-- But let's not do that for now!
-
-- We will create a new copy of DockerCoins in another namespace
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Deploy DockerCoins with Kustomize
-
-.lab[
-
-- Create a new namespace:
-  ```bash
-  kubectl create namespace kustomcoins
-  ```
-
-- Deploy DockerCoins:
-  ```bash
-  kubectl apply -f rendered.yaml --namespace=kustomcoins
-  ```
-
-- Or, with Kubernetes 1.14, we can also do this:
-  ```bash
-  kubectl apply -k overlays/ship --namespace=kustomcoins
-  ```
-
-]
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Checking our new copy of DockerCoins
-
-- We can check the worker logs, or the web UI
-
-.lab[
-
-- Retrieve the NodePort number of the web UI:
-  ```bash
-  kubectl get service webui --namespace=kustomcoins
-  ```
-
-- Open it in a web browser
-
-- Look at the worker logs:
-  ```bash
-  kubectl logs deploy/worker --tail=10 --follow --namespace=kustomcoins
-  ```
-
-<!--
-```wait units of work done``` 
-```key ^C```
--->
-
-]
-
-Note: it might take a minute or two for the worker to start.
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Working with the `kustomize` CLI
-
-- This is another way to get started
-
-- General workflow:
-
-  `kustomize create` to generate an empty `kustomization.yaml` file
-
-  `kustomize edit add resource` to add Kubernetes YAML files to it
-
-  `kustomize edit add patch` to add patches to said resources
-
-  `kustomize build | kubectl apply -f-` or `kubectl apply -k .`
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## `kubectl` integration
-
-- Kustomize has been integrated in `kubectl` (since Kubernetes 1.14)
-
-  - `kubectl kustomize` can apply a kustomization
-
-  - commands that use `-f` can also use `-k` (`kubectl apply`/`delete`/...)
-
-- The `kustomize` tool is still needed if we want to use `create`, `edit`, ...
-
-- Kubernetes 1.14 to 1.20 uses Kustomize 2.0.3
-
-- Kubernetes 1.21 jumps to Kustomize 4.1.2
-
-- Future versions should track Kustomize updates more closely
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-class: extra-details
-
-## Differences between 2.0.3 and later
-
-- Kustomize 2.1 / 3.0 deprecates `bases` (they should be listed in `resources`)
-
-  (this means that "modern" `kustomize edit add resource` won't work with "old" `kubectl apply -k`)
-
-- Kustomize 2.1 introduces `replicas` and `envs`
-
-- Kustomize 3.1 introduces multipatches
-
-- Kustomize 3.2 introduce inline patches in `kustomization.yaml`
-
-- Kustomize 3.3 to 3.10 is mostly internal refactoring
-
-- Kustomize 4.0 drops go-getter again
-
-- Kustomize 4.1 allows patching kind and name
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Scaling
-
-Instead of using a patch, scaling can be done like this:
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-...
-replicas:
-- name: worker
-  count: 5
-```
-
-It will automatically work with Deployments, ReplicaSets, StatefulSets.
-
-(For other resource types, fall back to a patch.)
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Updating images
-
-Instead of using patches, images can be changed like this:
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-...
-images:
-- name: postgres
-  newName: harbor.enix.io/my-postgres
-- name: dockercoins/worker
-  newTag: v0.2
-- name: dockercoins/hasher
-  newName: registry.dockercoins.io/hasher
-  newTag: v0.2
-- name: alpine
-  digest: sha256:24a0c4b4a4c0eb97a1aabb8e29f18e917d05abfe1b7a7c07857230879ce7d3d3
-```
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Updating images, pros and cons
-
-- Very convenient when the same image appears multiple times
-
-- Very convenient to define tags (or pin to hashes) outside of the main YAML
-
-- Doesn't support wildcard or generic substitutions:
-
-  - cannot "replace `dockercoins/*` with `ghcr.io/dockercoins/*`"
-
-  - cannot "tag all `dockercoins/*` with `v0.2`"
-
-- Only patches "well-known" image fields (won't work with CRDs referencing images)
-
-- Helm can deal with these scenarios, for instance:
-  ```yaml
-  image: {{ .Values.registry }}/worker:{{ .Values.version }}
-  ```
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Advanced resource patching
-
-The example below shows how to:
-
-- patch multiple resources with a selector (new in Kustomize 3.1)
-- use an inline patch instead of a separate patch file (new in Kustomize 3.2)
-
-```yaml
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-...
-patches:
-- patch: |-
-    - op: replace
-      path: /spec/template/spec/containers/0/image
-      value: alpine
-  target:
-    kind: Deployment
-    labelSelector: "app"
-```
-
-(This replaces all images of Deployments matching the `app` selector with `alpine`.)
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Advanced resource patching, pros and cons
-
-- Very convenient to patch an arbitrary number of resources
-
-- Very convenient to patch any kind of resource, including CRDs
-
-- Doesn't support "fine-grained" patching (e.g. image registry or tag)
-
-- Once again, Helm can do it:
-  ```yaml
-  image: {{ .Values.registry }}/worker:{{ .Values.version }}
-  ```
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.md)]
----
-
-## Differences with Helm
-
-- Helm charts generally require more upfront work
-
-  (while kustomize "bases" are standard Kubernetes YAML)
-
-- ... But Helm charts are also more powerful; their templating language can:
-
-  - conditionally include/exclude resources or blocks within resources
-
-  - generate values by concatenating, hashing, transforming parameters
-
-  - generate values or resources by iteration (`{{ range ... }}`)
-
-  - access the Kubernetes API during template evaluation
-
-  - [and much more](https://helm.sh/docs/chart_template_guide/)
-
-???
-
-:EN:- Packaging and running apps with Kustomize
-:FR:- *Packaging* d'applications avec Kustomize
-
-.debug[[k8s/kustomize.md](""/tree/main/slides/k8s/kustomize.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-managing-stacks-with-helm
-class: title
-
- Managing stacks with Helm
-
-.nav[
-[Previous part](#toc-kustomize)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-helm-chart-format)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Managing stacks with Helm
-
-- Helm is a (kind of!) package manager for Kubernetes
-
-- We can use it to:
-
-  - find existing packages (called "charts") created by other folks
-
-  - install these packages, configuring them for our particular setup
-
-  - package our own things (for distribution or for internal use)
-
-  - manage the lifecycle of these installs (rollback to previous version etc.)
-
-- It's a "CNCF graduate project", indicating a certain level of maturity
-
-  (more on that later)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## From `kubectl run` to YAML
-
-- We can create resources with one-line commands
-
-  (`kubectl run`, `kubectl create deployment`, `kubectl expose`...)
-
-- We can also create resources by loading YAML files
-
-  (with `kubectl apply -f`, `kubectl create -f`...)
-
-- There can be multiple resources in a single YAML files
-
-  (making them convenient to deploy entire stacks)
-
-- However, these YAML bundles often need to be customized
-
-  (e.g.: number of replicas, image version to use, features to enable...)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Beyond YAML
-
-- Very often, after putting together our first `app.yaml`, we end up with:
-
-  - `app-prod.yaml`
-
-  - `app-staging.yaml`
-
-  - `app-dev.yaml`
-
-  - instructions indicating to users "please tweak this and that in the YAML"
-
-- That's where using something like
-  [CUE](https://github.com/cuelang/cue/blob/v0.3.2/doc/tutorial/kubernetes/README.md),
-  [Kustomize](https://kustomize.io/),
-  or [Helm](https://helm.sh/) can help!
-
-- Now we can do something like this:
-  ```bash
-  helm install app ... --set this.parameter=that.value
-  ```
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Other features of Helm
-
-- With Helm, we create "charts"
-
-- These charts can be used internally or distributed publicly
-
-- Public charts can be indexed through the [Artifact Hub](https://artifacthub.io/)
-
-- This gives us a way to find and install other folks' charts
-
-- Helm also gives us ways to manage the lifecycle of what we install:
-
-  - keep track of what we have installed
-
-  - upgrade versions, change parameters, roll back, uninstall
-
-- Furthermore, even if it's not "the" standard, it's definitely "a" standard!
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## CNCF graduation status
-
-- On April 30th 2020, Helm was the 10th project to *graduate* within the CNCF
-
-  🎉
-
-  (alongside Containerd, Prometheus, and Kubernetes itself)
-
-- This is an acknowledgement by the CNCF for projects that
-
-  *demonstrate thriving adoption, an open governance process,
-  <br/>
-  and a strong commitment to community, sustainability, and inclusivity.*
-
-- See [CNCF announcement](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/)
-  and [Helm announcement](https://helm.sh/blog/celebrating-helms-cncf-graduation/)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Helm concepts
-
-- `helm` is a CLI tool
-
-- It is used to find, install, upgrade *charts*
-
-- A chart is an archive containing templatized YAML bundles
-
-- Charts are versioned
-
-- Charts can be stored on private or public repositories
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Differences between charts and packages
-
-- A package (deb, rpm...) contains binaries, libraries, etc.
-
-- A chart contains YAML manifests
-
-  (the binaries, libraries, etc. are in the images referenced by the chart)
-
-- On most distributions, a package can only be installed once
-
-  (installing another version replaces the installed one)
-
-- A chart can be installed multiple times
-
-- Each installation is called a *release*
-
-- This allows to install e.g. 10 instances of MongoDB
-
-  (with potentially different versions and configurations)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-class: extra-details
-
-## Wait a minute ...
-
-*But, on my Debian system, I have Python 2 **and** Python 3.
-<br/>
-Also, I have multiple versions of the Postgres database engine!*
-
-Yes!
-
-But they have different package names:
-
-- `python2.7`, `python3.8`
-
-- `postgresql-10`, `postgresql-11`
-
-Good to know: the Postgres package in Debian includes
-provisions to deploy multiple Postgres servers on the
-same system, but it's an exception (and it's a lot of
-work done by the package maintainer, not by the `dpkg`
-or `apt` tools).
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Helm 2 vs Helm 3
-
-- Helm 3 was released [November 13, 2019](https://helm.sh/blog/helm-3-released/)
-
-- Charts remain compatible between Helm 2 and Helm 3
-
-- The CLI is very similar (with minor changes to some commands)
-
-- The main difference is that Helm 2 uses `tiller`, a server-side component
-
-- Helm 3 doesn't use `tiller` at all, making it simpler (yay!)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-class: extra-details
-
-## With or without `tiller`
-
-- With Helm 3:
-
-  - the `helm` CLI communicates directly with the Kubernetes API
-
-  - it creates resources (deployments, services...) with our credentials
-
-- With Helm 2:
-
-  - the `helm` CLI communicates with `tiller`, telling `tiller` what to do
-
-  - `tiller` then communicates with the Kubernetes API, using its own credentials
-
-- This indirect model caused significant permissions headaches
-
-  (`tiller` required very broad permissions to function)
-
-- `tiller` was removed in Helm 3 to simplify the security aspects
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Installing Helm
-
-- If the `helm` CLI is not installed in your environment, install it
-
-.lab[
-
-- Check if `helm` is installed:
-  ```bash
-  helm
-  ```
-
-- If it's not installed, run the following command:
-  ```bash
-  curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get-helm-3 \
-  | bash
-  ```
-
-]
-
-(To install Helm 2, replace `get-helm-3` with `get`.)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-class: extra-details
-
-## Only if using Helm 2 ...
-
-- We need to install Tiller and give it some permissions
-
-- Tiller is composed of a *service* and a *deployment* in the `kube-system` namespace
-
-- They can be managed (installed, upgraded...) with the `helm` CLI
-
-.lab[
-
-- Deploy Tiller:
-  ```bash
-  helm init
-  ```
-
-]
-
-At the end of the install process, you will see:
-
-```
-Happy Helming!
-```
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-class: extra-details
-
-## Only if using Helm 2 ...
-
-- Tiller needs permissions to create Kubernetes resources
-
-- In a more realistic deployment, you might create per-user or per-team
-  service accounts, roles, and role bindings
-
-.lab[
-
-- Grant `cluster-admin` role to `kube-system:default` service account:
-  ```bash
-  kubectl create clusterrolebinding add-on-cluster-admin \
-      --clusterrole=cluster-admin --serviceaccount=kube-system:default
-  ```
-
-
-]
-
-(Defining the exact roles and permissions on your cluster requires
-a deeper knowledge of Kubernetes' RBAC model. The command above is
-fine for personal and development clusters.)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Charts and repositories
-
-- A *repository* (or repo in short) is a collection of charts
-
-- It's just a bunch of files
-
-  (they can be hosted by a static HTTP server, or on a local directory)
-
-- We can add "repos" to Helm, giving them a nickname
-
-- The nickname is used when referring to charts on that repo
-
-  (for instance, if we try to install `hello/world`, that
-  means the chart `world` on the repo `hello`; and that repo
-  `hello` might be something like https://blahblah.hello.io/charts/)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-class: extra-details
-
-## How to find charts, the old way
-
-- Helm 2 came with one pre-configured repo, the "stable" repo
-
-  (located at https://charts.helm.sh/stable)
-
-- Helm 3 doesn't have any pre-configured repo
-
-- The "stable" repo mentioned above is now being deprecated
-
-- The new approach is to have fully decentralized repos
-
-- Repos can be indexed in the Artifact Hub
-
-  (which supersedes the Helm Hub)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## How to find charts, the new way
-
-- Go to the [Artifact Hub](https://artifacthub.io/packages/search?kind=0) (https://artifacthub.io)
-
-- Or use `helm search hub ...` from the CLI
-
-- Let's try to find a Helm chart for something called "OWASP Juice Shop"!
-
-  (it is a famous demo app used in security challenges)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Finding charts from the CLI
-
-- We can use `helm search hub <keyword>`
-
-.lab[
-
-- Look for the OWASP Juice Shop app:
-  ```bash
-  helm search hub owasp juice
-  ```
-
-- Since the URLs are truncated, try with the YAML output:
-  ```bash
-  helm search hub owasp juice -o yaml
-  ```
-
-]
-
-Then go to → https://artifacthub.io/packages/helm/seccurecodebox/juice-shop
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Finding charts on the web
-
-- We can also use the Artifact Hub search feature
-
-.lab[
-
-- Go to https://artifacthub.io/
-
-- In the search box on top, enter "owasp juice"
-
-- Click on the "juice-shop" result (not "multi-juicer" or "juicy-ctf")
-
-]
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Installing the chart
-
-- Click on the "Install" button, it will show instructions
-
-.lab[
-
-- First, add the repository for that chart:
-  ```bash
-  helm repo add juice https://charts.securecodebox.io
-  ```
-
-- Then, install the chart:
-  ```bash
-  helm install my-juice-shop juice/juice-shop
-  ```
-
-]
-
-Note: it is also possible to install directly a chart, with `--repo https://...`
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Charts and releases
-
-- "Installing a chart" means creating a *release*
-
-- In the previous example, the release was named "my-juice-shop"
-
-- We can also use `--generate-name` to ask Helm to generate a name for us
-
-.lab[
-
-- List the releases:
-  ```bash
-  helm list
-  ```
-
-- Check that we have a `my-juice-shop-...` Pod up and running:
-  ```bash
-  kubectl get pods
-  ```
-
-]
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-class: extra-details
-
-## Searching and installing with Helm 2
-
-- Helm 2 doesn't have support for the Helm Hub
-
-- The `helm search` command only takes a search string argument
-
-  (e.g. `helm search juice-shop`)
-
-- With Helm 2, the name is optional:
-
-  `helm install juice/juice-shop` will automatically generate a name
-
-  `helm install --name my-juice-shop juice/juice-shop` will specify a name
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Viewing resources of a release
-
-- This specific chart labels all its resources with a `release` label
-
-- We can use a selector to see these resources
-
-.lab[
-
-- List all the resources created by this release:
-  ```bash
-  kubectl get all --selector=app.kubernetes.io/instance=my-juice-shop
-  ```
-
-]
-
-Note: this label wasn't added automatically by Helm.
-<br/>
-It is defined in that chart. In other words, not all charts will provide this label.
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Configuring a release
-
-- By default, `juice/juice-shop` creates a service of type `ClusterIP`
-
-- We would like to change that to a `NodePort`
-
-- We could use `kubectl edit service my-juice-shop`, but ...
-
-  ... our changes would get overwritten next time we update that chart!
-
-- Instead, we are going to *set a value*
-
-- Values are parameters that the chart can use to change its behavior
-
-- Values have default values
-
-- Each chart is free to define its own values and their defaults
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Checking possible values
-
-- We can inspect a chart with `helm show` or `helm inspect`
-
-.lab[
-
-- Look at the README for the app:
-  ```bash
-  helm show readme juice/juice-shop
-  ```
-
-- Look at the values and their defaults:
-  ```bash
-  helm show values juice/juice-shop
-  ```
-
-]
-
-The `values` may or may not have useful comments.
-
-The `readme` may or may not have (accurate) explanations for the values.
-
-(If we're unlucky, there won't be any indication about how to use the values!)
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Setting values
-
-- Values can be set when installing a chart, or when upgrading it
-
-- We are going to update `my-juice-shop` to change the type of the service
-
-.lab[
-
-- Update `my-juice-shop`:
-  ```bash
-  helm upgrade my-juice-shop juice/juice-shop \
-       --set service.type=NodePort
-  ```
-
-]
-
-Note that we have to specify the chart that we use (`juice/my-juice-shop`),
-even if we just want to update some values.
-
-We can set multiple values. If we want to set many values, we can use `-f`/`--values` and pass a YAML file with all the values.
-
-All unspecified values will take the default values defined in the chart.
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-## Connecting to the Juice Shop
-
-- Let's check the app that we just installed
-
-.lab[
-
-- Check the node port allocated to the service:
-  ```bash
-  kubectl get service my-juice-shop
-  PORT=$(kubectl get service my-juice-shop -o jsonpath={..nodePort})
-  ```
-
-- Connect to it:
-  ```bash
-  curl localhost:$PORT/
-  ```
-
-]
-
-???
-
-:EN:- Helm concepts
-:EN:- Installing software with Helm
-:EN:- Helm 2, Helm 3, and the Helm Hub
-
-:FR:- Fonctionnement général de Helm
-:FR:- Installer des composants via Helm
-:FR:- Helm 2, Helm 3, et le *Helm Hub*
-
-:T: Getting started with Helm and its concepts
-
-:Q: Which comparison is the most adequate?
-:A: Helm is a firewall, charts are access lists
-:A: ✔️Helm is a package manager, charts are packages
-:A: Helm is an artefact repository, charts are artefacts
-:A: Helm is a CI/CD platform, charts are CI/CD pipelines
-
-:Q: What's required to distribute a Helm chart?
-:A: A Helm commercial license
-:A: A Docker registry
-:A: An account on the Helm Hub
-:A: ✔️An HTTP server
-
-.debug[[k8s/helm-intro.md](""/tree/main/slides/k8s/helm-intro.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]
-
----
-
-name: toc-helm-chart-format
-class: title
-
- Helm chart format
-
-.nav[
-[Previous part](#toc-managing-stacks-with-helm)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-creating-a-basic-chart)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Helm chart format
-
-- What exactly is a chart?
-
-- What's in it?
-
-- What would be involved in creating a chart?
-
-  (we won't create a chart, but we'll see the required steps)
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## What is a chart
-
-- A chart is a set of files
-
-- Some of these files are mandatory for the chart to be viable
-
-  (more on that later)
-
-- These files are typically packed in a tarball
-
-- These tarballs are stored in "repos"
-
-  (which can be static HTTP servers)
-
-- We can install from a repo, from a local tarball, or an unpacked tarball
-
-  (the latter option is preferred when developing a chart)
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## What's in a chart
-
-- A chart must have at least:
-
-  - a `templates` directory, with YAML manifests for Kubernetes resources
-
-  - a `values.yaml` file, containing (tunable) parameters for the chart
-
-  - a `Chart.yaml` file, containing metadata (name, version, description ...)
-
-- Let's look at a simple chart for a basic demo app
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Adding the repo
-
-- If you haven't done it before, you need to add the repo for that chart
-
-.lab[
-
-- Add the repo that holds the chart for the OWASP Juice Shop:
-  ```bash
-  helm repo add juice https://charts.securecodebox.io
-  ```
-
-]
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Downloading a chart
-
-- We can use `helm pull` to download a chart from a repo
-
-.lab[
-
-- Download the tarball for `juice/juice-shop`:
-  ```bash
-  helm pull juice/juice-shop
-  ```
-  (This will create a file named `juice-shop-X.Y.Z.tgz`.)
-
-- Or, download + untar `juice/juice-shop`:
-  ```bash
-  helm pull juice/juice-shop --untar
-  ```
-  (This will create a directory named `juice-shop`.)
-
-]
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Looking at the chart's content
-
-- Let's look at the files and directories in the `juice-shop` chart
-
-.lab[
-
-- Display the tree structure of the chart we just downloaded:
-  ```bash
-  tree juice-shop
-  ```
-
-]
-
-We see the components mentioned above: `Chart.yaml`, `templates/`, `values.yaml`.
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Templates
-
-- The `templates/` directory contains YAML manifests for Kubernetes resources
-
-  (Deployments, Services, etc.)
-
-- These manifests can contain template tags
-
-  (using the standard Go template library)
-
-.lab[
-
-- Look at the template file for the Service resource:
-  ```bash
-  cat juice-shop/templates/service.yaml
-  ```
-
-]
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Analyzing the template file
-
-- Tags are identified by `{{ ... }}`
-
-- `{{ template "x.y" }}` expands a [named template](https://helm.sh/docs/chart_template_guide/named_templates/#declaring-and-using-templates-with-define-and-template)
-
-  (previously defined with `{{ define "x.y" }}...stuff...{{ end }}`)
-
-- The `.` in `{{ template "x.y" . }}` is the *context* for that named template
-
-  (so that the named template block can access variables from the local context)
-
-- `{{ .Release.xyz }}` refers to [built-in variables](https://helm.sh/docs/chart_template_guide/builtin_objects/) initialized by Helm
-
-  (indicating the chart name, version, whether we are installing or upgrading ...)
-
-- `{{ .Values.xyz }}` refers to tunable/settable [values](https://helm.sh/docs/chart_template_guide/values_files/)
-
-  (more on that in a minute)
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Values
-
-- Each chart comes with a
-  [values file](https://helm.sh/docs/chart_template_guide/values_files/)
-
-- It's a YAML file containing a set of default parameters for the chart
-
-- The values can be accessed in templates with e.g. `{{ .Values.x.y }}`
-
-  (corresponding to field `y` in map `x` in the values file)
-
-- The values can be set or overridden when installing or ugprading a chart:
-
-  - with `--set x.y=z` (can be used multiple times to set multiple values)
-
-  - with `--values some-yaml-file.yaml` (set a bunch of values from a file)
-
-- Charts following best practices will have values following specific patterns
-
-  (e.g. having a `service` map allowing to set `service.type` etc.)
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Other useful tags
-
-- `{{ if x }} y {{ end }}` allows to include `y` if `x` evaluates to `true`
-
-  (can be used for e.g. healthchecks, annotations, or even an entire resource)
-
-- `{{ range x }} y {{ end }}` iterates over `x`, evaluating `y` each time
-
-  (the elements of `x` are assigned to `.` in the range scope)
-
-- `{{- x }}`/`{{ x -}}` will remove whitespace on the left/right
-
-- The whole [Sprig](http://masterminds.github.io/sprig/) library, with additions:
-
-  `lower` `upper` `quote` `trim` `default` `b64enc` `b64dec` `sha256sum` `indent` `toYaml` ...
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Pipelines
-
-- `{{ quote blah }}` can also be expressed as `{{ blah | quote }}`
-
-- With multiple arguments, `{{ x y z }}` can be expressed as `{{ z | x y }}`)
-
-- Example: `{{ .Values.annotations | toYaml | indent 4 }}`
-
-  - transforms the map under `annotations` into a YAML string
-
-  - indents it with 4 spaces (to match the surrounding context)
-
-- Pipelines are not specific to Helm, but a feature of Go templates
-
-  (check the [Go text/template documentation](https://golang.org/pkg/text/template/) for more details and examples)
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## README and NOTES.txt
-
-- At the top-level of the chart, it's a good idea to have a README
-
-- It will be viewable with e.g. `helm show readme juice/juice-shop`
-
-- In the `templates/` directory, we can also have a `NOTES.txt` file
-
-- When the template is installed (or upgraded), `NOTES.txt` is processed too
-
-  (i.e. its `{{ ... }}` tags are evaluated)
-
-- It gets displayed after the install or upgrade
-
-- It's a great place to generate messages to tell the user:
-
-  - how to connect to the release they just deployed
-
-  - any passwords or other thing that we generated for them
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Additional files
-
-- We can place arbitrary files in the chart (outside of the `templates/` directory)
-
-- They can be accessed in templates with `.Files`
-
-- They can be transformed into ConfigMaps or Secrets with `AsConfig` and `AsSecrets`
-
-  (see [this example](https://helm.sh/docs/chart_template_guide/accessing_files/#configmap-and-secrets-utility-functions) in the Helm docs)
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-## Hooks and tests
-
-- We can define *hooks* in our templates
-
-- Hooks are resources annotated with `"helm.sh/hook": NAME-OF-HOOK`
-
-- Hook names include `pre-install`, `post-install`, `test`, [and much more](https://helm.sh/docs/topics/charts_hooks/#the-available-hooks)
-
-- The resources defined in hooks are loaded at a specific time
-
-- Hook execution is *synchronous*
-
-  (if the resource is a Job or Pod, Helm will wait for its completion)
-
-- This can be use for database migrations, backups, notifications, smoke tests ...
-
-- Hooks named `test` are executed only when running `helm test RELEASE-NAME`
-
-???
-
-:EN:- Helm charts format
-:FR:- Le format des *Helm charts*
-
-.debug[[k8s/helm-chart-format.md](""/tree/main/slides/k8s/helm-chart-format.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg)]
-
----
-
-name: toc-creating-a-basic-chart
-class: title
-
- Creating a basic chart
-
-.nav[
-[Previous part](#toc-helm-chart-format)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-extra-content)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Creating a basic chart
-
-- We are going to show a way to create a *very simplified* chart
-
-- In a real chart, *lots of things* would be templatized
-
-  (Resource names, service types, number of replicas...)
-
-.lab[
-
-- Create a sample chart:
-  ```bash
-  helm create dockercoins
-  ```
-
-- Move away the sample templates and create an empty template directory:
-  ```bash
-  mv dockercoins/templates dockercoins/default-templates
-  mkdir dockercoins/templates
-  ```
-
-]
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Adding the manifests of our app
-
-- There is a convenient `dockercoins.yml` in the repo
-
-.lab[
-
-- Copy the YAML file to the `templates` subdirectory in the chart:
-  ```bash
-  cp ~/container.training/k8s/dockercoins.yaml dockercoins/templates
-  ```
-
-]
-
-- Note: it is probably easier to have multiple YAML files
-
-  (rather than a single, big file with all the manifests)
-
-- But that works too!
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Testing our Helm chart
-
-- Our Helm chart is now ready
-
-  (as surprising as it might seem!)
-
-.lab[
-
-- Let's try to install the chart:
-  ```
-  helm install helmcoins dockercoins
-  ```
-  (`helmcoins` is the name of the release; `dockercoins` is the local path of the chart)
-
-]
-
---
-
-- If the application is already deployed, this will fail:
-```
-Error: rendered manifests contain a resource that already exists.
-Unable to continue with install: existing resource conflict:
-kind: Service, namespace: default, name: hasher
-```
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Switching to another namespace
-
-- If there is already a copy of dockercoins in the current namespace:
-
-  - we can switch with `kubens` or `kubectl config set-context`
-
-  - we can also tell Helm to use a different namespace
-
-.lab[
-
-- Create a new namespace:
-  ```bash
-  kubectl create namespace helmcoins
-  ```
-
-- Deploy our chart in that namespace:
-  ```bash
-  helm install helmcoins dockercoins --namespace=helmcoins
-  ```
-
-]
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Helm releases are namespaced
-
-- Let's try to see the release that we just deployed
-
-.lab[
-
-- List Helm releases:
-  ```bash
-  helm list
-  ```
-
-]
-
-Our release doesn't show up!
-
-We have to specify its namespace (or switch to that namespace).
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Specifying the namespace
-
-- Try again, with the correct namespace
-
-.lab[
-
-- List Helm releases in `helmcoins`:
-  ```bash
-  helm list --namespace=helmcoins
-  ```
-
-]
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Checking our new copy of DockerCoins
-
-- We can check the worker logs, or the web UI
-
-.lab[
-
-- Retrieve the NodePort number of the web UI:
-  ```bash
-  kubectl get service webui --namespace=helmcoins
-  ```
-
-- Open it in a web browser
-
-- Look at the worker logs:
-  ```bash
-  kubectl logs deploy/worker --tail=10 --follow --namespace=helmcoins
-  ```
-
-]
-
-Note: it might take a minute or two for the worker to start.
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Discussion, shortcomings
-
-- Helm (and Kubernetes) best practices recommend to add a number of annotations
-
-  (e.g. `app.kubernetes.io/name`, `helm.sh/chart`, `app.kubernetes.io/instance` ...)
-
-- Our basic chart doesn't have any of these
-
-- Our basic chart doesn't use any template tag
-
-- Does it make sense to use Helm in that case?
-
-- *Yes,* because Helm will:
-
-  - track the resources created by the chart
-
-  - save successive revisions, allowing us to rollback
-
-[Helm docs](https://helm.sh/docs/topics/chart_best_practices/labels/)
-and [Kubernetes docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)
-have details about recommended annotations and labels.
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Cleaning up
-
-- Let's remove that chart before moving on
-
-.lab[
-
-- Delete the release (don't forget to specify the namespace):
-  ```bash
-  helm delete helmcoins --namespace=helmcoins
-  ```
-
-]
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Tips when writing charts
-
-- It is not necessary to `helm install`/`upgrade` to test a chart
-
-- If we just want to look at the generated YAML, use `helm template`:
-  ```bash
-  helm template ./my-chart
-  helm template release-name ./my-chart
-  ```
-
-- Of course, we can use `--set` and `--values` too
-
-- Note that this won't fully validate the YAML!
-
-  (e.g. if there is `apiVersion: klingon` it won't complain)
-
-- This can be used when trying things out
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-
-## Exploring the templating system
-
-Try to put something like this in a file in the `templates` directory:
-
-```yaml
-hello: {{ .Values.service.port }}
-comment: {{/* something completely.invalid !!!  */}}
-type: {{ .Values.service | typeOf | printf }}
-### print complex value
-{{ .Values.service | toYaml }}
-### indent it
-indented:
-{{ .Values.service | toYaml | indent 2 }}
-```
-
-Then run `helm template`.
-
-The result is not a valid YAML manifest, but this is a great debugging tool!
-
-???
-
-:EN:- Writing a basic Helm chart for the whole app
-:FR:- Écriture d'un *chart* Helm simplifié
-
-.debug[[k8s/helm-create-basic-chart.md](""/tree/main/slides/k8s/helm-create-basic-chart.md)]
----
-# (Extra content)
-
-.debug[[kube-adv.yml](""/tree/main/slides/kube-adv.yml)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg)]
-
----
-
-name: toc-creating-better-helm-charts
-class: title
-
- Creating better Helm charts
-
-.nav[
-[Previous part](#toc-extra-content)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-charts-using-other-charts)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Creating better Helm charts
-
-- We are going to create a chart with the helper `helm create`
-
-- This will give us a chart implementing lots of Helm best practices
-
-  (labels, annotations, structure of the `values.yaml` file ...)
-
-- We will use that chart as a generic Helm chart
-
-- We will use it to deploy DockerCoins
-
-- Each component of DockerCoins will have its own *release*
-
-- In other words, we will "install" that Helm chart multiple times
-
-  (one time per component of DockerCoins)
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Creating a generic chart
-
-- Rather than starting from scratch, we will use `helm create`
-
-- This will give us a basic chart that we will customize
-
-.lab[
-
-- Create a basic chart:
-  ```bash
-  cd ~
-  helm create helmcoins
-  ```
-
-]
-
-This creates a basic chart in the directory `helmcoins`.
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## What's in the basic chart?
-
-- The basic chart will create a Deployment and a Service
-
-- Optionally, it will also include an Ingress
-
-- If we don't pass any values, it will deploy the `nginx` image
-
-- We can override many things in that chart
-
-- Let's try to deploy DockerCoins components with that chart!
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Writing `values.yaml` for our components
-
-- We need to write one `values.yaml` file for each component
-
-  (hasher, redis, rng, webui, worker)
-
-- We will start with the `values.yaml` of the chart, and remove what we don't need
-
-- We will create 5 files:
-
-  hasher.yaml, redis.yaml, rng.yaml, webui.yaml, worker.yaml
-
-- In each file, we want to have:
-  ```yaml
-    image:
-      repository: IMAGE-REPOSITORY-NAME
-      tag: IMAGE-TAG
-  ```
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Getting started
-
-- For component X, we want to use the image dockercoins/X:v0.1
-
-  (for instance, for rng, we want to use the image dockercoins/rng:v0.1)
-
-- Exception: for redis, we want to use the official image redis:latest
-
-.lab[
-
-- Write YAML files for the 5 components, with the following model:
-  ```yaml
-    image:
-      repository: `IMAGE-REPOSITORY-NAME` (e.g. dockercoins/worker)
-      tag: `IMAGE-TAG` (e.g. v0.1)
-  ```
-
-]
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Deploying DockerCoins components
-
-- For convenience, let's work in a separate namespace
-
-.lab[
-
-- Create a new namespace (if it doesn't already exist):
-  ```bash
-  kubectl create namespace helmcoins
-  ```
-
-- Switch to that namespace:
-  ```bash
-  kns helmcoins
-  ```
-
-]
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Deploying the chart
-
-- To install a chart, we can use the following command:
-  ```bash
-  helm install COMPONENT-NAME CHART-DIRECTORY
-  ```
-
-- We can also use the following command, which is *idempotent*:
-  ```bash
-  helm upgrade COMPONENT-NAME CHART-DIRECTORY --install
-  ```
-
-.lab[
-
-- Install the 5 components of DockerCoins:
-  ```bash
-    for COMPONENT in hasher redis rng webui worker; do
-      helm upgrade $COMPONENT helmcoins --install --values=$COMPONENT.yaml
-    done
-  ```
-
-]
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-class: extra-details
-
-## "Idempotent"
-
-- Idempotent = that can be applied multiple times without changing the result
-
-  (the word is commonly used in maths and computer science)
-
-- In this context, this means:
-
-  - if the action (installing the chart) wasn't done, do it
-
-  - if the action was already done, don't do anything
-
-- Ideally, when such an action fails, it can be retried safely
-
-  (as opposed to, e.g., installing a new release each time we run it)
-
-- Other example: `kubectl apply -f some-file.yaml`
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Checking what we've done
-
-- Let's see if DockerCoins is working!
-
-.lab[
-
-- Check the logs of the worker:
-  ```bash
-  stern worker
-  ```
-
-- Look at the resources that were created:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
-There are *many* issues to fix!
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Can't pull image
-
-- It looks like our images can't be found
-
-.lab[
-
-- Use `kubectl describe` on any of the pods in error
-
-]
-
-- We're trying to pull `rng:1.16.0` instead of `rng:v0.1`!
-
-- Where does that `1.16.0` tag come from?
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Inspecting our template
-
-- Let's look at the `templates/` directory
-
-  (and try to find the one generating the Deployment resource)
-
-.lab[
-
-- Show the structure of the `helmcoins` chart that Helm generated:
-  ```bash
-  tree helmcoins
-  ```
-
-- Check the file `helmcoins/templates/deployment.yaml`
-
-- Look for the `image:` parameter
-
-]
-
-*The image tag references `{{ .Chart.AppVersion }}`. Where does that come from?*
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## The `.Chart` variable
-
-- `.Chart` is a map corresponding to the values in `Chart.yaml`
-
-- Let's look for `AppVersion` there!
-
-.lab[
-
-- Check the file `helmcoins/Chart.yaml`
-
-- Look for the `appVersion:` parameter
-
-]
-
-(Yes, the case is different between the template and the Chart file.)
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Using the correct tags
-
-- If we change `AppVersion` to `v0.1`, it will change for *all* deployments
-
-  (including redis)
-
-- Instead, let's change the *template* to use `{{ .Values.image.tag }}`
-
-  (to match what we've specified in our values YAML files)
-
-.lab[
-
-- Edit `helmcoins/templates/deployment.yaml`
-
-- Replace `{{ .Chart.AppVersion }}` with `{{ .Values.image.tag }}`
-
-]
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Upgrading to use the new template
-
-- Technically, we just made a new version of the *chart*
-
-- To use the new template, we need to *upgrade* the release to use that chart
-
-.lab[
-
-- Upgrade all components:
-  ```bash
-    for COMPONENT in hasher redis rng webui worker; do
-      helm upgrade $COMPONENT helmcoins
-    done
-  ```
-
-- Check how our pods are doing:
-  ```bash
-  kubectl get pods
-  ```
-
-]
-
-We should see all pods "Running". But ... not all of them are READY.
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Troubleshooting readiness
-
-- `hasher`, `rng`, `webui` should show up as `1/1 READY`
-
-- But `redis` and `worker` should show up as `0/1 READY`
-
-- Why?
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Troubleshooting pods
-
-- The easiest way to troubleshoot pods is to look at *events*
-
-- We can look at all the events on the cluster (with `kubectl get events`)
-
-- Or we can use `kubectl describe` on the objects that have problems
-
-  (`kubectl describe` will retrieve the events related to the object)
-
-.lab[
-
-- Check the events for the redis pods:
-  ```bash
-  kubectl describe pod -l app.kubernetes.io/name=redis
-  ```
-
-]
-
-It's failing both its liveness and readiness probes!
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Healthchecks
-
-- The default chart defines healthchecks doing HTTP requests on port 80
-
-- That won't work for redis and worker
-
-  (redis is not HTTP, and not on port 80; worker doesn't even listen)
-
---
-
-- We could remove or comment out the healthchecks
-
-- We could also make them conditional
-
-- This sounds more interesting, let's do that!
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Conditionals
-
-- We need to enclose the healthcheck block with:
-
-  `{{ if false }}` at the beginning (we can change the condition later)
-
-  `{{ end }}` at the end
-
-.lab[
-
-- Edit `helmcoins/templates/deployment.yaml`
-
-- Add `{{ if false }}` on the line before `livenessProbe`
-
-- Add `{{ end }}` after the `readinessProbe` section
-
-  (see next slide for details)
-
-]
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-This is what the new YAML should look like (added lines in yellow):
-
-```yaml
-        ports:
-          - name: http
-            containerPort: 80
-            protocol: TCP
-        `{{ if false }}`
-        livenessProbe:
-          httpGet:
-            path: /
-            port: http
-        readinessProbe:
-          httpGet:
-            path: /
-            port: http
-        `{{ end }}`
-        resources:
-          {{- toYaml .Values.resources | nindent 12 }}
-```
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Testing the new chart
-
-- We need to upgrade all the services again to use the new chart
-
-.lab[
-
-- Upgrade all components:
-  ```bash
-    for COMPONENT in hasher redis rng webui worker; do
-      helm upgrade $COMPONENT helmcoins
-    done
-  ```
-
-- Check how our pods are doing:
-  ```bash
-  kubectl get pods
-  ```
-
-]
-
-Everything should now be running!
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## What's next?
-
-- Is this working now?
-
-.lab[
-
-- Let's check the logs of the worker:
-  ```bash
-  stern worker
-  ```
-
-]
-
-This error might look familiar ... The worker can't resolve `redis`.
-
-Typically, that error means that the `redis` service doesn't exist.
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Checking services
-
-- What about the services created by our chart?
-
-.lab[
-
-- Check the list of services:
-  ```bash
-  kubectl get services
-  ```
-
-]
-
-They are named `COMPONENT-helmcoins` instead of just `COMPONENT`.
-
-We need to change that!
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Where do the service names come from?
-
-- Look at the YAML template used for the services
-
-- It should be using `{{ include "helmcoins.fullname" }}`
-
-- `include` indicates a *template block* defined somewhere else
-
-.lab[
-
-- Find where that `fullname` thing is defined:
-  ```bash
-  grep define.*fullname helmcoins/templates/*
-  ```
-
-]
-
-It should be in `_helpers.tpl`.
-
-We can look at the definition, but it's fairly complex ...
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Changing service names
-
-- Instead of that `{{ include }}` tag, let's use the name of the release
-
-- The name of the release is available as `{{ .Release.Name }}`
-
-.lab[
-
-- Edit `helmcoins/templates/service.yaml`
-
-- Replace the service name with `{{ .Release.Name }}`
-
-- Upgrade all the releases to use the new chart
-
-- Confirm that the services now have the right names
-
-]
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Is it working now?
-
-- If we look at the worker logs, it appears that the worker is still stuck
-
-- What could be happening?
-
---
-
-- The redis service is not on port 80!
-
-- Let's see how the port number is set
-
-- We need to look at both the *deployment* template and the *service* template
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Service template
-
-- In the service template, we have the following section:
-  ```yaml
-    ports:
-    - port: {{ .Values.service.port }}
-      targetPort: http
-      protocol: TCP
-      name: http
-  ```
-
-- `port` is the port on which the service is "listening"
-
-  (i.e. to which our code needs to connect)
-
-- `targetPort` is the port on which the pods are listening
-
-- The `name` is not important (it's OK if it's `http` even for non-HTTP traffic)
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Setting the redis port
-
-- Let's add a `service.port` value to the redis release
-
-.lab[
-
-- Edit `redis.yaml` to add:
-  ```yaml
-    service:
-      port: 6379
-  ```
-
-- Apply the new values file:
-  ```bash
-  helm upgrade redis helmcoins --values=redis.yaml
-  ```
-
-]
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Deployment template
-
-- If we look at the deployment template, we see this section:
-  ```yaml
-          ports:
-            - name: http
-              containerPort: 80
-              protocol: TCP
-  ```
-
-- The container port is hard-coded to 80
-
-- We'll change it to use the port number specified in the values
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Changing the deployment template
-
-.lab[  
-
-- Edit `helmcoins/templates/deployment.yaml`
-
-- The line with `containerPort` should be:
-  ```yaml
-  containerPort: {{ .Values.service.port }}
-  ```
-
-]
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Apply changes
-
-- Re-run the for loop to execute `helm upgrade` one more time
-
-- Check the worker logs
-
-- This time, it should be working!
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-## Extra steps
-
-- We don't need to create a service for the worker
-
-- We can put the whole service block in a conditional
-
-  (this will require additional changes in other files referencing the service)
-
-- We can set the webui to be a NodePort service
-
-- We can change the number of workers with `replicaCount`
-
-- And much more!
-
-???
-
-:EN:- Writing better Helm charts for app components
-:FR:- Écriture de *charts* composant par composant
-
-.debug[[k8s/helm-create-better-chart.md](""/tree/main/slides/k8s/helm-create-better-chart.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg)]
-
----
-
-name: toc-charts-using-other-charts
-class: title
-
- Charts using other charts
-
-.nav[
-[Previous part](#toc-creating-better-helm-charts)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-helm-and-invalid-values)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Charts using other charts
-
-- Helm charts can have *dependencies* on other charts
-
-- These dependencies will help us to share or reuse components
-
-  (so that we write and maintain less manifests, less templates, less code!)
-
-- As an example, we will use a community chart for Redis
-
-- This will help people who write charts, and people who use them
-
-- ... And potentially remove a lot of code! ✌️
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Redis in DockerCoins
-
-- In the DockerCoins demo app, we have 5 components:
-
-  - 2 internal webservices
-  - 1 worker
-  - 1 public web UI
-  - 1 Redis data store
-
-- Every component is running some custom code, except Redis
-
-- Every component is using a custom image, except Redis
-
-  (which is using the official `redis` image)
-
-- Could we use a standard chart for Redis?
-
-- Yes! Dependencies to the rescue!
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Adding our dependency
-
-- First, we will add the dependency to the `Chart.yaml` file
-
-- Then, we will ask Helm to download that dependency
-
-- We will also *lock* the dependency
-
-  (lock it to a specific version, to ensure reproducibility)
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Declaring the dependency
-
-- First, let's edit `Chart.yaml`
-
-.lab[
-
-- In `Chart.yaml`, fill the `dependencies` section:
-  ```yaml
-    dependencies:
-      - name: redis
-        version: 11.0.5
-        repository: https://charts.bitnami.com/bitnami
-        condition: redis.enabled
-  ```
-
-]
-
-Where do that `repository` and `version` come from?
-
-We're assuming here that we did our research,
-or that our resident Helm expert advised us to
-use Bitnami's Redis chart.
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Conditions
-
-- The `condition` field gives us a way to enable/disable the dependency:
-  ```yaml
-  conditions: redis.enabled
-  ```
-
-- Here, we can disable Redis with the Helm flag `--set redis.enabled=false`
-
-  (or set that value in a `values.yaml` file)
-
-- Of course, this is mostly useful for *optional* dependencies
-
-  (otherwise, the app ends up being broken since it'll miss a component)
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Lock & Load!
-
-- After adding the dependency, we ask Helm to pin an download it
-
-.lab[
-
-- Ask Helm:
-  ```bash
-  helm dependency update
-  ```
-
-  (Or `helm dep up`)
-
-]
-
-- This wil create `Chart.lock` and fetch the dependency
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## What's `Chart.lock`?
-
-- This is a common pattern with dependencies
-
-  (see also: `Gemfile.lock`, `package.json.lock`, and many others)
-
-- This lets us define loose dependencies in `Chart.yaml`
-
-  (e.g. "version 11.whatever, but below 12")
-
-- But have the exact version used in `Chart.lock`
-
-- This ensures reproducible deployments
-
-- `Chart.lock` can (should!) be added to our source tree
-
-- `Chart.lock` can (should!) regularly be updated
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Loose dependencies
-
-- Here is an example of loose version requirement:
-  ```yaml
-    dependencies:
-      - name: redis
-        version: ">=11, <12"
-        repository: https://charts.bitnami.com/bitnami
-  ```
-
-- This makes sure that we have the most recent version in the 11.x train
-
-- ... But without upgrading to version 12.x
-
-  (because it might be incompatible)
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## `build` vs `update`
-
-- Helm actually offers two commands to manage dependencies:
-
-  `helm dependency build` = fetch dependencies listed in `Chart.lock`
-
-  `helm dependency update` = update `Chart.lock` (and run `build`)
-
-- When the dependency gets updated, we can/should:
-
-  - `helm dep up` (update `Chart.lock` and fetch new chart)
-
-  - test!
-
-  - if everything is fine, `git add Chart.lock` and commit
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Where are my dependencies?
-
-- Dependencies are downloaded to the `charts/` subdirectory
-
-- When they're downloaded, they stay in compressed format (`.tgz`)
-
-- Should we commit them to our code repository?
-
-- Pros:
-
-  - more resilient to internet/mirror failures/decomissioning
-
-- Cons:
-
-  - can add a lot of weight to the repo if charts are big or change often
-
-  - this can be solved by extra tools like git-lfs
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Dependency tuning
-
-- DockerCoins expects the `redis` Service to be named `redis`
-
-- Our Redis chart uses a different Service name by default
-
-- Service name is `{{ template "redis.fullname" . }}-master`
-
-- `redis.fullname` looks like this:
-  ```
-    {{- define "redis.fullname" -}}
-    {{- if .Values.fullnameOverride -}}
-    {{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}}
-    {{- else -}}
-    [...]
-    {{- end }}
-    {{- end }}
-  ```
-
-- How do we fix this?
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Setting dependency variables
-
-- If we set `fullnameOverride` to `redis`:
-
-  - the `{{ template ... }}` block will output `redis`
-
-  - the Service name will be `redis-master`
-
-- A parent chart can set values for its dependencies
-
-- For example, in the parent's `values.yaml`:
-
-  ```yaml
-    redis:                    # Name of the dependency
-      fullnameOverride: redis # Value passed to redis
-      cluster:                # Other values passed to redis
-        enabled: false
-  ```
-
-- User can also set variables with `--set=` or with `--values=`
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-class: extra-details
-
-## Passing templates
-
-- We can even pass template `{{ include "template.name" }}`, but warning:
-
-   - need to be evaluated with the `tpl` function, on the child side
-
-   - evaluated in the context of the child, with no access to parent variables
-
-<!-- FIXME this probably deserves an example, but I can't imagine one right now 😅 -->
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Getting rid of the `-master`
-
-- Even if we set that `fullnameOverride`, the Service name will be `redis-master`
-
-- To remove the `-master` suffix, we need to edit the chart itself
-
-- To edit the Redis chart, we need to *embed* it in our own chart
-
-- We need to:
-
-  - decompress the chart
-
-  - adjust `Chart.yaml` accordingly
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Embedding a dependency
-
-.lab[
-
-- Decompress the chart:
-  ```yaml
-  cd charts
-  tar zxf redis-*.tgz
-  cd ..
-  ```
-
-- Edit `Chart.yaml` and update the `dependencies` section:
-  ```yaml
-    dependencies:
-      - name: redis
-        version: '*' # No need to constraint version, from local files
-  ```
-
-- Run `helm dep update`
-
-]
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Updating the dependency
-
-- Now we can edit the Service name
-
-  (it should be in `charts/redis/templates/redis-master-svc.yaml`)
-
-- Then try to deploy the whole chart!
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-## Embedding a dependency multiple times
-
-- What if we need multiple copies of the same subchart?
-
-  (for instance, if we need two completely different Redis servers)
-
-- We can declare a dependency multiple times, and specify an `alias`:
-  ```yaml
-  dependencies:
-    - name: redis
-      version: '*'
-      alias: querycache
-    - name: redis
-      version: '*'
-      alias: celeryqueue
-  ```
-
-- `.Chart.Name` will be set to the `alias`
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-class: extra-details
-
-## Determining if we're in a subchart
-
-- `.Chart.IsRoot` indicates if we're in the top-level chart or in a sub-chart
-
-- Useful in charts that are designed to be used standalone or as dependencies
-
-- Example: generic chart
-
-  - when used standalone (`.Chart.IsRoot` is `true`), use `.Release.Name`
-
-  - when used as a subchart e.g. with multiple aliases, use `.Chart.Name`
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-class: extra-details
-
-## Compatibility with Helm 2
-
-- Chart `apiVersion: v1` is the only version supported by Helm 2
-
-- Chart v1 is also supported by Helm 3
-
-- Use v1 if you want to be compatible with Helm 2
-
-- Instead of `Chart.yaml`, dependencies are defined in `requirements.yaml`
-
-  (and we should commit `requirements.lock` instead of `Chart.lock`)
-
-???
-
-:EN:- Depending on other charts
-:EN:- Charts within charts
-
-:FR:- Dépendances entre charts
-:FR:- Un chart peut en cacher un autre
-
-.debug[[k8s/helm-dependencies.md](""/tree/main/slides/k8s/helm-dependencies.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-housing.jpg)]
-
----
-
-name: toc-helm-and-invalid-values
-class: title
-
- Helm and invalid values
-
-.nav[
-[Previous part](#toc-charts-using-other-charts)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-helm-secrets)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Helm and invalid values
-
-- A lot of Helm charts let us specify an image tag like this:
-  ```bash
-  helm install ... --set image.tag=v1.0
-  ```
-
-- What happens if we make a small mistake, like this:
-  ```bash
-  helm install ... --set imagetag=v1.0
-  ```
-
-- Or even, like this:
-  ```bash
-  helm install ... --set image=v1.0
-  ```
-
-🤔
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-## Making mistakes
-
-- In the first case:
-
-  - we set `imagetag=v1.0` instead of `image.tag=v1.0`
-
-  - Helm will ignore that value (if it's not used anywhere in templates)
-
-  - the chart is deployed with the default value instead
-
-- In the second case:
-
-  - we set `image=v1.0` instead of `image.tag=v1.0`
-
-  - `image` will be a string instead of an object
-
-  - Helm will *probably* fail when trying to evaluate `image.tag`
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-## Preventing mistakes
-
-- To prevent the first mistake, we need to tell Helm:
-
-  *"let me know if any additional (unknown) value was set!"*
-
-- To prevent the second mistake, we need to tell Helm:
-
-  *"`image` should be an object, and `image.tag` should be a string!"*
-
-- We can do this with *values schema validation*
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-## Helm values schema validation
-
-- We can write a spec representing the possible values accepted by the chart
-
-- Helm will check the validity of the values before trying to install/upgrade
-
-- If it finds problems, it will stop immediately
-
-- The spec uses [JSON Schema](https://json-schema.org/):
-
-  *JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.*
-
-- JSON Schema is designed for JSON, but can easily work with YAML too
-
-  (or any language with `map|dict|associativearray` and `list|array|sequence|tuple`)
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-## In practice
-
-- We need to put the JSON Schema spec in a file called `values.schema.json`
-
-  (at the root of our chart; right next to `values.yaml` etc.)
-
-- The file is optional
-
-- We don't need to register or declare it in `Chart.yaml` or anywhere
-
-- Let's write a schema that will verify that ...
-
-  - `image.repository` is an official image (string without slashes or dots)
-
-  - `image.pullPolicy` can only be `Always`, `Never`, `IfNotPresent`
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-## `values.schema.json`
-
-```json
-{
-  "$schema": "http://json-schema.org/schema#",
-  "type": "object",
-  "properties": {
-    "image": {
-      "type": "object",
-      "properties": {
-        "repository": {
-          "type": "string",
-          "pattern": "^[a-z0-9-_]+$"
-        },
-        "pullPolicy": {
-          "type": "string",
-          "pattern": "^(Always|Never|IfNotPresent)$"
-        }
-      } 
-    } 
-  } 
-}
-```
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-## Testing our schema
-
-- Let's try to install a couple releases with that schema!
-
-.lab[
-
-- Try an invalid `pullPolicy`:
-  ```bash
-  helm install broken --set image.pullPolicy=ShallNotPass
-  ```
-
-- Try an invalid value:
-  ```bash
-  helm install should-break --set ImAgeTAg=toto
-  ```
-
-]
-
-- The first one fails, but the second one still passes ...
-
-- Why?
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-## Bailing out on unkown properties
-
-- We told Helm what properties (values) were valid
-
-- We didn't say what to do about additional (unknown) properties!
-
-- We can fix that with `"additionalProperties": false`
-
-.lab[
-
-- Edit `values.schema.json` to add `"additionalProperties": false`
-  ```json
-    {
-      "$schema": "http://json-schema.org/schema#",
-      "type": "object",
-      "additionalProperties": false,
-      "properties": {
-      ...
-  ```
-
-]
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-## Testing with unknown properties
-
-.lab[
-
-- Try to pass an extra property:
-  ```bash
-  helm install should-break --set ImAgeTAg=toto
-  ```
-
-- Try to pass an extra nested property:
-  ```bash
-  helm install does-it-work --set image.hello=world
-  ```
-
-]
-
-The first command should break.
-
-The second will not.
-
-`"additionalProperties": false` needs to be specified at each level.
-
-???
-
-:EN:- Helm schema validation
-:FR:- Validation de schema Helm
-
-.debug[[k8s/helm-values-schema-validation.md](""/tree/main/slides/k8s/helm-values-schema-validation.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/containers-by-the-water.jpg)]
-
----
-
-name: toc-helm-secrets
-class: title
-
- Helm secrets
-
-.nav[
-[Previous part](#toc-helm-and-invalid-values)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-ytt)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Helm secrets
-
-- Helm can do *rollbacks*:
-
-  - to previously installed charts
-
-  - to previous sets of values
-
-- How and where does it store the data needed to do that?
-
-- Let's investigate!
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Adding the repo
-
-- If you haven't done it before, you need to add the repo for that chart
-
-.lab[
-
-- Add the repo that holds the chart for the OWASP Juice Shop:
-  ```bash
-  helm repo add juice https://charts.securecodebox.io
-  ```
-
-]
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## We need a release
-
-- We need to install something with Helm
-
-- Let's use the `juice/juice-shop` chart as an example
-
-.lab[
-
-- Install a release called `orange` with the chart `juice/juice-shop`:
-  ```bash
-  helm upgrade orange juice/juice-shop --install
-  ```
-
-- Let's upgrade that release, and change a value:
-  ```bash
-  helm upgrade orange juice/juice-shop --set ingress.enabled=true
-  ```
-
-]
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Release history
-
-- Helm stores successive revisions of each release
-
-.lab[
-
-- View the history for that release:
-  ```bash
-  helm history orange
-  ```
-
-]
-
-Where does that come from?
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Investigate
-
-- Possible options:
-
-  - local filesystem (no, because history is visible from other machines)
-
-  - persistent volumes (no, Helm works even without them)
-
-  - ConfigMaps, Secrets?
-
-.lab[
-
-- Look for ConfigMaps and Secrets:
-  ```bash
-  kubectl get configmaps,secrets
-  ```
-
-]
-
---
-
-We should see a number of secrets with TYPE `helm.sh/release.v1`.
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Unpacking a secret
-
-- Let's find out what is in these Helm secrets
-
-.lab[
-
-- Examine the secret corresponding to the second release of `orange`:
-  ```bash
-  kubectl describe secret sh.helm.release.v1.orange.v2
-  ```
-  (`v1` is the secret format; `v2` means revision 2 of the `orange` release)
-
-]
-
-There is a key named `release`.
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Unpacking the release data
-
-- Let's see what's in this `release` thing!
-
-.lab[
-
-- Dump the secret:
-  ```bash
-  kubectl get secret sh.helm.release.v1.orange.v2 \
-      -o go-template='{{ .data.release }}'
-  ```
-
-]
-
-Secrets are encoded in base64. We need to decode that!
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Decoding base64
-
-- We can pipe the output through `base64 -d` or use go-template's `base64decode`
-
-.lab[
-
-- Decode the secret:
-  ```bash
-  kubectl get secret sh.helm.release.v1.orange.v2 \
-      -o go-template='{{ .data.release | base64decode }}'
-  ```
-
-]
-
---
-
-... Wait, this *still* looks like base64. What's going on?
-
---
-
-Let's try one more round of decoding!
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Decoding harder
-
-- Just add one more base64 decode filter
-
-.lab[
-
-- Decode it twice:
-  ```bash
-  kubectl get secret sh.helm.release.v1.orange.v2 \
-      -o go-template='{{ .data.release | base64decode | base64decode }}'
-  ```
-
-]
-
---
-
-... OK, that was *a lot* of binary data. What should we do with it?
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Guessing data type
-
-- We could use `file` to figure out the data type
-
-.lab[
-
-- Pipe the decoded release through `file -`:
-  ```bash
-  kubectl get secret sh.helm.release.v1.orange.v2 \
-      -o go-template='{{ .data.release | base64decode | base64decode }}' \
-      | file -
-  ```
-
-]
-
---
-
-Gzipped data! It can be decoded with `gunzip -c`.
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Uncompressing the data
-
-- Let's uncompress the data and save it to a file
-
-.lab[
-
-- Rerun the previous command, but with `| gunzip -c > release-info` :
-  ```bash
-  kubectl get secret sh.helm.release.v1.orange.v2 \
-      -o go-template='{{ .data.release | base64decode | base64decode }}' \
-      | gunzip -c > release-info
-  ```
-
-- Look at `release-info`:
-  ```bash
-  cat release-info
-  ```
-
-]
-
---
-
-It's a bundle of ~~YAML~~ JSON.
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Looking at the JSON
-
-If we inspect that JSON (e.g. with `jq keys release-info`), we see:
-
-- `chart` (contains the entire chart used for that release)
-- `config` (contains the values that we've set)
-- `info` (date of deployment, status messages)
-- `manifest` (YAML generated from the templates)
-- `name` (name of the release, so `orange`)
-- `namespace` (namespace where we deployed the release)
-- `version` (revision number within that release; starts at 1)
-
-The chart is in a structured format, but it's entirely captured in this JSON.
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-## Conclusions
-
-- Helm stores each release information in a Secret in the namespace of the release
-
-- The secret is JSON object (gzipped and encoded in base64)
-
-- It contains the manifests generated for that release
-
-- ... And everything needed to rebuild these manifests
-
-  (including the full source of the chart, and the values used)
-
-- This allows arbitrary rollbacks, as well as tweaking values even without having access to the source of the chart (or the chart repo) used for deployment
-
-???
-
-:EN:- Deep dive into Helm internals
-:FR:- Fonctionnement interne de Helm
-
-.debug[[k8s/helm-secrets.md](""/tree/main/slides/k8s/helm-secrets.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/distillery-containers.jpg)]
-
----
-
-name: toc-ytt
-class: title
-
- YTT
-
-.nav[
-[Previous part](#toc-helm-secrets)
-|
-[Back to table of contents](#toc-part-4)
-|
-[Next part](#toc-extending-the-kubernetes-api)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# YTT
-
-- YAML Templating Tool
-
-- Part of [Carvel]
-
-  (a set of tools for Kubernetes application building, configuration, and deployment)
-
-- Can be used for any YAML
-
-  (Kubernetes, Compose, CI pipelines...)
-
-[Carvel]: https://carvel.dev/
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Features
-
-- Manipulate data structures, not text (≠ Helm)
-
-- Deterministic, hermetic execution
-
-- Define variables, blocks, functions
-
-- Write code in Starlark (dialect of Python)
-
-- Define and override values (Helm-style)
-
-- Patch resources arbitrarily (Kustomize-style)
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Getting started
-
-- Install `ytt` ([binary download][download])
-
-- Start with one (or multiple) Kubernetes YAML files
-
-  *(without comments; no `#` allowed at this point!)*
-
-- `ytt -f one.yaml -f two.yaml | kubectl apply -f-`
-
-- `ytt -f. | kubectl apply -f-`
-
-[download]: https://github.com/vmware-tanzu/carvel-ytt/releases/latest
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## No comments?!?
-
-- Replace `#` with `#!`
-
-- `#@` is used by ytt
-
-- It's a kind of template tag, for instance:
-
-  ```yaml
-  #! This is a comment
-  #@ a = 42
-  #@ b = "*"
-  a: #@ a
-  b: #@ b
-  operation: multiply
-  result: #@ a*b
-  ```
-
-- `#@` at the beginning of a line = instruction
-
-- `#@` somewhere else = value
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Building strings
-
-- Concatenation:
-
-  ```yaml
-    #@ repository = "dockercoins"
-    #@ tag = "v0.1"
-    containers:
-    - name: worker
-      image: #@ repository + "/worker:" + tag
-  ```
-
-- Formatting:
-
-  ```yaml
-    #@ repository = "dockercoins"
-    #@ tag = "v0.1"
-    containers:
-    - name: worker
-      image: #@ "{}/worker:{}".format(repository, tag)
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Defining functions
-
-- Reusable functions can be written in Starlark (=Python)
-
-- Blocks (`def`, `if`, `for`...) must be terminated with `#@ end`
-
-- Example:
-
-  ```yaml
-    #@ def image(component, repository="dockercoins", tag="v0.1"):
-    #@   return "{}/{}:{}".format(repository, component, tag)
-    #@ end
-    containers:
-    - name: worker
-      image: #@ image("worker")
-    - name: hasher
-      image: #@ image("hasher")
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Structured data
-
-- Functions can return complex types
-
-- Example: defining a common set of labels
-
-  ```yaml
-    #@ name = "worker"
-    #@ def labels(component):
-    #@   return {
-    #@     "app": component,
-    #@     "container.training/generated-by": "ytt",
-    #@   }
-    #@ end
-    kind: Pod
-    apiVersion: v1
-    metadata:
-      name: #@ name
-      labels: #@ labels(name)
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## YAML functions
-
-- Function body can also be straight YAML:
-
-  ```yaml
-    #@ name = "worker"
-
-    #@ def labels(component):
-    app: #@ component
-    container.training/generated-by: ytt
-    #@ end
-
-    kind: Pod
-    apiVersion: v1
-    metadata:
-      name: #@ name
-      labels: #@ labels(name)
-  ```
-
-- The return type of the function is then a [YAML fragment][fragment]
-
-[fragment]: https://carvel.dev/ytt/docs/v0.41.0/
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## More YAML functions
-
-- We can load library functions:
-  ```yaml
-  #@ load("@ytt:sha256", "sha256")
-  ```
-
-- This is (sort of) equivalent fo `from ytt.sha256 import sha256`
-
-- Functions can contain a mix of code and YAML fragment:
-  
-  ```yaml
-    #@ load("@ytt:sha256", "sha256")
-
-    #@ def annotations():
-    #@ author = "Jérôme Petazzoni"
-    author: #@ author
-    author_hash: #@ sha256.sum(author)[:8]
-    #@ end
-
-    annotations: #@ annotations()
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Data values
-
-- We can define a *schema* in a separate file:
-  ```yaml
-    #@data/values-schema
-    --- #! there must be a "---" here!
-    repository: dockercoins
-    tag: v0.1
-  ```
-
-- This defines the data values (=customizable parameters),
-
-  as well as their *types* and *default values*
-
-- Technically, `#@data/values-schema` is an annotation,
-  and it applies to a YAML document; so the following
-  element must be a YAML document
-
-- This is conceptually similar to Helm's *values* file
-  <br/>
-  (but with type enforcement as a bonus)
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Using data values
-
-- Requires loading `@ytt:data`
-
-- Values are then available in `data.values`
-
-- Example:
-
-  ```yaml
-    #@ load("@ytt:data", "data")
-    #@ def image(component):
-    #@   return "{}/{}:{}".format(data.values.repository, component, data.values.tag)
-    #@ end
-    #@ name = "worker"
-    containers:
-    - name: #@ name
-      image: #@ image(name)
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Overriding data values
-
-- There are many ways to set and override data values:
-
-  - plain YAML files
-
-  - data value overlays
-
-  - environment variables
-
-  - command-line flags
-
-- Precedence of the different methods is defined in the [docs]
-
-[docs]: https://carvel.dev/ytt/docs/v0.41.0/ytt-data-values/#data-values-merge-order
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Values in plain YAML files
-
-- Content of `values.yaml`:
-  ```yaml
-  tag: latest
-  ```
-
-- Values get merged with `--data-values-file`:
-  ```bash
-  ytt -f config/ --data-values-file values.yaml
-  ```
-
-- Multiple files can be specified
-
-- These files can also be URLs!
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Data value overlay
-
-- Content of `values.yaml`:
-  ```yaml
-  #@data/values
-  --- #! must have --- here
-  tag: latest
-  ```
-
-- Values get merged by being specified like "normal" files:
-  ```bash
-  ytt -f config/ -f values.yaml
-  ```
-
-- Multiple files can be specified
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Set a value with a flag
-
-- Set a string value:
-  ```bash
-  ytt -f config/ --data-value tag=latest
-  ```
-
-- Set a YAML value (useful to parse it as e.g. integer, boolean...):
-  ```bash
-  ytt -f config/ --data-value-yaml replicas=10
-  ```
-
-- Read a string value from a file:
-  ```bash
-  ytt -f config/ --data-value-file ca_cert=cert.pem
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Set values from environment variables
-
-- Set environment variables with a prefix:
-  ```bash
-  export VAL_tag=latest
-  export VAL_repository=ghcr.io/dockercoins
-  ```
-
-- Use the variables as strings:
-  ```bash
-  ytt -f config/ --data-values-env VAL
-  ```
-
-- Or parse them as YAML:
-  ```bash
-  ytt -f config/ --data-values-env-yaml VAL
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Lines starting with `#@`
-
-- This generates an empty document:
-  ```yaml
-  #@ def hello():
-  hello: world
-  #@ end
-  
-  #@ hello()
-  ```
-
-- Do this instead:
-  ```yaml
-  #@ def hello():
-  hello: world
-  #@ end
-  
-  --- #@ hello()
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Generating multiple documents, take 1
-
-- This won't work:
-
-  ```yaml
-  #@ def app():
-  kind: Deployment
-  apiVersion: apps/v1
-  --- #! separate from next document
-  kind: Service
-  apiVersion: v1
-  #@ end
-
-  --- #@ app()
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Generating multiple documents, take 2
-
-- This won't work either:
-
-  ```yaml
-  #@ def app():
-  --- #! the initial separator indicates "this is a Document Set"
-  kind: Deployment
-  apiVersion: apps/v1
-  --- #! separate from next document
-  kind: Service
-  apiVersion: v1
-  #@ end
-
-  --- #@ app()
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Generating multiple documents, take 3
-
-- We must use the `template` module:
-
-  ```yaml
-  #@ load("@ytt:template", "template")
-
-  #@ def app():
-  --- #! the initial separator indicates "this is a Document Set"
-  kind: Deployment
-  apiVersion: apps/v1
-  --- #! separate from next document
-  kind: Service
-  apiVersion: v1
-  #@ end
-
-  --- #@ template.replace(app())
-  ```
-
-- `template.replace(...)` is the only way (?) to replace one element with many
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Libraries
-
-- A reusable ytt configuration can be transformed into a library
-
-- Put it in a subdirectory named `_ytt_lib/whatever`, then:
-
-  ```yaml
-  #@ load("@ytt:library", "library")
-  #@ load("@ytt:template", "template")
-  #@ whatever = library.get("whatever")
-  #@ my_values = {"tag": "latest", "registry": "..."}
-  #@ output = whatever.with_data_values(my_values).eval()
-  --- #@ template.replace(output)
-  ```
-
-- The `with_data_values()` step is optional, but useful to "configure" the library
-
-- Note the whole combo:
-  ```yaml
-  template.replace(library.get("...").with_data_values(...).eval())
-  ```
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Overlays
-
-- Powerful, but complex, but powerful! 💥
-
-- Define transformations that are applied after generating the whole document set
-
-- General idea:
-
-  - select YAML nodes to be transformed with an `#@overlay/match` decorator
-
-  - write a YAML snippet with the modifications to be applied
-    <br/>
-    (a bit like a strategic merge patch)
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Example
-
-```yaml
-#@ load("@ytt:overlay", "overlay")
-
-#@ selector = {"kind": "Deployment", "metadata": {"name": "worker"}}
-#@overlay/match by=overlay.subset(selector)
---- 
-spec:
-  replicas: 10
-```
-
-- By default, `#@overlay/match` must find *exactly* one match
-
-  (that can be changed by specifying `expects=...`, `missing_ok=True`... see [docs])
-
-- By default, the specified fields (here, `spec.replicas`) must exist
-
-  (that can also be changed by annotating the optional fields)
-
-[docs]: https://carvel.dev/ytt/docs/v0.41.0/lang-ref-ytt-overlay/#overlaymatch
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Matching using a YAML document
-
-```yaml
-#@ load("@ytt:overlay", "overlay")
-
-#@ def match():
-kind: Deployment
-metadata:
-  name: worker
-#@ end
-
-#@overlay/match by=overlay.subset(match())
---- 
-spec:
-  replicas: 10
-```
-
-- This is equivalent to the subset match of the previous slide
-
-- It will find YAML nodes having all the listed fields
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Removing a field
-
-```yaml
-#@ load("@ytt:overlay", "overlay")
-
-#@ def match():
-kind: Deployment
-metadata:
-  name: worker
-#@ end
-
-#@overlay/match by=overlay.subset(match())
---- 
-spec:
-  #@overlay/remove
-  replicas:
-```
-
-- This would remove the `replicas:` field from a specific Deployment spec
-
-- This could be used e.g. when enabling autoscaling
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Selecting multiple nodes
-
-```yaml
-#@ load("@ytt:overlay", "overlay")
-
-#@ def match():
-kind: Deployment
-#@ end
-
-#@overlay/match by=overlay.subset(match()), expects="1+"
---- 
-spec:
-  #@overlay/remove
-  replicas:
-```
-
-- This would match all Deployments
-  <br/>
-  (assuming that *at least one* exists)
-
-- It would remove the `replicas:` field from their spec
-  <br/>
-  (the field must exist!)
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Adding a field
-
-```yaml
-#@ load("@ytt:overlay", "overlay")
-
-#@overlay/match by=overlay.all, expects="1+"
---- 
-metadata:
-  #@overlay/match missing_ok=True
-  annotations:
-    #@overlay/match expects=0
-    rainbow: 🌈
-```
-
-- `#@overlay/match missing_ok=True`
-  <br/>
-  *will match whether our resources already have annotations or not*
-
-- `#@overlay/match expects=0`
-  <br/>
-  *will only match if the `rainbow` annotation doesn't exist*
-  <br/>
-  *(to make sure that we don't override/replace an existing annotation)*
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Overlays vs data values
-
-- The documentation has a [detailed discussion][docs] about this question
-
-- In short:
-
-  - values = for parameters that are exposed to the user
-
-  - overlays = for arbitrary extra modifications
-
-- Values are easier to use (use them when possible!)
-
-- Fallback to overlays when values don't expose what you need
-
-  (keeping in mind that overlays are harder to write/understand/maintain)
-
-[docs]: https://carvel.dev/ytt/docs/v0.41.0/data-values-vs-overlays/
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Gotchas
-
-- Reminder: put your `#@` at the right place!
-
-```yaml
-#! This will generate "hello, world!"
---- #@ "{}, {}!".format("hello", "world")
-```
-
-```yaml
-#! But this will generate an empty document
---- 
-#@ "{}, {}!".format("hello", "world")
-```
-
-- Also, don't use YAML anchors (`*foo` and `&foo`)
-
-- They don't mix well with ytt
-
-- Remember to use `template.render(...)` when generating multiple nodes
-
-  (or to update lists or arrays without replacing them entirely)
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-## Next steps with ytt
-
-- Read this documentation page about [injecting secrets][secrets]
-
-- Check the [FAQ], it gives some insights about what's possible with ytt
-
-- Exercise idea: write an overlay that will find all ConfigMaps mounted in Pods...
-
-  ...and annotate the Pod with a hash of the ConfigMap
-
-[FAQ]: https://carvel.dev/ytt/docs/v0.41.0/faq/
-[secrets]: https://carvel.dev/ytt/docs/v0.41.0/injecting-secrets/
-
-???
-
-:EN:- YTT
-:FR:- YTT
-
-.debug[[k8s/ytt.md](""/tree/main/slides/k8s/ytt.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/lots-of-containers.jpg)]
-
----
-
-name: toc-extending-the-kubernetes-api
-class: title
-
- Extending the Kubernetes API
-
-.nav[
-[Previous part](#toc-ytt)
-|
-[Back to table of contents](#toc-part-5)
-|
-[Next part](#toc-operators)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Extending the Kubernetes API
-
-There are multiple ways to extend the Kubernetes API.
-
-We are going to cover:
-
-- Controllers
-
-- Dynamic Admission Webhooks
-
-- Custom Resource Definitions (CRDs)
-
-- The Aggregation Layer
-
-But first, let's re(re)visit the API server ...
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Revisiting the API server
-
-- The Kubernetes API server is a central point of the control plane
-
-- Everything connects to the API server:
-
-  - users (that's us, but also automation like CI/CD)
-
-  - kubelets
-
-  - network components (e.g. `kube-proxy`, pod network, NPC)
-
-  - controllers; lots of controllers
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Some controllers
-
-- `kube-controller-manager` runs built-on controllers
-
-  (watching Deployments, Nodes, ReplicaSets, and much more)
-
-- `kube-scheduler` runs the scheduler
-
-  (it's conceptually not different from another controller)
-
-- `cloud-controller-manager` takes care of "cloud stuff"
-
-  (e.g. provisioning load balancers, persistent volumes...)
-
-- Some components mentioned above are also controllers
-
-  (e.g. Network Policy Controller)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## More controllers
-
-- Cloud resources can also be managed by additional controllers
-
-  (e.g. the [AWS Load Balancer Controller](https://github.com/kubernetes-sigs/aws-load-balancer-controller))
-
-- Leveraging Ingress resources requires an Ingress Controller
-
-  (many options available here; we can even install multiple ones!)
-
-- Many add-ons (including CRDs and operators) have controllers as well
-
-🤔 *What's even a controller ?!?*
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## What's a controller?
-
-According to the [documentation](https://kubernetes.io/docs/concepts/architecture/controller/):
-
-*Controllers are **control loops** that<br/>
-**watch** the state of your cluster,<br/>
-then make or request changes where needed.*
-
-*Each controller tries to move the current cluster state closer to the desired state.*
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## What controllers do
-
-- Watch resources
-
-- Make changes:
-
-  - purely at the API level (e.g. Deployment, ReplicaSet controllers)
-
-  - and/or configure resources (e.g. `kube-proxy`)
-
-  - and/or provision resources (e.g. load balancer controller)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Extending Kubernetes with controllers
-
-- Random example:
-
-  - watch resources like Deployments, Services ...
-
-  - read annotations to configure monitoring
-
-- Technically, this is not extending the API
-
-  (but it can still be very useful!)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Other ways to extend Kubernetes
-
-- Prevent or alter API requests before resources are committed to storage:
-
-  *Admission Control*
-
-- Create new resource types leveraging Kubernetes storage facilities:
-
-  *Custom Resource Definitions*
-
-- Create new resource types with different storage or different semantics:
-
-  *Aggregation Layer*
-
-- Spoiler alert: often, we will combine multiple techniques
-
-  (and involve controllers as well!)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Admission controllers
-
-- Admission controllers can vet or transform API requests
-
-- The diagram on the next slide shows the path of an API request
-
-  (courtesy of Banzai Cloud)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-class: pic
-
-![API request lifecycle](images/api-request-lifecycle.png)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Types of admission controllers
-
-- *Validating* admission controllers can accept/reject the API call
-
-- *Mutating* admission controllers can modify the API request payload
-
-- Both types can also trigger additional actions
-
-  (e.g. automatically create a Namespace if it doesn't exist)
-
-- There are a number of built-in admission controllers
-
-  (see [documentation](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do) for a list)
-
-- We can also dynamically define and register our own
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-class: extra-details
-
-## Some built-in admission controllers
-
-- ServiceAccount:
-
-  automatically adds a ServiceAccount to Pods that don't explicitly specify one
-
-- LimitRanger:
-
-  applies resource constraints specified by LimitRange objects when Pods are created
-
-- NamespaceAutoProvision:
-
-  automatically creates namespaces when an object is created in a non-existent namespace
-
-*Note: #1 and #2 are enabled by default; #3 is not.*
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Dynamic Admission Control
-
-- We can set up *admission webhooks* to extend the behavior of the API server
-
-- The API server will submit incoming API requests to these webhooks
-
-- These webhooks can be *validating* or *mutating*
-
-- Webhooks can be set up dynamically (without restarting the API server)
-
-- To setup a dynamic admission webhook, we create a special resource:
-
-  a `ValidatingWebhookConfiguration` or a `MutatingWebhookConfiguration`
-
-- These resources are created and managed like other resources
-
-  (i.e. `kubectl create`, `kubectl get`...)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Webhook Configuration
-
-- A ValidatingWebhookConfiguration or MutatingWebhookConfiguration contains:
-
-  - the address of the webhook
-
-  - the authentication information to use with the webhook
-
-  - a list of rules
-
-- The rules indicate for which objects and actions the webhook is triggered
-
-  (to avoid e.g. triggering webhooks when setting up webhooks)
-
-- The webhook server can be hosted in or out of the cluster
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Dynamic Admission Examples
-
-- Policy control
-
-  ([Kyverno](https://kyverno.io/),
-  [Open Policy Agent](https://www.openpolicyagent.org/docs/latest/))
-
-- Sidecar injection
-
-  (Used by some service meshes)
-
-- Type validation
-
-  (More on this later, in the CRD section)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Kubernetes API types
-
-- Almost everything in Kubernetes is materialized by a resource
-
-- Resources have a type (or "kind")
-
-  (similar to strongly typed languages)
-
-- We can see existing types with `kubectl api-resources`
-
-- We can list resources of a given type with `kubectl get <type>`
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Creating new types
-
-- We can create new types with Custom Resource Definitions (CRDs)
-
-- CRDs are created dynamically
-
-  (without recompiling or restarting the API server)
-
-- CRDs themselves are resources:
-
-  - we can create a new type with `kubectl create` and some YAML
-
-  - we can see all our custom types with `kubectl get crds`
-
-- After we create a CRD, the new type works just like built-in types
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Examples
-
-- Representing composite resources
-
-  (e.g. clusters like databases, messages queues ...)
-
-- Representing external resources
-
-  (e.g. virtual machines, object store buckets, domain names ...)
-
-- Representing configuration for controllers and operators
-
-  (e.g. custom Ingress resources, certificate issuers, backups ...)
-
-- Alternate representations of other objects; services and service instances
-
-  (e.g. encrypted secret, git endpoints ...)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## The aggregation layer
-
-- We can delegate entire parts of the Kubernetes API to external servers
-
-- This is done by creating APIService resources
-
-  (check them with `kubectl get apiservices`!)
-
-- The APIService resource maps a type (kind) and version to an external service
-
-- All requests concerning that type are sent (proxied) to the external service
-
-- This allows to have resources like CRDs, but that aren't stored in etcd
-
-- Example: `metrics-server`
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Why?
-
-- Using a CRD for live metrics would be extremely inefficient
-
-  (etcd **is not** a metrics store; write performance is way too slow)
-
-- Instead, `metrics-server`:
-
-  - collects metrics from kubelets
-
-  - stores them in memory
-
-  - exposes them as PodMetrics and NodeMetrics (in API group metrics.k8s.io)
-
-  - is registered as an APIService
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Drawbacks
-
-- Requires a server
-
-- ... that implements a non-trivial API (aka the Kubernetes API semantics)
-
-- If we need REST semantics, CRDs are probably way simpler
-
-- *Sometimes* synchronizing external state with CRDs might do the trick
-
-  (unless we want the external state to be our single source of truth)
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Service catalog
-
-- *Service catalog* is another extension mechanism
-
-- It's not extending the Kubernetes API strictly speaking
-
-  (but it still provides new features!)
-
-- It doesn't create new types; it uses:
-
-  - ClusterServiceBroker
-  - ClusterServiceClass
-  - ClusterServicePlan
-  - ServiceInstance
-  - ServiceBinding
-
-- It uses the Open service broker API
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-## Documentation
-
-- [Custom Resource Definitions: when to use them](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
-
-- [Custom Resources Definitions: how to use them](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
-
-- [Service Catalog](https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/)
-
-- [Built-in Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
-
-- [Dynamic Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)
-
-- [Aggregation Layer](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
-
-???
-
-:EN:- Overview of Kubernetes API extensions
-:FR:- Comment étendre l'API Kubernetes
-
-.debug[[k8s/extending-api.md](""/tree/main/slides/k8s/extending-api.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/plastic-containers.JPG)]
-
----
-
-name: toc-operators
-class: title
-
- Operators
-
-.nav[
-[Previous part](#toc-extending-the-kubernetes-api)
-|
-[Back to table of contents](#toc-part-5)
-|
-[Next part](#toc-sealed-secrets)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Operators
-
-The Kubernetes documentation describes the [Operator pattern] as follows:
-
-*Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components. Operators follow Kubernetes principles, notably the control loop.*
-
-Another good definition from [CoreOS](https://coreos.com/blog/introducing-operators.html):
-
-*An operator represents **human operational knowledge in software,**
-<br/>
-to reliably manage an application.*
-
-There are many different use cases spanning different domains; but the general idea is:
-
-*Manage some resources (that reside inside our outside the cluster),
-<br/>
-using Kubernetes manifests and tooling.*
-
-[Operator pattern]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
-
-.debug[[k8s/operators.md](""/tree/main/slides/k8s/operators.md)]
----
-
-## Some uses cases
-
-- Managing external resources ([AWS], [GCP], [KubeVirt]...)
-
-- Setting up database replication or distributed systems
-  <br/>
-  (Cassandra, Consul, CouchDB, ElasticSearch, etcd, Kafka, MongoDB, MySQL, PostgreSQL, RabbitMQ, Redis, ZooKeeper...)
-
-- Running and configuring CI/CD
-  <br/>
-  ([ArgoCD], [Flux]), backups ([Velero]), policies ([Gatekeeper], [Kyverno])...
-
-- Automating management of certificates and secrets
-  <br/>
-  ([cert-manager]), secrets ([External Secrets Operator], [Sealed Secrets]...)
-
-- Configuration of cluster components ([Istio], [Prometheus])
-
-- etc.
-
-[ArgoCD]: https://github.com/argoproj/argo-cd
-[AWS]: https://aws-controllers-k8s.github.io/community/docs/community/services/
-[cert-manager]: https://cert-manager.io/
-[External Secrets Operator]: https://external-secrets.io/
-[Flux]: https://fluxcd.io/
-[Gatekeeper]: https://open-policy-agent.github.io/gatekeeper/website/docs/
-[GCP]: https://github.com/paulczar/gcp-cloud-compute-operator
-[Istio]: https://istio.io/latest/docs/setup/install/operator/
-[KubeVirt]: https://kubevirt.io/
-[Kyverno]: https://kyverno.io/
-[Prometheus]: https://prometheus-operator.dev/
-[Sealed Secrets]: https://github.com/bitnami-labs/sealed-secrets
-[Velero]: https://velero.io/
-
-.debug[[k8s/operators.md](""/tree/main/slides/k8s/operators.md)]
----
-
-## What are they made from?
-
-- Operators combine two things:
-
-  - Custom Resource Definitions
-
-  - controller code watching the corresponding resources and acting upon them
-
-- A given operator can define one or multiple CRDs
-
-- The controller code (control loop) typically runs within the cluster
-
-  (running as a Deployment with 1 replica is a common scenario)
-
-- But it could also run elsewhere
-
-  (nothing mandates that the code run on the cluster, as long as it has API access)
-
-.debug[[k8s/operators.md](""/tree/main/slides/k8s/operators.md)]
----
-
-## Operators for e.g. replicated databases
-
-- Kubernetes gives us Deployments, StatefulSets, Services ...
-
-- These mechanisms give us building blocks to deploy applications
-
-- They work great for services that are made of *N* identical containers
-
-  (like stateless ones)
-
-- They also work great for some stateful applications like Consul, etcd ...
-
-  (with the help of highly persistent volumes)
-
-- They're not enough for complex services:
-
-  - where different containers have different roles
-
-  - where extra steps have to be taken when scaling or replacing containers
-
-.debug[[k8s/operators.md](""/tree/main/slides/k8s/operators.md)]
----
-
-## How operators work
-
-- An operator creates one or more CRDs
-
-  (i.e., it creates new "Kinds" of resources on our cluster)
-
-- The operator also runs a *controller* that will watch its resources
-
-- Each time we create/update/delete a resource, the controller is notified
-
-  (we could write our own cheap controller with `kubectl get --watch`)
-
-.debug[[k8s/operators.md](""/tree/main/slides/k8s/operators.md)]
----
-
-## Operators are not magic
-
-- Look at this ElasticSearch resource definition:
-
-  [k8s/eck-elasticsearch.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/eck-elasticsearch.yaml)
-
-- What should happen if we flip the TLS flag? Twice?
-
-- What should happen if we add another group of nodes?
-
-- What if we want different images or parameters for the different nodes?
-
-*Operators can be very powerful.
-<br/>
-But we need to know exactly the scenarios that they can handle.*
-
-???
-
-:EN:- Kubernetes operators
-:FR:- Les opérateurs
-
-.debug[[k8s/operators.md](""/tree/main/slides/k8s/operators.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-1.jpg)]
-
----
-
-name: toc-sealed-secrets
-class: title
-
- Sealed Secrets
-
-.nav[
-[Previous part](#toc-operators)
-|
-[Back to table of contents](#toc-part-5)
-|
-[Next part](#toc-custom-resource-definitions)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Sealed Secrets
-
-- Kubernetes provides the "Secret" resource to store credentials, keys, passwords ...
-
-- Secrets can be protected with RBAC
-
-  (e.g. "you can write secrets, but only the app's service account can read them")
-
-- [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) is an operator that lets us store secrets in code repositories
-
-- It uses asymetric cryptography:
-
-  - anyone can *encrypt* a secret
-
-  - only the cluster can *decrypt* a secret
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Principle
-
-- The Sealed Secrets operator uses a *public* and a *private* key
-
-- The public key is available publicly (duh!)
-
-- We use the public key to encrypt secrets into a SealedSecret resource
-
-- the SealedSecret resource can be stored in a code repo (even a public one)
-
-- The SealedSecret resource is `kubectl apply`'d to the cluster
-
-- The Sealed Secrets controller decrypts the SealedSecret with the private key
-
-  (this creates a classic Secret resource)
-
-- Nobody else can decrypt secrets, since only the controller has the private key
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## In action
-
-- We will install the Sealed Secrets operator
-
-- We will generate a Secret
-
-- We will "seal" that Secret (generate a SealedSecret)
-
-- We will load that SealedSecret on the cluster
-
-- We will check that we now have a Secret
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Installing the operator
-
-- The official installation is done through a single YAML file
-
-- There is also a Helm chart if you prefer that (see next slide!)
-
-<!-- #VERSION# -->
-
-.lab[
-
-- Install the operator:
-  .small[
-  ```bash
-    kubectl apply -f \
-            https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.17.5/controller.yaml
-  ```
-  ]
-
-]
-
-Note: it installs into `kube-system` by default.
-
-If you change that, you will also need to inform `kubeseal` later on.
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-class: extra-details
-
-## Installing with Helm
-
-- The Sealed Secrets controller can be installed like this:
-
-  ```bash
-    helm install --repo https://bitnami-labs.github.io/sealed-secrets/ \
-         sealed-secrets-controller sealed-secrets --namespace kube-system
-  ```
-
-- Make sure to install in the `kube-system` Namespace
-
-- Make sure that the release is named `sealed-secrets-controller`
-
-  (or pass a `--controller-name` option to `kubeseal` later)
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Creating a Secret
-
-- Let's create a normal (unencrypted) secret
-
-.lab[
-
-- Create a Secret with a couple of API tokens:
-  ```bash
-    kubectl create secret generic awskey \
-            --from-literal=AWS_ACCESS_KEY_ID=AKI... \
-            --from-literal=AWS_SECRET_ACCESS_KEY=abc123xyz... \
-            --dry-run=client -o yaml > secret-aws.yaml
-  ```
-
-]
-
-- Note the `--dry-run` and `-o yaml`
-
-  (we're just generating YAML, not sending the secrets to our Kubernetes cluster)
-
-- We could also write the YAML from scratch or generate it with other tools
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Creating a Sealed Secret
-
-- This is done with the `kubeseal` tool
-
-- It will obtain the public key from the cluster
-
-.lab[
-
-- Create the Sealed Secret:
-  ```bash
-    kubeseal < secret-aws.yaml > sealed-secret-aws.json
-  ```
-
-]
-
-- The file `sealed-secret-aws.json` can be committed to your public repo
-
-  (if you prefer YAML output, you can add `-o yaml`)
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Using a Sealed Secret
-
-- Now let's `kubectl apply` that Sealed Secret to the cluster
-
-- The Sealed Secret controller will "unseal" it for us
-
-.lab[
-
-- Check that our Secret doesn't exist (yet):
-  ```bash
-  kubectl get secrets
-  ```
-
-- Load the Sealed Secret into the cluster:
-  ```bash
-  kubectl create -f sealed-secret-aws.json
-  ```
-
-- Check that the secret is now available:
-  ```bash
-  kubectl get secrets
-  ```
-
-]
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Tweaking secrets
-
-- Let's see what happens if we try to rename the Secret
-
-  (or use it in a different namespace)
-
-.lab[
-
-- Delete both the Secret and the SealedSecret
-
-- Edit `sealed-secret-aws.json`
-
-- Change the name of the secret, or its namespace
-
-  (both in the SealedSecret metadata and in the Secret template)
-
-- `kubectl apply -f` the new JSON file and observe the results 🤔
-
-]
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Sealed Secrets are *scoped*
-
-- A SealedSecret cannot be renamed or moved to another namespace
-
-  (at least, not by default!)
-
-- Otherwise, it would allow to evade RBAC rules:
-
-  - if I can view Secrets in namespace `myapp` but not in namespace `yourapp`
-
-  - I could take a SealedSecret belonging to namespace `yourapp`
-
-  - ... and deploy it in `myapp`
-
-  - ... and view the resulting decrypted Secret!
-
-- This can be changed with `--scope namespace-wide` or `--scope cluster-wide`
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Working offline
-
-- We can obtain the public key from the server
-
-  (technically, as a PEM certificate)
-
-- Then we can use that public key offline
-
-  (without contacting the server)
-
-- Relevant commands:
-
-  `kubeseal --fetch-cert > seal.pem`
-
-  `kubeseal --cert seal.pem < secret.yaml > sealedsecret.json`
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Key rotation
-
-- The controller generate new keys every month by default
-
-- The keys are kept as TLS Secrets in the `kube-system` namespace
-
-  (named `sealed-secrets-keyXXXXX`)
-
-- When keys are "rotated", old decryption keys are kept
-
-  (otherwise we can't decrypt previously-generated SealedSecrets)
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Key compromise
-
-- If the *sealing* key (obtained with `--fetch-cert` is compromised):
-
-  *we don't need to do anything (it's a public key!)*
-
-- However, if the *unsealing* key (the TLS secret in `kube-system`) is compromised ...
-
-  *we need to:*
-
-  - rotate the key
-
-  - rotate the SealedSecrets that were encrypted with that key
-    <br/>
-    (as they are compromised)
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Rotating the key
-
-- By default, new keys are generated every 30 days
-
-- To force the generation of a new key "right now":
-
-  - obtain an RFC1123 timestamp with `date -R`
-
-  - edit Deployment `sealed-secrets-controller` (in `kube-system`)
-
-  - add `--key-cutoff-time=TIMESTAMP` to the command-line
-
-- *Then*, rotate the SealedSecrets that were encrypted with it
-
-  (generate new Secrets, then encrypt them with the new key)
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Discussion (the good)
-
-- The footprint of the operator is rather small:
-
-  - only one CRD
-
-  - one Deployment, one Service
-
-  - a few RBAC-related objects
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Discussion (the less good)
-
-- Events could be improved
-
-  - `no key to decrypt secret` when there is a name/namespace mismatch
-
-  - no event indicating that a SealedSecret was successfully unsealed
-
-- Key rotation could be improved (how to find secrets corresponding to a key?)
-
-- If the sealing keys are lost, it's impossible to unseal the SealedSecrets
-
-  (e.g. cluster reinstall)
-
-- ... Which means that we need to back up the sealing keys
-
-- ... Which means that we need to be super careful with these backups!
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-## Other approaches
-
-- [Kamus](https://kamus.soluto.io/) ([git](https://github.com/Soluto/kamus)) offers "zero-trust" secrets
-
-  (the cluster cannot decrypt secrets; only the application can decrypt them)
-
-- [Vault](https://learn.hashicorp.com/tutorials/vault/kubernetes-sidecar?in=vault/kubernetes) can do ... a lot
-
-  - dynamic secrets (generated on the fly for a consumer)
-
-  - certificate management
-
-  - integration outside of Kubernetes
-
-  - and much more!
-
-???
-
-:EN:- The Sealed Secrets Operator
-:FR:- L'opérateur *Sealed Secrets*
-
-.debug[[k8s/sealed-secrets.md](""/tree/main/slides/k8s/sealed-secrets.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-2.jpg)]
-
----
-
-name: toc-custom-resource-definitions
-class: title
-
- Custom Resource Definitions
-
-.nav[
-[Previous part](#toc-sealed-secrets)
-|
-[Back to table of contents](#toc-part-5)
-|
-[Next part](#toc-ingress-and-tls-certificates)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Custom Resource Definitions
-
-- CRDs are one of the (many) ways to extend the API
-
-- CRDs can be defined dynamically
-
-  (no need to recompile or reload the API server)
-
-- A CRD is defined with a CustomResourceDefinition resource
-
-  (CustomResourceDefinition is conceptually similar to a *metaclass*)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Creating a CRD
-
-- We will create a CRD to represent different recipes of pizzas
-
-- We will be able to run `kubectl get pizzas` and it will list the recipes
-
-- Creating/deleting recipes won't do anything else
-
-  (because we won't implement a *controller*)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## First slice of pizza
-
-```yaml
-apiVersion: apiextensions.k8s.io/v1beta1
-kind: CustomResourceDefinition
-metadata:
-  name: pizzas.container.training
-spec:
-  group: container.training
-  version: v1alpha1
-  scope: Namespaced
-  names:
-    plural: pizzas
-    singular: pizza
-    kind: Pizza
-    shortNames:
-    - piz
-
-```
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## The joys of API deprecation
-
-- Unfortunately, the CRD manifest on the previous slide is deprecated!
-
-- It is using `apiextensions.k8s.io/v1beta1`, which is dropped in Kubernetes 1.22
-
-- We need to use `apiextensions.k8s.io/v1`, which is a little bit more complex
-
-  (a few optional things become mandatory, see [this guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#customresourcedefinition-v122) for details)
-
-- `apiextensions.k8s.io/v1beta1` is available since Kubernetes 1.16
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Second slice of pizza
-
-- The next slide will show file [k8s/pizza-2.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/pizza-2.yaml)
-
-- Note the `spec.versions` list
-
-  - we need exactly one version with `storage: true`
-
-  - we can have multiple versions with `served: true`
-
-- `spec.versions[].schema.openAPI3Schema` is required
-
-  (and must be a valid OpenAPI schema; here it's a trivial one)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-```yaml
-apiVersion: apiextensions.k8s.io/v1
-kind: CustomResourceDefinition
-metadata:
-  name: pizzas.container.training
-spec:
-  group: container.training
-  scope: Namespaced
-  names:
-    plural: pizzas
-    singular: pizza
-    kind: Pizza
-    shortNames:
-    - piz
-  versions:
-  - name: v1alpha1
-    served: true
-    storage: true
-    schema:
-      openAPIV3Schema:
-        type: object
-
-```
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Baking some pizza
-
-- Let's create the Custom Resource Definition for our Pizza resource
-
-.lab[
-
-- Load the CRD:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/pizza-2.yaml
-  ```
-
-- Confirm that it shows up:
-  ```bash
-  kubectl get crds
-  ```
-
-]
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Creating custom resources
-
-The YAML below defines a resource using the CRD that we just created:
-
-```yaml
-kind: Pizza
-apiVersion: container.training/v1alpha1
-metadata:
-  name: napolitana
-spec:
-  toppings: [ mozzarella ]
-```
-
-.lab[
-
-- Try to create a few pizza recipes:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/pizzas.yaml
-  ```
-
-]
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Type validation
-
-- Older versions of Kubernetes will accept our pizza definition as is
-
-- Newer versions, however, will issue warnings about unknown fields
-
-  (and if we use `--validate=false`, these fields will simply be dropped)
-
-- We need to improve our OpenAPI schema
-
-  (to add e.g. the `spec.toppings` field used by our pizza resources)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Third slice of pizza
-
-- Let's add a full OpenAPI v3 schema to our Pizza CRD
-
-- We'll require a field `spec.sauce` which will be a string
-
-- And a field `spec.toppings` which will have to be a list of strings
-
-.lab[
-
-- Update our pizza CRD:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/pizza-3.yaml
-  ```
-
-- Load our pizza recipes:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/pizzas.yaml
-  ```
-
-]
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Viewing custom resources
-
-- By default, `kubectl get` only shows name and age of custom resources
-
-.lab[
-
-- View the pizza recipes that we just created:
-  ```bash
-  kubectl get pizzas
-  ```
-
-]
-
-- Let's see how we can improve that display!
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Additional printer columns
-
-- We can tell Kubernetes which columns to show:
-  ```yaml
-    additionalPrinterColumns:
-    - jsonPath: .spec.sauce
-      name: Sauce
-      type: string
-    - jsonPath: .spec.toppings
-      name: Toppings
-      type: string
-  ```
-
-- There is an updated CRD in [k8s/pizza-4.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/pizza-4.yaml)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Using additional printer columns
-
-- Let's update our CRD!
-
-.lab[
-
-- Update the CRD:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/pizza-4.yaml
-  ```
-
-- Look at our Pizza resources:
-  ```bash
-  kubectl get pizzas
-  ```
-
-]
-
-Note: we can update a CRD without having to re-create the corresponding resources.
-
-(Good news, right?)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Better data validation
-
-- Let's change the data schema so that the sauce can only be `red` or `white`
-
-- This will be implemented by [k8s/pizza-5.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/pizza-5.yaml)
-
-.lab[
-
-- Update the Pizza CRD:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/pizza-5.yaml
-  ```
-
-]
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Validation *a posteriori*
-
-- Some of the pizzas that we defined earlier *do not* pass validation
-
-- How is that possible?
-
---
-
-- Validation happens at *admission*
-
-  (when resources get written into the database)
-
-- Therefore, we can have "invalid" resources in etcd
-
-  (they are invalid from the CRD perspective, but the CRD can be changed)
-
-🤔 How should we handle that ?
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Versions
-
-- If the data format changes, we can roll out a new version of the CRD
-
-  (e.g. go from `v1alpha1` to `v1alpha2`)
-
-- In a CRD we can specify the versions that exist, that are *served*, and *stored*
-
-  - multiple versions can be *served*
-
-  - only one can be *stored*
-
-- Kubernetes doesn't automatically migrate the content of the database
-
-- However, it can convert between versions when resources are read/written
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Conversion
-
-- When *creating* a new resource, the *stored* version is used
-
-  (if we create it with another version, it gets converted)
-
-- When *getting* or *watching* resources, the *requested* version is used
-
-  (if it is stored with another version, it gets converted)
-
-- By default, "conversion" only changes the `apiVersion` field
-
-- ... But we can register *conversion webhooks*
-
-  (see [that doc page](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion) for details)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Migrating database content
-
-- We need to *serve* a version as long as we *store* objects in that version
-
-  (=as long as the database has at least one object with that version)
-
-- If we want to "retire" a version, we need to migrate these objects first
-
-- All we have to do is to read and re-write them
-
-  (the [kube-storage-version-migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator) tool can help)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## Even better data validation
-
-- If we need more complex data validation, we can use a validating webhook
-
-- Use cases:
-
-  - validating a "version" field for a database engine
-
-  - validating that the number of e.g. coordination nodes is even
-
-  - preventing inconsistent or dangerous changes
-    <br/>
-    (e.g. major version downgrades)
-
-  - checking a key or certificate format or validity
-
-  - and much more!
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## CRDs in the wild
-
-- [gitkube](https://storage.googleapis.com/gitkube/gitkube-setup-stable.yaml)
-
-- [A redis operator](https://github.com/amaizfinance/redis-operator/blob/master/deploy/crds/k8s_v1alpha1_redis_crd.yaml)
-
-- [cert-manager](https://github.com/jetstack/cert-manager/releases/download/v1.0.4/cert-manager.yaml)
-
-*How big are these YAML files?*
-
-*What's the size (e.g. in lines) of each resource?*
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## CRDs in practice
-
-- Production-grade CRDs can be extremely verbose
-
-  (because of the openAPI schema validation)
-
-- This can (and usually will) be managed by a framework
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## (Ab)using the API server
-
-- If we need to store something "safely" (as in: in etcd), we can use CRDs
-
-- This gives us primitives to read/write/list objects (and optionally validate them)
-
-- The Kubernetes API server can run on its own
-
-  (without the scheduler, controller manager, and kubelets)
-
-- By loading CRDs, we can have it manage totally different objects
-
-  (unrelated to containers, clusters, etc.)
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.md)]
----
-
-## What's next?
-
-- Creating a basic CRD is relatively straightforward
-
-- But CRDs generally require a *controller* to do anything useful
-
-- The controller will typically *watch* our custom resources
-
-  (and take action when they are created/updated)
-
-- Most serious use-cases will also require *validation web hooks*
-
-- When our CRD data format evolves, we'll also need *conversion web hooks*
-
-- Doing all that work manually is tedious; use a framework!
-
-???
-
-:EN:- Custom Resource Definitions (CRDs)
-:FR:- Les CRDs *(Custom Resource Definitions)*
-
-.debug[[k8s/crd.md](""/tree/main/slides/k8s/crd.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-ingress-and-tls-certificates
-class: title
-
- Ingress and TLS certificates
-
-.nav[
-[Previous part](#toc-custom-resource-definitions)
-|
-[Back to table of contents](#toc-part-6)
-|
-[Next part](#toc-cert-manager)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Ingress and TLS certificates
-
-- Most ingress controllers support TLS connections
-
-  (in a way that is standard across controllers)
-
-- The TLS key and certificate are stored in a Secret
-
-- The Secret is then referenced in the Ingress resource:
-  ```yaml
-    spec:
-      tls:
-      - secretName: XXX
-        hosts:
-        - YYY
-      rules:
-      - ZZZ
-  ```
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Obtaining a certificate
-
-- In the next section, we will need a TLS key and certificate
-
-- These usually come in [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) format:
-   ```
-   -----BEGIN CERTIFICATE-----
-   MIIDATCCAemg...
-   ...
-   -----END CERTIFICATE-----
-   ```
-
-- We will see how to generate a self-signed certificate
-
-  (easy, fast, but won't be recognized by web browsers)
-
-- We will also see how to obtain a certificate from [Let's Encrypt](https://letsencrypt.org/)
-
-  (requires the cluster to be reachable through a domain name)
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-class: extra-details
-
-## In production ...
-
-- A very popular option is to use the [cert-manager](https://cert-manager.io/docs/) operator
-
-- It's a flexible, modular approach to automated certificate management
-
-- For simplicity, in this section, we will use [certbot](https://certbot.eff.org/)
-
-- The method shown here works well for one-time certs, but lacks:
-
-  - automation
-
-  - renewal
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Which domain to use
-
-- If you're doing this in a training:
-
-  *the instructor will tell you what to use*
-
-- If you're doing this on your own Kubernetes cluster:
-
-  *you should use a domain that points to your cluster*
-
-- More precisely:
-
-  *you should use a domain that points to your ingress controller*
-
-- If you don't have a domain name, you can use [nip.io](https://nip.io/)
-
-  (if your ingress controller is on 1.2.3.4, you can use `whatever.1.2.3.4.nip.io`)
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Setting `$DOMAIN`
-
-- We will use `$DOMAIN` in the following section
-
-- Let's set it now
-
-.lab[
-
-- Set the `DOMAIN` environment variable:
-  ```bash
-  export DOMAIN=...
-  ```
-
-]
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Choose your adventure!
-
-- We present 3 methods to obtain a certificate
-
-- We suggest that we use method 1 (self-signed certificate)
-
-  - it's the simplest and fastest method
-
-  - it doesn't rely on other components
-
-- You're welcome to try methods 2 and 3 (leveraging certbot)
-
-  - they're great if you want to understand "how the sausage is made"
-
-  - they require some hacks (make sure port 80 is available)
-
-  - they won't be used in production (cert-manager is better)
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Method 1, self-signed certificate
-
-- Thanks to `openssl`, generating a self-signed cert is just one command away!
-
-.lab[
-
-- Generate a key and certificate:
-  ```bash
-    openssl req \
-      -newkey rsa -nodes -keyout privkey.pem \
-      -x509 -days 30 -subj /CN=$DOMAIN/ -out cert.pem
-  ```
-
-]
-
-This will create two files, `privkey.pem` and `cert.pem`.
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Method 2, Let's Encrypt with certbot
-
-- `certbot` is an [ACME](https://tools.ietf.org/html/rfc8555) client
-
-  (Automatic Certificate Management Environment)
-
-- We can use it to obtain certificates from Let's Encrypt
-
-- It needs to listen to port 80
-
-  (to complete the [HTTP-01 challenge](https://letsencrypt.org/docs/challenge-types/))
-
-- If port 80 is already taken by our ingress controller, see method 3
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-class: extra-details
-
-## HTTP-01 challenge
-
-- `certbot` contacts Let's Encrypt, asking for a cert for `$DOMAIN`
-
-- Let's Encrypt gives a token to `certbot`
-
-- Let's Encrypt then tries to access the following URL:
-
-  `http://$DOMAIN/.well-known/acme-challenge/<token>`
-
-- That URL needs to be routed to `certbot`
-
-- Once Let's Encrypt gets the response from `certbot`, it issues the certificate
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Running certbot
-
-- There is a very convenient container image, `certbot/certbot`
-
-- Let's use a volume to get easy access to the generated key and certificate
-
-.lab[
-
-- Obtain a certificate from Let's Encrypt:
-  ```bash
-    EMAIL=your.address@example.com
-    docker run --rm -p 80:80 -v $PWD/letsencrypt:/etc/letsencrypt \
-      certbot/certbot certonly \
-      -m $EMAIL \
-      --standalone --agree-tos -n \
-      --domain $DOMAIN \
-      --test-cert
-  ```
-
-]
-
-This will get us a "staging" certificate.
-Remove `--test-cert` to obtain a *real* certificate.
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Copying the key and certificate
-
-- If everything went fine:
-
-  - the key and certificate files are in `letsencrypt/live/$DOMAIN`
-
-  - they are owned by `root`
-
-.lab[
-
-- Grant ourselves permissions on these files:
-  ```bash
-  sudo chown -R $USER letsencrypt
-  ```
-
-- Copy the certificate and key to the current directory:
-  ```bash
-  cp letsencrypt/live/test/{cert,privkey}.pem .
-  ```
-
-]
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Method 3, certbot with Ingress
-
-- Sometimes, we can't simply listen to port 80:
-
-  - we might already have an ingress controller there
-  - our nodes might be on an internal network
-
-- But we can define an Ingress to route the HTTP-01 challenge to `certbot`!
-
-- Our Ingress needs to route all requests to `/.well-known/acme-challenge` to `certbot`
-
-- There are at least two ways to do that:
-
-  - run `certbot` in a Pod (and extract the cert+key when it's done)
-  - run `certbot` in a container on a node (and manually route traffic to it)
-
-- We're going to use the second option
-
-  (mostly because it will give us an excuse to tinker with Endpoints resources!)
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## The plan
-
-- We need the following resources:
-
-  - an Endpoints¹ listing a hard-coded IP address and port
-    <br/>(where our `certbot` container will be listening)
-
-  - a Service corresponding to that Endpoints
-
-  - an Ingress sending requests to `/.well-known/acme-challenge/*` to that Service
-    <br/>(we don't even need to include a domain name in it)
-
-- Then we need to start `certbot` so that it's listening on the right address+port
-
-.footnote[¹Endpoints is always plural, because even a single resource is a list of endpoints.]
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Creating resources
-
-- We prepared a YAML file to create the three resources
-
-- However, the Endpoints needs to be adapted to put the current node's address
-
-.lab[
-
-- Edit `~/containers.training/k8s/certbot.yaml`
-
-  (replace `A.B.C.D` with the current node's address)
-
-- Create the resources:
-  ```bash
-  kubectl apply -f ~/containers.training/k8s/certbot.yaml
-  ```
-
-]
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Obtaining the certificate
-
-- Now we can run `certbot`, listening on the port listed in the Endpoints
-
-  (i.e. 8000)
-
-.lab[
-
-- Run `certbot`:
-  ```bash
-    EMAIL=your.address@example.com
-    docker run --rm -p 8000:80 -v $PWD/letsencrypt:/etc/letsencrypt \
-      certbot/certbot certonly \
-      -m $EMAIL \
-      --standalone --agree-tos -n \
-      --domain $DOMAIN \
-      --test-cert
-  ```
-
-]
-
-This is using the staging environment.
-Remove `--test-cert` to get a production certificate.
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Copying the certificate
-
-- Just like in the previous method, the certificate is in `letsencrypt/live/$DOMAIN`
-
-  (and owned by root)
-
-.lab[
-
-- Grand ourselves permissions on these files:
-  ```bash
-  sudo chown -R $USER letsencrypt
-  ```
-
-- Copy the certificate and key to the current directory:
-  ```bash
-  cp letsencrypt/live/$DOMAIN/{cert,privkey}.pem .
-  ```
-
-]
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Creating the Secret
-
-- We now have two files:
-
-  - `privkey.pem` (the private key)
-
-  - `cert.pem` (the certificate)
-
-- We can create a Secret to hold them
-
-.lab[
-
-- Create the Secret:
-  ```bash
-  kubectl create secret tls $DOMAIN --cert=cert.pem --key=privkey.pem 
-  ```
-
-]
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Ingress with TLS
-
-- To enable TLS for an Ingress, we need to add a `tls` section to the Ingress:
-
-  ```yaml
-	spec:
-	  tls:
-	  - secretName: DOMAIN
-	    hosts:
-	    - DOMAIN
-	  rules: ...
-  ```
-
-- The list of hosts will be used by the ingress controller
-
-  (to know which certificate to use with [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication))
-
-- Of course, the name of the secret can be different
-
-  (here, for clarity and convenience, we set it to match the domain)
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## `kubectl create ingress`
-
-- We can also create an Ingress using TLS directly
-
-- To do it, add `,tls=secret-name` to an Ingress rule
-
-- Example:
-  ```bash
-  kubectl create ingress hello \
-          --rule=hello.example.com/*=hello:80,tls=hello
-  ```
-
-- The domain will automatically be inferred from the rule
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-class: extra-details
-
-## About the ingress controller
-
-- Many ingress controllers can use different "stores" for keys and certificates
-
-- Our ingress controller needs to be configured to use secrets
-
-  (as opposed to, e.g., obtain certificates directly with Let's Encrypt)
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Using the certificate
-
-.lab[
-
-- Add the `tls` section to an existing Ingress
-
-- If you need to see what the `tls` section should look like, you can:
-
-  - `kubectl explain ingress.spec.tls`
-
-  - `kubectl create ingress --dry-run=client -o yaml ...`
-
-  - check `~/container.training/k8s/ingress.yaml` for inspiration
-
-  - read the docs
-
-- Check that the URL now works over `https`
-
-  (it might take a minute to be picked up by the ingress controller)
-
-]
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Discussion
-
-*To repeat something mentioned earlier ...*
-
-- The methods presented here are for *educational purpose only*
-
-- In most production scenarios, the certificates will be obtained automatically
-
-- A very popular option is to use the [cert-manager](https://cert-manager.io/docs/) operator
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-
-## Security
-
-- Since TLS certificates are stored in Secrets...
-
-- ...It means that our Ingress controller must be able to read Secrets
-
-- A vulnerability in the Ingress controller can have dramatic consequences
-
-- See [CVE-2021-25742](https://github.com/kubernetes/ingress-nginx/issues/7837) for an example
-
-- This can be mitigated by limiting which Secrets the controller can access
-
-  (RBAC rules can specify resource names)
-
-- Downside: each TLS secret must explicitly be listed in RBAC
-
-  (but that's better than a full cluster compromise, isn't it?)
-
-???
-
-:EN:- Ingress and TLS
-:FR:- Certificats TLS et *ingress*
-
-.debug[[k8s/ingress-tls.md](""/tree/main/slides/k8s/ingress-tls.md)]
----
-## Optimizing request flow
-
-- With most ingress controllers, requests follow this path:
-
-  HTTP client → load balancer → NodePort → ingress controller Pod → app Pod
-
-- Sometimes, some of these components can be on the same machine
-
-  (e.g. ingress controller Pod and app Pod)
-
-- But they can also be on different machines
-
-  (each arrow = a potential hop)
-
-- This could add some unwanted latency!
-
-(See following diagrams)
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-class: pic
-
-![](images/kubernetes-services/61-ING.png)
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-class: pic
-
-![](images/kubernetes-services/62-ING-path.png)
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-## External traffic policy
-
-- The Service manifest has a field `spec.externalTrafficPolicy`
-
-- Possible values are:
-
-  - `Cluster` (default) - load balance connections to all pods
-
-  - `Local` - only send connections to local pods (on the same node)
-
-- When the policy is set to `Local`, we avoid one hop:
-
-  HTTP client → load balancer → NodePort .red[**→**] ingress controller Pod → app Pod
-
-(See diagram on next slide)
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-class: pic
-
-![](images/kubernetes-services/63-ING-policy.png)
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-## What if there is no Pod?
-
-- If a connection for a Service arrives on a Node through a NodePort...
-
-- ...And that Node doesn't host a Pod matching the selector of that Service...
-
-  (i.e. there is no local Pod)
-
-- ...Then the connection is refused
-
-- This can be detected from outside (by the external load balancer)
-
-- The external load balancer won't send connections to these nodes
-
-(See diagram on next slide)
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-class: pic
-
-![](images/kubernetes-services/64-ING-nolocal.png)
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-class: extra-details
-
-## Internal traffic policy
-
-- Since Kubernetes 1.21, there is also `spec.internalTrafficPolicy`
-
-- It works similarly but for internal traffic
-
-- It's an *alpha* feature
-
-  (not available by default; needs special steps to be enabled on the control plane)
-
-- See the [documentation] for more details
-
-[documentation]: https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-## Other ways to save hops
-
-- Run the ingress controller as a DaemonSet, using port 80 on the nodes:
-
-  HTTP client → load balancer → ingress controller on Node port 80 → app Pod
-
-- Then simplify further by setting a set of DNS records pointing to the nodes:
-
-  HTTP client → ingress controller on Node port 80 → app Pod 
-
-- Or run a combined load balancer / ingress controller at the edge of the cluster:
-
-  HTTP client → edge ingress controller → app Pod
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-## Source IP address
-
-- Obtaining the IP address of the HTTP client (from the app Pod) can be tricky!
-
-- We should consider (at least) two steps:
-
-  - obtaining the IP address of the HTTP client (from the ingress controller)
-
-  - passing that IP address from the ingress controller to the HTTP client
-
-- The second step is usually done by injecting an HTTP header
-
-  (typically `x-forwarded-for`)
-
-- Most ingress controllers do that out of the box
-
-- But how does the ingress controller obtain the IP address of the HTTP client? 🤔
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-## Scenario 1, direct connection
-
-- If the HTTP client connects directly to the ingress controller: easy!
-
-  - e.g. when running a combined load balancer / ingress controller
-
-  - or when running the ingress controller as a Daemon Set directly on port 80
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-## Scenario 2, external load balancer
-
-- Most external load balancers running in TCP mode don't expose client addresses
-
-  (HTTP client connects to load balancer; load balancer connects to ingress controller)
-
-- The ingress controller will "see" the IP address of the load balancer
-
-  (instead of the IP address of the client)
-
-- Many external load balancers support the [Proxy Protocol]
-
-- This enables the ingress controller to "see" the IP address of the HTTP client
-
-- It needs to be enabled on both ends (ingress controller and load balancer)
-
-[ProxyProtocol]: https://www.haproxy.com/blog/haproxy/proxy-protocol/
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-## Scenario 3, leveraging `externalTrafficPolicy`
-
-- In some cases, the external load balancer will preserve the HTTP client address
-
-- It is then possible to set `externalTrafficPolicy` to `Local`
-
-- The ingress controller will then "see" the HTTP client address
-
-- If `externalTrafficPolicy` is set to `Cluster`:
-
-  - sometimes the client address will be visible
-
-  - when bouncing the connection to another node, the address might be changed
-
-- This is a big "it depends!"
-
-- Bottom line: rely on the two other techniques instead?
-
-.debug[[k8s/ingress-advanced.md](""/tree/main/slides/k8s/ingress-advanced.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/wall-of-containers.jpeg)]
-
----
-
-name: toc-cert-manager
-class: title
-
- cert-manager
-
-.nav[
-[Previous part](#toc-ingress-and-tls-certificates)
-|
-[Back to table of contents](#toc-part-6)
-|
-[Next part](#toc-an-elasticsearch-operator)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# cert-manager
-
-- cert-manager¹ facilitates certificate signing through the Kubernetes API:
-
-  - we create a Certificate object (that's a CRD)
-
-  - cert-manager creates a private key
-
-  - it signs that key ...
-
-  - ... or interacts with a certificate authority to obtain the signature
-
-  - it stores the resulting key+cert in a Secret resource
-
-- These Secret resources can be used in many places (Ingress, mTLS, ...)
-
-.footnote[.red[¹]Always lower case, words separated with a dash; see the [style guide](https://cert-manager.io/docs/faq/style/_.)]
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## Getting signatures
-
-- cert-manager can use multiple *Issuers* (another CRD), including:
-
-  - self-signed
-
-  - cert-manager acting as a CA
-
-  - the [ACME protocol](https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment]) (notably used by Let's Encrypt)
-
-  - [HashiCorp Vault](https://www.vaultproject.io/)
-
-- Multiple issuers can be configured simultaneously
-
-- Issuers can be available in a single namespace, or in the whole cluster
-
-  (then we use the *ClusterIssuer* CRD)
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## cert-manager in action
-
-- We will install cert-manager
-
-- We will create a ClusterIssuer to obtain certificates with Let's Encrypt
-
-  (this will involve setting up an Ingress Controller)
-
-- We will create a Certificate request
-
-- cert-manager will honor that request and create a TLS Secret
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## Installing cert-manager
-
-- It can be installed with a YAML manifest, or with Helm
-
-.lab[
-
-- Let's install the cert-manager Helm chart with this one-liner:
-  ```bash
-    helm install cert-manager cert-manager \
-        --repo https://charts.jetstack.io \
-        --create-namespace --namespace cert-manager \
-        --set installCRDs=true
-  ```
-
-]
-
-- If you prefer to install with a single YAML file, that's fine too!
-
-  (see [the documentation](https://cert-manager.io/docs/installation/kubernetes/#installing-with-regular-manifests) for instructions)
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## ClusterIssuer manifest
-
-```yaml
-apiVersion: cert-manager.io/v1
-kind: ClusterIssuer
-metadata:
-  name: letsencrypt-staging
-spec:
-  acme:
-    # Remember to update this if you use this manifest to obtain real certificates :)
-    email: hello@example.com
-    server: https://acme-staging-v02.api.letsencrypt.org/directory
-    # To use the production environment, use the following line instead:
-    #server: https://acme-v02.api.letsencrypt.org/directory
-    privateKeySecretRef:
-      name: issuer-letsencrypt-staging
-    solvers:
-    - http01:
-        ingress:
-          class: traefik
-
-
-```
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## Creating the ClusterIssuer
-
-- The manifest shown on the previous slide is in [k8s/cm-clusterissuer.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/cm-clusterissuer.yaml)
-
-.lab[
-
-- Create the ClusterIssuer:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/cm-clusterissuer.yaml
-  ```
-
-]
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## Certificate manifest
-
-```yaml
-apiVersion: cert-manager.io/v1
-kind: Certificate
-metadata:
-  name: xyz.A.B.C.D.nip.io
-spec:
-  secretName: xyz.A.B.C.D.nip.io
-  dnsNames:
-  - xyz.A.B.C.D.nip.io
-  issuerRef:
-    name: letsencrypt-staging
-    kind: ClusterIssuer
-
-```
-
-- The `name`, `secretName`, and `dnsNames` don't have to match
-
-- There can be multiple `dnsNames`
-
-- The `issuerRef` must match the ClusterIssuer that we created earlier
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## Creating the Certificate
-
-- The manifest shown on the previous slide is in [k8s/cm-certificate.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/cm-certificate.yaml)
-
-.lab[
-
-- Edit the Certificate to update the domain name
-
-  (make sure to replace A.B.C.D with the IP address of one of your nodes!)
-
-- Create the Certificate:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/cm-certificate.yaml
-  ```
-
-]
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## What's happening?
-
-- cert-manager will create:
-
-  - the secret key
-
-  - a Pod, a Service, and an Ingress to complete the HTTP challenge
-
-- then it waits for the challenge to complete
-
-.lab[
-
-- View the resources created by cert-manager:
-  ```bash
-    kubectl get pods,services,ingresses \
-            --selector=acme.cert-manager.io/http01-solver=true
-  ```
-
-]
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## HTTP challenge
-
-- The CA (in this case, Let's Encrypt) will fetch a particular URL:
-
-  `http://<our-domain>/.well-known/acme-challenge/<token>`
-
-.lab[
-
-- Check the *path* of the Ingress in particular:
-  ```bash
-    kubectl describe ingress 
-            --selector=acme.cert-manager.io/http01-solver=true
-  ```
-
-]
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-## What's missing ?
-
---
-
-An Ingress Controller! 😅
-
-.lab[
-
-- Install an Ingress Controller:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/traefik-v2.yaml
-  ```
-
-- Wait a little bit, and check that we now have a `kubernetes.io/tls` Secret:
-  ```bash
-  kubectl get secrets
-  ```
-
-]
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-class: extra-details
-
-## Using the secret
-
-- For bonus points, try to use the secret in an Ingress!
-
-- This is what the manifest would look like:
-
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: Ingress
-metadata:
-  name: xyz
-spec:
-  tls:
-  - secretName: xyz.A.B.C.D.nip.io
-    hosts:
-    - xyz.A.B.C.D.nip.io
-  rules:
-  ...
-```
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-class: extra-details
-
-## Automatic TLS Ingress with annotations
-
-- It is also possible to annotate Ingress resources for cert-manager
-
-- If we annotate an Ingress resource with `cert-manager.io/cluster-issuer=xxx`:
-
-  - cert-manager will detect that annotation
-
-  - it will obtain a certificate using the specified ClusterIssuer (`xxx`)
-
-  - it will store the key and certificate in the specified Secret
-
-- Note: the Ingress still needs the `tls` section with `secretName` and `hosts`
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-
-class: extra-details
-
-## Let's Encrypt and nip.io
-
-- Let's Encrypt has [rate limits](https://letsencrypt.org/docs/rate-limits/) per domain
-
-  (the limits only apply to the production environment, not staging)
-
-- There is a limit of 50 certificates per registered domain
-
-- If we try to use the production environment, we will probably hit the limit
-
-- It's fine to use the staging environment for these experiments
-
-  (our certs won't validate in a browser, but we can always check
-  the details of the cert to verify that it was issued by Let's Encrypt!)
-
-???
-
-:EN:- Obtaining certificates with cert-manager
-:FR:- Obtenir des certificats avec cert-manager
-
-:T: Obtaining TLS certificates with cert-manager
-
-.debug[[k8s/cert-manager.md](""/tree/main/slides/k8s/cert-manager.md)]
----
-## CA injector - overview
-
-- The Kubernetes API server can invoke various webhooks:
-
-  - conversion webhooks (registered in CustomResourceDefinitions)
-
-  - mutation webhooks (registered in MutatingWebhookConfigurations)
-
-  - validation webhooks (registered in ValidatingWebhookConfiguration)
-
-- These webhooks must be served over TLS
-
-- These webhooks must use valid TLS certificates
-
-.debug[[k8s/cainjector.md](""/tree/main/slides/k8s/cainjector.md)]
----
-
-## Webhook certificates
-
-- Option 1: certificate issued by a global CA
-
-  - doesn't work with internal services
-    <br/>
-    (their CN must be `<servicename>.<namespace>.svc`)
-
-- Option 2: certificate issued by private CA + CA certificate in system store
-
-  - requires access to API server certificates tore
-
-  - generally not doable on managed Kubernetes clusters
-
-- Option 3: certificate issued by private CA + CA certificate in `caBundle`
-
-  - pass the CA certificate in `caBundle` field
-    <br/>
-    (in CRD or webhook manifests)
-
-  - can be managed automatically by cert-manager
-
-.debug[[k8s/cainjector.md](""/tree/main/slides/k8s/cainjector.md)]
----
-
-## CA injector - details
-
-- Add annotation to *injectable* resource
-  (CustomResouceDefinition, MutatingWebhookConfiguration, ValidatingWebhookConfiguration)
-
-- Annotation refers to the thing holding the certificate:
-
-  - `cert-manager.io/inject-ca-from: <namespace>/<certificate>`
-
-  - `cert-manager.io/inject-ca-from-secret: <namespace>/<secret>`
-
-  - `cert-manager.io/inject-apiserver-ca: true` (use API server CA)
-
-- When injecting from a Secret, the Secret must have a special annotation:
-
-  `cert-manager.io/allow-direct-injection: "true"`
-
-- See [cert-manager documentation][docs] for details
-
-[docs]: https://cert-manager.io/docs/concepts/ca-injector/
-
-.debug[[k8s/cainjector.md](""/tree/main/slides/k8s/cainjector.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/catene-de-conteneurs.jpg)]
-
----
-
-name: toc-an-elasticsearch-operator
-class: title
-
- An ElasticSearch Operator
-
-.nav[
-[Previous part](#toc-cert-manager)
-|
-[Back to table of contents](#toc-part-6)
-|
-[Next part](#toc-dynamic-admission-control)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# An ElasticSearch Operator
-
-- We will install [Elastic Cloud on Kubernetes](https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-quickstart.html), an ElasticSearch operator
-
-- This operator requires PersistentVolumes
-
-- We will install Rancher's [local path storage provisioner](https://github.com/rancher/local-path-provisioner) to automatically create these
-
-- Then, we will create an ElasticSearch resource
-
-- The operator will detect that resource and provision the cluster
-
-- We will integrate that ElasticSearch cluster with other resources
-
-  (Kibana, Filebeat, Cerebro ...)
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Installing a Persistent Volume provisioner
-
-(This step can be skipped if you already have a dynamic volume provisioner.)
-
-- This provisioner creates Persistent Volumes backed by `hostPath`
-
-  (local directories on our nodes)
-
-- It doesn't require anything special ...
-
-- ... But losing a node = losing the volumes on that node!
-
-.lab[
-
-- Install the local path storage provisioner:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/local-path-storage.yaml
-  ```
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Making sure we have a default StorageClass
-
-- The ElasticSearch operator will create StatefulSets
-
-- These StatefulSets will instantiate PersistentVolumeClaims
-
-- These PVCs need to be explicitly associated with a StorageClass
-
-- Or we need to tag a StorageClass to be used as the default one
-
-.lab[
-
-- List StorageClasses:
-  ```bash
-  kubectl get storageclasses
-  ```
-
-]
-
-We should see the `local-path` StorageClass.
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Setting a default StorageClass
-
-- This is done by adding an annotation to the StorageClass:
-
-  `storageclass.kubernetes.io/is-default-class: true`
-
-.lab[
-
-- Tag the StorageClass so that it's the default one:
-  ```bash
-  kubectl annotate storageclass local-path \
-            storageclass.kubernetes.io/is-default-class=true
-  ```
-
-- Check the result:
-  ```bash
-  kubectl get storageclasses
-  ```
-
-]
-
-Now, the StorageClass should have `(default)` next to its name.
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Install the ElasticSearch operator
-
-- The operator provides:
-
-  - a few CustomResourceDefinitions
-  - a Namespace for its other resources
-  - a ValidatingWebhookConfiguration for type checking
-  - a StatefulSet for its controller and webhook code
-  - a ServiceAccount, ClusterRole, ClusterRoleBinding for permissions
-
-- All these resources are grouped in a convenient YAML file
-
-.lab[
-
-- Install the operator:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/eck-operator.yaml
-  ```
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Check our new custom resources
-
-- Let's see which CRDs were created
-
-.lab[
-
-- List all CRDs:
-  ```bash
-  kubectl get crds
-  ```
-
-]
-
-This operator supports ElasticSearch, but also Kibana and APM. Cool!
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Create the `eck-demo` namespace
-
-- For clarity, we will create everything in a new namespace, `eck-demo`
-
-- This namespace is hard-coded in the YAML files that we are going to use
-
-- We need to create that namespace
-
-.lab[
-
-- Create the `eck-demo` namespace:
-  ```bash
-  kubectl create namespace eck-demo
-  ```
-
-- Switch to that namespace:
-  ```bash
-  kns eck-demo
-  ```
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-class: extra-details
-
-## Can we use a different namespace?
-
-Yes, but then we need to update all the YAML manifests that we
-are going to apply in the next slides.
-
-The `eck-demo` namespace is hard-coded in these YAML manifests.
-
-Why?
-
-Because when defining a ClusterRoleBinding that references a
-ServiceAccount, we have to indicate in which namespace the
-ServiceAccount is located.
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Create an ElasticSearch resource
-
-- We can now create a resource with `kind: ElasticSearch`
-
-- The YAML for that resource will specify all the desired parameters:
-
-  - how many nodes we want
-  - image to use
-  - add-ons (kibana, cerebro, ...)
-  - whether to use TLS or not
-  - etc.
-
-.lab[
-
-- Create our ElasticSearch cluster:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/eck-elasticsearch.yaml
-  ```
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Operator in action
-
-- Over the next minutes, the operator will create our ES cluster
-
-- It will report our cluster status through the CRD
-
-.lab[
-
-- Check the logs of the operator:
-  ```bash
-  stern --namespace=elastic-system operator
-  ```
-
-<!--
-```wait elastic-operator-0```
-```tmux split-pane -v```
---->
-
-- Watch the status of the cluster through the CRD:
-  ```bash
-  kubectl get es -w
-  ```
-
-<!--
-```longwait green```
-```key ^C```
-```key ^D```
-```key ^C```
--->
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Connecting to our cluster
-
-- It's not easy to use the ElasticSearch API from the shell
-
-- But let's check at least if ElasticSearch is up!
-
-.lab[
-
-- Get the ClusterIP of our ES instance:
-  ```bash
-  kubectl get services
-  ```
-
-- Issue a request with `curl`:
-  ```bash
-  curl http://`CLUSTERIP`:9200
-  ```
-
-]
-
-We get an authentication error. Our cluster is protected!
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Obtaining the credentials
-
-- The operator creates a user named `elastic`
-
-- It generates a random password and stores it in a Secret
-
-.lab[
-
-- Extract the password:
-  ```bash
-    kubectl get secret demo-es-elastic-user \
-            -o go-template="{{ .data.elastic | base64decode }} "
-  ```
-
-- Use it to connect to the API:
-  ```bash
-  curl -u elastic:`PASSWORD` http://`CLUSTERIP`:9200
-  ```
-
-]
-
-We should see a JSON payload with the `"You Know, for Search"` tagline.
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Sending data to the cluster
-
-- Let's send some data to our brand new ElasticSearch cluster!
-
-- We'll deploy a filebeat DaemonSet to collect node logs
-
-.lab[
-
-- Deploy filebeat:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/eck-filebeat.yaml
-  ```
-
-- Wait until some pods are up:
-  ```bash
-  watch kubectl get pods -l k8s-app=filebeat
-  ```
-
-<!--
-```wait Running```
-```key ^C```
--->
-
-- Check that a filebeat index was created:
-  ```bash
-  curl -u elastic:`PASSWORD` http://`CLUSTERIP`:9200/_cat/indices
-  ```
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Deploying an instance of Kibana
-
-- Kibana can visualize the logs injected by filebeat
-
-- The ECK operator can also manage Kibana
-
-- Let's give it a try!
-
-.lab[
-
-- Deploy a Kibana instance:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/eck-kibana.yaml
-  ```
-
-- Wait for it to be ready:
-  ```bash
-  kubectl get kibana -w
-  ```
-
-<!--
-```longwait green```
-```key ^C```
--->
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Connecting to Kibana
-
-- Kibana is automatically set up to conect to ElasticSearch
-
-  (this is arranged by the YAML that we're using)
-
-- However, it will ask for authentication
-
-- It's using the same user/password as ElasticSearch
-
-.lab[
-
-- Get the NodePort allocated to Kibana:
-  ```bash
-  kubectl get services
-  ```
-
-- Connect to it with a web browser
-
-- Use the same user/password as before
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Setting up Kibana
-
-After the Kibana UI loads, we need to click around a bit
-
-.lab[
-
-- Pick "explore on my own"
-
-- Click on Use Elasticsearch data / Connect to your Elasticsearch index"
-
-- Enter `filebeat-*` for the index pattern and click "Next step"
-
-- Select `@timestamp` as time filter field name
-
-- Click on "discover" (the small icon looking like a compass on the left bar)
-
-- Play around!
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Scaling up the cluster
-
-- At this point, we have only one node
-
-- We are going to scale up
-
-- But first, we'll deploy Cerebro, an UI for ElasticSearch
-
-- This will let us see the state of the cluster, how indexes are sharded, etc.
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Deploying Cerebro
-
-- Cerebro is stateless, so it's fairly easy to deploy
-
-  (one Deployment + one Service)
-
-- However, it needs the address and credentials for ElasticSearch
-
-- We prepared yet another manifest for that!
-
-.lab[
-
-- Deploy Cerebro:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/eck-cerebro.yaml
-  ```
-
-- Lookup the NodePort number and connect to it:
-  ```bash
-  kubectl get services
-  ```
-
-]
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.md)]
----
-
-## Scaling up the cluster
-
-- We can see on Cerebro that the cluster is "yellow"
-
-  (because our index is not replicated)
-
-- Let's change that!
-
-.lab[
-
-- Edit the ElasticSearch cluster manifest:
-  ```bash
-  kubectl edit es demo
-  ```
-
-- Find the field `count: 1` and change it to 3
-
-- Save and quit
-
-<!--
-```wait Please edit```
-```keys /count:```
-```key ^J```
-```keys $r3:x```
-```key ^J```
--->
-
-]
-
-???
-
-:EN:- Deploying ElasticSearch with ECK
-:FR:- Déployer ElasticSearch avec ECK
-
-.debug[[k8s/eck.md](""/tree/main/slides/k8s/eck.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-dynamic-admission-control
-class: title
-
- Dynamic Admission Control
-
-.nav[
-[Previous part](#toc-an-elasticsearch-operator)
-|
-[Back to table of contents](#toc-part-7)
-|
-[Next part](#toc-policy-management-with-kyverno)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Dynamic Admission Control
-
-- This is one of the many ways to extend the Kubernetes API
-
-- High level summary: dynamic admission control relies on webhooks that are ...
-
-  - dynamic (can be added/removed on the fly)
-
-  - running inside our outside the cluster
-
-  - *validating* (yay/nay) or *mutating* (can change objects that are created/updated)
-
-  - selective (can be configured to apply only to some kinds, some selectors...)
-
-  - mandatory or optional (should it block operations when webhook is down?)
-
-- Used for themselves (e.g. policy enforcement) or as part of operators
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Use cases
-
-Some examples ...
-
-- Stand-alone admission controllers
-
-  *validating:* policy enforcement (e.g. quotas, naming conventions ...)
-
-  *mutating:* inject or provide default values (e.g. pod presets)
-
-- Admission controllers part of a greater system
-
-  *validating:* advanced typing for operators
-
-  *mutating:* inject sidecars for service meshes
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## You said *dynamic?*
-
-- Some admission controllers are built in the API server
-
-- They are enabled/disabled through Kubernetes API server configuration
-
-  (e.g. `--enable-admission-plugins`/`--disable-admission-plugins` flags)
-
-- Here, we're talking about *dynamic* admission controllers
-
-- They can be added/remove while the API server is running
-
-  (without touching the configuration files or even having access to them)
-
-- This is done through two kinds of cluster-scope resources:
-
-  ValidatingWebhookConfiguration and MutatingWebhookConfiguration
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## You said *webhooks?*
-
-- A ValidatingWebhookConfiguration or MutatingWebhookConfiguration contains:
-
-  - a resource filter
-    <br/>
-    (e.g. "all pods", "deployments in namespace xyz", "everything"...)
-
-  - an operations filter
-    <br/>
-    (e.g. CREATE, UPDATE, DELETE)
-
-  - the address of the webhook server
-
-- Each time an operation matches the filters, it is sent to the webhook server
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## What gets sent exactly?
-
-- The API server will `POST` a JSON object to the webhook
-
-- That object will be a Kubernetes API message with `kind` `AdmissionReview`
-
-- It will contain a `request` field, with, notably:
-
-  - `request.uid` (to be used when replying)
-
-  - `request.object` (the object created/deleted/changed)
-
-  - `request.oldObject` (when an object is modified)
-
-  - `request.userInfo` (who was making the request to the API in the first place)
-
-(See [the documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#request) for a detailed example showing more fields.)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## How should the webhook respond?
-
-- By replying with another `AdmissionReview` in JSON
-
-- It should have a `response` field, with, notably:
-
-  - `response.uid` (matching the `request.uid`)
-
-  - `response.allowed` (`true`/`false`)
-
-  - `response.status.message` (optional string; useful when denying requests)
-
-  - `response.patchType` (when a mutating webhook changes the object; e.g. `json`)
-
-  - `response.patch` (the patch, encoded in base64)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## What if the webhook *does not* respond?
-
-- If "something bad" happens, the API server follows the `failurePolicy` option
-
-  - this is a per-webhook option (specified in the webhook configuration)
-
-  - it can be `Fail` (the default) or `Ignore` ("allow all, unmodified")
-
-- What's "something bad"?
-
-  - webhook responds with something invalid
-
-  - webhook takes more than 10 seconds to respond
-    <br/>
-    (this can be changed with `timeoutSeconds` field in the webhook config)
-
-  - webhook is down or has invalid certificates
-    <br/>
-    (TLS! It's not just a good idea; for admission control, it's the law!)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## What did you say about TLS?
-
-- The webhook configuration can indicate:
-
-  - either `url` of the webhook server (has to begin with `https://`)
-
-  - or `service.name` and `service.namespace` of a Service on the cluster
-
-- In the latter case, the Service has to accept TLS connections on port 443
-
-- It has to use a certificate with CN `<name>.<namespace>.svc`
-
-  (**and** a `subjectAltName` extension with `DNS:<name>.<namespace>.svc`)
-
-- The certificate needs to be valid (signed by a CA trusted by the API server)
-
-  ... alternatively, we can pass a `caBundle` in the webhook configuration
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Webhook server inside or outside
-
-- "Outside" webhook server is defined with `url` option
-
-  - convenient for external webooks (e.g. tamper-resistent audit trail)
-
-  - also great for initial development (e.g. with ngrok)
-
-  - requires outbound connectivity (duh) and can become a SPOF
-
-- "Inside" webhook server is defined with `service` option
-
-  - convenient when the webhook needs to be deployed and managed on the cluster
-
-  - also great for air gapped clusters
-
-  - development can be harder (but tools like [Tilt](https://tilt.dev) can help)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Developing a simple admission webhook
-
-- We're going to register a custom webhook!
-
-- First, we'll just dump the `AdmissionRequest` object
-
-  (using a little Node app)
-
-- Then, we'll implement a strict policy on a specific label
-
-  (using a little Flask app)
-
-- Development will happen in local containers, plumbed with ngrok
-
-- The we will deploy to the cluster 🔥
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Running the webhook locally
-
-- We prepared a Docker Compose file to start the whole stack
-
-  (the Node "echo" app, the Flask app, and one ngrok tunnel for each of them)
-
-.lab[
-
-- Go to the webhook directory:
-  ```bash
-  cd ~/container.training/webhooks/admission
-  ```
-
-- Start the webhook in Docker containers:
-  ```bash
-  docker-compose up
-  ```
-
-]
-
-*Note the URL in `ngrok-echo_1` looking like `url=https://xxxx.ngrok.io`.*
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-class: extra-details
-
-## What's ngrok?
-
-- Ngrok provides secure tunnels to access local services
-
-- Example: run `ngrok http 1234`
-
-- `ngrok` will display a publicly-available URL (e.g. https://xxxxyyyyzzzz.ngrok.io)
-
-- Connections to https://xxxxyyyyzzzz.ngrok.io will terminate at `localhost:1234`
-
-- Basic product is free; extra features (vanity domains, end-to-end TLS...) for $$$
-
-- Perfect to develop our webhook!
-
-- Probably not for production, though
-
-  (webhook requests and responses now pass through the ngrok platform)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Update the webhook configuration
-
-- We have a webhook configuration in `k8s/webhook-configuration.yaml`
-
-- We need to update the configuration with the correct `url`
-
-.lab[
-
-- Edit the webhook configuration manifest:
-  ```bash
-  vim k8s/webhook-configuration.yaml
-  ```
-
-- **Uncomment** the `url:` line
-
-- **Update** the `.ngrok.io` URL with the URL shown by Compose
-
-- Save and quit
-
-]
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Register the webhook configuration
-
-- Just after we register the webhook, it will be called for each matching request
-
-  (CREATE and UPDATE on Pods in all namespaces)
-
-- The `failurePolicy` is `Ignore`
-
-  (so if the webhook server is down, we can still create pods)
-
-.lab[
-
-- Register the webhook:
-  ```bash
-  kubectl apply -f k8s/webhook-configuration.yaml
-  ```
-
-]
-
-It is strongly recommended to tail the logs of the API server while doing that.
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Create a pod
-
-- Let's create a pod and try to set a `color` label
-
-.lab[
-
-- Create a pod named `chroma`:
-  ```bash
-  kubectl run --restart=Never chroma --image=nginx
-  ```
-
-- Add a label `color` set to `pink`:
-  ```bash
-  kubectl label pod chroma color=pink
-  ```
-
-]
-
-We should see the `AdmissionReview` objects in the Compose logs.
-
-Note: the webhook doesn't do anything (other than printing the request payload).
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Use the "real" admission webhook
-
-- We have a small Flask app implementing a particular policy on pod labels:
-
-  - if a pod sets a label `color`, it must be `blue`, `green`, `red`
-
-  - once that `color` label is set, it cannot be removed or changed
-
-- That Flask app was started when we did `docker-compose up` earlier
-
-- It is exposed through its own ngrok tunnel
-
-- We are going to use that webhook instead of the other one
-
-  (by changing only the `url` field in the ValidatingWebhookConfiguration)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Update the webhook configuration
-
-.lab[
-
-- First, check the ngrok URL of the tunnel for the Flask app:
-  ```bash
-  docker-compose logs ngrok-flask
-  ```
-
-- Then, edit the webhook configuration:
-  ```bash
-  kubectl edit validatingwebhookconfiguration admission.container.training
-  ```
-- Find the `url:` field with the `.ngrok.io` URL and update it
-
-- Save and quit; the new configuration is applied immediately
-
-]
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Verify the behavior of the webhook
-
-- Try to create a few pods and/or change labels on existing pods
-
-- What happens if we try to make changes to the earlier pod?
-
-  (the one that has `label=pink`)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Deploying the webhook on the cluster
-
-- Let's see what's needed to self-host the webhook server!
-
-- The webhook needs to be reachable through a Service on our cluster
-
-- The Service needs to accept TLS connections on port 443
-
-- We need a proper TLS certificate:
-
-  - with the right `CN` and `subjectAltName` (`<servicename>.<namespace>.svc`)
-
-  - signed by a trusted CA
-
-- We can either use a "real" CA, or use the `caBundle` option to specify the CA cert
-
-  (the latter makes it easy to use self-signed certs)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## In practice
-
-- We're going to generate a key pair and a self-signed certificate
-
-- We will store them in a Secret
-
-- We will run the webhook in a Deployment, exposed with a Service
-
-- We will update the webhook configuration to use that Service
-
-- The Service will be named `admission`, in Namespace `webhooks`
-
-  (keep in mind that the ValidatingWebhookConfiguration itself is at cluster scope)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Let's get to work!
-
-.lab[
-
-- Make sure we're in the right directory:
-  ```bash
-  cd ~/container.training/webhooks/admission
-  ```
-
-- Create the namespace:
-  ```bash
-  kubectl create namespace webhooks
-  ```
-
-- Switch to the namespace:
-  ```bash
-  kubectl config set-context --current --namespace=webhooks
-  ```
-
-]
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Deploying the webhook
-
-- *Normally,* we would author an image for this
-
-- Since our webhook is just *one* Python source file ...
-
-  ... we'll store it in a ConfigMap, and install dependencies on the fly
-
-.lab[
-
-- Load the webhook source in a ConfigMap:
-  ```bash
-  kubectl create configmap admission --from-file=flask/webhook.py
-  ```
-
-- Create the Deployment and Service:
-  ```bash
-  kubectl apply -f k8s/webhook-server.yaml
-  ```
-
-]
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Generating the key pair and certificate
-
-- Let's call OpenSSL to the rescue!
-
-  (of course, there are plenty others options; e.g. `cfssl`)
-
-.lab[
-
-- Generate a self-signed certificate:
-  ```bash
-    NAMESPACE=webhooks
-    SERVICE=admission
-    CN=$SERVICE.$NAMESPACE.svc
-    openssl req -x509 -newkey rsa:4096 -nodes -keyout key.pem -out cert.pem \
-        -days 30 -subj /CN=$CN -addext subjectAltName=DNS:$CN
-  ```
-
-- Load up the key and cert in a Secret:
-  ```bash
-  kubectl create secret tls admission --cert=cert.pem --key=key.pem
-  ```
-
-]
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Update the webhook configuration
-
-- Let's reconfigure the webhook to use our Service instead of ngrok
-
-.lab[
-
-- Edit the webhook configuration manifest:
-  ```bash
-  vim k8s/webhook-configuration.yaml
-  ```
-
-- Comment out the `url:` line
-
-- Uncomment the `service:` section
-
-- Save, quit
-
-- Update the webhook configuration:
-  ```bash
-  kubectl apply -f k8s/webhook-configuration.yaml
-  ```
-
-]
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Add our self-signed cert to the `caBundle`
-
-- The API server won't accept our self-signed certificate
-
-- We need to add it to the `caBundle` field in the webhook configuration
-
-- The `caBundle` will be our `cert.pem` file, encoded in base64
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-Shell to the rescue!
-
-.lab[
-
-- Load up our cert and encode it in base64:
-  ```bash
-  CA=$(base64 -w0 < cert.pem)
-  ```
-
-- Define a patch operation to update the `caBundle`:
-  ```bash
-    PATCH='[{
-        "op": "replace",
-        "path": "/webhooks/0/clientConfig/caBundle",
-        "value":"'$CA'"
-    }]'
-  ```
-
-- Patch the webhook configuration:
-  ```bash
-    kubectl patch validatingwebhookconfiguration \
-                  admission.webhook.container.training \
-                  --type='json' -p="$PATCH"
-  ```
-
-]
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-## Try it out!
-
-- Keep an eye on the API server logs
-
-- Tail the logs of the pod running the webhook server
-
-- Create a few pods; we should see requests in the webhook server logs
-
-- Check that the label `color` is enforced correctly
-
-  (it should only allow values of `red`, `green`, `blue`)
-
-???
-
-:EN:- Dynamic admission control with webhooks
-:FR:- Contrôle d'admission dynamique (webhooks)
-
-.debug[[k8s/admission.md](""/tree/main/slides/k8s/admission.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]
-
----
-
-name: toc-policy-management-with-kyverno
-class: title
-
- Policy Management with Kyverno
-
-.nav[
-[Previous part](#toc-dynamic-admission-control)
-|
-[Back to table of contents](#toc-part-7)
-|
-[Next part](#toc-the-aggregation-layer)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Policy Management with Kyverno
-
-- The Kubernetes permission management system is very flexible ...
-
-- ... But it can't express *everything!*
-
-- Examples:
-
-  - forbid using `:latest` image tag
-
-  - enforce that each Deployment, Service, etc. has an `owner` label
-    <br/>(except in e.g. `kube-system`)
-
-  - enforce that each container has at least a `readinessProbe` healthcheck
-
-- How can we address that, and express these more complex *policies?*
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Admission control
-
-- The Kubernetes API server provides a generic mechanism called *admission control*
-
-- Admission controllers will examine each write request, and can:
-
-  - approve/deny it (for *validating* admission controllers)
-
-  - additionally *update* the object (for *mutating* admission controllers)
-
-- These admission controllers can be:
-
-  - plug-ins built into the Kubernetes API server
-    <br/>(selectively enabled/disabled by e.g. command-line flags)
-
-  - webhooks registered dynamically with the Kubernetes API server
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## What's Kyverno?
-
-- Policy management solution for Kubernetes
-
-- Open source (https://github.com/kyverno/kyverno/)
-
-- Compatible with all clusters
-
-  (doesn't require to reconfigure the control plane, enable feature gates...)
-
-- We don't endorse / support it in a particular way, but we think it's cool
-
-- It's not the only solution!
-
-  (see e.g. [Open Policy Agent](https://www.openpolicyagent.org/docs/v0.12.2/kubernetes-admission-control/))
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## What can Kyverno do?
-
-- *Validate* resource manifests
-
-  (accept/deny depending on whether they conform to our policies)
-
-- *Mutate* resources when they get created or updated
-
-  (to add/remove/change fields on the fly)
-
-- *Generate* additional resources when a resource gets created
-
-  (e.g. when namespace is created, automatically add quotas and limits)
-
-- *Audit* existing resources
-
-  (warn about resources that violate certain policies)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## How does it do it?
-
-- Kyverno is implemented as a *controller* or *operator*
-
-- It typically runs as a Deployment on our cluster
-
-- Policies are defined as *custom resource definitions*
-
-- They are implemented with a set of *dynamic admission control webhooks*
-
---
-
-🤔
-
---
-
-- Let's unpack that!
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Custom resource definitions
-
-- When we install Kyverno, it will register new resource types:
-
-  - Policy and ClusterPolicy (per-namespace and cluster-scope policies)
-
-  - PolicyReport and ClusterPolicyReport (used in audit mode)
-
-  - GenerateRequest (used internally when generating resources asynchronously)
-
-- We will be able to do e.g. `kubectl get clusterpolicyreports --all-namespaces`
-
-  (to see policy violations across all namespaces)
-
-- Policies will be defined in YAML and registered/updated with e.g. `kubectl apply`
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Dynamic admission control webhooks
-
-- When we install Kyverno, it will register a few webhooks for its use
-
-  (by creating ValidatingWebhookConfiguration and MutatingWebhookConfiguration resources)
-
-- All subsequent resource modifications are submitted to these webhooks
-
-  (creations, updates, deletions)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Controller
-
-- When we install Kyverno, it creates a Deployment (and therefore, a Pod)
-
-- That Pod runs the server used by the webhooks
-
-- It also runs a controller that will:
-
-  - run checks in the background (and generate PolicyReport objects)
-
-  - process GenerateRequest objects asynchronously
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Kyverno in action
-
-- We're going to install Kyverno on our cluster
-
-- Then, we will use it to implement a few policies
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Installing Kyverno
-
-- Kyverno can be installed with a (big) YAML manifest
-
-- ... or with Helm charts (which allows to customize a few things)
-
-.lab[
-
-- Install Kyverno:
-  ```bash
-  kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/release-1.7/config/release/install.yaml
-  ```
-
-]
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Kyverno policies in a nutshell
-
-- Which resources does it *select?*
-
-  - can specify resources to *match* and/or *exclude*
-
-  - can specify *kinds* and/or *selector* and/or users/roles doing the action
-
-- Which operation should be done?
-
-  - validate, mutate, or generate
-
-- For validation, whether it should *enforce* or *audit* failures
-
-- Operation details (what exactly to validate, mutate, or generate)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Painting pods
-
-- As an example, we'll implement a policy regarding "Pod color"
-
-- The color of a Pod is the value of the label `color`
-
-- Example: `kubectl label pod hello color=yellow` to paint a Pod in yellow
-
-- We want to implement the following policies:
-
-  - color is optional (i.e. the label is not required)
-
-  - if color is set, it *must* be `red`, `green`, or `blue`
-
-  - once the color has been set, it cannot be changed
-
-  - once the color has been set, it cannot be removed
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Immutable primary colors, take 1
-
-- First, we will add a policy to block forbidden colors
-
-  (i.e. only allow `red`, `green`, or `blue`)
-
-- One possible approach:
-
-  - *match* all pods that have a `color` label that is not `red`, `green`, or `blue`
-
-  - *deny* these pods
-
-- We could also *match* all pods, then *deny* with a condition
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-.small[
-```yaml
-apiVersion: kyverno.io/v1
-kind: ClusterPolicy
-metadata:
-  name: pod-color-policy-1
-spec:
-  validationFailureAction: enforce
-  rules:
-  - name: ensure-pod-color-is-valid
-    match:
-      resources:
-        kinds:
-        - Pod
-        selector:
-          matchExpressions:
-          - key: color
-            operator: Exists
-          - key: color
-            operator: NotIn
-            values: [ red, green, blue ]
-    validate:
-      message: "If it exists, the label color must be red, green, or blue."
-      deny: {}
-
-```
-]
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Testing without the policy
-
-- First, let's create a pod with an "invalid" label
-
-  (while we still can!)
-
-- We will use this later
-
-.lab[
-
-- Create a pod:
-  ```bash
-  kubectl run test-color-0 --image=nginx
-  ```
-
-- Apply a color label:
-  ```bash
-  kubectl label pod test-color-0 color=purple
-  ```
-
-]
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Load and try the policy
-
-.lab[
-
-- Load the policy:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/kyverno-pod-color-1.yaml
-  ```
-
-- Create a pod:
-  ```bash
-  kubectl run test-color-1 --image=nginx
-  ```
-
-- Try to apply a few color labels:
-  ```bash
-  kubectl label pod test-color-1 color=purple
-  kubectl label pod test-color-1 color=red
-  kubectl label pod test-color-1 color-
-  ```
-
-]
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Immutable primary colors, take 2
-
-- Next rule: once a `color` label has been added, it cannot be changed
-
-  (i.e. if `color=red`, we can't change it to `color=blue`)
-
-- Our approach:
-
-  - *match* all pods
-
-  - add a *precondition* matching pods that have a `color` label
-    <br/>
-    (both in their "before" and "after" states)
-
-  - *deny* these pods if their `color` label has changed
-
-- Again, other approaches are possible!
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-.small[
-```yaml
-apiVersion: kyverno.io/v1
-kind: ClusterPolicy
-metadata:
-  name: pod-color-policy-2
-spec:
-  validationFailureAction: enforce
-  background: false
-  rules:
-  - name: prevent-color-change
-    match:
-      resources:
-        kinds:
-        - Pod
-    preconditions:
-    - key: "{{ request.operation }}"
-      operator: Equals
-      value: UPDATE
-    - key: "{{ request.oldObject.metadata.labels.color || '' }}"
-      operator: NotEquals
-      value: ""
-    - key: "{{ request.object.metadata.labels.color || '' }}"
-      operator: NotEquals
-      value: ""
-    validate:
-      message: "Once label color has been added, it cannot be changed."
-      deny:
-        conditions:
-        - key: "{{ request.object.metadata.labels.color }}"
-          operator: NotEquals
-          value: "{{ request.oldObject.metadata.labels.color }}"
-
-
-```
-]
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Comparing "old" and "new"
-
-- The fields of the webhook payload are available through `{{ request }}`
-
-- For UPDATE requests, we can access:
-
-  `{{ request.oldObject }}` → the object as it is right now (before the request)
-
-  `{{ request.object }}` → the object with the changes made by the request
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Missing labels
-
-- We can access the `color` label through `{{ request.object.metadata.labels.color }}`
-
-- If we reference a label (or any field) that doesn't exist, the policy fails
-
-  (with an error similar to `JMESPAth query failed: Unknown key ... in path`)
-
-- To work around that, [use an OR expression][non-existence-checks]:
-
-  `{{ requests.object.metadata.labels.color || '' }}`
-
-- Note that in older versions of Kyverno, this wasn't always necessary
-
-  (e.g. in *preconditions*, a missing label would evalute to an empty string)
-
-[non-existence-checks]: https://kyverno.io/docs/writing-policies/jmespath/#non-existence-checks
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Load and try the policy
-
-.lab[
-
-- Load the policy:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/kyverno-pod-color-2.yaml
-  ```
-
-- Create a pod:
-  ```bash
-  kubectl run test-color-2 --image=nginx
-  ```
-
-- Try to apply a few color labels:
-  ```bash
-  kubectl label pod test-color-2 color=purple
-  kubectl label pod test-color-2 color=red
-  kubectl label pod test-color-2 color=blue --overwrite
-  ```
-
-]
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## `background`
-
-- What is this `background: false` option, and why do we need it?
-
---
-
-- Admission controllers are only invoked when we change an object
-
-- Existing objects are not affected
-
-  (e.g. if we have a pod with `color=pink` *before* installing our policy)
-
-- Kyvero can also run checks in the background, and report violations
-
-  (we'll see later how they are reported)
-
-- `background: false` disables that
-
---
-
-- Alright, but ... *why* do we need it?
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Accessing `AdmissionRequest` context
-
-- In this specific policy, we want to prevent an *update*
-
-  (as opposed to a mere *create* operation)
-
-- We want to compare the *old* and *new* version
-
-  (to check if a specific label was removed)
-
-- The `AdmissionRequest` object has `object` and `oldObject` fields
-
-  (the `AdmissionRequest` object is the thing that gets submitted to the webhook)
-
-- We access the `AdmissionRequest` object through `{{ request }}`
-
---
-
-- Alright, but ... what's the link with `background: false`?
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## `{{ request }}`
-
-- The `{{ request }}` context is only available when there is an `AdmissionRequest`
-
-- When a resource is "at rest", there is no `{{ request }}` (and no old/new)
-
-- Therefore, a policy that uses `{{ request }}` cannot validate existing objects
-
-  (it can only be used when an object is actually created/updated/deleted)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Immutable primary colors, take 3
-
-- Last rule: once a `color` label has been added, it cannot be removed
-
-- Our approach is to match all pods that:
-
-  - *had* a `color` label (in `request.oldObject`)
-
-  - *don't have* a `color` label (in `request.Object`)
-
-- And *deny* these pods
-
-- Again, other approaches are possible!
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-.small[
-```yaml
-apiVersion: kyverno.io/v1
-kind: ClusterPolicy
-metadata:
-  name: pod-color-policy-3
-spec:
-  validationFailureAction: enforce
-  background: false
-  rules:
-  - name: prevent-color-change
-    match:
-      resources:
-        kinds:
-        - Pod
-    preconditions:
-    - key: "{{ request.operation }}"
-      operator: Equals
-      value: UPDATE
-    - key: "{{ request.oldObject.metadata.labels.color || '' }}"
-      operator: NotEquals
-      value: ""
-    - key: "{{ request.object.metadata.labels.color || '' }}"
-      operator: Equals
-      value: ""
-    validate:
-      message: "Once label color has been added, it cannot be removed."
-      deny:
-        conditions:
-
-
-```
-]
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Load and try the policy
-
-.lab[
-
-- Load the policy:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/kyverno-pod-color-3.yaml
-  ```
-
-- Create a pod:
-  ```bash
-  kubectl run test-color-3 --image=nginx
-  ```
-
-- Try to apply a few color labels:
-  ```bash
-  kubectl label pod test-color-3 color=purple
-  kubectl label pod test-color-3 color=red
-  kubectl label pod test-color-3 color-
-  ```
-
-]
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Background checks
-
-- What about the `test-color-0` pod that we create initially?
-
-  (remember: we did set `color=purple`)
-
-- We can see the infringing Pod in a PolicyReport
-
-.lab[
-
-- Check that the pod still an "invalid" color:
-  ```bash
-  kubectl get pods -L color
-  ```
-
-- List PolicyReports:
-  ```bash
-  kubectl get policyreports
-  kubectl get polr
-  ```
-
-]
-
-(Sometimes it takes a little while for the infringement to show up, though.)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Generating objects
-
-- When we create a Namespace, we also want to automatically create:
-
-  - a LimitRange (to set default CPU and RAM requests and limits)
-
-  - a ResourceQuota (to limit the resources used by the namespace)
-
-  - a NetworkPolicy (to isolate the namespace)
-
-- We can do that with a Kyverno policy with a *generate* action
-
-  (it is mutually exclusive with the *validate* action)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Overview
-
-- The *generate* action must specify:
-
-  - the `kind` of resource to generate
-
-  - the `name` of the resource to generate
-
-  - its `namespace`, when applicable
-
-  - *either* a `data` structure, to be used to populate the resource
-
-  - *or* a `clone` reference, to copy an existing resource
-
-Note: the `apiVersion` field appears to be optional.
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## In practice
-
-- We will use the policy [k8s/kyverno-namespace-setup.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/kyverno-namespace-setup.yaml)
-
-- We need to generate 3 resources, so we have 3 rules in the policy
-
-- Excerpt:
-  ```yaml
-      generate: 
-      kind: LimitRange
-      name: default-limitrange
-      namespace: "{{request.object.metadata.name}}" 
-      data:
-        spec:
-          limits:
-  ```
-
-- Note that we have to specify the `namespace`
-
-  (and we infer it from the name of the resource being created, i.e. the Namespace)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Lifecycle
-
-- After generated objects have been created, we can change them
-
-  (Kyverno won't update them)
-
-- Except if we use `clone` together with the `synchronize` flag
-
-  (in that case, Kyverno will watch the cloned resource)
-
-- This is convenient for e.g. ConfigMaps shared between Namespaces
-
-- Objects are generated only at *creation* (not when updating an old object)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-class: extra-details
-
-## Managing `ownerReferences`
-
-- By default, the generated object and triggering object have independent lifecycles
-
-  (deleting the triggering object doesn't affect the generated object)
-
-- It is possible to associate the generated object with the triggering object
-
-  (so that deleting the triggering object also deletes the generated object)
-
-- This is done by adding the triggering object information to `ownerReferences`
-
-  (in the generated object `metadata`)
-
-- See [Linking resources with ownerReferences][ownerref] for an example
-
-[ownerref]: https://kyverno.io/docs/writing-policies/generate/#linking-resources-with-ownerreferences
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Asynchronous creation
-
-- Kyverno creates resources asynchronously
-
-  (by creating a GenerateRequest resource first)
-
-- This is useful when the resource cannot be created
-
-  (because of permissions or dependency issues)
-
-- Kyverno will periodically loop through the pending GenerateRequests
-
-- Once the ressource is created, the GenerateRequest is marked as Completed
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Footprint
-
-- 8 CRDs
-
-- 5 webhooks
-
-- 2 Services, 1 Deployment, 2 ConfigMaps
-
-- Internal resources (GenerateRequest) "parked" in a Namespace
-
-- Kyverno packs a lot of features in a small footprint
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Strengths
-
-- Kyverno is very easy to install
-
-  (it's harder to get easier than one `kubectl apply -f`)
-
-- The setup of the webhooks is fully automated
-
-  (including certificate generation)
-
-- It offers both namespaced and cluster-scope policies
-
-- The policy language leverages existing constructs
-
-  (e.g. `matchExpressions`)
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-## Caveats
-
-- The `{{ request }}` context is powerful, but difficult to validate
-
-  (Kyverno can't know ahead of time how it will be populated)
-
-- Advanced policies (with conditionals) have unique, exotic syntax:
-  ```yaml
-      spec:
-	    =(volumes):
-	      =(hostPath):
-	        path: "!/var/run/docker.sock"
-  ```
-
-- Writing and validating policies can be difficult
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-class: extra-details
-
-## Pods created by controllers
-
-- When e.g. a ReplicaSet or DaemonSet creates a pod, it "owns" it
-
-  (the ReplicaSet or DaemonSet is listed in the Pod's `.metadata.ownerReferences`)
-
-- Kyverno treats these Pods differently
-
-- If my understanding of the code is correct (big *if*):
-
-  - it skips validation for "owned" Pods
-
-  - instead, it validates their controllers
-
-  - this way, Kyverno can report errors on the controller instead of the pod
-
-- This can be a bit confusing when testing policies on such pods!
-
-???
-
-:EN:- Policy Management with Kyverno
-:FR:- Gestion de *policies* avec Kyverno
-
-.debug[[k8s/kyverno.md](""/tree/main/slides/k8s/kyverno.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg)]
-
----
-
-name: toc-the-aggregation-layer
-class: title
-
- The Aggregation Layer
-
-.nav[
-[Previous part](#toc-policy-management-with-kyverno)
-|
-[Back to table of contents](#toc-part-8)
-|
-[Next part](#toc-checking-node-and-pod-resource-usage)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# The Aggregation Layer
-
-- The aggregation layer is a way to extend the Kubernetes API
-
-- It is similar to CRDs
-
-  - it lets us define new resource types
-
-  - these resources can then be used with `kubectl` and other clients
-
-- The implementation is very different
-
-  - CRDs are handled within the API server
-
-  - the aggregation layer offloads requests to another process
-
-- They are designed for very different use-cases
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## CRDs vs aggregation layer
-
-- The Kubernetes API is a REST-ish API with a hierarchical structure
-
-- It can be extended with Custom Resource Definifions (CRDs)
-
-- Custom resources are managed by the Kubernetes API server
-
-  - we don't need to write code
-
-  - the API server does all the heavy lifting
-
-  - these resources are persisted in Kubernetes' "standard" database
-    <br/>
-    (for most installations, that's `etcd`)
-
-- We can also define resources that are *not* managed by the API server
-
-  (the API server merely proxies the requests to another server)
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Which one is best?
-
-- For things that "map" well to objects stored in a traditional database:
-
-  *probably CRDs*
-
-- For things that "exist" only in Kubernetes and don't represent external resources:
-
-  *probably CRDs*
-
-- For things that are read-only, at least from Kubernetes' perspective:
-
-  *probably aggregation layer*
-
-- For things that can't be stored in etcd because of size or access patterns:
-
-  *probably aggregation layer*
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## How are resources organized?
-
-- Let's have a look at the Kubernetes API hierarchical structure
-
-- We'll ask `kubectl` to show us the exacts requests that it's making
-
-.lab[
-
-- Check the URI for a cluster-scope, "core" resource, e.g. a Node:
-  ```bash
-  kubectl -v6 get node node1
-  ```
-
-- Check the URI for a cluster-scope, "non-core" resource, e.g. a ClusterRole:
-  ```bash
-  kubectl -v6 get clusterrole view
-  ```
-
-]
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Core vs non-core
-
-- This is the structure of the URIs that we just checked:
-
-  ```
-    /api/v1/nodes/node1
-         ↑    ↑     ↑
-     `version` `kind` `name`
-
-    /apis/rbac.authorization.k8s.io/v1/clusterroles/view
-                        ↑           ↑        ↑       ↑
-                      `group`      `version`   `kind`    `name`
-  ```
-
-- There is no group for "core" resources
-
-- Or, we could say that the group, `core`, is implied
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Group-Version-Kind
-
-- In the API server, the Group-Version-Kind triple maps to a Go type
-
-  (look for all the "GVK" occurrences in the source code!)
-
-- In the API server URI router, the GVK is parsed "relatively early"
-
-  (so that the server can know which resource we're talking about)
-
-- "Well, actually ..." Things are a bit more complicated, see next slides!
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-class: extra-details
-
-## Namespaced resources
-
-- What about namespaced resources?
-
-.lab[
-
-- Check the URI for a namespaced, "core" resource, e.g. a Service:
-  ```bash
-  kubectl -v6 get service kubernetes --namespace default
-  ```
-
-]
-
-- Here are what namespaced resources URIs look like:
-
-  ```
-    /api/v1/namespaces/default/services/kubernetes
-         ↑               ↑        ↑         ↑
-      `version`        `namespace`  `kind`      `name`
-
-    /apis/apps/v1/namespaces/kube-system/daemonsets/kube-proxy
-           ↑   ↑                 ↑           ↑          ↑
-       `group`  `version`        `namespace`     `kind`       `name`
-  ```
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-class: extra-details
-
-## Subresources
-
-- Many resources have *subresources*, for instance:
-
-  - `/status` (decouples status updates from other updates)
-
-  - `/scale` (exposes a consistent interface for autoscalers)
-
-  - `/proxy` (allows access to HTTP resources)
-
-  - `/portforward` (used by `kubectl port-forward`)
-
-  - `/logs` (access pod logs)
-
-- These are added at the end of the URI
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-class: extra-details
-
-## Accessing a subresource
-
-.lab[
-
-- List `kube-proxy` pods:
-  ```bash
-    kubectl get pods --namespace=kube-system --selector=k8s-app=kube-proxy
-    PODNAME=$(
-      kubectl get pods --namespace=kube-system --selector=k8s-app=kube-proxy \
-              -o json | jq -r .items[0].metadata.name)
-  ```
-
-- Execute a command in a pod, showing the API requests:
-  ```bash
-  kubectl -v6 exec --namespace=kube-system $PODNAME -- echo hello world
-  ```
-
-]
-
---
-
-The full request looks like:
-```
-POST https://.../api/v1/namespaces/kube-system/pods/kube-proxy-c7rlw/exec?
-command=echo&command=hello&command=world&container=kube-proxy&stderr=true&stdout=true
-```
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Listing what's supported on the server
-
-- There are at least three useful commands to introspect the API server
-
-.lab[
-
-- List resources types, their group, kind, short names, and scope:
-  ```bash
-  kubectl api-resources
-  ```
-
-- List API groups + versions:
-  ```bash
-  kubectl api-versions
-  ```
-
-- List APIServices:
-  ```bash
-  kubectl get apiservices
-  ```
-
-]
-
---
-
-🤔 What's the difference between the last two?
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## API registration
-
-- `kubectl api-versions` shows all API groups, including `apiregistration.k8s.io`
-
-- `kubectl get apiservices` shows the "routing table" for API requests
-
-- The latter doesn't show `apiregistration.k8s.io`
-
-  (APIServices belong to `apiregistration.k8s.io`)
-
-- Most API groups are `Local` (handled internally by the API server)
-
-- If we're running the `metrics-server`, it should handle `metrics.k8s.io`
-
-- This is an API group handled *outside* of the API server
-
-- This is the *aggregation layer!*
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Finding resources
-
-The following assumes that `metrics-server` is deployed on your cluster.
-
-.lab[
-
-- Check that the metrics.k8s.io is registered with `metrics-server`:
-  ```bash
-  kubectl get apiservices | grep metrics.k8s.io
-  ```
-
-- Check the resource kinds registered in the metrics.k8s.io group:
-  ```bash
-  kubectl api-resources --api-group=metrics.k8s.io
-  ```
-
-]
-
-(If the output of either command is empty, install `metrics-server` first.)
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## `nodes` vs `nodes`
-
-- We can have multiple resources with the same name
-
-.lab[
-
-- Look for resources named `node`:
-  ```bash
-  kubectl api-resources | grep -w nodes
-  ```
-
-- Compare the output of both commands:
-  ```bash
-  kubectl get nodes
-  kubectl get nodes.metrics.k8s.io
-  ```
-
-]
-
---
-
-🤔 What are the second kind of nodes? How can we see what's really in them?
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Node vs NodeMetrics
-
-- `nodes.metrics.k8s.io` (aka NodeMetrics) don't have fancy *printer columns*
-
-- But we can look at the raw data (with `-o json` or `-o yaml`)
-
-.lab[
-
-- Look at NodeMetrics objects with one of these commands:
-  ```bash
-  kubectl get -o yaml nodes.metrics.k8s.io
-  kubectl get -o yaml NodeMetrics
-  ```
-
-]
-
---
-
-💡 Alright, these are the live metrics (CPU, RAM) for our nodes.
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## An easier way to consume metrics
-
-- We might have seen these metrics before ... With an easier command!
-
---
-
-.lab[
-
-- Display node metrics:
-  ```bash
-  kubectl top nodes
-  ```
-
-- Check which API requests happen behind the scenes:
-  ```bash
-  kubectl top nodes -v6
-  ```
-
-]
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Aggregation layer in practice
-
-- We can write an API server to handle a subset of the Kubernetes API
-
-- Then we can register that server by creating an APIService resource
-
-.lab[
-
-- Check the definition used for the `metrics-server`:
-  ```bash
-  kubectl describe apiservices v1beta1.metrics.k8s.io
-  ```
-]
-
-- Group priority is used when multiple API groups provide similar kinds
-
-  (e.g. `nodes` and `nodes.metrics.k8s.io` as seen earlier)
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Authentication flow
-
-- We have two Kubernetes API servers:
- 
-  - "aggregator" (the main one; clients connect to it)
-
-  - "aggregated" (the one providing the extra API; aggregator connects to it)
-
-- Aggregator deals with client authentication
-
-- Aggregator authenticates with aggregated using mutual TLS
-
-- Aggregator passes (/forwards/proxies/...) requests to aggregated
-
-- Aggregated performs authorization by calling back aggregator
-
-  ("can subject X perform action Y on resource Z?")
-
-[This doc page](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/#authentication-flow) has very nice swim lanes showing that flow.
-
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-## Discussion
-
-- Aggregation layer is great for metrics
-
-  (fast-changing, ephemeral data, that would be outrageously bad for etcd)
-
-- It *could* be a good fit to expose other REST APIs as a pass-thru 
-
-  (but it's more common to see CRDs instead)
-
-???
-
-:EN:- The aggregation layer
-:FR:- Étendre l'API avec le *aggregation layer*
-.debug[[k8s/aggregation-layer.md](""/tree/main/slides/k8s/aggregation-layer.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg)]
-
----
-
-name: toc-checking-node-and-pod-resource-usage
-class: title
-
- Checking Node and Pod resource usage
-
-.nav[
-[Previous part](#toc-the-aggregation-layer)
-|
-[Back to table of contents](#toc-part-8)
-|
-[Next part](#toc-collecting-metrics-with-prometheus)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Checking Node and Pod resource usage
-
-- We've installed a few things on our cluster so far
-
-- How much resources (CPU, RAM) are we using?
-
-- We need metrics!
-
-.lab[
-
-- Let's try the following command:
-  ```bash
-  kubectl top nodes
-  ```
-]
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Is metrics-server installed?
-
-- If we see a list of nodes, with CPU and RAM usage:
-
-  *great, metrics-server is installed!*
-
-- If we see `error: Metrics API not available`:
-
-  *metrics-server isn't installed, so we'll install it!*
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## The resource metrics pipeline
-
-- The `kubectl top` command relies on the Metrics API
-
-- The Metrics API is part of the "[resource metrics pipeline]"
-
-- The Metrics API isn't served (built into) the Kubernetes API server
-
-- It is made available through the [aggregation layer]
-
-- It is usually served by a component called metrics-server
-
-- It is optional (Kubernetes can function without it)
-
-- It is necessary for some features (like the Horizontal Pod Autoscaler)
-
-[resource metrics pipeline]: https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/
-[aggregation layer]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Other ways to get metrics
-
-- We could use a SAAS like Datadog, New Relic...
-
-- We could use a self-hosted solution like Prometheus
-
-- Or we could use metrics-server
-
-- What's special about metrics-server?
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Pros/cons
-
-Cons:
-
-- no data retention (no history data, just instant numbers)
-
-- only CPU and RAM of nodes and pods (no disk or network usage or I/O...)
-
-Pros:
-
-- very lightweight
-
-- doesn't require storage
-
-- used by Kubernetes autoscaling
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Why metrics-server
-
-- We may install something fancier later
-
-  (think: Prometheus with Grafana)
-
-- But metrics-server will work in *minutes*
-
-- It will barely use resources on our cluster
-
-- It's required for autoscaling anyway
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## How metric-server works
-
-- It runs a single Pod
-
-- That Pod will fetch metrics from all our Nodes
-
-- It will expose them through the Kubernetes API aggregation layer
-
-  (we won't say much more about that aggregation layer; that's fairly advanced stuff!)
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Installing metrics-server
-
-- In a lot of places, this is done with a little bit of custom YAML
-
-  (derived from the [official installation instructions](https://github.com/kubernetes-sigs/metrics-server#installation))
-
-- We're going to use Helm one more time:
-  ```bash
-    helm upgrade --install metrics-server bitnami/metrics-server \
-      --create-namespace --namespace metrics-server \
-      --set apiService.create=true \
-      --set extraArgs.kubelet-insecure-tls=true \
-      --set extraArgs.kubelet-preferred-address-types=InternalIP
-  ```
-
-- What are these options for?
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Installation options
-
-- `apiService.create=true`
-
-  register `metrics-server` with the Kubernetes aggregation layer
-
-  (create an entry that will show up in `kubectl get apiservices`)
-
-- `extraArgs.kubelet-insecure-tls=true`
-
-  when connecting to nodes to collect their metrics, don't check kubelet TLS certs
-
-  (because most kubelet certs include the node name, but not its IP address)
-
-- `extraArgs.kubelet-preferred-address-types=InternalIP`
-
-  when connecting to nodes, use their internal IP address instead of node name
-
-  (because the latter requires an internal DNS, which is rarely configured)
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Testing metrics-server
-
-- After a minute or two, metrics-server should be up
-
-- We should now be able to check Nodes resource usage:
-  ```bash
-  kubectl top nodes
-  ```
-
-- And Pods resource usage, too:
-  ```bash
-  kubectl top pods --all-namespaces
-  ```
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Keep some padding
-
-- The RAM usage that we see should correspond more or less to the Resident Set Size
-
-- Our pods also need some extra space for buffers, caches...
-
-- Do not aim for 100% memory usage!
-
-- Some more realistic targets:
-
-  50% (for workloads with disk I/O and leveraging caching)
-
-  90% (on very big nodes with mostly CPU-bound workloads)
-
-  75% (anywhere in between!)
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-## Other tools
-
-- kube-capacity is a great CLI tool to view resources
-
-  (https://github.com/robscott/kube-capacity)
-
-- It can show resource and limits, and compare them with usage
-
-- It can show utilization per node, or per pod
-
-- kube-resource-report can generate HTML reports
-
-  (https://codeberg.org/hjacobs/kube-resource-report)
-
-???
-
-:EN:- The resource metrics pipeline
-:EN:- Installing metrics-server
-
-:EN:- Le *resource metrics pipeline*
-:FR:- Installtion de metrics-server
-
-.debug[[k8s/metrics-server.md](""/tree/main/slides/k8s/metrics-server.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg)]
-
----
-
-name: toc-collecting-metrics-with-prometheus
-class: title
-
- Collecting metrics with Prometheus
-
-.nav[
-[Previous part](#toc-checking-node-and-pod-resource-usage)
-|
-[Back to table of contents](#toc-part-8)
-|
-[Next part](#toc-prometheus-and-grafana)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Collecting metrics with Prometheus
-
-- Prometheus is an open-source monitoring system including:
-
-  - multiple *service discovery* backends to figure out which metrics to collect
-
-  - a *scraper* to collect these metrics
-
-  - an efficient *time series database* to store these metrics
-
-  - a specific query language (PromQL) to query these time series
-
-  - an *alert manager* to notify us according to metrics values or trends
-
-- We are going to use it to collect and query some metrics on our Kubernetes cluster
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Why Prometheus?
-
-- We don't endorse Prometheus more or less than any other system
-
-- It's relatively well integrated within the cloud-native ecosystem
-
-- It can be self-hosted (this is useful for tutorials like this)
-
-- It can be used for deployments of varying complexity:
-
-  - one binary and 10 lines of configuration to get started
-
-  - all the way to thousands of nodes and millions of metrics
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Exposing metrics to Prometheus
-
-- Prometheus obtains metrics and their values by querying *exporters*
-
-- An exporter serves metrics over HTTP, in plain text
-
-- 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
-
-- If you want to expose custom metrics to Prometheus:
-
-  - serve a text page like these, and you're good to go
-
-  - libraries are available in various languages to help with quantiles etc.
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## How Prometheus gets these metrics
-
-- The *Prometheus server* will *scrape* URLs like these at regular intervals
-
-  (by default: every minute; can be more/less frequent)
-
-- The list of URLs to scrape (the *scrape targets*) is defined in configuration
-
-.footnote[Worried about the overhead of parsing a text format?
-<br/>
-Check this [comparison](https://github.com/RichiH/OpenMetrics/blob/master/markdown/protobuf_vs_text.md) of the text format with the (now deprecated) protobuf format!]
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Defining scrape targets
-
-This is maybe the simplest configuration file for Prometheus:
-```yaml
-scrape_configs:
-  - job_name: 'prometheus'
-    static_configs:
-      - targets: ['localhost:9090']
-```
-
-- In this configuration, Prometheus collects its own internal metrics
-
-- A typical configuration file will have multiple `scrape_configs`
-
-- In this configuration, the list of targets is fixed
-
-- A typical configuration file will use dynamic service discovery
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Service discovery
-
-This configuration file will leverage existing DNS `A` records:
-```yaml
-scrape_configs:
-  - ...
-  - job_name: 'node'
-    dns_sd_configs:
-      - names: ['api-backends.dc-paris-2.enix.io']
-        type: 'A'
-        port: 9100
-```
-
-- In this configuration, Prometheus resolves the provided name(s)
-
-  (here, `api-backends.dc-paris-2.enix.io`)
-
-- Each resulting IP address is added as a target on port 9100
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Dynamic service discovery
-
-- In the DNS example, the names are re-resolved at regular intervals
-
-- As DNS records are created/updated/removed, scrape targets change as well
-
-- Existing data (previously collected metrics) is not deleted
-
-- Other service discovery backends work in a similar fashion
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Other service discovery mechanisms
-
-- Prometheus can connect to e.g. a cloud API to list instances
-
-- Or to the Kubernetes API to list nodes, pods, services ...
-
-- Or a service like Consul, Zookeeper, etcd, to list applications
-
-- The resulting configurations files are *way more complex*
-
-  (but don't worry, we won't need to write them ourselves)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Time series database
-
-- We could wonder, "why do we need a specialized database?"
-
-- One metrics data point = metrics ID + timestamp + value
-
-- With a classic SQL or noSQL data store, that's at least 160 bits of data + indexes
-
-- Prometheus is way more efficient, without sacrificing performance
-
-  (it will even be gentler on the I/O subsystem since it needs to write less)
-
-- Would you like to know more? Check this video:
-
-  [Storage in Prometheus 2.0](https://www.youtube.com/watch?v=C4YV-9CrawA) by [Goutham V](https://twitter.com/putadent) at DC17EU
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Checking if Prometheus is installed
-
-- Before trying to install Prometheus, let's check if it's already there
-
-.lab[
-
-- Look for services with a label `app=prometheus` across all namespaces:
-  ```bash
-  kubectl get services --selector=app=prometheus --all-namespaces
-  ```
-
-]
-
-If we see a `NodePort` service called `prometheus-server`, we're good!
-
-(We can then skip to "Connecting to the Prometheus web UI".)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Running Prometheus on our cluster
-
-We need to:
-
-- Run the Prometheus server in a pod
-
-  (using e.g. a Deployment to ensure that it keeps running)
-
-- Expose the Prometheus server web UI (e.g. with a NodePort)
-
-- Run the *node exporter* on each node (with a Daemon Set)
-
-- Set up a Service Account so that Prometheus can query the Kubernetes API
-
-- Configure the Prometheus server
-
-  (storing the configuration in a Config Map for easy updates)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Helm charts to the rescue
-
-- To make our lives easier, we are going to use a Helm chart
-
-- The Helm chart will take care of all the steps explained above
-
-  (including some extra features that we don't need, but won't hurt)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Step 1: install Helm
-
-- If we already installed Helm earlier, this command won't break anything
-
-.lab[
-
-- Install the Helm CLI:
-  ```bash
-  curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get-helm-3 \
-  | bash
-  ```
-
-]
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Step 2: install Prometheus
-
-- The following command, just like the previous ones, is idempotent
-
-  (it won't error out if Prometheus is already installed)
-
-.lab[
-
-- Install Prometheus on our cluster:
-  ```bash
-    helm upgrade prometheus --install prometheus \
-        --repo https://prometheus-community.github.io/helm-charts \
-        --namespace prometheus --create-namespace \
-        --set server.service.type=NodePort \
-        --set server.service.nodePort=30090 \
-        --set server.persistentVolume.enabled=false \
-        --set alertmanager.enabled=false
-  ```
-
-]
-
-Curious about all these flags? They're explained in the next slide.
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-class: extra-details
-
-## Explaining all the Helm flags
-
-- `helm upgrade prometheus` → upgrade the release named `prometheus`
-  <br/>
-  (a "release" is an instance of an app deployed with Helm)
-
-- `--install` → if it doesn't exist, install it (instead of upgrading)
-
-- `prometheus` → use the chart named `prometheus`
-
-- `--repo ...` → the chart is located on the following repository
-
-- `--namespace prometheus` → put it in that specific namespace
-
-- `--create-namespace` → create the namespace if it doesn't exist
-
-- `--set ...` → here are some *values* to be used when rendering the chart's templates
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-class: extra-details
-
-## Values for the Prometheus chart
-
-Helm *values* are parameters to customize our installation.
-
-- `server.service.type=NodePort` → expose the Prometheus server with a NodePort
-
-- `server.service.nodePort=30090` → set the specific NodePort number to use
-
-- `server.persistentVolume.enabled=false` → do not use a PersistentVolumeClaim
-
-- `alertmanager.enabled=false` → disable the alert manager entirely
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Connecting to the Prometheus web UI
-
-- Let's connect to the web UI and see what we can do
-
-.lab[
-
-- Figure out the NodePort that was allocated to the Prometheus server:
-  ```bash
-  kubectl get svc --all-namespaces | grep prometheus-server
-  ```
-
-- With your browser, connect to that port
-
-
-- It should be 30090 if we just installed Prometheus with the Helm chart!
-
-]
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Querying some metrics
-
-- This is easy... if you are familiar with PromQL
-
-.lab[
-
-- Click on "Graph", and in "expression", paste the following:
-  ```
-    sum by (instance) (
-      irate(
-        container_cpu_usage_seconds_total{
-          pod=~"worker.*"
-          }[5m]
-      )
-    )
-  ```
-
-]
-
-- Click on the blue "Execute" button and on the "Graph" tab just below
-
-- We see the cumulated CPU usage of worker pods for each node
-  <br/>
-  (if we just deployed Prometheus, there won't be much data to see, though)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Getting started with PromQL
-
-- We can't learn PromQL in just 5 minutes
-
-- But we can cover the basics to get an idea of what is possible
-
-  (and have some keywords and pointers)
-
-- We are going to break down the query above
-
-  (building it one step at a time)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Graphing one metric across all tags
-
-This query will show us CPU usage across all containers:
-```
-container_cpu_usage_seconds_total
-```
-
-- The suffix of the metrics name tells us:
-
-  - the unit (seconds of CPU)
-
-  - that it's the total used since the container creation
-
-- Since it's a "total," it is an increasing quantity
-
-  (we need to compute the derivative if we want e.g. CPU % over time)
-
-- We see that the metrics retrieved have *tags* attached to them
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Selecting metrics with tags
-
-This query will show us only metrics for worker containers:
-```
-container_cpu_usage_seconds_total{pod=~"worker.*"}
-```
-
-- The `=~` operator allows regex matching
-
-- We select all the pods with a name starting with `worker`
-
-  (it would be better to use labels to select pods; more on that later)
-
-- The result is a smaller set of containers
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Transforming counters in rates
-
-This query will show us CPU usage % instead of total seconds used:
-```
-100*irate(container_cpu_usage_seconds_total{pod=~"worker.*"}[5m])
-```
-
-- The [`irate`](https://prometheus.io/docs/prometheus/latest/querying/functions/#irate) operator computes the "per-second instant rate of increase"
-
-  - `rate` is similar but allows decreasing counters and negative values
-
-  - with `irate`, if a counter goes back to zero, we don't get a negative spike
-
-- The `[5m]` tells how far to look back if there is a gap in the data
-
-- And we multiply with `100*` to get CPU % usage
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Aggregation operators
-
-This query sums the CPU usage per node:
-```
-sum by (instance) (
-  irate(container_cpu_usage_seconds_total{pod=~"worker.*"}[5m])
-)
-```
-
-- `instance` corresponds to the node on which the container is running
-
-- `sum by (instance) (...)` computes the sum for each instance
-
-- Note: all the other tags are collapsed
-
-  (in other words, the resulting graph only shows the `instance` tag)
-
-- PromQL supports many more [aggregation operators](https://prometheus.io/docs/prometheus/latest/querying/operators/#aggregation-operators)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## What kind of metrics can we collect?
-
-- Node metrics (related to physical or virtual machines)
-
-- Container metrics (resource usage per container)
-
-- Databases, message queues, load balancers, ...
-
-  (check out this [list of exporters](https://prometheus.io/docs/instrumenting/exporters/)!)
-
-- Instrumentation (=deluxe `printf` for our code)
-
-- Business metrics (customers served, revenue, ...)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-class: extra-details
-
-## 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[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-class: extra-details
-
-## 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 specially accounted for
-
-- 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[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-class: extra-details
-
-## 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[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-class: extra-details
-
-## Detecting scrape targets
-
-- Prometheus can leverage Kubernetes service discovery
-
-  (with proper configuration)
-
-- Services or pods can be annotated with:
-
-  - `prometheus.io/scrape: true` to enable scraping
-  - `prometheus.io/port: 9090` to indicate the port number
-  - `prometheus.io/path: /metrics` to indicate the URI (`/metrics` by default)
-
-- Prometheus will detect and scrape these (without needing a restart or reload)
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## Querying labels
-
-- What if we want to get metrics for containers belonging to a pod tagged `worker`?
-
-- The cAdvisor exporter does not give us Kubernetes labels
-
-- Kubernetes labels are exposed through another exporter
-
-- We can see Kubernetes labels through metrics `kube_pod_labels`
-
-  (each container appears as a time series with constant value of `1`)
-
-- Prometheus *kind of* supports "joins" between time series
-
-- But only if the names of the tags match exactly
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-class: extra-details
-
-## What if the tags don't match?
-
-- Older versions of cAdvisor exporter used tag `pod_name` for the name of a pod
-
-- The Kubernetes service endpoints exporter uses tag `pod` instead
-
-- See [this blog post](https://www.robustperception.io/exposing-the-software-version-to-prometheus) or [this other one](https://www.weave.works/blog/aggregating-pod-resource-cpu-memory-usage-arbitrary-labels-prometheus/) to see how to perform "joins"
-
-- Note that Prometheus cannot "join" time series with different labels
-
-  (see [Prometheus issue #2204](https://github.com/prometheus/prometheus/issues/2204) for the rationale)
-
-- There is a workaround involving relabeling, but it's "not cheap"
-
-  - see [this comment](https://github.com/prometheus/prometheus/issues/2204#issuecomment-261515520) for an overview
-
-  - or [this blog post](https://5pi.de/2017/11/09/use-prometheus-vector-matching-to-get-kubernetes-utilization-across-any-pod-label/) for a complete description of the process
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-## In practice
-
-- Grafana is a beautiful (and useful) frontend to display all kinds of graphs
-
-- Not everyone needs to know Prometheus, PromQL, Grafana, etc.
-
-- But in a team, it is valuable to have at least one person who know them
-
-- That person can set up queries and dashboards for the rest of the team
-
-- It's a little bit like knowing how to optimize SQL queries, Dockerfiles...
-
-  Don't panic if you don't know these tools!
-
-  ...But make sure at least one person in your team is on it 💯
-
-???
-
-:EN:- Collecting metrics with Prometheus
-:FR:- Collecter des métriques avec Prometheus
-
-.debug[[k8s/prometheus.md](""/tree/main/slides/k8s/prometheus.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg)]
-
----
-
-name: toc-prometheus-and-grafana
-class: title
-
- Prometheus and Grafana
-
-.nav[
-[Previous part](#toc-collecting-metrics-with-prometheus)
-|
-[Back to table of contents](#toc-part-8)
-|
-[Next part](#toc-scaling-with-custom-metrics)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Prometheus and Grafana
-
-- What if we want metrics retention, view graphs, trends?
-
-- A very popular combo is Prometheus+Grafana:
-
-  - Prometheus as the "metrics engine"
-
-  - Grafana to display comprehensive dashboards
-
-- Prometheus also has an alert-manager component to trigger alerts
-
-  (we won't talk about that one)
-
-.debug[[k8s/prometheus-stack.md](""/tree/main/slides/k8s/prometheus-stack.md)]
----
-
-## Installing Prometheus and Grafana
-
-- A complete metrics stack needs at least:
-
-  - the Prometheus server (collects metrics and stores them efficiently)
-
-  - a collection of *exporters* (exposing metrics to Prometheus)
-
-  - Grafana
-
-  - a collection of Grafana dashboards (building them from scratch is tedious)
-
-- The Helm chart `kube-prometheus-stack` combines all these elements
-
-- ... So we're going to use it to deploy our metrics stack!
-
-.debug[[k8s/prometheus-stack.md](""/tree/main/slides/k8s/prometheus-stack.md)]
----
-
-## Installing `kube-prometheus-stack`
-
-- Let's install that stack *directly* from its repo
-
-  (without doing `helm repo add` first)
-
-- Otherwise, keep the same naming strategy:
-  ```bash
-    helm upgrade --install kube-prometheus-stack kube-prometheus-stack \
-      --namespace kube-prometheus-stack --create-namespace \
-      --repo https://prometheus-community.github.io/helm-charts 
-  ```
-
-- This will take a minute...
-
-- Then check what was installed:
-  ```bash
-  kubectl get all --namespace kube-prometheus-stack
-  ```
-
-.debug[[k8s/prometheus-stack.md](""/tree/main/slides/k8s/prometheus-stack.md)]
----
-
-## Exposing Grafana
-
-- Let's create an Ingress for Grafana
-  ```bash
-    kubectl create ingress --namespace kube-prometheus-stack grafana \
-      --rule=grafana.`cloudnative.party`/*=kube-prometheus-stack-grafana:80
-  ```
-
-  (as usual, make sure to use *your* domain name above)
-
-- Connect to Grafana
-
-  (remember that the DNS record might take a few minutes to come up)
-
-.debug[[k8s/prometheus-stack.md](""/tree/main/slides/k8s/prometheus-stack.md)]
----
-
-## Grafana credentials
-
-- What could the login and password be?
-
-- Let's look at the Secrets available in the namespace:
-  ```bash
-  kubectl get secrets --namespace kube-prometheus-stack
-  ```
-
-- There is a `kube-prometheus-stack-grafana` that looks promising!
-
-- Decode the Secret:
-  ```bash
-    kubectl get secret --namespace kube-prometheus-stack \
-      kube-prometheus-stack-grafana -o json | jq '.data | map_values(@base64d)'
-  ```
-
-- If you don't have the `jq` tool mentioned above, don't worry...
-
---
-
-- The login/password is hardcoded to `admin`/`prom-operator` 😬
-
-.debug[[k8s/prometheus-stack.md](""/tree/main/slides/k8s/prometheus-stack.md)]
----
-
-## Grafana dashboards
-
-- Once logged in, click on the "Dashboards" icon on the left
-
-  (it's the one that looks like four squares)
-
-- Then click on the "Manage" entry
-
-- Then click on "Kubernetes / Compute Resources / Cluster"
-
-- This gives us a breakdown of resource usage by Namespace
-
-- Feel free to explore the other dashboards!
-
-???
-
-:EN:- Installing Prometheus and Grafana
-:FR:- Installer Prometheus et Grafana
-
-:T: Observing our cluster with Prometheus and Grafana
-
-:Q: What's the relationship between Prometheus and Grafana?
-:A: Prometheus collects and graphs metrics; Grafana sends alerts
-:A: ✔️Prometheus collects metrics; Grafana displays them on dashboards
-:A: Prometheus collects and graphs metrics; Grafana is its configuration interface
-:A: Grafana collects and graphs metrics; Prometheus sends alerts
-
-.debug[[k8s/prometheus-stack.md](""/tree/main/slides/k8s/prometheus-stack.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-housing.jpg)]
-
----
-
-name: toc-scaling-with-custom-metrics
-class: title
-
- Scaling with custom metrics
-
-.nav[
-[Previous part](#toc-prometheus-and-grafana)
-|
-[Back to table of contents](#toc-part-8)
-|
-[Next part](#toc-designing-an-operator)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Scaling with custom metrics
-
-- The HorizontalPodAutoscaler v1 can only scale on Pod CPU usage
-
-- Sometimes, we need to scale using other metrics:
-
-  - memory
-
-  - requests per second
-
-  - latency
-
-  - active sessions
-
-  - items in a work queue
-
-  - ...
-
-- The HorizontalPodAutoscaler v2 can do it!
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Requirements
-
-⚠️ Autoscaling on custom metrics is fairly complex!
-
-- We need some metrics system
-
-  (Prometheus is a popular option, but others are possible too)
-
-- We need our metrics (latency, traffic...) to be fed in the system
-
-  (with Prometheus, this might require a custom exporter)
-
-- We need to expose these metrics to Kubernetes
-
-  (Kubernetes doesn't "speak" the Prometheus API)
-
-- Then we can set up autoscaling!
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## The plan
-
-- We will deploy the DockerCoins demo app
-
-  (one of its components has a bottleneck; its latency will increase under load)
-
-- We will use Prometheus to collect and store metrics
-
-- We will deploy a tiny HTTP latency monitor (a Prometheus *exporter*)
-
-- We will deploy the "Prometheus adapter"
-
-  (mapping Prometheus metrics to Kubernetes-compatible metrics)
-
-- We will create an HorizontalPodAutoscaler 🎉
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Deploying DockerCoins
-
-- That's the easy part!
-
-.lab[
-
-- Create a new namespace and switch to it:
-  ```bash
-  kubectl create namespace customscaling
-  kns customscaling
-  ```
-
-- Deploy DockerCoins, and scale up the `worker` Deployment:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/dockercoins.yaml
-  kubectl scale deployment worker --replicas=10
-  ```
-
-]
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Current state of affairs
-
-- The `rng` service is a bottleneck
-
-  (it cannot handle more than 10 requests/second)
-
-- With enough traffic, its latency increases
-
-  (by about 100ms per `worker` Pod after the 3rd worker)
-
-.lab[
-
-- Check the `webui` port and open it in your browser:
-  ```bash
-  kubectl get service webui
-  ```
-
-- Check the `rng` ClusterIP and test it with e.g. `httping`:
-  ```bash
-  kubectl get service rng
-  ```
-
-]
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Measuring latency
-
-- We will use a tiny custom Prometheus exporter, [httplat](https://github.com/jpetazzo/httplat)
-
-- `httplat` exposes Prometheus metrics on port 9080 (by default)
-
-- It monitors exactly one URL, that must be passed as a command-line argument
-
-.lab[
-
-- Deploy `httplat`:
-  ```bash
-  kubectl create deployment httplat --image=jpetazzo/httplat -- httplat http://rng/
-  ```
-
-- Expose it:
-  ```bash
-  kubectl expose deployment httplat --port=9080
-  ```
-
-]
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-class: extra-details
-
-## Measuring latency in the real world
-
-- We are using this tiny custom exporter for simplicity
-
-- A more common method to collect latency is to use a service mesh
-
-- A service mesh can usually collect latency for *all* services automatically
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Install Prometheus
-
-- We will use the Prometheus community Helm chart
-
-  (because we can configure it dynamically with annotations)
-
-.lab[
-
-- If it's not installed yet on the cluster, install Prometheus:
-  ```bash
-    helm upgrade --install prometheus prometheus \
-         --repo https://prometheus-community.github.io/helm-charts \
-         --namespace prometheus --create-namespace \
-         --set server.service.type=NodePort \
-         --set server.service.nodePort=30090 \
-         --set server.persistentVolume.enabled=false \
-         --set alertmanager.enabled=false
-  ```
-
-]
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Configure Prometheus
-
-- We can use annotations to tell Prometheus to collect the metrics
-
-.lab[
-
-- Tell Prometheus to "scrape" our latency exporter:
-  ```bash
-    kubectl annotate service httplat \
-            prometheus.io/scrape=true \
-            prometheus.io/port=9080 \
-            prometheus.io/path=/metrics
-  ```
-
-]
-
-If you deployed Prometheus differently, you might have to configure it manually.
-
-You'll need to instruct it to scrape http://httplat.customscaling.svc:9080/metrics.
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Make sure that metrics get collected
-
-- Before moving on, confirm that Prometheus has our metrics
-
-.lab[
-
-- Connect to Prometheus
-
-  (if you installed it like instructed above, it is exposed as a NodePort on port 30090)
-
-- Check that `httplat` metrics are available
-
-- You can try to graph the following PromQL expression:
-  ```
-  rate(httplat_latency_seconds_sum[2m])/rate(httplat_latency_seconds_count[2m])
-  ```
-
-]
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Troubleshooting
-
-- Make sure that the exporter works:
-
-  - get the ClusterIP of the exporter with `kubectl get svc httplat`
-
-  - `curl http://<ClusterIP>:9080/metrics`
-
-  - check that the result includes the `httplat` histogram
-
-- Make sure that Prometheus is scraping the exporter:
-
-  - go to `Status` / `Targets` in Prometheus
-
-  - make sure that `httplat` shows up in there
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Creating the autoscaling policy
-
-- We need custom YAML (we can't use the `kubectl autoscale` command)
-
-- It must specify `scaleTargetRef`, the resource to scale
-
-  - any resource with a `scale` sub-resource will do
-
-  - this includes Deployment, ReplicaSet, StatefulSet...
-
-- It must specify one or more `metrics` to look at
-
-  - if multiple metrics are given, the autoscaler will "do the math" for each one
-
-  - it will then keep the largest result
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Details about the `metrics` list
-
-- Each item will look like this:
-  ```yaml
-    - type: <TYPE-OF-METRIC>
-      <TYPE-OF-METRIC>:
-        metric:
-          name: <NAME-OF-METRIC>
-          <...optional selector (mandatory for External metrics)...>
-        target:
-          type: <TYPE-OF-TARGET>
-          <TYPE-OF-TARGET>: <VALUE>
-        <describedObject field, for Object metrics>
-  ```
-
-`<TYPE-OF-METRIC>` can be `Resource`, `Pods`, `Object`, or `External`.
-
-`<TYPE-OF-TARGET>` can be `Utilization`, `Value`, or `AverageValue`.
-
-Let's explain the 4 different `<TYPE-OF-METRIC>` values!
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## `Resource`
-
-Use "classic" metrics served by `metrics-server` (`cpu` and `memory`).
-
-```yaml
-  - type: Resource
-    resource:
-      name: cpu
-      target:
-        type: Utilization
-        averageUtilization: 50
-```
-
-Compute average *utilization* (usage/requests) across pods.
-
-It's also possible to specify `Value` or `AverageValue` instead of `Utilization`.
-
-(To scale according to "raw" CPU or memory usage.)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## `Pods`
-
-Use custom metrics. These are still "per-Pod" metrics.
-
-```yaml
-  - type: Pods
-    pods:
-      metric:
-        name: packets-per-second
-      target:
-        type: AverageValue
-        averageValue: 1k
-```
-
-`type:` *must* be `AverageValue`.
-
-(It cannot be `Utilization`, since these can't be used in Pod `requests`.)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## `Object`
-
-Use custom metrics. These metrics are "linked" to any arbitrary resource.
-
-(E.g. a Deployment, Service, Ingress, ...)
-
-```yaml
-  - type: Object
-    object:
-      metric:
-        name: requests-per-second
-      describedObject:
-        apiVersion: networking.k8s.io/v1
-        kind: Ingress
-        name: main-route
-      target:
-        type: AverageValue
-        value: 100
-```
-
-`type:` can be `Value` or `AverageValue` (see next slide for details).
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## `Value` vs `AverageValue`
-
-- `Value`
-
-  - use the value as-is
-
-  - useful to pace a client or producer
-
-  - "target a specific total load on a specific endpoint or queue"
-
-- `AverageValue`
-
-  - divide the value by the number of pods
-
-  - useful to scale a server or consumer
-
-  - "scale our systems to meet a given SLA/SLO"
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## `External`
-
-Use arbitrary metrics. The series to use is specified with a label selector.
-
-```yaml
-  - type: External
-    external:
-      metric:
-        name: queue_messages_ready
-        selector: "queue=worker_tasks"
-      target:
-        type: AverageValue
-        averageValue: 30
-```
-
-The `selector` will be passed along when querying the metrics API.
-
-Its meaninng is implementation-dependent.
-
-It may or may not correspond to Kubernetes labels.
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## One more thing ...
-
-- We can give a `behavior` set of options
-
-- Indicates:
-
-  - how much to scale up/down in a single step
-
-  - a *stabilization window* to avoid hysteresis effects
-
-- The default stabilization window is 15 seconds for `scaleUp`
-
-  (we might want to change that!)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-Putting togeher [k8s/hpa-v2-pa-httplat.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/hpa-v2-pa-httplat.yaml):
-
-.small[
-```yaml
-kind: HorizontalPodAutoscaler
-apiVersion: autoscaling/v2beta2
-metadata:
-  name: rng
-spec:
-  scaleTargetRef:
-    apiVersion: apps/v1
-    kind: Deployment
-    name: rng
-  minReplicas: 1
-  maxReplicas: 20
-  behavior:
-    scaleUp:
-        stabilizationWindowSeconds: 60
-    scaleDown:
-        stabilizationWindowSeconds: 180
-  metrics:
-  - type: Object
-    object:
-      describedObject:
-        apiVersion: v1
-        kind: Service
-        name: httplat
-      metric:
-        name: httplat_latency_seconds
-      target:
-        type: Value
-        value: 0.1
-
-
-```
-]
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Creating the autoscaling policy
-
-- We will register the policy
-
-- Of course, it won't quite work yet (we're missing the *Prometheus adapter*)
-
-.lab[
-
-- Create the HorizontalPodAutoscaler:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/hpa-v2-pa-httplat.yaml
-  ```
-
-- Check the logs of the `controller-manager`:
-  ```bash
-  stern --namespace=kube-system --tail=10 controller-manager
-  ```
-
-]
-
-After a little while we should see messages like this:
-```
-no custom metrics API (custom.metrics.k8s.io) registered
-```
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## `custom.metrics.k8s.io`
-
-- The HorizontalPodAutoscaler will get the metrics *from the Kubernetes API itself*
-
-- In our specific case, it will access a resource like this one:
-  .small[
-  ```
-  /apis/custom.metrics.k8s.io/v1beta1/namespaces/customscaling/services/httplat/httplat_latency_seconds
-  ```
-  ]
-
-- By default, the Kubernetes API server doesn't implement `custom.metrics.k8s.io`
-
-  (we can have a look at `kubectl get apiservices`)
-
-- We need to:
-
-  - start an API service implementing this API group
-
-  - register it with our API server
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## The Prometheus adapter
-
-- The Prometheus adapter is an open source project:
-
-  https://github.com/DirectXMan12/k8s-prometheus-adapter
-
-- It's a Kubernetes API service implementing API group `custom.metrics.k8s.io`
-
-- It maps the requests it receives to Prometheus metrics
-
-- Exactly what we need!
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Deploying the Prometheus adapter
-
-- There is ~~an app~~ a Helm chart for that
-
-.lab[
-
-- Install the Prometheus adapter:
-  ```bash
-    helm upgrade --install prometheus-adapter prometheus-adapter \
-      --repo https://prometheus-community.github.io/helm-charts \
-      --namespace=prometheus-adapter --create-namespace \
-      --set prometheus.url=http://prometheus-server.prometheus.svc \
-      --set prometheus.port=80
-  ```
-
-]
-
-- It comes with some default mappings
-
-- But we will need to add `httplat` to these mappings
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Configuring the Prometheus adapter
-
-- The Prometheus adapter can be configured/customized through a ConfigMap
-
-- We are going to edit that ConfigMap, then restart the adapter
-
-- We need to add a rule that will say:
-
-  - all the metrics series named `httplat_latency_seconds_sum` ...
-
-  - ... belong to *Services* ...
-
-  - ... the name of the Service and its Namespace are indicated by the `kubernetes_name` and `kubernetes_namespace` Prometheus tags respectively ...
-
-  - ... and the exact value to use should be the following PromQL expression
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## The mapping rule
-
-Here is the rule that we need to add to the configuration:
-
-```yaml
-    - seriesQuery: 'httplat_latency_seconds_sum{namespace!="",service!=""}'
-      resources:
-        overrides:
-          namespace:
-            resource: namespace
-          service:
-            resource: service
-      name:
-        matches: "httplat_latency_seconds_sum"
-        as: "httplat_latency_seconds"
-      metricsQuery: |
-        rate(httplat_latency_seconds_sum{<<.LabelMatchers>>}[2m])/rate(httplat_latency_seconds_count{<<.LabelMatchers>>}[2m])
-```
-
-(I built it following the [walkthrough](https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/master/docs/config-walkthrough.md
-) in the Prometheus adapter documentation.)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Editing the adapter's configuration
-
-.lab[
-
-- Edit the adapter's ConfigMap:
-  ```bash
-  kubectl edit configmap prometheus-adapter --namespace=prometheus-adapter
-  ```
-
-- Add the new rule in the `rules` section, at the end of the configuration file
-
-- Save, quit
-
-- Restart the Prometheus adapter:
-  ```bash
-  kubectl rollout restart deployment --namespace=prometheus-adapter prometheus-adapter
-  ```
-
-]
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Witness the marvel of custom autoscaling
-
-(Sort of)
-
-- After a short while, the `rng` Deployment will scale up
-
-- It should scale up until the latency drops below 100ms
-
-  (and continue to scale up a little bit more after that)
-
-- Then, since the latency will be well below 100ms, it will scale down
-
-- ... and back up again, etc.
-
-(See pictures on next slides!)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-class: pic
-
-![Latency over time](images/hpa-v2-pa-latency.png)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-class: pic
-
-![Number of pods over time](images/hpa-v2-pa-pods.png)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## What's going on?
-
-- The autoscaler's information is slightly out of date
-
-  (not by much; probably between 1 and 2 minute)
-
-- It's enough to cause the oscillations to happen
-
-- One possible fix is to tell the autoscaler to wait a bit after each action
-
-- It will reduce oscillations, but will also slow down its reaction time
-
-  (and therefore, how fast it reacts to a peak of traffic)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## What's going on? Take 2
-
-- As soon as the measured latency is *significantly* below our target (100ms) ...
-
-  the autoscaler tries to scale down
-
-- If the latency is measured at 20ms ...
-
-  the autoscaler will try to *divide the number of pods by five!*
-
-- One possible solution: apply a formula to the measured latency,
-  so that values between e.g. 10 and 100ms get very close to 100ms.
-
-- Another solution: instead of targetting for a specific latency,
-  target a 95th percentile latency or something similar, using
-  a more advanced PromQL expression (and leveraging the fact that
-  we have histograms instead of raw values).
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Troubleshooting
-
-Check that the adapter registered itself correctly:
-```bash
-kubectl get apiservices | grep metrics
-```
-
-Check that the adapter correctly serves metrics:
-```bash
-kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
-```
-
-Check that our `httplat` metrics are available:
-```bash
-kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1\
-/namespaces/customscaling/services/httplat/httplat_latency_seconds
-```
-
-Also check the logs of the `prometheus-adapter` and the `kube-controller-manager`.
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Useful links
-
-- [Horizontal Pod Autoscaler walkthrough](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) in the Kubernetes documentation
-
-- [Autoscaling design proposal](https://github.com/kubernetes/community/tree/master/contributors/design-proposals/autoscaling)
-
-- [Kubernetes custom metrics API alternative implementations](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md)
-
-- [Prometheus adapter configuration walkthrough](https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/master/docs/config-walkthrough.md)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-## Discussion
-
-- This system works great if we have a single, centralized metrics system
-
-  (and the corresponding "adapter" to expose these metrics through the Kubernetes API)
-
-- If we have metrics in multiple places, we must aggregate them
-
-  (good news: Prometheus has exporters for almost everything!)
-
-- It is complex and has a steep learning curve
-
-- Another approach is [KEDA](https://keda.sh/)
-
-???
-
-:EN:- Autoscaling with custom metrics
-:FR:- Suivi de charge avancé (HPAv2)
-
-.debug[[k8s/hpa-v2.md](""/tree/main/slides/k8s/hpa-v2.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/containers-by-the-water.jpg)]
-
----
-
-name: toc-designing-an-operator
-class: title
-
- Designing an operator
-
-.nav[
-[Previous part](#toc-scaling-with-custom-metrics)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-writing-a-tiny-operator)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Designing an operator
-
-- Once we understand CRDs and operators, it's tempting to use them everywhere
-
-- Yes, we can do (almost) everything with operators ...
-
-- ... But *should we?*
-
-- Very often, the answer is **“no!”**
-
-- Operators are powerful, but significantly more complex than other solutions
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## When should we (not) use operators?
-
-- Operators are great if our app needs to react to cluster events
-
-  (nodes or pods going down, and requiring extensive reconfiguration)
-
-- Operators *might* be helpful to encapsulate complexity
-
-  (manipulate one single custom resource for an entire stack)
-
-- Operators are probably overkill if a Helm chart would suffice
-
-- That being said, if we really want to write an operator ...
-
-  Read on!
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## What does it take to write an operator?
-
-- Writing a quick-and-dirty operator, or a POC/MVP, is easy
-
-- Writing a robust operator is hard
-
-- We will describe the general idea
-
-- We will identify some of the associated challenges
-
-- We will list a few tools that can help us
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Top-down vs. bottom-up
-
-- Both approaches are possible
-
-- Let's see what they entail, and their respective pros and cons
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Top-down approach
-
-- Start with high-level design (see next slide)
-
-- Pros:
-
-  - can yield cleaner design that will be more robust
-
-- Cons:
-
-  - must be able to anticipate all the events that might happen
-
-  - design will be better only to the extent of what we anticipated
-
-  - hard to anticipate if we don't have production experience
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## High-level design
-
-- What are we solving?
-
-  (e.g.: geographic databases backed by PostGIS with Redis caches)
-
-- What are our use-cases, stories?
-
-  (e.g.: adding/resizing caches and read replicas; load balancing queries)
-
-- What kind of outage do we want to address?
-
-  (e.g.: loss of individual node, pod, volume)
-
-- What are our *non-features*, the things we don't want to address?
-
-  (e.g.: loss of datacenter/zone; differentiating between read and write queries;
-  <br/>
-  cache invalidation; upgrading to newer major versions of Redis, PostGIS, PostgreSQL)
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Low-level design
-
-- What Custom Resource Definitions do we need?
-
-  (one, many?)
-
-- How will we store configuration information?
-
-  (part of the CRD spec fields, annotations, other?)
-
-- Do we need to store state? If so, where?
-
-  - state that is small and doesn't change much can be stored via the Kubernetes API
-    <br/>
-    (e.g.: leader information, configuration, credentials)
-
-  - things that are big and/or change a lot should go elsewhere
-    <br/>
-    (e.g.: metrics, bigger configuration file like GeoIP)
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-class: extra-details
-
-## What can we store via the Kubernetes API?
-
-- The API server stores most Kubernetes resources in etcd
-
-- Etcd is designed for reliability, not for performance
-
-- If our storage needs exceed what etcd can offer, we need to use something else:
-
-  - either directly
-
-  - or by extending the API server
-    <br/>(for instance by using the aggregation layer, like [metrics server](https://github.com/kubernetes-incubator/metrics-server) does)
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Bottom-up approach
-
-- Start with existing Kubernetes resources (Deployment, Stateful Set...)
-
-- Run the system in production
-
-- Add scripts, automation, to facilitate day-to-day operations
-
-- Turn the scripts into an operator
-
-- Pros: simpler to get started; reflects actual use-cases
-
-- Cons: can result in convoluted designs requiring extensive refactor
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## General idea
-
-- Our operator will watch its CRDs *and associated resources*
-
-- Drawing state diagrams and finite state automata helps a lot
-
-- It's OK if some transitions lead to a big catch-all "human intervention"
-
-- Over time, we will learn about new failure modes and add to these diagrams
-
-- It's OK to start with CRD creation / deletion and prevent any modification
-
-  (that's the easy POC/MVP we were talking about)
-
-- *Presentation* and *validation* will help our users
-
-  (more on that later)
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Challenges
-
-- Reacting to infrastructure disruption can seem hard at first
-
-- Kubernetes gives us a lot of primitives to help:
-
-  - Pods and Persistent Volumes will *eventually* recover
-
-  - Stateful Sets give us easy ways to "add N copies" of a thing
-
-- The real challenges come with configuration changes
-
-  (i.e., what to do when our users update our CRDs)
-
-- Keep in mind that [some] of the [largest] cloud [outages] haven't been caused by [natural catastrophes], or even code bugs, but by configuration changes
-
-[some]: https://www.datacenterdynamics.com/news/gcp-outage-mainone-leaked-google-cloudflare-ip-addresses-china-telecom/
-[largest]: https://aws.amazon.com/message/41926/
-[outages]: https://aws.amazon.com/message/65648/
-[natural catastrophes]: https://www.datacenterknowledge.com/amazon/aws-says-it-s-never-seen-whole-data-center-go-down
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Configuration changes
-
-- It is helpful to analyze and understand how Kubernetes controllers work:
-
-  - watch resource for modifications
-
-  - compare desired state (CRD) and current state
-
-  - issue actions to converge state
-
-- Configuration changes will probably require *another* state diagram or FSA
-
-- Again, it's OK to have transitions labeled as "unsupported"
-
-  (i.e. reject some modifications because we can't execute them)
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Tools
-
-- CoreOS / RedHat Operator Framework
-
-  [GitHub](https://github.com/operator-framework)
-  |
-  [Blog](https://developers.redhat.com/blog/2018/12/18/introduction-to-the-kubernetes-operator-framework/)
-  |
-  [Intro talk](https://www.youtube.com/watch?v=8k_ayO1VRXE)
-  |
-  [Deep dive talk](https://www.youtube.com/watch?v=fu7ecA2rXmc)
-  |
-  [Simple example](https://medium.com/faun/writing-your-first-kubernetes-operator-8f3df4453234)
-
-- Kubernetes Operator Pythonic Framework (KOPF)
-
-  [GitHub](https://github.com/nolar/kopf)
-  |
-  [Docs](https://kopf.readthedocs.io/)
-  |
-  [Step-by-step tutorial](https://kopf.readthedocs.io/en/stable/walkthrough/problem/)
-
-- Mesosphere Kubernetes Universal Declarative Operator (KUDO)
-
-  [GitHub](https://github.com/kudobuilder/kudo)
-  |
-  [Blog](https://mesosphere.com/blog/announcing-maestro-a-declarative-no-code-approach-to-kubernetes-day-2-operators/)
-  |
-  [Docs](https://kudo.dev/)
-  |
-  [Zookeeper example](https://github.com/kudobuilder/frameworks/tree/master/repo/stable/zookeeper)
-
-- Kubebuilder (Go, very close to the Kubernetes API codebase)
-
-  [GitHub](https://github.com/kubernetes-sigs/kubebuilder)
-  |
-  [Book](https://book.kubebuilder.io/)
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Validation
-
-- By default, a CRD is "free form"
-
-  (we can put pretty much anything we want in it)
-
-- When creating a CRD, we can provide an OpenAPI v3 schema
-  ([Example](https://github.com/amaizfinance/redis-operator/blob/master/deploy/crds/k8s_v1alpha1_redis_crd.yaml#L34))
-
-- The API server will then validate resources created/edited with this schema
-
-- If we need a stronger validation, we can use a Validating Admission Webhook:
-
-  - run an [admission webhook server](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server) to receive validation requests
-
-  - register the webhook by creating a [ValidatingWebhookConfiguration](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#configure-admission-webhooks-on-the-fly)
-
-  - each time the API server receives a request matching the configuration,
-    <br/>the request is sent to our server for validation
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Presentation
-
-- By default, `kubectl get mycustomresource` won't display much information
-
-  (just the name and age of each resource)
-
-- When creating a CRD, we can specify additional columns to print
-  ([Example](https://github.com/amaizfinance/redis-operator/blob/master/deploy/crds/k8s_v1alpha1_redis_crd.yaml#L6),
-  [Docs](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#additional-printer-columns))
-
-- By default, `kubectl describe mycustomresource` will also be generic
-
-- `kubectl describe` can show events related to our custom resources
-
-  (for that, we need to create Event resources, and fill the `involvedObject` field)
-
-- For scalable resources, we can define a `scale` sub-resource
-
-- This will enable the use of `kubectl scale` and other scaling-related operations
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## About scaling
-
-- It is possible to use the HPA (Horizontal Pod Autoscaler) with CRDs
-
-- But it is not always desirable
-
-- The HPA works very well for homogenous, stateless workloads
-
-- For other workloads, your mileage may vary
-
-- Some systems can scale across multiple dimensions
-
-  (for instance: increase number of replicas, or number of shards?)
-
-- If autoscaling is desired, the operator will have to take complex decisions
-
-  (example: Zalando's Elasticsearch Operator ([Video](https://www.youtube.com/watch?v=lprE0J0kAq0)))
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Versioning
-
-- As our operator evolves over time, we may have to change the CRD
-
-  (add, remove, change fields)
-
-- Like every other resource in Kubernetes, [custom resources are versioned](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/
-)
-
-- When creating a CRD, we need to specify a *list* of versions
-
-- Versions can be marked as `stored` and/or `served`
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Stored version
-
-- Exactly one version has to be marked as the `stored` version
-
-- As the name implies, it is the one that will be stored in etcd
-
-- Resources in storage are never converted automatically
-
-  (we need to read and re-write them ourselves)
-
-- Yes, this means that we can have different versions in etcd at any time
-
-- Our code needs to handle all the versions that still exist in storage
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Served versions
-
-- By default, the Kubernetes API will serve resources "as-is"
-
-  (using their stored version)
-
-- It will assume that all versions are compatible storage-wise
-
-  (i.e. that the spec and fields are compatible between versions)
-
-- We can provide [conversion webhooks](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion) to "translate" requests
-
-  (the alternative is to upgrade all stored resources and stop serving old versions)
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Operator reliability
-
-- Remember that the operator itself must be resilient
-
-  (e.g.: the node running it can fail)
-
-- Our operator must be able to restart and recover gracefully
-
-- Do not store state locally
-
-  (unless we can reconstruct that state when we restart)
-
-- As indicated earlier, we can use the Kubernetes API to store data:
-
-  - in the custom resources themselves
-
-  - in other resources' annotations
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-## Beyond CRDs
-
-- CRDs cannot use custom storage (e.g. for time series data)
-
-- CRDs cannot support arbitrary subresources (like logs or exec for Pods)
-
-- CRDs cannot support protobuf (for faster, more efficient communication)
-
-- If we need these things, we can use the [aggregation layer](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) instead
-
-- The aggregation layer proxies all requests below a specific path to another server
-
-  (this is used e.g. by the metrics server)
-
-- [This documentation page](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources) compares the features of CRDs and API aggregation
-
-???
-
-:EN:- Guidelines to design our own operators
-:FR:- Comment concevoir nos propres opérateurs
-
-.debug[[k8s/operators-design.md](""/tree/main/slides/k8s/operators-design.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/distillery-containers.jpg)]
-
----
-
-name: toc-writing-a-tiny-operator
-class: title
-
- Writing a tiny operator
-
-.nav[
-[Previous part](#toc-designing-an-operator)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-kubebuilder)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Writing a tiny operator
-
-- Let's look at a simple operator
-
-- It does have:
-
-  - a control loop
-  - resource lifecycle management
-  - basic logging
-
-- It doesn't have:
-
-  - CRDs (and therefore, resource versioning, conversion webhooks...)
-  - advanced observability (metrics, Kubernetes Events)
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-## Use case
-
-*When I push code to my source control system, I want that code
-to be built into a container image, and that image to be deployed
-in a staging environment. I want each branch/tag/commit (depending
-on my needs) to be deployed into its specific Kubernetes Namespace.*
-
-- The last part requires the CI/CD pipeline to manage Namespaces
-
-- ...And permissions in these Namespaces
-
-- This requires elevated privileges for the CI/CD pipeline
-
-  (read: `cluster-admin`)
-
-- If the CI/CD pipeline is compromised, this can lead to cluster compromise
-
-- This can be a concern if the CI/CD pipeline is part of the repository
-
-  (which is the default modus operandi with GitHub, GitLab, Bitbucket...)
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-## Proposed solution
-
-- On-demand creation of Namespaces
-
-- Creation is triggered by creating a ConfigMap in a dedicated Namespace
-
-- Namespaces are set up with basic permissions
-
-- Credentials are generated for each Namespace
-
-- Credentials only give access to their Namespace
-
-- Credentials are exposed back to the dedicated configuration Namespace
-
-- Operator implemented as a shell script
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-## An operator in shell... Really?
-
-- About 150 lines of code
-
-  (including comments + white space)
-
-- Performance doesn't matter
-
-  - operator work will be a tiny fraction of CI/CD pipeline work
-
-  - uses *watch* semantics to minimize control plane load
-
-- Easy to understand, easy to audit, easy to tweak
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-## Show me the code!
-
-- GitHub repository and documentation:
-
-  https://github.com/jpetazzo/nsplease
-
-- Operator source code:
-
-  https://github.com/jpetazzo/nsplease/blob/main/nsplease.sh
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-## Main loop
-
-```bash
-  info "Waiting for ConfigMap events in $REQUESTS_NAMESPACE..."
-  kubectl --namespace $REQUESTS_NAMESPACE get configmaps \
-    --watch --output-watch-events -o json \
-    | jq --unbuffered --raw-output '[.type,.object.metadata.name] | @tsv' \
-    | while read TYPE NAMESPACE; do
-
-      debug "Got event: $TYPE $NAMESPACE"
-```
-
-- `--watch` to avoid active-polling the control plane
-
-- `--output-watch-events` to disregard e.g. resource deletion, edition
-
-- `jq` to process JSON easily
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-## Resource ownership
-
-- Check out the `kubectl patch` commands
-
-- The created Namespace "owns" the corresponding ConfigMap and Secret
-
-- This means that deleting the Namespace will delete the ConfigMap and Secret
-
-- We don't need to watch for object deletion to clean up
-
-- Clean up will we done automatically even if operator is not running
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-## Why no CRD?
-
-- It's easier to create a ConfigMap
-
-  (e.g. `kubectl create configmap --from-literal=` one-liner)
-
-- We don't need the features of CRDs
-
-  (schemas, printer columns, versioning...)
-
-- “This CRD could have been a ConfigMap!”
-
-  (this doesn't mean *all* CRDs could be ConfigMaps, of course)
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-## Discussion
-
-- A lot of simple, yet efficient logic, can be implemented in shell scripts
-
-- These can be used to prototype more complex operators
-
-- Not all use-cases require CRDs
-
-  (keep in mind that correct CRDs are *a lot* of work!)
-
-- If the algorithms are correct, shell performance won't matter at all
-
-  (but it will be difficult to keep a resource cache in shell)
-
-- Improvement idea: this operator could generate *events*
-
-  (visible with `kubectl get events` and `kubectl describe`)
-
-???
-
-:EN:- How to write a simple operator with shell scripts
-:FR:- Comment écrire un opérateur simple en shell script
-
-.debug[[k8s/operators-example.md](""/tree/main/slides/k8s/operators-example.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/lots-of-containers.jpg)]
-
----
-
-name: toc-kubebuilder
-class: title
-
- Kubebuilder
-
-.nav[
-[Previous part](#toc-writing-a-tiny-operator)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-events)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Kubebuilder
-
-- Writing a quick and dirty operator is (relatively) easy
-
-- Doing it right, however ...
-
---
-
-- We need:
-
-  - proper CRD with schema validation
-
-  - controller performing a reconcilation loop
-
-  - manage errors, retries, dependencies between resources
-
-  - maybe webhooks for admission and/or conversion
-
-😱
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Frameworks
-
-- There are a few frameworks available out there:
-
-  - [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder)
-    ([book](https://book.kubebuilder.io/)):
-    go-centric, very close to Kubernetes' core types
-
-  - [operator-framework](https://operatorframework.io/):
-    higher level; also supports Ansible and Helm
-
-  - [KUDO](https://kudo.dev/):
-    declarative operators written in YAML
-
-  - [KOPF](https://kopf.readthedocs.io/en/latest/):
-    operators in Python
-
-  - ...
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Kubebuilder workflow
-
-- Kubebuilder will create scaffolding for us
-
-  (Go stubs for types and controllers)
-
-- Then we edit these types and controllers files
-
-- Kubebuilder generates CRD manifests from our type definitions
-
-  (and regenerates the manifests whenver we update the types)
-
-- It also gives us tools to quickly run the controller against a cluster
-
-  (not necessarily *on* the cluster)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Our objective
-
-- We're going to implement a *useless machine*
-
-  [basic example](https://www.youtube.com/watch?v=aqAUmgE3WyM)
-  |
-  [playful example](https://www.youtube.com/watch?v=kproPsch7i0)
-  |
-  [advanced example](https://www.youtube.com/watch?v=Nqk_nWAjBus)
-  |
-  [another advanced example](https://www.youtube.com/watch?v=eLtUB8ncEnA)
-
-- A machine manifest will look like this:
-  ```yaml
-    kind: Machine
-    apiVersion: useless.container.training/v1alpha1
-    metadata:
-      name: machine-1
-    spec:
-      # Our useless operator will change that to "down"
-      switchPosition: up
-  ```
-
-- Each time we change the `switchPosition`, the operator will move it back to `down`
-
-(This is inspired by the
-[uselessoperator](https://github.com/tilt-dev/uselessoperator)
-written by
-[V Körbes](https://twitter.com/veekorbes).
-Highly recommend!💯)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-class: extra-details
-
-## Local vs remote
-
-- Building Go code can be a little bit slow on our modest lab VMs
-
-- It will typically be *much* faster on a local machine
-
-- All the demos and labs in this section will run fine either way!
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-
-## Preparation
-
-- Install Go
-
-  (on our VMs: `sudo snap install go --classic`)
-
-- Install kubebuilder
-
-  ([get a release](https://github.com/kubernetes-sigs/kubebuilder/releases/), untar, move the `kubebuilder` binary to the `$PATH`)
-
-- Initialize our workspace:
-  ```bash
-  mkdir useless
-  cd useless
-  go mod init container.training/useless
-  kubebuilder init --domain container.training
-  ```
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Create scaffolding
-
-- Create a type and corresponding controller:
-  ```bash
-  kubebuilder create api --group useless --version v1alpha1 --kind Machine
-  ```
-
-- Answer `y` to both questions
-
-- Then we need to edit the type that just got created!
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Edit type
-
-Edit `api/v1alpha1/machine_types.go`.
-
-Add the `switchPosition` field in the `spec` structure:
-
-```go
-// MachineSpec defines the desired state of Machine
-type MachineSpec struct {
-	// Position of the switch on the machine, for instance up or down.
-	SwitchPosition string ``json:"switchPosition,omitempty"``
-}
-```
-
-⚠️ The backticks above should be simple backticks, not double-backticks. Sorry.
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Go markers
-
-We can use Go *marker comments* to give `controller-gen` extra details about how to handle our type, for instance:
-
-```go
-//+kubebuilder:object:root=true
-```
-
-→ top-level type exposed through API (as opposed to "member field of another type")
-
-```go
-//+kubebuilder:subresource:status
-```
-
-→ automatically generate a `status` subresource (very common with many types)
-
-```go
-//+kubebuilder:printcolumn:JSONPath=".spec.switchPosition",name=Position,type=string
-```
-
-(See
-[marker syntax](https://book.kubebuilder.io/reference/markers.html),
-[CRD generation](https://book.kubebuilder.io/reference/markers/crd.html),
-[CRD validation](https://book.kubebuilder.io/reference/markers/crd-validation.html),
-[Object/DeepCopy](https://master.book.kubebuilder.io/reference/markers/object.html)
-)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Installing the CRD
-
-After making these changes, we can run `make install`.
-
-This will build the Go code, but also:
-
-- generate the CRD manifest
-
-- and apply the manifest to the cluster
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Creating a machine
-
-Edit `config/samples/useless_v1alpha1_machine.yaml`:
-
-```yaml
-kind: Machine
-apiVersion: useless.container.training/v1alpha1
-metadata:
-  labels: # ...
-  name: machine-1
-spec:
-  # Our useless operator will change that to "down"
-  switchPosition: up
-```
-
-... and apply it to the cluster.
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Designing the controller
-
-- Our controller needs to:
-
-  - notice when a `switchPosition` is not `down`
-
-  - move it to `down` when that happens
-
-- Later, we can add fancy improvements (wait a bit before moving it, etc.)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Reconciler logic
-
-- Kubebuilder will call our *reconciler* when necessary
-
-- When necessary = when changes happen ...
-
-  - on our resource
-
-  - or resources that it *watches* (related resources)
-
-- After "doing stuff", the reconciler can return ...
-
-  - `ctrl.Result{},nil` = all is good
-
-  - `ctrl.Result{Requeue...},nil` = all is good, but call us back in a bit
-
-  - `ctrl.Result{},err` = something's wrong, try again later
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Loading an object
-
-Open `controllers/machine_controller.go`.
-
-Add that code in the `Reconcile` method, at the `TODO(user)` location:
-
-```go
-var machine uselessv1alpha1.Machine
-logger := log.FromContext(ctx)
-
-if err := r.Get(ctx, req.NamespacedName, &machine); err != nil {
-  logger.Info("error getting object")
-  return ctrl.Result{}, err
-}
-
-logger.Info(
-  "reconciling",
-  "machine", req.NamespacedName,
-  "switchPosition", machine.Spec.SwitchPosition,
-)
-```
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Running the controller
-
-Our controller is not done yet, but let's try what we have right now!
-
-This will compile the controller and run it:
-```
-make run
-```
-
-Then:
-
-- create a machine
-- change the `switchPosition`
-- delete the machine
-
---
-
-We get a bunch of errors and go stack traces! 🤔
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## `IgnoreNotFound`
-
-When we are called for object deletion, the object has *already* been deleted.
-
-(Unless we're using finalizers, but that's another story.)
-
-When we return `err`, the controller will try to access the object ...
-
-... We need to tell it to *not* do that.
-
-Don't just return `err`, but instead, wrap it around `client.IgnoreNotFound`:
-
-```go
-return ctrl.Result{}, client.IgnoreNotFound(err)
-```
-
-Update the code, `make run` again, create/change/delete again.
-
---
-
-🎉
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Updating the machine
-
-Let's try to update the machine like this:
-
-```go
-if machine.Spec.SwitchPosition != "down" {
-	machine.Spec.SwitchPosition = "down"
-	if err := r.Update(ctx, &machine); err != nil {
-		logger.Info("error updating switch position")
-		return ctrl.Result{}, client.IgnoreNotFound(err)
-	}
-}
-```
-
-Again - update, `make run`, test.
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Spec vs Status
-
-- Spec = desired state
-
-- Status = observed state
-
-- If Status is lost, the controller should be able to reconstruct it
-
-  (maybe with degraded behavior in the meantime)
-
-- Status will almost always be a sub-resource, so that it can be updated separately
-
-  (and potentially with different permissions)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-class: extra-details
-
-## Spec vs Status (in depth)
-
-- The `/status` subresource is handled differently by the API server
-
-- Updates to `/status` don't alter the rest of the object
-
-- Conversely, updates to the object ignore changes in the status
-
-(See [the docs](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) for the fine print.)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## "Improving" our controller
-
-- We want to wait a few seconds before flipping the switch
-
-- Let's add the following line of code to the controller:
-  ```go
-  time.Sleep(5 * time.Second)
-  ```
-
-- `make run`, create a few machines, observe what happens
-
---
-
-💡 Concurrency!
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Controller logic
-
-- Our controller shouldn't block (think "event loop")
-
-- There is a queue of objects that need to be reconciled
-
-- We can ask to be put back on the queue for later processing
-
-- When we need to block (wait for something to happen), two options:
-
-  - ask for a *requeue* ("call me back later")
-
-  - yield because we know we will be notified by another resource
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## To requeue ...
-
-`return ctrl.Result{RequeueAfter: 1 * time.Second}, nil`
-
-- That means: "try again in 1 second, and I will check if progress was made"
-
-- This *does not* guarantee that we will be called exactly 1 second later:
-
-  - we might be called before (if other changes happen)
-
-  - we might be called after (if the controller is busy with other objects)
-
-- If we are waiting for another Kubernetes resource to change, there is a better way
-
-  (explained on next slide)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## ... or not to requeue
-
-`return ctrl.Result{}, nil`
-
-- That means: "we're done here!"
-
-- This is also what we should use if we are waiting for another resource
-
-  (e.g. a LoadBalancer to be provisioned, a Pod to be ready...)
-
-- In that case, we will need to set a *watch* (more on that later)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Keeping track of state
-
-- If we simply requeue the object to examine it 1 second later...
-
-- ...We'll keep examining/requeuing it forever!
-
-- We need to "remember" that we saw it (and when)
-
-- Option 1: keep state in controller
-
-  (e.g. an internal `map`)
-
-- Option 2: keep state in the object
-
-  (typically in its status field)
-
-- Tradeoffs: concurrency / failover / control plane overhead...
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## "Improving" our controller, take 2
-
-Let's store in the machine status the moment when we saw it:
-
-```go
-type MachineStatus struct {
-	// Time at which the machine was noticed by our controller.
-	SeenAt *metav1.Time ``json:"seenAt,omitempty"``
-}
-```
-
-⚠️ The backticks above should be simple backticks, not double-backticks. Sorry.
-
-Note: `date` fields don't display timestamps in the future.
-
-(That's why for this example it's simpler to use `seenAt` rather than `changeAt`.)
-
-And for better visibility, add this along with the other `printcolumn` comments:
-
-```go
-//+kubebuilder:printcolumn:JSONPath=".status.seenAt",name=Seen,type=date
-```
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Set `seenAt`
-
-Let's add the following block in our reconciler:
-
-```go
-if machine.Status.SeenAt == nil {
-	now := metav1.Now()
-	machine.Status.SeenAt = &now
-	if err := r.Status().Update(ctx, &machine); err != nil {
-		logger.Info("error updating status.seenAt")
-		return ctrl.Result{}, client.IgnoreNotFound(err)
-	}
-	return ctrl.Result{RequeueAfter: 5 * time.Second}, nil
-}
-```
-
-(If needed, add `metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"` to our imports.)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Use `seenAt`
-
-Our switch-position-changing code can now become:
-
-```go
-if machine.Spec.SwitchPosition != "down" {
-	now := metav1.Now()
-	changeAt := machine.Status.SeenAt.Time.Add(5 * time.Second)
-	if now.Time.After(changeAt) {
-		machine.Spec.SwitchPosition = "down"
-    machine.Status.SeenAt = nil
-		if err := r.Update(ctx, &machine); err != nil {
-			logger.Info("error updating switch position")
-			return ctrl.Result{}, client.IgnoreNotFound(err)
-		}
-	}
-}
-```
-
-`make run`, create a few machines, tweak their switches.
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Owner and dependents
-
-- Next, let's see how to have relationships between objects!
-
-- We will now have two kinds of objects: machines, and switches
-
-- Machines will store the number of switches in their spec
-
-- Machines should have *at least* one switch, possibly *multiple ones*
-
-- Our controller will automatically create switches if needed
-
-  (a bit like the ReplicaSet controller automatically creates Pods)
-
-- The switches will be tied to their machine through a label
-
-  (let's pick `machine=name-of-the-machine`)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Switch state
-
-- The position of a switch will now be stored in the switch
-
-  (not in the machine like in the first scenario)
-
-- The machine will also expose the combined state of the switches
-
-  (through its status)
-
-- The machine's status will be automatically updated by the controller
-
-  (each time a switch is added/changed/removed)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Switches and machines
-
-```
-[jp@hex ~]$ kubectl get machines
-NAME            SWITCHES   POSITIONS
-machine-cz2vl   3          ddd
-machine-vf4xk   1          d
-
-[jp@hex ~]$ kubectl get switches --show-labels
-NAME           POSITION   SEEN   LABELS
-switch-6wmjw   down              machine=machine-cz2vl
-switch-b8csg   down              machine=machine-cz2vl
-switch-fl8dq   down              machine=machine-cz2vl
-switch-rc59l   down              machine=machine-vf4xk
-```
-
-(The field `status.positions` shows the first letter of the `position` of each switch.)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Tasks
-
-1. Create the new resource type (but don't create a controller)
-
-2. Update `machine_types.go` and `switch_types.go`
-
-3. Implement logic to display machine status (status of its switches)
-
-4. Implement logic to automatically create switches
-
-5. Implement logic to flip all switches down immediately
-
-6. Then tweak it so that a given machine doesn't flip more than one switch every 5 seconds
-
-*See next slides for detailed steps!*
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Creating the new type
-
-```bash
-kubebuilder create api --group useless --version v1alpha1 --kind Switch
-```
-
-Note: this time, only create a new custom resource; not a new controller.
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Updating our types
-
-- Move the "switch position" and "seen at" to the new `Switch` type
-
-- Update the `Machine` type to have:
-
-  - `spec.switches` (Go type: `int`, JSON type: `integer`)
-
-  - `status.positions` of type `string`
-
-- Bonus points for adding [CRD Validation](https://book.kubebuilder.io/reference/markers/crd-validation.html) to the numbers of switches!
-
-- Then install the new CRDs with `make install`
-
-- Create a Machine, and a Switch linked to the Machine (by setting the `machine` label)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Listing switches
-
-- Switches are associated to Machines with a label
-
-  (`kubectl label switch switch-xyz machine=machine-xyz`)
-
-- We can retrieve associated switches like this:
-
-  ```go
-  var switches uselessv1alpha1.SwitchList
-
-  if err := r.List(ctx, &switches,
-    client.InNamespace(req.Namespace),
-    client.MatchingLabels{"machine": req.Name},
-    ); err != nil {
-    logger.Error(err, "unable to list switches of the machine")
-    return ctrl.Result{}, client.IgnoreNotFound(err)
-  }
-
-  logger.Info("Found switches", "switches", switches)
-  ```
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Updating status
-
-- Each time we reconcile a Machine, let's update its status:
-
-  ```go
-  status := ""
-  for _, sw := range switches.Items {
-    status += string(sw.Spec.Position[0])
-  }
-  machine.Status.Positions = status
-  if err := r.Status().Update(ctx, &machine); err != nil {
-    ...
-  ```
-
-- Run the controller and check that POSITIONS gets updated
-
-- Add more switches linked to the same machine
-
-- ...The POSITIONS don't get updated, unless we restart the controller
-
-- We'll see later how to fix that!
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Creating objects
-
-We can use the `Create` method to create a new object:
-
-```go
-sw := uselessv1alpha1.Switch{
-	TypeMeta: metav1.TypeMeta{
-		APIVersion: uselessv1alpha1.GroupVersion.String(),
-		Kind:       "Switch",
-	},
-	ObjectMeta: metav1.ObjectMeta{
-		GenerateName: "switch-",
-		Namespace:    machine.Namespace,
-		Labels:       map[string]string{"machine": machine.Name},
-	},
-	Spec: uselessv1alpha1.SwitchSpec{
-		Position: "down",
-	},
-}
-if err := r.Create(ctx, &sw); err != nil { ...
-```
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Create missing switches
-
-- In our reconciler, if a machine doesn't have enough switches, create them!
-
-- Option 1: directly create the number of missing switches
-
-- Option 2: create only one switch (and rely on later requeuing)
-
-- Note: option 2 won't quite work yet, since we haven't set up *watches* yet
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Watches
-
-- Our controller doesn't react when switches are created/updated/deleted
-
-- We need to tell it to watch switches
-
-- We also need to tell it how to map a switch to its machine
-
-  (so that the correct machine gets queued and reconciled when a switch is updated)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Mapping a switch to its machine
-
-Define the following helper function:
-
-```go
-func (r *MachineReconciler) machineOfSwitch(obj client.Object) []ctrl.Request {
-  return []ctrl.Request{
-    ctrl.Request{
-      NamespacedName: types.NamespacedName{
-        Name:      obj.GetLabels()["machine"],
-        Namespace: obj.GetNamespace(),
-      },
-    },
-  }
-}
-```
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Telling the controller to watch switches
-
-Update the `SetupWithManager` method in the controller:
-
-```go
-// SetupWithManager sets up the controller with the Manager.
-func (r *MachineReconciler) SetupWithManager(mgr ctrl.Manager) error {
-  return ctrl.NewControllerManagedBy(mgr).
-    For(&uselessv1alpha1.Machine{}).
-    Owns(&uselessv1alpha1.Switch{}).
-    Watches(
-      &source.Kind{Type: &uselessv1alpha1.Switch{}},
-      handler.EnqueueRequestsFromMapFunc(r.machineOfSwitch),
-    ).
-    Complete(r)
-}
-```
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## ...And a few extra imports
-
-Import the following packages referenced by the previous code:
-
-```go
-"sigs.k8s.io/controller-runtime/pkg/handler"
-"sigs.k8s.io/controller-runtime/pkg/source"
-"k8s.io/apimachinery/pkg/types"
-```
-
-After this, when we update a switch, it should reflect on the machine.
-
-(Try to change switch positions and see the machine status update!)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Flipping switches
-
-- Now re-add logic to flip switches that are not in "down" position
-
-- Re-add logic to wait a few seconds before flipping a switch
-
-- Change the logic to toggle one switch per machine every few seconds
-
-  (i.e. don't change all the switches for a machine; move them one at a time)
-
-- Handle "scale down" of a machine (by deleting extraneous switches)
-
-- Automatically delete switches when a machine is deleted
-
-  (ideally, using ownership information)
-
-- Test corner cases (e.g. changing a switch label)
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Other possible improvements
-
-- Formalize resource ownership
-
-  (by setting `ownerReferences` in the switches)
-
-- This can simplify the watch mechanism a bit
-
-- Allow to define a selector
-
-  (instead of using the hard-coded `machine` label)
-
-- And much more!
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-## Acknowledgements
-
-- Useless Operator, by [V Körbes](https://twitter.com/veekorbes)
-
-  [code](https://github.com/tilt-dev/uselessoperator)
-  |
-  [video (EN)](https://www.youtube.com/watch?v=85dKpsFFju4)
-  |
-  [video (PT)](https://www.youtube.com/watch?v=Vt7Eg4wWNDw)
-
-- Zero To Operator, by [Solly Ross](https://twitter.com/directxman12)
-
-  [code](https://pres.metamagical.dev/kubecon-us-2019/code)
-  |
-  [video](https://www.youtube.com/watch?v=KBTXBUVNF2I)
-  |
-  [slides](https://pres.metamagical.dev/kubecon-us-2019/)
-
-- The [kubebuilder book](https://book.kubebuilder.io/)
-
-???
-
-:EN:- Implementing an operator with kubebuilder
-:FR:- Implémenter un opérateur avec kubebuilder
-
-.debug[[k8s/kubebuilder.md](""/tree/main/slides/k8s/kubebuilder.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/plastic-containers.JPG)]
-
----
-
-name: toc-events
-class: title
-
- Events
-
-.nav[
-[Previous part](#toc-kubebuilder)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-finalizers)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Events
-
-- Kubernetes has an internal structured log of *events*
-
-- These events are ordinary resources:
-
-  - we can view them with `kubectl get events`
-
-  - they can be viewed and created through the Kubernetes API
-
-  - they are stored in Kubernetes default database (e.g. etcd)
-
-- Most components will generate events to let us know what's going on
-
-- Events can be *related* to other resources
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-## Reading events
-
-- `kubectl get events` (or `kubectl get ev`)
-
-- Can use `--watch`
-
-  ⚠️ Looks like `tail -f`, but events aren't necessarily sorted!
-
-- Can use `--all-namespaces`
-
-- Cluster events (e.g. related to nodes) are in the `default` namespace
-
-- Viewing all "non-normal" events:
-  ```bash
-  kubectl get ev -A --field-selector=type!=Normal
-  ```
-
-  (as of Kubernetes 1.19, `type` can be either `Normal` or `Warning`)
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-## Reading events (take 2)
-
-- When we use `kubectl describe` on an object, `kubectl` retrieves the associated events
-
-.lab[
-
-- See the API requests happening when we use `kubectl describe`:
-  ```bash
-  kubectl describe service kubernetes --namespace=default -v6 >/dev/null
-  ```
-
-]
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-## Generating events
-
-- This is rarely (if ever) done manually
-
-  (i.e. by crafting some YAML)
-
-- But controllers (e.g. operators) need this!
-
-- It's not mandatory, but it helps with *operability*
-
-  (e.g. when we `kubectl describe` a CRD, we will see associated events)
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-## ⚠️ Work in progress
-
-- "Events" can be :
-
-  - "old-style" events (in core API group, aka `v1`)
-
-  - "new-style" events (in API group `events.k8s.io`)
-
-- See [KEP 383](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/383-new-event-api-ga-graduation/README.md) in particular this [comparison between old and new APIs](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/383-new-event-api-ga-graduation/README.md#comparison-between-old-and-new-apis)
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-## Experimenting with events
-
-- Let's create an event related to a Node, based on [k8s/event-node.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/event-node.yaml)
-
-.lab[
-
-- Edit `k8s/event-node.yaml`
-
-- Update the `name` and `uid` of the `involvedObject`
-
-- Create the event with `kubectl create -f`
-
-- Look at the Node with `kubectl describe`
-
-]
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-## Experimenting with events
-
-- Let's create an event related to a Pod, based on [k8s/event-pod.yaml](https://github.com/jpetazzo/container.training/tree/master/k8s/event-pod.yaml)
-
-.lab[
-
-- Create a pod
-
-- Edit `k8s/event-pod.yaml`
-
-- Edit the `involvedObject` section (don't forget the `uid`)
-
-- Create the event with `kubectl create -f`
-
-- Look at the Pod with `kubectl describe`
-
-]
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-## Generating events in practice
-
-- In Go, use an `EventRecorder` provided by the `kubernetes/client-go` library
-
-  - [EventRecorder interface](https://github.com/kubernetes/client-go/blob/release-1.19/tools/record/event.go#L87)
-  
-  - [kubebuilder book example](https://book-v1.book.kubebuilder.io/beyond_basics/creating_events.html)
-
-- It will take care of formatting / aggregating events
-
-- To get an idea of what to put in the `reason` field, check [kubelet events](
-https://github.com/kubernetes/kubernetes/blob/release-1.19/pkg/kubelet/events/event.go)
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-## Cluster operator perspective
-
-- Events are kept 1 hour by default
-
-- This can be changed with the `--event-ttl` flag on the API server
-
-- On very busy clusters, events can be kept on a separate etcd cluster
-
-- This is done with the `--etcd-servers-overrides` flag on the API server
-
-- Example:
-  ```
-  --etcd-servers-overrides=/events#http://127.0.0.1:12379
-  ```
-
-???
-
-:EN:- Consuming and generating cluster events
-:FR:- Suivre l'activité du cluster avec les *events*
-
-.debug[[k8s/events.md](""/tree/main/slides/k8s/events.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-1.jpg)]
-
----
-
-name: toc-finalizers
-class: title
-
- Finalizers
-
-.nav[
-[Previous part](#toc-events)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-extra-content)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Finalizers
-
-- Sometimes, we.red[¹] want to prevent a resource from being deleted:
-
-  - perhaps it's "precious" (holds important data)
-
-  - perhaps other resources depend on it (and should be deleted first)
-
-  - perhaps we need to perform some clean up before it's deleted
-
-- *Finalizers* are a way to do that!
-
-.footnote[.red[¹]The "we" in that sentence generally stands for a controller.
-<br/>(We can also use finalizers directly ourselves, but it's not very common.)]
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## Examples
-
-- Prevent deletion of a PersistentVolumeClaim which is used by a Pod
-
-- Prevent deletion of a PersistentVolume which is bound to a PersistentVolumeClaim
-
-- Prevent deletion of a Namespace that still contains objects
-
-- When a LoadBalancer Service is deleted, make sure that the corresponding external resource (e.g. NLB, GLB, etc.) gets deleted.red[¹]
-
-- When a CRD gets deleted, make sure that all the associated resources get deleted.red[²]
-
-.footnote[.red[¹²]Finalizers are not the only solution for these use-cases.]
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## How do they work?
-
-- Each resource can have list of `finalizers` in its `metadata`, e.g.:
-
-  ```yaml
-    kind: PersistentVolumeClaim
-    apiVersion: v1
-    metadata:
-      name: my-pvc
-      annotations: ...
-      finalizers:
-      - kubernetes.io/pvc-protection
-  ```
-
-- If we try to delete an resource that has at least one finalizer:
-
-  - the resource is *not* deleted
-
-  - instead, its `deletionTimestamp` is set to the current time
-
-  - we are merely *marking the resource for deletion*
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## What happens next?
-
-- The controller that added the finalizer is supposed to:
-
-  - watch for resources with a `deletionTimestamp`
-
-  - execute necessary clean-up actions
-
-  - then remove the finalizer
-
-- The resource is deleted once all the finalizers have been removed
-
-  (there is no timeout, so this could take forever)
-
-- Until then, the resource can be used normally
-
-  (but no further finalizer can be *added* to the resource)
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## Finalizers in review
-
-Let's review the examples mentioned earlier.
-
-For each of them, we'll see if there are other (perhaps better) options.
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## Volume finalizer
-
-- Kubernetes applies the following finalizers:
-
-  - `kubernetes.io/pvc-protection` on PersistentVolumeClaims
-
-  - `kubernetes.io/pv-protection` on PersistentVolumes
-
-- This prevents removing them when they are in use
-
-- Implementation detail: the finalizer is present *even when the resource is not in use*
-
-- When the resource is ~~deleted~~ marked for deletion, the controller will check if the finalizer can be removed
-
-  (Perhaps to avoid race conditions?)
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## Namespace finalizer
-
-- Kubernetes applies a finalizer named `kubernetes`
-
-- It prevents removing the namespace if it still contains objects
-
-- *Can we remove the namespace anyway?*
-
-  - remove the finalizer
-
-  - delete the namespace
-
-  - force deletion
-
-- It *seems to works* but, in fact, the objects in the namespace still exist
-
-  (and they will re-appear if we re-create the namespace)
-
-See [this blog post](https://www.openshift.com/blog/the-hidden-dangers-of-terminating-namespaces) for more details about this.
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## LoadBalancer finalizer
-
-- Scenario:
-
-  We run a custom controller to implement provisioning of LoadBalancer Services.
-
-  When a Service with type=LoadBalancer is deleted, we want to make sure
-  that the corresponding external resources are properly deleted.
-
-- Rationale for using a finalizer:
-
-  Normally, we would watch and observe the deletion of the Service;
-  but if the Service is deleted while our controller is down,
-  we could "miss" the deletion and forget to clean up the external resource.
-
-  The finalizer ensures that we will "see" the deletion
-  and clean up the external resource.
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## Counterpoint
-
-- We could also:
-
-  - Tag the external resources
-    <br/>(to indicate which Kubernetes Service they correspond to)
-
-  - Periodically reconcile them against Kubernetes resources
-
-  - If a Kubernetes resource does no longer exist, delete the external resource
-
-- This doesn't have to be a *pre-delete* hook
-
-  (unless we store important information in the Service, e.g. as annotations)
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## CRD finalizer
-
-- Scenario:
-
-  We have a CRD that represents a PostgreSQL cluster.
-
-  It provisions StatefulSets, Deployments, Services, Secrets, ConfigMaps.
-
-  When the CRD is deleted, we want to delete all these resources.
-
-- Rationale for using a finalizer:
-
-  Same as previously; we could observe the CRD, but if it is deleted
-  while the controller isn't running, we would miss the deletion,
-  and the other resources would keep running.
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## Counterpoint
-
-- We could use the same technique as described before
-
-  (tag the resources with e.g. annotations, to associate them with the CRD)
-
-- Even better: we could use `ownerReferences`
-
-  (this feature is *specifically* designed for that use-case!)
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## CRD finalizer (take two)
-
-- Scenario:
-
-  We have a CRD that represents a PostgreSQL cluster.
-
-  It provisions StatefulSets, Deployments, Services, Secrets, ConfigMaps.
-
-  When the CRD is deleted, we want to delete all these resources.
-
-  We also want to store a final backup of the database.
-
-  We also want to update final usage metrics (e.g. for billing purposes).
-
-- Rationale for using a finalizer:
-
-  We need to take some actions *before* the resources get deleted, not *after*.
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-
-## Wrapping up
-
-- Finalizers are a great way to:
-
-  - prevent deletion of a resource that is still in use
-
-  - have a "guaranteed" pre-delete hook
-
-- They can also be (ab)used for other purposes
-
-- Code spelunking exercise:
-
-  *check where finalizers are used in the Kubernetes code base and why!*
-
-???
-
-:EN:- Using "finalizers" to manage resource lifecycle
-:FR:- Gérer le cycle de vie des ressources avec les *finalizers*
-
-.debug[[k8s/finalizers.md](""/tree/main/slides/k8s/finalizers.md)]
----
-# (Extra content)
-
-.debug[[kube-adv.yml](""/tree/main/slides/kube-adv.yml)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/two-containers-on-a-truck.jpg)]
-
----
-
-name: toc-owners-and-dependents
-class: title
-
- Owners and dependents
-
-.nav[
-[Previous part](#toc-extra-content)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-api-server-internals)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# Owners and dependents
-
-- Some objects are created by other objects
-
-  (example: pods created by replica sets, themselves created by deployments)
-
-- When an *owner* object is deleted, its *dependents* are deleted
-
-  (this is the default behavior; it can be changed)
-
-- We can delete a dependent directly if we want
-
-  (but generally, the owner will recreate another right away)
-
-- An object can have multiple owners
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-## Finding out the owners of an object
-
-- The owners are recorded in the field `ownerReferences` in the `metadata` block
-
-.lab[
-
-- Let's create a deployment running `nginx`:
-  ```bash
-  kubectl create deployment yanginx --image=nginx
-  ```
-
-- Scale it to a few replicas:
-  ```bash
-  kubectl scale deployment yanginx --replicas=3
-  ```
-
-- Once it's up, check the corresponding pods:
-  ```bash
-  kubectl get pods -l app=yanginx -o yaml | head -n 25
-  ```
-
-]
-
-These pods are owned by a ReplicaSet named yanginx-xxxxxxxxxx.
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-## Listing objects with their owners
-
-- This is a good opportunity to try the `custom-columns` output!
-
-.lab[
-
-- Show all pods with their owners:
-  ```bash
-  kubectl get pod -o custom-columns=\
-  NAME:.metadata.name,\
-  OWNER-KIND:.metadata.ownerReferences[0].kind,\
-  OWNER-NAME:.metadata.ownerReferences[0].name
-  ```
-
-]
-
-Note: the `custom-columns` option should be one long option (without spaces),
-so the lines should not be indented (otherwise the indentation will insert spaces).
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-## Deletion policy
-
-- When deleting an object through the API, three policies are available:
-
-  - foreground (API call returns after all dependents are deleted)
-
-  - background (API call returns immediately; dependents are scheduled for deletion)
-
-  - orphan (the dependents are not deleted)
-
-- When deleting an object with `kubectl`, this is selected with `--cascade`:
-
-  - `--cascade=true` deletes all dependent objects (default)
-
-  - `--cascade=false` orphans dependent objects
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-## What happens when an object is deleted
-
-- It is removed from the list of owners of its dependents
-
-- If, for one of these dependents, the list of owners becomes empty ...
-
-  - if the policy is "orphan", the object stays
-
-  - otherwise, the object is deleted
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-## Orphaning pods
-
-- We are going to delete the Deployment and Replica Set that we created
-
-- ... without deleting the corresponding pods!
-
-.lab[
-
-- Delete the Deployment:
-  ```bash
-  kubectl delete deployment -l app=yanginx --cascade=false
-  ```
-
-- Delete the Replica Set:
-  ```bash
-  kubectl delete replicaset -l app=yanginx --cascade=false
-  ```
-
-- Check that the pods are still here:
-  ```bash
-  kubectl get pods
-  ```
-
-]
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-class: extra-details
-
-## When and why would we have orphans?
-
-- If we remove an owner and explicitly instruct the API to orphan dependents
-
-  (like on the previous slide)
-
-- If we change the labels on a dependent, so that it's not selected anymore
-
-  (e.g. change the `app: yanginx` in the pods of the previous example)
-
-- If a deployment tool that we're using does these things for us
-
-- If there is a serious problem within API machinery or other components
-
-  (i.e. "this should not happen")
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-## Finding orphan objects
-
-- We're going to output all pods in JSON format
-
-- Then we will use `jq` to keep only the ones *without* an owner
-
-- And we will display their name
-
-.lab[
-
-- List all pods that *do not* have an owner:
-  ```bash
-  kubectl get pod -o json | jq -r "
-          .items[]
-          | select(.metadata.ownerReferences|not)
-          | .metadata.name"
-  ```
-
-]
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-## Deleting orphan pods
-
-- Now that we can list orphan pods, deleting them is easy
-
-.lab[
-
-- Add `| xargs kubectl delete pod` to the previous command:
-  ```bash
-  kubectl get pod -o json | jq -r "
-          .items[]
-          | select(.metadata.ownerReferences|not)
-          | .metadata.name" | xargs kubectl delete pod
-  ```
-
-]
-
-As always, the [documentation](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/) has useful extra information and pointers.
-
-???
-
-:EN:- Owners and dependents
-:FR:- Liens de parenté entre les ressources
-
-.debug[[k8s/owners-and-dependents.md](""/tree/main/slides/k8s/owners-and-dependents.md)]
----
-
-class: pic
-
-.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/wall-of-containers.jpeg)]
-
----
-
-name: toc-api-server-internals
-class: title
-
- API server internals
-
-.nav[
-[Previous part](#toc-owners-and-dependents)
-|
-[Back to table of contents](#toc-part-9)
-|
-[Next part](#toc-)
-]
-
-.debug[(automatically generated title slide)]
-
----
-# API server internals
-
-- Understanding the internals of the API server is useful.red[¹]:
-
-  - when extending the Kubernetes API server (CRDs, webhooks...)
-
-  - when running Kubernetes at scale
-
-- Let's dive into a bit of code!
-
-.footnote[.red[¹]And by *useful*, we mean *strongly recommended or else...*]
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-## The main handler
-
-- The API server parses its configuration, and builds a `GenericAPIServer`
-
-- ... which contains an `APIServerHandler` ([src](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/server/handler.go#L37
-))
-
-- ... which contains a couple of `http.Handler` fields
-
-- Requests go through:
-
-  - `FullhandlerChain` (a series of HTTP filters, see next slide)
-
-  - `Director` (switches the request to `GoRestfulContainer` or `NonGoRestfulMux`)
-
-- `GoRestfulContainer`  is for "normal" APIs; integrates nicely with OpenAPI
-
-- `NonGoRestfulMux` is for everything else (e.g. proxy, delegation)
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-## The chain of handlers
-
-- API requests go through a complex chain of filters ([src](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/server/config.go#L671))
-
-  (note when reading that code: requests start at the bottom and go up)
-
-- This is where authentication, authorization, and admission happen
-
-  (as well as a few other things!)
-
-- Let's review an arbitrary selection of some of these handlers!
-
-*In the following slides, the handlers are in chronological order.*
-
-*Note: handlers are nested; so they can act at the beginning and end of a request.*
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-## `WithPanicRecovery`
-
-- Reminder about Go: there is no exception handling in Go; instead:
-
-  - functions typically return a composite `(SomeType, error)` type
-
-  - when things go really bad, the code can call `panic()`
-
-  - `panic()` can be caught with `recover()`
-    <br/>
-    (but this is almost never used like an exception handler!)
-
-- The API server code is not supposed to `panic()`
-
-- But just in case, we have that handler to prevent (some) crashes
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-## `WithRequestInfo` ([src](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/request/requestinfo.go#L163))
-
-
-- Parse out essential information:
-
-  API group, version, namespace, resource, subresource, verb ...
-
-- WithRequestInfo: parse out API group+version, Namespace, resource, subresource ...
-
-- Maps HTTP verbs (GET, PUT, ...) to Kubernetes verbs (list, get, watch, ...)
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-class: extra-details
-
-## HTTP verb mapping
-
-- POST → create
-
-- PUT → update
-
-- PATCH → patch
-
-- DELETE
-  <br/> → delete (if a resource name is specified)
-  <br/> → deletecollection (otherwise)
-
-- GET, HEAD
-  <br/> → get (if a resource name is specified)
-  <br/> → list (otherwise)
-  <br/> → watch (if the `?watch=true` option is specified)
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-## `WithWaitGroup`
-
-- When we shutdown, tells clients (with in-flight requests) to retry
-
-  - only for "short" requests
-
-  - for long running requests, the client needs to do more
-
-- Long running requests include `watch` verb, `proxy` sub-resource
-
-(See also `WithTimeoutForNonLongRunningRequests`)
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-## AuthN and AuthZ
-
-- `WithAuthentication`:
-  the request goes through a *chain* of authenticators
-  ([src](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/filters/authentication.go#L38))
-
-- WithAudit
-
-- WithImpersonation: used for e.g. `kubectl ... --as another.user`
-
-- WithPriorityAndFairness or WithMaxInFlightLimit
-
-  (`system:masters` can bypass these)
-
-- WithAuthorization
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-## After all these handlers ...
-
-- We get to the "director" mentioned above
-
-- Api Groups get installed into the "gorestfulhandler"
-  ([src](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/server/genericapiserver.go#L423))
-
-- REST-ish resources are managed by various handlers
-  (in [this directory](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/handlers/))
-
-- These files show us the code path for each type of request
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.md)]
----
-
-class: extra-details
-
-## Request code path
-
-- [create.go](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/handlers/create.go):
-  decode to HubGroupVersion; admission; mutating admission; store
-
-- [delete.go](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/handlers/delete.go):
-  validating admission only; deletion
-
-- [get.go](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/handlers/get.go) (get, list):
-  directly fetch from rest storage abstraction
-
-- [patch.go](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/handlers/patch.go):
-  admission; mutating admission; patch
-
-- [update.go](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/handlers/update.go):
-  decode to HubGroupVersion; admission; mutating admission; store
-
-- [watch.go](https://github.com/kubernetes/apiserver/blob/release-1.19/pkg/endpoints/handlers/watch.go):
-  similar to get.go, but with watch logic
-
-(HubGroupVersion = in-memory, "canonical" version.)
-
-???
-
-:EN:- Kubernetes API server internals
-:FR:- Fonctionnement interne du serveur API
-
-.debug[[k8s/apiserver-deepdive.md](""/tree/main/slides/k8s/apiserver-deepdive.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)]</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/kube-fullday.yml.html b/slides/kube-fullday.yml.html
index 6214de8..eea6b28 100644
--- a/slides/kube-fullday.yml.html
+++ b/slides/kube-fullday.yml.html
@@ -31,7 +31,6 @@ Deploying and Scaling Microservices<br/>with Kubernetes<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
  M slides/intro-twodays.yml.html
  M slides/kadm-fullday.yml.html
  M slides/kadm-twodays.yml.html
@@ -41,7 +40,7 @@ Deploying and Scaling Microservices<br/>with Kubernetes<br/>
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/kube-halfday.yml.html b/slides/kube-halfday.yml.html
index 76ba55a..b26b017 100644
--- a/slides/kube-halfday.yml.html
+++ b/slides/kube-halfday.yml.html
@@ -31,7 +31,6 @@ Kubernetes 101<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
  M slides/intro-twodays.yml.html
  M slides/kadm-fullday.yml.html
  M slides/kadm-twodays.yml.html
@@ -42,7 +41,7 @@ Kubernetes 101<br/>
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/kube-selfpaced.yml.html b/slides/kube-selfpaced.yml.html
index c9e6b75..9a708f1 100644
--- a/slides/kube-selfpaced.yml.html
+++ b/slides/kube-selfpaced.yml.html
@@ -31,7 +31,6 @@ Deploying and Scaling Microservices<br/>with Docker and Kubernetes<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
  M slides/intro-twodays.yml.html
  M slides/kadm-fullday.yml.html
  M slides/kadm-twodays.yml.html
@@ -43,7 +42,7 @@ Deploying and Scaling Microservices<br/>with Docker and Kubernetes<br/>
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/kube-twodays.yml.html b/slides/kube-twodays.yml.html
index baf84fa..aaa8509 100644
--- a/slides/kube-twodays.yml.html
+++ b/slides/kube-twodays.yml.html
@@ -31,7 +31,6 @@ Deploying and Scaling Microservices<br/>with Kubernetes<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
  M slides/intro-twodays.yml.html
  M slides/kadm-fullday.yml.html
  M slides/kadm-twodays.yml.html
@@ -44,7 +43,7 @@ Deploying and Scaling Microservices<br/>with Kubernetes<br/>
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/swarm-fullday.yml.html b/slides/swarm-fullday.yml.html
index e4be6e1..d722b1a 100644
--- a/slides/swarm-fullday.yml.html
+++ b/slides/swarm-fullday.yml.html
@@ -31,7 +31,6 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
  M slides/intro-twodays.yml.html
  M slides/kadm-fullday.yml.html
  M slides/kadm-twodays.yml.html
@@ -45,7 +44,7 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/swarm-halfday.yml.html b/slides/swarm-halfday.yml.html
index 3071122..09693f5 100644
--- a/slides/swarm-halfday.yml.html
+++ b/slides/swarm-halfday.yml.html
@@ -31,7 +31,6 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
  M slides/intro-twodays.yml.html
  M slides/kadm-fullday.yml.html
  M slides/kadm-twodays.yml.html
@@ -46,7 +45,7 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/swarm-selfpaced.yml.html b/slides/swarm-selfpaced.yml.html
index d345889..194fd8e 100644
--- a/slides/swarm-selfpaced.yml.html
+++ b/slides/swarm-selfpaced.yml.html
@@ -31,7 +31,6 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
  M slides/intro-twodays.yml.html
  M slides/kadm-fullday.yml.html
  M slides/kadm-twodays.yml.html
@@ -47,7 +46,7 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]
diff --git a/slides/swarm-video.yml.html b/slides/swarm-video.yml.html
index de1596d..5251b8a 100644
--- a/slides/swarm-video.yml.html
+++ b/slides/swarm-video.yml.html
@@ -31,7 +31,6 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 ```
  M slides/airgapped/Importing_Images.md
  M slides/intro-fd-docker.yml
- M slides/intro-triodos-1-day.yml.html
  M slides/intro-twodays.yml.html
  M slides/kadm-fullday.yml.html
  M slides/kadm-twodays.yml.html
@@ -48,7 +47,7 @@ Container Orchestration<br/>with Docker and Swarm<br/>
 
 ```
 
-These slides have been built from commit: c830a9d
+These slides have been built from commit: 07d4dae
 
 
 [shared/title.md](""/tree/main/slides/shared/title.md)]