From 394091338ffd8ca4537e25ca9556c582b0657808 Mon Sep 17 00:00:00 2001 From: Pierre-Olivier Mercier Date: Sat, 17 Dec 2022 23:12:17 +0100 Subject: [PATCH] Make OCI part an introduction to subsiduaries sections --- tutorial/docker-internals/oci.md | 78 +++++++++++++++++++++------ tutorial/docker-internals/registry.md | 48 +++++++++++------ tutorial/docker-internals/runtimes.md | 4 ++ 3 files changed, 96 insertions(+), 34 deletions(-) create mode 100644 tutorial/docker-internals/runtimes.md 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 +====================================