Fix orthograf and grammar thanks to grammalecte

tutorial/docker-internals/clair.md

@@ -3,7 +3,7 @@
 Un outil complet indexer et chercher des vulnérabilités est
 [`Clair`](https://github.com/coreos/clair/), du projet CoreOS. À partir des
 informations mises à disposition par les équipes de sécurités des principales
-distributions, cela alimente en continu une base de données qui sera accéder au
+distributions, cela alimente en continu une base de données qui sera accédé au
 moment de l'analyse.
 
 L'outil se présente sous la forme d'un serveur autonome dans la récupération

tutorial/docker-internals/linuxkit-content.md

@@ -68,7 +68,7 @@ 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
-la partie `init`, elle sera alors lancé comme un équivalent de
+la partie `init`, elle sera alors lancée comme un équivalent de
 `init=/bin/sh`.[^infogetty]
 
 [^infogetty]: Plus d'infos à
@@ -177,7 +177,7 @@ serveur SSH aux `services` :
 ```
 </div>
 
-Comme nous n'avons définis aucun mot de passe, il va falloir utiliser une clef
+Comme nous n'avons défini aucun mot de passe, il va falloir utiliser une clef
 SSH pour se connecter. Voilà un bon début d'utilisation de la section `files` :
 
 <div lang="en-US">

tutorial/docker-internals/oci.md

@@ -9,9 +9,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é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`](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`
@@ -47,7 +47,7 @@ Le
 [manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
 est toujours le point d'entrée d'une image : il référence l'emplacement où
 trouver les différents éléments : configuration et couches. Lorsqu'une même
-image a des variation 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'image](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
 est utilisé pour sélectionner le bon manifest.
@@ -78,8 +78,8 @@ aussi en envoyer.
 ## 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 :\
+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/>
 
 Et `containerd` dans l'histoire ?\

tutorial/docker-internals/registry.md

@@ -186,7 +186,7 @@ Pensez également à tester avec d'autres images, comme par exemple
 `nemunaire/youp0m`. Il vous faudra alors extraire plusieurs couches.
 
 Pour gérer les différentes couches, vous pouvez utiliser une stratégie
-similaire au driver `vfs` : en extrayant chaque tarball l'une au dessus de
+similaire au driver `vfs` : en extrayant chaque tarball l'une au-dessus de
 l'autre, en essayant de gérer les *whiteout files*. Ou bien en suivant le
 driver `overlayfs`, en montant un système de fichier à chaque couche (dans ce
 cas, votre script devra être lancé en `root`).

tutorial/docker-internals/runc.md

@@ -9,7 +9,7 @@ montages ou volumes, ... Attention, son rôle reste limité à la mise en place
 l'environnement conteneurisé, ce n'est pas lui qui télécharge l'image, ni fait
 l'assemblage des couches de système de fichiers, entre autres.
 
-Aujourd'hui, le lancement de conteneur est faite avec `runc`, mais il est
+Aujourd'hui, le lancement de conteneur est fait avec `runc`, mais il est
 parfaitement possible d'utiliser n'importe quel autre programme à sa place, à
 partir du moment où il expose la même interface à Docker et qu'il accepte les
 *bundle* OCI.

tutorial/docker-internals/vulnerability-scan.md

@@ -12,7 +12,7 @@ l'effort de cloisonnement mis en place.
 Mais doit-on pour autant s'arrêter là et considérer que nous avons réglé
 l'ensemble des problématiques de sécurité liées aux conteneurs ?
 
-Évidemment, non : une fois nos services lancés dans des conteneurs, il ne sont
+Évidemment, non : une fois nos services lancés dans des conteneurs, ils ne sont
 pas moins exposés aux bugs et autres failles applicatives ; qu'elles soient
 dans notre code ou celui d'une bibliothèque, accessible par rebond, ...
 
@@ -20,7 +20,7 @@ Il est donc primordial de ne pas laisser ses conteneurs à l'abandon une fois
 leur image créée et envoyée en production. Nos conteneurs doivent être
 regénérés sitôt que leur image de base est mise à jour (une mise à jour d'une
 image telle que Debian, Ubuntu ou Redhat n'apparaît que pour cela) ou bien
-lorsqu'un des programmes ou l'une des bibliothèques que l'on a installés
+lorsqu'un des programmes ou l'une des bibliothèques que l'on a installées
 ensuite est mise à jour.
 
 Convaincu ? Cela sonne encore comme des bonnes pratiques difficiles à mettre en
@@ -191,7 +191,7 @@ Total: 158 (UNKNOWN: 5, LOW: 19, MEDIUM: 64, HIGH: 61, CRITICAL: 9)
 
 Les résultats sont un peu différents qu'avec `docker scan`, mais on constate
 que l'image `mysql` contient vraiment de nombreuses vulnérabilités. Même si
-elles ne sont heureusement pas forcément exploitable directement.
+elles ne sont heureusement pas forcément exploitables directement.
 
 Voyons maintenant s'il y a des différentes avec l'image `nemunaire/fic-admin` :