Webhosting mit CloudPanel verkaufen

CloudPanel ist das Panel, das man installiert, wenn eine Site schnell laufen soll und sonst nichts im Weg stehen darf. Es ist kostenlos, es liegt in wenigen Minuten auf einer frischen Cloud-Instanz, und heraus kommt ein schlichter Stack aus NGINX und PHP-FPM mit Let's Encrypt, einer Datenbank und einer Cloudflare-Anbindung. Kein Mailserver. Keine Schichten, um die Sie nicht gebeten haben.

Genau dieser Fokus ist der Grund, warum Menschen es mögen, und zugleich der Grund, warum Hosting darauf zu verkaufen eine andere Übung ist als auf DirectAdmin oder cPanel. CloudPanel verwaltet Sites auf einem Server. Es verwaltet keine Kundschaft, die Sie bezahlt. Das sind nicht dieselben Probleme, und um den Abstand dazwischen geht es auf dieser Seite.

Worum CloudPanel tatsächlich gebaut ist

Um einen Server und die Sites darauf.

Sie legen eine Site an (PHP, statisch, Node.js, Python oder ein Reverse Proxy), und CloudPanel schreibt einen NGINX-vhost, einen PHP-FPM-Pool, einen Linux-Site-Benutzer und ein Home-Verzeichnis. Sie stellen eine Datenbank daneben. Sie richten ein Zertifikat darauf aus. Das ist die Schleife, und sie ist gut: Eine Entwicklerin oder eine Agentur mit zwanzig Sites auf einer Kiste bekommt eine saubere Oberfläche über genau die Dinge, die sie anfasst.

Was fehlt, ist die Schicht darüber: ein Kunde, dem eine Reihe von Sites gehört, mit einem Plan, einem Kontingent und einem Schalter. CloudPanel hat Panel-Benutzer mit Rollen (Administrator, Site-Manager, Benutzer), und diese Benutzer lassen sich auf bestimmte Sites einschränken. Aber das ist Zugriffssteuerung für Menschen, die sich anmelden, kein kaufmännisches Konto, das Sie abrechnen und abschalten können.

Der Unterschied klingt akademisch, bis der erste Kunde aufhört zu zahlen.

Die gesamte Bedienfläche ist ein Kommandozeilenwerkzeug

CloudPanel hat keine REST-API. Alles, was Automatisierung tun kann, tut sie über clpctl, das eigene Kommandozeilenwerkzeug des Panels, das als root auf dem Host läuft. Es lässt sich sauber skripten (nicht-interaktiv, Flags statt Rückfragen) und deckt ab, was Sie erwarten würden:

Zwei Dinge in dieser Tabelle lohnen den Blick, bevor Sie irgendetwas darum herum planen.

Das erste: Die Identität einer Site ist ihr Domainname. Keine numerische ID, kein Kontoname: die Domain. Alles, was Sie bauen, hängt daran, und es muss einen Kunden überstehen, der eine Domain in einen anderen Plan verschieben möchte.

Das zweite wiegt schwerer, und darum geht es im nächsten Abschnitt: In dieser Tabelle steht kein Verb, um eine Site abzuschalten.

Die drei Lücken, die beim Verkaufen zählen

Es gibt kein Stilllegen

clpctl hat site:add:* und es hat site:delete. Dazwischen hat es nichts. Es gibt kein site:suspend, kein site:disable, keinen Wartungsschalter, und die Panel-Oberfläche hat ebenso wenig ein Gegenstück.

Für ein Hosting-Geschäft ist das keine kosmetische Lücke, denn „die Rechnung ist dreißig Tage überfällig“ ist mit Abstand das Häufigste, worauf Sie reagieren müssen, und die Site zu löschen ist nicht die Antwort. Löschen ist unumkehrbar und nimmt die Daten des Kunden mit; wer am einunddreißigsten Tag zahlt, erwartet die Website dort wieder, wo sie sie verlassen hat.

