Pelican

Pelican possède deux API avec deux clés différentes, et Provibr a besoin des deux. Elles proviennent de deux écrans différents, et toutes deux doivent appartenir à un compte disposant des droits d’administrateur.

• La clé application, issue d’Admin → API Keys. Elle commence par papp_ et gère les serveurs : créer, suspendre, réinstaller, supprimer. Accordez-lui les droits de lecture et d’écriture sur Server, Node, Allocation, User et Egg.
• La clé client, issue de votre propre Profile → API Keys. Elle commence par pacc_ et transporte les commandes d’alimentation, les relevés d’utilisation en direct et la console.

Quatre champs, et seul le dernier est facultatif.

• L’adresse du panneau, par exemple https://panel.example.com. N’ajoutez un port que si le panneau y tourne réellement ; derrière un proxy inverse, il répond sur le port par défaut de son schéma.
• La clé application, commençant par papp_.
• La clé client, commençant par pacc_.
• L’empreinte TLS du panneau, nécessaire uniquement lorsque son certificat est auto-signé.

Si le panneau présente un certificat auto-signé, renseignez son empreinte. L’agent fait alors confiance à ce certificat précis au lieu de désactiver la vérification. Lisez-la avec :

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

Laissez le champ vide pour un certificat émis par une autorité publique, ainsi que si le panneau n’est joignable qu’en http. Une empreinte à côté d’une adresse http est refusée, car il n’y a aucun certificat sur lequel s’ancrer. Un panneau en http simple fonctionne, mais les deux clés circulent alors en clair sur votre réseau.

Un serveur est construit à partir d’un egg : une image Docker, une commande de démarrage et un jeu de variables que l’egg définit lui-même. Provibr lit la liste depuis votre panneau, si bien que le formulaire de commande propose les eggs que vous avez réellement au lieu de demander un numéro.

Un plan de jeu contient l’egg, l’image, la commande de démarrage et les limites qu’un serveur reçoit. Reliez-le à une ou plusieurs intégrations Pelican et il devient commandable.

La mémoire, le disque et le processeur acceptent 0 pour illimité, et la limite de processeur se compte en pourcentage d’un cœur : 100 correspond à un cœur entier, 200 à deux. Le poids d’E/S va de 0 à 1000 et 500 en est la valeur habituelle.

Pelican indique de combien de mémoire et de combien de processeur dispose chaque nœud, et quelle part en est déjà distribuée. Provibr se sert des deux : un nouveau serveur va sur un nœud qui a de la place pour lui, et il est refusé avec un motif lorsqu’aucun nœud n’en a.

Toute la vie d’un serveur de jeu, depuis le panneau ou via l’API :

• Le créer à partir d’un plan, et le supprimer quand le client s’en va.
• Le démarrer, l’arrêter, le redémarrer et forcer son arrêt.
• Le suspendre et le réactiver. C’est aussi ce qui se produit automatiquement lorsqu’un compte dépasse sa limite.
• Le réinstaller, ce qui relance le script d’installation de son egg.

Un serveur de jeu se pilote depuis sa console : commandes, joueurs, et la ligne de journal qui explique un plantage. Elle fonctionne dans le panneau via la même connexion sortante que tout le reste, si bien qu’il n’y a ni port distinct ni seconde authentification.

Les serveurs que vous avez créés en dehors de Provibr sont laissés tels quels. Vous pouvez les importer pour qu’ils apparaissent dans Provibr et comptent dans votre capacité, ce qui est le moyen de basculer un panneau existant sans rien reconstruire.

Les fichiers, les sauvegardes, les bases de données et les planifications restent dans le panneau Pelican, tout comme la gestion du panneau et de ses nœuds eux-mêmes. Provibr couvre la vie d’un serveur et sa console, pas l’administration de votre panneau.