Make OCI part an introduction to subsiduaries sections
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
nemunaire 2022-12-17 23:12:17 +01:00
parent 4e58219ba8
commit 394091338f
3 changed files with 96 additions and 34 deletions

View File

@ -33,16 +33,61 @@ rejoindre), quelles *capabilities* resteront disponibles, quels nouveaux points
de montages, ... Voir [la de montages, ... Voir [la
suite](https://github.com/opencontainers/runtime-spec/blob/master/config.md). suite](https://github.com/opencontainers/runtime-spec/blob/master/config.md).
Aujourd'hui, les dernières versions de `docker` utilisent `runc` pour l'étape Aujourd'hui, `docker` utilise `runc` pour l'étape de lancement du conteneur,
de lancement du conteneur, après avoir téléchargé l'image puis mis en place après avoir téléchargé l'image puis mis en place l'empilement de couches dans
l'empilement de couches dans un répertoire prédéterminé. `docker` ne lance donc un répertoire prédéterminé. `docker` ne lance donc plus de conteneur à
plus de conteneur à proprement parler, il fait seulement en sorte d'atteindre proprement parler, il fait seulement en sorte d'atteindre l'état voulu par
l'état voulu par cette spécification, avant de passer la main à `runc`. 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` ### `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. fichiers, d'une configuration ainsi que d'un index d'image optionnel.
Le 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 image a des variations en fonction de l'architecture du processeur, du système
d'exploitation, ... dans ce cas [l'index d'exploitation, ... dans ce cas [l'index
d'image](https://github.com/opencontainers/image-spec/blob/master/image-index.md) 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 Le format des [couches de système de
fichiers](https://github.com/opencontainers/image-spec/blob/master/layer.md) 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 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 les tarballs), contenant éventuellement des fichiers et dossiers spéciaux
contenant les modifications, suppressions, ... éventuelles de la couche représentant les modifications ou les suppressions éventuelles de la couche.
représentée.
La La
[configuration](https://github.com/opencontainers/image-spec/blob/master/config.md) [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` ### `distribution-spec`
Dernière née de l'organisme, cette spécification fédère la notion de Enfin, cette spécification fédère la notion de *registre* et la manière dont
*registre* : une API REST sur HTTP où l'on peut récupérer des images, mais les clients vont interagir avec : il s'agit d'une API REST au dessus du
aussi en envoyer. 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 Nous allons voir plus en détails, dans les chapitres suivantes, ce que l'on
effectivement nos conteneurs, c'est que l'on peut changer cette peut tirer de ces spécifications, en décortiquant des usages précis.
implémentation ? la réponse dans l'article :\
<https://ops.tips/blog/run-docker-with-forked-runc/>

View File

@ -1,12 +1,17 @@
\newpage \newpage
Registres Registres d'images
========= ==================
Nous allons appréhender le fonctionnement d'un registre OCI, en essayant de Regardons d'un peu plus près les registres d'images OCI. Ce sont eux qui
récupérer les couches de quelques images (Debian, Ubuntu, hello, ...) : dans un distribuent les images OCI et permettent à Docker de récupérer très facilement
premier temps en nous préoccupant simplement de la couche la plus basse (qui ne de nouveaux services.
contient pas de modification ou de suppression : chaque fichier est normal).
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 ## Authentification
@ -29,7 +34,7 @@ lang="en-US">`repository:hello-world:pull`</span>). Ce qui nous donne :
dépôt (*repository*). dépôt (*repository*).
<div lang="en-US"> <div lang="en-US">
```bash ```
42sh$ curl "https://auth.docker.io/token?service=registry.docker.io&" \ 42sh$ curl "https://auth.docker.io/token?service=registry.docker.io&" \
"scope=repository:library/hello-world:pull" | jq . "scope=repository:library/hello-world:pull" | jq .
``` ```
@ -79,9 +84,10 @@ curl -s \
``` ```
</div> </div>
Dans la liste des *manifests* retournés, nous devons récupérer son `digest`. Dans Parmi la liste des *manifests* retournés, nous devons récupérer le `digest`
tout l'écosystème OCI, les `digest` servent à la fois de chemin d'accès et de correspondant au système qui correspond à votre architecture et notre
somme de contrôle. 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* ## Lecture du *manifest*
@ -100,17 +106,17 @@ curl -s \
</div> </div>
Nous voici donc maintenant avec le *manifest* de notre image. Nous pouvons 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 ## 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 Les deux éléments que l'on cherche maintenant à récupérer vont se trouver dans
répertoire `blobs`, il ne s'agit en effet plus de *manifest*. Si les *manifests* le répertoire `blobs` de notre dépôt. Il ne s'agira plus de *manifest*, mais
sont toujours stockés par le registre lui-même, les blobs peuvent être délégués bien des fichiers définitifs.
à un autre service, par exemple dans le cloud, chez Amazon S3, un CDN, etc.
Pour récupérer la configuration de l'image : Récupérons la configuration de l'image comme ceci :
<div lang="en-US"> <div lang="en-US">
```bash ```bash
@ -120,8 +126,16 @@ curl -s --location \
``` ```
</div> </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"> <div lang="en-US">
```bash ```bash

View File

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