Automatizarea facturării și aprovizionării CloudPanel

Un produs de găzduire automatizat are exact trei momente în care banii și mașinile se ating:

1. 01Comanda este plătită. Site-ul trebuie să existe, corect configurat, în câteva secunde.
2. 02Factura este restantă. Site-ul trebuie să se stingă și să revină în momentul în care este plătită.
3. 03Abonamentul se încheie. Site-ul trebuie eliminat, cu adevărat, inclusiv datele sale.

CloudPanel are o comandă curată pentru momentul unu și o comandă curată pentru momentul trei. Pentru momentul doi nu are absolut nimic. Aceasta nu este o simplă notă de subsol la o integrare altminteri obișnuită; este faptul definitoriu al automatizării facturării pe acest panou și merită mijlocul acestei pagini, nu o linie la final.

Cele trei momente și ce oferă CloudPanel

Totul rulează prin clpctl, instrumentul de linie de comandă al panoului. Nu există niciun API REST: CloudPanel este un panou randat pe server plus un CLI, iar automatizarea trece prin CLI sau nu trece deloc.

Cele două comenzi care există sunt bune. site:add:php preia domeniul, versiunea PHP, un șablon de vhost și utilizatorul Linux al site-ului cu parola sa și revine după ce a scris vhost-ul, pool-ul și directorul personal. site:delete --force este o ștergere reală, nu una temporară. Între ele se află golul.

Mijlocul lipsă și cum se umple

Suspendarea este acțiunea pe care un sistem de facturare o execută mai des decât oricare alta, pentru că este cea care rulează nesupravegheat, după un program, împotriva unor conturi la care nu se uită nimeni. Este totodată singura pârghie reversibilă pe care o aveți între „continuați să îi găzduiți gratuit” și „ștergeți-le afacerea”.

CloudPanel nu are niciun cuvânt pentru ea. Nu există site:suspend, nu există site:disable, nu există niciun indicator de mentenanță în panou și nicio stare per site pe care să o comutați. Așadar, dacă vindeți găzduire CloudPanel, suspendarea este ceva ce construiți. Opțiunile realiste, cu costurile lor oneste:

Opriți pool-ul PHP-FPM al site-ului. Rapid, reversibil și oprește cu adevărat servirea site-ului. Produce însă un 502 în loc de o explicație, așa că clientul dumneavoastră vede un site web stricat, nu un cont suspendat. Și este o operațiune systemd pe gazdă, nu una clpctl, deci rămâne în grija dumneavoastră să funcționeze de-a lungul actualizărilor de panou.

Editați vhost-ul. Configurația NGINX a site-ului este un fișier pe gazdă, iar o singură linie din el decide dacă site-ul răspunde. Reversibil, instantaneu și nu îl costă pe client nimic în afară de acces. Complicația este că scrieți într-un fișier deținut de CloudPanel, așa că contează foarte mult cum scrieți în el.

Ștergeți cu o copie de rezervă în prealabil. Fără echivoc și permanent într-un fel care vă va costa, în cele din urmă, un client care a plătit în ziua treizeci și unu. Restaurarea nu este un comutator, cu tot ce implică asta pentru DNS, certificate și mesajele pe care trebuie să le trimiteți după aceea.

Nu există o a patra opțiune care să fie curată. Ce contează este să alegeți una în mod deliberat și să vă asigurați că persoana care răspunde la telefon știe care este. Modul de eșec aici nu este tehnic. Este un agent de asistență care îi promite unui client că site-ul lui va reveni imediat, pe un sistem unde a reveni înseamnă a restaura o copie de rezervă.

Cum arată o editare atentă de vhost

A doua opțiune este cea care merită făcută cum se cuvine, iar „cum se cuvine” este o listă scurtă. Așa procedează Provibr, iar raționamentul se transferă indiferent dacă folosiți Provibr sau îl scrieți dumneavoastră înșivă.

Marcați ce ați inserat. Suspendarea este un return 403; încadrat de un comentariu de început și unul de sfârșit. A o elimina înseamnă a șterge exact liniile dintre acele marcaje, astfel încât reluarea lasă fișierul octet cu octet așa cum era, iar un return 403; pe care clientul l-a pus acolo din motivele lui rămâne neatins. O căutare-și-înlocuire pe return 403 nu ar avea această proprietate.

