docker-internal: Fix typos
This commit is contained in:
parent
5ff94431cb
commit
8a84f7a527
|
|
@ -5,6 +5,6 @@
|
|||
|
||||
Des expériences sont en cours pour essayer de faire un format
|
||||
d'archive pour les couches qui permettrait d'utiliser les conteneurs
|
||||
sans avoir eu besoin préalablement d'avoir télécharger le contenu des
|
||||
sans avoir eu besoin préalablement d'avoir téléchargé le contenu des
|
||||
couches :
|
||||
<https://github.com/containerd/stargz-snapshotter/blob/main/docs/estargz.md>
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Systèmes de fichiers et couches
|
|||
===============================
|
||||
|
||||
Les images de conteneurs sont distribuées en couches, chaque couche contenant
|
||||
les différences apportée par rapport à la couche précédente : l'ajout d'un
|
||||
les différences apportées par rapport à la couche précédente : l'ajout d'un
|
||||
fichier, la suppression d'un dossier, ...
|
||||
|
||||
L'intérêt principal est bien entendu d'optimiser l'espace de stockage, en
|
||||
|
|
@ -41,7 +41,7 @@ paquets, ou ajouter ses propres applications, documents, photos, ...
|
|||
Historiquement, le noyau Linux devait être *patché* pour supporter ce type de
|
||||
système de fichiers (que ce soit `unionfs` ou `aufs`, les deux principaux
|
||||
*patch* apportant cette fonctionnalité). Les systèmes BSD disposent d'une
|
||||
implémentation depuis au moins 1995 et c'est SunOS qui fût le premier OS à
|
||||
implémentation depuis au moins 1995 et c'est SunOS qui fut le premier OS à
|
||||
développer cette technique dès 1986 (pour un système de fichier appelé
|
||||
*Translucent File Service*). Pour Linux, il aura fallu attendre 2014 pour voir
|
||||
l'arrivée du système de fichier OverlayFS dans un noyau sans *patch*.
|
||||
|
|
@ -109,7 +109,7 @@ davantage de place au fil du temps et des modifications, que l'union.
|
|||
## OverlayFS
|
||||
|
||||
OverlayFS est arrivé dans le noyau 3.18, après de plus de 4 années de réécritures
|
||||
et d'amélioration structurelles, pour atteindre le niveau d'exigence et sans
|
||||
et d'améliorations structurelles, pour atteindre le niveau d'exigence et sans
|
||||
compromis nécessaire à son intégration dans le noyau officiel.
|
||||
|
||||
::::: {.question}
|
||||
|
|
@ -121,8 +121,8 @@ L'un des problèmes les plus délicats est de trouver une manière de représent
|
|||
les suppressions de fichiers et de dossiers : cela doit être un fichier valide
|
||||
(avec ou sans métadonnée) car il faut pouvoir stocker l'information
|
||||
concrètement. Dans de nombreuses implémentations, un fichier `.wh.<filename>`
|
||||
sert de *whiteout file*, ce qui peut créer des conflits avec des fichiers de
|
||||
l'utilisateur (ou réduire ses choix de noms de fichiers).
|
||||
sert de *whiteout file*, ce qui peut créer des conflits avec les noms des
|
||||
fichiers de l'utilisateur (ou réduire ses choix de noms de fichiers).
|
||||
|
||||
Un problème similaire s'applique aux dossiers : est-ce qu'il faut supprimer
|
||||
chaque fichier contenu dans le dossier ou la simple présence d'un *opaque
|
||||
|
|
@ -136,11 +136,11 @@ fichiers.
|
|||
L'implémentation de `mmap(2)` est nécessairement un cauchemar : lorsqu'un
|
||||
fichier est modifié par deux processus qui le `mmap(2)`, on s'attend
|
||||
normalement à voir les modifications dans les deux processus, or le premier à
|
||||
faire une modification a créer un nouveau fichier dans la branche accessible en
|
||||
écriture. Il est ardu de réconcilier les pointeurs deux des processus.
|
||||
faire une modification crée un nouveau fichier dans la branche accessible en
|
||||
écriture. Il est alors ardu de réconcilier les pointeurs des deux processus.
|
||||
|
||||
D'une manière similaire, il faut penser à la gestion des *hard links* : tous
|
||||
les pointeurs d'un contenu mis à jour devrait être modifié dans la couche en
|
||||
les pointeurs d'un contenu mis à jour devraient être modifiés dans la couche en
|
||||
écriture, cependant il n'y a pas d'index des pointeurs, il n'est donc pas
|
||||
facile de retrouver les fichiers à mettre à jour.
|
||||
|
||||
|
|
@ -160,12 +160,12 @@ choix et différences : <https://lwn.net/Articles/325369/>,
|
|||
:::::
|
||||
|
||||
Afin de satisfaire les contraintes d'intégration au noyau, le minimum de
|
||||
fonctionnalités ont été retenues : on ne peut notamment avoir qu'une seule
|
||||
couche en écriture, qui se positionne nécessairement au sommet, en
|
||||
superposition des autres. C'est de là que vient le nom du système de fichiers,
|
||||
puisqu'il s'agit davantage d'une superposition (*overlay*) d'un système de
|
||||
fichiers sur un autre, plutôt qu'une union de plusieurs systèmes aux politiques
|
||||
d'écritures potentiellement plus variées.
|
||||
fonctionnalités a été retenu : on ne peut notamment avoir qu'une seule couche
|
||||
en écriture, qui se positionne nécessairement au sommet, en superposition des
|
||||
autres. C'est de là que vient le nom du système de fichiers, puisqu'il s'agit
|
||||
davantage d'une superposition (*overlay*) d'un système de fichiers sur un
|
||||
autre, plutôt qu'une union de plusieurs systèmes aux politiques d'écritures
|
||||
potentiellement plus variées.
|
||||
|
||||
|
||||
### Utilisation
|
||||
|
|
@ -196,7 +196,7 @@ mount -t overlay -olowerdir=/lower,upperdir=/upper,workdir=/work ignored /merged
|
|||
Le type à utiliser est `overlay`, avec les options `lowerdir` qui indique
|
||||
l'emplacement du/des dossiers à combiner en lecture seule (on les sépare par
|
||||
des `:` lorsqu'il y en a plusieurs), on indique également le répertoire
|
||||
contenant le système en lecture/écriture dans l'option `upperdir`, et on il
|
||||
contenant le système en lecture/écriture dans l'option `upperdir`, et il ne
|
||||
faut pas oublier l'option `workdir` un chemin sur la même partition que
|
||||
l'`upperdir`, qui doit être vide.
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ On peut également voir les dossiers utilisés en inspectant notre conteneur :
|
|||
```
|
||||
</div>
|
||||
|
||||
Si on teste avec une image avec plus de couches, on obtient davantage de
|
||||
Si on teste avec une image ayant plus de couches, on obtient davantage de
|
||||
`lowerdir`, un par couche. N'hésitez pas à faire la même série de commandes
|
||||
avec l'image `python` par exemple.
|
||||
|
||||
|
|
@ -267,7 +267,7 @@ avec l'image `python` par exemple.
|
|||
### Ajout de fichiers
|
||||
|
||||
À ce stade, si nous regardons le contenu de notre dossier `upperdir`, nous
|
||||
pouvons remarqué que celui-ci est vide. C'est normal puisque nous n'avons apporté
|
||||
pouvons remarquer que celui-ci est vide. C'est normal puisque nous n'avons apporté
|
||||
aucune modification.
|
||||
|
||||
Dans notre conteneur précédemment lancé, apportons une modification, en
|
||||
|
|
@ -387,7 +387,7 @@ monté conduisent à des résultats explicitement indéfinis.
|
|||
|
||||
Le concept de *whiteout file*, comme on a pu le voir, diffère en fonction du
|
||||
système de fichiers. Il s'avère que même si l'OverlayFS a été intégré dans le
|
||||
noyau Linux après maintes péripéties, Docker, lorsqu'à été spécifié le format
|
||||
noyau Linux après maintes péripéties, Docker, lorsqu'a été spécifié le format
|
||||
des archives utilisées pour distribuer les couches, utilise aujourd'hui le
|
||||
format d'AuFS pour représenter les suppressions. Il est donc important de le
|
||||
voir également.
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ services:
|
|||
|
||||
On retrouve nos différentes sections : `kernel` indique qu'il faut récupérer
|
||||
l'image `linuxkit/kernel` depuis le registre Docker : il ne s'agit pas d'une
|
||||
image qui sera lancé, elle est plutôt utilisée comme une archive de stockage
|
||||
image qui sera lancée, elle est plutôt utilisée comme une archive de stockage
|
||||
pour le noyau et ses modules. LinuxKit au moment de la construction de l'image
|
||||
se chargera de placer les fichiers aux bons endroits.
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ Ensuite, nous avons une section `init` qui déclare 3 images Docker :
|
|||
Ces trois images ne sont pas non plus des images Docker conventionnelles, dans
|
||||
le sens où on ne peut pas les utiliser pour faire un `docker container
|
||||
run`. Elles contiennent chacune une partie de l'arborescence du système de
|
||||
fichiers, uniquement les fichiers nécessaire, en plus, au fonctionnement du
|
||||
fichiers, uniquement les fichiers nécessaires, en plus, au fonctionnement du
|
||||
programme qu'elles ajoutent. Les images déclarées dans la section `init` seront
|
||||
fusionnées ensemble et formeront le système de fichiers de base de notre image
|
||||
LinuxKit.
|
||||
|
|
@ -95,7 +95,7 @@ d'avoir un shell sur la machine !
|
|||
|
||||
On notera cependant que, positionné dans `services`, le shell que nous
|
||||
obtiendrons sera lui-même exécuté dans un conteneur, nous n'aurons donc pas un
|
||||
accès entièrement privilégier. Pour déboguer, il faut placer cette image dans
|
||||
accès entièrement privilégié. Pour déboguer, il faut placer cette image dans
|
||||
la partie `init`, elle sera alors lancée comme un équivalent de
|
||||
`init=/bin/sh`.[^infogetty]
|
||||
|
||||
|
|
@ -172,7 +172,7 @@ réutiliser plus tard ce chemin, en remplacement du mot clef `new` :
|
|||
|
||||
Toute la puissance de `linuxkit` repose dans son système de construction et
|
||||
surtout de lancement. En effet, il peut construire des images pour un grand
|
||||
nombre de plate-forme, mais il est également possible d'utiliser les API de ces
|
||||
nombre de plate-formes, mais il est également possible d'utiliser les API de ces
|
||||
plates-formes pour aller y lancer des instances de cette image !
|
||||
|
||||
Pour construire l'image faite précédemment :
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ fragmentation de l'écosystème.
|
|||
|
||||
Trois spécifications ont été écrites :
|
||||
|
||||
- [`runtime-spec`](https://github.com/opencontainers/runtime-spec/blob/master/spec.md#platforms): définis les paramètres du démarrage d'un conteneur ;
|
||||
- [`image-spec`](https://github.com/opencontainers/image-spec/blob/master/spec.md): définis la construction, le transport et la préparation des images ;
|
||||
- [`distribution-spec`](https://github.com/opencontainers/distribution-spec/blob/master/spec.md): définis la manière dont sont partagées et récupérées les images.
|
||||
- [`runtime-spec`](https://github.com/opencontainers/runtime-spec/blob/master/spec.md#platforms): définit les paramètres du démarrage d'un conteneur ;
|
||||
- [`image-spec`](https://github.com/opencontainers/image-spec/blob/master/spec.md): définit la construction, le transport et la préparation des images ;
|
||||
- [`distribution-spec`](https://github.com/opencontainers/distribution-spec/blob/master/spec.md): définit la manière dont sont partagées et récupérées les images.
|
||||
|
||||
|
||||
### `runtime-spec`
|
||||
|
|
@ -36,14 +36,14 @@ 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 a proprement parlé, il fait seulement en sorte d'atteindre
|
||||
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`.
|
||||
|
||||
|
||||
### `image-spec`
|
||||
|
||||
Une image OCI est composée d'un manifest, d'une suite de couches de systèmes de
|
||||
fichiers, d'une configuration ainsi qu'un index d'image optionnel.
|
||||
fichiers, d'une configuration ainsi que d'un index d'image optionnel.
|
||||
|
||||
Le
|
||||
[manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
|
||||
|
|
|
|||
|
|
@ -146,7 +146,8 @@ tar xzf ${DL_LAYER} -C rootfs
|
|||
```
|
||||
</div>
|
||||
|
||||
Et voilà, nous avons extrait notre première image, nous devrions pouvoir :
|
||||
Et voilà, nous avons extrait notre première image, nous devrions pouvoir entrer
|
||||
dedans :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ ajouter un élément à cette liste, demandant de *bind* :
|
|||
|
||||
À vous maintenant d'éditer votre `config.json`, pour lancer le service youp0m.
|
||||
|
||||
Dans un premier temps, assurez-vous de pouvoir télécharger et d'assembler
|
||||
Dans un premier temps, assurez-vous de pouvoir télécharger et assembler
|
||||
rapidement les couches du conteneur.
|
||||
|
||||
À partir du fichier `config.json` fourni, adaptez la ligne de commande à lancer
|
||||
|
|
@ -138,7 +138,7 @@ stocker les photos (dossier `/srv/images`)[^chmod].
|
|||
simple pour l'instant serait d'attribuer les permissions `0777` à la
|
||||
source, temporairement.
|
||||
|
||||
Pour cette étape, Considérez que vous avez réussi si vous voyez s'afficher :
|
||||
Pour cette étape, considérez que vous avez réussi si vous voyez s'afficher :
|
||||
|
||||
> `Ready, listening on :8080`
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ utiliser la commande `lxc-console` pour nous attacher aux conteneurs. À tout
|
|||
moment, nous pouvons nous détacher de la console (sans que cela n'affecte
|
||||
l'état du conteneur) en pressant les touches : `^A q`.
|
||||
|
||||
Connectons-nous, lancons quelques commandes puis éteignons la machine en
|
||||
Connectons-nous, lançons quelques commandes puis éteignons la machine en
|
||||
lançant la commande `poweroff` dans le conteneur. Il est également possible de
|
||||
lancer la commande `lxc-stop --name toto_first` dans un autre terminal, depuis
|
||||
la machine hôte.
|
||||
|
|
@ -209,7 +209,7 @@ configuration du conteneur afin qu'il ne puisse pas utiliser plus que 256 MB de
|
|||
RAM et 512 MB de swap.
|
||||
|
||||
Limitez ensuite les `capabilities(7)` de ce conteneur afin qu'il s'exécute avec
|
||||
le strict minimum de droits, nécessaire au bon fonctionnement des programmes
|
||||
le strict minimum de droits, nécessaires au bon fonctionnement des programmes
|
||||
installés.
|
||||
|
||||
**Rendez le fichier `config` de ce premier conteneur.** N'hésitez pas à laisser
|
||||
|
|
@ -218,7 +218,7 @@ installés.
|
|||
### Questions
|
||||
|
||||
1. Quels sont les autres types de virtualisation réseau existants ? Expliquez
|
||||
en chacun une phrase leurs particularités.
|
||||
leurs particularités en une phrase.
|
||||
|
||||
1. Quel fichier de configuration devriez-vous changer pour rendre persistante la
|
||||
valeur d'`ip_forward` ?
|
||||
|
|
|
|||
Loading…
Reference in New Issue