Automatizzare la fatturazione e il provisioning CloudPanel

Un prodotto di hosting automatizzato ha esattamente tre momenti in cui il denaro e le macchine si toccano:

1. 01L’ordine viene pagato. Il sito deve esistere, configurato correttamente, nel giro di pochi secondi.
2. 02La fattura è scaduta. Il sito deve spegnersi e tornare nel momento in cui viene pagata.
3. 03L’abbonamento termina. Il sito deve essere rimosso, davvero, dati compresi.

CloudPanel ha un comando netto per il primo momento e un comando netto per il terzo. Per il secondo non ha proprio nulla. Non è una piccola nota a piè di pagina sotto un’integrazione per il resto ordinaria; è il fatto determinante dell’automazione della fatturazione su questo pannello, e merita il centro di questa pagina anziché una riga in fondo.

I tre momenti, e ciò che CloudPanel offre

Tutto passa per clpctl, lo strumento a riga di comando del pannello. Non esiste un’API REST: CloudPanel è un pannello reso lato server più una CLI, e l’automazione passa per questa CLI o non passa.

I due comandi che esistono sono buoni comandi. site:add:php prende il dominio, la versione di PHP, un modello di vhost e l’utente Linux del sito con la sua password, e restituisce il controllo dopo aver scritto il vhost, il pool e la home directory. site:delete --force è una vera eliminazione, non una soft. Tra i due sta la lacuna.

Il centro mancante, e come si riempie

La sospensione è l’azione che un sistema di fatturazione esegue più di ogni altra, perché è quella che gira senza sorveglianza, secondo un calendario, contro account che nessuno guarda. È anche l’unica leva reversibile che ha tra «continuare a ospitarli gratis» e «eliminare la loro attività».

CloudPanel non ha una parola per questo. Non esiste site:suspend, non esiste site:disable, non c’è alcun indicatore di manutenzione nel pannello, e nessuno stato per sito che si possa commutare. Quindi, se vende hosting CloudPanel, la sospensione è qualcosa che costruisce Lei. Le opzioni realistiche, con il loro costo onesto:

Arrestare il pool PHP-FPM del sito. Veloce, reversibile, e ferma davvero l’erogazione del sito. Produce però un 502 anziché una spiegazione, quindi il suo cliente vede un sito web rotto anziché un account sospeso. Ed è un’operazione systemd sull’host, non una di clpctl, quindi tocca a Lei mantenerla funzionante attraverso gli aggiornamenti del pannello.

Modificare il vhost. La configurazione NGINX del sito è un file sull’host, e una sola riga al suo interno decide se il sito risponde. Reversibile, immediato, e non costa al cliente nulla se non l’accesso. L’inconveniente è che si scrive in un file che appartiene a CloudPanel, quindi conta moltissimo come ci si scrive.

Eliminare, previa una copia di sicurezza. Senza ambiguità, e definitivo in un modo che prima o poi le costerà un cliente che paga il trentunesimo giorno. Il ripristino non è un interruttore, con tutto ciò che questo implica per il DNS, i certificati e la mail che dovrà inviare dopo.

Non esiste una quarta opzione pulita. Ciò che conta è sceglierne una deliberatamente e assicurarsi che la persona che risponde al telefono sappia quale sia. Qui il modo di guasto non è tecnico: è un addetto al supporto che promette a un cliente che il suo sito tornerà subito, su un sistema in cui tornare significa ripristinare una copia di sicurezza.

Che aspetto ha una modifica accurata del vhost

La seconda opzione è quella che vale la pena fare per bene, e «per bene» è un elenco breve. È così che fa Provibr, e il ragionamento vale sia che usi Provibr sia che lo scriva da sé.

Contrassegni ciò che inserisce. La sospensione è un return 403; racchiuso tra un commento di inizio e uno di fine. Rimuoverla significa eliminare esattamente le righe tra quei marcatori, così la riattivazione lascia il file byte per byte com’era, e un return 403; che il cliente ha messo per ragioni proprie sopravvive intatto. Un cerca-e-sostituisci su return 403 non avrebbe questa proprietà.

