Servidores de juegos

¿Qué es un servidor de juegos?

Introducido en la v0.6.0, un servidor de juegos es un tercer tipo de servicio dentro de un proyecto, junto a las aplicaciones y los stacks de compose. No tiene build ni dominios: DeployKit ejecuta una imagen de contenedor ya preparada, descrita por una definición de juego, publica sus puertos directamente en el host, guarda el mundo en volúmenes de Docker y te ofrece una consola en vivo, un gestor de archivos, backups programados del mundo y (en los juegos compatibles) mods y modpacks. Cada servidor también dispone de las pestañas habituales de Logs y Monitoring.

Definiciones de juego

Los juegos no vienen incluidos con DeployKit. Se obtienen en tiempo de ejecución del catálogo público de plantillas (el mismo registro que las plantillas, definido por TEMPLATES_REGISTRY_URL) y se guardan en caché, por lo que la instancia necesita acceso de salida a él. Cada definición declara la imagen, los puertos, el formulario de ajustes, los volúmenes, el tipo de consola, el comportamiento de parada, el alcance del backup y la memoria mínima. Al crear un servidor, su definición se copia en él: los cambios posteriores en el catálogo solo afectan a los servidores nuevos. Actualmente el catálogo ofrece:

Cada juego también muestra sus propias notas en la pestaña General del servidor — léelas, recogen peculiaridades específicas del juego, como qué ajustes se reescriben en cada arranque.

Crear un servidor de juegos

Desde la página de tu proyecto haz clic en New game server, elige un juego del catálogo y rellena el formulario:

• Server name — letras minúsculas, dígitos y guiones, hasta 41 caracteres, único en toda la instancia. Da nombre al contenedor (dk-gs-<name>) y a sus volúmenes
• Start from — para juegos con modpacks, el juego base o un modpack (consulta Mods y modpacks)
• Settings — el formulario propio del juego (p. ej. EULA, tipo de servidor, versión, MOTD, contraseñas). Campos como la semilla o el nombre del mundo quedan fijos tras la creación
• Ports — puertos del host para cada puerto del juego (ver más abajo)
• Memory — un límite estricto entre 256 MB y 64 GB; la API rechaza valores inferiores al mínimo del juego. En Minecraft el heap de la JVM se fija al 75 % de ese valor

Los campos secretos que dejes en blanco (como la contraseña de RCON) se generan por ti y se muestran una sola vez tras la creación — cópialos en ese momento. Después se almacenan cifrados y solo son visibles para los miembros del proyecto que pueden ver secretos. A continuación el servidor se aprovisiona en segundo plano; su estado pasa de provisioning a running. Si Docker falla, el servidor muestra error con el motivo, y Start lo reintenta. El primer arranque de la mayoría de los juegos descarga archivos del servidor y puede tardar varios minutos.

Crear un servidor de juegos requiere acceso Operator en el proyecto (iniciar desde un modpack se rechaza para los usuarios cuyo rol global es Viewer). Cambiar los ajustes en la pestaña Settings recrea el contenedor, así que un servidor en ejecución se reinicia y desconecta a sus jugadores. Eliminar un servidor de juegos requiere Admin del proyecto; por defecto sus volúmenes del mundo y sus backups se conservan en el host, salvo que marques Also delete world data and backups.

Puertos

Los jugadores se conectan directamente a un puerto del host — a menudo UDP — no a través de Traefik. El formulario rellena cada puerto con el puerto de host por defecto del juego, y puedes cambiarlo al crear el servidor o más tarde en Settings.

• Si un puerto del host ya está ocupado (por otro servidor de juegos, cualquier puerto de contenedor publicado, o un puerto que usa el propio DeployKit como 22, 80, 443, 5432 o 6379), la API lo rechaza y sugiere un puerto libre
• Las sugerencias salen de GAME_PORT_RANGE (por defecto 20000-40000); define esta variable en la API para usar otro rango
• El mismo número puede usarse una vez para TCP y otra para UDP
• Algunos juegos de Steam (Valheim, CS2) escuchan en el mismo número de puerto dentro del contenedor que en el host, y el puerto de consulta de Valheim es siempre el puerto del juego + 1
• La pestaña General muestra la dirección a la que se conectan los jugadores. Define PUBLIC_IP en el servidor de DeployKit para que pueda mostrar la dirección completa, no solo el puerto

Consola

La pestaña Console muestra la salida del servidor en vivo y, mientras el servidor está en ejecución, te permite escribir comandos (con historial con ↑/↓). La salida de tus comandos se muestra a todos los que estén viendo la consola. Cómo llega el comando al juego depende de su definición:

• RCON (Minecraft, CS2) — se envía por la red interna de juegos; el puerto RCON nunca se publica en el host y su contraseña se genera por servidor
• stdin (Terraria) — se escribe en la entrada estándar del proceso del servidor
• exec — se ejecuta mediante un inyector dentro del contenedor, nunca a través de una shell
• None (Valheim) — el juego no tiene consola remota, por lo que la pestaña Console se oculta

Los comandos son una sola línea de hasta 1000 caracteres, con un límite de 20 comandos cada 10 segundos por usuario y servidor, y cada comando queda registrado en el log de auditoría. Enviar comandos requiere el rol global Operator y acceso Operator en el proyecto — un comando de consola puede cargar un plugin, que es código. Al detener un servidor se envía primero el comando de parada propio del juego (p. ej. stop o exit) para que el mundo se guarde, y solo recurre a una señal si no termina a tiempo.

