Add some technical history
This commit is contained in:
parent
bba1d4107b
commit
31473a65f1
|
|
@ -40,9 +40,9 @@ Deux fois par semaines, toute l'équipe fait le point sur l'avancée de
|
|||
chacun. C'est l'occasion de recentrer les priorités.
|
||||
|
||||
Tous les jours, nous sommes tenu d'envoyer un petit compte-rendu de nos
|
||||
activités du jour, en n'oubliant pas d'indiquer les difficultés que l'on 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é.
|
||||
activités de la journée, en n'oubliant pas d'indiquer les difficultés que l'on
|
||||
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é.
|
||||
|
||||
Le soir est toujours une bonne occasion de discuter avec mon maître de stage :
|
||||
que ce soit pour se tenir mutuellement informé de nos activités ou pour faire
|
||||
|
|
|
|||
|
|
@ -45,7 +45,11 @@ Les solutions libres retenues sont :
|
|||
|
||||
### Résultats obtenus
|
||||
|
||||
%FIXME
|
||||
La solution d'Amazon a été retenue pour sa grande diversité et le
|
||||
support dont nous bénéficions en tant que start-up en développement.
|
||||
|
||||
Vous trouverez en annexe le tableau de résultat comparatif effectué
|
||||
dans le cadre de cette analyse.
|
||||
|
||||
|
||||
## Analyse des outils de déploiement automatique
|
||||
|
|
@ -73,8 +77,6 @@ interférer dans la procédure 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.
|
||||
|
||||
### Cadre imposé
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
Les outils de déploiment automatique retenus sont :
|
||||
|
|
@ -88,7 +90,12 @@ Les outils de déploiment automatique retenus sont :
|
|||
|
||||
### Résultats obtenus
|
||||
|
||||
%FIXME
|
||||
Ansible a été la solution retenue : assez récente, elle n'impose pas
|
||||
l'installation préalable d'un programme sur chaque machine et est en
|
||||
constant développement depuis son lancement.
|
||||
|
||||
Vous trouverez en annexe le tableau comparatif effectué dans le cadre
|
||||
de cette analyse.
|
||||
|
||||
|
||||
## Analyse des solutions de virtualisation
|
||||
|
|
@ -148,31 +155,83 @@ avancée que ne permettrait pas de faire Docker.
|
|||
|
||||
### Objectifs
|
||||
|
||||
Le chat est un élément essentiel dans un jeu 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
|
||||
|
||||
### Cadre imposé
|
||||
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.
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
### Difficultés
|
||||
Les principales solutions existantes sont les suivantes :
|
||||
|
||||
* IRC ;
|
||||
* XMPP.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
Jabber (protocole XMPP) a été retenu comme solution de chat. En effet,
|
||||
le serveur `ejabberd`, écrit en Erlang, permet aisément de déployer un
|
||||
cluster et ainsi répartir la charge d'une manière relativement
|
||||
transparente, comparé aux autres implémentations et des autres
|
||||
protocoles.
|
||||
|
||||
|
||||
## Recherche d'une solution de gestion de l'authentification
|
||||
|
||||
### Objectifs
|
||||
|
||||
L'authentification est un point crucial à ne pas négliger lorsque l'on
|
||||
développe un jeu massivement multijoueur. En effet, c'est elle qui
|
||||
permettra de contrôler l'accès aux différents services du jeu :
|
||||
|
||||
* site web ;
|
||||
* forum ;
|
||||
* jeu ;
|
||||
* système de chat dans le jeu ;
|
||||
* ...
|
||||
|
||||
### Alternatives possibles
|
||||
|
||||
### Cadre imposé
|
||||
L'implémentation d'une solution maison est encore une fois
|
||||
envisageable. Elle n'a pas été retenue pour éviter d'avoir à gérer les
|
||||
vulnérabilités qui pourraient être découverte 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 compatible avec une solution maison les logiciels
|
||||
compatibles avec des solutions d'authentification standards.
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
### Difficultés
|
||||
Les solutions de centralisation d'authentification courantes sont :
|
||||
|
||||
* LDAP ;
|
||||
* Kerberos ;
|
||||
* RADIUS.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
LDAP est une solution utilisée universellement dans le cadre de
|
||||
l'authentification et du stockage d'informations sur les utilisateurs (Active
|
||||
Directory dans les environnements Windows, LDAP directement dans les
|
||||
environnements Unix traditionnels ou en plugin dans de nombreuses applications
|
||||
demandant une authentification).
|
||||
|
||||
Afin de gérer plus simplement l'authentification entre les différents services
|
||||
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.
|
||||
|
||||
|
||||
## Conception d'un programme de relevé de métriques système
|
||||
|
||||
|
|
@ -204,7 +263,93 @@ devrons faire les relevés.
|
|||
Le projet a été terminé et mis en ligne publiquement sur GitHub sous licence
|
||||
CC0.
|
||||
|
||||
Il a ensuite été annoncé à la communauté InfluxDB qui lui a fait un bon accueil.
|
||||
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
|
||||
pour y faire des améliorations.
|
||||
|
||||
En sus de ce programme de relevé de métrique, il m'a été demandé de réaliser un
|
||||
tableau de board 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 FIXME) : 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.
|
||||
|
||||
|
||||
## Conception de recettes de déploiement automatique de serveurs
|
||||
|
||||
### Objectifs
|
||||
|
||||
Chaque serveur, que ce soit un serveur physique ou virtuel, doit pouvoir être
|
||||
reconfiguré rapidement en fonction des rôles qui lui sont attribués.
|
||||
|
||||
Certain 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.
|
||||
|
||||
### 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
|
||||
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
|
||||
l'état 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
|
||||
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ée 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
|
||||
développeurs doivent leur permettre de tester le jeu avec un serveur qui leur
|
||||
est fournis grâce à cette machine virtuelle. Elle contient tous les
|
||||
composants nécessaire 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
|
||||
superviser les serveurs connus au moment de sa construction.
|
||||
|
||||
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).
|
||||
|
||||
Certaines machines disposeront de deux interfaces réseau : une publique et une
|
||||
interne. Un plugin pour Ansible a donc été développé afin de gérer la présence
|
||||
de ces deux cartes, permettant d'adapter automatique les configurations des
|
||||
logiciels en fonction de leur besoin (usage interne ou externe au cluster).
|
||||
|
||||
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 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).
|
||||
|
||||
Les premières versions du serveur de jeu utilisaient le programme de
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
## Mise en place d'un processus de livraison du serveur à destination des développeurs du client
|
||||
|
|
@ -270,6 +415,12 @@ ceux-ci par les développeurs (filtrage de ports par un anti-virus nouvellement
|
|||
installé, version différentes de Windows, ...), la solution utilisant des
|
||||
conteneurs contrôlés par l'équipe serveur sur une machine dédiée a été retenue.
|
||||
|
||||
Actuellement au stade d'étude, il serait question de mettre à disposition des
|
||||
développeur une interface web leur permettant de lancer à volonté des machines
|
||||
virtuelles et de leur permettre de contrôler certain aspects préenregistrés
|
||||
(vider la base de données, charger une carte prédéfinie, ...) et de consulter
|
||||
les journaux du serveurs.
|
||||
|
||||
|
||||
## Conception de l'architecture de test de monté en charge
|
||||
|
||||
|
|
@ -297,25 +448,10 @@ diffusion, entraînant le plantage du serveur.
|
|||
|
||||
Ce problème a été corrigé dans la version suivante de la bibliothèque
|
||||
d'acteurs. La nouvelle monté en charge a permis d'atteindre cette fois plus de
|
||||
700 joueurs simultanément, à ce moment, c'était bien le CPU qui était limitant
|
||||
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.
|
||||
|
||||
|
||||
## Conception de l'architecture des serveurs
|
||||
|
||||
### Objectifs
|
||||
|
||||
### Alternatives possibles
|
||||
|
||||
### Cadre imposé
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
### Difficultés
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
|
||||
## Intégration de métriques dans le serveur
|
||||
|
||||
### Objectifs
|
||||
|
|
@ -332,9 +468,60 @@ ou C++ pour s'interfacer avec la base de données. Malheureusement, comme elle
|
|||
est récente, cette bibliothèque n'avait pas encore été développée.
|
||||
|
||||
J'ai donc pris le soin de la développer puis de la proposer aux développeurs de
|
||||
la base de données qui l'ont intégré, La bibliothèque est désormais disponible
|
||||
la base de données qui l'ont intégrée. La bibliothèque est désormais disponible
|
||||
sur GitHub : https://github.com/influxdb/influxdb-c
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
Le travail d'intégration de métriques a d'abord conduit à la réalisation
|
||||
Le travail d'intégration de métriques a d'abord conduit à la réalisation d'un
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
## Déploiement du site web commercial du jeu
|
||||
|
||||
### Objectifs
|
||||
|
||||
Précédemment hébergé auprès d'une société d'hébergement mutualisé permettant de
|
||||
modifier facilement de contenu du site ; nous avons été contraint de le refaire
|
||||
et de l'héberger nous-même afin de pouvoir l'adapter plus facilement à nos
|
||||
besoins.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
Le site web est déployé par un conteneur Docker, sur un serveur dédié aux
|
||||
services présenté à la communauté (aucun service d'usage interne ne s'y
|
||||
trouve).
|
||||
|
||||
Le serveur web `nginx` est utilisé, allié au service `php-fpm`. Tous deux ont
|
||||
été configurés afin de permettre à un millier d'utilisateur de visionner le
|
||||
site en même temps.
|
||||
|
||||
Prévoyant un afflux massif de joueurs dans les prochains mois, nous nous sommes
|
||||
intéressé aux services d'Amazon afin de bénéficier d'une structure de mise à
|
||||
l'échelle. Un test grandeur nature a donc été effectué en utilisant le service
|
||||
*Amazon Elastic Beanstalk*. Ce service configure seul un load-balancer et
|
||||
s'occupe de déployer automatiquement de nouvelles instances d'une machine
|
||||
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é.
|
||||
|
||||
|
||||
## Conception de l'architecture des serveurs
|
||||
|
||||
### Objectifs
|
||||
|
||||
### Alternatives possibles
|
||||
|
||||
### Cadre imposé
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
### Difficultés
|
||||
|
||||
### Résultats obtenus
|
||||
|
|
|
|||
Reference in New Issue