Spelling and more

report/R_abstract.md

@@ -4,14 +4,15 @@ Novaquark est un studio de jeux vidéo réalisant un jeu en ligne massivement mu
 
 Durant les six mois de mon stage, j'ai travaillé au sein de l'équipe en charge
 du développement du serveur, dans le but de mettre en place les bases de
-l'infrastructure d'informatique en nuage nécessaire à la mise à l'échelle
+l'infrastructure d'informatique en nuage nécessaires à la mise à l'échelle
 automatiquement du nombre de serveurs en fonction du nombre de joueurs
 connectés.
 
 \vspace{1em}
 
 Le jeu étant encore en phase de développement intensif, j'ai donc surtout
-analyser différentes solutions d'hébergement, de déploiement, etc.
+analysé les différentes solutions d'hébergement, de déploiement, etc. avant de
+monter en compétence sur les technologies retenues.
 
 \vspace{1em}
 

report/R_bilan.md

@@ -18,7 +18,7 @@ tout ce qui gravite autour du serveur de jeu :
 
 \vspace{1em}
 
-D'autre part, j'ai également permis d'éclaircir certain points encore
+D'autre part, j'ai également permis d'éclaircir certains points encore
 obscurs tels que l'authentification, le système de chat ou encore
 l'architecture de déploiement et de mise à jour. Cela sera mis en
 place lorsque les développeurs seront plus avancés sur ces points.
@@ -33,10 +33,14 @@ ancienne dans les environnements Solaris et BSD, l'utilisation des
 conteneurs est quelque chose d'assez nouveau au sein du noyau Linux et
 est en train de se généraliser depuis plusieurs mois.
 
-Par ailleurs, j'ai travaillé avec de nombreuses application,
-bibliothèques et technologies libres, et suis ravi d'avoir pu
-contribué au nom de l'entreprise au développement ou à l'amélioration
+\vspace{1em}
+
+Par ailleurs, j'ai travaillé avec de nombreuses applications,
+bibliothèques et technologies libres, et suis ravi d'avoir pu,
+contribuer au nom de l'entreprise, au développement ou à l'amélioration
 de plusieurs projets.
 
+\vspace{1em}
+
 Enfin, la diversité du travail effectué durant ce stage fut
 particulièrement gratifiant.

report/R_glossaire.md

@@ -1,34 +1,61 @@
 Chat
 
-:   Moyen de communication instantanné entre les joueurs.
+:   Moyen de communication instantané entre les joueurs.
+
+\vspace{0.5em}
 
 Cluster
 
-:   Un groupe de machine.
+:   Un groupe de machines.
+
+\vspace{0.5em}
 
 Cloud computing
 
 :   Voir *Informatique en nuage*.
 
+\vspace{0.5em}
+
 Conteneur
 
 :   Système d'exploitation complet (programmes, bibliothèques, ...) exécuté par
     un noyau compatible (GNU/Linux, BSD, Solaris). L'idée est de cloisonner,
-	voire de restreindre, les actions effectuée par ce conteneur.
+	voire de restreindre, les actions effectuées par ce conteneur.
+
+\vspace{0.5em}
 
 Déploiement
 
 :   Configurer une machine ou un programme pour qu'il s'exécute d'une manière
     définie.
 
+\vspace{0.5em}
+
+DevOps
+
+:   Personne ou groupe de personnes chargé d'écouter les demandes des
+    équipes de développement afin de répondre aux mieux à leur besoin du
+    point de vue du système d'information mis à leur disposition.
+
+\vspace{0.5em}
+
 Front-end
 
 :   Partie d'un système exposée à l'utilisateur final. En opposition au
     *back-end* qui lui n'est pas voué à être accédé par l'utilisateur final.
 
+\vspace{0.5em}
+
 Informatique en nuage
 
