Cum să vindeți găzduire web cu CloudPanel

CloudPanel este panoul pe care oamenii îl instalează când vor un site care rulează repede și nimic altceva în cale. Este gratuit, ajunge pe o instanță cloud proaspătă în câteva minute, iar ce iese este o stivă simplă NGINX și PHP-FPM cu Let's Encrypt, o bază de date și o integrare Cloudflare. Fără server de e-mail. Fără straturi pe care nu le-ați cerut.

Acea concentrare este exact motivul pentru care le place oamenilor, și este totodată motivul pentru care a vinde găzduire pe el este un exercițiu diferit față de DirectAdmin sau cPanel. CloudPanel gestionează site-uri pe un singur server. Nu gestionează clienți care vă plătesc. Acestea nu sunt aceeași problemă, iar distanța dintre ele este despre ce este această pagină.

În jurul a ce este de fapt construit CloudPanel

Un server și site-urile de pe el.

Creați un site (PHP, static, Node.js, Python sau un proxy invers), iar CloudPanel scrie un vhost NGINX, un pool PHP-FPM, un utilizator Linux al site-ului și un director personal. Creați o bază de date lângă el. Îndreptați un certificat către el. Aceasta este bucla, și este una bună: un dezvoltator sau o agenție care rulează douăzeci de site-uri pe o cutie primesc o interfață curată peste exact lucrurile pe care le ating.

Ce nu are este stratul de deasupra acestuia: un client care deține un set de site-uri, cu un plan, o cotă și un comutator. CloudPanel are utilizatori de panou cu roluri (admin, manager de site, utilizator), iar acei utilizatori pot fi limitați la anumite site-uri. Dar acela este control de acces pentru oamenii care se autentifică, nu un cont comercial pe care îl puteți factura și închide.

Distincția pare academică până când primul client încetează să plătească.

Suprafața de control este un singur instrument de linie de comandă

CloudPanel nu are niciun API REST. Tot ce poate face automatizarea o face prin clpctl, propriul instrument de linie de comandă al panoului, care rulează pe gazdă ca root. Este scriptabil cum se cuvine (neinteractiv, indicatoare în loc de solicitări) și acoperă părțile la care v-ați aștepta:

Două lucruri din acel tabel merită observate înainte de a planifica ceva în jurul lui.

Primul este că identitatea unui site este numele său de domeniu. Nu un id numeric, nu un identificator de cont. Domeniul. Tot ce construiți se bazează pe asta și trebuie să supraviețuiască unui client care vrea să mute un domeniu între planuri.

Al doilea este mai consecvent și este despre ce este secțiunea următoare: nu există niciun verb în acel tabel pentru a stinge un site.

Cele trei goluri care contează la vânzare

Nu există suspendare

clpctl are site:add:* și are site:delete. Nu are nimic la mijloc. Nu există site:suspend, nu există site:disable, niciun comutator de mentenanță, iar interfața panoului nu are nici ea vreun echivalent.

Pentru o afacere de găzduire, acela nu este un gol cosmetic, pentru că „factura este restantă de treizeci de zile” este cel mai frecvent lucru la care veți avea nevoie vreodată să acționați, iar ștergerea site-ului nu este răspunsul. Ștergerea este ireversibilă și ia datele clientului cu ea; un client care plătește în ziua treizeci și unu se așteaptă să își găsească site-ul web acolo unde l-a lăsat.

Așadar, orice vinde găzduire CloudPanel trebuie să inventeze suspendarea. Candidații obișnuiți sunt oprirea pool-ului PHP-FPM al site-ului sau editarea vhost-ului astfel încât site-ul să nu mai răspundă. Ambele funcționează, iar al doilea este cel mai bun dintre cele două: un pool oprit produce un 502, care îi arată clientului dumneavoastră ca și cum serverul dumneavoastră este stricat, nu ca și cum factura lui este restantă.

A edita bine un vhost este o listă mai scurtă decât pare. Încadrați ce inserați în comentarii de început și de sfârșit, astfel încât reluarea să însemne ștergerea exactă a acelor linii și a nimic altceva. Faceți-o în fiecare bloc de server public, pentru că un vhost are de obicei unul pentru portul 80 și unul pentru 443. Iar un site suspendat prin HTTP și sănătos prin HTTPS este mai rău decât unul care nu este suspendat deloc, din moment ce arată de parcă a funcționat. Rulați nginx -t înainte de a reîncărca, pentru că acesta este un server web partajat, iar o configurație proastă doboară fiecare site de pe el odată cu dumneavoastră. Faceți-le pe aceste trei și suspendarea devine o acțiune obișnuită, instantanee, pe deplin reversibilă. Provibr face exact asta: un return 403; marcat, fiecare bloc public, testat înainte de reîncărcare.

Ce nu repară niciun aranjament este că panoul nu știe. CloudPanel nu are niciun concept de site suspendat, așa că va lista unul suspendat ca pe unul obișnuit, iar oricine are acces la panou sau la gazdă poate deschide fișierul și poate scoate linia, inclusiv clientul pe care tocmai l-ați suspendat. Puteți face starea lizibilă (marcajul este la un grep distanță, ceea ce este felul în care Provibr observă o editare manuală), dar nu puteți face ca CloudPanel să o dețină.

Decideți ce înseamnă „stins” înainte de primul client, nu după primul neplătitor.

Nu există pachete

