Cómo vender alojamiento de servidores de juego con Pelican Panel

Pelican ejecuta servidores de juego. No acepta pedidos, no envía facturas y no decide que un servidor deba detenerse porque nadie lo ha pagado. De esa brecha (entre el panel funciona y el negocio funciona) trata esta página.

Pelican es un fork de Pterodactyl y, en el momento de escribir esto, sigue en beta. Provibr se conecta a él como integración live y está probado con Pelican 1.0.0.

Qué ofrece Pelican y qué no

Pelican es un panel de control. Conoce bien tres cosas:

Lo que Pelican no conoce: un cliente, una factura, un pago, una suscripción que caduca. Existe un indicador suspended en un servidor, pero nada en el panel lo activa jamás en su lugar.

Así que un negocio de alojamiento de juegos construido sobre Pelican tiene tres partes, no una:

1. 01El panel: Pelican, que ejecuta sus servidores.
2. 02La tienda: donde un cliente elige un plan y paga. WHMCS, Blesta, FOSSBilling, su propio proceso de pago.
3. 03El puente: lo que convierte un pedido pagado en un servidor en marcha, y uno impagado en un servidor detenido.

La mayoría de la gente construye esa tercera parte a mano y se arrepiente. Es donde viven los casos límite: un nodo lleno, una variable de egg que se dejó vacía, un cliente que cancela mientras el instalador todavía está en marcha.

Conectar Pelican: dos claves y una trampa

Pelican tiene dos API con dos claves diferentes, y un puente de aprovisionamiento necesita ambas. Provienen de dos pantallas diferentes, y ambas deben pertenecer a una cuenta con derechos de administrador.

La clave de aplicación necesita acceso de lectura y escritura sobre Server, Node, Allocation, User y Egg. Con menos, la creación falla a mitad de camino, lo cual es peor que fallar al principio.

Dos aspectos de esto que cuestan una tarde:

Conviene copiar la clave de cliente en cuanto aparece. Pelican la muestra una sola vez. Después, la lista solo conserva un identificador corto, y ese identificador se acepta como clave, así que pegarlo da un simple error de autenticación en lugar de una pista de que se copió lo equivocado. La clave de aplicación sí puede releerse íntegramente desde la lista; la clave de cliente no.

Atención a qué clave va en qué campo. Pelican también acepta una clave de cliente en la API de gestión, así que intercambiar ambas no produce ningún error visible. El prefijo es lo único que las distingue. Provibr comprueba ese prefijo en ambos lados exactamente por esta razón: la alternativa es una integración que parece autenticarse y luego se comporta de forma extraña durante una semana.

Aquí no hay atajo por línea de comandos: Pelican no incluye ningún comando artisan para las claves de API, así que ambas se crean a través de la interfaz web.

Si el panel presenta un certificado autofirmado, conviene fijar su huella en lugar de desactivar la verificación. Un panel accesible por http simple funciona, pero ambas claves viajan entonces sin cifrar por su red, y una huella junto a una dirección http se rechaza, porque no hay ningún certificado que fijar.

De los eggs a algo que se pueda vender

Un egg no es un producto. No tiene precio, ni un nombre que un cliente reconozca, ni límites asociados. Un plan es la capa que convierte lo uno en lo otro: contiene el egg, la imagen Docker, el comando de arranque y los límites de recursos que recibe un servidor.

Dos detalles que sorprenden al fijar los límites:

• La memoria, el disco y la CPU aceptan 0 para ilimitado.
• El límite de CPU se cuenta en porcentaje de un núcleo. 100 es un núcleo entero, 200 son dos. Un plan vendido como «2 vCPU» es 200, no 2.
• El peso de E/S va de 0 a 1000, y 500 es el valor habitual.

La regla de las variables obligatorias

Un egg define sus propias variables y marca algunas como obligatorias. He aquí una decisión que vale la pena copiar, se use Provibr o no:

Rechazar el pedido cuando una variable obligatoria está vacía, aunque el propio Pelican lo aceptaría.

