Automatizarea facturării și a aprovizionării HestiaCP

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

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

HestiaCP are o comandă pentru fiecare dintre acestea. Ce nu are este ceva care să decidă când să le ruleze. Această pagină este despre racordarea celor două jumătăți și despre locurile precise în care API-ul HestiaCP răspunde într-un mod care va strica în tăcere o primă încercare.

Cele trei momente și comenzile care le susțin

Observați coloana răspunsurilor. O modificare reușită pe HestiaCP este HTTP 204, fără nimic în corp. Nu 200. Un client scris pornind de la presupunerea că succesul înseamnă 200 respinge fiecare apel care a funcționat și apoi, de obicei, îl reîncearcă, și așa se transformă o integrare care merge în una blocată (vedeți mai jos).

Adevăratul răspuns trăiește într-un antet de răspuns, Hestia-Exit-Code, care poartă un număr dintr-o tabelă fixă. Starea HTTP derivă din el și pliază vreo douăzeci de coduri pe patru stări. Citiți antetul; tratați starea ca pe un indiciu.

Suspendarea nu este simetrică, iar aici contează mai mult decât oriunde

Aceasta este capcana care lovește în mod specific o integrare de facturare, pentru că o integrare de facturare este singurul lucru care suspendă de două ori același cont.

Măsurat, pe același cont:

v-suspend-user   on an active account     → 204, exit 0
v-suspend-user   on a suspended account   → 401, exit 5   ("user X is suspended")
v-unsuspend-user on a suspended account   → 204, exit 0
v-unsuspend-user on an active account     → 204, exit 0

Reluarea este idempotentă. Suspendarea nu este. Iar eșecul pe care îl produce este HTTP 401, aceeași stare pe care o primiți pentru un secret greșit, o cheie în afara domeniului ei și o adresă blocată.

Așadar, un ciclu de relansare care suspendă tot ce este restant, inclusiv lucrurile pe care le-a suspendat deja ieri, va raporta erori de autentificare pentru conturi care sunt exact în starea pe care o doreați. Codul de ieșire 5 la v-suspend-user înseamnă „era deja așa” și trebuie citit ca un succes.

Nu reîncercați niciodată după o eroare de autentificare

HestiaCP blochează o adresă după cinci conexiuni refuzate, folosind fail2ban cu maxretry = 5 și un DROP iptables. Odată ce acest lucru se declanșează, apelurile nu mai expiră la nivel de aplicație, ci încep să expire la nivel de rețea: monitorizarea dumneavoastră spune că panoul este inaccesibil, iar nimic din jurnalele dumneavoastră nu indică o problemă de date de autentificare.

Pentru o integrare de facturare acest lucru contează mai mult decât pentru orice altceva, pentru că o integrare de facturare este ceea ce rulează nesupravegheat noaptea. Două consecințe:

• Codurile de ieșire 9, 10 și 21 nu trebuie să declanșeze niciodată o reîncercare automată. Acestea sunt, respectiv, secret greșit, permisiune refuzată și API dezactivat. Niciunul nu este o defecțiune pasageră, iar toate trei contează pentru blocare.
• O comandă în afara permisiunilor cheii contează, de asemenea, ca o conexiune refuzată. Nu este evident: aceeași linie de jurnal se scrie pentru un secret greșit și pentru o cheie validă care întinde mâna către o comandă pe care nu are dreptul să o ruleze. O cheie limitată la setul de permisiuni billing livrat din fabrică de HestiaCP nu are nici v-list-user-packages, nici v-list-web-domains, așa că un ciclu de interogare care citește pachetele și domeniile epuizează contorul de blocare la program. Folosiți o cheie nelimitată pentru utilizatorul administrator.

Ridicarea unei blocări necesită un terminal pe gazda panoului: v-delete-firewall-ban <address> HESTIA. Dacă software-ul pe care îl construiți nu știe să spună această frază, cel care este de gardă la trei dimineața își va petrece noaptea pe problema greșită.

O comandă plătită costă două apeluri, deci are nevoie de o revenire

HestiaCP nu are nicio comandă care să creeze un utilizator și să atașeze un domeniu deodată. Aceasta lasă o fereastră:

