Pelican

Pelican ha due API con due chiavi diverse, e Provibr ha bisogno di entrambe. Provengono da due schermate diverse e devono appartenere entrambe a un account con diritti di amministratore.

• La chiave applicazione, da Admin → API Keys. Inizia con papp_ e gestisce i server: creare, sospendere, reinstallare, eliminare. Le conceda accesso in lettura e scrittura a Server, Node, Allocation, User ed Egg.
• La chiave client, dal suo Profile → API Keys. Inizia con pacc_ e trasporta i comandi di accensione e spegnimento, i dati di utilizzo in tempo reale e la console.

Quattro campi, e solo l’ultimo è facoltativo.

• L’indirizzo del pannello, ad esempio https://panel.example.com. Aggiunga una porta solo se il pannello gira davvero su una; dietro a un reverse proxy risponde sulla porta predefinita del suo schema.
• La chiave applicazione, che inizia con papp_.
• La chiave client, che inizia con pacc_.
• L’impronta TLS del pannello, necessaria solo quando il suo certificato è autofirmato.

Se il pannello presenta un certificato autofirmato, inserisca la sua impronta. L’agente si fida allora di quel singolo certificato invece di disattivare la verifica. La legga con:

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

Lasci il campo vuoto per un certificato di un’autorità pubblica, e lo stesso quando il pannello è raggiungibile solo tramite http: un’impronta accanto a un indirizzo http viene rifiutata, perché non c’è alcun certificato da fissare. Un pannello in http in chiaro funziona, ma entrambe le chiavi viaggiano allora senza cifratura sulla sua rete.

Un server è costruito a partire da un egg: un’immagine Docker, un comando di avvio e un insieme di variabili definite dall’egg stesso. Provibr legge l’elenco dal suo pannello, così il modulo d’ordine propone gli egg che ha davvero invece di chiedere un numero.

Un piano di gioco contiene l’egg, l’immagine, il comando di avvio e i limiti che riceve un server. Lo colleghi a una o più integrazioni Pelican e diventa ordinabile.

Memoria, disco e CPU accettano 0 per illimitato, e il limite di CPU si conta in percentuale di un core: 100 è un core intero, 200 sono due. Il peso I/O va da 0 a 1000 e 500 è il valore consueto.

Pelican comunica quanta memoria e quanta CPU ha ciascun nodo, e quanta ne è già stata distribuita. Provibr usa entrambe: un nuovo server va su un nodo che ha spazio per accoglierlo, e viene rifiutato con una motivazione quando nessun nodo ne ha.

L’intera vita di un server di gioco, dal pannello o tramite l’API:

• Crearlo a partire da un piano ed eliminarlo quando il cliente se ne va.
• Avviarlo, arrestarlo, riavviarlo e forzarne l’arresto.
• Sospenderlo e riattivarlo: è anche ciò che avviene automaticamente quando un account supera il proprio limite.
• Reinstallarlo, operazione che esegue di nuovo lo script di installazione del suo egg.

Un server di gioco si guida dalla sua console: comandi, giocatori e la riga di log che spiega un crash. Funziona nel pannello attraverso la stessa connessione in uscita di tutto il resto, quindi non c’è una porta separata né un secondo accesso.

I server creati al di fuori di Provibr vengono lasciati intatti. Li può importare in modo che compaiano nel pannello e incidano sulla sua capacità: è così che si trasferisce un pannello esistente senza ricostruire nulla.

File, backup, database e pianificazioni restano nel pannello Pelican, e così pure la gestione del pannello e dei suoi nodi. Provibr copre la vita di un server e la sua console, non l’amministrazione del suo pannello.