-:   s
+:   Abstraction des couches bases d'un système qui ne relèvent pas du
+    cœur de métier d'une entreprise. Les premières couches concernées
+    par les délégations/sous-traitements sont le matériel, puis le
+    système d'exploitation, et peuvent aller jusqu'à la mise à
+    disposition d'un logiciel particulier configuré pour un usage
+    déterminé.
+
+\vspace{0.5em}
 
 Journaux
 
@@ -39,17 +66,23 @@ Journaux
     environnement de développement, on va enregistrer les
     avertissements ou des informations de développement.
 
+\vspace{0.5em}
+
 Load-balancer
 
 :   Machine ou groupe de machines dont le rôle est d'orienter le trafic
     entrant vers un second groupe de machines, effectuant un travail plus
     lourd.
 
+\vspace{0.5em}
+
 Machine virtuelle
 
 :   Simulation complète d'une machine physique effectuée par un programme de
     virtualisation (hyperviseur ou émulateur) dans le but de tester un système
-	ou pour isoler l'exécution de programmes.
+    ou pour isoler l'exécution de programmes.
+
+\vspace{0.5em}
 
 Monitoring
 
@@ -57,17 +90,23 @@ Monitoring
     relevé de métriques permettant de s'assurer de la bonne marche des
     installations.
 
+\vspace{0.5em}
+
 Pare-feu
 
 :   Programme filtrant les données passant sur le réseau d'une machine
     connectée afin de supprimer le trafic qui n'est pas jugé légitime
     suivant des critères prédéfinis.
 
+\vspace{0.5em}
+
 Plugin
 
 :   Extension d'un programme se présentant généralement sous la forme
     d'un module, permettant de lui ajouter des fonctionnalités.
 
+\vspace{0.5em}
+
 SSH
 
 :   Protocole sécurisé de connexion à distance dans les environnements

report/R_intro.md

@@ -18,9 +18,9 @@ d'évoluer dans un monde éditable (à la manière de Minecraft).
 Depuis la création de l'entreprise, de nombreux concurrents sont apparus,
 partageant des idées innovantes de \Dual :
 
-- Untold Universe : projet similaire incubé chez Startup 42 ;
-- Star Citizen : MMO par concepteur de jeux vidéo Chris Roberts ;
+- Star Citizen : MMO par le concepteur de jeux vidéo Chris Roberts ;
 - No Man's Sky : MMO dans un univers généré de manière procédurale ;
+- Untold Universe : projet similaire incubé chez Startup 42 ;
 - Blockscape ;
 - Space Engineers ;
 - Planets Cube ;
@@ -47,7 +47,7 @@ mener à bien mon sujet de stage.
 
 \vspace{1em}
 
-Depuis l'équipe s'est aggrandie et se compose aujourd'hui de 10 personnes :
+Depuis, l'équipe s'est aggrandie et se compose aujourd'hui de 10 personnes :
 dont un concepteur de jeux-vidéo, un gestionnaire de communauté, un graphiste,
 un développeur client, et trois autres stagiaires. Voir l'organigramme figure
 \ref{fig:img/organigrame.pdf} en page \pageref{fig:img/organigrame.pdf}.
@@ -73,9 +73,13 @@ solutions existantes de déploiement automatique, puis d'écrire un certain
 nombre de *recettes*. Les premières *recettes* concernaient le déploiement des
 machines de monitoring.
 
+\vspace{1em}
+
 Par la suite, lorsque le serveur a été suffisamment fonctionnel, j'ai eu à
 concevoir le système de test de montée en charge.
 
+\vspace{1em}
+
 De nombreuses tâches annexes m'ont également été attribuées tout au long du
 stage en particulier pour connaître mon avis d'administrateur système quant à
 l'implémentation de certaines fonctionnalités pouvant influer sur le
@@ -84,7 +88,7 @@ déploiement, la charge ou la sécurité.
 ## Maturité de l'entreprise
 
 L'entreprise démarrant son activité, elle n'avait encore aucune base de travail
-lié à mon sujet de stage.
+liée à mon sujet de stage.
 
 Les autres employés de l'entreprise travaillaient sur d'autres problématiques :
 principalement le code du client : moteur de rendu, expérience de jeu, etc.
