Serveur de jeu Docker : le rendre portable en conteneur

Mettre en place un serveur de jeu Docker libère votre serveur de toute dépendance à un système d'exploitation ou à une seule machine : chaque dépendance, version et configuration est empaquetée dans une image, si bien que le serveur fonctionne de la même manière partout où vous le déplacez. Vous ne direz plus jamais « ça marchait sur ma machine mais ça refuse de démarrer sur le VPS ». Dans cet article, nous verrons la logique de la conteneurisation d'un serveur de jeu, comment protéger les données de sauvegarde persistantes, le mappage des ports, le redémarrage automatique, ainsi que la façon de sauvegarder et de tout déplacer vers une autre machine — le tout avec des exemples concrets.

Pourquoi conteneuriser un serveur de jeu ?

Dans une installation classique, vous déposez le serveur sur une machine nue, installez manuellement le bon environnement d'exécution (Java, .NET, une version précise de glibc, etc.) et écrivez des fichiers de service. Le problème, c'est que cette installation est spécifique à cette machine. Docker renverse cette logique :

• Portabilité : la même image fonctionne à l'identique sur votre machine de développement, sur un VPS et sur un serveur de secours.
• Isolation : le serveur tourne dans son propre conteneur ; il ne pollue pas le système hôte et n'entre pas en conflit de versions avec d'autres services.
• Reproductibilité : votre configuration vit dans un Dockerfile et un compose.yaml ; vous pouvez reconstruire toute l'installation avec une seule commande.
• Gestion des versions facilitée : les tags d'image (:1.20, :latest) figent la version du serveur et permettent de revenir en arrière au besoin.

Une image prête à l'emploi ou votre propre Dockerfile ?

Pour la plupart des jeux populaires, il existe des images communautaires. Pour Minecraft, par exemple, itzg/minecraft-server est une image mature et très utilisée qui gère l'EULA, la version et la mémoire via des variables d'environnement. Si une image prête existe, l'utiliser est la voie la plus rapide. Mais pour un serveur personnalisé ou que vous avez écrit vous-même, vous devez construire votre propre image. Pour un simple binaire de serveur Linux, un Dockerfile typique ressemble à ceci :

FROM debian:12-slim

