Pelican

Pelican tiene dos API con dos claves distintas, y Provibr necesita las dos. Vienen de dos pantallas distintas, y ambas tienen que pertenecer a una cuenta con permisos de administrador.

• La clave de aplicación, de Admin → API Keys. Empieza por papp_ y gestiona servidores: crear, suspender, reinstalar, eliminar. Conviene darle permisos de lectura y escritura sobre Server, Node, Allocation, User y Egg.
• La clave de cliente, de Profile → API Keys de la propia cuenta. Empieza por pacc_ y lleva los comandos de encendido y apagado, las cifras de consumo en vivo y la consola.

Cuatro campos, y solo el último es opcional.

• La dirección del panel, por ejemplo https://panel.example.com. Solo hay que añadir un puerto si el panel se ejecuta realmente en él; detrás de un proxy inverso responde en el puerto predeterminado de su esquema.
• La clave de aplicación, que empieza por papp_.
• La clave de cliente, que empieza por pacc_.
• La huella TLS del panel, necesaria solo si su certificado es autofirmado.

Si el panel presenta un certificado autofirmado, hay que rellenar su huella. El agente confía entonces en ese certificado concreto en lugar de desactivar la verificación. Se lee con:

openssl s_client -connect <host>:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256

Con un certificado de una autoridad pública se deja el campo vacío, y también si el panel solo es accesible por http. Una huella junto a una dirección http se rechaza, porque no hay ningún certificado al que anclarse. Un panel en http sin cifrar sí funciona, pero entonces las dos claves viajan sin cifrar por la red.

Un servidor se construye a partir de un egg: una imagen de Docker, un comando de arranque y un conjunto de variables que el propio egg define. Provibr lee la lista del panel, así que el formulario de pedido ofrece los eggs que realmente hay en lugar de pedir un número.

Un plan de juego contiene el egg, la imagen, el comando de arranque y los límites que recibe un servidor. Al vincularlo a una o varias integraciones de Pelican, pasa a poderse pedir.

La memoria, el disco y la CPU aceptan 0 para sin límite, y el límite de CPU se cuenta en porcentaje de un núcleo: 100 es un núcleo entero, 200 son dos. El peso de E/S va de 0 a 1000 y 500 es el valor habitual.

Pelican informa de cuánta memoria y cuánta CPU tiene cada nodo, y de cuánto ya está repartido. Provibr usa las dos cosas: un servidor nuevo va a un nodo con sitio para él, y se rechaza con un motivo cuando ningún nodo lo tiene.

Toda la vida de un servidor de juego, desde el panel o a través de la API:

• Crearlo a partir de un plan y eliminarlo cuando el cliente se va.
• Iniciarlo, detenerlo, reiniciarlo y forzar su parada.
• Suspenderlo y reactivarlo. Es también lo que ocurre automáticamente cuando una cuenta supera su límite.
• Reinstalarlo, que vuelve a ejecutar el script de instalación de su egg.

Un servidor de juego se maneja desde su consola: comandos, jugadores y la línea de registro que explica un fallo. Funciona en el panel sobre la misma conexión saliente que todo lo demás, así que no hay un puerto aparte ni un segundo inicio de sesión.

Los servidores creados fuera de Provibr se dejan intactos. Se pueden importar para que aparezcan en el panel y cuenten para la capacidad, que es la manera de traer un panel existente sin reconstruir nada.

Los archivos, las copias de seguridad, las bases de datos y las programaciones se quedan en el panel de Pelican, igual que gestionar el panel y sus propios nodos. Provibr cubre la vida de un servidor y su consola, no la administración del panel.