@@ -129,16 +133,19 @@ Pour l'entreprise, mon stage a permis d'établir :
 
 L'entreprise est établie dans l'incubateur Agoranov ; une pièce nous y a été
 attribuée. Nous nous y retrouvons tous pour travailler, il est donc facile de
-parler à n'importe qui puisque l'on se trouve dans le même espace.
+parler à n'importe qui puisque l'on se trouve dans le même espace. Voir la
+figure \ref{fig:img/tinyplanet.jpg} sur la page suivante.
 
-%%fimage(img/tinyplanet.jpg, 0.49, "Notre espace de travail")
+\vspace{1em}
 
 Dès le premier jour, une machine dotée de composants de pointe m'a été
 attribuée ; il m'a été laissé le choix du système d'exploitation. Au milieu de
-mon stage, j'ai eu besoin de travailler avec un disque dur plus réactif, à la
+mon stage, j'ai eu besoin de travailler avec un disque dur plus réactif ; à la
 suite de ma demande, celui-ci a été commandé dans la semaine.
 
-\vspace*{1em}
+\vspace{1em}
 
 Arrivé quelques semaines après la création de l'entreprise, j'ai participé à
 l'élaboration des premières documentations.
+
+%%fimage(img/tinyplanet.jpg, 0.9, "Notre espace de travail")

report/R_organisationnels.md

@@ -5,7 +5,7 @@
 Afin de mesurer l'ampleur de l'architecture qu'il est nécessaire de mettre en
 place, mon stage a débuté par plusieurs comparaisons d'outils et
 l'apprentissage de certains concepts propres aux jeux vidéo et tout
-particulièrement aux jeux massivement multi-joueurs.
+particulièrement aux jeux en ligne massivement multijoueurs.
 
 \vspace{1em}
 
@@ -15,7 +15,7 @@ résultats ainsi que leur critique.
 ### Montée en compétences
 
 Une fois les outils sélectionnés suivants les critères établis au travers de
-l'étape précédente, il a fallu montée en compétence sur ceux-ci.
+l'étape précédente, il m'a fallu monter en compétence sur ceux-ci.
 
 ### Développements et tests de montée en charge
 
@@ -44,6 +44,8 @@ de telle sorte que chaque étape coïncide avec les besoins de chacun.
 Le développement du jeu suit une méthodologie agile : cela a commencé par
 Kaban, pour arriver aujourd'hui à Scrum.
 
+\vspace{1em}
+
 Deux fois par semaine, toute l'équipe fait le point sur l'avancée de
 chacun. C'est l'occasion de recentrer les priorités.
 
@@ -52,6 +54,8 @@ activités de la journée, en n'oubliant pas d'indiquer les difficultés que l'o
 peut rencontrer. En fonction de la difficulté, un membre de l'équipe peut être
 amené à donner son avis sur le problème s'il l'a déjà rencontré par le passé.
 
+\vspace{1em}
+
 Le soir est toujours une bonne occasion de discuter avec mon maître de stage :
 que ce soit pour se tenir mutuellement informés de nos activités ou pour faire
 le point sur les développements à venir.

report/R_technique.md

@@ -7,8 +7,9 @@ facilement d'adapter leur nombre en fonction du besoin (fortement en
 corrélation avec le nombre de joueurs inscrits et connectés).
 
 Depuis quelques années, un grand nombre de plates-forme se développent,
-fournissant un service clef en main ; mais des solutions libres sont également
-disponibles lorsque l'on désire s'occuper du service manuellement.
+fournissant un service de mise à l'échelle clef en main ; mais des solutions
+libres sont également disponibles lorsque l'on désire s'occuper du service
+manuellement.
 
 Ici, l'objectif était de trouver les avantages et les inconvénients de chaque
 fournisseur et de contre balancer cette analyse par rapport aux solutions à
@@ -71,17 +72,19 @@ d'harmonisation, les difficultés de réalisation des mises à jour, les besoins
 de tests de l'environnement avant la mise en production, le redéploiement
 rapide d'une version stable ou précédente.
 