Pelican crea el servidor de todos modos. El contenedor falla entonces en su primer arranque, el cliente ve un servidor muerto, y su cola de soporte recibe un ticket que dice «no funciona». Un campo que se pone rojo al realizar el pedido es una respuesta mucho mejor que un servidor que existe y no arranca.

Provibr lee la lista de eggs desde su panel, de modo que el formulario de pedido ofrece los eggs que realmente tiene en lugar de pedir que se escriba un número.

Dónde aterriza un servidor

Pelican indica cuánta memoria y CPU tiene cada nodo, y qué parte de ellas ya está repartida. Un puente sensato usa ambas: un servidor nuevo va a un nodo que tiene sitio para él, y se rechaza con un motivo cuando ningún nodo lo tiene.

⚠️ Las cifras que reporta el panel son contabilidad, no una medición. Suman los límites de los servidores presentes en un nodo, incluidos los que todavía se están instalando. Un nodo puede, por tanto, parecer lleno mientras en realidad se está ejecutando muy poco.

Eso importa comercialmente. Si se sobrevende (y la mayoría de los proveedores de alojamiento de juegos lo hacen, porque un servidor de Minecraft al que se le asignan 4 GB rara vez usa 4 GB), las cifras de Pelican lo detendrán mucho antes que su hardware. Conviene calibrar los presupuestos de nodo según lo que se piensa vender, no según lo que la máquina puede soportar físicamente.

Lo que el cliente toca realmente

Para un servidor de juego, la consola es el producto. Los comandos, las entradas de jugadores y la línea de log que explica un fallo viven todas ahí. Pelican tiene una consola de verdad, y Provibr la transmite al cliente por la misma conexión saliente que todo lo demás: sin puerto separado, sin segundo inicio de sesión, sin segunda contraseña que restablecer.

Los archivos, las copias de seguridad, las bases de datos y las planificaciones se quedan en Pelican. Es deliberado: son funciones del panel, y reconstruirlas en una segunda interfaz da a sus clientes dos lugares donde podría estar la verdad.

Migrar un panel existente

Si ya ejecuta Pelican con clientes de pago, no tiene que reconstruir nada. Los servidores creados fuera del puente se dejan en paz; se importan para que aparezcan en su panel de control y cuenten para su capacidad.

Importar no toca el servidor. Solo empieza a contarlo. Mientras no se importe, no está ni gestionado ni facturado, lo que significa que se puede migrar un panel por lotes, a su propio ritmo, en lugar de durante una ventana de mantenimiento.

Lo que esto no cubre

Conviene tener clara la frontera antes de vender frente a ella:

• La administración del panel se queda en Pelican. Añadir nodos, editar eggs, gestionar los usuarios del panel: nada de eso se traslada.
• Los archivos, las copias de seguridad, las bases de datos y las planificaciones también se quedan en Pelican.
• Pelican sigue en beta y su API cambia entre versiones. El panel no ofrece ninguna forma de preguntar qué versión ejecuta, así que una actualización que cambia una respuesta se manifiesta como un error en lugar de como un aviso previo. Conviene leer las notas de la versión antes de actualizar un panel con el que habla su automatización. Esto no es una limitación de Provibr: es una propiedad del panel, y cualquier puente que se construya la tendrá.

No hay que elegir un solo panel

La mayoría de los proveedores de alojamiento de juegos acaban ejecutando más de un panel: Pelican para el stock nuevo, Pterodactyl para lo que ya estaba, otra cosa para un cliente que insistió. Y la mayoría también venden alojamiento web o VPS junto a ello.

Provibr ejecuta sus paneles de control, sus hipervisores y sus paneles de juego en paralelo en un solo panel de control. Una sola cifra de capacidad, un solo conjunto de claves de API, un solo lugar donde se registra la vida de un servidor, sea cual sea el panel en el que se ejecute.

La página siguiente cubre la otra mitad: qué le ocurre a un servidor Pelican cuando una factura queda impagada.