Cómo vender alojamiento de servidores de juego con PufferPanel

PufferPanel es un panel de servidores de juego ligero y autoalojado. Se instala en minutos, ejecuta muchos juegos, y está gratamente libre de la complejidad de Pterodactyl. También le faltan varias cosas que un negocio de alojamiento da por hechas.

Esta página trata de vender sobre PufferPanel con los ojos abiertos: qué se automatiza limpiamente, qué no, y dónde está la frontera honesta. Todo lo que sigue se midió contra PufferPanel 3.0.9.

PufferPanel no es un fork de Pterodactyl

Vale la pena decirlo pronto, porque esa suposición cuesta días de trabajo. Pelican es un fork de Pterodactyl y comparte la mayor parte de la forma de su API. PufferPanel es un proyecto independiente, y nada se traspasa:

• La autenticación son credenciales de cliente OAuth2, no una clave de API.
• Los servidores se construyen a partir de plantillas comunitarias por nombre, no de eggs numerados.
• No hay ninguna jerarquía nest/egg que recorrer.
• Los identificadores de servidor son elegidos por uno mismo, de ocho caracteres, y se eligen en el momento de la creación en lugar de recibir uno.

Si tiene una integración de Pterodactyl y espera apuntarla a PufferPanel con un cambio de configuración, está escribiendo una integración nueva.

Conectar: OAuth2, y un secreto que se ve una vez

Se crea un cliente OAuth2 en el panel, dentro de su cuenta. Se obtienen un ID de cliente y un secreto de cliente; ambos entran en su automatización junto con la URL del panel.

Conviene copiar el secreto de cliente de inmediato. PufferPanel lo muestra una sola vez, en la creación. Un secreto copiado a medias da un simple error de autenticación en lugar de indicar que está incompleto: una hora muy corriente de su vida dedicada a comprobar lo que no es.

Lo que el cliente puede hacer depende de la cuenta a la que pertenece. No hay selector de alcance. Para que cree y elimine servidores, debe pertenecer a una cuenta de administrador. Es una nota de seguridad que importa: un cliente OAuth2 en una cuenta de administrador es una credencial de administrador, y debe tratarse como tal.

El puerto no se adivina

Un PufferPanel nuevo sirve HTTP simple en el puerto 8080. Detrás de un proxy inverso estará en el 443. No hay ningún puerto que una automatización pueda añadir en su lugar sin adivinar, así que conviene dar la URL completa: http://panel.example.com:8080 o https://panel.example.com.

Y conviene ser honesto consigo mismo sobre el transporte. Un panel en http simple funciona, pero el secreto de cliente (una credencial de administrador) y todo lo que hace la integración viajan entonces sin cifrar por su red. Si el panel está detrás de TLS con un certificado autofirmado, conviene fijar su huella en lugar de desactivar la verificación. Una huella junto a una dirección http se rechaza, porque no hay nada que fijar.

Plantillas, no eggs

PufferPanel construye un servidor a partir de una plantilla comunitaria (minecraft, factorio, etc.) en lugar de a partir de un egg numerado que uno mismo haya definido. El nombre de la plantilla es su identidad.

Dos consecuencias que determinan cómo se vende:

La definición completa de la plantilla debe enviarse en línea en la creación. PufferPanel no permite decir «hazme un servidor a partir de la plantilla X» por referencia; toda la definición, con sus variables, va en la petición. Por eso hacer pedidos en PufferPanel es, de manera realista, únicamente por plan: hace falta un catálogo que contenga la plantilla y sus valores, porque un formulario de texto libre pediría un documento a un cliente.

Las plantillas comunitarias usan por defecto un entorno de host. Ese entorno necesita binarios que un host de panel nuevo no tiene: Java, las dependencias de un juego, lo que la plantilla asuma. Si se deja tal cual, el servidor no consigue construirse y da un error de binario faltante que se lee como un fallo de su plataforma. La solución es cambiar a la variante docker de la plantilla, que los lleva en su imagen. Provibr lo hace automáticamente; si construye su propio puente, conviene hacerlo por cuenta propia, porque el modo de fallo es un ticket de soporte cada vez.

Colocación entre nodos, y por qué es tosca

PufferPanel expone sus nodos. No expone su memoria, su disco ni su CPU.

No es algo menor. Un motor de colocación no tiene nada por lo que clasificar: no puede preguntar qué nodo tiene sitio, porque el panel no responde a esa pregunta. Provibr informa del nodo de todos modos (un panel de juego sin ningún nodo no se puede pedir), pero con capacidad desconocida, y un panel con varios nodos se elige por orden de nombre en lugar de por espacio libre.