+\vspace{1em}
+
 Il est nécessaire de configurer de nombreuses machines dans différents cadres :
 
-* ajout d'un nouveau serveur au sein du cluster (fournir le contexte) ;
+* ajout d'un nouveau serveur au sein du cluster (lui fournir le contexte et l'annoncer) ;
 * configuration d'une machine virtuelle à destination des développeurs ;
 * configuration des serveurs annexes (sites web, bases de données, monitoring, ...).
 
 ### Alternatives possibles
 
 Dans de nombreux environnements chaque machine est configurée à la main par un
-administrateur système, à chaque étape, une erreur humaine peut venir
-interférer dans la procédure de mise à jour.
+administrateur système ; à chaque étape, une erreur humaine peut venir
+interférer dans les procédures de mise à jour.
 
 Cette solution est évidemment à écarter si l'on veut garder le contrôle de son
 système d'information et pouvoir faire face à tout type de problème.
@@ -121,17 +124,17 @@ La virtualisation peut nous être utile à plusieurs niveaux :
 
 \vspace{1em}
 
-Si dans une contexte de production les serveurs sont utilisés à une valeur
+Si dans un contexte de production les serveurs sont utilisés à une valeur
 proche de leur puissance maximale, pour un environnement de test, il est tout à
-fait envisageable de regrouper les différentes machines nécessaire au sein de
+fait envisageable de regrouper les différentes machines nécessaires au sein de
 plusieurs machines virtuelles d'une même machine physique, dédiée aux tests.
 
 \vspace{1em}
 
 Pour les développeurs, l'installation de l'environnement de développement n'est
 pas toujours facile (surtout s'ils doivent alterner entre deux systèmes
-d'exploitation différent) et requiert une certaine standardisation (versions
-précises de certaine bibliothèques, paquet particulier). La virtualisation
+d'exploitation différents) et requiert une certaine standardisation (versions
+précises de certaines bibliothèques, paquets particuliers). La virtualisation
 permet de leur fournir un environnement clef en main qu'ils n'ont pas à
 maintenir.
 
@@ -139,8 +142,8 @@ maintenir.
 
 Sont apparues ces dernières années des technologies prônant le déploiement en
 production de machines virtuelles ou conteneur. Cela permet d'avoir une série
