docker-internal: Fix typos

tutorial/docker-internals/linuxkit-content.md

@@ -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 :

tutorial/docker-internals/oci.md

@@ -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)

tutorial/docker-internals/registry.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">
 ```

tutorial/docker-internals/runc.md

@@ -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`