Cómo containerizar tu servidor de MU Online con Docker

Correr un servidor de MU Online directamente en el sistema operativo funciona, pero crea un problema recurrente: las dependencias de MySQL, del .NET/VC++ redistributable y de los binarios del emulador quedan dispersas y son difíciles de reproducir en otra máquina. Containerizar el servidor con Docker resuelve esto — cada componente (base de datos, ConnectServer, JoinServer, GameServer, DataServer) corre aislado, con sus propias dependencias, y todo el entorno puede recrearse en minutos con un único comando. Este tutorial muestra cómo estructurar un docker-compose completo para un servidor de MU, desde los Dockerfiles individuales hasta la persistencia de datos y la red interna entre los servicios.

Por qué containerizar un servidor de MU Online

Un servidor de MU tradicional (basado en emuladores como MuEmu o IGCN) está compuesto por varios procesos que necesitan correr simultáneamente y comunicarse entre sí: MySQL, DataServer, JoinServer, ConnectServer y GameServer. Sin contenedores, migrar ese conjunto a otra máquina significa reinstalar manualmente cada dependencia, reconfigurar rutas y esperar que las versiones coincidan. Con Docker, cada pieza se convierte en una imagen versionada, con sus dependencias declaradas en un Dockerfile — el entorno entero queda reproducible, probable en una máquina de desarrollo y migrable a un servidor nuevo con docker-compose up.

Requisitos previos

• Docker Engine y Docker Compose instalados (Linux nativo, o Docker Desktop con WSL2 en Windows).
• Binarios del emulador de MU (GameServer, ConnectServer, JoinServer, DataServer) ya funcionando fuera de contenedor, para servir de base a los Dockerfiles.
• Backup completo de la base de datos actual antes de migrar al entorno containerizado.
• Conocimiento básico de red Docker (bridge networks, exposición de puertos).

Visión general de la arquitectura en contenedores

Todos los servicios comparten una red Docker interna (mu-network), lo que permite que se comuniquen por nombre de servicio en vez de por IP fijo — esencial para la portabilidad entre entornos de desarrollo y producción.

Estructurando el docker-compose.yml

version: "3.8"

services:
  mu-mysql:
    image: mysql:5.7
    container_name: mu-mysql
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: "senha_forte_aqui"
      MYSQL_DATABASE: "MuOnline"
    volumes:
      - mu-db-data:/var/lib/mysql
      - ./sql/init:/docker-entrypoint-initdb.d
    networks:
      - mu-network
    ports:
      - "3306:3306"

  mu-gameserver:
    build: ./gameserver
    container_name: mu-gameserver
    restart: unless-stopped
    depends_on:
      - mu-mysql
    environment:
      DB_HOST: mu-mysql
      DB_USER: root
      DB_PASS: "senha_forte_aqui"
    volumes:
      - mu-game-logs:/app/logs
    networks:
      - mu-network
    ports:
      - "55901:55901"

networks:
  mu-network:
    driver: bridge

volumes:
  mu-db-data:
  mu-game-logs:
  mu-data-files:

Este archivo es el punto central: describe todos los servicios, sus dependencias (depends_on), variables de entorno y la red compartida.

Escribiendo el Dockerfile del GameServer

FROM mcr.microsoft.com/windows/servercore:ltsc2022

WORKDIR /app
COPY ./bin/GameServer.exe .
COPY ./bin/Data/ ./Data/
COPY ./bin/Config/ ./Config/

EXPOSE 55901

CMD ["GameServer.exe"]

Para emuladores compilados en C++/Delphi para Windows, esta es la ruta más sencilla: usar una imagen base Windows Server Core y copiar los binarios ya compilados. En entornos Linux, muchos administradores optan por correr los binarios Windows bajo Wine dentro de un contenedor Linux, lo que reduce el consumo de recursos comparado con una imagen Windows completa.

Persistencia de datos con volúmenes

Nunca dejes la base de datos ni los archivos de configuración dentro del sistema de archivos "efímero" del contenedor. Un docker-compose down sin volúmenes nombrados borra todo el progreso de los jugadores. Declara siempre volúmenes nombrados (mu-db-data, mu-game-logs) y, si es posible, monta carpetas del host directamente para los archivos de configuración que editas con frecuencia:

volumes:
  - ./config/GameServerInfo.dat:/app/Config/GameServerInfo.dat

Esto permite editar la configuración en el host, sin necesidad de reconstruir la imagen en cada ajuste pequeño.

Configurando la red interna entre los servicios

Dentro de la red mu-network, cada contenedor ve a los demás por el nombre del servicio definido en el Compose. Esto significa que, en la cadena de conexión del GameServer con la base de datos, en vez de 127.0.0.1 usas mu-mysql:

[Database]
Host = mu-mysql
Port = 3306
User = root
Password = senha_forte_aqui

Este es el ajuste más común al migrar una configuración existente a Docker: cualquier referencia a localhost en la base de datos debe convertirse en el nombre del servicio correspondiente.

Backup y restauración de la base de datos containerizada

# Backup
docker exec mu-mysql mysqldump -u root -psenha_forte_aqui MuOnline > backup_$(date +%F).sql

# Restauración
docker exec -i mu-mysql mysql -u root -psenha_forte_aqui MuOnline < backup_2026-07-30.sql

Automatiza este comando con un cron job en el host, guardando los archivos .sql fuera del contenedor — así, aunque destruyas y recrees el contenedor de MySQL, el backup permanece seguro en el host.

Logs y monitoreo de los contenedores

Usa docker logs -f mu-gameserver para seguir el comportamiento del GameServer en tiempo real, y docker stats para monitorear el consumo de CPU/memoria de cada servicio. Para producción, vale la pena integrar una stack de observabilidad (Prometheus + Grafana) recolectando métricas de los contenedores, especialmente el uso de CPU del GameServer en horarios pico, que suele ser el cuello de botella en servidores con muchos jugadores simultáneos.

Actualizando el servidor sin downtime largo

Al lanzar una nueva versión del emulador o una corrección de configuración, el flujo recomendado es: reconstruir solo la imagen del servicio modificado (docker-compose build mu-gameserver), luego recrear solo ese contenedor (docker-compose up -d --no-deps mu-gameserver), manteniendo el MySQL y los demás servicios activos. Esto reduce el tiempo de indisponibilidad a segundos, en vez de tumbar toda la stack por un ajuste puntual.

Errores comunes y soluciones

Lista de verificación de containerización

• Docker y Docker Compose instalados y probados.
• Dockerfiles creados para cada servicio (MySQL, GameServer, ConnectServer, JoinServer).
• docker-compose.yml con red interna y volúmenes nombrados definidos.
• Cadenas de conexión actualizadas a nombres de servicio.
• Rutina de backup de la base de datos automatizada y probada.
• Logs y métricas de cada contenedor siendo monitoreados.
• Proceso de actualización sin downtime documentado y probado.

Con el servidor corriendo en contenedores, el siguiente paso natural es estandarizar ese entorno como base para nuevos despliegues — incluso para quien está montando el proyecto desde cero. Consulta el tutorial de creación de servidor de MU Online para alinear esta infraestructura containerizada con los fundamentos del emulador.

Preguntas frecuentes