Alles, was CloudPanel-Hosting verkauft, muss die Stilllegung also erfinden. Die üblichen Kandidaten sind, den PHP-FPM-Pool der Site zu stoppen oder den vhost so zu bearbeiten, dass die Site nicht mehr antwortet. Beides funktioniert, und das zweite ist das bessere: Ein gestoppter Pool liefert einen 502, und das sieht für Ihren Kunden so aus, als wäre Ihr Server kaputt, statt so, als wäre seine Rechnung überfällig.

Einen vhost gut zu bearbeiten ist eine kürzere Liste, als es klingt. Setzen Sie das Eingefügte zwischen ein Anfangs- und ein Endkommentar, damit die Wiederaufnahme genau diese Zeilen entfernt und sonst nichts. Tun Sie es in jedem öffentlichen server-Block, denn ein vhost hat meist einen für Port 80 und einen für 443, und eine Site, die über HTTP stillgelegt und über HTTPS kerngesund ist, ist schlimmer als eine, die gar nicht stillgelegt ist, denn es sieht aus, als hätte es funktioniert. Lassen Sie nginx -t vor dem Neuladen laufen, denn dies ist ein geteilter Webserver, und eine kaputte Konfiguration nimmt jede Site darauf mit. Machen Sie diese drei Dinge, und die Stilllegung wird eine gewöhnliche, sofortige, vollständig umkehrbare Handlung. Provibr macht genau das: ein markiertes return 403;, jeder öffentliche Block, geprüft vor dem Neuladen.

Was keine Konstruktion löst: Das Panel weiß es nicht. CloudPanel kennt keine stillgelegte Site, zeigt sie also als gewöhnliche an, und jede Person mit Panel- oder Host-Zugang kann die Datei öffnen und die Zeile entfernen, auch der Kunde, den Sie gerade stillgelegt haben. Sie können den Zustand lesbar machen (die Markierung ist ein grep weit entfernt, so bemerkt Provibr eine Handbearbeitung), aber Sie können CloudPanel nicht zu seinem Eigentümer machen.

Entscheiden Sie vor dem ersten Kunden, was „aus“ bedeutet, nicht nach der ersten Zahlungsverweigerung.

Es gibt keine Pakete

CloudPanel hat keine Pläne, keine Kontingente und keine Grenzen pro Site. Kein Speicherkontingent, kein Limit für das Datenvolumen, kein „diese Site darf drei Datenbanken haben“. Am nächsten an ein Paket kommt eine vhost-Vorlage, und das ist eine NGINX-Konfiguration, nützlich, aber keine Grenze, und sie hält niemanden auf, der 400 GB verbraucht.

Das heißt, Ihr Produktkatalog kann nicht im Panel liegen. Was Ihren 5-€-Plan von Ihrem 15-€-Plan unterscheidet, muss oberhalb von CloudPanel definiert, durchgesetzt und gemessen werden. Wird es nirgends durchgesetzt, ist es kein Plan. Dann ist es ein Vorschlag.

Es gibt keine Liste der Sites

Es gibt user:list für Panel-Logins. Es gibt kein site:list. Die Sites selbst liegen in der eigenen SQLite-Datenbank des Panels auf dem Host.

1

Der Ausweg ist, diese Datenbank direkt zu lesen: /home/clp/htdocs/app/data/db.sq3, ein select über die Tabelle site, und Sie haben jede Domain mit ihrem Benutzer, ihrer Vorlage und ihrer PHP-Version. Das macht Provibr, und darauf läuft alles Ernsthafte hinaus. Wissen Sie nur, dass Sie ein internes Schema lesen und keine Schnittstelle: Es kann sich in einer Version ändern, ohne dass das ein gebrochenes Versprechen wäre. Es gehört also auf die Liste der Dinge, die nach einem Panel-Upgrade erneut zu prüfen sind.

Und eine Entwurfsbedingung unter alldem

clpctl läuft als root auf dem Host. Das ist kein Implementierungsdetail, um das Sie herumkommen: Es schreibt NGINX-Konfiguration, legt Linux-Benutzer an und verwaltet Systemdienste, und dafür braucht es diese Rechte.

