Vendere hosting web con CloudPanel

CloudPanel è il pannello che si installa quando si vuole un sito attivo in fretta e nient’altro tra i piedi. È gratuito, si installa su un’istanza cloud nuova in pochi minuti, e ciò che ne esce è un semplice stack NGINX e PHP-FPM con Let's Encrypt, un database e un’integrazione con Cloudflare. Nessun server di posta. Nessuno strato che non ha chiesto.

È proprio questa concentrazione a renderlo apprezzato, ed è anche il motivo per cui venderci hosting è un esercizio diverso rispetto a DirectAdmin o cPanel. CloudPanel gestisce i siti su un solo server. Non gestisce i clienti che La pagano. Non sono lo stesso problema, e la distanza tra i due è l’argomento di questa pagina.

Su cosa è davvero costruito CloudPanel

Un solo server, e i siti che contiene.

Si crea un sito (PHP, statico, Node.js, Python o un reverse proxy) e CloudPanel scrive un vhost NGINX, un pool PHP-FPM, un utente di sistema del sito e una home directory. Si crea un database accanto. Vi si punta un certificato. Questo è il ciclo, ed è un buon ciclo: uno sviluppatore o un’agenzia che gestisce venti siti su una sola macchina ottiene un’interfaccia pulita esattamente sulle cose che tocca.

Ciò che non ha è lo strato al di sopra: un cliente che possiede un insieme di siti, con un piano, una quota e un interruttore. CloudPanel ha utenti del pannello con ruoli (amministratore, gestore del sito, utente), e questi utenti possono essere limitati a siti specifici. Ma è controllo degli accessi per chi effettua l’accesso, non un account commerciale che si può fatturare e disattivare.

La distinzione sembra accademica finché il primo cliente non smette di pagare.

La superficie di controllo è un unico strumento a riga di comando

CloudPanel non ha un’API REST. Tutto ciò che l’automazione può fare, lo fa tramite clpctl, lo strumento a riga di comando del pannello stesso, che gira sull’host come root. È scriptabile per bene (non interattivo, flag anziché prompt) e copre le parti che ci si aspetta:

Due cose in quella tabella meritano attenzione prima di pianificare qualcosa attorno ad essa.

La prima è che l’identità di un sito è il suo nome di dominio. Non un id numerico, non un identificativo di account: il dominio. Tutto ciò che si costruisce si basa su quello, e deve sopravvivere a un cliente che vuole spostare un dominio da un piano all’altro.

La seconda è più rilevante, ed è l’argomento della sezione successiva: in quella tabella non c’è alcun comando per disattivare un sito.

Le tre lacune che contano quando si vende

Non esiste una sospensione

clpctl ha site:add:* e ha site:delete. Non ha nulla nel mezzo. Non esiste site:suspend, non esiste site:disable, non c’è un interruttore di manutenzione, e nemmeno l’interfaccia del pannello ha un equivalente.

Per un’attività di hosting non è una lacuna cosmetica, perché «la fattura è scaduta da trenta giorni» è la cosa più frequente su cui si dovrà mai intervenire, ed eliminare il sito non è la risposta. Eliminare è irreversibile e porta via con sé i dati del cliente; un cliente che paga il trentunesimo giorno si aspetta di ritrovare il proprio sito dove l’aveva lasciato.

Quindi qualsiasi cosa venda hosting CloudPanel deve inventarsi la sospensione. I candidati soliti sono fermare il pool PHP-FPM del sito, oppure modificare il vhost così che il sito smetta di rispondere. Entrambi funzionano, e il secondo è il migliore dei due: un pool fermo produce un 502, che al cliente appare come un server rotto anziché come una fattura scaduta.

Modificare bene un vhost è un elenco più corto di quanto sembri. Racchiuda ciò che inserisce tra commenti di inizio e fine, così che riattivare significhi eliminare esattamente quelle righe e nient’altro. Lo faccia in ogni blocco server pubblico, perché un vhost ne ha di solito uno per la porta 80 e uno per la 443. E un sito sospeso su HTTP ma sano su HTTPS è peggio di uno non sospeso affatto, perché sembra aver funzionato. Esegua nginx -t prima di ricaricare, perché questo è un server web condiviso e una configurazione errata porta giù con sé ogni sito che vi si trova. Faccia queste tre cose e la sospensione diventa un’azione ordinaria, istantanea e del tutto reversibile. Provibr fa esattamente questo: un return 403; contrassegnato, in ogni blocco pubblico, testato prima di ricaricare.

Ciò che nessun accorgimento risolve è che il pannello non lo sa. CloudPanel non ha alcun concetto di sito sospeso, quindi elencherà un sito sospeso come uno qualsiasi, e chiunque abbia accesso al pannello o all’host può aprire il file e togliere la riga, compreso il cliente che ha appena sospeso. Può rendere lo stato leggibile (il contrassegno è a un grep di distanza, ed è così che Provibr si accorge di una modifica manuale) ma non può fare in modo che CloudPanel se ne faccia carico.

Decida cosa significa «spento» prima del primo cliente, non dopo il primo insolvente.

Non esistono i pacchetti

CloudPanel non ha piani, non ha quote e non ha limiti per sito. Nessuna quota di disco, nessun tetto alla banda, nessun «questo sito può avere tre database». La cosa più simile a un pacchetto è un template di vhost, che è una configurazione NGINX: utile, ma non è un limite, e non impedirà a nessuno di usare 400 GB.