CloudPanel nu are planuri, nu are cote și nu are limite per site. Nicio cotă de disc, niciun plafon de lățime de bandă, niciun „acest site poate avea trei baze de date”. Cel mai apropiat lucru de un pachet este un șablon de vhost, care este o configurație NGINX: util, dar nu este o limită și nu va opri pe nimeni să folosească 400 de GB.

Asta înseamnă că acel catalog de produse al dumneavoastră nu poate locui în panou. Orice separă planul dumneavoastră de 5 € de planul de 15 € trebuie definit, impus și măsurat undeva deasupra CloudPanel. Dacă nu este impus nicăieri, nu este un plan. Este o sugestie.

Nu există listă de site-uri

Există user:list pentru autentificările panoului. Nu există site:list. Site-urile în sine se află în propria bază de date SQLite a panoului, pe gazdă.

Asta contează mai mult decât pare, pentru că o listă este ceea ce alcătuiește reconcilierea. Fără una nu puteți răspunde la „tot ce facturez mai există?”, nu puteți detecta un site pe care cineva l-a șters manual și nu puteți importa un server existent în absolut nimic.

Ieșirea este să citiți acea bază de date direct: /home/clp/htdocs/app/data/db.sq3, un singur select peste tabelul site și aveți fiecare domeniu cu utilizatorul, șablonul și versiunea PHP. Este ce face Provibr și este ce va sfârși prin a face orice altceva serios. Doar să știți că citiți o schemă internă, nu o interfață: se poate schimba într-o versiune fără ca aceea să fie o promisiune încălcată, așa că intră pe lista lucrurilor de reverificat după o actualizare de panou.

Și o constrângere de proiectare sub toate acestea

clpctl rulează ca root pe gazdă. Acela nu este un detaliu de implementare pe care să îl puteți ocoli: scrie configurație NGINX, creează utilizatori Linux și gestionează servicii de sistem, iar acestea au nevoie de privilegiile de care au nevoie.

Consecința este că automatizarea CloudPanel este o chestiune de privilegiu înainte de a fi o chestiune de integrare. Orice acționează clpctl (propriul dumneavoastră script, un job cron, un instrument de implementare) rulează ca root pe un server web de producție care găzduiește site-urile altor oameni. Orice construiți, construiți-l știind că credențialul implicat nu este un token de API cu domeniu restrâns; este acces administrativ la mașină. Păstrați-l îngust, păstrați-l auditabil și țineți-l departe de orice poate atinge un client.

Ce trebuie să existe deasupra panoului

Scoateți detaliul specific panoului și lista este aceeași pentru orice panou de control, ceea ce este partea utilă (nu se schimbă dacă schimbați panourile mai târziu):

• Un formular de comandă și un catalog, cu planuri care înseamnă ceva de impus.
• O plată care declanșează aprovizionarea în câteva secunde, nu într-o zi lucrătoare.
• O cale de somare (restant, avertizat, suspendat, restaurat) cu o acțiune definită la fiecare pas.
• Capacitate pe care o puteți vedea, ca să știți câte conturi cărați și cât vă costă înainte să vă spună factura.
• Un traseu de audit, ca „cine a șters acel site” să aibă un răspuns.
• Un model de permisiuni pentru oamenii care lucrează pentru dumneavoastră, ca asistența să poată reporni ceva fără să poată șterge tot.

Nimic din asta nu vine cu CloudPanel și nimic din asta nu este ce încearcă să fie CloudPanel.

Unde se potrivește Provibr

Suportul CloudPanel este activ. Un agent din interiorul propriei dumneavoastră rețele se conectează la gazdă prin SSH și rulează clpctl așa cum s-ar face de mână, așa că pe panou nu se instalează nimic și niciun port nu trebuie să dea față cu internetul. Crearea unui site, suspendarea, reluarea și eliminarea lui funcționează, iar site-urile care existau deja sunt importate doar dacă le bifați. În jur stă stratul descris mai sus: planuri și capacitate, un preț per unitate, un model de permisiuni, un traseu de activitate și un API REST și un modul WHMCS pentru a-l acționa din orice folosiți deja pentru facturare.

Ce nu poate face integrarea este să șteargă golurile de mai sus, pentru că sunt proprietăți ale panoului. Suspendarea este partea inventată: o regulă NGINX marcată care returnează 403, introdusă în fiecare bloc de server public și verificată înainte de reîncărcare; reluarea o scoate, iar site-ul revine octet cu octet. Șablonul de vhost este fix din clipa în care site-ul există, deci nu există schimbare de pachet: trecerea la alt șablon sau la altă versiune de PHP înseamnă recrearea lui, iar Provibr o spune în loc să se prefacă că s-a schimbat ceva. Nu există nici consolă și nici grafic de consum, pentru că CloudPanel nu măsoară niciunul dintre ele.

Ce nu va face

Merită spus acum, nu mai târziu: a gestiona conturi nu este a gestiona panoul. Instalarea CloudPanel, actualizarea lui, schimbarea setărilor serverului, reglarea NGINX și îngrijirea bazelor de date și a certificatelor pe care le creează clienții dumneavoastră, asta rămâne de partea dumneavoastră, în panou, unde îi este locul.

Nu trebuie să pariați afacerea pe un singur panou. Provibr rulează una lângă alta panourile sale de control, hipervizoarele și panourile de joc, sub un singur inventar, un singur model de permisiuni și un singur jurnal de activitate. Un panou NGINX ușor pentru clienții care vor viteză pe o singură cutie, ceva cu un arbore de revânzători pentru cei care cer cPanel pe nume și un singur loc unde le puteți vedea pe amândouă.