Docker
Docker est une plateforme qui encapsule une application et tout ce dont elle a besoin dans une image de conteneur qui se comporte de manière identique quel que soit l'endroit où elle s'exécute. Pour les serveurs de jeu, cela comble le fossé entre une version qui fonctionne sur une machine et cette même version qui échoue sur une autre, et c'est l'unité déployée par la plupart des plateformes d'orchestration.
,
Pourquoi les serveurs de jeu sont-ils empaquetés avec Docker ?
Docker est l'outil qui transforme la construction d'un serveur en une image de conteneur et vous permet d'exécuter cette image sur votre propre machine. L'image est ce que vous livrez. En production, une plateforme d'hébergement ou un orchestrateur exécute la même image avec son propre moteur d'exécution de conteneur, généralement containerd, sans que Docker ne soit installé.
Cela fait de l'image l'artefact de construction. La CI la produit, la QA la teste, la production l'exécute, et chaque version porte un tag. Revenir sur un correctif défectueux signifie redéployer le tag précédent plutôt que de reconstruire une machine.
Un conteneur n'est pas non plus une machine virtuelle. Il partage le noyau du système d'exploitation de l'hôte au lieu d'exécuter le sien sur un hyperviseur, de sorte que la simulation d'un serveur s'exécute à une vitesse proche de celle du processeur natif et démarre sans démarrer de système d'exploitation. Chaque conteneur s'exécute également dans les limites de processeur et de mémoire qui lui ont été attribuées, de sorte qu'une instance ne peut pas s'approprier la part de l'hôte d'une autre. Le compromis réside dans une certaine surcharge au niveau du réseau et des E/S disque.
Qu'est-ce qui casse quand on conteneurise un serveur de jeu ?
La plupart des problèmes proviennent de la build, pas du conteneur, et l'exécution locale de l'image avec Docker permet de les détecter avant tout déploiement. Quatre d'entre eux reviennent fréquemment :
La build cible le mauvais système d'exploitation. Les hôtes de conteneurs exécutent Linux, le serveur a donc besoin d'une build Linux : une build Linux Dedicated Server dans Unity, ou une cible Linux dans Unreal, souvent compilée de manière croisée depuis Windows.
L'image cible le mauvais processeur. Les images créées sur un Mac Apple Silicon sont par défaut au format arm64, tandis que la plupart des serveurs exécutent amd64. Le fait de compiler avec
--platform linux/amd64évite que l'image n'échoue au démarrage.Le port du jeu est en TCP.
docker run -ppublie du TCP sauf indication contraire, donc un port de jeu UDP nécessite/udp, comme dans-p 7777:7777/udp(documentation Docker). En production, la plateforme attribue le port externe, le serveur doit donc lire son port à partir de l'environnement plutôt que de l'écrire en dur.L'image est trop volumineuse. Chaque nouvel hôte doit charger l'image avant qu'un match puisse y démarrer. La taille de l'image influe donc directement sur le temps d'attente des joueurs pour un nouveau serveur.
Une fois que le serveur s'exécute correctement dans un conteneur, la question suivante est de savoir combien coûte son exécution. Pour Unreal, le profilage d'une build de serveur dédié montre où vont le processeur, la mémoire et la bande passante.
Le WebAssembly peut-il remplacer les conteneurs pour les serveurs de jeux ?
Pas encore. L'attrait de WebAssembly réside dans sa taille. En mai 2026, le développeur Ivan Bogomolov a compilé l'intégralité d'un moteur Godot 4 dans un binaire WebAssembly de 35 Mo, contre 421 Mo pour l'image Docker Node.js par défaut. Des binaires plus petits signifieraient des téléchargements plus rapides et des démarrages plus rapides.
Mais cela s'arrête au niveau du serveur. L'interface système WebAssembly (WASI) ne permet pas encore un accès fiable aux sockets UDP dont dépendent les serveurs de jeu, le multi-threading nécessite des contournements, et les runtimes des serveurs se rabattent sur les WebSockets via TCP, ce que le netcode des jeux est conçu pour éviter. Aujourd'hui, WebAssembly convient aux jeux Web solo. Notre analyse complète détaille chaque limite.
Pour l'instant, l'unité portable reste le conteneur. Comme une image s'exécute de la même manière sur le matériel de n'importe quel fournisseur, une seule version peut être déployée sur un réseau de la taille de celui d'Edgegap : plus de 615 emplacements répartis sur plus de 17 fournisseurs (données de la plateforme, au 18 septembre 2026).
Un mot de notre sponsor (nous-mêmes !)
Une région est une supposition quant à l'endroit où se trouveront vos joueurs. L'Edge Cloud d'Edgegap est un réseau distribué et multi-cloud de plus de 615 emplacements répartis sur plus de 17 fournisseurs, disponible sur demande. Chaque serveur se lance au meilleur emplacement disponible sur le réseau au début du match, et non dans la région la plus proche parmi une poignée d'options.
