correction de coquilles (détectées par thomas)

documentation/01.introduction.md

@@ -14,9 +14,9 @@ Par ailleurs ce recours de plus en plus fréquent aux conteneurs dans le monde a
 
 A cela s’ajoute une utilisation de plus en plus fréquente des conteneurs pour la mise en place d’environnements de développement local, que ce soit avec un outil générique comme Docker Compose[^dockrcomp] ou avec des solutions spécifiques comme `ddev`[^ddev] pour les applications PHP\MySQL. Il serait dès lors intéressant de pouvoir déployer en production les applications développées au sein des différentes équipes avec les mêmes technologies utilisées par les équipes de développement. 
 
-Mais au-delà du développement d'application, les conteneurs permettent aussi un déploiement d'application pré-configurées (configuration as code), l'upgrade plus sûr des applications en production, des cycles de release plus court (voire de l'intégration continue)... 
+Mais au-delà du développement d'application, les conteneurs permettent aussi un déploiement d'applications pré-configurées (configuration as code), l'upgrade plus sûr des applications en production, des cycles de release plus courts (voire de l'intégration continue)... 
 
-De nombreuses applications propose donc des procédures de déploiement basées sur les conteneurs, par exemple Ceph qui utilise l'orchestrateur Podman pour déployer son cluster, et les compétences dans ce domaine vont devoir se développer au sein des équipes. 
+De nombreuses applications proposent donc des procédures de déploiement basées sur les conteneurs, par exemple Ceph qui utilise l'orchestrateur Podman pour déployer son cluster, et les compétences dans ce domaine vont devoir se développer au sein des équipes. 
 
 ### Des applications aux besoins variés et plus complexes à mettre en production
 
@@ -66,7 +66,7 @@ Dans un second temps, j'aborderai la mise en place d’une infrastructure de dé
 
 Dans la troisième partie, je proposerai des solutions pour automatiser le déploiement de cette infrastructure ainsi que des outils permettant de faciliter sa gestion. Il s’agira aussi de décrire la manière dont les applications peuvent être déployées sur cette infrastructure.
 
-Dans la quatrième partie, j'aborderai les perspectives liées à la mise en production de cette infrastructure et au changement technologique qu'elle implique. Il s'agira également de décrire comment le travail réalisé dans la deuxième partie précédente pourra être transcrit en basée sur la solution Docker Swarm production. J’aborderai enfin quelques pistes pour l'avenir des infrastructures à base de conteneurs à l'UCLouvain.
+Dans la quatrième partie, j'aborderai les perspectives liées à la mise en production de cette infrastructure et au changement technologique qu'elle implique. Il s'agira également de décrire comment le travail réalisé dans la deuxième partie pourra être transcrit en production. J’aborderai enfin quelques pistes pour l'avenir des infrastructures à base de conteneurs à l'UCLouvain.
 
 Il sera alors temps pour moi de conclure et de remettre en contexte le travail réalisé.
 

documentation/02.docker-et-docker-swarm.md

@@ -302,7 +302,7 @@ Typiquement, le nombre de manager sera de 1, 3 ou 5. Au-delà de 5, les performa
 
 #### Redondance et distribution des managers
 
-Docker Swarm supporte la perte de `(N - 1) / 2` managers, où `N` est le nombre de managers. Il est donc fortement conseillé que chaque manager se trouve isolé dans un data center différent des autres managers, ceci afin d'éviter que la perte d'un data center contenant plus de `(N - 1) / 2` managers ne provoque la perte du consensus sur l'état du swarm. Comme on peut le voir dns le tableau ci-dessous, afin de garantir le fonctionnement optimal du cluster et supporter la perte d'un des managers, le nombre minimum de manager et de 3.
+Docker Swarm supporte la perte de `(N - 1) / 2` managers, où `N` est le nombre de managers. Il est donc fortement conseillé que chaque manager se trouve isolé dans un data center différent des autres managers, ceci afin d'éviter que la perte d'un data center contenant plus de `(N - 1) / 2` managers ne provoque la perte du consensus sur l'état du swarm. Comme on peut le voir dns le tableau ci-dessous, afin de garantir le fonctionnement optimal du cluster et supporter la perte d'un des managers, le nombre minimum de manager est de 3.
 
 | Nombre de managers | Nombre de managers nécessaires<br />pour garantir le quorum | Nombre de managers<br />pouvant être perdus | Répartition<br />(2 zones) | Répartition<br />(avec 3 zones) |
 | :----------------: | :---------------------------------------------------------: | :-----------------------------------------: | -------------------------- | ------------------------------- |

