From 25aef1af172880e6dee4ddf0fc995707c2e62e4e Mon Sep 17 00:00:00 2001 From: Pierre-Olivier Mercier Date: Fri, 10 Apr 2026 16:19:05 +0700 Subject: [PATCH] New spelling fixes --- tutorial/3/capabilities.md | 10 ++++----- tutorial/3/cgroups.md | 4 ++-- tutorial/3/chroot.md | 4 ++-- tutorial/3/oom.md | 6 ++--- tutorial/3/project-rendu.md | 2 +- tutorial/3/rendu.md | 2 +- tutorial/4/filesystem.md | 4 ++-- tutorial/4/howto.md | 6 ++--- tutorial/4/intro.md | 6 ++--- tutorial/4/lesson.md | 2 +- tutorial/4/lsns.md | 2 +- tutorial/4/mount.md | 2 +- tutorial/4/networkns.md | 4 ++-- tutorial/4/pidns.md | 2 +- tutorial/4/project-intro.md | 2 +- tutorial/4/rendu.md | 2 +- tutorial/4/setns-samples.md | 2 +- tutorial/4/tutorial.md | 2 +- tutorial/containers/overview.md | 8 +++---- tutorial/devops/ci-about-webhook.md | 4 ++-- tutorial/devops/ci-tags.md | 2 +- tutorial/devops/devops.md | 6 ++--- tutorial/devops/publish-docker-end-gistre.md | 2 +- tutorial/devops/publish-docker-end.md | 2 +- tutorial/devops/renovate-cmd.md | 2 +- tutorial/devops/renovate-end.md | 8 +++---- tutorial/devops/renovate.md | 4 ++-- tutorial/devops/run-gistre.md | 2 +- tutorial/devops/tools-drone-runner-ansible.md | 2 +- tutorial/devops/what-gistre.md | 8 +++---- tutorial/devops/what.md | 2 +- tutorial/docker-advanced/manual.md | 2 +- tutorial/docker-advanced/security.md | 2 +- tutorial/docker-advanced/setup.md | 4 ++-- tutorial/docker-advanced/what.md | 2 +- tutorial/docker-basis/debug.md | 4 ++-- tutorial/docker-basis/ex-flask-volume.md | 4 ++-- tutorial/docker-basis/ex-flask.md | 6 ++--- tutorial/docker-basis/first.md | 6 ++--- tutorial/docker-basis/installation.md | 2 +- tutorial/docker-basis/linking-ex-fic.md | 2 +- tutorial/docker-basis/volumes.md | 4 ++-- tutorial/docker-basis/what.md | 8 +++---- tutorial/docker-internals/clair.md | 4 ++-- tutorial/docker-internals/oci.md | 6 ++--- tutorial/docker-internals/setup.md | 2 +- tutorial/docker-internals/tini.md | 8 +++---- .../docker-internals/vulnerability-scan.md | 4 ++-- tutorial/docker-orchestration/setup.md | 2 +- tutorial/docker-orchestration/stack.md | 10 ++++----- tutorial/docker-orchestration/swarm.md | 2 +- tutorial/k8s/discover.md | 22 +++++++++---------- tutorial/k8s/overview.md | 14 ++++++------ tutorial/k8s/setup.md | 9 ++++---- 54 files changed, 123 insertions(+), 122 deletions(-) diff --git a/tutorial/3/capabilities.md b/tutorial/3/capabilities.md index 3b8882f..d23be45 100644 --- a/tutorial/3/capabilities.md +++ b/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 : * [Linux Capabilities on HackTricks](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) :\ diff --git a/tutorial/3/cgroups.md b/tutorial/3/cgroups.md index 08466cd..6ebc113 100644 --- a/tutorial/3/cgroups.md +++ b/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 ``` -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*. diff --git a/tutorial/3/chroot.md b/tutorial/3/chroot.md index 30db29d..db792de 100644 --- a/tutorial/3/chroot.md +++ b/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
```bash -tar xpf alpine-minirootfs-*.tar.xz -C newroot/ +tar xpf alpine-minirootfs-*.tar.gz -C newroot/ ```
diff --git a/tutorial/3/oom.md b/tutorial/3/oom.md index 596157a..511edfe 100644 --- a/tutorial/3/oom.md +++ b/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`. diff --git a/tutorial/3/project-rendu.md b/tutorial/3/project-rendu.md index d59d3d4..84905d8 100644 --- a/tutorial/3/project-rendu.md +++ b/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 diff --git a/tutorial/3/rendu.md b/tutorial/3/rendu.md index ad17990..67e45c8 100644 --- a/tutorial/3/rendu.md +++ b/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). -:::: +::::: diff --git a/tutorial/4/filesystem.md b/tutorial/4/filesystem.md index 18a9cd0..16936da 100644 --- a/tutorial/4/filesystem.md +++ b/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*. diff --git a/tutorial/4/howto.md b/tutorial/4/howto.md index 2f6eb9b..517581d 100644 --- a/tutorial/4/howto.md +++ b/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)`. ::::: diff --git a/tutorial/4/intro.md b/tutorial/4/intro.md index 4e3ce96..9e97562 100644 --- a/tutorial/4/intro.md +++ b/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. diff --git a/tutorial/4/lesson.md b/tutorial/4/lesson.md index e8d4cbc..fabd2c9 100644 --- a/tutorial/4/lesson.md +++ b/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. ... diff --git a/tutorial/4/lsns.md b/tutorial/4/lsns.md index ec99913..720a09f 100644 --- a/tutorial/4/lsns.md +++ b/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*. diff --git a/tutorial/4/mount.md b/tutorial/4/mount.md index b40d33d..d882f63 100644 --- a/tutorial/4/mount.md +++ b/tutorial/4/mount.md @@ -168,7 +168,7 @@ esclave ne propagera pas ses nouveaux points de montage à son *maître*.
```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 diff --git a/tutorial/4/networkns.md b/tutorial/4/networkns.md index 62065dd..8adcd84 100644 --- a/tutorial/4/networkns.md +++ b/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
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. ::::: diff --git a/tutorial/4/pidns.md b/tutorial/4/pidns.md index 418b992..21ec24e 100644 --- a/tutorial/4/pidns.md +++ b/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 diff --git a/tutorial/4/project-intro.md b/tutorial/4/project-intro.md index 91105a3..a6255b8 100644 --- a/tutorial/4/project-intro.md +++ b/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. diff --git a/tutorial/4/rendu.md b/tutorial/4/rendu.md index ca1c02f..b6c9f23 100644 --- a/tutorial/4/rendu.md +++ b/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). -:::: +::::: diff --git a/tutorial/4/setns-samples.md b/tutorial/4/setns-samples.md index 0152800..9ee4f87 100644 --- a/tutorial/4/setns-samples.md +++ b/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 diff --git a/tutorial/4/tutorial.md b/tutorial/4/tutorial.md index 478a477..9dc69ee 100644 --- a/tutorial/4/tutorial.md +++ b/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. ... diff --git a/tutorial/containers/overview.md b/tutorial/containers/overview.md index 97e71b4..908b339 100644 --- a/tutorial/containers/overview.md +++ b/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, -puis le système crée une isolation, pour contenir et restreindre l'exécution -aux seules données de l'image. +Lorsqu'on lance un conteneur, une couche lecture/écriture est créée à partir +de l'image, puis le système crée une isolation, pour contenir et restreindre +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. ::::: diff --git a/tutorial/devops/ci-about-webhook.md b/tutorial/devops/ci-about-webhook.md index b47a42f..e661836 100644 --- a/tutorial/devops/ci-about-webhook.md +++ b/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. diff --git a/tutorial/devops/ci-tags.md b/tutorial/devops/ci-tags.md index 4be06dc..a9a8d05 100644 --- a/tutorial/devops/ci-tags.md +++ b/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 : diff --git a/tutorial/devops/devops.md b/tutorial/devops/devops.md index 3628dea..41cebc1 100644 --- a/tutorial/devops/devops.md +++ b/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 !). diff --git a/tutorial/devops/publish-docker-end-gistre.md b/tutorial/devops/publish-docker-end-gistre.md index 4130bb6..e1ce34a 100644 --- a/tutorial/devops/publish-docker-end-gistre.md +++ b/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. diff --git a/tutorial/devops/publish-docker-end.md b/tutorial/devops/publish-docker-end.md index f9473d3..b63846c 100644 --- a/tutorial/devops/publish-docker-end.md +++ b/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 ! diff --git a/tutorial/devops/renovate-cmd.md b/tutorial/devops/renovate-cmd.md index cc54e01..a3d5552 100644 --- a/tutorial/devops/renovate-cmd.md +++ b/tutorial/devops/renovate-cmd.md @@ -12,7 +12,7 @@ La commande que nous allons utiliser pour lancer Renovatebot est la suivante :
```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 " \ -e RENOVATE_AUTODISCOVER=true -e RENOVATE_LOG_LEVEL=info -d \ renovate/renovate diff --git a/tutorial/devops/renovate-end.md b/tutorial/devops/renovate-end.md index 348ca59..8201cc4 100644 --- a/tutorial/devops/renovate-end.md +++ b/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) : -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 :
@@ -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 diff --git a/tutorial/devops/renovate.md b/tutorial/devops/renovate.md index a97a123..11a33e3 100644 --- a/tutorial/devops/renovate.md +++ b/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. diff --git a/tutorial/devops/run-gistre.md b/tutorial/devops/run-gistre.md index fbd71fd..0acc286 100644 --- a/tutorial/devops/run-gistre.md +++ b/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 diff --git a/tutorial/devops/tools-drone-runner-ansible.md b/tutorial/devops/tools-drone-runner-ansible.md index 945aab6..0f4db91 100644 --- a/tutorial/devops/tools-drone-runner-ansible.md +++ b/tutorial/devops/tools-drone-runner-ansible.md @@ -2,7 +2,7 @@ Voici à quoi pourrait ressembler le playbook Ansible démarrant notre agent Dro
```yaml -- name: Launch drone runer +- name: Launch drone runner docker_container: name: droneci-runner image: "drone/drone-runner-docker:1" diff --git a/tutorial/devops/what-gistre.md b/tutorial/devops/what-gistre.md index f0f0a89..92a7c01 100644 --- a/tutorial/devops/what-gistre.md +++ b/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. diff --git a/tutorial/devops/what.md b/tutorial/devops/what.md index 2b8cb33..6264ef7 100644 --- a/tutorial/devops/what.md +++ b/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 diff --git a/tutorial/docker-advanced/manual.md b/tutorial/docker-advanced/manual.md index a63c5f9..f34bb9b 100644 --- a/tutorial/docker-advanced/manual.md +++ b/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 :\ diff --git a/tutorial/docker-advanced/security.md b/tutorial/docker-advanced/security.md index b819899..9cfb724 100644 --- a/tutorial/docker-advanced/security.md +++ b/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 à diff --git a/tutorial/docker-advanced/setup.md b/tutorial/docker-advanced/setup.md index f522390..3de172e 100644 --- a/tutorial/docker-advanced/setup.md +++ b/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 . +télécharger depuis . 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 diff --git a/tutorial/docker-advanced/what.md b/tutorial/docker-advanced/what.md index 63511e3..b86558e 100644 --- a/tutorial/docker-advanced/what.md +++ b/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. diff --git a/tutorial/docker-basis/debug.md b/tutorial/docker-basis/debug.md index 26a82c9..875e9b1 100644 --- a/tutorial/docker-basis/debug.md +++ b/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 :
@@ -76,7 +76,7 @@ docker container top cntr_name ```
-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`. diff --git a/tutorial/docker-basis/ex-flask-volume.md b/tutorial/docker-basis/ex-flask-volume.md index a64d22a..5a9c4ee 100644 --- a/tutorial/docker-basis/ex-flask-volume.md +++ b/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 ? diff --git a/tutorial/docker-basis/ex-flask.md b/tutorial/docker-basis/ex-flask.md index 1fa7159..31426c7 100644 --- a/tutorial/docker-basis/ex-flask.md +++ b/tutorial/docker-basis/ex-flask.md @@ -42,16 +42,16 @@ docker container run --publish 8080:8080 registry.nemunai.re/youp0m
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 :
diff --git a/tutorial/docker-basis/first.md b/tutorial/docker-basis/first.md index 170e21c..d2ace99 100644 --- a/tutorial/docker-basis/first.md +++ b/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 : - @@ -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 : diff --git a/tutorial/docker-basis/installation.md b/tutorial/docker-basis/installation.md index c3f2bea..493eedd 100644 --- a/tutorial/docker-basis/installation.md +++ b/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. diff --git a/tutorial/docker-basis/linking-ex-fic.md b/tutorial/docker-basis/linking-ex-fic.md index 003c83c..18f2200 100644 --- a/tutorial/docker-basis/linking-ex-fic.md +++ b/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 : diff --git a/tutorial/docker-basis/volumes.md b/tutorial/docker-basis/volumes.md index 882538a..ddceb85 100644 --- a/tutorial/docker-basis/volumes.md +++ b/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 à diff --git a/tutorial/docker-basis/what.md b/tutorial/docker-basis/what.md index 567b48b..eee7cda 100644 --- a/tutorial/docker-basis/what.md +++ b/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`. diff --git a/tutorial/docker-internals/clair.md b/tutorial/docker-internals/clair.md index 6fad5c5..7f2c0be 100644 --- a/tutorial/docker-internals/clair.md +++ b/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 diff --git a/tutorial/docker-internals/oci.md b/tutorial/docker-internals/oci.md index 06cd5c9..1737319 100644 --- a/tutorial/docker-internals/oci.md +++ b/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. diff --git a/tutorial/docker-internals/setup.md b/tutorial/docker-internals/setup.md index c24d492..6e8f6c1 100644 --- a/tutorial/docker-internals/setup.md +++ b/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` diff --git a/tutorial/docker-internals/tini.md b/tutorial/docker-internals/tini.md index 17e8788..f108166 100644 --- a/tutorial/docker-internals/tini.md +++ b/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 diff --git a/tutorial/docker-internals/vulnerability-scan.md b/tutorial/docker-internals/vulnerability-scan.md index f224578..7c40863 100644 --- a/tutorial/docker-internals/vulnerability-scan.md +++ b/tutorial/docker-internals/vulnerability-scan.md @@ -152,7 +152,7 @@ the selected base image
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) ```
-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`. diff --git a/tutorial/docker-orchestration/setup.md b/tutorial/docker-orchestration/setup.md index a113b80..1ed3bfd 100644 --- a/tutorial/docker-orchestration/setup.md +++ b/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. diff --git a/tutorial/docker-orchestration/stack.md b/tutorial/docker-orchestration/stack.md index 9219bc0..c8cb5ad 100644 --- a/tutorial/docker-orchestration/stack.md +++ b/tutorial/docker-orchestration/stack.md @@ -54,7 +54,7 @@ iyue3rgd0ohs myWebS replicated 1/1 nginx:latest
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 -selon un round-robin à quelle tâche il va diriger la requête. C'est grâce à ce +Lorsque plusieurs tâches s'exécutent pour ce service, le nœud d'entrée choisit +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: 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. diff --git a/tutorial/docker-orchestration/swarm.md b/tutorial/docker-orchestration/swarm.md index e2f2ae6..ea18eca 100644 --- a/tutorial/docker-orchestration/swarm.md +++ b/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. diff --git a/tutorial/k8s/discover.md b/tutorial/k8s/discover.md index bc8dd58..eab74d1 100644 --- a/tutorial/k8s/discover.md +++ b/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* -`rs/pingpong-xxxx`. Ce *replicatset* a créé un *pod* `po/pingpong-yyyy`. +`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicaset* +`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 -*replicatset* voyant un décalage entre le nombre de *pod*s attendus et le nombre +tout simplement propager ce nombre au *replicaset* existant. Puis, le +*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 diff --git a/tutorial/k8s/overview.md b/tutorial/k8s/overview.md index efd5b7e..6edc811 100644 --- a/tutorial/k8s/overview.md +++ b/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]: @@ -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/). diff --git a/tutorial/k8s/setup.md b/tutorial/k8s/setup.md index 8cf76db..5e969ac 100644 --- a/tutorial/k8s/setup.md +++ b/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", [...] ``` -Par défaut, `kubectl` va tenter de contacter le port local 2375, `kind` aura -pris soin de l'exposer pour vous au moment de la création du cluster. +Par défaut, `kubectl` va utiliser le fichier `~/.kube/config` pour contacter +l'API du cluster, `kind` aura pris soin de le configurer pour vous au moment +de la création du cluster. ::::: {.warning}