|
|
|
|
@ -21,8 +21,6 @@ nos besoins n'était pas envisageable : cela aurait réclamé une équipe dédi
|
|
|
|
|
développement de cette solution alternative. Comme ce n'est pas le cœur de
|
|
|
|
|
métier du studio, cette solution a d'emblée été écartée.
|
|
|
|
|
|
|
|
|
|
### Cadre imposé
|
|
|
|
|
|
|
|
|
|
### Propositions retenues
|
|
|
|
|
|
|
|
|
|
Les fournisseurs de service d'hébergement en nuage retenus sont :
|
|
|
|
|
@ -38,6 +36,8 @@ Les fournisseurs de service d'hébergement en nuage retenus sont :
|
|
|
|
|
* Rackspace ;
|
|
|
|
|
* Windows Azure.
|
|
|
|
|
|
|
|
|
|
\vspace{0.5em}
|
|
|
|
|
|
|
|
|
|
Les solutions libres retenues sont :
|
|
|
|
|
|
|
|
|
|
* Ecalyptus ;
|
|
|
|
|
@ -51,6 +51,14 @@ 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.
|
|
|
|
|
|
|
|
|
|
### Discussions complémentaires
|
|
|
|
|
|
|
|
|
|
Organisé par l'incubateur à destination des start-up intéressées, une
|
|
|
|
|
journée nous a permis de discuter avec des architectes d'Amazon afin
|
|
|
|
|
de connaître leur avis sur la structure que nous envisagions et
|
|
|
|
|
comment cela pourrait s'intégrer au sein de l'offre d'Amazon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\newpage
|
|
|
|
|
|
|
|
|
|
## Analyse des outils de déploiement automatique
|
|
|
|
|
@ -72,7 +80,7 @@ Il est nécessaire de configurer de nombreuses machines dans différents cadres
|
|
|
|
|
### Alternatives possibles
|
|
|
|
|
|
|
|
|
|
Dans de nombreux environnements chaque machine est configurée à la main par un
|
|
|
|
|
administrateur système, a chaque étape, une erreur humaine peut venir
|
|
|
|
|
administrateur système, à chaque étape, une erreur humaine peut venir
|
|
|
|
|
interférer dans la procédure de mise à jour.
|
|
|
|
|
|
|
|
|
|
Cette solution est évidemment à écarter si l'on veut garder le contrôle de son
|
|
|
|
|
@ -111,11 +119,15 @@ La virtualisation peut nous être utile à plusieurs niveaux :
|
|
|
|
|
* l'utilisation d'un environnement standardisé pour les développeurs ;
|
|
|
|
|
* le déploiement d'environnements standardisés et minimalistes.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
Si dans une 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
|
|
|
|
|
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 (version
|
|
|
|
|
@ -123,6 +135,8 @@ précises de certaine bibliothèques, paquet particulier). La virtualisation
|
|
|
|
|
permet de leur fournir un environnement clef en main qu'ils n'ont pas à
|
|
|
|
|
maintenir.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
@ -148,6 +162,8 @@ guère d'avantages face aux conteneurs : ils permettent de garantir un niveau de
|
|
|
|
|
sécurité et d'isolation quasi-identique, sans avoir la lourdeur de gestion
|
|
|
|
|
d'autant de noyau que l'on veut lancer de machines.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
Docker et LXC ont donc été retenus. La première version stable de Docker est
|
|
|
|
|
sortie pendant mon stage, ce qui a été déterminant pour le choix de cette
|
|
|
|
|
solution. LXC reste dans la course pour tout ce qui nécessite une configuration
|
|
|
|
|
@ -182,11 +198,10 @@ Les principales solutions existantes sont les suivantes :
|
|
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\newpage
|
|
|
|
|
@ -211,6 +226,8 @@ 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é.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
@ -221,7 +238,7 @@ compatibles avec des solutions d'authentification standards.
|
|
|
|
|
Les solutions de centralisation d'authentification courantes sont :
|
|
|
|
|
|
|
|
|
|
* LDAP ;
|
|
|
|
|
* Kerberos ;
|
|
|
|
|
* Kerberos/PKINIT ;
|
|
|
|
|
* RADIUS.
|
|
|
|
|
|
|
|
|
|
### Résultats obtenus
|
|
|
|
|
@ -232,6 +249,8 @@ Directory dans les environnements Windows, LDAP directement dans les
|
|
|
|
|
environnements Unix traditionnels ou en plugin dans de nombreuses applications
|
|
|
|
|
demandant une authentification).
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
@ -247,14 +266,14 @@ authentifications.
|
|
|
|
|
### Objectifs
|
|
|
|
|
|
|
|
|
|
Afin de pouvoir déterminer le moment optimal pour démarrer un nouveau serveur,
|
|
|
|
|
il faut relever un certain nombre de métrique et déterminer dans une première
|
|
|
|
|
phase l'indicateur le plus adapté.
|
|
|
|
|
il faut relever un certain nombre de métriques puis déterminer dans une
|
|
|
|
|
première phase l'indicateur le plus adapté.
|
|
|
|
|
|
|
|
|
|
### Cadre imposé
|
|
|
|
|
|
|
|
|
|
Avant mon arrivée dans l'entreprise, mon maître de stage a fait le choix de la
|
|
|
|
|
base de données InfluxDB pour le stockage des métriques (aussi bien système que
|
|
|
|
|
business).
|
|
|
|
|
Avant mon arrivée dans l'entreprise, mon maître de stage avait fait le choix de
|
|
|
|
|
la base de données InfluxDB pour le stockage des métriques (aussi bien système
|
|
|
|
|
que business).
|
|
|
|
|
|
|
|
|
|
### Propositions retenues
|
|
|
|
|
|
|
|
|
|
@ -263,6 +282,8 @@ encore aucun programme pour faire simplement un relevé de métriques système
|
|
|
|
|
(consommation CPU, mémoire vive disponible, bande passante, ...). Il a donc été
|
|
|
|
|
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.
|
|
|
|
|
@ -277,18 +298,20 @@ 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.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
%%fimage(img/cubism.png, 0.77, "Tableau de bord réalisé avec Cubism")
|
|
|
|
|
%%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")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ -301,7 +324,7 @@ le jeu.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
@ -344,7 +367,7 @@ permettant de prévenir diverses attaques comme le DNS et l'ARP-poisoning).
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
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 automatique les configurations des
|
|
|
|
|
logiciels en fonction de leur besoin (usage interne ou externe au cluster).
|
|
|
|
|
|
|
|
|
|
@ -420,11 +443,16 @@ souffert d'un manque de consultation des besoins des développeurs : travailler
|
|
|
|
|
dans une machine virtuelle en ligne de commande n'est en général pas à la
|
|
|
|
|
portée des développeurs plus habitués à Visual Studio.
|
|
|
|
|
|
|
|
|
|
%FIXME parler de l'interface console
|
|
|
|
|
Comme première contre-mesure, une interface a été développée afin de masquer
|
|
|
|
|
et centraliser les principales actions.
|
|
|
|
|
|
|
|
|
|
%%fimage(img/ncurses-dev.png, 0.67, "Interface Curses de contrôle du serveur")
|
|
|
|
|
|
|
|
|
|
Dans un soucis d'harmonisation des technologies, Docker a été retenu dans un
|
|
|
|
|
second temps pour répondre également aux problématiques de déploiement futurs.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
Après une semaine de test sur les machines des développeurs, de nombreux
|
|
|
|
|
problèmes m'ont été remontés. Ces problèmes étant liés d'une part à la
|
|
|
|
|
difficulté de configuration automatique des machines sous Windows et d'autre
|
|
|
|
|
@ -441,9 +469,11 @@ 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.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
@ -455,12 +485,12 @@ les journaux du serveurs.
|
|
|
|
|
### Objectifs
|
|
|
|
|
|
|
|
|
|
Une fois les premières versions du serveur livrées, nous nous sommes rapidement
|
|
|
|
|
intéressé à ses capacités : en particulier le nombre maximum de joueurs pouvant
|
|
|
|
|
être accueillit.
|
|
|
|
|
intéressés à ses capacités : en particulier le nombre maximum de joueurs
|
|
|
|
|
pouvant être accueilli.
|
|
|
|
|
|
|
|
|
|
### Propositions retenues
|
|
|
|
|
|
|
|
|
|
En tant que start-up, nous avons eu un certain nombre de crédit sur Amazon Web
|
|
|
|
|
En tant que start-up, nous avons eu un certain nombre de crédits sur Amazon Web
|
|
|
|
|
Service afin de tester et démarrer notre activité sur leur plate-forme.
|
|
|
|
|
|
|
|
|
|
Nous avons donc utilisé un certain nombre de nos crédits afin de lancer 20
|
|
|
|
|
@ -486,7 +516,7 @@ et il n'en résultat pas de plantage du serveur.
|
|
|
|
|
|
|
|
|
|
### Objectifs
|
|
|
|
|
|
|
|
|
|
Les métriques relevées précédemment concernait le système : consommation CPU,
|
|
|
|
|
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, ...
|
|
|
|
|
@ -499,7 +529,7 @@ 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ée. La bibliothèque est désormais disponible
|
|
|
|
|
sur GitHub : https://github.com/influxdb/influxdb-c
|
|
|
|
|
sur GitHub : \url{https://github.com/influxdb/influxdb-c}.
|
|
|
|
|
|
|
|
|
|
### Résultats obtenus
|
|
|
|
|
|
|
|
|
|
@ -530,12 +560,16 @@ 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).
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
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 à
|
|
|
|
|
intéressés 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
|
|
|
|
|
@ -545,18 +579,41 @@ d'attendre d'en avoir vraiment l'utilité.
|
|
|
|
|
|
|
|
|
|
%%fimage(img/siteweb.png, 0.95, "Page d'accueil du site web")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\newpage
|
|
|
|
|
|
|
|
|
|
## Conception de l'architecture des serveurs
|
|
|
|
|
## Réflexion sur l'architecture et le déploiement des serveurs
|
|
|
|
|
|
|
|
|
|
### Objectifs
|
|
|
|
|
|
|
|
|
|
### Alternatives possibles
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
### Cadre imposé
|
|
|
|
|
### Pistes envisagées
|
|
|
|
|
|
|
|
|
|
### Propositions retenues
|
|
|
|
|
À l'heure actuelle, la principale piste envisagée consiste à générer l'image
|
|
|
|
|
d'un conteneur préalablement, de l'envoyer sur un dépôt d'images (contenant
|
|
|
|
|
toutes les dernières versions des conteneurs). Ensuite, progressivement, on
|
|
|
|
|
coupe les serveurs de jeu, puis on lance la nouvelle image. En cas de problème
|
|
|
|
|
lors du déploiement, l'ancienne image persiste sur les serveurs jusqu'à ce que
|
|
|
|
|
l'on lance un nettoyage. Cela permet de relancer la version stable précédent
|
|
|
|
|
très rapidement en cas de problème.
|
|
|
|
|
|
|
|
|
|
### Difficultés
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
### Résultats obtenus
|
|
|
|
|
Précédemment, il était plutôt question d'effectuer un déploiement plus
|
|
|
|
|
classique : une recette Ansible aurait éteint un petit groupe de serveur, puis
|
|
|
|
|
aurait procédé à la migration avant de relancer le nouveau serveur.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
\vspace{1em}
|
|
|
|
|
|
|
|
|
|
L'avantage des images est que l'intégralité du système est inclus dans le
|
|
|
|
|
conteneur. Il n'y a donc aucune variation d'environnement au moment du
|
|
|
|
|
déploiement : il est ainsi plus facile d'avoir un environnement de test proche
|
|
|
|
|
de l'environnement de production.
|
|
|
|
|
|
