diff --git a/tutorial/docker-internals/oci.md b/tutorial/docker-internals/oci.md
index bfa8c5e..06cd5c9 100644
--- a/tutorial/docker-internals/oci.md
+++ b/tutorial/docker-internals/oci.md
@@ -33,16 +33,61 @@ rejoindre), quelles *capabilities* resteront disponibles, quels nouveaux points
de montages, ... Voir [la
suite](https://github.com/opencontainers/runtime-spec/blob/master/config.md).
-Aujourd'hui, les dernières versions de `docker` utilisent `runc` pour l'étape
-de lancement du conteneur, après avoir téléchargé l'image puis mis en place
-l'empilement de couches dans un répertoire prédéterminé. `docker` ne lance donc
-plus de conteneur à proprement parler, il fait seulement en sorte d'atteindre
-l'état voulu par cette spécification, avant de passer la main à `runc`.
+Aujourd'hui, `docker` utilise `runc` pour l'étape de lancement du conteneur,
+après avoir téléchargé l'image puis mis en place l'empilement de couches dans
+un répertoire prédéterminé. `docker` ne lance donc plus de conteneur à
+proprement parler, il fait seulement en sorte d'atteindre l'état voulu par
+cette spécification, avant de passer la main à `runc`.
+
+::::: {.question}
+
+##### Si `docker` fait appel à un programme externe pour lancer effectivement nos conteneurs, c'est que l'on peut changer cette implémentation ? {-}
+
+
+
+Oui ! Et il n'y a même pas besoin de faire beaucoup d'efforts, car c'est une
+possibilité qui est offerte au travers d'une option du daemon Docker. Le
+binaire doit simplement avoir la même interface de ligne de commande que `runc`
+(les arguments `create` et `start`, nous les verrons plus tard).
+
+Pour l'ajouter, il convient de passer l'option suivante au daemon Docker lors
+de son lancement (dans le fichier de service `systemd`, ou d'`init`) :
+
+
+```sh
+/usr/bin/dockerd [...] --add-runtime=my-runtime=/usr/local/bin/my-runtime
+```
+
+
+Ou bien en passant par le fichier de configuration `/etc/docker/daemon.json` :
+
+
+```json
+{
+ "runtimes": {
+ "my-runtime": {
+ "path": "/usr/local/bin/my-runtime",
+ "runtimeArgs": []
+ }
+ }
+}
+```
+
+
+Pour chaque nouveau conteneur lancé, il sera alors possible de préciser le *runtime* à utiliser grâce à l'option `--runtime` :
+
+
+```sh
+docker container run [...] --runtime=my-runtime nginx:alpine
+```
+
+
+:::::
### `image-spec`
-Une image OCI est composée d'un manifest, d'une suite de couches de systèmes de
+Une image OCI est composée d'un manifest, d'une série de couches de systèmes de
fichiers, d'une configuration ainsi que d'un index d'image optionnel.
Le
@@ -52,14 +97,13 @@ trouver les différents éléments : configuration et couches. Lorsqu'une même
image a des variations en fonction de l'architecture du processeur, du système
d'exploitation, ... dans ce cas [l'index
d'image](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
-est utilisé pour sélectionner le bon manifest.
+est utilisé pour sélectionner le bon manifest correspondant au système.
Le format des [couches de système de
fichiers](https://github.com/opencontainers/image-spec/blob/master/layer.md)
sont spécifiées : il est nécessaire de passer par des formats standards (comme
les tarballs), contenant éventuellement des fichiers et dossiers spéciaux
-contenant les modifications, suppressions, ... éventuelles de la couche
-représentée.
+représentant les modifications ou les suppressions éventuelles de la couche.
La
[configuration](https://github.com/opencontainers/image-spec/blob/master/config.md)
@@ -72,14 +116,14 @@ des couches du système de fichiers, ainsi que l'historique de l'image.
### `distribution-spec`
-Dernière née de l'organisme, cette spécification fédère la notion de
-*registre* : une API REST sur HTTP où l'on peut récupérer des images, mais
-aussi en envoyer.
+Enfin, cette spécification fédère la notion de *registre* et la manière dont
+les clients vont interagir avec : il s'agit d'une API REST au dessus du
+protocole HTTP.
+Cela permet de récupérer des images, mais aussi d'en envoyer, en gérant
+éventuellement la manière de s'authentifier.
-### Pour aller plus loin {-}
+\
-Si maintenant `docker` fait appel à un programme externe pour lancer
-effectivement nos conteneurs, c'est que l'on peut changer cette
-implémentation ? la réponse dans l'article :\
-
+Nous allons voir plus en détails, dans les chapitres suivantes, ce que l'on
+peut tirer de ces spécifications, en décortiquant des usages précis.
diff --git a/tutorial/docker-internals/registry.md b/tutorial/docker-internals/registry.md
index a067c09..f6b0054 100644
--- a/tutorial/docker-internals/registry.md
+++ b/tutorial/docker-internals/registry.md
@@ -1,12 +1,17 @@
\newpage
-Registres
-=========
+Registres d'images
+==================
-Nous allons appréhender le fonctionnement d'un registre OCI, en essayant de
-récupérer les couches de quelques images (Debian, Ubuntu, hello, ...) : dans un
-premier temps en nous préoccupant simplement de la couche la plus basse (qui ne
-contient pas de modification ou de suppression : chaque fichier est normal).
+Regardons d'un peu plus près les registres d'images OCI. Ce sont eux qui
+distribuent les images OCI et permettent à Docker de récupérer très facilement
+de nouveaux services.
+
+Dans les sections à venir, nous allons essayer de récupérer la configuration et
+les couches de quelques images courantes (Debian, Ubuntu, `hello-world`, ...) :
+dans un premier temps en nous préoccupant simplement de la couche la plus basse
+(le système de baase). Puis nous verrons dans le chapitre suivant comment gérer
+les autres couches.
## Authentification
@@ -29,7 +34,7 @@ lang="en-US">`repository:hello-world:pull`). Ce qui nous donne :
dépôt (*repository*).
-```bash
+```
42sh$ curl "https://auth.docker.io/token?service=registry.docker.io&" \
"scope=repository:library/hello-world:pull" | jq .
```
@@ -79,9 +84,10 @@ curl -s \
```
-Dans la liste des *manifests* retournés, nous devons récupérer son `digest`. Dans
-tout l'écosystème OCI, les `digest` servent à la fois de chemin d'accès et de
-somme de contrôle.
+Parmi la liste des *manifests* retournés, nous devons récupérer le `digest`
+correspondant au système qui correspond à votre architecture et notre
+système. Dans tout l'écosystème OCI, les `digest` servent à la fois de chemin
+d'accès et de somme de contrôle.
## Lecture du *manifest*
@@ -100,17 +106,17 @@ curl -s \
Nous voici donc maintenant avec le *manifest* de notre image. Nous pouvons
-constater qu'il n'a bien qu'une seule couche, ouf !
+constater qu'il n'a bien qu'une seule couche. Ouf, ça va simplifier les
+choses !
## Récupération de la configuration et de la première couche
-Les deux éléments que l'on cherche à récupérer vont se trouver dans le
-répertoire `blobs`, il ne s'agit en effet plus de *manifest*. Si les *manifests*
-sont toujours stockés par le registre lui-même, les blobs peuvent être délégués
-à un autre service, par exemple dans le cloud, chez Amazon S3, un CDN, etc.
+Les deux éléments que l'on cherche maintenant à récupérer vont se trouver dans
+le répertoire `blobs` de notre dépôt. Il ne s'agira plus de *manifest*, mais
+bien des fichiers définitifs.
-Pour récupérer la configuration de l'image :
+Récupérons la configuration de l'image comme ceci :
```bash
@@ -120,8 +126,16 @@ curl -s --location \
```
+Remarquez l'usage de l'option `--location` de `curl` : si les *manifests* sont
+toujours stockés par le registre lui-même, les *blobs* peuvent être délégués à
+un autre service, par exemple dans le cloud, chez Amazon S3, un CDN, etc. Sans
+l'option `--location`, notre `curl` va retourner une redirection vers une autre
+adresse, celle qui contient effectivement la configuration. Il en sera de même
+pour les fichiers stockant les couches.\
-Enfin, armé du `digest` de notre couche, il ne nous reste plus qu'à la demander gentiment :
+
+Enfin d'autre part, armé du `digest` de notre couche, il ne nous reste plus
+qu'à la demander gentiment :
```bash
diff --git a/tutorial/docker-internals/runtimes.md b/tutorial/docker-internals/runtimes.md
new file mode 100644
index 0000000..6342fb2
--- /dev/null
+++ b/tutorial/docker-internals/runtimes.md
@@ -0,0 +1,4 @@
+\newpage
+
+Programmes d'exécution de conteneurs
+====================================