Die Folge: CloudPanel zu automatisieren ist eine Rechtefrage, bevor es eine Integrationsfrage ist. Alles, was clpctl ansteuert (Ihr eigenes Skript, ein Cronjob, ein Deployment-Werkzeug), läuft als root auf einem Produktions-Webserver, der die Sites anderer Leute trägt. Was auch immer Sie bauen: Bauen Sie es im Wissen, dass die beteiligte Zugangsberechtigung kein eng gefasstes API-Token ist, sondern administrativer Zugriff auf die Maschine. Halten Sie ihn schmal, halten Sie ihn nachvollziehbar, und halten Sie ihn weit weg von allem, was Kundschaft erreichen kann.

Was oberhalb des Panels existieren muss

Streichen Sie das Panel-Spezifische, und die Liste ist für jedes Control Panel dieselbe; das ist der nützliche Teil, denn sie ändert sich nicht, wenn Sie später wechseln:

• Ein Bestellformular und ein Katalog, mit Plänen, die etwas Durchsetzbares bedeuten.
• Eine Zahlung, die die Bereitstellung auslöst, in Sekunden, nicht innerhalb eines Arbeitstages.
• Ein Mahnweg (überfällig, gewarnt, stillgelegt, wiederhergestellt), mit einer festgelegten Aktion bei jedem Schritt.
• Sichtbare Kapazität, damit Sie wissen, wie viele Konten Sie tragen und was sie kosten, bevor die Rechnung es Ihnen sagt.
• Ein Aktivitätsprotokoll, damit „wer hat diese Site gelöscht“ eine Antwort hat.
• Ein Rechtemodell für Ihre Mitarbeitenden, damit der Support etwas neu starten kann, ohne alles löschen zu können.

Nichts davon kommt mit CloudPanel mit, und nichts davon will CloudPanel sein.

Wo Provibr hineinpasst

Die Unterstützung für CloudPanel ist live. Ein Agent in Ihrem eigenen Netzwerk verbindet sich über SSH mit dem Host und führt clpctl so aus, wie man es von Hand täte; auf dem Panel wird nichts installiert, und kein Port muss ins Internet zeigen. Eine Site anlegen, sperren, wieder freigeben und entfernen funktioniert, und Sites, die bereits vorhanden waren, werden nur importiert, wenn Sie sie anhaken. Darum herum liegt die oben beschriebene Schicht: Pläne und Kapazität, ein gestaffelter Stückpreis, ein Rechtemodell, ein Aktivitätsprotokoll sowie eine REST-API und ein WHMCS-Modul, um das Ganze aus dem anzusteuern, womit Sie ohnehin abrechnen.

Was die Integration nicht kann, ist die Lücken oben wegzaubern, denn es sind Eigenschaften des Panels. Das Sperren ist der erfundene Teil: eine markierte NGINX-Regel, die 403 zurückgibt, in jeden öffentlichen Server-Block eingesetzt und vor dem Neuladen geprüft; das Freigeben entfernt sie wieder, und die Site ist Byte für Byte zurück. Das vHost-Template steht fest, sobald eine Site existiert, es gibt also keinen Paketwechsel: Der Wechsel auf ein anderes Template oder eine andere PHP-Version bedeutet Neuanlegen, und Provibr sagt das, statt eine Änderung vorzutäuschen. Eine Konsole und eine Verbrauchsgrafik gibt es ebenfalls nicht, weil CloudPanel beides nicht misst.

Was es nicht tun wird

Lieber jetzt als später gesagt: Konten zu verwalten ist nicht dasselbe wie das Panel zu verwalten. CloudPanel installieren, aktualisieren, Servereinstellungen ändern, NGINX abstimmen und die Datenbanken und Zertifikate pflegen, die Ihre Kundschaft anlegt: Das bleibt bei Ihnen, im Panel, wo es hingehört.

Sie müssen Ihr Geschäft nicht auf ein Panel setzen. Provibr betreibt seine Controlpanels, Hypervisoren und Gamepanels nebeneinander, mit einem Bestand, einem Rechtemodell und einem Aktivitätsprotokoll. Ein leichtes NGINX-Panel für die Kundschaft, die Tempo auf einer Kiste will, etwas mit Reseller-Baum für die, die nach cPanel fragt, und ein Ort, an dem Sie beides sehen.