Automatiser la facturation CloudPanel

Un produit d’hébergement automatisé compte exactement trois moments où l’argent et les machines se touchent :

1. 01La commande est payée : le site doit exister en quelques secondes, correctement configuré.
2. 02La facture est en retard : le site doit s’éteindre, et revenir dès qu’il est payé.
3. 03L’abonnement se termine : le site doit disparaître, vraiment, données comprises.

CloudPanel a une commande nette pour le premier moment et une commande nette pour le troisième. Pour le deuxième, il n’a rien du tout. Ce n’est pas une petite note de bas de page sous une intégration par ailleurs ordinaire ; c’est le fait déterminant de l’automatisation de la facturation sur ce panneau, et cela mérite le milieu de cette page plutôt qu’une ligne à la fin.

Les trois moments, et ce que CloudPanel propose

Tout passe par clpctl, l’outil en ligne de commande du panneau. Il n’y a pas d’API REST : CloudPanel est un panneau rendu côté serveur plus une CLI, et l’automatisation passe par cette CLI ou ne passe pas.

Les deux commandes qui existent sont de bonnes commandes. site:add:php prend le domaine, la version de PHP, un modèle de vhost et l’utilisateur Linux du site avec son mot de passe, puis rend la main une fois le vhost, le pool et le répertoire personnel écrits. site:delete --force est une vraie suppression, pas une suppression douce. Entre les deux se trouve le vide.

Le vide au milieu, et comment il se comble

La suspension est l’action qu’un système de facturation exécute plus que toute autre, car c’est celle qui tourne sans surveillance, selon un calendrier, contre des comptes que personne ne regarde. C’est aussi le seul levier réversible dont vous disposez entre « continuer à les héberger gratuitement » et « supprimer leur activité ».

CloudPanel n’a pas de mot pour cela. Pas de site:suspend, pas de site:disable, pas d’indicateur de maintenance dans le panneau, et aucun statut par site que vous pourriez basculer. Si vous vendez de l’hébergement CloudPanel, la suspension est donc quelque chose que vous construisez. Les options réalistes, avec leur coût honnête :

Arrêter le pool PHP-FPM du site. Rapide, réversible, et cela arrête réellement le service. Cela produit en revanche un 502 plutôt qu’une explication : votre client voit un site cassé et non un compte suspendu. Et c’est une opération systemd sur l’hôte, pas une opération clpctl ; c’est donc à vous de la maintenir au fil des mises à jour du panneau.

Modifier le vhost. La configuration NGINX du site est un fichier sur l’hôte, et une seule ligne décide si le site répond. Réversible, immédiat, et cela ne coûte au client que l’accès. Le piège : vous écrivez dans un fichier que CloudPanel possède, donc la manière dont vous y écrivez compte énormément.

Supprimer, après une sauvegarde. Sans ambiguïté, et définitif d’une manière qui finira par vous coûter un client qui paie le trente et unième jour. Restaurer n’est pas un interrupteur, avec tout ce que cela implique pour le DNS, les certificats et le courrier que vous devrez envoyer ensuite.

Il n’existe pas de quatrième option propre. Ce qui compte, c’est d’en choisir une délibérément et de vous assurer que la personne qui répond au téléphone sait laquelle. Le mode de défaillance n’est pas technique ici : c’est un agent de support qui promet à un client que son site revient tout de suite, sur un système où revenir signifie restaurer une sauvegarde.

À quoi ressemble une modification de vhost soignée

La deuxième option est celle qui mérite d’être faite correctement, et « correctement » tient en une courte liste. C’est ainsi que Provibr procède, et le raisonnement vaut que vous utilisiez Provibr ou que vous l’écriviez vous-même.

Marquez ce que vous insérez. La suspension est un return 403; entre un commentaire de début et un commentaire de fin. Retirer revient à supprimer exactement les lignes entre les deux. La reprise laisse donc le fichier octet pour octet tel qu’il était, et un return 403; que le client a mis pour ses propres raisons reste intact. Un chercher-remplacer sur return 403 n’aurait pas cette propriété.