En la práctica: si ejecuta más de un nodo de PufferPanel, la planificación de la capacidad queda en sus manos. Nada en la cadena le impedirá sobrecargar un nodo, porque nada en la cadena puede verlo llenarse.

Ciclo de vida: lo que funciona

Crear, iniciar, detener, reiniciar, matar, reinstalar y eliminar funcionan todos.

Un detalle medido: la eliminación detiene primero el servidor, porque el demonio se niega a retirar un contenedor en ejecución. Una eliminación lanzada contra un servidor en marcha devuelve un 500 si se omite ese paso: exactamente el tipo de fallo que aparece la primera vez que un cliente cancela un servidor de Minecraft muy concurrido un viernes por la noche.

Tres cosas que PufferPanel no tiene

Esta es la sección que hay que leer antes de comprometerse con PufferPanel como plataforma de venta.

Sin suspensión

PufferPanel no tiene una suspensión propia. Ni columna, ni endpoint; el estado de un servidor solo conoce running e installing.

Así que cuando una plataforma «suspende» un servidor de juego de PufferPanel por impago, lo que ocurre realmente es esto: el contenedor se detiene, y el acceso a él se bloquea en el panel de la plataforma. Eso es algo real y útil, pero no lo impone el propio PufferPanel, lo que significa que cualquiera con acceso directo a la instalación de PufferPanel puede volver a iniciar el servidor.

Si sus clientes no tienen acceso al panel subyacente, esto no tiene consecuencias. Si lo tienen, su proceso de reclamación de pagos tiene un agujero, y ninguna cantidad de automatización lo cierra. Es una propiedad del panel, no de ninguna herramienta que se ponga delante. Compárese con Pelican, que tiene un indicador suspended de verdad.

Sin consola en directo

PufferPanel tiene una consola, pero está basada en sondeo: GET /console devuelve logs en base64 con un cursor epoch, y POST /console envía un comando. Un handshake de WebSocket conforme a la especificación contra /console devuelve 200 JSON en lugar de 101, probado tanto con un token bearer como con una cookie de sesión.

El relé de consola de Provibr es un túnel (transporta WebSockets NDJSON de Wings y VNC), y un modelo por sondeo no encaja en él sin construir una segunda forma de relé. Así que la consola está desactivada para PufferPanel, deliberadamente, en lugar de entregar un botón de consola que lleva a una pestaña que vuelve a la vista general.

Para un servidor de juego, la consola es, posiblemente, el producto. Conviene vender en consecuencia: sus clientes la obtienen en el propio PufferPanel, no en su panel de control.

Casi ninguna cifra de uso

El endpoint de estadísticas de PufferPanel informa del porcentaje de CPU y de la memoria en bytes. Nada de disco, nada de red, nada de tiempo de actividad.

El conjunto de gráficos estándar para un servidor de juego es CPU, memoria, disco y red. Dos de esos cuatro estarían permanentemente vacíos. Un gráfico clavado en cero para siempre es peor que ningún gráfico, así que los gráficos de uso también están desactivados para PufferPanel.

Entonces, ¿cuándo es PufferPanel la elección correcta?

Es un panel sinceramente bueno, y las fronteras anteriores no lo descalifican: simplemente son específicas. PufferPanel encaja si:

• Sus clientes no obtienen acceso directo al host del panel, con lo que la falta de imposición de la suspensión es irrelevante.
• Vende planes fijos en lugar de recursos medidos.
• Ejecuta un solo nodo, o le resulta cómodo ser su propio planificador de capacidad.
• Valora un panel pequeño, rápido y con pocas dependencias por encima de la profundidad de funciones.

Encaja menos bien si vende a un público técnico con acceso al panel, o si los gráficos de uso por servidor forman parte de lo que cobra.

No hay que elegir un solo panel

La respuesta realista para la mayoría de los proveedores de alojamiento de juegos es ambos. PufferPanel para el nivel ligero, Pelican o Pterodactyl donde la consola y la imposición de reglas importan, y probablemente alojamiento web o VPS junto a todo ello.

Provibr ejecuta sus paneles de control, sus hipervisores y sus paneles de juego en paralelo en un solo panel de control, con una sola API y una sola cifra de capacidad que lo cubre todo. Donde un proveedor no puede hacer algo, la plataforma se niega con un motivo que nombra la capacidad que falta en lugar de fingir lo contrario.

La página siguiente detalla en profundidad los caminos del pedido al servidor y de la factura impagada: automatización de facturación con PufferPanel.