documentation/03.mise-en-place-d-une-infrastructure-de-demonstration.md

@@ -90,7 +90,7 @@ sudo dpkg-reconfigure locales
 
 Si les machines ne sont pas sur le bon gateway, ou si elles ne sont pas encore autorisées à sortir sur les ports nécessaires sur le load balancer HAProxy de SIPR, il peut être nécessaire de configurer le passage par le proxy HTTP(S) des Data Center afin d'accéder à l'Internet et pouvoir installer les paquets requis. Ce proxy doit être configuré pour différentes applications. 
 
-> **Note** : Attention toutefois que pour l'utilisation de Docker, les machines devront être capables de faire des requêtes vers l'extérieur sur les ports 22 et 11371 qui ne sont pas pris en charge par le proxy du Data Center. Configurer le proxy HTTP(S) permet toutefois l'installation des paquets nécessaires sur les machines en attendant que la configuration sur le load balancer HAProxy de SIPR soient terminées.
+> **Note** : Attention toutefois que pour l'utilisation de Docker, les machines devront être capables de faire des requêtes vers l'extérieur sur les ports 22 et 11371 qui ne sont pas pris en charge par le proxy du Data Center. Configurer le proxy HTTP(S) permet toutefois l'installation des paquets nécessaires sur les machines en attendant que la configuration sur le load balancer HAProxy de SIPR soit terminée.
 
 #### Apt (normalement pas nécessaire)
 
@@ -280,12 +280,12 @@ Dans `/etc/docker/daemon.json` ajouter la configuration des sockets pour `docker
 ```
 
 > **Notes** : 
