Intégrations

Chaque fournisseur est décrit à un seul endroit : la catégorie à laquelle il appartient, le type de ressource qu’il produit, les identifiants dont il a besoin et celles des sept capacités qu’il possède. Le panneau, la plateforme et l’agent lisent tous cette même description. Rien dans le produit ne demande si un système se trouve être Proxmox.

C’est pourquoi les onglets d’une intégration diffèrent selon le fournisseur. Un onglet de test existe parce que le fournisseur déclare un test de connexion ; un onglet des systèmes d’exploitation existe parce que le fournisseur peut détenir des modèles ; un onglet d’import existe parce que le fournisseur peut lister ce qu’il fait déjà tourner. Un onglet absent est une capacité absente, pas une page qui n’a pas réussi à se charger.

Hyperviseur

Fait tourner des machines virtuelles et livre la machine entière : cœurs, mémoire, disque, réseau. La page des intégrations indique quels hyperviseurs sont disponibles et lesquels sont sur la feuille de route.

Panneau de contrôle

Fait tourner des comptes d’hébergement web sur une machine déjà en marche. Il crée un compte doté d’un forfait, pas d’un système d’exploitation. La page des intégrations étiquette chaque panneau de contrôle disponible ou sur la feuille de route.

Panneau de jeu

Fait tourner des conteneurs de serveurs de jeu, construits à partir d’une recette plutôt que d’une image de système d’exploitation. Cette catégorie est placée à côté des panneaux de contrôle et non à l’intérieur, car presque rien n’est identique entre les deux. La page des intégrations montre les panneaux de jeu qui sont disponibles.

Dédié

Machines physiques, installées par le réseau et pilotées hors bande. Annoncé mais pas développé.

Réseau

Commutateurs et routeurs. Annoncé mais pas développé, et cette catégorie n’apparaît pas du tout sur la page des intégrations, car les équipements réseau ont leurs propres écrans et ne comptent pas comme une ressource.

Sept capacités déterminent ce qui apparaît et ce que la plateforme accepte d’envoyer. Une commande qui exige une capacité dont le fournisseur ne dispose pas est refusée avant d’atteindre votre agent, avec le motif indiqué.

• Console : un écran ou un terminal en direct sur la ressource.
• Pare-feu : la plateforme peut imposer les adresses qu’une ressource a le droit d’utiliser.
• Règles de pare-feu : une liste de règles ordonnée que vous modifiez vous-même, ainsi que le journal du pare-feu.
• Matériel : des disques et des cartes réseau que vous pouvez ajouter, redimensionner et supprimer.
• Mesures : des relevés d’utilisation, et donc des graphiques.
• Systèmes d’exploitation : des modèles ou des images à partir desquels la plateforme peut installer.
• Attribution d’adresses : Provibr décide quelle adresse reçoit la ressource.

Ajouter une intégration prend trois étapes : le type de système, la connexion et les identifiants. Une catégorie derrière laquelle rien n’est développé est visible mais non sélectionnable : vous voyez ce qui arrive sans pouvoir le choisir.

• Vous choisissez un agent en même temps qu’un fournisseur. C’est cet agent qui joindra le système : il doit donc se trouver sur un réseau qui le permet.
• Le nom vous appartient. C’est un libellé dans le panneau et rien d’autre ne le lit.
• Les identifiants sont validés selon les mêmes règles que celles de l’agent, puis envoyés à cet agent et scellés dans son coffre. Vous restez sur la page jusqu’à ce que l’agent réponde.
• Si l’agent les refuse, le motif est affiché et les valeurs que vous avez saisies restent en place : une simple faute de frappe ne vous coûte pas tout le formulaire.

Les identifiants ne sont jamais écrits dans la base de données de la plateforme. Ce qui est conservé, c’est le nom des champs que vous avez renseignés ainsi que l’hôte et le port, pour que le panneau ait quelque chose à vous montrer et la piste d’audit quelque chose à désigner.

Sur l’hôte, ils sont chiffrés avec une clé mêlée à l’identité de cette machine. Copier le coffre et sa clé sur une autre machine ne donne rien. Cela ne protège pas contre root sur votre propre hôte. Cet hôte est le vôtre, et les identifiants aussi.

Chaque fournisseur qui parle HTTPS propose un champ d’empreinte. Renseignez-le et l’agent n’acceptera que le certificat exact que vous avez épinglé : c’est ce qui rend sûr l’usage d’un certificat auto-signé sur votre propre nœud. Relevez l’empreinte depuis l’hôte de l’agent, afin d’épingler ce que l’agent verra réellement :

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

« Active » signifie seulement que l’agent a accepté vos identifiants. Cela ne veut pas dire que l’intégration est prête à livrer des machines. La liste au-dessus des onglets montre ce qui manque encore et renvoie directement à l’endroit voulu.

• Identifiants : transmis à l’agent et acceptés.
• Paramètres : les choix non secrets dont le fournisseur a besoin, comme le nœud et la plage d’identifiants de machines. Un fournisseur qui n’a rien à choisir saute cette étape au lieu de l’afficher comme non faite.
• Méthode d’installation : selon que les machines sont clonées depuis un modèle ou installées par le réseau.
• Systèmes d’exploitation : au moins une image associée, pour la méthode que vous avez choisie.

Le bouton de test met en file un véritable appel vers votre système, exécuté par votre agent, et affiche ce qui en revient. Ce qu’il rapporte diffère selon le fournisseur, car ce qu’un test de connexion peut dire d’utile découle de l’API du produit concerné.

• Proxmox : la version et la liste des nœuds avec leur statut en ligne.
• DirectAdmin : la version du panneau, le nombre de comptes, le nombre de commandes que votre clé de connexion a le droit d’exécuter, et si la connexion est chiffrée. Ce dernier point, seul votre agent peut le déterminer.
• Webmin : si le module Virtualmin répond, combien de comptes d’hébergement et de forfaits existent, et si le certificat correspond à l’empreinte saisie.
• Pterodactyl : le nombre de nœuds et de serveurs de jeu, et si la clé client fonctionne. Sans elle, il n’y a ni contrôle de l’alimentation ni console, et vous voulez le savoir avant votre premier bouton de démarrage plutôt qu’après.

La désactivation est l’étape intermédiaire prudente : l’agent cesse de recevoir des commandes pour cette intégration et tout reste en place. La réactivation la remet à l’état actif si les identifiants avaient déjà été acceptés, et en attente d’identifiants sinon, car seul un test peut vous dire s’ils fonctionnent encore.

L’agent signale un code accompagné de paramètres, pas une phrase, pour que le panneau puisse vous montrer le motif dans votre langue. Lorsque l’autre partie a dit quelque chose elle-même (un corps de réponse HTTP de votre hyperviseur, une erreur de votre panneau), c’est cité en dessous, sans traduction, parce que c’est une citation.

Il existe un second canal pour les cas « réussi, mais ». Un panneau qui fonctionne sur une connexion non chiffrée n’est pas un échec, et ce n’est pas non plus un statut : cela apparaît donc comme un avertissement dans l’onglet Aperçu tant que votre agent continue de le signaler.