Vendre de l’hébergement avec CloudPanel

CloudPanel est le panneau que l’on installe quand on veut un site qui tourne vite et rien d’autre dans le chemin. Il est gratuit, il se pose en quelques minutes sur une instance cloud neuve, et ce qui en sort est une pile NGINX et PHP-FPM sans fioritures, avec Let's Encrypt, une base de données et une intégration Cloudflare. Pas de serveur de courrier. Aucune couche que vous n’avez pas demandée.

Cette concentration est exactement ce qui plaît, et c’est aussi pourquoi vendre de l’hébergement dessus est un exercice différent de DirectAdmin ou cPanel. CloudPanel gère des sites sur un serveur. Il ne gère pas des clients qui vous paient. Ce ne sont pas les mêmes problèmes, et c’est de la distance entre les deux que parle cette page.

Ce autour de quoi CloudPanel est réellement bâti

Un serveur, et les sites qui s’y trouvent.

Vous créez un site (PHP, statique, Node.js, Python ou reverse proxy) et CloudPanel écrit un vhost NGINX, un pool PHP-FPM, un utilisateur Linux de site et un répertoire personnel. Vous placez une base de données à côté. Vous y pointez un certificat. Voilà la boucle, et elle est bonne : un développeur ou une agence qui fait tourner vingt sites sur une machine obtient une interface propre sur exactement ce qu’il manipule.

Ce qu’il n’a pas, c’est la couche au-dessus : un client qui possède un ensemble de sites, avec une formule, un quota et un interrupteur. CloudPanel a des utilisateurs de panneau avec des rôles (administrateur, gestionnaire de site, utilisateur), et ces utilisateurs peuvent être restreints à certains sites. Mais c’est du contrôle d’accès pour des gens qui se connectent, pas un compte commercial que vous pouvez facturer et couper.

La distinction paraît théorique jusqu’au jour où le premier client cesse de payer.

Toute la surface de commande tient dans un outil en ligne de commande

CloudPanel n’a pas d’API REST. Tout ce que l’automatisation peut faire, elle le fait via clpctl, l’outil en ligne de commande du panneau, qui tourne en root sur l’hôte. Il se scripte correctement (non interactif, des options plutôt que des questions) et il couvre ce à quoi vous vous attendez :

Deux choses dans ce tableau méritent l’attention avant de planifier quoi que ce soit autour.

La première : l’identité d’un site est son nom de domaine. Pas un identifiant numérique, pas un nom de compte : le domaine. Tout ce que vous bâtissez s’y accroche, et cela doit survivre à un client qui veut déplacer un domaine d’une formule à une autre.

La seconde pèse plus lourd, et c’est l’objet de la section suivante : il n’y a dans ce tableau aucun verbe pour éteindre un site.

Les trois lacunes qui comptent quand vous vendez

Il n’y a pas de suspension

clpctl a site:add:* et il a site:delete. Entre les deux, il n’a rien. Pas de site:suspend, pas de site:disable, pas d’interrupteur de maintenance. Et l’interface du panneau n’a pas davantage d’équivalent.

Pour une activité d’hébergement, ce n’est pas une lacune cosmétique, car « la facture a trente jours de retard » est de loin la situation la plus fréquente sur laquelle vous devrez agir, et supprimer le site n’est pas la réponse. Supprimer est irréversible et emporte les données du client ; un client qui paie le trente et unième jour s’attend à retrouver son site là où il l’a laissé.

Tout ce qui vend de l’hébergement CloudPanel doit donc inventer la suspension. Les candidats habituels sont d’arrêter le pool PHP-FPM du site, ou de modifier le vhost pour que le site cesse de répondre. Les deux fonctionnent, et le second est le meilleur des deux : un pool arrêté produit un 502, ce qui, pour votre client, ressemble à un serveur en panne plutôt qu’à une facture en retard.

Bien modifier un vhost tient en une liste plus courte qu’il n’y paraît. Encadrez ce que vous insérez par un commentaire de début et un commentaire de fin, pour que la reprise supprime exactement ces lignes et rien d’autre. Faites-le dans chaque bloc server public, car un vhost en a généralement un pour le port 80 et un pour le 443. Et un site suspendu en HTTP mais sain en HTTPS est pire qu’un site non suspendu, car cela ressemble à une réussite. Lancez nginx -t avant de recharger, car il s’agit d’un serveur web mutualisé et une configuration cassée emporte avec elle tous les sites qui s’y trouvent. Faites ces trois choses et la suspension devient une action ordinaire, immédiate et entièrement réversible. Provibr fait exactement cela : un return 403; marqué, chaque bloc public, testé avant le rechargement.

Ce qu’aucun montage ne règle : le panneau l’ignore. CloudPanel n’a pas la notion de site suspendu, il en affiche donc un comme ordinaire, et quiconque a accès au panneau ou à l’hôte peut ouvrir le fichier et retirer la ligne, y compris le client que vous venez de suspendre. Vous pouvez rendre l’état lisible (la marque est à un grep de distance, c’est ainsi que Provibr repère une modification manuelle) mais vous ne pouvez pas en faire la propriété de CloudPanel.

Décidez de ce que « éteint » veut dire avant le premier client, pas après le premier impayé.

Il n’y a pas de paquets

