Dès les premières étapes de préparation de l’application, les exigences étaient claires : concevoir un projet à la fois évolutif et pérenne. C’est dans cet esprit que j’ai imaginé l’architecture de l’infrastructure. Alors que pour mes projets précédents, aux ambitions plus modestes, j’avais opté pour une solution autonome hébergée sur mon VPS, j’ai cette fois choisi une approche distribuée.
Avant tout, il est essentiel de passer en revue les différents composants logiciels. Côté client, on trouve des applications mobiles (Android/iOS) ainsi qu’une interface web destinée à l’administration et aux utilisateurs. Côté serveur, l’application se compose d’une API et d’un service WebSocket.
Ces deux services sont déployés dans des conteneurs Docker distincts. En effet, le redémarrage du WebSocket ne doit pas rendre l’ensemble de l’application indisponible et, au départ, faire converger tous les clients vers le même serveur simplifiait les échanges de données. Ce problème ne se pose pas pour l’API, qui est par nature stateless.
Ces conteneurs tournent sur une instance Kubernetes fournie par OVH, répartie sur deux nœuds qui hébergent l’ensemble de mes projets actifs (y compris ce blog). Cependant, à ce stade, plusieurs éléments essentiels manquent encore à cette application de quiz : où stocker les images, les icônes et les mots de passe ?
Concernant les images, j’ai préféré les héberger sur un espace de stockage S3 chez Digital Ocean, garantissant ainsi la persistance des données sans surcharger mon VPS. Le VPS stocke par ailleurs les bases de données MySQL (pour les environnements TEST, DEV et PROD). J’ai choisi de ne pas externaliser cette partie, car les coûts augmentent rapidement lorsqu’on recherche une gestion plus souple, notamment quant au nombre de connexions actives. En effet, comme je parallélise la récupération des questions lors de la construction du schéma de quiz, le nombre de sessions peut vite dépasser la centaine. Pour assurer la pérennité des données, une sauvegarde de la version de production est réalisée chaque nuit et stockée à la fois sur mon VPS et sur le stockage S3, garantissant une redondance efficace.
Un point crucial concerne l’accès aux clusters Kubernetes via une URL telle que api.vstrivia.app. Pour cela, j’utilise mon VPS comme proxy avec NGINX, qui redirige toutes les connexions. En complément, pour me prémunir d’éventuelles attaques DDoS, j’emploie Cloudflare (version gratuite) afin de masquer l’adresse IP de mon VPS.
Côté DevOps, le code s’articule autour de deux branches principales. À chaque merge, la branche « dev » déclenche les tests de conformité et la construction des conteneurs, qui sont ensuite déployés sur l’environnement DEV de mon cluster Kubernetes afin de tester l’application en conditions réelles. Si tous les tests passent, la branche « dev » peut être fusionnée avec la branche « prod », déclenchant alors le processus de déploiement en production. Les conteneurs générés sont ensuite stockés dans un Container Registry chez Digital Ocean.
