diff --git a/tutorial/3/cgroups.md b/tutorial/3/cgroups.md index b334094..23a2a7c 100644 --- a/tutorial/3/cgroups.md +++ b/tutorial/3/cgroups.md @@ -18,7 +18,7 @@ spécifique : - [`blkio` (`io` dans la v2) :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html) limites et statistiques de bande passante sur les disques ; -- `cpu` : cycles CPU minimum garantis ; +- `cpu` : cycles CPU minimums garantis ; - [`cpuacct` (inclus dans `cpu` dans la v2) :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/cpuacct.html) statistiques du temps CPU utilisé ; @@ -55,7 +55,7 @@ l'une de ces trois situations : la nouvelle version des `cgroup`s. - Votre dossier `/sys/fs/cgroup` contient d'autres dossiers au nom des - sous-systèmes que l'on a listé ci-dessus : il s'agit des `cgroup`s v1. + sous-systèmes que l'on a listés ci-dessus : il s'agit des `cgroup`s v1. - Votre dossier `/sys/fs/cgroup` est vide ou inexistant, vous pouvez choisir d'utiliser la version de votre choix : @@ -94,7 +94,7 @@ sous-systèmes que l'on souhaite utiliser. ### Création d'un nouveau groupe -Les *cgroup*s sont organisé autour d'une arborescence de groupe, où chaque +Les *cgroup*s sont organisés autour d'une arborescence de groupe, où chaque groupe est représenté par un dossier. Il peut bien évidemment y avoir des sous-groupes, en créant des dossiers dans les dossiers existants, etc.\ @@ -192,7 +192,7 @@ adaptés. ### Consultation de l'état En affichant le contenu du dossier `virli`, nous pouvions constater que -celui-ci contenait déjà un certain nombre de fichiers. Certains d'entre-eux +celui-ci contenait déjà un certain nombre de fichiers. Certains d'entre eux sont en lecture seule et permettent de lire des statistiques instantanées sur le groupe ; tandis que d'autres sont des propriétés que nous pouvons modifier. @@ -252,7 +252,7 @@ mémoire utilisée par le groupe monitoré. Vous pouvez utiliser un programme comme `memhog`[^memhog] pour remplir rapidement votre mémoire. -[^memhog]: Ce programme fait parti du paquet `numactl`, mais vous trouverez une +[^memhog]: Ce programme fait partie du paquet `numactl`, mais vous trouverez une version modifiée plus adaptée à nos tests sur . diff --git a/tutorial/3/chroot.md b/tutorial/3/chroot.md index 4f5f302..e4ac337 100644 --- a/tutorial/3/chroot.md +++ b/tutorial/3/chroot.md @@ -43,7 +43,7 @@ chroot newroot /busybox ash Nous voici donc maintenant dans un nouveau shell (il s'agit d'`ash`, le shell de `busybox`). -Jusque là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour +Jusque-là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour `bash` :
diff --git a/tutorial/3/oom.md b/tutorial/3/oom.md index 0d020ae..801637d 100644 --- a/tutorial/3/oom.md +++ b/tutorial/3/oom.md @@ -58,7 +58,7 @@ ce sujet :\ #### À vous de jouer {-} Continuons l'exercice précédent où nous avions [fixé les -limites](#Fixer-des-limites) de mémoire que pouvez réserver les processus de +limites](#Fixer-des-limites) de mémoire que pouvaient réserver les processus de notre groupe. Que se passe-t-il alors si `memhog` dépasse la quantité de mémoire autorisée dans le `cgroup` ? diff --git a/tutorial/3/pseudofs.md b/tutorial/3/pseudofs.md index 188ea18..9dd8c45 100644 --- a/tutorial/3/pseudofs.md +++ b/tutorial/3/pseudofs.md @@ -40,12 +40,12 @@ apporter des modifications. Linux emploie de nombreux systèmes de fichiers virtuels : -- `/proc` : contient, principalement, la liste des processus (`top` et ses +- `/proc` : contiens, principalement, la liste des processus (`top` et ses dérivés se contentent de lire les fichiers de ce point de montage) ; -- `/proc/sys` : contient la configuration du noyau ; -- `/sys` : contient des informations à propos du matériel (utilisées notamment +- `/proc/sys` : contiens la configuration du noyau ; +- `/sys` : contiens des informations à propos du matériel (utilisées notamment par `udev` pour peupler `/dev`) et des périphériques (taille des tampons, - clignottement des DELs, ...) ; + clignotement des DELs, ...) ; - `/sys/firmware/efi/efivars` : pour accéder et modifier les variables de l'UEFI ; - ... diff --git a/tutorial/3/seccomp.md b/tutorial/3/seccomp.md index b199446..0756797 100644 --- a/tutorial/3/seccomp.md +++ b/tutorial/3/seccomp.md @@ -55,7 +55,7 @@ autorisé conduit à un `SIGKILL` du processus. Plus modulable que le mode strict, le mode de filtrage permet une grande amplitude en permettant au programmeur de définir finement quels appels -systèmes le programme est autorisé à faire ou non, et quel sentence est +systèmes le programme est autorisé à faire ou non, et quelle sentence est exécutée en cas de faute. Notons que les processus fils issus (`fork(2)` ou `clone(2)`) d'un processus diff --git a/tutorial/4/howto.md b/tutorial/4/howto.md index 21fcb18..219ac16 100644 --- a/tutorial/4/howto.md +++ b/tutorial/4/howto.md @@ -6,7 +6,7 @@ Utiliser les *namespace*s ### S'isoler dans un nouveau *namespace* Si l'on voit l'isolation procurée par les *namespace*s en parallèle avec les -machines virtuelle, on peut se dire qu'il suffit d'exécuter un appel système +machines virtuelles, on peut se dire qu'il suffit d'exécuter un appel système pour arriver dans un conteneur bien isolé. Cependant, le choix fait par les développeurs de Linux a été de laisser le choix des espaces de noms dont on veut se dissocier. diff --git a/tutorial/4/lifetime.md b/tutorial/4/lifetime.md index e88bba5..5b595f5 100644 --- a/tutorial/4/lifetime.md +++ b/tutorial/4/lifetime.md @@ -3,7 +3,7 @@ Le noyau tient à jour un compteur de références pour chaque *namespace*. Dès qu'une référence tombe à 0, la structure de l'espace de noms est automatiquement libérée, les points de montage sont démontés, les interfaces -réseaux sont réattribués à l'espace de noms initial, ... +réseaux sont réattribuées à l'espace de noms initial, ... Ce compteur évolue selon plusieurs critères, et principalement selon le nombre de processus qui l'utilisent. C'est-à-dire que, la plupart du temps, le diff --git a/tutorial/4/mount.md b/tutorial/4/mount.md index 7bce19d..28b876c 100644 --- a/tutorial/4/mount.md +++ b/tutorial/4/mount.md @@ -11,17 +11,17 @@ systèmes de fichiers. ## Les points de montage Au premier abord, les points de montage dans l'arborescence d'un système de -fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire +fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire peut être le point d'entrée d'un montage vers la partition d'un disque physique... ou d'une partition virtuelle, comme nous l'avons vu précédemment. Mais avez-vous déjà essayé de monter la même partition d'un disque physique à -deux endroits différents de votre arborescence ? +deux endroits différents de votre arborescence ? Si pour plein de raisons on pouvait se dire que cela ne devrait pas être autorisé, ce problème s'avère être à la base de beaucoup de fonctionnalités intéressantes. Le noyau va finalement décorréler les notions de montage, -d'accès et d'accroche dans l'arborescence : et par exemple, une partition ne +d'accès et d'accroche dans l'arborescence : et par exemple, une partition ne sera plus forcément démontée après un appel à `umount(2)`, mais le sera seulement lorsque cette partition n'aura plus d'accroches dans aucune arborescence. @@ -64,7 +64,7 @@ TARGET SOURCE FSTYPE OPTIONS ## `bind` -- montage miroir Lorsque l'on souhaite monter à un deuxième endroit (ou plus) une partition, on -utilise le *bind mount* : +utilise le *bind mount* :
```bash @@ -77,12 +77,12 @@ l'installe ou qu'on le répare via un *live CD*), il est nécessaire de duplique certains points de montage, tels que `/dev`, `/proc` et `/sys`. Sans monter ces partitions, vous ne serez pas en mesure d'utiliser le système -dans son intégralité : vous ne pourrez pas monter les partitions indiquées par +dans son intégralité : vous ne pourrez pas monter les partitions indiquées par le `/etc/fstab`, vous ne pourrez pas utiliser `top` ou `ps`, `sysctl` ne pourra pas accorder les paramètres du noyau, ... Pour que tout cela fonctionne, nous aurons besoin, au préalable, d'exécuter les -commandes suivantes : +commandes suivantes :
```bash @@ -96,7 +96,7 @@ mount --bind /sys sys En se `chroot`ant à nouveau dans cette nouvelle racine, tous nos outils fonctionneront comme prévu. -Tous ? ... en fait non. Si l'on jette un œil à `findmnt(1)`, nous constatons +Tous ? ... en fait non. Si l'on jette un œil à `findmnt(1)`, nous constatons par exemple que `/sys/fs/cgroup` dans notre nouvelle racine est vide, alors que celui de notre machine hôte contient bien les répertoires de nos *cgroups*. @@ -105,7 +105,7 @@ partie de celui-ci) à un autre endroit, sans se préoccuper des points de montages sous-jacents. Pour effectuer cette action récursivement, et donc monter au nouvel emplacement le système de fichier ainsi que tous les points d'accroche qu'il contient, il faut utiliser `--rbind`. Il serait donc plus -correct de lancer : +correct de lancer :
```bash @@ -119,7 +119,7 @@ mount --rbind /sys sys ## Les types de propagation des points de montage -On distingue quatre variétés de propagation des montages pour un sous-arbre : +On distingue quatre variétés de propagation des montages pour un sous-arbre : partagé, esclave, privé et non-attachable. Chacun va agir sur la manière dont seront propagées les nouvelles accroches au @@ -130,7 +130,7 @@ sein d'un système de fichiers attaché à plusieurs endroits. Dans un montage partagé, une nouvelle accroche sera propagée parmi tous les systèmes de fichiers de ce partage (on parle de *peer group*). Voyons avec un -exemple : +exemple :
```bash @@ -146,7 +146,7 @@ mount --bind /tmp /mnt/test-shared
Si l'on attache un nouveau point de montage dans `/tmp` ou dans -`/mnt/test-shared`, avec la politique `shared`, l'accroche sera propagée : +`/mnt/test-shared`, avec la politique `shared`, l'accroche sera propagée :
```bash @@ -178,7 +178,7 @@ mount --make-slave /mnt/test-slave ```
-Si l'on effectue un montage dans `/mnt/test-shared` : +Si l'on effectue un montage dans `/mnt/test-shared` :
```bash @@ -187,7 +187,7 @@ mount -t tmpfs none /mnt/test-shared/foo ```
-Le point de montage apparaît bien sous `/mnt/test-slave/foo`. Par contre : +Le point de montage apparaît bien sous `/mnt/test-slave/foo`. Par contre :
```bash @@ -201,11 +201,11 @@ Le nouveau point de montage n'est pas propagé dans `/mnt/test-shared/bar`. ### privé -- *private mount* -C'est le mode le plus simple : ici les points de montage ne sont tout +C'est le mode le plus simple : ici les points de montage ne sont tout simplement pas propagés. Pour forcer un point d'accroche à ne pas propager et à ne pas recevoir de -propagation, on utilise l'option suivante : +propagation, on utilise l'option suivante :
```bash @@ -224,7 +224,7 @@ mount --make-unbindable /mnt/test-slave ```
-Il ne sera pas possible de faire : +Il ne sera pas possible de faire :
```bash @@ -238,7 +238,7 @@ mount --bind /mnt/test-slave /mnt/test-unbindable Les options que nous venons de voir s'appliquent sur un point de montage. Il existe les mêmes options pour les appliquer en cascade sur les points d'attache -contenus dans leur sous-arbre : +contenus dans leur sous-arbre :
```bash @@ -253,7 +253,7 @@ mount --make-runbindable mountpoint ## Montage miroir de dossiers et de fichiers Il n'est pas nécessaire que le point d'accroche que l'on cherche à dupliquer -pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une +pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une partition ou un système de fichiers virtuel). Il peut parfaitement pointer sur un dossier, et même sur un simple fichier, à la manière d'un *hardlink*, mais que l'on pourrait faire entre plusieurs partitions et qui ne persisterait pas @@ -272,7 +272,7 @@ faire même si un fichier est en cours d'utilisation. Il faut cependant veiller à ce que les programmes susceptibles d'aller chercher un fichier à l'ancien emplacement soient prévenus du changement. -Pour déplacer un point de montage, on utilise l'option `--move` de `mount(8)` : +Pour déplacer un point de montage, on utilise l'option `--move` de `mount(8)` :
```bash @@ -280,7 +280,7 @@ mount --move olddir newdir ```
-Par exemple : +Par exemple :
```bash @@ -289,7 +289,7 @@ mount --move /dev /newroot/dev
Cette possibilité s'emploie notamment lorsque l'on souhaite changer la racine -de notre système de fichiers : par exemple pour passer de l'*initramfs* au +de notre système de fichiers : par exemple pour passer de l'*initramfs* au système démarré, de notre système hôte au système d'un conteneur, ... @@ -299,6 +299,6 @@ Voici quelques articles qui valent le détour, en lien avec les points de montage : * [Shared subtree](https://lwn.net/Articles/159077) () et la - [documentation du noyau associée](https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) () ; -* [Mount namespaces and shared subtrees](https://lwn.net/Articles/689856) : ; + [documentation du noyau associée](https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) () ; +* [Mount namespaces and shared subtrees](https://lwn.net/Articles/689856) :  ; * [Mount namespaces, mount propagation, and unbindable mounts](https://lwn.net/Articles/690679) : . diff --git a/tutorial/4/networkns.md b/tutorial/4/networkns.md index d60dd68..3060a1a 100644 --- a/tutorial/4/networkns.md +++ b/tutorial/4/networkns.md @@ -63,7 +63,7 @@ des interfaces : Cette commande ne nous montre que l'interface de *loopback*, car nous n'avons pour l'instant pas encore attaché la moindre interface. -D'ailleurs, cette interface est rapportée comme étant désactivée, activons-là +D'ailleurs, cette interface est rapportée comme étant désactivée, activons-la via la commande :
@@ -72,7 +72,7 @@ via la commande : ```
-À ce stade, nous pouvons déjà commencer à lancer un `ping` sur cette interface: +À ce stade, nous pouvons déjà commencer à lancer un `ping` sur cette interface :
``` diff --git a/tutorial/4/pidns.md b/tutorial/4/pidns.md index 37f9d57..31386f4 100644 --- a/tutorial/4/pidns.md +++ b/tutorial/4/pidns.md @@ -91,7 +91,7 @@ de noms. [^PR_SET_CHILD_SUBREAPER]: en réalité, ce comportement est lié à la propriété `PR_SET_CHILD_SUBREAPER`, qui peut être définie pour n'importe quel processus de l'arborescence. Le processus au PID 1 hérite forcément de cette propriété\ ; - il va donc récupérer tous les orphelins, si aucun de leurs parents n'ont la + il va donc récupérer tous les orphelins, si aucun de leurs parents n'a la propriété définie. Lorsque l'on lance un processus via `nsenter(1)` ou `setns(2)`, cela crée un diff --git a/tutorial/4/setns.md b/tutorial/4/setns.md index ad7c53b..566863b 100644 --- a/tutorial/4/setns.md +++ b/tutorial/4/setns.md @@ -11,7 +11,7 @@ symbolique, représentant l'espace de nom. #### Voir les *namespace*s d'un processus Chaque processus lancé est rattaché à une liste d'espaces de nom, y compris -s'il est issu du système de base (« l'hôte »). +s'il est issu du système de base (« l'hôte »). Nous pouvons dès lors consulter le dossier `/proc//ns/` de chaque processus, pour consulter les différents espaces de nom de nos processus. diff --git a/tutorial/4/setup.md b/tutorial/4/setup.md index b96a9bd..ed2d37e 100644 --- a/tutorial/4/setup.md +++ b/tutorial/4/setup.md @@ -3,7 +3,7 @@ #### Noyau Linux -Pour pouvoir suivre les exercices ci-après, vous devez disposez d'un noyau +Pour pouvoir suivre les exercices ci-après, vous devez disposer d'un noyau Linux, idéalement dans sa version 5.6 ou mieux. Il doit de plus être compilé avec les options suivantes (lorsqu'elles sont disponibles pour votre version) : diff --git a/tutorial/devops/devops.md b/tutorial/devops/devops.md index bd9b1c2..d996147 100644 --- a/tutorial/devops/devops.md +++ b/tutorial/devops/devops.md @@ -57,7 +57,7 @@ Chez Google (et d'autres entreprises qui ont depuis repris l'idée), des équipe sont chargées de développer la fiabilité des systèmes d'information de production. Ce sont les équipes SRE, pour Site Reliability Engineering. On confie alors complètement la responsabilité de l'environnement de production -aux développeurs qui sont chargés de l'automatiser. Au delà de l'automatisation +aux développeurs qui sont chargés de l'automatiser. Au-delà de l'automatisation des déploiements de services, il s'agit ici de développer des mécanismes permettant au système de réagir face aux situations telles que les montées en charges, les pannes, ... @@ -108,7 +108,7 @@ Dans le cas d'un programme à télécharger ([Python](https://buildbot.python.org/all/#/), VLC, [MariaDB](https://buildbot.askmonty.org/buildbot/), ...), on va placer les paquets sur le site internet, éventuellement mettre à jour un fichier pointant -vers la dernière version (pour que les utilisateurs aient la notifications). +vers la dernière version (pour que les utilisateurs aient la notification). Ou bien dans le cas d'un service en ligne (GitHub, Netflix, GMail, ...), il s'agira de mettre à jour le service. @@ -166,7 +166,7 @@ outils. **Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la stack TICK que nous avons mis en place précédemment, nous avions placé un agent sur la machine que nous souhaitions analyser. Outre les graphiques -présenté dans Chronograf, le dernier outil que l'on n'avait pas configuré était +présentés dans Chronograf, le dernier outil que l'on n'avait pas configuré était Kapacitor, qui permet après avoir analysé les données, d'alerter en fonction d'une évolution. @@ -177,7 +177,7 @@ faire remonter dans sa base de données de métriques. \ La différence entre les deux techniques est que nagios va vous alerter à partir -d'un certain seuil que vous aurez préalablement défini (s'il reste moins de 10% +d'un certain seuil que vous aurez préalablement défini (s'il reste moins de 10 % d'espace disque par exemple), tandis que Kapacitor va tenter d'interpréter les indicateurs (et donc vous alerter seulement si la courbe représentant l'espace disque disponible augmente de telle sorte qu'il ne reste plus que quelques @@ -193,7 +193,7 @@ Enfin, citons le [Chaos Monkey](https://fr.wikipedia.org/wiki/Chaos_Monkey), conçu par Netflix, qui est un programme qui va casser de manière aléatoire des é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 (brulatement certes) sa résilience. Cela oblige les développeurs, les +tester (brutalement certes) sa résilience. Cela oblige les développeurs, les opérationnels et les architectes à concevoir des services hautement tolérant 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.md b/tutorial/devops/publish-docker.md index b4197b4..bfadd2b 100644 --- a/tutorial/devops/publish-docker.md +++ b/tutorial/devops/publish-docker.md @@ -72,7 +72,7 @@ docker run --rm -p 8080:8080 localhost:5000/youp0m ::::: {.question} On notera que ceci est possible exclusivement parce que le registre -`localhost:5000` est considéré non-sûr par défaut. C'est à dire qu'il n'a pas +`localhost:5000` est considéré non-sûr par défaut. C'est-à-dire qu'il n'a pas besoin de certificat TLS sur sa connexion HTTP pour être utilisé.\ Si on avait dû utiliser un autre nom de domaine, il aurait fallu [l'ajouter à la liste des diff --git a/tutorial/devops/tools-drone-cmd.md b/tutorial/devops/tools-drone-cmd.md index 9e5e74b..17c8c30 100644 --- a/tutorial/devops/tools-drone-cmd.md +++ b/tutorial/devops/tools-drone-cmd.md @@ -1,6 +1,6 @@ Tout comme Gitea, Drone tire un certain nombre de paramètres depuis son environnement. Nous allons donc commencer par indiquer l'identifiant et le -secret de l'application que l'on a créé précédemment dans Gitea : +secret de l'application que l'on a créés précédemment dans Gitea :
```shell diff --git a/tutorial/devops/tools-drone-runner-end.md b/tutorial/devops/tools-drone-runner-end.md index c19602b..392645a 100644 --- a/tutorial/devops/tools-drone-runner-end.md +++ b/tutorial/devops/tools-drone-runner-end.md @@ -2,7 +2,7 @@ On remarquera que l'on partage notre socket Docker : l'exécution de code arbitraire n'aura pas lieu directement dans le conteneur, en fait il s'agit -d'un petit orchetrateur qui lancera d'autres conteneurs en fonction des tâches +d'un petit orchestrateur qui lancera d'autres conteneurs en fonction des tâches qu'on lui demandera. Le code arbitraire sera donc toujours exécuté dans un conteneur moins privilégié. diff --git a/tutorial/devops/tools-drone.md b/tutorial/devops/tools-drone.md index df0be10..b8fa725 100644 --- a/tutorial/devops/tools-drone.md +++ b/tutorial/devops/tools-drone.md @@ -11,7 +11,7 @@ moderne, conçue tout autour de Docker. Idéale pour nous ! Deux conteneurs sont à lancer : nous aurons d'un côté l'interface de contrôle et de l'autre un agent (*runner* dans le vocabulaire de Drone) chargé d'exécuter les tests. Dans un environnement de production, on aura généralement -plusieurs agents, et ceux-ci seront situé sur des machines distinctes. +plusieurs agents, et ceux-ci seront situés sur des machines distinctes. ### Interface de contrôle et de dispatch des tâches diff --git a/tutorial/devops/tools-gitea.md b/tutorial/devops/tools-gitea.md index 2f2f382..0e175ff 100644 --- a/tutorial/devops/tools-gitea.md +++ b/tutorial/devops/tools-gitea.md @@ -6,7 +6,7 @@ gestionnaire de versions. Nous allons ici utiliser Git. ### Problématique du stockage des produits de compilation -Outre les interfaces rudimentaires fournies au dessus de Git +Outre les interfaces rudimentaires fournies au-dessus de Git ([gitweb](https://git.wiki.kernel.org/index.php/Gitweb)), il y a de nombreux projets qui offrent davantage que le simple hébergement de dépôts. Vous pouvez voir sur GitHub notamment qu'il est possible d'attacher à un tag un [certain diff --git a/tutorial/devops/what-gistre.md b/tutorial/devops/what-gistre.md index 6c1a992..459e300 100644 --- a/tutorial/devops/what-gistre.md +++ b/tutorial/devops/what-gistre.md @@ -7,18 +7,18 @@ Bienvenue dans la société Électropcool ! Électropcool est une société française spécialisée dans l'[immotique](https://fr.wikipedia.org/wiki/Immotique), elle vend des -équipements IoT, principalement à destination des professionels du bâtiment. Le +équipements IoT, principalement à destination des professionnels du bâtiment. Le produit phare est une plate-forme de [GTB](https://fr.wikipedia.org/wiki/Gestion_technique_de_b%C3%A2timent) modulaire de suivi de la vie d'un bâtiment où sont regroupés les différents compteurs, capteurs et actionneurs que l'on retrouve dans les installations. Les nouveaux bâtiments conçus autour la plate-forme permettent de faire de -sérieuses économies d'entretien (en ne faisant déplacer les techiciens que +sérieuses économies d'entretien (en ne faisant déplacer les techniciens que lorsque c'est nécessaire) tout en permettant d'anticiper les problèmes (grâce à un moteur de *machine-learning* capable d'anticiper les pannes) et les besoins en combustible (liés à la météo)[^HOMEASSISTANT]. -[^HOMEASSISTANT]: Si ça vous met l'eau à la bouche, jettez un œil du côté du +[^HOMEASSISTANT]: Si ça vous met l'eau à la bouche, jetez un œil du côté du projet qui fait un peu moins de *bullshit*, mais est bien réel ! @@ -51,7 +51,7 @@ Une grosse partie des travaux est donc réalisé avec un noyau Linux, sur du matériel très performant, pour de l'embarqué. \ -Tous les modules logiciels qui interragissent avec les capteurs sont +Tous les modules logiciels qui interagissent avec les capteurs sont aujourd'hui intégrés dans un système construit à l'aide de [`bitbake`](https://www.yoctoproject.org/). L'entreprise grossissant à vue d'œil, il devient de plus en plus difficile de synchroniser les équipes concilier la @@ -70,7 +70,7 @@ 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 l'équipe développant le nouveau système de base, suivant le meilleur outil que -retiendrez.) +vous retiendrez.) \ Le projet qui vous servira de base pour vos tests sera diff --git a/tutorial/docker-advanced/compose.md b/tutorial/docker-advanced/compose.md index 864af3d..62bf911 100644 --- a/tutorial/docker-advanced/compose.md +++ b/tutorial/docker-advanced/compose.md @@ -54,7 +54,7 @@ run`. #### `volumes` -Cette section est le pendant de la commandes `docker volume`. +Cette section est le pendant de la commande `docker volume`. On déclare les volumes simplement en leur donnant un nom et un driver comme suit : @@ -83,7 +83,7 @@ l'emplacement à partager : #### `network` -Cette section est le pendant de la commandes `docker network`. +Cette section est le pendant de la commande `docker network`. Par défaut, Docker relie tous les conteneurs sur un bridge et fait du NAT pour que les conteneurs puissent accéder à l'Internet. Mais ce n'est pas le seul @@ -113,7 +113,7 @@ les ports ouverts par la machine hôte. Avec le driver `null`, la pile réseau est recréée et aucune interface (autre que l'interface de loopback) n'est présente. Le conteneur ne peut donc pas -accéder à Internet, ni aux autres conteneur, ... +accéder à Internet, ni aux autres conteneurs, ... Lorsque l'on exécute un conteneur qui n'a pas besoin d'accéder au réseau, c'est le driver à utiliser. Par exemple pour un conteneur dont le but est de vérifier @@ -127,7 +127,7 @@ conteneurs qui la référencent. Avec cette configuration, les conteneurs ont accès à une résolution DNS des noms de conteneurs qui partagent leur bridge. Ainsi, sans avoir à utiliser la -fonctionnalité de `link` au moment du `run`, il est possible de se retrouvé +fonctionnalité de `link` au moment du `run`, il est possible de se retrouver lié, même après que l'on ait démarré. La résolution se fera dynamiquement. diff --git a/tutorial/docker-advanced/what.md b/tutorial/docker-advanced/what.md index c577fd0..63511e3 100644 --- a/tutorial/docker-advanced/what.md +++ b/tutorial/docker-advanced/what.md @@ -6,9 +6,9 @@ Orchestrer un groupe de conteneurs Maintenant que nous savons démarrer individuellement des conteneurs et les lier entre-eux, nous allons voir une première manière d'automatiser cela. -Plutôt que de lancer les commandes `docker` comme nous l'avons fait jusque là : +Plutôt que de lancer les commandes `docker` comme nous l'avons fait jusque-là : soit directement dans un terminal, soit via un script, nous allons décrire -l'état que nous souhaitons atteindre : quels images lancer, quels volumes +l'état que nous souhaitons atteindre : quelles images lancer, quels volumes créer, quels réseaux, etc. Cette description peut s'utiliser pour lancer un conteneur seul, mais elle prend tout son sens lorsqu'il faut démarrer tout un groupe de conteneurs qui fonctionnent de concert, parfois avec des dépendances @@ -31,7 +31,7 @@ génériques et pouvant facilement être mis à l'échelle. Nous collecterons les données d'utilisation de votre machine avec [Telegraf](https://www.influxdata.com/time-series-platform/telegraf/). Ces -données seront envoyés vers +données seront envoyées vers [InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/), puis elles seront affichées sous forme de graphique grâce à [Chronograf](https://www.influxdata.com/time-series-platform/chronograf/). diff --git a/tutorial/docker-basis/cleaning.md b/tutorial/docker-basis/cleaning.md index 7045876..0372bbe 100644 --- a/tutorial/docker-basis/cleaning.md +++ b/tutorial/docker-basis/cleaning.md @@ -7,7 +7,7 @@ d'informations dépréciées. Dans la mesure du possible, Docker essaie de ne pas encombrer inutilement votre disque dur avec les vieilles images qui ne sont plus utilisées. Il ne va -cependant jamais supprimer une image encore liée à un conteneur ; il ne +cependant jamais supprimer une image encore liée à un conteneur ; il ne supprimera pas non plus les conteneurs qui n'auront pas été démarrés avec l'option `--rm`. diff --git a/tutorial/docker-basis/ex-owncloud.md b/tutorial/docker-basis/ex-owncloud.md index 9adff31..1550898 100644 --- a/tutorial/docker-basis/ex-owncloud.md +++ b/tutorial/docker-basis/ex-owncloud.md @@ -1,6 +1,6 @@ ::::: {.exercice} -Pour mettre en pratiques toutes les notions que l'on a vu jusque là, écrivez un +Pour mettre en pratiques toutes les notions que l'on a vues jusque-là, écrivez un script `mycloud-run.sh` pour automatiser le lancement de votre instance personnelle de [`nextcloud`](https://hub.docker.com/_/nextcloud/) ou d'[`owncloud`](https://hub.docker.com/r/owncloud/server/). Une attention @@ -29,7 +29,7 @@ exemple). L'exécution doit être la plus sécurisée possible (pas de port MySQL exposé sur l'hôte par exemple, etc.) et la plus respectueuse des bonnes pratiques que l'on -a pu voir jusque là. +a pu voir jusque-là. ### Exemple d'exécution {-} diff --git a/tutorial/docker-basis/first.md b/tutorial/docker-basis/first.md index 8fbc48f..3a9fd02 100644 --- a/tutorial/docker-basis/first.md +++ b/tutorial/docker-basis/first.md @@ -45,9 +45,9 @@ docker image pull ubuntu Les registres publics tels quel le Docker Hub mettent à disposition des images officielles, mais aussi des images créées par la communauté. Chaque utilisateur -est libre d'envoyer une image qu'il a lui-même créé : soit car l'éditeur ne +est libre d'envoyer une image qu'il a lui-même créée : soit car l'éditeur ne proposait pas d'image et que quelqu'un s'est dévoué pour la faire, soit parce -qu'il avait des besoins plus spécifiques qui n'étaient pas couvert par l'image +qu'il avait des besoins plus spécifiques qui n'étaient pas couverts par l'image originale. Il est important de garder en tête que vous téléchargez des exécutables, et bien qu'ils s'exécutent dans un environnement isolé, ils peuvent contenir du code malveillant. @@ -62,7 +62,7 @@ assurez-vous d'avoir confiance dans la personne affiliée à l'image.** Remarquez comment on interagit avec chaque *objet Docker* : dans la ligne de commande, le premier mot clef est le type d'objet (`container`, `image`, -`service`, `network`, `volume`, ...) ; ensuite, vient l'action que l'on +`service`, `network`, `volume`, ...) ; ensuite, vient l'action que l'on souhaite faire dans ce cadre.[^oldcall] [^oldcall]: cela n'a pas toujours été aussi simple, cette syntaxe n'existe que diff --git a/tutorial/docker-basis/installation.md b/tutorial/docker-basis/installation.md index 707cdaf..c30b2e0 100644 --- a/tutorial/docker-basis/installation.md +++ b/tutorial/docker-basis/installation.md @@ -4,7 +4,7 @@ Installation Docker repose sur plusieurs techniques implémentées dans les noyaux Linux récents (et plus marginalement, Windows). Ces techniques, contrairement aux instructions de virtualisation qui rendent les hyperviseurs attractifs, ne sont -pas limitées à une architecture de microprocesseur spécifique ; cependant la +pas limitées à une architecture de microprocesseur spécifique ; cependant la communauté autour de Docker utilise principalement l'architecture `amd64`, c'est sur cette dernière que Docker pourra être exploité à son plein potentiel, suivi de près par l'architecture `arm64`. @@ -97,7 +97,7 @@ Si vous rencontrez des difficultés pour vous lancer, le projet Play With Docker[^PlayWithDocker] vous donne accès à un bac à sable dans lequel vous pourrez commencer à faire les exercices à suivre. -[^PlayWithDocker]: Play With Docker est accessible à cette addresse : +[^PlayWithDocker]: Play With Docker est accessible à cette adresse : Il vous faudra disposer [d'un compte Docker](https://hub.docker.com/signup). Une fois identifié, vous pourrez créer diff --git a/tutorial/docker-basis/linking-ex-help.md b/tutorial/docker-basis/linking-ex-help.md index b2978bf..3f8fe1c 100644 --- a/tutorial/docker-basis/linking-ex-help.md +++ b/tutorial/docker-basis/linking-ex-help.md @@ -1,10 +1,10 @@ ### Au secours, ça veut pas se connecter ! Lorsque nous lançons pour la première fois notre conteneur MySQL ou MariaDB, un -script est chargé d'initialisé le volume attaché à `/var/lib/mysql`. Les -démarrage suivant, ou si vous réutilisez un volume déjà initialisé avec une +script est chargé d'initialiser le volume attaché à `/var/lib/mysql`. Les +démarrages suivant, ou si vous réutilisez un volume déjà initialisé avec une base de données, le script ne refait pas d'initialisation. Même si les -variables d'environnement ont changées. +variables d'environnement ont changé. Si vous rencontrez des difficultés pour connecter votre conteneur à `my-db`, prenez le temps de recréer un volume. diff --git a/tutorial/docker-basis/linking.md b/tutorial/docker-basis/linking.md index 4b7dc39..6011c3d 100644 --- a/tutorial/docker-basis/linking.md +++ b/tutorial/docker-basis/linking.md @@ -21,11 +21,11 @@ Mais avant, regardons d'un peu plus près la gestion des réseaux par Docker. ## Les pilotes réseau -Docker propose de base trois pilotes (*drivers*) pour « gérer » cela : +Docker propose de base trois pilotes (*drivers*) pour « gérer » cela : - `none` : pour limiter les interfaces réseau du conteneur à l'interface de - loopback `lo` ; -- `host` : pour partager la pile réseau avec l'hôte ; + loopback `lo` ; +- `host` : pour partager la pile réseau avec l'hôte ; - `bridge` : pour créer une nouvelle pile réseau par conteneur et rejoindre un pont réseau dédié. @@ -64,7 +64,7 @@ directement accessible, sans avoir à utiliser l'option `-p` du `run`. ### Créer un nouveau réseau `bridge` Afin de contrôler quels échanges peuvent être réalisés entre les conteneurs, il -est recommandé de créer des réseaux utilisateur. +est recommandé de créer des réseaux utilisateurs. La création d'un réseau se fait tout simplement au travers des sous-commandes relatives aux objets Docker `network` : diff --git a/tutorial/docker-basis/volumes.md b/tutorial/docker-basis/volumes.md index bd7e4f7..d91d1bc 100644 --- a/tutorial/docker-basis/volumes.md +++ b/tutorial/docker-basis/volumes.md @@ -12,7 +12,7 @@ volumes. Il est possible d'utiliser la dernière couche en lecture/écriture pour inscrire des données. Il n'est cependant pas recommandé de stocker des données de cette manière, car elles ne vont pas persister une fois que le conteneur aura terminé -son exécution ; elles seront alors plus compliquées à retrouver manuellement. +son exécution ; elles seront alors plus compliquées à retrouver manuellement. Docker met à notre disposition plusieurs mécanismes pour que les données de nos applications persistent et soient prêtes à migrer plus facilement vers une diff --git a/tutorial/docker-basis/what.md b/tutorial/docker-basis/what.md index 5d6511f..41df769 100644 --- a/tutorial/docker-basis/what.md +++ b/tutorial/docker-basis/what.md @@ -67,7 +67,7 @@ proposent également. Alors que les images constituent la partie immuable de Docker, les conteneurs sont sa partie vivante. Chaque conteneur est créé à partir d'une image : à chaque fois que nous lançons un conteneur, une couche lecture/écriture est -ajoutée au dessus de l'image. Cette couche est propre au conteneur et +ajoutée au-dessus de l'image. Cette couche est propre au conteneur et temporaire : l'image n'est pas modifiée par l'exécution d'un conteneur. ![Couches d'un conteneur](layers-multi-container.png "Couches d'un conteneur"){ width=70% } diff --git a/tutorial/docker-internals/clair.md b/tutorial/docker-internals/clair.md index 317b355..98dd63f 100644 --- a/tutorial/docker-internals/clair.md +++ b/tutorial/docker-internals/clair.md @@ -3,7 +3,7 @@ Un outil complet indexer et chercher des vulnérabilités est [`Clair`](https://github.com/coreos/clair/), du projet CoreOS. À partir des informations mises à disposition par les équipes de sécurités des principales -distributions, cela alimente en continu une base de données qui sera accéder au +distributions, cela alimente en continu une base de données qui sera accédé au moment de l'analyse. L'outil se présente sous la forme d'un serveur autonome dans la récupération diff --git a/tutorial/docker-internals/linuxkit-content.md b/tutorial/docker-internals/linuxkit-content.md index 5be8eb3..859a2b8 100644 --- a/tutorial/docker-internals/linuxkit-content.md +++ b/tutorial/docker-internals/linuxkit-content.md @@ -68,7 +68,7 @@ shell sur la machine ! On notera cependant que, positionné dans `services`, le shell que nous obtiendrons sera lui-même exécuté dans un conteneur, nous n'aurons donc pas un accès entièrement privilégier. Pour déboguer, il faut placer cette image dans -la partie `init`, elle sera alors lancé comme un équivalent de +la partie `init`, elle sera alors lancée comme un équivalent de `init=/bin/sh`.[^infogetty] [^infogetty]: Plus d'infos à @@ -177,7 +177,7 @@ serveur SSH aux `services` : ```
-Comme nous n'avons définis aucun mot de passe, il va falloir utiliser une clef +Comme nous n'avons défini aucun mot de passe, il va falloir utiliser une clef SSH pour se connecter. Voilà un bon début d'utilisation de la section `files` :
diff --git a/tutorial/docker-internals/oci.md b/tutorial/docker-internals/oci.md index 69d7da8..0a50526 100644 --- a/tutorial/docker-internals/oci.md +++ b/tutorial/docker-internals/oci.md @@ -9,9 +9,9 @@ fragmentation de l'écosystème. Trois spécifications ont été écrites : -- [`runtime-spec`](https://github.com/opencontainers/runtime-spec/blob/master/spec.md#platforms): définit les paramètres du démarrage d'un conteneur ; -- [`image-spec`](https://github.com/opencontainers/image-spec/blob/master/spec.md): définit la construction, le transport et la préparation des images ; -- [`distribution-spec`](https://github.com/opencontainers/distribution-spec/blob/master/spec.md): définit la manière dont sont partagées et récupérées les images. +- [`runtime-spec`](https://github.com/opencontainers/runtime-spec/blob/master/spec.md#platforms): définis les paramètres du démarrage d'un conteneur ; +- [`image-spec`](https://github.com/opencontainers/image-spec/blob/master/spec.md): définis la construction, le transport et la préparation des images ; +- [`distribution-spec`](https://github.com/opencontainers/distribution-spec/blob/master/spec.md): définis la manière dont sont partagées et récupérées les images. ## `runtime-spec` @@ -47,7 +47,7 @@ Le [manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md) est toujours le point d'entrée d'une image : il référence l'emplacement où trouver les différents éléments : configuration et couches. Lorsqu'une même -image a des variation en fonction de l'architecture du processeur, du système +image a des variations en fonction de l'architecture du processeur, du système d'exploitation, ... dans ce cas [l'index d'image](https://github.com/opencontainers/image-spec/blob/master/image-index.md) est utilisé pour sélectionner le bon manifest. @@ -78,8 +78,8 @@ aussi en envoyer. ## Pour aller plus loin {-} Si maintenant `docker` fait appel à un programme externe pour lancer -effectivement nos conteneurs, c'est que l'on peut changer cette implémentation -? la réponse dans l'article :\ +effectivement nos conteneurs, c'est que l'on peut changer cette +implémentation ? la réponse dans l'article :\ Et `containerd` dans l'histoire ?\ diff --git a/tutorial/docker-internals/registry.md b/tutorial/docker-internals/registry.md index ecfd18d..c95d9dc 100644 --- a/tutorial/docker-internals/registry.md +++ b/tutorial/docker-internals/registry.md @@ -186,7 +186,7 @@ Pensez également à tester avec d'autres images, comme par exemple `nemunaire/youp0m`. Il vous faudra alors extraire plusieurs couches. Pour gérer les différentes couches, vous pouvez utiliser une stratégie -similaire au driver `vfs` : en extrayant chaque tarball l'une au dessus de +similaire au driver `vfs` : en extrayant chaque tarball l'une au-dessus de l'autre, en essayant de gérer les *whiteout files*. Ou bien en suivant le driver `overlayfs`, en montant un système de fichier à chaque couche (dans ce cas, votre script devra être lancé en `root`). diff --git a/tutorial/docker-internals/runc.md b/tutorial/docker-internals/runc.md index cd0a2bf..a40f326 100644 --- a/tutorial/docker-internals/runc.md +++ b/tutorial/docker-internals/runc.md @@ -9,7 +9,7 @@ montages ou volumes, ... Attention, son rôle reste limité à la mise en place l'environnement conteneurisé, ce n'est pas lui qui télécharge l'image, ni fait l'assemblage des couches de système de fichiers, entre autres. -Aujourd'hui, le lancement de conteneur est faite avec `runc`, mais il est +Aujourd'hui, le lancement de conteneur est fait avec `runc`, mais il est parfaitement possible d'utiliser n'importe quel autre programme à sa place, à partir du moment où il expose la même interface à Docker et qu'il accepte les *bundle* OCI. diff --git a/tutorial/docker-internals/vulnerability-scan.md b/tutorial/docker-internals/vulnerability-scan.md index a25390f..a76ad10 100644 --- a/tutorial/docker-internals/vulnerability-scan.md +++ b/tutorial/docker-internals/vulnerability-scan.md @@ -12,7 +12,7 @@ l'effort de cloisonnement mis en place. Mais doit-on pour autant s'arrêter là et considérer que nous avons réglé l'ensemble des problématiques de sécurité liées aux conteneurs ? -Évidemment, non : une fois nos services lancés dans des conteneurs, il ne sont +Évidemment, non : une fois nos services lancés dans des conteneurs, ils ne sont pas moins exposés aux bugs et autres failles applicatives ; qu'elles soient dans notre code ou celui d'une bibliothèque, accessible par rebond, ... @@ -20,7 +20,7 @@ Il est donc primordial de ne pas laisser ses conteneurs à l'abandon une fois leur image créée et envoyée en production. Nos conteneurs doivent être regénérés sitôt que leur image de base est mise à jour (une mise à jour d'une image telle que Debian, Ubuntu ou Redhat n'apparaît que pour cela) ou bien -lorsqu'un des programmes ou l'une des bibliothèques que l'on a installés +lorsqu'un des programmes ou l'une des bibliothèques que l'on a installées ensuite est mise à jour. Convaincu ? Cela sonne encore comme des bonnes pratiques difficiles à mettre en @@ -191,7 +191,7 @@ Total: 158 (UNKNOWN: 5, LOW: 19, MEDIUM: 64, HIGH: 61, CRITICAL: 9) Les résultats sont un peu différents qu'avec `docker scan`, mais on constate que l'image `mysql` contient vraiment de nombreuses vulnérabilités. Même si -elles ne sont heureusement pas forcément exploitable directement. +elles ne sont heureusement pas forcément exploitables directement. Voyons maintenant s'il y a des différentes avec l'image `nemunaire/fic-admin` : diff --git a/tutorial/docker-orchestration/setup.md b/tutorial/docker-orchestration/setup.md index 88708d7..40db57e 100644 --- a/tutorial/docker-orchestration/setup.md +++ b/tutorial/docker-orchestration/setup.md @@ -6,7 +6,7 @@ notre machine hôte, même si ce n'est pas un Linux : le but va être de lancer plusieurs machines virtuelles dédiées à Docker pour simuler un cluster. Ce programme permet de simplifier la gestion de multiples environnements -Docker, comme par exmple lorsque l'on souhaite gérer un cluster de machines +Docker, comme par exemple lorsque l'on souhaite gérer un cluster de machines pour un projet. Ainsi, il est possible de provisionner et gérer des machines hôtes sur les @@ -38,7 +38,7 @@ Hyper-V. Bien d'autres environnements peuvent être supportés, au moyen de plug-ins. Si vous utilisez KVM comme hyperviseur, vous allez avoir besoin d'installer le -plugins +plugin [`docker-machine-kvm`](https://github.com/machine-drivers/docker-machine-kvm). Vous n'aurez qu'à suivre les instructions du `README` :\ diff --git a/tutorial/docker-orchestration/stack.md b/tutorial/docker-orchestration/stack.md index 8be67ff..0a358bc 100644 --- a/tutorial/docker-orchestration/stack.md +++ b/tutorial/docker-orchestration/stack.md @@ -101,7 +101,7 @@ consulter la documentation à ce sujet :\ #### Mise à l'échelle et placement -On parle depuis toute à l'heure de lancer plusieurs tâches pour le même +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 physiques différentes. diff --git a/tutorial/docker-orchestration/swarm.md b/tutorial/docker-orchestration/swarm.md index a782a20..e2f2ae6 100644 --- a/tutorial/docker-orchestration/swarm.md +++ b/tutorial/docker-orchestration/swarm.md @@ -26,7 +26,7 @@ Swarm. #### Initialisation du cluster -La première chose à faire est d'initialiser un cluster Swarm. Pour se faire, +La première chose à faire est d'initialiser un cluster Swarm. Pour ce faire, ce n'est pas plus compliqué que de faire :
@@ -46,7 +46,7 @@ attendant d'autres nœuds. Pour rejoindre un cluster, il est nécessaire d'avoir le jeton associé à ce cluster. -La commande pour rejoindre un cluster et contenant le jeton est iniquée +La commande pour rejoindre un cluster et contenant le jeton est indiquée lorsque vous initialisez le cluster. Si vous avez raté la sortie de la commande, vous pouvez retrouver le jeton avec : @@ -102,7 +102,7 @@ Pour que l'algorithme de consensus fonctionne de manière optimale, il convient de toujours avoir un nombre impair de managers : Docker en recommande 3 ou 5. La pire configuration est avec deux managers, car si l'un des deux tombe, il ne peut pas savoir si c'est lui qui est isolé (auquel cas il attendrait -d'être à nouveau en ligne avant de se procalmer leader) ou si c'est l'autre qui +d'être à nouveau en ligne avant de se proclamer leader) ou si c'est l'autre qui est tombé. Avec trois managers, en cas de perte d'un manager, les deux restants peuvent considérer qu'ils ont perdu le troisième et peuvent élire le nouveau manager entre eux et continuer à faire vivre le cluster. diff --git a/tutorial/dockerfiles/dockerfile.md b/tutorial/dockerfiles/dockerfile.md index 7c8a3ad..75230ac 100644 --- a/tutorial/dockerfiles/dockerfile.md +++ b/tutorial/dockerfiles/dockerfile.md @@ -151,7 +151,7 @@ suivante. Lorsqu'on lance la reconstruction du même `Dockerfile`, les images intermédiaires sont réutilisées, comme un cache d'instructions. Cela permet de -gagner du temps sur les étapes qui n'ont pas changées. Ainsi, lorsque vous +gagner du temps sur les étapes qui n'ont pas changé. Ainsi, lorsque vous modifiez une instruction dans votre `Dockerfile`, les instructions précédentes ne sont pas réexécutées mais sont ressorties du cache. @@ -164,7 +164,7 @@ Il est possible de ne pas utiliser le cache et de relancer toutes les étapes du `Dockerfile` en ajoutant l'option `--no-cache` au moment du `docker image build`. -Les couches du cache peuvent être partagées entre plusieurs conteneur, c'est +Les couches du cache peuvent être partagées entre plusieurs conteneurs, c'est ainsi que vous pouvez partager facilement une plus grosse partie du système de fichiers (rappelez-vous le principe d'union FS). @@ -195,7 +195,7 @@ pour indiquer que c'est vous qui maintenez cette image, si des utilisateurs ont besoin de vous avertir pour le mettre à jour ou s'ils rencontrent des difficultés par exemple. -On le place dès le début, car comme c'est une information qui n'est pas amener +On le place dès le début, car comme c'est une information qui n'est pas amenée à changer, elle sera toujours retrouvée en cache. diff --git a/tutorial/dockerfiles/goodpractices.md b/tutorial/dockerfiles/goodpractices.md index 0ff2524..d127a9b 100644 --- a/tutorial/dockerfiles/goodpractices.md +++ b/tutorial/dockerfiles/goodpractices.md @@ -4,12 +4,12 @@ Les bonnes pratiques -------------------- Pour chaque bonne pratique ci-dessous, vérifiez que vous la respectez -bien, faites les modifications nécessaire dans votre `Dockerfile`. +bien, faites les modifications nécessaires dans votre `Dockerfile`. ### Utilisez le fichier `.dockerignore` Dans la plupart des cas, vos `Dockerfile` seront dans des dossiers contenant -beaucoup de fichiers qui ne sont pas nécessaire à la construction de votre +beaucoup de fichiers qui ne sont pas nécessaires à la construction de votre conteneur (par exemple, vous pouvez avoir un `Dockerfile` placé à la racine d'un dépôt git). @@ -22,7 +22,7 @@ vous utilisez un langage compilé, excluez également les produits de compilatio si votre image construit le binaire. Dans le cas de NodeJS, vous allez sans doute vouloir exclure le dossier `node_modules` et faire un `npm install` dans votre `Dockerfile`. Cela permettra au passage de s'assurer que toutes les -dépendances ont bien été enregistrée. +dépendances ont bien été enregistrées. Ce fichier fonctionne de la même manière que le `.gitignore` : vous pouvez utiliser du globing. @@ -123,7 +123,7 @@ Il y a un certain nombre de règles à connaître pour bien utiliser ce mécanis dans le `Dockerfile` vont être exécutées. -### Concevez des conteneur éphémères +### Concevez des conteneurs éphémères Les conteneurs que vous générez doivent être aussi éphémères que possible : ils devraient pouvoir être arrêtés, détruits et recréés sans nécessiter d'étape de @@ -155,7 +155,7 @@ modifier la configuration des autres logiciels contenu dans d'autres conteneurs puisqu'ils sont généralement configurés pour se connecter aux ports standards. S'il y a un conflit sur la machine hôte, il sera toujours temps de créer une -redirection à ce moment là. +redirection à ce moment-là. ### La bonne utilisation de l'`ENTRYPOINT` @@ -165,7 +165,7 @@ utilisé de deux manières différentes : - Vous pouvez l'utiliser de telle sorte que la commande passée au `docker run`, après le nom de l'image, corresponde aux arguments attendu par le programme - indiqué dans l'*entrypoint*. Par exemple pour nginx : + indiqué dans l'*entrypoint*. Par exemple pour `nginx` :
```dockerfile @@ -208,7 +208,7 @@ prendre deux formes : arguments. Si d'éventuels variables se trouve dans les arguments, elles ne seront pas remplacées. - `cmd arg1 arg2` : ici l'exécution se fera au sein d'un `sh -c`, donc les - variables seront remplacés et étendues. + variables seront remplacées et étendues. Les commandes sous forme de tableau étant parsées par un parser JSON, vous ne pouvez pas utiliser les *simples quotes*. diff --git a/tutorial/dockerfiles/interactive.md b/tutorial/dockerfiles/interactive.md index 0d35352..d226e0c 100644 --- a/tutorial/dockerfiles/interactive.md +++ b/tutorial/dockerfiles/interactive.md @@ -33,7 +33,7 @@ quelles versions de nos dépendances on va récupérer. [^SECURITY_UPDATE]: Voir cet article : -Si vous souhaitez disposez d'une nouvelle version de l'image, il est +Si vous souhaitez disposer d'une nouvelle version de l'image, il est plutôt recommandé de contacter le mainteneur de l'image pour qu'il la mette à jour, en utilisant un nouveau tag s'il le juge nécessaire. Si cette solution n'est pas envisageable, alors il vaut mieux créer votre diff --git a/tutorial/dockerfiles/others.md b/tutorial/dockerfiles/others.md index b4e6765..682eed9 100644 --- a/tutorial/dockerfiles/others.md +++ b/tutorial/dockerfiles/others.md @@ -126,7 +126,7 @@ Faites en sorte que le `Dockerfile` que vous avez créé pour `youp0m` indique u Il est aussi possible de se passer complètement de Docker. La plupart des outils qui sont capables de générer des images de machines virtuelles, sont -aussi capable de générer des images Docker. Citons notamment : +aussi capables de générer des images Docker. Citons notamment : - [Hashicorp Packer](https://www.packer.io/docs/builders/docker), - [Nix et Guix](https://nix.dev/tutorials/building-and-running-docker-images), diff --git a/tutorial/k8s/discover.md b/tutorial/k8s/discover.md index 9ff84e5..ec2cf0c 100644 --- a/tutorial/k8s/discover.md +++ b/tutorial/k8s/discover.md @@ -9,13 +9,13 @@ Découverte de `kubectl` programme que l'on utilise pour interagir avec notre cluster. Étant donné qu'il s'agit d'un programme client, qui ne fait rien de plus que -discuter avec une API REST HTTP, on peut le considérer comme un gros wrapper au -dessus de `curl`. +discuter avec une API REST HTTP, on peut le considérer comme un gros wrapper +au-dessus de `curl`. ### Obtenir de l'aide Commençons par apprivoiser `kubectl` en prenant quelques -renseignements et surtout en apprennant comment obtenir de l'aide : +renseignements et surtout en apprenant comment obtenir de l'aide :
```bash @@ -25,7 +25,7 @@ kubectl explain type
Les `type`s que vous pouvez découvrir sont ceux que l'on a vu à la -sections précédentes : `node`, `pod`, ... +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 diff --git a/tutorial/k8s/discover2.md b/tutorial/k8s/discover2.md index fbc2311..d2fde23 100644 --- a/tutorial/k8s/discover2.md +++ b/tutorial/k8s/discover2.md @@ -1,7 +1,7 @@ ::::: {.warning} Notez que le dashboard, avec cette configuration, va s'exécuter sans les -prérequis minimum de sécurité : pas de certificat TLS, ni +prérequis minimums de sécurité : pas de certificat TLS, ni d'authentification. Ceci est juste pour jouer avec l'interface, en production, on n'utilisera pas cette recette. @@ -44,7 +44,7 @@ la partie `Service` un *node port* plus spécifique : ``` Maintenant, nous n'allons pas recréer un nouveau dashboard : nous allons -simplement « appliquer » la nouvelle configuration : +simplement « appliquer » la nouvelle configuration : ```bash kubectl apply -f my-insecure-dashboard.yaml diff --git a/tutorial/k8s/intro-book.md b/tutorial/k8s/intro-book.md index 2cb68c1..a692d9b 100644 --- a/tutorial/k8s/intro-book.md +++ b/tutorial/k8s/intro-book.md @@ -6,5 +6,5 @@ Présentation du fil rouge Afin d'évaluer Kubernetes, nous allons travailler avec un mineur de pépites ... de chocolat ! -Alors, on se sert un bon thé, on prend sa boîte de gâteaux pour teniir le coup, +Alors, on se sert un bon thé, on prend sa boîte de gâteaux pour tenir le coup, et c'est parti ! diff --git a/tutorial/k8s/setup.md b/tutorial/k8s/setup.md index bd19899..54d3f54 100644 --- a/tutorial/k8s/setup.md +++ b/tutorial/k8s/setup.md @@ -45,7 +45,7 @@ utiliser Kubernetes facilement : ### Docker for Mac/Windows {#dockerdesktop} -*Docker Desktop* pour Mac ou pour Windows intégre Kubernetes directement. Il +*Docker Desktop* pour Mac ou pour Windows intègre Kubernetes directement. Il n'est pas activé par défaut, pour cela il convient d'activer l'option dans les préférences de l'application :