CloudPanel n’a ni formules, ni quotas, ni limites par site. Pas de quota disque, pas de plafond de bande passante, pas de « ce site a droit à trois bases de données ». Ce qui s’en rapproche le plus est un modèle de vhost, c’est-à-dire une configuration NGINX : utile, mais ce n’est pas une limite, et cela n’arrêtera personne qui consomme 400 Go.

Autrement dit, votre catalogue produit ne peut pas vivre dans le panneau. Ce qui sépare votre formule à 5 € de celle à 15 € doit être défini, appliqué et mesuré quelque part au-dessus de CloudPanel. Si ce n’est appliqué nulle part, ce n’est pas une formule. C’est une suggestion.

Il n’y a pas de liste des sites

Il y a user:list pour les identifiants du panneau. Il n’y a pas de site:list. Les sites eux-mêmes vivent dans la base SQLite du panneau, sur l’hôte.

1

L’issue est de lire cette base directement : /home/clp/htdocs/app/data/db.sq3, un select sur la table site, et vous avez chaque domaine avec son utilisateur, son modèle et sa version de PHP. C’est ce que fait Provibr, et ce à quoi tout ce qui est sérieux finit par aboutir. Sachez seulement que vous lisez un schéma interne et non une interface : il peut changer dans une version sans que ce soit une promesse rompue, cela figure donc sur la liste des choses à revérifier après une mise à jour du panneau.

Et une contrainte de conception sous tout cela

clpctl tourne en root sur l’hôte. Ce n’est pas un détail d’implémentation que l’on contourne : il écrit de la configuration NGINX, crée des utilisateurs Linux et gère des services système, et cela demande ces privilèges.

La conséquence, c’est qu’automatiser CloudPanel est une question de privilèges avant d’être une question d’intégration. Tout ce qui pilote clpctl (votre propre script, une tâche planifiée, un outil de déploiement) tourne en root sur un serveur web de production qui porte les sites d’autres personnes. Quoi que vous construisiez, construisez-le en sachant que l’identifiant en jeu n’est pas un jeton d’API à portée limitée ; c’est un accès administratif à la machine. Gardez-le étroit, gardez-le traçable, et gardez-le loin de tout ce qu’un client peut atteindre.

Ce qui doit exister au-dessus du panneau

Retirez ce qui est propre au panneau et la liste est la même pour n’importe quel panneau de contrôle, et c’est là qu’elle devient utile : elle ne change pas si vous changez de panneau plus tard.

• Un formulaire de commande et un catalogue, avec des formules qui veulent dire quelque chose d’applicable.
• Un paiement qui déclenche le provisionnement en quelques secondes, pas dans la journée.
• Un parcours de relance (en retard, averti, suspendu, rétabli) avec une action définie à chaque étape.
• Une capacité visible, pour savoir combien de comptes vous portez et ce qu’ils vous coûtent avant que la facture ne vous le dise.
• Un journal d’activité, pour que « qui a supprimé ce site » ait une réponse.
• Un modèle de droits pour les personnes qui travaillent avec vous, afin que le support puisse redémarrer quelque chose sans pouvoir tout supprimer.

Rien de tout cela ne vient avec CloudPanel, et rien de tout cela n’est ce que CloudPanel cherche à être.

Où Provibr s’insère

La prise en charge de CloudPanel est en service. Un agent dans votre propre réseau se connecte à l’hôte en SSH et exécute clpctl comme on le ferait à la main, si bien que rien n’est installé sur le panneau et qu’aucun port n’a à être exposé. Créer un site, le suspendre, le réactiver et le supprimer fonctionne, et les sites déjà présents ne sont importés que si vous les cochez. Autour se trouve la couche décrite plus haut : des formules et de la capacité, un prix unitaire dégressif, un modèle de droits, un journal d’activité, ainsi qu’une API REST et un module WHMCS pour le piloter depuis ce avec quoi vous facturez déjà.

Ce que l’intégration ne peut pas faire, c’est effacer les lacunes ci-dessus, car ce sont des propriétés du panneau. La suspension est la partie inventée : une règle NGINX balisée qui renvoie 403, insérée dans chaque bloc serveur public et vérifiée avant le rechargement ; la réactivation la retire et le site revient octet pour octet. Le modèle de vhost est figé dès que le site existe, il n’y a donc pas de changement de formule : passer à un autre modèle ou à une autre version de PHP suppose de le recréer, et Provibr le dit plutôt que de faire semblant qu’un changement a eu lieu. Il n’y a pas non plus de console ni de graphique de consommation, parce que CloudPanel ne mesure ni l’une ni l’autre.

Ce que cela ne fera pas

Autant le dire maintenant plutôt que plus tard : gérer des comptes n’est pas gérer le panneau. Installer CloudPanel, le mettre à jour, changer des réglages serveur, régler NGINX et s’occuper des bases de données et des certificats que vos clients créent : cela reste de votre côté, dans le panneau, là où c’est sa place.

Vous n’êtes pas obligé de jouer votre activité sur un seul panneau. Provibr fait tourner côte à côte ses panneaux de contrôle, ses hyperviseurs et ses panneaux de jeu, avec un seul inventaire, un seul modèle de droits et un seul journal d’activité. Un panneau NGINX léger pour les clients qui veulent de la vitesse sur une machine, autre chose avec un arbre de revendeurs pour ceux qui réclament cPanel, et un endroit unique où vous voyez les deux.