-de machine hôte dédiée au déploiement et des machines virtuelles minimalistes
-et standardisées (pas d'écoute SSH par exemple).
+de machines hôtes dédiées au déploiement et des machines virtuelles
+standardisées et minimalistes (pas d'écoute SSH par exemple).
 
 ### Propositions retenues
 
@@ -176,18 +179,17 @@ avancée que ne permettrait pas de faire Docker.
 
 ### Objectifs
 
-Le chat est un élément essentiel dans un jeu massivement
+Le chat est un élément essentiel dans un jeu en ligne massivement
 multijoueurs. Pour nous éviter de réinventer la roue, il a fallu faire
 le choix d'une technologie existante et répondant à nos besoins.
 
 ### Alternatives possibles
 
 Ajouter au sein du serveur de jeu la gestion du chat aurait pu être
-envisageable. Cependant, il peut être fastidieux de programmer un
-système complet (par exemple il faut prévoir les systèmes de
-modération, de répartition de charge, ...). Afin d'éviter de faire
-perdre du temps inutilement au développement, il a donc été préféré le
-choix d'une technologie existante.
+envisageable. Cependant, il peut être fastidieux de programmer un système
+complet (par exemple il faut prévoir les systèmes de modération, de répartition
+de charge, ...). Afin d'éviter d'ajouter inutilement du temps au développement,
+il a donc été préféré le choix d'une technologie existante.
 
 ### Propositions retenues
 
@@ -230,15 +232,15 @@ vulnérabilités qui pourraient être découvertes une fois le jeu lancé.
 
 D'autre part, étant donné que plusieurs services devront pouvoir
 s'authentifier en un point central, cela évite de fournir un travail
-pour rendre compatibles avec une solution maison les logiciels
-compatibles avec des solutions d'authentification standards.
+pour rendre compatibles avec une solution maison les logiciels déjà
+opérationnels avec des solutions d'authentification standards.
 
 ### Propositions retenues
 
 Les solutions de centralisation d'authentification courantes sont :
 
 * LDAP ;
-* Kerberos/PKINIT ;
+* Kerberos, PKINIT ;
 * RADIUS.
 
 ### Résultats obtenus
@@ -256,7 +258,7 @@ au sein du client de jeu (chat, jeu, contenus, marché) et compte tenu du fait
 que plusieurs serveurs vont être contactés par le client au fil de l'évolution
 du joueur dans le jeu, l'authentification par un serveur Kerberos puis
 l'échange de tickets permet de s'affranchir de trop nombreuses
-authentifications.
+authentifications répétées.
 
 
 \newpage
@@ -285,8 +287,8 @@ choisi de le développer.
 \vspace{1em}
 
 Le langage retenu fut le Go : le langage compilant les binaires statiquement,
-il n'y aurait donc rien de plus à installer sur les machines sur lesquels nous
-devrons faire les relevés.
+il n'y aurait donc rien de plus à installer sur les machines sur lesquelles
+nous devions faire les relevés.
 
 ### Résultats obtenus
 
@@ -295,21 +297,22 @@ CC0.
 
 Il a ensuite été annoncé à la communauté InfluxDB qui lui a fait un bon
 accueil : nous avons eu quelques retours sur des fonctionnalités manquantes et
-les membres de la communauté ont eux-mêmes pris la peine de modifier le code
+des membres de la communauté ont eux-mêmes pris la peine de modifier le code
 pour y faire des améliorations.
 
 \vspace{1em}
 
-En sus de ce programme de relevé de métrique, il m'a été demandé de réaliser un
-tableau de bord permettant de visualiser en temps réel les données
+En sus de ce programme de relevé de métriques, il m'a été demandé de réaliser
+un tableau de bord permettant de visualiser en temps réel les données
 compilées. Le premier tableau de bord a été réalisé directement avec le serveur
 web de la base de données allié à la bibliothèque JavaScript *Cubism* (voir
 figure \ref{fig:img/cubism.png}) : il permet de visualiser en un coup d'oeil
-l'état des différents serveurs. Le deuxième dashboard utilise la bibliothèque
-JavaScript *Graphana* : il montre sous une autre forme les données enregistrées
-dans la base de données en permettant plus facilement de comparer sur le long
-terme l'utilisation des ressources sur les machines en les corrélant avec les
-événements survenus dans le jeu.
+l'état des différents serveurs. Le deuxième tableau de bord utilise la
+bibliothèque JavaScript *Graphana* (voir figure
+\ref{fig:img/grafana-monitor0.png}) : il montre sous une autre forme les
+données enregistrées dans la base de données en permettant plus facilement de
+comparer sur le long terme l'utilisation des ressources sur les machines en les
+corrélant avec les événements survenus dans le jeu.
 
 %%fimage(img/cubism.png, 0.7, "Tableau de bord réalisé avec Cubism")
 %%fimage(img/grafana-monitor0.png, 1, "Tableau de bord réalisé avec Graphana")
@@ -326,60 +329,70 @@ reconfiguré rapidement en fonction des rôles qui lui sont attribués.
 
 Certains rôles sont réutilisés d'une recette à l'autre : par exemple la machine
 virtuelle de développement est un serveur de jeu sur lequel tous les types de
-serveur sont disponibles et elle possède également une base de donnée locale.
+serveur de jeu sont disponibles et elle possède également une base de donnée
+locale.
 
 ### Résultats obtenus
 
 Les recettes qu'il a été nécessaire de développer sont les suivantes :
 
-- **serveur de monitoring :** chaque serveur déployé assure son rôle grâce à la
+- **Serveur de monitoring :** chaque serveur déployé assure son rôle grâce à la
   mise à disposition d'une base de données InfluxDB et à des outils permettant
-  de visualiser la charge. Afin de toujours connaître l'état en temps réel
-  des serveurs de jeu, chaque serveur configuré est inclus au sein d'un
-  cluster de haute-disponibilité.
-- **serveurs de base de données :** pour l'instant un seul type de base de
+  de visualiser la charge et les événements. Afin de toujours connaître l'état
+  en temps réel des serveurs de jeu, chaque serveur configuré est inclus au
+  sein d'un cluster de haute-disponibilité, grâce à LVS et Keepalived.
+- **Serveurs de base de données :** pour l'instant un seul type de base de
   données est utilisé : Redis. La recette doit permettre de déployer un serveur
   au sein d'un cluster Redis. À terme, un second type de base de données devra
-  être déployé afin de disposer de stockage permanent.
-- **serveurs de jeu :** le serveur étant décomposé en trois parties, trois
-  recettes différentes sont nécessaires, en fonction du type de serveur que
-  l'on veut déployé.
-- **machine virtuelle de développement :** ces machines mises à disposition des
+  être déployée afin de disposer de stockage permanent.
+- **Serveurs de jeu :** le serveur de jeu étant décomposé en trois parties,
+  trois recettes différentes sont nécessaires, en fonction du type de serveur
+  que l'on veut déployer.
+- **Machine virtuelle de développement :** ces machines mises à disposition des
   développeurs doivent leur permettre de tester le jeu avec un serveur qui leur
-  est fournis grâce à ces machines virtuelles. Elles contiennent tous les
-  composants nécessaires au bon fonctionnement du serveur.
-- **serveur de machines virtuelles :** il s'agit de configurer un serveur
-  fraîchement arrivé pour lui permettre d'exécuter des conteneurs (serveur de
-  jeu, site web, etc.).
-- **site web commercial :** cette recette crée un conteneur permettant
-  d'afficher le site web du jeu via un serveur web correctement configuré.
-- **serveur de supervision :** cette recette crée un conteneur pouvant exécuter
-  un serveur icinga (clone de nagios). Le conteneur est préconfiguré pour
+  est fournis. Elles contiennent tous les composants nécessaires au bon
+  fonctionnement du serveur de jeu.
+- **Serveur de machines virtuelles/conteneurs :** il s'agit de configurer un
+  serveur fraîchement arrivé pour lui permettre d'exécuter des conteneurs
+  (serveur de jeu, site web, etc.).  Pour cela, une étape supplémentaire est
+  nécessaire afin de qualifier une première fois les rôles à déployer sur le
+  serveur. Par exemple, on peut distinguer les rôles suivants :
+    * **proxy frontal :** cette recette crée un conteneur redirigeant le trafic
+      vers d'autres machines virtuelles exécutant un service web. En effectuant
+      aussi peu d'action que possible, il permet d'afficher une page d'erreur
+      lorsque les autres services sont rendus inaccessibles;
+    * **site web commercial :** cette recette crée un conteneur permettant
+      d'afficher le site web du jeu via un serveur web correctement configuré;
+    * **forum :** cette recette crée un conteneur exécutant le logiciel de forum;
+    * **serveur de mails** à usage interne aux serveurs.
+- **Serveur de supervision :** cette recette crée un conteneur exécutant un
+  serveur icinga (clone de nagios). Le conteneur est préconfiguré pour
   superviser les serveurs connus au moment de sa construction.
 
 \vspace{1em}
 
 Pour chaque recette, un certain nombre d'actions communes sont effectuées comme
-la mise à jour des paquets et la sécurisation générale (comme la restriction de
-l'authentification par SSH, des règles de pare-feu sommaires et diverses règles
-permettant de prévenir diverses attaques comme le DNS et l'ARP-poisoning).
+la mise à jour des paquets et la sécurisation générale (restriction de
+l'authentification par SSH, ajout de règles de pare-feu sommaires et diverses
+règles permettant de prévenir diverses attaques comme le DNS et
+l'ARP-poisoning suivant les machines).
 
 \vspace{1em}
 
-Certaines machines disposeront de deux interfaces réseau : une publique et une
+Certaines machines disposeront de deux cartes réseau : une publique et une
 privée. Un plugin pour Ansible a donc été développé afin de gérer la présence
-de ces deux cartes, permettant d'adapter automatiquement les configurations des
+de ces deux interfaces, permettant d'adapter automatiquement les configurations des
 logiciels en fonction de leur besoin (usage interne ou externe au cluster).
 
 \vspace{1em}
 
 De nombreux modules Ansible existent afin de configurer des bases de
 données. Malheureusement, InfluxDB étant encore relativement récente, aucun
-module n'était disponible. Pour nos besoins, nous avons donc du développer un
+module n'était disponible. Pour nos besoins, nous avons donc dû développer un
 module en Go (pour profiter d'un code compilé de manière statique avec ses
 bibliothèques, nous évitant ainsi d'avoir des prérequis sur les machines). Une
-demande de fusion de branche a été passé auprès de l'équipe d'Ansible afin de
-permettre l'exécution de programme natifs (précédemment limité aux scripts).
+demande de fusion de branche a été passée auprès de l'équipe d'Ansible afin de
+permettre l'exécution de programmes natifs (précédemment limité aux scripts).
 
 \vspace{1em}
 
@@ -388,15 +401,26 @@ compilation `sbt-native-packager`, cela générait les scripts
 d'initialisation. Lors de la mise en place des recettes de déploiement pour
 cette version du serveur, nous avons observé un bug dans le script
 d'initialisation à destination des systèmes Debian. Nous avons donc corrigé le
-problème et soumis le correctif au mainteneur du la solution.
+problème et soumis le correctif au mainteneur de la solution.
 
 \vspace{1em}
 
 Un peu plus tard, afin d'enregistrer les actions effectuées par le programme de
 déploiement, il a été nécessaire de développer un nouveau module pour Ansible
-afin qu'il enregistrer les actions qu'il fait et les éventuelles erreurs qu'il
-rencontre. Cela permet d'avoir une traçabilité des déploiements et des mises à
-jour effectuées sur l'ensemble du cluster.
+afin qu'il enregistre les actions qu'il effectue ainsi que les éventuelles
+erreurs qu'il rencontre. Cela permet d'avoir une traçabilité des déploiements
+et des mises à jour de l'ensemble du cluster.
+
+\vspace{1em}
+
+À noter que pour le moment, aucune solution n'a été trouvée pour éviter ou
+simplifier l'étape de compilation de noyau sur les serveurs exécutant les
+conteneurs. En effet, les serveurs nous sont livrés avec un noyau standard ne
+disposant pas de toutes les options nécessaires au fonctionnement de LXC.
+
+Une première étape manuelle consiste alors à compiler un noyau renforcé (par
+l'application du correctif GrSecurity) avec des options plus appropriées à
+notre usage.
 
 
 \newpage
@@ -475,7 +499,7 @@ Actuellement au stade d'étude, il serait question de mettre à disposition des
 développeurs une interface web leur permettant de lancer à volonté des machines
 virtuelles et de leur permettre de contrôler certains aspects préenregistrés
 (vider la base de données, charger une carte prédéfinie, ...) et de consulter
-les journaux du serveurs.
+les journaux des différents programmes.
 
 
 \newpage
@@ -500,14 +524,17 @@ machines virtuelles exécutant chacune plusieurs clients.
 
 Dans un premier temps, la montée en charge montrait que le serveur ne permettait
 pas de dépasser 250 joueurs. Au delà, l'analyse qui s'en est suivie a montré
-que le scheduler de la bibliothèque d'acteurs que nous utilisions ne faisais
-pas correctement son travail : il en résultait une surcharge des canaux de
-diffusion, entraînant le plantage du serveur.
+que l'ordonnanceur de la bibliothèque d'acteurs que nous utilisions ne faisait
+pas correctement son travail : il en résultait alors une surcharge anormale des
+canaux de diffusion internes, entraînant le sabordage du serveur de jeu
+(s'agissant d'une situation irrécupérable).
+
+\vspace{1em}
 
 Ce problème a été corrigé dans la version suivante de la bibliothèque
 d'acteurs. La nouvelle montée en charge a permis d'atteindre cette fois plus de
-800 joueurs simultanément, à ce moment, c'était bien le CPU qui était limitant
-et il n'en résultat pas de plantage du serveur.
+800 joueurs simultanément ; à ce moment, c'était bien le CPU qui était limitant
+et il n'en résultait pas de plantage du serveur.
 
 
 \newpage
@@ -518,8 +545,9 @@ et il n'en résultat pas de plantage du serveur.
 
 Les métriques relevées précédemment concernaient le système : consommation CPU,
 utilisation de la mémoire et de la bande passante, ... Pour des besoins
-statistiques (et à terme business), il est nécessaire d'intégrer au serveur
-l'envoi de métrique telles que le nombre de joueurs inscrits, connectés, ...
+statistiques (et à terme business), il est nécessaire d'intégrer au serveur de
+jeu l'envoi de métriques telles que le nombre de joueurs inscrits, connectés,
+...
 
 ### Difficultés
 
@@ -538,6 +566,8 @@ système de configuration de l'application. En effet, jusque là, les quelques
 paramètres nécessaires au fonctionnement du serveur étaient regroupés dans des
 macros de préprocesseur.
 
+\vspace{1em}
+
 Une fois ce travail préliminaire réalisé, il a été aisé de rajouter dans le
 code du serveur une série de macros envoyant à chaque événement intéressant, un
 message vers la base de données.
@@ -566,7 +596,7 @@ Le serveur web `nginx` est utilisé, allié au service `php-fpm`. Tous deux ont
 été configurés afin de permettre à un millier d'utilisateurs de visionner le
 site en même temps.
 
-\vspace{1em}
+%%fimage(img/siteweb.png, 0.95, "Page d'accueil du site web")
 
 Prévoyant un afflux massif de joueurs dans les prochains mois, nous nous sommes
 intéressés aux services d'Amazon afin de bénéficier d'une structure de mise à
@@ -577,8 +607,6 @@ spécifique afin de répondre à la demande fluctuante, selon des critères
 préétablis. Après ce test, compte-tenu du coût de la solution, il a été décidé
 d'attendre d'en avoir vraiment l'utilité.
 
-%%fimage(img/siteweb.png, 0.95, "Page d'accueil du site web")
-
 
 \newpage
 
@@ -588,7 +616,8 @@ d'attendre d'en avoir vraiment l'utilité.
 
 La sortie du jeu n'étant pas encore à l'ordre du jour et certains aspects du
 développement du serveur n'étant pas encore complètement réglés, cette étape
-est là pour établir une base de travail.
+est là pour établir une base de travail concernant l'architecture et le
+déploiement des serveurs de jeu, de monitoring ainsi que leur interactions.
 
 ### Pistes envisagées
 
@@ -604,12 +633,12 @@ très rapidement en cas de problème.
 
 Précédemment, il était plutôt question d'effectuer un déploiement plus
 classique : une recette Ansible aurait éteint un petit groupe de serveurs, puis
-aurait procédé à la migration avant de relancer le nouveau serveur.
+aurait procédé à la migration avant de relancer les serveurs mis à jour.
 
 Les serveurs sont mis à jour progressivement ; en cas de problème durant la
-procédure de mise à jour, il faut alors retirer du cluster les serveurs
-défectueux. Cette opération est plus lourde que le basculement d'une version à
-l'autre tel que le permet Docker.
+procédure, il faut alors retirer du cluster les serveurs défectueux. Cette
+opération est plus lourde que le basculement d'une version à l'autre tel que le
+permet Docker.
 
 \vspace{1em}