Archivos

La pestaña Files explora los volúmenes del servidor, tanto si está en ejecución como detenido. Puedes abrir y editar archivos de texto (hasta 1 MB; los archivos más grandes o binarios se descargan en su lugar), crear carpetas, renombrar, eliminar, subir y descargar archivos o carpetas completas. Los archivos de configuración habituales (como server.properties) tienen accesos directos en la parte superior.

• Las subidas están limitadas por GAME_UPLOAD_MAX_BYTES (256 MB por defecto)
• Leer y descargar archivos requiere permiso para ver secretos (Operator o Admin en el proyecto), porque los archivos de configuración contienen contraseñas
• Escribir, subir, renombrar y eliminar requiere el rol global Operator y acceso Operator en el proyecto — un .jar subido es código
• Las rutas están confinadas al volumen; DeployKit trabaja sobre los archivos mediante un contenedor auxiliar de corta duración, nunca directamente en el host

Backups del mundo

La pestaña Backups crea instantáneas comprimidas del mundo (las rutas que la definición del juego marca para backup — p. ej. solo worlds_local/ en Valheim, solo la carpeta cfg en CS2). Los backups pueden lanzarse manualmente o programarse con un preset de cron o una expresión cron personalizada.

• La retención es un número de backups (1–100, por defecto 7), no días — los mundos son grandes
• Si el juego tiene consola, el guardado se pausa y se vuelca durante el backup (p. ej. save-off / save-all flush / save-on en Minecraft) para que la instantánea sea consistente
• Restore detiene el servidor, reemplaza las rutas respaldadas y lo vuelve a iniciar si estaba en ejecución. Por defecto, antes hace un backup de seguridad del mundo actual
• Los backups pueden descargarse desde la lista; los backups completados y fallidos activan las notificaciones de backup habituales
• Los backups y las restauraciones se ejecutan de uno en uno por instancia, así que un backup en cola puede esperar a que termine otro

Mods y modpacks

Los juegos cuya definición admite mods tienen una pestaña Mods — hoy es el caso de Minecraft: Java Edition, con mods (Fabric, Forge) y plugins (Paper) de Modrinth y CurseForge. DeployKit mantiene la lista con cada versión fijada; la imagen del juego descarga los archivos cuando se reconstruye el contenedor.

• Añade mods buscando en un catálogo (los resultados se filtran por el loader y la versión de juego de tu servidor) o pegando un enlace o id
• Los cambios quedan pendientes hasta que hagas clic en Apply & restart, que hace un backup y recrea el contenedor. Eliminar o deshabilitar un mod, o cambiar el modpack, fuerza siempre ese backup — y si el backup falla, no se aplica nada
• Inicia un servidor nuevo desde un modpack de Modrinth o CurseForge, o define uno más tarde; el modpack decide el tipo de servidor y la versión del juego
• Check for updates compara tus versiones fijadas con los catálogos
• Los jars subidos a mano a mods/ o plugins/ desde la pestaña Files siguen funcionando y aparecen listados en On disk
• Añadir, actualizar o eliminar mods y aplicar cambios requiere el rol global Operator y acceso Operator en el proyecto

Modrinth funciona sin configuración. La búsqueda e instalación en CurseForge necesitan una clave de API, y la búsqueda en Steam Workshop necesita una clave de Steam Web API: un Admin las añade en Settings → Game mods. Las claves se validan contra el proveedor antes de guardarse, se almacenan cifradas y solo se muestran sus últimos 4 caracteres.

Aislamiento y refuerzo de seguridad

Los mods y plugins son código de terceros que se ejecuta dentro del contenedor, por lo que los servidores de juegos están más restringidos que las aplicaciones:

• Se ejecutan solo en su propia red de Docker, deploykit-games — no pueden alcanzar la red interna de DeployKit (Postgres, Redis, tus aplicaciones), y tus aplicaciones no pueden alcanzar sus puertos RCON. La API se une a esta red al arrancar para llegar a RCON
• no-new-privileges está activado, las capabilities NET_RAW, MKNOD, AUDIT_WRITE, SYS_CHROOT, SETFCAP y SETPCAP se eliminan, y cada contenedor está limitado a 2048 procesos
• La memoria es un límite estricto del contenedor
• Los servidores de juegos de la misma instancia pueden verse entre sí en deploykit-games; su RCON está protegido por una contraseña por servidor

La v0.6.0 también reforzó el resto del stack: Traefik ahora lee Docker a través de un proxy de socket de solo lectura, cada servicio se ejecuta con no-new-privileges y Redis requiere contraseña — las instalaciones de producción deben definir REDIS_PASSWORD en .env o el stack no arrancará.

Limitaciones

• Los servidores de juegos se ejecutan solo en el servidor local; los servidores remotos se rechazan
• El catálogo se obtiene del registro de plantillas; si no es accesible y no hay nada en caché, no se puede crear ningún juego
• Los nombres de servidor comparten el prefijo dk-gs- con otros servicios: una aplicación o base de datos llamada gs-<x> ocupa el nombre de contenedor dk-gs-<x>. DeployKit se niega a tocar un contenedor que no le pertenece y te pide renombrar el servidor de juegos
• Valheim no tiene consola, así que la parada y los backups dependen de una señal y del guardado propio del juego al apagarse; el crossplay no está habilitado
• Desde el dashboard solo se puede dimensionar la RAM; el uso de disco no está limitado, y algunos juegos descargan decenas de GB en el primer arranque