Conteneurs
Un conteneur est une instance isolée et en cours d'exécution d'une application packagée et de tout ce dont elle a besoin pour s'exécuter. Pour le multijoueur, il contient généralement un processus de serveur de jeu pour un match : démarré au début du match, détruit lorsqu'il se termine. L'isolation signifie qu'un plantage dans un serveur reste à l'intérieur de son conteneur, laissant les autres serveurs sur son hôte en cours d'exécution.
Aussi appelé
conteneurisation
,
Pourquoi chaque match a-t-il son propre conteneur ?
Parce qu'un match est l'unité naturelle de la vie d'un serveur de jeu. Le Matchmaking forme un match, un conteneur démarre à partir de l'image du serveur, les joueurs se connectent, le match se déroule et le conteneur est détruit. Le match suivant obtient un nouveau conteneur, démarré à partir de la même image.
Cela donne à chaque match le même point de départ : rien ne subsiste du match précédent, pas de fuite de mémoire, pas d'état obsolète, pas de sauvegarde à moitié terminée. Un bug qui n'apparaît qu'après six heures de fonctionnement d'un serveur a rarement sa chance dans un match de 20 minutes.
Cela change également ce que vous payez. Un serveur qui n'existe que pendant le déroulement d'un match n'est facturé que pendant ce temps, au lieu d'une machine maintenue active pour l'heure la plus chargée. Un processus de serveur à exécution longue qui enchaîne les matchs peut également fonctionner, mais il transporte l'état d'un match à l'autre et nécessite que sa capacité soit planifiée à l'avance.
Tous les jeux ne correspondent pas à ce modèle. Les mondes persistants et les serveurs multi-salles qui hébergent de nombreux matchs dans un seul processus fonctionnent beaucoup plus longtemps. La dernière section ci-dessous explique comment ils restent sains.
Qu'est-ce qu'un conteneur isole et qu'est-ce qu'il partage ?
Un conteneur sépare le processus, les fichiers et l'allocation de ressources d'un serveur des conteneurs qui l'entourent. Si un serveur plante ou présente une fuite de mémoire, le problème reste confiné à son conteneur et les parties adjacentes continuent de s'exécuter.
Les limites sont ce qui sécurise le partage d'un hôte. Chaque conteneur reçoit une allocation de processeur et de mémoire, et l'hôte l'applique strictement. C'est ce qui permet d'écarter le problème du voisin bruyant : une partie active à côté ne peut pas s'approprier le processeur ou la mémoire attribués à un autre serveur. Ainsi, le partage d'un hôte avec d'autres parties, ou avec les serveurs d'autres studios, ne modifie en rien le déroulement de votre partie. Le piège fonctionne dans l'autre sens : un serveur qui dépasse sa limite de mémoire est arrêté par l'hôte, en pleine partie. Mesurez la mémoire de pointe avec votre nombre cible de joueurs et définissez la limite au-dessus, dimensionnée pour le moment le plus intense d'une partie plutôt que pour la moyenne.
Les conteneurs partagent également le réseau de l'hôte, et c'est là que de nombreux premiers déploiements trébuchent. Un serveur de jeu écoute sur un port à l'intérieur de son conteneur, généralement UDP, et l'hôte l'associe à un port différent à l'extérieur. Les joueurs ont besoin du port externe. Un serveur qui signale son port interne, ou un client qui suppose un port fixe, ne peut pas se connecter. L'orchestrateur connaît le mappage et transmet l'adresse et le port externes à l'élément qui fournit aux joueurs leurs informations de connexion.
Pour savoir comment un conteneur se compare à une machine virtuelle, consultez Docker.
Où vont les données de match lorsque le conteneur est détruit ?
Nulle part, à moins que vous ne l'envoyiez quelque part d'abord. Le système de fichiers d'un conteneur disparaît avec lui, donc tout ce qui mérite d'être conservé doit partir avant la fin du match.
Résultats des matchs et progression des joueurs. Écrivez-les sur votre backend, comme une base de données ou un service de données de joueurs, au moment où le match se termine, et non sur un minuteur qu'un arrêt peut interrompre.
Journaux (Logs). Envoyez-les vers un espace de stockage externe. Sur Edgegap, les journaux de conteneur sont supprimés dès qu'un déploiement s'arrête, et la documentation conseille d'utiliser un compartiment S3 tiers pour les conserver, enregistré via Endpoint Storage (documentation). Configurez le compartiment avant votre premier véritable test de jeu, et non après le premier plantage que vous ne pouvez pas expliquer.
Rapports de plantage (Crash dumps) et replays. Même règle que pour les journaux, si vous souhaitez les récupérer plus tard.
Les mondes persistants font exception, car leur état doit survivre à n'importe quel conteneur individuel. Le monde est sauvegardé sur un espace de stockage externe au conteneur à intervalles réguliers, et un nouveau conteneur le charge à son démarrage. Cet intervalle détermine la quantité de progression qu'un plantage peut faire perdre.
Comment les studios maintiennent-ils les conteneurs de serveurs de jeux en bonne santé ?
Deux habitudes couvrent la majeure partie de cela.
Recyclez selon un calendrier. Même un serveur qui n'est jamais censé s'arrêter gagne à être remplacé, car les fuites de mémoire et les dérives s'accumulent à mesure qu'un processus s'exécute. L'Edge Cloud d'Edgegap limite le temps d'exécution d'un conteneur à 24 heures consécutives (tarification), ce qui permet d'instaurer cette habitude. Pour les serveurs persistants, l'approche habituelle consiste à démarrer un nouveau conteneur, à y transférer les joueurs ou à laisser l'ancien se vider, puis à l'arrêter pendant les heures les plus calmes.
Attribuez un tag unique à chaque image. Chaque build devient une image avec un tag qui n'est jamais réutilisé, comme une date avec un compteur ou un hachage de commit. Une branche de test et une branche de production peuvent alors fonctionner côte à côte à partir de tags différents, et un retour en arrière (rollback) consiste à pointer à nouveau la production vers le tag précédent plutôt que de reconstruire. Excluez le nom de l'environnement du tag, afin que le build qui a réussi les tests soit exactement celui qui est déployé.
Un mot de notre sponsor (nous-mêmes !)
Les pools chauds rendent l'allocation rapide car vous payez pour des serveurs qui restent inactifs. Edgegap déploie un nouveau serveur de jeu en une médiane de 2 secondes à partir d'un démarrage à froid, mesuré jusqu'à ce que le conteneur soit prêt avant le démarrage de votre moteur, de sorte qu'un serveur n'existe que lorsqu'un match en a besoin.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
Traitez chaque conteneur comme jetable
Un conteneur est conçu pour être arrêté. Les serveurs qui causent des problèmes sont ceux conçus comme si le leur ne le serait jamais.
Concevez de manière à ce que la perte d'un conteneur ne coûte rien : des résultats sauvegardés à la fin du match, des journaux dans un espace de stockage (bucket), un recyclage planifié. Ensuite, testez-le. Lors d'un test de jeu, arrêtez un conteneur en plein match et listez ce qui a été perdu. Chaque élément de cette liste est un bug, et il est généralement moins coûteux de le trouver ainsi que par le biais du signalement d'un joueur.
Le caractère jetable ne fonctionne que si le remplacement d'un conteneur est rapide. Sur Edgegap, le temps médian de déploiement d'un serveur à partir d'un démarrage à froid est de 2 secondes sur une période glissante de 30 jours, mesuré jusqu'au moment où le conteneur est prêt, avant le démarrage du moteur de jeu (données de la plateforme, 18 septembre 2026).
,