Questo significa che il suo catalogo prodotti non può risiedere nel pannello. Qualunque cosa distingua il piano da 5 € da quello da 15 € va definita, applicata e misurata da qualche parte al di sopra di CloudPanel. Se non è applicata da nessuna parte, non è un piano. È un suggerimento.

Non esiste un elenco dei siti

C’è user:list per i login del pannello. Non c’è site:list. I siti stessi risiedono nel database SQLite del pannello, sull’host.

Conta più di quanto sembri, perché un elenco è ciò di cui è fatta la riconciliazione. Senza non si può rispondere a «esiste ancora ciò che sto fatturando?», non si può rilevare un sito che qualcuno ha eliminato a mano, e non si può importare un server esistente in alcunché.

La via d’uscita è leggere quel database direttamente: /home/clp/htdocs/app/data/db.sq3, un select sulla tabella site, e si ha ogni dominio con il suo utente, il template e la versione PHP. È ciò che fa Provibr, ed è ciò che finirà per fare qualsiasi altra soluzione seria. Sappia solo che sta leggendo uno schema interno anziché un’interfaccia: può cambiare in una release senza che questo sia una promessa infranta, quindi finisce nell’elenco delle cose da ricontrollare dopo un aggiornamento del pannello.

E un vincolo di progettazione alla base di tutto

clpctl gira come root sull’host. Non è un dettaglio implementativo che si possa aggirare: scrive configurazioni NGINX, crea utenti Linux e gestisce servizi di sistema, e queste operazioni richiedono i privilegi che richiedono.

La conseguenza è che automatizzare CloudPanel è una questione di privilegi prima ancora che di integrazione. Qualunque cosa piloti clpctl (un suo script, un cron job, uno strumento di deployment) gira come root su un server web di produzione che ospita i siti di altre persone. Qualunque cosa costruisca, la costruisca sapendo che la credenziale in gioco non è un token API con ambito ristretto; è accesso amministrativo alla macchina. La tenga ristretta, la tenga verificabile, e la tenga ben lontana da tutto ciò che un cliente può raggiungere.

Cosa deve esistere al di sopra del pannello

Tolti i dettagli specifici del pannello, l’elenco è lo stesso per qualsiasi pannello di controllo, il che è la parte utile (non cambia se in seguito cambia pannello):

• Un modulo d’ordine e un catalogo, con piani che significano qualcosa di applicabile.
• Un pagamento che avvia il provisioning in pochi secondi, non in una giornata lavorativa.
• Un percorso di sollecito (scaduto, avvisato, sospeso, ripristinato), con un’azione definita a ogni passo.
• Una capacità che si può vedere, così da sapere quanti account si stanno gestendo e quanto costano prima che glielo dica la fattura.
• Un registro di controllo, così che «chi ha eliminato quel sito» abbia una risposta.
• Un modello di permessi per le persone che lavorano per Lei, così che l’assistenza possa riavviare qualcosa senza poter eliminare tutto.

Nulla di tutto ciò arriva con CloudPanel, e nulla di ciò è quello che CloudPanel cerca di essere.

Dove si colloca Provibr

Il supporto per CloudPanel è attivo. Un agente all’interno della sua rete si collega all’host via SSH ed esegue clpctl come lo si farebbe a mano, quindi sul pannello non viene installato nulla e nessuna porta deve essere esposta a internet. Creare un sito, sospenderlo, riattivarlo ed eliminarlo funziona, e i siti già presenti vengono importati solo se li seleziona. Attorno c’è lo strato descritto qui sopra: piani e capacità, un prezzo per unità, un modello di permessi, un registro delle attività, e un’API REST e un modulo WHMCS per pilotarlo da qualunque sistema con cui già fattura.

Ciò che l’integrazione non può fare è cancellare le lacune qui sopra, perché sono proprietà del pannello. La sospensione è la parte inventata: una regola NGINX contrassegnata che restituisce 403, inserita in ogni blocco server pubblico e verificata prima del ricaricamento; la riattivazione la rimuove e il sito torna byte per byte. Il template vhost è fissato non appena il sito esiste, quindi non esiste un cambio di piano: passare a un altro template o a un’altra versione di PHP significa ricrearlo, e Provibr lo dice invece di fingere che sia cambiato qualcosa. Non ci sono nemmeno una console né un grafico dei consumi, perché CloudPanel non misura né l’uno né l’altro.

Cosa non fa

Meglio dirlo ora che dopo: gestire gli account non è gestire il pannello. Installare CloudPanel, aggiornarlo, modificare le impostazioni del server, mettere a punto NGINX e occuparsi dei database e dei certificati che i suoi clienti creano: tutto questo resta dalla sua parte, nel pannello, dove è giusto che stia.

Non deve puntare tutta l’attività su un solo pannello. Provibr fa girare fianco a fianco i suoi pannelli di controllo, i suoi hypervisor e i suoi pannelli di gioco, in un solo inventario, con un solo modello di permessi e un solo registro delle attività. Un pannello NGINX leggero per i clienti che vogliono velocità su una sola macchina, qualcosa con un albero di rivendita per chi chiede cPanel per nome, e un unico posto da cui vedere entrambi.