Pelican

Pelican heeft twee API's met twee verschillende sleutels, en Provibr heeft ze allebei nodig. Ze komen van twee verschillende schermen, en ze moeten allebei bij een account met beheerdersrechten horen.

• De application-sleutel, uit Admin → API Keys. Hij begint met papp_ en beheert servers: aanmaken, opschorten, herinstalleren, verwijderen. Geef hem lees- en schrijfrechten op Server, Node, Allocation, User en Egg.
• De client-sleutel, uit je eigen Profile → API Keys. Hij begint met pacc_ en draagt de aan/uit-commando's, live verbruikscijfers en de console.

Vier velden, en alleen het laatste is optioneel.

• Het adres van het paneel, bijvoorbeeld https://panel.example.com. Zet er alleen een poort bij als het paneel daar echt op draait; achter een reverse proxy antwoordt het op de standaardpoort van zijn schema.
• De application-sleutel die met papp_ begint.
• De client-sleutel die met pacc_ begint.
• De TLS-fingerprint van het paneel, alleen nodig als zijn certificaat self-signed is.

Biedt het paneel een self-signed certificaat aan, vul dan zijn fingerprint in. De agent vertrouwt dan dat ene certificaat in plaats van de controle uit te zetten. Lees hem uit met:

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

Laat het veld leeg bij een certificaat van een publieke autoriteit, en ook als het paneel alleen over http bereikbaar is. Een fingerprint naast een http-adres wordt geweigerd, want er is geen certificaat om op te pinnen. Een paneel op gewoon http werkt wel, maar beide sleutels reizen dan onversleuteld over je netwerk.

Een server wordt gebouwd uit een egg: een Docker-image, een startcommando en een set variabelen die het egg zelf definieert. Provibr leest de lijst van je paneel, zodat het bestelformulier de eggs aanbiedt die je echt hebt in plaats van om een nummer te vragen.

In een gameplan staan het egg, de image, het startcommando en de limieten die een server krijgt. Koppel het aan een of meer Pelican-integraties en het wordt bestelbaar.

Geheugen, schijf en cpu accepteren 0 voor onbeperkt, en de cpu-limiet telt in procenten van één core: 100 is één volle core, 200 is er twee. Het IO-gewicht loopt van 0 tot 1000 en 500 is de gebruikelijke waarde.

Pelican meldt hoeveel geheugen en hoeveel cpu elke node heeft, en hoeveel daarvan al is uitgedeeld. Provibr gebruikt allebei: een nieuwe server gaat naar een node met plek voor hem, en wordt met een reden geweigerd als geen enkele node die heeft.

De hele levensloop van een gameserver, vanuit het paneel of via de API:

• Hem uit een plan aanmaken, en verwijderen als de klant vertrekt.
• Starten, stoppen, herstarten en killen.
• Opschorten en weer vrijgeven. Dit gebeurt ook automatisch als een account over zijn limiet gaat.
• Opnieuw installeren, wat het installatiescript van zijn egg opnieuw draait.

Een gameserver wordt vanuit zijn console bediend: commando's, spelers, en de logregel die verklaart waarom hij crashte. Hij draait in het paneel over dezelfde uitgaande verbinding als al het andere, dus er is geen aparte poort en geen tweede login.

Servers die je buiten Provibr om hebt aangemaakt blijven met rust. Je kunt ze importeren zodat ze in het paneel verschijnen en meetellen voor je capaciteit, en zo verhuis je een bestaand paneel zonder iets opnieuw te bouwen.

Bestanden, back-ups, databases en schema's blijven in het Pelican-paneel, en het paneel en zijn nodes zelf beheren ook. Provibr dekt het leven van een server en zijn console, niet het beheer van je paneel.