Ogni blocco server pubblico, non il primo. Un vhost ha di solito un blocco per la porta 80 e uno per la 443. Iniettando in uno solo si ottiene un sito sospeso su HTTP e uno perfettamente sano su HTTPS, il che è peggio che non sospendere affatto, perché sembra aver funzionato.

Verifichi la configurazione prima di ricaricarla. nginx -t viene eseguito per primo. Una sospensione che manda giù ogni altro sito sulla macchina non è una sospensione, e questo è per progettazione un server web condiviso.

Renda lo stato leggibile dall’host. Poiché il marcatore è un commento in un file, i siti sospesi sono a un grep di distanza e l’agente li rilegge invece di fidarsi del proprio database. Se qualcuno modifica il file a mano, il giro di polling successivo se ne accorge.

Ciò che nulla di tutto questo cambia: CloudPanel stesso continua a non avere alcuna nozione di sito sospeso. Il pannello lo mostra come un sito ordinario, perché dal punto di vista del pannello lo è. Chiunque abbia accesso a CloudPanel, incluso il cliente che ha appena sospeso, può aprire quel file e togliere la riga. Lo stato è leggibile ed è applicato al server web, ma non appartiene al pannello, e nessuna costruzione su questo pannello può cambiarlo.

Non c’è nemmeno un percorso di upgrade, perché non ci sono pacchetti

CloudPanel non ha piani, né quote, né limiti per sito. Questo rimuove un intero momento dalla lista qui sopra: non esiste una chiamata «cambia pacchetto», perché non esiste un pacchetto.

Significa anche che la differenza tra i suoi piani deve essere reale da qualche altra parte. Se il suo piano da 5 € e quello da 15 € atterrano sullo stesso CloudPanel con tutto uguale, allora ciò che il suo cliente ha comprato è un prezzo, e il primo che se ne accorge lo dirà agli altri. L’applicazione dei limiti vive al di sopra del pannello: host separati per fascia, quote a livello di file system, o limiti che la sua stessa piattaforma applica e conta.

La riconciliazione richiede un elenco, e non ce n’è uno

clpctl sa elencare gli utenti del pannello. Non sa elencare i siti: questi vivono nel database SQLite del pannello stesso, sull’host.

Per la fatturazione è un vero buco, perché un sistema di fatturazione dovrebbe poter porre due domande in qualsiasi momento: tutto ciò che addebito esiste ancora? e c’è qui qualcosa che non addebito? A entrambe si risponde confrontando i propri registri con un elenco di ciò che si trova davvero sulla macchina. Senza un elenco, si viene a sapere di un sito eliminato a mano quando il cliente scrive, e di uno creato a mano mai.

Qualunque cosa costruisca sopra CloudPanel deve procurarsi quell’elenco da un luogo diverso da clpctl, e per farlo servirà l’accesso all’host. In pratica esiste esattamente un posto: il database del pannello stesso, /home/clp/htdocs/app/data/db.sq3, dove un semplice select sulla tabella site fornisce in un colpo solo il dominio, l’utente Linux, il tipo, il modello di vhost e la versione di PHP. Provibr lo legge lì.

Funziona, e vale la pena essere chiari su ciò che si accetta facendolo. Quello schema è affare interno di CloudPanel, non un’interfaccia pubblicata, quindi può cambiare in una versione senza che nessuno abbia infranto una promessa. Leggerlo è la scelta giusta (un sistema di fatturazione senza riconciliazione è peggio), ma rientra nel breve elenco delle cose da riverificare dopo un aggiornamento del pannello, accanto ai formati di output di clpctl.

La credenziale non è un token API

Vale la pena dirlo senza giri di parole, perché è la più grande differenza pratica tra automatizzare CloudPanel e automatizzare un pannello dotato di un’API REST.