Chaque bloc server public, pas le premier. Un vhost a généralement un bloc pour le port 80 et un pour le 443. N’écrivez que dans l’un et vous obtenez un site suspendu en HTTP et parfaitement sain en HTTPS. C’est pire que pas de suspension du tout, car cela ressemble à une réussite.

Testez la configuration avant de recharger. nginx -t passe en premier. Une suspension qui met par terre tous les autres sites de la machine n’est pas une suspension, et il s’agit par conception d’un serveur web mutualisé.

Rendez l’état lisible depuis l’hôte. Comme la marque est un commentaire dans un fichier, les sites suspendus sont à un grep de distance, et l’agent relit cela plutôt que de croire sa propre base. Si quelqu’un modifie le fichier à la main, cela se voit au passage suivant.

Ce que rien de tout cela ne change : CloudPanel lui-même ne connaît toujours pas la notion de site suspendu. Le panneau l’affiche comme un site ordinaire, car de son point de vue c’en est un. Quiconque a accès à CloudPanel, y compris le client que vous venez de suspendre, peut ouvrir ce fichier et retirer la ligne. L’état est lisible et il est appliqué au serveur web, mais il n’appartient pas au panneau, et aucun montage sur ce panneau ne peut y changer quoi que ce soit.

Il n’y a pas non plus de chemin de montée en gamme, car il n’y a pas de paquets

CloudPanel n’a ni formules, ni quotas, ni limites par site. Cela retire un moment entier de la liste ci-dessus : il n’y a pas d’appel « changer de paquet », parce qu’il n’y a pas de paquet.

Cela veut dire aussi que la différence entre vos formules doit être réelle ailleurs. Si votre formule à 5 € et celle à 15 € atterrissent sur le même CloudPanel avec partout la même chose, alors ce que votre client a acheté est un prix, et le premier qui s’en aperçoit le dira aux autres. L’application des limites vit au-dessus du panneau : des hôtes distincts par palier, des quotas au niveau du système de fichiers, ou des limites que votre propre plateforme applique et compte.

Le rapprochement demande une liste, et il n’y en a pas

clpctl sait lister les utilisateurs du panneau. Il ne sait pas lister les sites : ceux-ci vivent dans la base SQLite du panneau, sur l’hôte.

Pour la facturation, c’est un vrai trou, car un système de facturation devrait pouvoir poser deux questions à tout moment : est-ce que tout ce que je facture existe encore ? et y a-t-il ici quelque chose que je ne facture pas ? On répond aux deux en comparant ses propres registres à une liste de ce qui se trouve réellement sur la machine. Sans liste, vous apprenez l’existence d’un site supprimé à la main quand le client écrit, et celle d’un site créé à la main jamais.

Quoi que vous bâtissiez au-dessus de CloudPanel, cela devra tirer cette liste d’ailleurs, et il faudra un accès à l’hôte pour le faire. En pratique il n’existe qu’un seul endroit : la base de données du panneau lui-même, /home/clp/htdocs/app/data/db.sq3, où un simple select sur la table site vous donne d’un coup le domaine, l’utilisateur Linux, le type, le modèle de vhost et la version de PHP. Provibr la lit là.

Cela fonctionne, et il vaut la peine d’être clair sur ce que vous acceptez en le faisant. Ce schéma est l’affaire interne de CloudPanel, pas une interface publiée : il peut changer dans une version sans que personne n’ait rompu de promesse. Le lire est le bon choix (un système de facturation sans réconciliation est pire), mais cela figure sur la courte liste des choses à revérifier après une mise à jour du panneau, à côté des formats de sortie de clpctl.

L’identifiant n’est pas un jeton d’API

Cela mérite d’être dit franchement, car c’est la plus grande différence pratique entre automatiser CloudPanel et automatiser un panneau doté d’une API REST.

clpctl tourne en root. Il écrit de la configuration NGINX, crée des utilisateurs Linux et gère des services : root n’est pas un oubli, c’est le travail. Ce qui le pilote détient donc un accès administratif à un serveur web de production qui porte les sites d’autres personnes, et non un jeton à portée limitée qui ne toucherait qu’une seule surface d’API.