Fiecare bloc de server public, nu doar primul. Un vhost are de obicei un bloc pentru portul 80 și unul pentru 443. Injectați în unul singur și obțineți un site suspendat prin HTTP și unul perfect sănătos prin HTTPS, ceea ce este mai rău decât să nu suspendați deloc, pentru că arată de parcă a funcționat.

Testați configurația înainte de a o reîncărca. nginx -t rulează primul. O suspendare care doboară fiecare alt site de pe mașină nu este o suspendare, iar acesta este, prin proiectare, un server web partajat.

Faceți starea lizibilă de pe gazdă. Pentru că marcajul este un comentariu într-un fișier, site-urile suspendate sunt la un grep distanță, iar agentul citește asta înapoi în loc să aibă încredere în propria bază de date. Dacă cineva editează fișierul manual, următoarea interogare observă.

Ce nu schimbă nimic din toate acestea: CloudPanel în sine tot nu are niciun concept de site suspendat. Panoul îl va afișa ca pe un site obișnuit, pentru că, din punctul de vedere al panoului, chiar este unul. Oricine are acces la CloudPanel, inclusiv clientul pe care tocmai l-ați suspendat, poate deschide acel fișier și poate scoate linia. Starea este lizibilă și este impusă la nivelul serverului web, dar nu este deținută de panou, iar niciun aranjament pe acest panou nu poate schimba asta.

Nu există nici o cale de upgrade, pentru că nu există pachete

CloudPanel nu are planuri, nu are cote și nu are limite per site. Asta elimină un întreg moment din lista de mai sus: nu există niciun apel de „schimbare a pachetului”, pentru că nu există niciun pachet.

Înseamnă totodată că diferența dintre planurile dumneavoastră trebuie să fie reală în altă parte. Dacă planul dumneavoastră de 5 € și planul de 15 € aterizează pe același CloudPanel cu totul identic, atunci ceea ce a cumpărat clientul dumneavoastră a fost un preț, iar primul care își dă seama de asta le va spune celorlalți. Impunerea se află deasupra panoului: gazde separate per palier, cote la nivelul sistemului de fișiere sau limite pe care propria dumneavoastră platformă le aplică și le numără.

Reconcilierea are nevoie de o listă, iar aceasta nu există

clpctl poate enumera utilizatorii panoului. Nu poate enumera site-urile; acestea se află în propria bază de date SQLite a panoului, pe gazdă.

Pentru facturare acesta este un gol real, deoarece un sistem de facturare ar trebui să poată pune două întrebări în orice moment: tot ce facturez mai există? și există aici ceva ce nu facturez? La ambele se răspunde comparând evidențele dumneavoastră cu o listă a ceea ce se află cu adevărat pe mașină. Fără o listă, aflați despre un site șters manual atunci când vă trimite clientul un e-mail, iar despre unul creat manual niciodată.

Orice construiți deasupra CloudPanel trebuie să obțină acea listă din altă parte decât clpctl, iar pentru asta va avea nevoie de acces la gazdă. În practică există exact un singur loc: propria bază de date a panoului, /home/clp/htdocs/app/data/db.sq3, unde un simplu select peste tabelul site vă oferă dintr-o singură mișcare domeniul, utilizatorul Linux, tipul, șablonul de vhost și versiunea PHP. Provibr o citește de acolo.

Asta funcționează și merită să fiți limpede cu privire la ce acceptați atunci când o faceți. Acea schemă este afacerea internă a CloudPanel, nu o interfață publicată, așa că se poate schimba într-o versiune fără ca nimeni să fi încălcat vreo promisiune. A o citi este alegerea corectă (un sistem de facturare fără reconciliere este mai rău), dar aparține listei scurte de lucruri de reverificat după o actualizare de panou, alături de formatele de ieșire ale clpctl.

Credențialul nu este un token de API

Merită spus fără ocolișuri, pentru că este cea mai mare diferență practică dintre automatizarea CloudPanel și automatizarea unui panou cu un API REST.

clpctl rulează ca root. Scrie configurație NGINX, creează utilizatori Linux și gestionează servicii, deci root nu este o scăpare. Este esența treburii. Prin urmare, orice îl acționează deține acces administrativ la un server web de producție care poartă site-urile altor oameni, nu un token cu domeniu restrâns limitat la o singură suprafață de API.

