New spelling fixes

tutorial/3/capabilities.md

@@ -14,7 +14,7 @@ privilégiés outrepassaient ces tests, tandis que les autres devaient passer le
 tests de l'*effective UID*, *effective GID*, et autres groupes
 supplémentaires...
 
-Dans les années 90, ce système s'est rélévé être un peu trop basique et
+Dans les années 90, ce système s'est révélé être un peu trop basique et
 conduisait régulièrement à des abus, au moyen de vulnérabilités trouvées dans
 les programmes *setuid root*.
 
@@ -41,7 +41,7 @@ contient les hashs des mots de passe).
 C'est ainsi qu'est apparu le `suid-bit` parmi les modes de fichiers. Lorsque
 ce bit est défini sur un binaire exécutable, au moment de l'exécution, le
 contexte passe à celui du propriétaire du fichier (`root` si le propriétaire
-est `root`, mais cela fonctionne quelque soit le propriétaire du fichier : on
+est `root`, mais cela fonctionne quel que soit le propriétaire du fichier : on
 ne devient pas `root`, mais bien l'utilisateur propriétaire).\
 
 
@@ -158,7 +158,7 @@ Tout d'abord, il faut noter que chaque *thread* dispose de 5 ensembles de
 
 - ***inheritable*** (I) : est utilisé au moment de la résolution des *capabilities*
   lors de l'exécution d'un nouveau processus. Il s'agit des *capabilities* qui
-  seront transmises au processus fil. À moins d'avoir la *capability*
+  seront transmises au processus fils. À moins d'avoir la *capability*
   `CAP_SETPCAP`, cet ensemble ne peut pas avoir plus de *capability* que celles
   présentent dans l'ensemble *permitted* ;
 
@@ -331,7 +331,7 @@ struct vfs_cap_data {
 La valeur `magic` contient la version sur 1 octet, puis 3 octets sont réservés
 pour des *flags*. Actuellement un seul *flag* existe, il s'agit de
 `VFS_CAP_FLAGS_EFFECTIVE` qui détermine si la liste effective de *capabilities*
-du programme doit être remplie avec les *capabilities* *permitted* si elle doit
+du programme doit être remplie avec les *capabilities* *permitted* ou si elle doit
 rester vide (auquel cas ce sera au programme de s'ajouter les *capabilities* au
 cours de l'exécution).\
 
@@ -698,5 +698,5 @@ Et de ces quelques articles :
   <https://forums.grsecurity.net/viewtopic.php?f=7&t=2522#p10271>
 * [Linux Capabilities on HackTricks](https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities) :\
   <https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities>
-- [POSIX Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\
+* [POSIX Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\
   <https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html>

tutorial/3/cgroups.md

@@ -88,7 +88,7 @@ La principale différence entre les deux est la fusion des différents
 sous-systèmes au sein d'une même arborescence. Dans la première version, chaque
 sous-système disposait de sa propre arborescence et il fallait créer les
 groupes et associer les tâches pour chaque sous-système. Avec la seconde
-version, une seule création est nécessaire, quelque soit le nombre de
+version, une seule création est nécessaire, quel que soit le nombre de
 sous-systèmes que l'on souhaite utiliser.
 
 :::::
@@ -360,7 +360,7 @@ max
 ```
 </div>
 
-Chaque *cgroup*s définit de nombreux indicateurs et possède de nombreux
+Chaque *cgroup* définit de nombreux indicateurs et possède de nombreux
 limiteurs, n'hésitez pas à consulter la documentation associée à chaque
 *cgroup*.
 

tutorial/3/chroot.md

@@ -58,7 +58,7 @@ d'avoir de quoi bidouiller : un shell sera amplement suffisant pour commencer.
 
 ### `busybox`
 
-Queques mots, pour commencer, à propos du projet Busybox : c'est un programme
+Quelques mots, pour commencer, à propos du projet Busybox : c'est un programme
 couteau-suisse qui implémente tous les binaires vitaux pour avoir un système
 fonctionnel et utilisable : `ls`, `sh`, `cat`, mais aussi `init`, `mdev` (un
 `udev`-like, cela permet de découvrir les périphériques attachés afin de les
@@ -171,7 +171,7 @@ chroot newroot/ bash
 
 <div lang="en-US">
 ```bash
-tar xpf alpine-minirootfs-*.tar.xz -C newroot/
+tar xpf alpine-minirootfs-*.tar.gz -C newroot/
 ```
 </div>
 

tutorial/3/oom.md

@@ -6,7 +6,7 @@ Gestion de la mémoire
 Linux a une gestion de la mémoire bien particulière[^vm-overcommit] : en effet,
 par défaut, `malloc(3)` ne retournera jamais `NULL`. En se basant sur
 l'euristique qu'un bloc mémoire demandé ne sera pas utilisé directement et que
-de nombreux process ne feront pas un usage total des blocs qu'ils ont alloués,
+de nombreux processus ne feront pas un usage total des blocs qu'ils ont alloués,
 le noyau permet d'allouer plus de mémoire qu'il n'y en a réellement
 disponible. La mémoire est ainsi utilisée de manière plus efficace.
 
@@ -21,7 +21,7 @@ trouve dans l'impossibilité d'attribuer un bloc physiquement disponible, car il
 n'y en a tout simplement plus (y compris via le swap).
 
 Puisque le noyau ne peut pas honorer sa promesse et qu'il n'a plus la
-possibilité de retourner `NULL` au programme qui réclamme sa mémoire (il s'agit
+possibilité de retourner `NULL` au programme qui réclame sa mémoire (il s'agit
 sans doute d'une simple assignation de variable à ce stade), il faut trouver
 une solution si l'on veut pouvoir continuer l'exécution du programme.
 
@@ -107,7 +107,7 @@ mémoire autorisée au sein du `cgroup` ?
 :::::
 
 Eh oui, l'OOM-killer passe également lorsqu'un `cgroup` atteint la limite de
-mémoire qui lui est réservé. Dans ce cas évidemment, les processus pris en
+mémoire qui lui est réservée. Dans ce cas évidemment, les processus pris en
 compte sont ceux contenus dans le `cgroup`.
 
 

tutorial/3/project-rendu.md

@@ -5,7 +5,7 @@ Rendu
 
 Est attendu d'ici le TP suivant :
 
-- le rendu des exercice de ce TP ;
+- le rendu des exercices de ce TP ;
 - vos réponses à [l'évaluation du cours](https://virli.nemunai.re/quiz/14).
 
 Pour les GISTRE (et en bonus pour les SRS), [un

tutorial/3/rendu.md

@@ -69,4 +69,4 @@ sur `rendu3`, ... ce qui vous permet d'avoir une arborescence
 correspondant à ce qui est demandé, sans pour autant perdre votre
 travail (ou le rendre plus difficile d'accès).
 
-::::
+:::::

tutorial/4/filesystem.md

@@ -31,7 +31,7 @@ combinaison de chaque couche.
 
 ### Historique
 
-Les premières implémentations de ce type de systèmes de fichiers est apparu
+Les premières implémentations de ce type de systèmes de fichiers sont apparues
 avec les LiveCD : on disposait d'une distribution Linux complètement
 opérationnelle sur un support en lecture seule, mais on pouvait dédier un
 espace de stockage sur son disque dur (ou en RAM, au travers d'un `tmpfs`) pour
@@ -42,7 +42,7 @@ 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 fut le premier OS à
-développer cette technique dès 1986 (pour un système de fichier appelé
+développer cette technique dès 1986 (pour un système de fichiers 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*.
 

tutorial/4/howto.md

@@ -79,7 +79,7 @@ processus se fait en fonction des *flags* qui sont passés. On retrouve donc :
 Le nom du *flag* `CLONE_NEWNS` est historique et assez peu explicite
 contrairement aux autres : il désigne en fait l'espace de nom `mount`.
 
-Au départ, les *namespace*s ont étés pensés pour former un tout : une couche
+Au départ, les *namespace*s ont été pensés pour former un tout : une couche
 d'isolation complète pour les processus. Mais lors des développements suivants,
 il s'est avéré pratique de pouvoir choisir finement de quels aspects on
 souhaitait se dissocier.
@@ -108,7 +108,7 @@ semblable à :
 #define STACKSIZE (1024 * 1024)
 static char child_stack[STACKSIZE];
 
-int clone_flags = CLONE_CGROUP | CLONE_NEWNET | SIGCHLD;
+int clone_flags = CLONE_NEWCGROUP | CLONE_NEWNET | SIGCHLD;
 
 pid_t pid = clone(do_execvp,          // First function executed by child
                   child_stack + STACKSIZE, // Assume stack grows downward
@@ -155,7 +155,7 @@ extensions GNU :
 \
 
 Lorsque l'on crée un nouveau processus, on ajoute l'option `SIGCHLD` afin
-d'être notifié par signal lorsque notre processus fil a terminé son
+d'être notifié par signal lorsque notre processus fils a terminé son
 exécution. Cela permet d'être réveillé de notre `wait(2)`.
 
 :::::

tutorial/4/intro.md

@@ -89,7 +89,7 @@ processus est rendu orphelin dans ce *namespace*, il devient un fils de ce
 processus, et non un fils de l'`init` de l'arbre global.
 
 
-#### L'espace de nom `network` {.unnumbered}
+#### L'espace de noms `network` {.unnumbered}
 
 Depuis Linux 2.6.29.
 
@@ -149,9 +149,9 @@ Lorsque l'on souhaite mesurer un écoulement de temps, la méthode naïve consis
 soustraction avec l'heure de fin. Cette technique fonctionne bien, à partir du
 moment où l'on est sûr que l'horloge ne remontera pas dans le temps, parce
 qu'elle se synchronise ou que le changement d'heure été/hiver
-intervient, ... Pour palier ces situations imprévisibles, le noyau expose une
+intervient, ... Pour pallier ces situations imprévisibles, le noyau expose une
 horloge dite monotone (`CLOCK_MONOTONIC`) : cette horloge démarre à un entier
-abstrait et s'incrèmente chaque seconde qui passe, sans jamais sauter de
+abstrait et s'incrémente chaque seconde qui passe, sans jamais sauter de
 secondes, ni revenir en arrière. C'est une horloge fiable pour calculer des
 intervalles de temps.
 

tutorial/4/lesson.md

@@ -8,5 +8,5 @@ abstract: |
   Le but de cette seconde partie sur les mécanismes internes du noyau
   va nous permettre d'utiliser les commandes et les appels système
   relatifs aux espaces de noms du noyau Linux ainsi que d'appréhender
-  la complexité des sytèmes de fichiers.
+  la complexité des systèmes de fichiers.
 ...

tutorial/4/lsns.md

@@ -40,7 +40,7 @@ Cette commande nous dévoile déjà de nombreuses choses :
   contenerisé » (dans un *namespace*). Le processus initial de la machine se
   retrouve donc dans des espaces de nom, tout comme les processus d'un conteneur.
 
-- On aperçoit un genre de hiérarchie dans certain cas.
+- On aperçoit un genre de hiérarchie dans certains cas.
 
 - La première colonne nous renseigne sur l'identifiant du *namespace*.
 

tutorial/4/mount.md

@@ -168,7 +168,7 @@ esclave ne propagera pas ses nouveaux points de montage à son *maître*.
 <div lang="en-US">
 ```bash
 # Suite de l'exemple précédent
-cd /mnt/test-slave
+mkdir /mnt/test-slave
 
 # Duplication de l'accroche, sans s'occuper des éventuels sous-accroches
 mount --bind /mnt/test-shared /mnt/test-slave

tutorial/4/networkns.md

@@ -30,7 +30,7 @@ l'autre.
 :::::
 
 Afin d'amener du réseau à notre nouvel espace de nom, il va falloir lui
-attribuer des interface. En fait, nous allons pouvoir déplacer nos interfaces
+attribuer des interfaces. En fait, nous allons pouvoir déplacer nos interfaces
 réseaux, dans le *namespace* vers lequel elle doit être accessible. Une
 interface donnée ne peut se trouver que dans un seul *namespace* à la fois.
 
@@ -88,7 +88,7 @@ foo  virli
 </div>
 
 Les fichiers utilisés par `ip netns` ne sont donc rien de plus que des
-*bind-mount*. Ce qui explique qu'ils soient persistant même sans processus
+*bind-mount*. Ce qui explique qu'ils soient persistants même sans processus
 s'exécutant à l'intérieur.
 
 :::::

tutorial/4/pidns.md

@@ -98,7 +98,7 @@ donc été alloué à un processus d'initialisation de `bash`, qui s'est termin
 depuis.\
 
 Le comportement du noyau, lorsque le PID 1 se termine, est de lancer un *kernel
-panic* (car c'est un processus indispensable, notamment de part son rôle de
+panic* (car c'est un processus indispensable, notamment de par son rôle de
 parent pour tous les processus orphelin). Au sein d'un *namespace* `PID` qui
 n'est pas le *namespace* racine, le noyau appelle la fonction
 `disable_pid_allocation` qui retire le *flag* `PIDNS_HASH_ADDING` de l'espace

tutorial/4/project-intro.md

@@ -12,7 +12,7 @@ Vous allez continuer aujourd'hui le projet qui s'étendra depuis le TP précéde
 et qui consistera à réaliser la partie d'isolation de la moulinette des ACUs !
 
 Cette semaine, il faudra faire en sorte de restreindre un groupe de processus
-pour qu'il s'exécute indépendemment de votre système.
+pour qu'il s'exécute indépendamment de votre système.
 
 Il n'y a pas de restriction sur le langage utilisé, vous pouvez tout aussi bien
 utiliser du C, du C++, du Python, du shell, etc.

tutorial/4/rendu.md

@@ -62,4 +62,4 @@ sur `rendu4`, ... ce qui vous permet d'avoir une arborescence
 correspondant à ce qui est demandé, sans pour autant perdre votre
 travail (ou le rendre plus difficile d'accès).
 
-::::
+:::::

tutorial/4/setns-samples.md

@@ -38,7 +38,7 @@ main(int argc, char *argv[])
 Ce programme prend au minimum deux arguments :
 - le chemin d'un fichier d'espace de nom que l'on souhaite rejoindre (le chemin
   vers le lien symbolique donc) ;
-- le programme (et ses arguments) que l'on souhaite souhaite exécuter une fois
+- le programme (et ses arguments) que l'on souhaite exécuter une fois
   que l'on a rejoint l'espace de noms ciblé.
 
 Dans un premier temps, on ouvre le fichier passé en paramètre afin d'obtenir un

tutorial/4/tutorial.md

@@ -14,6 +14,6 @@ abstract: |
 
   Les exercices de ce cours sont à rendre au plus tard le mardi 15
   novembre 2022 à 23 h 42. Consultez les sections matérialisées par un
-  bandeau jaunes et un engrenage pour plus d'informations sur les
+  bandeau jaune et un engrenage pour plus d'informations sur les
   éléments à rendre.
 ...

tutorial/containers/overview.md

@@ -62,9 +62,9 @@ Les conteneurs
 
 On parle d'un conteneur pour désigner une instance en cours d'exécution.
 
-Lorsqu'on lance un conteneur, une copie de l'image est créée sur le disque,
+Lorsqu'on lance un conteneur, une couche lecture/écriture est créée à partir
-puis le système crée une isolation, pour contenir et restreindre l'exécution
+de l'image, puis le système crée une isolation, pour contenir et restreindre
-aux seules données de l'image.
+l'exécution aux seules données de l'image.
 
 Les conteneurs sont par nature **immuables** : on exécute le contenu d'une
 image déjà construite, on n'y change pas le code qui est exécuté et on n'y fait
@@ -90,6 +90,6 @@ avec son historique (la manière dont il a été installé, les mises à jour qu
 ont été appliquées, les configurations modifiées et les données qui ont été
 apportées au fil du temps ...). On ne peut pas dans ces circonstances
 remplacer un conteneur système par un autre, tout comme on ne peut pas
-remplacer une machine virtuelle que l'on a installée et configuré à la main.
+remplacer une machine virtuelle que l'on a installée et configurée à la main.
 
 :::::

tutorial/devops/ci-about-webhook.md

@@ -3,7 +3,7 @@
 #### Que fait Drone pour « surveiller » un dépôt ? {-}
 \
 
-Grâce aux permissions de que Drone a récupéré lors de la connexion OAuth à
+Grâce aux permissions que Drone a récupéré lors de la connexion OAuth à
 Gitea, il peut non seulement lire et récupérer le code des différents dépôts
 auxquels vous avez accès, mais il peut aussi changer certains paramètres.
 
@@ -17,5 +17,5 @@ dépôt, sous l'onglet *Déclencheurs Web*.
 
 À chaque fois qu'un événement va se produire sur le dépôt, Gitea va prévenir
 Drone qui décidera si l'évènement doit conduire à lancer l'intégration continue
-ou non, selon les instructions qu'on lui a donné dans la configuration du
+ou non, selon les instructions qu'on lui a données dans la configuration du
 dépôt.

tutorial/devops/ci-tags.md

@@ -6,7 +6,7 @@ lors que la compilation est terminée, car nous n'en faisons rien.
 
 ::::: {.exercice}
 
-Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
+Ajoutons donc une nouvelle règle à notre `.drone.yml` pour placer le binaire
 au sein de la liste des fichiers téléchargeables aux côtés des tags.
 
 Vous aurez sans doute besoin de :

tutorial/devops/devops.md

@@ -13,7 +13,7 @@ en tête.\
 Ces contraintes : tant liées à la **sécurité** (il faut s'assurer
 qu'un service n'utilise pas une bibliothèque vulnérable par exemple, donc soit
 utilisé sur un système à jour, et qu'il ne tourne pas en `root`), qu'à la
-**disponibilité** (si le service est mal codé est contient beaucoup de fuites
+**disponibilité** (si le service est mal codé et contient beaucoup de fuites
 mémoire, il ne faut pas que les autres services présents sur la même machine en
 pâtissent).
 
@@ -29,7 +29,7 @@ Le même principe est aussi valable pour Python, Ruby, ... : les développeurs
 ont toujours eu tendance à vouloir utiliser les dernières améliorations d'un
 langage, mais les administrateurs système n'ont alors pas de paquets stables
 dans la distribution. En effet, les distributions stables telles que Debian,
-RedHat ou CentOS ont des cycles de vie assez long et se concentrent plus sur la
+RedHat ou CentOS ont des cycles de vie assez longs et se concentrent plus sur la
 stabilité.\
 Cette stabilité est obtenue grâce à l'utilisation de versions éprouvées des
 langages et des bibliothèques, qui assurent un temps de maintenance et de
@@ -197,6 +197,6 @@ conçu par Netflix, qui est un programme qui va casser de manière aléatoire de
 éléments de l'environnement de production. Le but est de provoquer sciemment
 des pannes, des latences, ... à n'importe quel niveau du produit, afin d'en
 tester (brutalement certes) sa résilience. Cela oblige les développeurs, les
-opérationnels et les architectes à concevoir des services hautement tolérant
+opérationnels et les architectes à concevoir des services hautement tolérants
 aux pannes, ce qui fait que le jour où une véritable panne survient, elle n'a
 aucun impact sur la production (enfin on espère !).

tutorial/devops/publish-docker-end-gistre.md

@@ -1,4 +1,4 @@
 ### Et ensuite ?
 
 Nous avons vu une manière possible de distribuer notre projet. Essayons-en une
-autre parmis celles proposées.
+autre parmi celles proposées.

tutorial/devops/publish-docker-end.md

@@ -7,7 +7,7 @@ Vous pouvez néanmoins tester les plugins
 [`scp`](http://plugins.drone.io/appleboy/drone-scp/) ou
 [`ansible`](http://plugins.drone.io/drone-plugins/drone-ansible/) si vous avez
 une machine virtuelle avec une connexion SSH. N'hésitez pas à l'ajouter à votre
-`.droneci.yml`.
+`.drone.yml`.
 
 
 ### Profitons !

tutorial/devops/renovate-cmd.md

@@ -12,7 +12,7 @@ La commande que nous allons utiliser pour lancer Renovatebot est la suivante :
 <div lang="en-US">
 ```shell
 docker container run --name renovate --network my_ci_net \
-    -e RENOVATE_ENDPOINT="http://gitea:3000/api/v1/" RENOVATE_PLATFORM=gitea \
+    -e RENOVATE_ENDPOINT="http://gitea:3000/api/v1/" -e RENOVATE_PLATFORM=gitea \
     -e RENOVATE_TOKEN -e RENOVATE_GIT_AUTHOR="Renovatebot <renovate@sample>" \
     -e RENOVATE_AUTODISCOVER=true -e RENOVATE_LOG_LEVEL=info -d \
     renovate/renovate

tutorial/devops/renovate-end.md

@@ -2,7 +2,7 @@ Dès que le conteneur sera lancé, nous devrions voir apparaître une ou plusieu
 *pull-requests* pour le projet `youp0m`. Si votre CI est configurée
 correctement, des tests automatiques seront lancés.
 
-Le conteneur s'arrête dès qu'il a terminé d'analysé tous les dépôts. Vous
+Le conteneur s'arrête dès qu'il a terminé d'analyser tous les dépôts. Vous
 devrez le relancer si vous attendez une nouvelle action de la part de
 Renovatebot. Il est courant de le lancer entre chaque heure et 2 ou 4 fois par
 jour.
@@ -18,7 +18,7 @@ consultez la liste des éléments de configuration :
 
 Ne soyez pas effrayé par la liste interminable d'options. Il est vrai que la
 première fois, on peut se sentir submergé de possibilités, mais il faut noter
-que le projet arriver avec des options par défaut plutôt correctes, et que l'on
+que le projet arrive avec des options par défaut plutôt correctes, et que l'on
 peut facilement avoir une configuration commune pour tous nos dépôts, à travers
 les *presets*.
 
@@ -26,7 +26,7 @@ Un certain nombre de *presets* sont distribués par défaut, voici la liste
 (humainement lisible cette fois) :
 <https://docs.renovatebot.com/presets-default/>
 
-Voici un exemple de configuration que vous pouvez utilisé comme base de tous
+Voici un exemple de configuration que vous pouvez utiliser comme base de tous
 vos projets :
 
 <div lang="en-US">
@@ -69,7 +69,7 @@ Voici un exemple de fichier `default.json` que vous pourriez vouloir utiliser :
 Attention, on ne le répétera jamais assez, mais Renovatebot peut vite devenir
 infernal, car il va créer de nombreuses *pull-requests*, inlassablement. Il
 convient de rapidement activer la fusion automatique des mises à jour pour
-lesquelles vous avez confiances et pour lesquelles vous ne feriez qu'appuyer
+lesquelles vous avez confiance et pour lesquelles vous ne feriez qu'appuyer
 sur le bouton de fusion, sans même tester vous-même. La fonctionnalité est
 décrite en détail dans la documentation[^RENOVATE_AUTOMERGE] et explique les
 différentes stratégies. Néanmoins, il est nécessaire d'avoir une bonne suite de

tutorial/devops/renovate.md

@@ -1,13 +1,13 @@
 Autres outils indispensables
 ----------------------------
 
-### Maintient à jour des dépendances
+### Maintien à jour des dépendances
 
 Une opération fastidieuse, souvent oubliée sitôt le projet envoyé en
 production, c'est la mise à jour des dépendances applicatives. Fastidieux car
 il faut d'une part être informé qu'une mise à jour est disponible, c'est-à-dire
 qu'il faut suivre les mails, parfois nombreux, informant des nouvelles
-*releases*, parfois il s'agir de newslettre, ou encore parfois aucune
+*releases*, parfois il s'agit de newsletters, ou encore parfois aucune
 notification ne peut être programmée, il faut se rendre régulièrement sur un
 site pour savoir si oui ou non une mise à jour est disponible.
 

tutorial/devops/run-gistre.md

@@ -64,7 +64,7 @@ accès au périphérique correspondant au compteur.
 
 ### Conteneur LXC
 
-LXC peut s'utiliser de multiple manière différentes, y compris avec des images
+LXC peut s'utiliser de multiples manières différentes, y compris avec des images
 OCI. Choisissez la méthode qui vous semble la plus appropriée, il est attendu
 au moins un script pour lancer notre conteneur, s'il est différent d'un
 

tutorial/devops/tools-drone-runner-ansible.md

@@ -2,7 +2,7 @@ Voici à quoi pourrait ressembler le playbook Ansible démarrant notre agent Dro
 
 <div lang="en-US">
 ```yaml
-- name: Launch drone runer
+- name: Launch drone runner
   docker_container:
     name: droneci-runner
     image: "drone/drone-runner-docker:1"

tutorial/devops/what-gistre.md

@@ -44,10 +44,10 @@ fundation*, notamment les [Compute Module 3 et
 4](https://www.raspberrypi.com/products/compute-module-4/) et les [Raspberry Pi
 Zero 2 W](https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/), ainsi
 que de nombreux PCB fait par l'entreprise, à base de micro-contrôleurs AVR,
-lorsqu'il est nécessaire de pour s'interfacer avec des équipements
+lorsqu'il est nécessaire pour s'interfacer avec des équipements
 propriétaires non prévu pour l'immotique.
 
-Une grosse partie des travaux est donc réalisé avec un noyau Linux, sur du
+Une grosse partie des travaux est donc réalisée avec un noyau Linux, sur du
 matériel très performant, pour de l'embarqué.
 \
 
@@ -68,7 +68,7 @@ entraver la stabilité de la plate-forme en cas de déploiement d'un module
 défaillant.
 
 Vous êtes également chargés de jeter les bases du système d'intégration continu
-des modules. (La partie déploiement continu, sera réalisé plus tard par
+des modules. (La partie déploiement continu, sera réalisée plus tard par
 l'équipe développant le nouveau système de base, suivant le meilleur outil que
 vous retiendrez.)
 \
@@ -90,5 +90,5 @@ quelques tests automatiques. Puis nous publierons automatiquement le binaire
 `linky2influx` comme fichier associé à un tag au sein de l'interface web du
 gestionnaire de versions.
 
-Nous testerons enfin différentes solution pour déployer notre binaire, afin
+Nous testerons enfin différentes solutions pour déployer notre binaire, afin
 d'établir quelle est la solution adéquate.

tutorial/devops/what.md

@@ -13,7 +13,7 @@ le projet `youp0m`, que l'on connaît déjà bien.
 \
 
 Dans un premier temps, on voudra juste compiler notre projet, pour s'assurer
-que chaque *commmit* poussé ne contient pas d'erreur de compilation (dans
+que chaque *commit* poussé ne contient pas d'erreur de compilation (dans
 l'environnement défini comme étant celui de production, donc avec une version
 précise des outils de compilation). Ensuite, nous ajouterons quelques tests
 automatiques, puis nous publierons automatiquement le binaire `youp0m` comme

tutorial/docker-advanced/manual.md

@@ -32,7 +32,7 @@ docker container run -p 8086:8086 -d --name mytsdb influxdb:1.8
 ::::: {.warning}
 
 Remarquez que nous n'utilisons pas la version 2 d'InfluxDB. Sa mise en
-place est plus contraignantes pour faire de simples tests. Si vous
+place est plus contraignante pour faire de simples tests. Si vous
 souhaitez tout de même utiliser la dernière version de la stack TICK,
 vous pouvez consulter le `README` du conteneur sur le Docker Hub :\
 <https://hub.docker.com/_/influxdb>

tutorial/docker-advanced/security.md

@@ -59,7 +59,7 @@ difficulté du rebond.
 
 Un certain nombre de capabilities Linux sont retirées par Docker au
 moment de l'exécution du conteneur, on peut utiliser les options
-`--cap-add` et `--cap-drop` pour respectivement ajouter et retirer une
+`--cap-add` et `--cap-drop` pour respectivement ajouter et retirer des
 capabilities.
 
 Notez que l'option `--privileged` ne retire aucune capabilities à

tutorial/docker-advanced/setup.md

@@ -12,7 +12,7 @@ communauté, et parfois même appropriées par Docker.
 Dans cette partie, nous allons avoir besoin du plugin `docker-compose`.
 
 L'équipe en charge du projet met à disposition un exécutable que nous pouvons
-téléchargeant depuis <https://github.com/docker/compose/releases>.
+télécharger depuis <https://github.com/docker/compose/releases>.
 
 Ajoutez l'exécutable dans le dossier des plugins : `$HOME/.docker/cli-plugins`
 (sans oublier de `chmod +x` !).
@@ -21,7 +21,7 @@ Ajoutez l'exécutable dans le dossier des plugins : `$HOME/.docker/cli-plugins`
 
 Autrefois, `docker-compose` était un script tiers que l'on utilisait
 indépendamment de Docker. Le projet, historiquement écrit en Python, a été
-entièrement réécrit récemment afin qu'il s'intégre mieux dans l'écosystème.
+entièrement réécrit récemment afin qu'il s'intègre mieux dans l'écosystème.
 
 Vous trouverez encore de nombreux articles vous incitant à utiliser
 `docker-compose`. Dans la plupart des cas, vous pouvez simplement remplacer par

tutorial/docker-advanced/what.md

@@ -44,5 +44,5 @@ s'agit d'un mécanisme de séries temporelles (*Time Series*) moderne, que l'on
 peut utiliser pour stocker toute sorte de données liées à un indice temporel.
 
 La pile logicielle TICK propose de collecter des métriques, en les enregistrant
-dans une base de données adaptées et permet ensuite de les ressortir sous
+dans une base de données adaptée et permet ensuite de les ressortir sous
 forme de graphiques ou de les utiliser pour faire des alertes intelligentes.

tutorial/docker-basis/debug.md

@@ -13,7 +13,7 @@ Consulter les journaux
 ----------------------
 
 La première étape consiste bien souvent à regarder ce que le conteneur affiche
-sur ses sorties standard et d'erreur. Lorsqu'il est lancé en monde *daemon*, il
+sur ses sorties standard et d'erreur. Lorsqu'il est lancé en mode *daemon*, il
 convient d'utiliser la commande :
 
 <div lang="en-US">
@@ -76,7 +76,7 @@ docker container top cntr_name
 ```
 </div>
 
-Cela liste tous les processus rattaché au conteneur nommé : à la fois les
+Cela liste tous les processus rattachés au conteneur nommé : à la fois les
 processus démarrés par le `run`, mais également les éventuels processus
 rattachés par `exec`.
 

tutorial/docker-basis/ex-flask-volume.md

@@ -38,9 +38,9 @@ ici, puisque c'est ce volume qui assure la persistance des images.
 
 :::::
 
-Nos images sont bien persistantes d'une instance à l'autre de notre contenu.
+Nos images sont bien persistantes d'une instance à l'autre de notre conteneur.
 
-Nous voici prêt à déployer en production notre service, sans crainte de perdre
+Nous voici prêts à déployer en production notre service, sans crainte de perdre
 les jolies contributions. Mais... est-ce que ce sera suffisant pour répondre aux
 milliers de visiteurs attendus ?
 

tutorial/docker-basis/ex-flask.md

@@ -42,16 +42,16 @@ docker container run --publish 8080:8080 registry.nemunai.re/youp0m
 </div>
 
 Cet argument va faire effectuer à Docker une étape supplémentaire lorsqu'il
-démarerra le conteneur : il va devoir mettre en place une redirection du port
+démarrera le conteneur : il va devoir mettre en place une redirection du port
 de notre système local (8080) vers le port 8080 du conteneur.
 
 ![Le port 8080 est redirigé vers le conteneur](published-ports.png "Le port 8080 est redirigé vers le conteneur"){ width=70% }
 
 ::::: {.question}
 
-#### Peut-on démarrer plusieurs conteurs utilisant le même port de notre système local ? {-}
+#### Peut-on démarrer plusieurs conteneurs utilisant le même port de notre système local ? {-}
 
-Si l'on essai de lancer deux fois la commande de notre dernier `run`, nous
+Si l'on essaie de lancer deux fois la commande de notre dernier `run`, nous
 obtenons l'erreur suivante :
 
 <div lang="en-US">

tutorial/docker-basis/first.md

@@ -33,7 +33,7 @@ Le daemon assemble ensuite l'image et met en place les différents éléments
 d'isolation pour préparer l'exécution de notre conteneur.
 
 Enfin, il lance la commande qui sera le premier processus du conteneur. Cette
-commande fait parti des métadonnées de l'image. Le processus ainsi lancé est un
+commande fait partie des métadonnées de l'image. Le processus ainsi lancé est un
 peu particulier : il obtient les mêmes caractéristiques que le PID 1 de notre
 système ('init').
 
@@ -57,7 +57,7 @@ afficher beaucoup de contenu pour faire son choix. Aussi, il est souvent plus
 pratique d'aller explorer les registres en passant directement par leur interface
 web.
 
-Vous trouverez forcément votre bonheur parmi les images proposées par les deux
+Vous trouverez forcément votre bonheur parmi les images proposées par les trois
 principaux registres :
 
 - <https://hub.docker.com/>
@@ -358,7 +358,7 @@ c'est toujours le daemon qui exécute directement les commandes et gère les
 entrées et sorties standards et d'erreur. Avec l'option `--interactive`, on
 s'assure que l'entrée standard ne sera pas fermée (`close(2)`). Nous demandons
 également l'allocation d'un TTY, sans quoi `bash` ne se lancera pas en mode
-interractif[^bashnointer].
+interactif[^bashnointer].
 
 [^bashnointer]: Mais il sera possible de l'utiliser sans allouer de TTY, comme
     dans cet exemple :

tutorial/docker-basis/installation.md

@@ -54,7 +54,7 @@ distribution :
 
 ### Sous Windows et macOS
 
-Bien que les fonctionnalités de contenerisation de Docker que nous utiliserons
+Bien que les fonctionnalités de conteneurisation de Docker que nous utiliserons
 ne soient disponibles que sous Linux, il est possible d'utiliser Docker de
 manière déportée : le daemon Docker tournera dans une machine virtuelle Linux,
 mais vous pourrez interagir avec lui via votre ligne de commande habituelle.

tutorial/docker-basis/linking-ex-fic.md

@@ -8,7 +8,7 @@ indiquent que le service cherche à se connecter à une base de données. Il va
 donc falloir lier notre interface d'administration à [un conteneur
 MariaDB](https://hub.docker.com/_/mariadb).
 
-Ne vous embêtez pas avec les mots de passes des services, initialisez la base
+Ne vous embêtez pas avec les mots de passe des services, initialisez la base
 de données avec le nom d'utilisateur et le mot de passe par défaut. Vous les
 obtiendrez en lisant la documentation de l'image fic-admin :
 <https://hub.docker.com/r/nemunaire/fic-admin/>

tutorial/docker-basis/volumes.md

@@ -3,12 +3,12 @@
 Stockage de données applicatives
 ================================
 
-Il est généralement toujours possible d'écrire dans le système de fichier de
+Il est généralement toujours possible d'écrire dans le système de fichiers de
 notre conteneur. (Cela n'affecte pas l'image, chaque conteneur est démarré à
 partir de l'image originale.) Cependant, il n'est pas recommandé de chercher à
 stocker des données ainsi. En effet, il n'est pas aisé de récupérer ces données
 une fois l'exécution du conteneur terminée ; les données peuvent même être
-détruite si on a lancé le conteneur avec l'option `--rm`.
+détruites si on a lancé le conteneur avec l'option `--rm`.
 
 Docker met donc à notre disposition plusieurs mécanismes pour que les données
 de nos applications persistent et soient prêtes à être migrées d'un conteneur à

tutorial/docker-basis/what.md

@@ -3,14 +3,14 @@ Composition de Docker
 
 Docker est une suite d'outils de haut niveau, permettant d'utiliser des
 *conteneurs*. Le projet en lui-même utilise de nombreuses dépendances,
-originellement développées par l'entreprise Docker Inc., puis laissé dans le
+originellement développées par l'entreprise Docker Inc., puis laissées dans le
 domaine public lors des efforts de standardisation en 2015.
 
 Commençons par planter le décor, en détaillant les principes de base de Docker.
 
 ### Séparation des compétences
 
-Le projet s'article autour d'un daemon lancé au démarrage de la machine, avec
+Le projet s'articule autour d'un daemon lancé au démarrage de la machine, avec
 lequel on interagit via un client (le programme `docker`). La communication
 entre le daemon et le client s'effectuant sur une API REST généralement au
 travers d'une socket.
@@ -71,7 +71,7 @@ de nombreuses directions, chacun voulant tirer la couverture vers soi, et
 l'équipe maintenant le projet a parfois eu du mal à arbitrer les bonnes choses
 à ajouter ou non au projet.
 
-Afin de pallier aux besoins complémentaires, parfois accessoires, parfois
+Afin de pallier les besoins complémentaires, parfois accessoires, parfois
 salvateurs, un système de plugins a été intégré. Il permet d'appeler d'autres
 programmes comme s'il s'agissait de composants de Docker.
 
@@ -85,7 +85,7 @@ utilisateurs de notre machine ou dans `$HOME/.docker/` si l'on veut l'installer
 seulement pour nous.
 
 Par exemple, les plugins ajoutant des commandes iront dans
-`$HOME/.docker/cli-plugins`. Par exemple, si l'on souhaite pouvoir disposer de
+`$HOME/.docker/cli-plugins`. Si l'on souhaite pouvoir disposer de
 la commande `docker compose`, on téléchargera le plugin vers l'emplacement :
 `$HOME/.docker/cli-plugins/docker-compose`.
 

tutorial/docker-internals/clair.md

@@ -2,7 +2,7 @@
 
 Un outil complet pour 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
+informations mises à disposition par les équipes de sécurité des principales
 distributions, cela alimente en continu une base de données qui sera accédé au
 moment de l'analyse.
 
@@ -57,7 +57,7 @@ export POSTGRES_PASSWORD=$(openssl rand -base64 16)
 
 Parmi les volumes partagés avec `clair`, il y a un dossier
 `./clair_config`. Notez le `./` au début, qui indique que le dossier sera
-recherché relativement par rapport à l'emplacement du `docker-compsose.yml`.
+recherché relativement par rapport à l'emplacement du `docker-compose.yml`.
 
 Dans ce dossier, vous devez placer un exemplaire du fichier de configuration
 dont un [exemple se trouve dans le dépôt du

tutorial/docker-internals/oci.md

@@ -4,7 +4,7 @@ Open Container Initiative
 =========================
 
 Formée en juin 2015, l'Open Container Initiative (OCI) a pour but d'établir le
-standard commun aux programmes de contenerisation, afin d'éviter une
+standard commun aux programmes de conteneurisation, afin d'éviter une
 fragmentation de l'écosystème.
 
 ## Spécifications
@@ -101,7 +101,7 @@ 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
+est spécifié : il est nécessaire de passer par des formats standards (comme
 les tarballs), contenant éventuellement des fichiers et dossiers spéciaux
 représentant les modifications ou les suppressions éventuelles de la couche.
 
@@ -125,5 +125,5 @@ Cela permet de récupérer des images, mais aussi d'en envoyer, en gérant
 
 \
 
-Nous allons voir plus en détails, dans les chapitres suivantes, ce que l'on
+Nous allons voir plus en détails, dans les chapitres suivants, ce que l'on
 peut tirer de ces spécifications, en décortiquant des usages précis.

tutorial/docker-internals/setup.md

@@ -3,7 +3,7 @@
 Mise en place
 =============
 
-Les exercices suivants nécessiteront l'installation de plusieurs outils..
+Les exercices suivants nécessiteront l'installation de plusieurs outils.
 
 - `docker-compose`
 - `venv`

tutorial/docker-internals/tini.md

@@ -14,7 +14,7 @@ exécution. Puis, lorsqu'il aura terminé, celui-ci sera passé dans un statut
 
 Parmi ses attributions, `init`, le PID 1 de notre système, est le processus qui
 récupère les processus orphelins du système. Lorsque le parent direct d'un
-processus meurt, ses fils sont reparenté sous le processus `init` et ils
+processus meurt, ses fils sont reparentés sous le processus `init` et ils
 obtiennent alors comme `ppid` 1. Ils ne conservent pas le PID de leur défunt
 parent.
 
@@ -29,7 +29,7 @@ l'argument `PR_SET_CHILD_SUBREAPER`.
 :::::
 
 Docker procure une isolation, notamment au travers du *namespace* PID : les
-processus faisant parti du même *namespace* ne voient seulement qu'une partie
+processus faisant partie du même *namespace* ne voient seulement qu'une partie
 de l'arbre de processus de l'hôte, et notamment, un PID 1 est recréé, il s'agit
 du premier processus à s'exécuter dans le *namespace*.
 
@@ -107,7 +107,7 @@ shell.
 
 Voici donc une raison supplémentaire de préférer `tini` à `bash` (ou à rien du
 tout). D'autant plus qu'à moins d'avoir préparé la fin d'exécution, `bash` ne
-retournera pas le code d'erreur de la commande que l'on a lancé, mais plutôt 0.
+retournera pas le code d'erreur de la commande que l'on a lancée, mais plutôt 0.
 
 
 ## Intégration dans les `Dockerfile`
@@ -121,7 +121,7 @@ semble particulièrement indiqué.
 L'utilisation par le paramètre `--init` du `run` n'est pas recommandée et
 devrait se limiter aux cas où l'image a été construite par quelqu'un qui
 n'avait pas en tête ces contraintes. Lorsque l'on sait que des zombies ne vont
-pas être géré par leurs parents, le mainteneur se doit d'ajouter `tini` dans
+pas être gérés par leurs parents, le mainteneur se doit d'ajouter `tini` dans
 son `Dockerfile`. La méthode recommandée est de l'installer par les paquets de
 la distribution (`apt-get install tini`, `apk add tini`, ...). Néanmoins, dans
 le cas d'une distribution qui ne possèderait pas le paquet, il convient

tutorial/docker-internals/vulnerability-scan.md

@@ -152,7 +152,7 @@ the selected base image
 </div>
 
 Ce dernier exemple est sans appel : `mysql` est une image officielle, et sa
-dernière version à l'écriture de ses lignes contient pas moins de 24
+dernière version à l'écriture de ces lignes contient pas moins de 24
 vulnérabilités dont 9 *high* (pourtant corrigées dans des versions suivantes).
 
 
@@ -216,7 +216,7 @@ Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
 ```
 </div>
 
-Nous pouvons remarque que Trivy, en plus de faire l'analyse statique des
+Nous pouvons remarquer que Trivy, en plus de faire l'analyse statique des
 vulnérabilités de l'image, a aussi fait une analyse des dépendances du binaire
 `/srv/youp0m`.
 

tutorial/docker-orchestration/setup.md

@@ -33,7 +33,7 @@ chmod +x /usr/bin/docker-machine
 
 ### Support de KVM
 
-Le programme support de base de nombreux environnement, dont VirtualBox et
+Le programme supporte de base de nombreux environnements, dont VirtualBox et
 Hyper-V. Bien d'autres environnements peuvent être supportés, au moyen de
 plug-ins.
 

tutorial/docker-orchestration/stack.md

@@ -54,7 +54,7 @@ iyue3rgd0ohs    myWebS      replicated    1/1         nginx:latest
 </div>
 
 Vous pouvez constater que sur l'un des nœuds, sur lequel votre serveur aura été
-déployé, le tâche apparaît dans la liste des conteneurs !
+déployé, la tâche apparaît dans la liste des conteneurs !
 
 
 Rien de très excitant pour le moment, car nous ne pouvons pas vraiment accéder
@@ -86,8 +86,8 @@ particulièrement.
 Essayons de nous connecter aux ports 80 des deux IP correspondant à nos deux
 nœuds. Vous devriez voir la même page.
 
-Lorsque plusieurs tâches s'exécutent pour ce service, le nœud d'entrée choisi
+Lorsque plusieurs tâches s'exécutent pour ce service, le nœud d'entrée choisit
-selon un round-robin à quelle tâche il va diriger la requête. C'est grâce à ce
+selon un round-robin vers quelle tâche il va diriger la requête. C'est grâce à ce
 mécanisme qu'il est possible de faire de la répartition de charge très
 simplement.
 
@@ -103,7 +103,7 @@ consulter la documentation à ce sujet :\
 
 On parle depuis tout à l'heure de lancer plusieurs tâches pour le même
 service. La mise à l'échelle, c'est ça : exécuter plusieurs conteneurs pour la
-même tâche afin de mieux répartir la charge, idéalement sur des machines
+même service afin de mieux répartir la charge, idéalement sur des machines
 physiques différentes.
 
 Ce qui se fait souvent avec beaucoup de douleur hors de Docker, se résume ici
@@ -172,5 +172,5 @@ services:
 </div>
 
 Certaines informations comme les ressources, permettent à l'orchestrateur de
-mieux choisir le *workers* de destination, en fonction de certaines de ses
+mieux choisir le *worker* de destination, en fonction de certaines de ses
 caractéristiques.

tutorial/docker-orchestration/swarm.md

@@ -7,7 +7,7 @@ Regroupés au sein d'un cluster (on parle de *swarm* pour Docker), chaque
 *Docker engine* représente un nœud (*node*) dans lequel on va déployer des
 *services*.
 
-Certain nœuds ont un rôle de *manager*, parmi ceux-ci, un seul est élu leader et
+Certains nœuds ont un rôle de *manager*, parmi ceux-ci, un seul est élu leader et
 prendra les décisions d'orchestration. Les autres sont là pour prendre le
 relais en cas de dysfonctionnement sur le manager élu.
 

tutorial/k8s/discover.md

@@ -26,7 +26,7 @@ Les `type`s que vous pouvez découvrir sont ceux que l'on a vu à la
 section précédente : `node`, `pod`, ...
 
 La commande `describe` permet d'afficher l'état tel qu'il est attendu
-et tel qu'il est actuellement (cela permet de se rendre lorsque les
+et tel qu'il est actuellement (cela permet de se rendre compte lorsque les
 deux divergent).
 
 
@@ -110,7 +110,7 @@ kindnet-2gwlp                                1/1     Running   0          13m
 ```
 
 Eh oui ! De nombreux services de base de Kubernetes tournent dans des
-conteneurs... qu'il gèren lui-même ! Notamment :
+conteneurs... qu'il gère lui-même ! Notamment :
 
 - `etcd` : notre base de données clef/valeur,
 - `kube-apiserver` : l'API REST avec qui communique `kubectl`,
@@ -166,7 +166,7 @@ kubectl logs -f pingpong
 Notez ici l'option -f qui permet de suivre les logs en direct.
 
 
-Notre premier test ayant réussi, nous pouvons arrêter de DDos Cloudflare :
+Notre premier test ayant réussi, nous pouvons arrêter de DDoS Cloudflare :
 
 ```bash
 kubectl delete pods pingpong
@@ -211,16 +211,16 @@ haut niveau et sont là pour s'assurer que les migrations se font en douceur :
 elles vont permettre de basculer progressivement les *pod*s d'une version X à une
 version Y (par exemple si l'on change notre ping d'alpine 3.16 vers alpine
 edge), mais éventuellement de revenir sur la version X si besoin, en cours de
-migration. Elles délèguent ensuite aux *replicatsets* la gestion des *pod*s.
+migration. Elles délèguent ensuite aux *replicasets* la gestion des *pod*s.
 
-Le *replicatset* est là pour indiquer le nombre de *pod*s que l'on désire et
+Le *replicaset* est là pour indiquer le nombre de *pod*s que l'on désire et
 s'assurer que le nombre de *pod*s actuellement lancé est bien en adéquation avec
 le nombre de *pod*s attendu.
 \
 
 Pour résumer : `kubectl` a créé une tâche de déploiement
-`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicatset*
+`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicaset*
-`rs/pingpong-xxxx`. Ce *replicatset* a créé un *pod* `po/pingpong-yyyy`.
+`rs/pingpong-xxxx`. Ce *replicaset* a créé un *pod* `po/pingpong-yyyy`.
 
 
 #### Passage à l'échelle : facile ?
@@ -232,8 +232,8 @@ kubectl scale deploy/pingpong --replicas 3
 ```
 
 À ce stade, comme nous ne modifions que le nombre de replicats, Kubernetes va
-tout simplement propager ce nombre au *replicatset* existant. Puis, le
+tout simplement propager ce nombre au *replicaset* existant. Puis, le
-*replicatset* voyant un décalage entre le nombre de *pod*s attendus et le nombre
+*replicaset* voyant un décalage entre le nombre de *pod*s attendus et le nombre
 de *pod*s en cours d'exécution, il va en lancer de nouveaux, afin de répondre à
 la demande.
 \
@@ -245,11 +245,11 @@ kubectl delete pod pingpong-yyyy-zzz
 ```
 
 Cela supprime bien un *pod*, mais un autre est relancé instantanément car le
-*replicatset* constate une différence dans le nombre attendu.
+*replicaset* constate une différence dans le nombre attendu.
 
 Si nous voulons arrêter de DDoS Google/Cloudflare, il ne s'agit pas de tuer
 chacun des *pod*s un par un, car de nouveaux seraient créés par le
-*replicatset*. Si l'on supprime le *replicatset*, la tâche de déploiement en
+*replicaset*. Si l'on supprime le *replicaset*, la tâche de déploiement en
 recréera un similaire (avec de nouveaux *pod*s).
 
 Pour arrêter nos conteneurs, il convient donc de supprimer la tâche de

tutorial/k8s/overview.md

@@ -4,7 +4,7 @@ Vue d'ensemble de Kubernetes
 *Kubernetes* (prononcé Ku-ber-né-tice[^prononciation-k8s] en grec) est un
 système *open source* d'orchestration et de gestion de conteneurs. C'est-à-dire
 qu'il se charge de faire coller constamment la liste des conteneurs qu'il voit
-vivant aux spécifications qu'on lui aura demandées.
+vivants aux spécifications qu'on lui aura demandées.
 
 [^prononciation-k8s]: <https://github.com/kubernetes/kubernetes/issues/44308>
 
@@ -37,7 +37,7 @@ d’une série de nœuds *workers*.
 
 Le(s) *control-plane(s)* sont en charge de prendre des décisions globales sur
 le déroulement des opérations du cluster : cela va de la détection d'anomalies
-sur le cluster ou encore le traiter d'événements et l'organisation de leur
+sur le cluster ou encore le traitement d'événements et l'organisation de leur
 réponse, ...
 
 On retrouve sur ces nœuds centraux les composants suivants :
@@ -52,7 +52,7 @@ L'ordonnanceur
   disponibles.
 
 Les contrôleurs
-: Ils vont contrôler l'état des différents composants déployées au sein du
+: Ils vont contrôler l'état des différents composants déployés au sein du
   cluster, pour s'assurer d'être dans l'état désiré. Il y a en fait plusieurs
   contrôleurs ayant chacun la responsabilité de veiller sur une partie des
   objets, ainsi que le `cloud-controller-manager` lorsque le cluster se trouve
@@ -65,11 +65,11 @@ Les contrôleurs
 \
 
 
-Chaque nœud (généralement, le nœud *master* est également *worker*) est utilisé
+Chaque nœud (généralement, le nœud *control-plane* est également *worker*) est utilisé
 via deux composants :
 
 `kubelet`
-: C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
+: C'est l'agent qui va se charger de créer les conteneurs et les gérer, afin
   de répondre aux spécifications demandées par les *control-planes*.
 
 `kube-proxy`
@@ -109,14 +109,14 @@ supprimer ou de vérifier qu'une interface va bien.
 
 Ainsi, à la création d'un conteneur, Kubernetes va laisser aux plugins CNI le
 loisir d'ajouter les interfaces réseaux adéquates, d'allouer l'adresse IP, de
-configurer les routes, les règles de pare-feu, ... quelque soit
+configurer les routes, les règles de pare-feu, ... quelle que soit
 l'infrastructure et la complexité du réseau utilisé derrière.
 \
 
 Terminons en ajoutant qu'un serveur DNS faisant autorité est nécessaire pour
 que, de la même manière que Docker, il soit possible d'accéder aux autres
 conteneurs via leur nom (sans qu'il ne soit nécessaire de le déclarer sur un
-serveur de noms public). Il n'y a pas de projet de porté par Kubernetes pour
+serveur de noms public). Il n'y a pas de projet porté par Kubernetes pour
 cela, mais cette tâche est généralement assurée par
 [CoreDNS](https://coredns.io/).
 

tutorial/k8s/setup.md

@@ -17,7 +17,7 @@ leurs infrastructures, choisissent de passer par un prestataire. L'entreprise
 délègue donc la gestion de son/ses cluster(s) à une autre entreprise, dont
 c'est le cœur de métier. La plupart du temps, il va s'agir d'Amazon (via
 [Elastic Kubernetes Service](https://aws.amazon.com/fr/eks/)), d'Azure
-[Kubernetes
+([Kubernetes
 Service](https://azure.microsoft.com/fr-fr/services/kubernetes-service/)) ou
 Google ([Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)), mais
 d'autres acteurs plus petits existent aussi
@@ -38,7 +38,7 @@ fonctionne.\
 Chaque distribution de *Kubernetes* aura donc pris soin de mettre à disposition
 des composants pour un usage plus ou moins spécifique. En dehors des composants
 strictement nécessaires qui ne changent pas, on verra d'une distribution à
-l'autre des choix quant au moteur d'exécution de conteneurs (tantot CRI-O,
+l'autre des choix quant au moteur d'exécution de conteneurs (tantôt CRI-O,
 Containerd, KataContainers, ...), le réseau sera géré par une brique spécifique
 (Flannel, Calico, Canal, Wave, ...), le stockage peut également faire l'objet
 de choix.\
@@ -147,8 +147,9 @@ Server Version: Version.Info{Major:"1", Minor:"21", GitVersion:"v1.25.3", [...]
 ```
 </div>
 
-Par défaut, `kubectl` va tenter de contacter le port local 2375, `kind` aura
+Par défaut, `kubectl` va utiliser le fichier `~/.kube/config` pour contacter
-pris soin de l'exposer pour vous au moment de la création du cluster.
+l'API du cluster, `kind` aura pris soin de le configurer pour vous au moment
+de la création du cluster.
 
 ::::: {.warning}