v-add-user       provibrtest1 …                        → 204, exit 0
v-add-web-domain provibrtest1 "not a valid domain"      → 422, exit 2
v-list-user      provibrtest1                           → the account exists, with zero domains

Un utilizator unix real, cu un director personal, fără site și cu un rând în fiecare numărătoare. Dacă domeniul clientului dumneavoastră era deja luat pe panoul dumneavoastră (ceea ce se întâmplă, pentru că clienții se mută), comanda eșuează, iar dumneavoastră rămâneți cu o jumătate de cont pe care nimeni nu o va observa vreodată.

Regula este simplă și trebuie să fie integrată: dacă al doilea pas eșuează, ștergeți utilizatorul și raportați eroarea inițială. Un domeniu refuzat nu trebuie să lase niciodată o jumătate de cont în urmă.

Provibr face exact acest lucru, iar eroarea pe care o vede clientul este cea pe care HestiaCP a dat-o pentru domeniu, nu o eroare secundară despre o curățare.

Unde se află de fapt factura

Merită să fim expliciți, 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 ce le percepeți. Acea relație este a dumneavoastră.

Ceea ce facturează Provibr este capacitatea pe care o rezervați dumneavoastră: câte conturi de găzduire puteți rula în același timp, pe lună, la un preț unitar pe paliere. Ceea ce le percepeți propriilor clienți pentru un cont HestiaCP, și în ce mod, 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 web Provibr. O comandă plătită creează contul; o suspendare în WHMCS îl suspendă; o reziliere îl elimină. Clientul dumneavoastră păstrează un cont, o factură și un nume de autentificare. Modulul este o simplă arhivă zip pe care o instalați singur și care 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 de calcul și o sarcină cron, controlați-l direct. O cheie, un URL de bază și exact permisiunile pe care le are deja membrul din spatele cheii.

Regula unică pentru a-l controla din propriul cod

Tot ce atinge o mașină este asincron, și trebuie să fie. Infrastructura dumneavoastră este accesibilă doar prin agentul din interiorul propriei dumneavoastră rețele, iar acel agent se conectează spre exterior. Așadar, un punct final care modifică un cont nu poate răspunde cu rezultatul. El răspunde că ordinul a fost acceptat și vă înmânează o comandă de urmărit, pe care o citiți până când starea ei este definitivă: încheiată, eșuată, expirată sau anulată. O comandă eșuată poartă propriul cod de eroare al agentului cu argumentele sale, același pe care panoul îl redă pe ecran.

Citirea nu funcționează niciodată astfel. Un inventar, o adresă sau o factură răspunde imediat, pentru că acel răspuns vine dintr-o bază de date, nu de la gazda dumneavoastră.

Consecința practică pentru un declanșator de facturare: nu marcați comanda ca finalizată pe baza răspunsului de acceptare. Pe HestiaCP, v-add-user durează aproximativ o secundă, iar v-delete-user aproximativ trei, așa că așteptarea este scurtă, dar răspunsul pe care îl primiți mai întâi este „l-am trimis”, nu „a funcționat”.

Suspendarea este și controlul propriilor costuri

O legătură ușor de ratat. În Provibr, un server suspendat nu contează pentru capacitatea dumneavoastră, iar pentru un cont de găzduire nu există „oprit”: există activ și suspendat.

Așadar, acțiunea de relansare pe care oricum voiați să o rulați din motive comerciale este și cea care eliberează locul pentru care plătiți. Suspendați un cont restant și el încetează imediat să conteze; ștergeți-l și el încetează, de asemenea, să conteze; lăsați-l să ruleze neplătit și îl plătiți.

Ce nu automatizează acest lucru

Provibr gestionează conturi, nu panoul. Nu instalează HestiaCP, nu îl actualizează, nu modifică setările serverului și nu atinge DNS-ul, căsuțele de e-mail sau bazele de date; un client care își șterge propria căsuță de e-mail prin HestiaCP o face fără ca ceva deasupra să știe sau să îi pese. Nu există consolă pentru un cont de găzduire. Și nu există suspendare parțială: un cont este activ sau nu este.

Dacă vindeți și VPS-uri, servere de jocuri sau conturi cPanel, aceleași trei momente se aplică tuturor, iar ele pot trăi î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 toate.