Deux conséquences pour qui branche de la facturation là-dessus. L’étendue des dégâts n’est pas la même : un jeton d’API de panneau qui fuit permet de créer et supprimer des comptes, tandis qu’un identifiant shell qui fuit sur le serveur web est une autre conversation, avec d’autres obligations. Et le moindre privilège est votre propre travail : il n’y a pas de case à cocher sur laquelle s’appuyer, donc le cloisonnement se conçoit au lieu de se configurer.

Où se trouve réellement la facture

Cela vaut la peine d’être explicite, car c’est le malentendu le plus courant : Provibr ne facture pas vos clients. Il ne leur envoie rien, ne les relance pas, et ignore ce que vous leur facturez. Cette relation est la vôtre.

Ce que Provibr facture, c’est la capacité que vous réservez : combien de comptes d’hébergement vous pouvez faire tourner en même temps, par mois, à un prix unitaire dégressif. Ce que vous facturez à vos propres clients, et comment, reste entièrement dans votre propre système de facturation.

Il y a deux façons de relier les deux moitiés.

Un module WHMCS. Si vous faites déjà tourner WHMCS, installez le module de provisionnement Provibr et faites pointer un produit WHMCS vers une formule d’hébergement web Provibr. Votre client garde un compte, une facture et un identifiant. Le module est une simple archive zip que vous installez vous-même et qui tourne dans votre WHMCS : rien n’est à activer de notre côté.

L’API REST. Si vous faites tourner FOSSBilling, Blesta, quelque chose de maison, ou un tableur et une tâche planifiée, pilotez-le directement. Une clé, une URL de base, et exactement les droits que possède déjà le membre derrière cette clé.

La seule règle pour le piloter depuis votre propre code

Tout ce qui touche une machine est asynchrone, et cela doit l’être. Votre infrastructure n’est joignable que par l’agent qui se trouve dans votre propre réseau, et cet agent se connecte vers l’extérieur. Un point d’accès qui modifie un compte ne peut donc pas répondre avec le résultat : il répond que la demande est acceptée et vous remet une commande à suivre, que vous lisez jusqu’à ce que son statut soit définitif (terminée, échouée, expirée ou annulée).

La lecture ne fonctionne jamais ainsi. Un inventaire, une adresse ou une facture répond immédiatement, car cette réponse vient d’une base de données et non de votre hôte.

La conséquence pratique pour un déclencheur de facturation : ne marquez pas la commande comme terminée sur la réponse « acceptée ». La première réponse que vous obtenez dit « nous l’avons envoyée », pas « cela a marché ».

Suspendre, c’est aussi maîtriser vos propres coûts

Un lien facile à manquer, et la raison pour laquelle le milieu manquant ci-dessus coûte de l’argent autant que de la bonne volonté. Dans Provibr, un serveur suspendu ne compte pas dans la capacité que vous payez. Pour un compte d’hébergement, il n’existe pas d’état « arrêté » : il y a actif et suspendu.

Sur un panneau où la suspension est une action réelle et prise en charge, l’étape de relance que vous vouliez de toute façon pour des raisons commerciales libère donc aussi la place que vous payez. Sur un panneau qui n’en a pas, chaque compte impayé que vous n’avez pas encore décidé de supprimer est de la capacité que vous continuez de porter. C’est un argument pour fixer tôt votre règle de suspension, et pour l’écrire.

Tout ce qui précède à propos du panneau est une propriété de CloudPanel et non la description d’une intégration, et c’est délibéré : les lacunes sont réelles et il ne nous appartient pas de les faire disparaître par la pensée. Ce qu’une intégration peut faire, en revanche, c’est choisir avec soin laquelle des trois options elle prend, et dire tout haut ce que ce choix ne règle toujours pas.

Si vous vendez aussi des VPS, des serveurs de jeu ou des comptes cPanel, les mêmes trois moments s’y appliquent, et ils peuvent vivre dans un seul inventaire. Provibr fait tourner aujourd’hui ses panneaux de contrôle, ses hyperviseurs et ses panneaux de jeu côte à côte, avec un seul modèle de droits et un seul journal d’activité sur l’ensemble.