clpctl gira come root. Scrive configurazione NGINX, crea utenti Linux e gestisce servizi, quindi root non è una svista: è il lavoro. Qualsiasi cosa lo piloti detiene perciò un accesso amministrativo a un server web di produzione che porta i siti di altre persone, non un token con ambito limitato a una sola superficie di API.

Due conseguenze per chi collega la fatturazione a questo. L’estensione del danno è diversa: un token API del pannello trapelato permette a qualcuno di creare ed eliminare account, mentre una credenziale shell trapelata sul server web è un altro discorso, con un altro insieme di obblighi. E il privilegio minimo è lavoro suo: non c’è una casella dei permessi su cui appoggiarsi, quindi la delimitazione è qualcosa che si progetta invece di configurarla.

Dove vive davvero la fattura

Vale la pena dirlo esplicitamente, perché è il malinteso più comune: Provibr non fattura ai suoi clienti. Non invia loro una fattura, non li sollecita e non sa quanto vengono addebitati. Quella relazione è sua.

Ciò che Provibr fattura è la capacità che Lei riserva: quanti account di hosting può far girare contemporaneamente, al mese, a un prezzo unitario a fasce. Ciò che addebita ai suoi clienti, e come, resta interamente all’interno del suo sistema di fatturazione.

Ci sono due modi per collegare le due metà:

Un modulo WHMCS. Se utilizza già WHMCS, installi il modulo di provisioning Provibr e faccia puntare un prodotto WHMCS a un piano web Provibr. Il suo cliente mantiene un account, una fattura e un login. Il modulo è un semplice zip che installa da sé, e gira all’interno del suo WHMCS. Non c’è nulla da attivare dal nostro lato.

L’API REST. Se utilizza FOSSBilling, Blesta, qualcosa di interno, o un foglio di calcolo e un cron job, lo piloti direttamente. Una chiave, un URL di base, ed esattamente le autorizzazioni che il membro dietro la chiave ha già.

L’unica regola per pilotarlo dal proprio codice

Tutto ciò che tocca una macchina è asincrono, e deve esserlo. La sua infrastruttura è raggiungibile solo attraverso l’agente all’interno della sua rete, e quell’agente si connette verso l’esterno. Quindi un endpoint che modifica un account non può rispondere con il risultato. Risponde che l’ordine è stato accettato e le consegna un comando da seguire, che legge finché il suo stato non è definitivo: completato, fallito, scaduto o annullato.

La lettura non funziona mai così. Un inventario, un indirizzo o una fattura risponde immediatamente, perché quella risposta viene da un database e non dal suo host.

La conseguenza pratica per un hook di fatturazione: non segni l’ordine come completato sulla risposta di accettazione. La prima risposta che ottiene dice «l’abbiamo inviato», non «ha funzionato».

La sospensione è anche il controllo dei propri costi

Un collegamento facile da mancare, ed è la ragione per cui il centro mancante qui sopra costa denaro oltre che buona volontà. In Provibr un server sospeso smette di contare nella capacità per cui paga. Per un account di hosting non esiste lo stato «arrestato»: esistono attivo e sospeso.

Quindi il passo di sollecito che voleva comunque per ragioni commerciali libera anche lo slot per cui sta pagando, a patto che la sospensione sia un’azione reale e non una nota nel proprio database. È l’argomento pratico per costruirla anziché lasciare il centro vuoto: un account non pagato che non ha ancora deciso di eliminare è capacità che continua a pagare.

Tutto ciò che precede sul pannello è una proprietà di CloudPanel e non la descrizione di un’integrazione, ed è deliberato: le lacune sono reali e non spetta a noi farle svanire con un desiderio. Ciò che un’integrazione può fare è scegliere con cura quale delle tre opzioni prende, e dire ad alta voce ciò che quella scelta continua a non risolvere.

Se vende anche VPS, server di gioco o account cPanel, gli stessi tre momenti valgono per tutti, e possono vivere in un unico inventario. Provibr fa girare oggi i suoi pannelli di controllo, i suoi hypervisor e i suoi pannelli di gioco fianco a fianco, con un unico set di autorizzazioni e un unico registro di attività su tutto.