Make OCI part an introduction to subsiduaries sections

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 ? {-}
+
+<!-- https://ops.tips/blog/run-docker-with-forked-runc/ -->
+
+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`) :
+
+<div lang="en-US">
+```sh
+/usr/bin/dockerd [...] --add-runtime=my-runtime=/usr/local/bin/my-runtime
+```
+</div>
+
+Ou bien en passant par le fichier de configuration `/etc/docker/daemon.json` :
+
+<div lang="en-US">
+```json
+{
+    "runtimes": {
+        "my-runtime": {
+            "path": "/usr/local/bin/my-runtime",
+            "runtimeArgs": []
+        }
+    }
+}
+```
+</div>
+
+Pour chaque nouveau conteneur lancé, il sera alors possible de préciser le *runtime* à utiliser grâce à l'option `--runtime` :
+
+<div lang="en-US">
+```sh
+docker container run [...] --runtime=my-runtime nginx:alpine
+```
+</div>
+
+:::::
 
 
 ### `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 :\
-<https://ops.tips/blog/run-docker-with-forked-runc/>
+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.

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`</span>). Ce qui nous donne :
     dépôt (*repository*).
 
 <div lang="en-US">
-```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 \
 ```
 </div>
 
-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 \
 </div>
 
 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 :
 
 <div lang="en-US">
 ```bash
@@ -120,8 +126,16 @@ curl -s --location \
 ```
 </div>
 
+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 :
 
 <div lang="en-US">
 ```bash

tutorial/docker-internals/runtimes.md

@@ -0,0 +1,4 @@
+\newpage
+
+Programmes d'exécution de conteneurs
+====================================