# Dépendances d'exécution
RUN apt-get update && apt-get install -y --no-install-recommends \
        ca-certificates libstdc++6 \
    && rm -rf /var/lib/apt/lists/*

# Un utilisateur dédié au lieu de root
RUN useradd --system --create-home --uid 1000 gameserver
USER gameserver
WORKDIR /home/gameserver

# Copier les fichiers du serveur
COPY --chown=gameserver:gameserver ./server/ ./

# Port de jeu (exemple : UDP 27015)
EXPOSE 27015/udp

CMD ["./game_server", "--config", "server.cfg"]

On trouve ici quelques bonnes habitudes : partir d'une base -slim garde l'image légère, --no-install-recommends élimine les paquets superflus, et faire tourner le serveur avec un utilisateur non-root est important pour la sécurité. Root à l'intérieur d'un conteneur augmente le risque sur l'hôte.

Données persistantes : les sauvegardes doivent vivre dans un volume

C'est le point le plus critique. Un conteneur est éphémère ; lorsqu'il est supprimé avec docker rm, son système de fichiers disparaît avec lui. Si la sauvegarde du monde, les données des joueurs et la configuration restent dans le conteneur, vous perdrez tout lors d'une mise à jour. La solution consiste à relier ces dossiers à un volume ou à un répertoire de l'hôte :

docker run -d \
  --name serveur-jeu \
  -p 27015:27015/udp \
  -v /srv/jeu/data:/home/gameserver/data \
  --restart unless-stopped \
  mon-serveur:1.0

La clause -v /srv/jeu/data:/home/gameserver/data relie un dossier persistant de l'hôte au répertoire de données du conteneur. Désormais, même si vous supprimez, mettez à jour ou déplacez le conteneur vers une autre machine, les sauvegardes restent côté hôte. Lorsque vous configurez votre serveur, assurez-vous que le chemin de sauvegarde écrit bien dans ce répertoire monté.

Mappage des ports : TCP ou UDP ?

Les serveurs de jeu utilisent surtout l'UDP, car dans le jeu en temps réel une faible latence importe plus que la retransmission des paquets perdus. Certains serveurs ouvrent en plus un port TCP de requête/RCON. Dans l'option -p, vous devez indiquer le protocole correctement :

• -p 27015:27015/udp — le port UDP pour le trafic de jeu.
• -p 27015:27015/tcp — le port TCP pour RCON / requêtes (si nécessaire).

Le nombre de gauche est le port de l'hôte, celui de droite le port du conteneur. Si le serveur est inaccessible depuis l'extérieur, c'est le premier endroit à vérifier : soit le protocole est faux (TCP/UDP confondus), soit le pare-feu du VPS (par exemple ufw) bloque le port.

Une installation propre avec Compose

Plutôt que d'écrire de longues lignes docker run en ligne de commande, déplacer la configuration dans un fichier compose.yaml est bien plus durable. La définition complète du serveur tient dans un seul fichier et se lance avec docker compose up -d :

services:
  game:
    build: .
    container_name: serveur-jeu
    ports:
      - "27015:27015/udp"
    volumes:
      - ./data:/home/gameserver/data
    environment:
      MAX_PLAYERS: "32"
      SERVER_NAME: "Aslain Serveur"
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "2.0"

Ici, restart: unless-stopped fait remonter le conteneur automatiquement même si le serveur plante ou si la machine redémarre — un réglage essentiel pour un serveur de jeu. Le bloc deploy.resources.limits empêche un seul serveur de jeu de consommer tout le CPU et la RAM et de bloquer l'hôte.

Sauvegarde et migration vers un autre serveur

Le plus bel atout de l'approche conteneur est que la migration se résume à peine à copier le dossier de données. Comme l'image est la même partout, sur le nouveau serveur il vous suffit de récupérer/construire l'image et de restaurer le répertoire de données :

# Instantané du dossier de données (le plus sûr : serveur arrêté)
docker compose stop game
tar czf sauvegarde-$(date +%F).tar.gz ./data
docker compose start game

# Sur le nouveau serveur :
tar xzf sauvegarde-2026-06-28.tar.gz
docker compose up -d

Pour moins d'interruption sur un serveur en production, vous pouvez d'abord déclencher la commande « save » dans le jeu afin que tout soit écrit sur le disque, puis prendre la sauvegarde. Vous pouvez aussi relier cette étape de sauvegarde à une tâche cron pour produire des sauvegardes quotidiennes automatiques.

Questions fréquentes

Y a-t-il une perte de performance avec un serveur de jeu Docker ?

Sous Linux, Docker n'est pas une machine virtuelle ; il utilise une couche d'isolation légère qui partage le noyau avec l'hôte. Le surcoût mesurable pour le CPU et la mémoire est très faible et n'entraîne aucune latence que les joueurs ressentiraient. Côté réseau, le réseau bridge par défaut ajoute un petit surcoût de NAT ; si vous ne le voulez pas, vous pouvez exposer les ports directement sur l'hôte avec network_mode: host.

Ma sauvegarde du monde disparaît-elle quand le conteneur est supprimé ?

Non, si vous avez relié les données à un volume ou à un répertoire de l'hôte. Les dossiers montés à l'extérieur avec -v sont indépendants du cycle de vie du conteneur ; même si vous supprimez et recréez le conteneur, les sauvegardes restent en place. Garder les données en dehors du conteneur est la règle la plus importante.

Puis-je aussi conteneuriser un serveur de jeu Windows ?

Docker est à son meilleur sur les serveurs Linux. Un binaire de serveur qui ne tourne que sous Windows nécessite des conteneurs Windows, une voie plus limitée et malcommode. Dans la plupart des cas, préférer les serveurs disposant d'une version Linux vous permet de tirer le meilleur de Docker.

Vous voulez déplacer votre serveur de jeu dans un conteneur ? Pour planifier ensemble toute l'installation — de l'écriture du Dockerfile aux données persistantes, aux sauvegardes et au déploiement sur VPS — contactez-moi.