Două consecințe pentru oricine cablează facturarea în acest lucru. Raza de acțiune a pagubelor este diferită: un token de API al panoului scurs îi permite cuiva să creeze și să șteargă conturi, în timp ce un credențial de shell scurs pe serverul web este o cu totul altă discuție, cu un alt set de obligații. Și privilegiul minim este munca dumneavoastră: nu există nicio casetă de permisiuni pe care să vă bazați, așa că delimitarea este ceva ce proiectați, nu configurați.

Unde locuiește de fapt factura

Merită spus explicit, pentru că este cea mai frecventă neînțelegere: Provibr nu facturează clienții dumneavoastră. Nu le trimite o factură, nu îi urmărește și nu știe cât le percepeți. Acea relație este a dumneavoastră.

Ce facturează Provibr este capacitatea pe care o rezervați dumneavoastră: câte conturi de găzduire aveți voie să rulați în același timp, pe lună, la un preț unitar pe paliere. Ceea ce le percepeți dumneavoastră propriilor clienți, și cum, rămâne în întregime în interiorul propriului dumneavoastră sistem de facturare.

Există două moduri de a lega cele două jumătăți:

Un modul WHMCS. Dacă rulați deja WHMCS, instalați modulul de aprovizionare Provibr și îndreptați un produs WHMCS către un plan de găzduire web Provibr. Clientul dumneavoastră păstrează un singur cont, o singură factură și o singură autentificare. Modulul este un simplu fișier zip pe care îl instalați dumneavoastră înșivă și rulează în interiorul WHMCS-ului dumneavoastră; nu este nimic de activat de partea noastră.

API-ul REST. Dacă rulați FOSSBilling, Blesta, ceva propriu sau un tabel și un job cron, acționați-l direct. O cheie, o adresă de bază și exact permisiunile pe care membrul din spatele cheii le are deja.

Singura regulă pentru a-l acționa din propriul cod

Tot ce atinge o mașină este asincron și așa trebuie să fie. Infrastructura dumneavoastră este accesibilă doar prin agentul din interiorul propriei rețele, iar acel agent inițiază conexiunea spre exterior. Așadar, un endpoint care schimbă un cont nu poate răspunde cu rezultatul. Răspunde că comanda a fost acceptată și vă predă o comandă de urmărit, pe care o citiți până când starea sa este finală: finalizată, eșuată, expirată sau anulată.

Citirea nu funcționează niciodată așa. Un inventar, o adresă sau o factură răspund imediat, pentru că acel răspuns vine dintr-o bază de date și nu de pe gazda dumneavoastră.

Consecința practică pentru un declanșator de facturare: nu marcați comanda ca finalizată pe baza răspunsului de acceptare. Răspunsul pe care îl primiți mai întâi este „am trimis-o”, nu „a funcționat”.

Suspendarea este și propriul dumneavoastră control al costurilor

O legătură ușor de trecut cu vederea, și este motivul pentru care mijlocul lipsă de mai sus costă bani, nu doar bunăvoință. În Provibr, un server suspendat încetează să conteze la capacitatea pe care o plătiți. Pentru un cont de găzduire nu există „oprit”: există activ și există suspendat.

Așadar, pasul de somare pe care îl doreați deja din motive comerciale eliberează totodată locul pe care îl plătiți, cu condiția ca suspendarea să fie o acțiune reală, nu o notă în propria dumneavoastră bază de date. Acesta este argumentul practic pentru a o construi în loc de a lăsa mijlocul gol: un cont neplătit pe care încă nu ați decis să îl ștergeți este capacitate pe care continuați să o plătiți.

Tot ce este spus mai sus despre panou este o proprietate a CloudPanel, nu o descriere a unei integrări, iar asta este deliberat: golurile sunt reale și nu ține de noi să le facem să dispară prin dorință. Ce poate face o integrare este să aleagă cu grijă pe care dintre cele trei opțiuni o adoptă și să spună cu voce tare ce anume tot nu rezolvă acea alegere.

Dacă vindeți și VPS-uri, servere de jocuri sau conturi cPanel, aceleași trei momente se aplică tuturor, iar ele pot locui într-un singur inventar. Provibr rulează astăzi panourile sale de control, hipervizoarele și panourile de joc unele lângă altele, cu un singur set de permisiuni și un singur jurnal de activitate pentru tot.