-> - L'utilisation de `tcp://0.0.0.0:2376` n'est en théorie pas sécurisée car elle permet à n'importe quelle machine de parler au daemon Docker. Néanmoins, dans le cadre de mon infrastructure, cela ne pose pas de problème, puisqu’il est facile de limiter les accès aux machines du cluster elles-mêmes via des règles de firewall. j’ajouterais également, que le port 2376 n'étant accessible que via le VLAN des noeuds Docker, les risques sont assez réduis surtout en comparaison de la simplification qu'ils permettent dans la gestion du cluster.
+> - L'utilisation de `tcp://0.0.0.0:2376` n'est en théorie pas sécurisée car elle permet à n'importe quelle machine de parler au daemon Docker. Néanmoins, dans le cadre de mon infrastructure, cela ne pose pas de problème, puisqu’il est facile de limiter les accès aux machines du cluster elles-mêmes via des règles de firewall. j’ajouterais également, que le port 2376 n'étant accessible que via le VLAN des noeuds Docker, les risques sont assez réduits surtout en comparaison de la simplification qu'ils permettent dans la gestion du cluster.
 > - Je n'ai pas activé le TLS sur le port 2376 à ce stade et ce principalement pour 2 raisons : il n'est pas nécessaire pour les raisons citées plus haut (VLAN + firewall), il requiert un certificat pour lequel il me semble préférable d'attendre qu'une CA "interne" aux Data Center SIPR soit disponible (l'alternative étant un certificat auto-signé). 
 
 ##### Configurer un registry non sécurisé
 
-Par défaut, Docker refuse d'utiliser un registry qui ne serait pas accessible via HTTPS. Il est toutefois possible de définir des regitries non sécurisé directement dans la configuration du daemon.
+Par défaut, Docker refuse d'utiliser un registry qui ne serait pas accessible via HTTPS. Il est toutefois possible de définir des regitries non sécurisés directement dans la configuration du daemon.
 
 Dans `/etc/docker/daemon.json` ajouter la configuration du registry (l'installation du registry est décrite plus loin) :
 
@@ -329,7 +329,7 @@ Voici le fichier `daemon.json` complet :
 
 #### Relancer le daemon Docker
 
-Recharger la configuration de systemd `sudo systemctl daemon-reload` et relancer docker `sudo systemctl retsart docker`.
+Recharger la configuration de systemd `sudo systemctl daemon-reload` et relancer docker `sudo systemctl restart docker`.
 
 Puis relancer Docker : `sudo systemctl restart docker`
 
@@ -469,7 +469,7 @@ Son utilisation est identique à celle de Docker Compose en version standalone,
 > - `docker compose version` : Docker Compose version v2.17.3
 > - `docker-compose version` : Docker Compose version v2.18.1
 
-De plus la version du plugin est maintenue les mainteneurs des paquets Docker pour les différentes distributions Linux.
+De plus la version du plugin est maintenue par les mainteneurs des paquets Docker pour les différentes distributions Linux.
 
 ## Déploiement du cluster Docker Swarm
 
@@ -518,7 +518,7 @@ Une fois le swarm initialisé, il est possible de lui ajouter d'autres nœuds wo
 
 Dans un swarm avec plusieurs managers, il reste à promouvoir les autres managers. 
 
-Pour obtenir d'un consensus sur l'état du cluster, il faut un nombre impair de managers. Afin de combiner redondance et performances, 2 managers supplémentaires sont ajoutés. Ajouter des managers supplémentaires peut se faire de deux manières :
+Pour obtenir un consensus sur l'état du cluster, il faut un nombre impair de managers. Afin de combiner redondance et performances, 2 managers supplémentaires sont ajoutés. Ajouter des managers supplémentaires peut se faire de deux manières :
 
 - En spécifiant le rôle de manager dans la commande en exécutant la commande générée par `docker swarm join-token manager` sur chacun des managers supplémentaires (voir plus haut)
 - En promouvant les noeuds en manager depuis le premier manager. Cette méthode est décrite plus bas.
@@ -723,9 +723,9 @@ Pour compléter l'installation, il reste à ajouter le Registry dont l'url est `
 > Impacts :
 >
 > 1. l'agent consomme moins de ressource système lors de son exécution (1/2 CPU)
-> 2. l'agent tourne 2 fois plus souvent (toutes les 30 minutes au lieu  de loutes les 1h)
+> 2. l'agent tourne 2 fois plus souvent (toutes les 30 minutes au lieu  de toutes les 1h)
 >
-> L'exécution de l'agent impactent moins les performances et la consommation de ressources des machines hôtes.
+> L'exécution de l'agent impacte moins les performances et la consommation de ressources des machines hôtes.
 
 Fichier complet de déploiement de Portainer :
 

documentation/05.livraison-continue.md

@@ -165,7 +165,7 @@ Voici deux exemples qui illustrent l'utilisation de ces mécanismes pour le dép
 
 #### Déploiement d'une pile Wordpress
 
-L'exemple suivant combine variables définie dans l'environnement du shell qui exécute la commande de déploiement (par exemple via un fichier .env) et fichiers d'environnement dans un même fichier Docker Compose, afin de déployer une instance de Wordpress:
+L'exemple suivant combine variables définies dans l'environnement du shell qui exécute la commande de déploiement (par exemple via un fichier .env) et fichiers d'environnement dans un même fichier Docker Compose, afin de déployer une instance de Wordpress:
 
 ```yaml
 version: '3.7'
@@ -219,7 +219,7 @@ MYSQL_USER=wp1user
 MYSQL_PASSWORD=wp1pass
 ```
 
-Les variables passées peuvent également être utilisées dans les conteneurs eux-mêmes. Voici un exemple d'une telle utilisation dans l'entry point d'un service pour déployer la plateforme Moodle :
+Les variables passées peuvent également être utilisées dans les conteneurs eux-mêmes. Voici un exemple d'une telle utilisation dans l'entrypoint d'un service pour déployer la plateforme Moodle :
 
 ```bash
 # entrypoint.sh
@@ -275,13 +275,13 @@ Les contraintes étaient :
 
 ##### Déploiement dans des environnements multiples 
 
-La pile applicative du portail devait pourvoir être déployée dans des environnements de test (sur les machines locales des développeurs), des instances spécifiques à certains usages (test, formation, migration, démonstration...) et, bien entendu, la pré-production (QA) et la production. Chacun de ces environnements avait ses spécificités quant à la configuration de la pile applicative.
+La pile applicative du portail devait pouvoir être déployée dans des environnements de test (sur les machines locales des développeurs), des instances spécifiques à certains usages (test, formation, migration, démonstration...) et, bien entendu, la pré-production (QA) et la production. Chacun de ces environnements avait ses spécificités quant à la configuration de la pile applicative.
 
 En particulier, la topologie de la pile (cluster avec 1 ou plusieurs noeuds), localisation de la base de donnée (dans la pile applicative ou sur un hôte distant), le montage de volume supplémentaires pour les migrations...
 
 ##### Déploiement sur des environnements d'exécution différents
 
-Afin de répondre tant aux besoins des développeurs que de prestataires externes, les piles ont dû être rendue compatible avec les environnements d'exécution Docker Compose, utilisé sur les machines locales sous MacOSX ou Windows, et Docker Swarm, utilisé sur les clusters distants ou sur les machines locales sous Linux.
+Afin de répondre tant aux besoins des développeurs que de prestataires externes, les piles ont dû être rendues compatibles avec les environnements d'exécution Docker Compose, utilisé sur les machines locales sous MacOSX ou Windows, et Docker Swarm, utilisé sur les clusters distants ou sur les machines locales sous Linux.
 
 ##### Variables d'environnements et composition de piles Docker
 
@@ -425,7 +425,7 @@ Le cas de Docker Compose est un peu particulier, puisqu'une personnalisation du
 
 ##### Généralisation
 
-Bien que créé spécifiquement pour le portail, ce mécanisme peut être généralisé avec un minimum d'effort et intégrer à d'autres piles applicatives. Il pourrait également être transformer en un ensemble de tâche Ansible ou être appelé par le mécanisme de livraison continue.
+Bien que créé spécifiquement pour le portail, ce mécanisme peut être généralisé avec un minimum d'effort et intégrer à d'autres piles applicatives. Il pourrait également être transformé en un ensemble de tâches Ansible ou être appelé par le mécanisme de livraison continue.
 
 ## Déploiement d’applications avec Ansible et Docker-Compose
 
@@ -671,7 +671,6 @@ services:
 Le script `wait-for-it.sh` permet d’attendre qu’un service soit disponible avant d’exécuter une commande. C’est particulièrement important pour éviter une erreur lors du démarrage du service nginx. Ce script est disponible dans les fichiers techniques ou sur [github](https://github.com/vishnubob/wait-for-it).
 
 ```yaml
----
 - name: "Deploying framemo application on a swarm"
   hosts: localhost
   connection: local
@@ -1008,7 +1007,7 @@ Afin de mettre en place ce mécanisme, j’ai choisi d’utiliser les outils sui
 Le mécanisme contient deux parties :
 
 - Un service gitlab-runner doit être déployé sur la machine qui exécutera les tâches de déploiement
-- Ce service doit être configuré dans les runners disponibles sur Gitlab. Un runner peut être soit `shared` pour l'ensemble des projets héberger sur l'instance Gitlab, soit dédié à un groupe de projets ou à un projet spécifique.
+- Ce service doit être configuré dans les runners disponibles sur Gitlab. Un runner peut être soit `shared` pour l'ensemble des projets hébergés sur l'instance Gitlab, soit dédié à un groupe de projets ou à un projet spécifique.
 
 L'enregistrement d'un runner se fait via l'interface de Gitlab, chaque runner se voit associé un token qui l'identifie et un autre qui permet au service gitlab-runner de s'enregistrer auprès de gitlab.
 

documentation/06.perspectives.md

@@ -10,7 +10,7 @@ Dans ce chapitre, je donne des pistes et des propositions pour de telles amélio
 
 ### Le proxy interne du cluster
 
-Le principal problème du reverse proxy interne que j'ai mis en place est qu'il ne permet pas une détection automatique des services déployés. Une autre de ses limitations est que si l'un des service exposés via mon proxy vient à ne plus répondre pour une raison ou pour une autre, c'est l'entièreté du proxy qui refusera de redémarrer. Cette situation peut se produire simplement si une pile applicative est arrêtée ou détruite et que le fichier de configuration du site correspondant n'a pas été supprimé du disque.
+Le principal problème du reverse proxy interne que j'ai mis en place est qu'il ne permet pas une détection automatique des services déployés. Une autre de ses limitations est que si l'un des services exposés via mon proxy vient à ne plus répondre pour une raison ou pour une autre, c'est l'entièreté du proxy qui refusera de redémarrer. Cette situation peut se produire simplement si une pile applicative est arrêtée ou détruite et que le fichier de configuration du site correspondant n'a pas été supprimé du disque.
 
 Corriger ces quelques problèmes n'est pas impossible, mais requierait la mise en place de mécanismes qui existent déjà au sein d'autres solutions de reverse proxy.
 
@@ -47,12 +47,12 @@ Dans ce projet, j'ai décidé de me baser sur [nginx-proxy](https://github.com/n
 Afin d'assurer la détection automatique des services exposés, nginx-proxy repose sur la déclaration de variables d'environnement :
 
 - `VIRTUAL_HOST` est le fqdn via lequel le service est appelé depuis l'extérieur du Swarm
-- `VIRTUAL_PROTO` est le protocole avec lequel appeler service à l'intérieur du Swarm (https ou http), par défaut il est identique à celui utilisé depuis l'extérieur du Swarm
+- `VIRTUAL_PROTO` est le protocole avec lequel appeler le service à l'intérieur du Swarm (https ou http), par défaut il est identique à celui utilisé depuis l'extérieur du Swarm
 - `VIRTUAL_PORT` est le port sur lequel est accessible le service dans le Swarm, par défaut il est identique à celui utilisé depuis l'extérieur du Swarm
 
-Mais pour que nginx-roxy puisse joindre les services, il faut encore les connecter sur un réseau overlay partagé avec celui-ci. Le proxy détecte les services exposés via le socket Docker de la machine et sur base des variables d'environnement défines plus haut. Ensuite, un système de templates permet de générer les configurations de sites.
+Mais pour que nginx-proxy puisse joindre les services, il faut encore les connecter sur un réseau overlay partagé avec celui-ci. Le proxy détecte les services exposés via le socket Docker de la machine et sur base des variables d'environnement défines plus haut. Ensuite, un système de templates permet de générer les configurations de sites.
 
-> **Note**: Nginx proxy peut gérer le renouvellement automatique des certificats SSL soit via letsencrypt soit via ACME. Il peut aussi utiliser des certificats pré-générés fournit dans des fichiers locaux.
+> **Note**: Nginx proxy peut gérer le renouvellement automatique des certificats SSL soit via letsencrypt soit via ACME. Il peut aussi utiliser des certificats pré-générés fournis dans des fichiers locaux.
 
 Voici un exemple de fichier de déploiement du proxy :
 
@@ -260,7 +260,7 @@ networks:
 
 La solution nginx-proxy est tout à fait satisfaisante pour la mise en place d'une infrastructure d'hébergement d'application web de type "single page", blog ou autre CMS. Elle est par contre moins adaptée s'il s'agit de mettre en place une infrastructure donnant accès à des web services via des API REST, GraphQL, SOAP... Dans ce cas de figure, Traefik est la solution la plus adaptée. 
 
-La solution la plus adaptée a Docker Swarm est Traefik. Traefik offre une grande souplesse dans la définition des règles de proxy pour les différents services.  En particulier, il permet la publication d'un même service sur plusieurs fqdn ou sur des paths différents d'un même fqdn, la publication de plusieurs ports d'un même service sur des endpoints (paths ou fqdn) différents, la gestion fine des droits d'accès... Bref tout ce qui est nécessaire pour fournir à la fois un hébergement d'application web et et la publication de services via des API.
+La solution la plus adaptée a Docker Swarm est Traefik. Traefik offre une grande souplesse dans la définition des règles de proxy pour les différents services.  En particulier, il permet la publication d'un même service sur plusieurs fqdn ou sur des paths différents d'un même fqdn, la publication de plusieurs ports d'un même service sur des endpoints (paths ou fqdn) différents, la gestion fine des droits d'accès... Bref tout ce qui est nécessaire pour fournir à la fois un hébergement d'application web et la publication de services via des API.
 
 Le prix à payer est une plus grande complexité dans sa prise en main.
 
@@ -318,7 +318,7 @@ volumes:
   portainer_data:
 ```
 
-### Automatiser le renouvellement des certificats TLS avec Acme
+### Automatiser le renouvellement des certificats TLS avec ACME
 
 Il est aujourd'hui possible de renouveler les certificats des serveurs automatiquement avec ACME. Toutefois cette solution demande des adaptations au niveau du load balancer SIPR. En effet, dans l'implémentation actuelle, le proxy HTTP et la gestion du certificat SSL se font au niveau du load balancer. Or, le renouvellement du certificat via ACME se fera au niveau des conteneurs. 
 
@@ -703,7 +703,7 @@ gluster volume set vol-1 performance.cache-invalidation on
 
 ##### Consensus et Glusterfs
 
-Comme pour Docker Swarm, un nombre perd de répliques de volumes peuvent causer un "split-brain", c'est-à-dire une situation dans laquelle aucun consensus ne peut être trouvé pour l'état du volume. Il est conseillé d'avoir un nombre impair de noeuds (minimum 3) pour Glusterfs.
+Comme pour Docker Swarm, un nombre paire de répliques de volumes peuvent causer un "split-brain", c'est-à-dire une situation dans laquelle aucun consensus ne peut être trouvé pour l'état du volume. Il est conseillé d'avoir un nombre impair de noeuds (minimum 3) pour Glusterfs.
 
 https://docs.gluster.org/en/latest/Troubleshooting/resolving-splitbrain/
 

documentation/99.conclusion.md

@@ -54,6 +54,6 @@ Je tiens tout d'abord à remercier mon collègue Mike De Man avec qui j'ai pu ex
 
 Je tiens également à remercier François Micaux qui m'a conforté dans mes choix techniques lors de la formation Docker qu'il a animée pour les équipes du SGSI et qui m'a permis d'améliorer ma maîtrise de Docker. 
 
-Je remercie aussi mon coach Thomas Koetgen dont les conseils et le soutien m'ont permis de mener à bien ce brevet, ainsi que mon évaluateur Jean-Luc Martou pour ses encouragements à terminer mon projet.
+Je remercie aussi mon coach Thomas Keutgen dont les conseils et le soutien m'ont permis de mener à bien ce brevet, ainsi que mon évaluateur Jean-Luc Martou pour ses encouragements à terminer mon projet.
 
 Et bien entendu, je remercie Valérie qui m'inspire tous les jours.
\ No newline at end of file