📃 Update container content with multi-arch

slides/containers/Background_Containers.md

@@ -44,6 +44,64 @@ Fri Feb 20 00:28:55 UTC 2015
 
 ---
 
+## When `^C` doesn't work...
+
+Sometimes, `^C` won't be enough.
+
+Why? And how can we stop the container in that case?
+
+---
+
+## 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.
+
+---
+
+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
+
+---
+
+## How to stop these containers, then?
+
+- Start another terminal and forget about them
+
+  (for now!)
+
+- We'll shortly learn about `docker kill`
+
+---
+
 ## Run a container in the background
 
 Containers can be started in the background, with the `-d` flag (daemon mode):

slides/containers/First_Containers.md

@@ -118,7 +118,7 @@ Let's check how many packages are installed there.
 
 ```bash
 root@04c0bb0a6c07:/# dpkg -l | wc -l
-190
+97
 ```
 
 * `dpkg -l` lists the packages installed in our container
@@ -175,7 +175,7 @@ Now try to run `figlet`. Does that work?
 
 * We can run *any container* on *any host*.
 
-  (One exception: Windows containers cannot run on Linux machines; at least not yet.)
+  (One exception: Windows containers can only run on Windows hosts; at least for now.)
 
 ---
 

slides/containers/Initial_Images.md

@@ -56,6 +56,8 @@ Each of the following items will correspond to one layer:
 * Our application code and assets
 * Our application configuration
 
+(Note: app config is generally added by orchestration facilities.)
+
 ---
 
 class: pic
@@ -367,6 +369,44 @@ This is similar to what we would do with `pip install`, `npm install`, etc.
 
 ---
 
+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)
+
+---
+
+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)
+
+---
+
 ## Section summary
 
 We've learned how to: