Faire tourner un jeu sur Kubernetes : retour d'expérience

Bonjour !

Aujourd'hui, un article technique : on va vous expliquer comment WorldWar, un jeu de 21 ans, tourne sur Kubernetes avec un pipeline CI/CD complet et des environnements de preview automatiques sur chaque pull request. Si vous n'êtes pas développeur, cet article sera sans doute un peu aride. Si vous l'êtes, on espère que le retour d'expérience vous parlera.

Pourquoi Kubernetes pour un jeu ?

La question revient souvent : Kubernetes, c'est pas overkill ? Sur le papier, peut-être. En pratique, non, si on sait ce qu'on fait.

Ce qu'on voulait :
- Des déploiements sans interruption (zero-downtime) ;
- Un pipeline CI/CD propre : push, tests, build, deploy, sans intervention manuelle ;
- Des environnements de preview par pull request pour tester avant de merger ;
- Une gestion propre des secrets et des certificats TLS ;
- Des tâches planifiées fiables, sans bricoler des crontabs sur un serveur.

Kubernetes coche toutes ces cases. Et une fois le Helm chart en place, ajouter un environnement ou modifier une config prend quelques lignes.

21 ans de PHP, et on assume

WorldWar a démarré en PHP 4 en 2005. Aujourd'hui, on tourne sur PHP 8.5. Quand on a 21 ans de code métier qui fait tourner un jeu en production, on ne réécrit pas tout en Go ou en Rust sur un coup de tête. On modernise.

Le backend, c'est une API JSON sur un framework PHP maison, avec des services bien découpés, un autoloader PSR-4 et Composer pour les dépendances. Rien de révolutionnaire, mais ça tourne, c'est testé, et on maîtrise chaque ligne. PHP a beaucoup évolué en 21 ans. Le langage qu'on utilise aujourd'hui n'a plus grand-chose à voir avec celui de 2005.

Le frontend, lui, a été entièrement réécrit : React 19, TypeScript, buildé avec Bun et servi par Nginx. Les deux communiquent via une API REST classique.

L'architecture en production

En production, un pod Kubernetes contient deux containers :
- API : PHP-FPM qui expose l'API JSON du jeu
- Web : Nginx qui sert le frontend et reverse-proxy les appels API vers PHP-FPM

Nginx gère tout le routing : les appels API, les fichiers statiques avec du cache agressif, et un fallback SPA pour le frontend React. Les anciennes URLs de l'époque PHP full-stack sont redirigées en 301 vers les nouvelles routes.

À côté du pod principal, plusieurs CronJobs Kubernetes gèrent les tâches récurrentes du jeu : traitement des événements en cours (attaques, constructions), mise à jour des classements, nettoyage des données obsolètes, etc. Chaque CronJob lance un container éphémère qui vérifie que la base de données est joignable avant de démarrer.

Le pipeline CI/CD

Tout passe par GitHub Actions. Un push sur la branche de production ou de staging déclenche le workflow :

1. Tests : PHPUnit tourne dans un container Docker identique à la prod. Si les tests échouent, rien ne se déploie.

2. Build des images Docker : deux images sont construites en parallèle. L'image API, basée sur notre framework PHP avec un autoloader optimisé. Et l'image Web, un build multi-stage où Bun construit le frontend puis les assets sont copiés dans une image Nginx Alpine légère.

3. Déploiement Helm : les nouvelles images sont déployées automatiquement dans le bon environnement selon la branche. Les secrets sont injectés au moment du déploiement.

Du push au déploiement, tout est automatique.

Les environnements de preview

C'est probablement la feature d'infrastructure dont on est le plus fiers. Chaque pull request déploie automatiquement un environnement de preview complet.

Quand une PR est ouverte :
- Un namespace Kubernetes dédié est créé ;
- Les images sont buildées et déployées via Helm ;
- L'environnement est accessible sur un sous-domaine unique avec TLS automatique ;
- Un commentaire est posté sur la PR avec le lien.

Quand la PR est fermée ou mergée, tout est nettoyé automatiquement. Aucun résidu.

Pour un projet solo ou une petite équipe, c'est un énorme gain de qualité. On teste chaque changement dans un environnement identique à la prod avant de merger.

En résumé

Kubernetes pour un jeu, c'est viable. Le setup initial demande du travail, mais une fois en place, on ne touche quasi plus à l'infra. Les déploiements sont automatiques, les previews par PR sont un game-changer pour la qualité, et les CronJobs remplacent avantageusement les crontabs bricolées sur un VPS.

Le vrai luxe, c'est de pouvoir se concentrer sur le jeu plutôt que sur les serveurs.

Si le sujet vous intéresse, on a aussi écrit sur notre migration de jQuery vers React. Et si vous n'avez pas encore testé WorldWar, c'est le moment : créez votre compte et venez voir par vous-même !

À bientôt,
L'Équipe WorldWar