Abrechnungs-Automatisierung für PufferPanel

Die meisten Seiten über Abrechnungs-Automatisierung beginnen beim glücklichen Pfad. Diese beginnt bei der Lücke, denn auf PufferPanel bestimmt die Lücke den Entwurf.

PufferPanel hat keine Sperre. Keine Spalte, keinen Endpunkt. Der Serverstatus kennt nur running und installing. Alles Weitere folgt daraus.

Gemessen gegen PufferPanel 3.0.9.

Zwei Abrechnungsebenen, und das ist nicht dasselbe

Was Sie Ihren eigenen Kunden berechnen, bleibt vollständig in Ihrem Abrechnungssystem. Provibr sieht nie eine Kundenrechnung und spricht nie mit Ihren Kunden. Ihr Abrechnungssystem besitzt die Entscheidung, die Provisionierungsschicht die Ausführung.

Der Lebenszyklus, abgebildet

Vier dieser fünf Zeilen sind gewöhnlich. Die zweite nicht.

Die Sperr-Lücke und wie man darum herum entwirft

Sperrt eine Plattform einen PufferPanel-Gameserver (um eine Lizenzgrenze durchzusetzen oder weil Sie es wegen Nichtzahlung angeordnet haben), stoppt sie den Container und blockiert den Zugriff auf diesen Server im Panel der Plattform selbst. Der Server läuft nicht, und Ihr Kunde kann ihn aus Ihrem Dashboard nicht starten.

Aber die Blockade ist ein Plattformbegriff, kein Panel-Begriff. Jeder mit direktem Zugang zur PufferPanel-Installation kann den Server wieder starten. PufferPanel setzt nichts durch, denn es hat nichts, womit es durchsetzen könnte.

Das gehört deutlich gesagt statt vergraben, denn es ändert, was Sie verkaufen sollten:

Sind Sie in der zweiten oder dritten Zeile und zählt die Durchsetzung im Mahnwesen, nutzen Sie ein Panel mit einem echten suspended-Flag. Pelican hat eines, und ein gesperrter Server bleibt dort gesperrt, wer sich auch einloggt.

Ein Mittelweg, wenn Sie PufferPanel behalten wollen: früher beenden. Da eine Sperre weich ist, behandeln Sie sie als Warnstufe statt als Durchsetzungsstufe und verlagern die echte Durchsetzung auf das Löschen, mit einer Aufbewahrungsregel und einem vorherigen Backup, vorab kommuniziert. Das ist eine Produktentscheidung, keine technische.

Die Regel, die alles prägt: nichts ist sofort fertig

Ihr Panel steht in Ihrem eigenen Netz, und eine vernünftige Plattform erreicht es über einen Agenten, der sich nach außen verbindet: kein eingehender Port, kein Loch in der Firewall. Die Folge ist unausweichlich: Ein Endpunkt, der eine Maschine verändert, kann nicht mit dem Ergebnis antworten. Er antwortet, dass der Auftrag angenommen wurde:

POST /v1/servers/{serverId}/actions/suspend
Authorization: Bearer pvk_...
Idempotency-Key: dunning-inv-10482

{
  "command": {
    "id": "cmd_...",
    "kind": "game.suspend",
    "status": "pending"
  }
}

202 Accepted, kein 200. Danach lesen Sie diesen Befehl, bis sein Status endgültig ist: done, failed, timed_out oder cancelled. Ein fehlgeschlagener Befehl trägt den eigenen Fehlercode des Agenten mit seinen Argumenten. Lesen ist anders: Ein Inventar, eine Adresse oder eine Rechnung antwortet sofort, denn das kommt aus einer Datenbank und nicht von Ihrem Host.

Entwerfen Sie Ihre Mahn-Hooks danach. Ein Hook, der „die API hat geantwortet“ als „die Arbeit ist getan“ liest, meldet eine erfolgreiche Sperre, die nie stattgefunden hat, genau an dem Tag, an dem es darauf ankam.

Sicher wiederholen

Alles, was etwas anlegt, akzeptiert einen selbst gewählten Idempotency-Key-Header. Wiederholen Sie dieselbe Anfrage mit demselben Wert, bekommen Sie das erste Ergebnis zurück statt eines zweiten Servers. Schlüsseln Sie auf etwas Stabiles Ihrerseits (die Rechnungsnummer, die Dienst-ID, die Mahnstufe), denn erneut zugestellte Webhooks und Viertelstunden-Crons sind normal, und beide sollen harmlos sein. Denselben Wert für eine andere Anfrage zu verwenden, wird bewusst abgelehnt: Ein Schlüssel, der zwei Dinge bedeutet, bedeutet nichts.

Die Verben, und wann sie erlaubt sind

Ein Gameserver akzeptiert sechs Aktionen über die API: start · stop · restart · kill · suspend · resume, bewacht vom aktuellen Status des Servers:

Sie können einen Server sperren, der bereits gestoppt ist, und das ist Absicht: Eine Durchsetzung, die man mit einem Druck auf „Stopp“ umgeht, ist keine Durchsetzung. suspend aus installing folgt derselben Logik: Eine Kündigung mitten in der Installation soll nicht warten müssen, bis diese fertig ist.

Bestellen ist plangesteuert, und das muss es sein

Auf manchen Panels können Sie eine Bestellung von Hand bauen. Auf PufferPanel praktisch nicht, und der Grund ist strukturell: PufferPanel verlangt die vollständige Vorlagendefinition inline, wenn ein Server angelegt wird. Es gibt kein „bau einen aus Vorlage X“ per Verweis, die Definition muss also aus einem Katalog kommen. Ein Gameplan trägt den Vorlagennamen und die Ressourcengrenzen; die Bestellung zeigt auf den Plan. Bauen Sie Ihre eigene Brücke, bauen Sie diesen Katalog ohnehin.

Zwei gemessene Details, über die man leicht stolpert:

• Community-Vorlagen stehen standardmäßig auf einer Host-Umgebung, die Binärdateien braucht, die ein frischer Panel-Host nicht hat. Wechseln Sie auf die Docker-Variante der Vorlage, sonst scheitert jede Bestellung mit einem Missing-Binary-Fehler, der sich wie ein Plattform-Bug liest.
• Löschen stoppt den Server zuerst. Der Daemon entfernt keinen laufenden Container; ein Löschen gegen einen laufenden Server ergibt einen 500.

Was bewusst nicht da ist

• Keine verbrauchsbasierte Abrechnung. Der Statistik-Endpunkt von PufferPanel meldet nur CPU-Prozent und Arbeitsspeicher: keine Festplatte, kein Netzwerk, keine Laufzeit. Zwei der vier Standarddiagramme stünden dauerhaft leer, Verbrauchsdiagramme sind für diesen Provider deshalb aus. Gemessene Abrechnung ist auf Daten, die es nicht gibt, nicht möglich.
• Keine Konsole im Dashboard. Die Konsole von PufferPanel ist poll-basiert statt ein Live-Terminal; ein spezifikationskonformer WebSocket-Handshake auf /console ergibt 200 JSON statt 101. Ihre Kunden bekommen die Konsole in PufferPanel selbst.
• Keine kapazitätsbewusste Platzierung. PufferPanel zeigt seine Nodes, aber nicht deren Arbeitsspeicher, Festplatte oder CPU. Ein Panel mit mehreren Nodes wird nach Namensreihenfolge gewählt statt nach freiem Platz. Sie sind der Kapazitätsplaner.
• Kein Planwechsel in einem Aufruf. Einen Plan zu wechseln ist eine Neuinstallation, mit den Folgen für Kundendaten, die das mit sich bringt.
• Kein Inventarabgleich. Der _ListAccounts-Sync von WHMCS beendet jeden Dienst, der in der Antwort fehlt, und „fehlt“ hat harmlose Ursachen: ein schmalerer API-Scope, ein auf einen Teil des Inventars beschränktes Mitglied, eine Ratenbegrenzung, eine kurze Seite, deren Cursor nicht verfolgt wurde. Jede davon würde Kundenmaschinen löschen.

Aus WHMCS statt aus Code

Betreiben Sie bereits WHMCS, liefert Provibr ein Provisionierungsmodul als einfaches Zip, das Sie selbst installieren. Ein WHMCS-Produkt zeigt auf einen Provibr-Plan; der normale Bestellablauf von WHMCS erledigt Anlegen, Sperren, Freigeben und Beenden. Zwei Entscheidungen darin lohnen sich auch in Ihrer eigenen Brücke:

Eine noch laufende Lieferung gilt als erfolgreich. Läuft das Wartebudget ab, während der Installer arbeitet, meldet das Modul Erfolg: Die Bestellung ist angenommen, und WHMCS kennt keinen Status „wird installiert“ (Pending bedeutet dort es ist noch nichts geschehen, und das ist falsch). Ein Befehl, der wirklich fehlschlägt, ist etwas anderes: Der Dienst bleibt Pending, und der Administrator sieht warum.

Ein Server, den es schon nicht mehr gibt, ist eine erfolgreiche Beendigung. Ein 404 bedeutet mehreres zugleich (unbekannte ID, andere Organisation, für dieses Mitglied nicht sichtbar, bereits gelöscht), und für einen Beendigungs-Hook ist die richtige Handlung in allen Fällen dieselbe: Es gibt nichts mehr aufzuräumen.

Kapazität zählen, und wie das zum Mahnwesen passt

Die Plattform-Abrechnung zählt Kapazität, nicht Verbrauch, mit einer Regel, die alle im ersten Monat überrascht: Jeder Server zählt, ob er läuft oder nicht. Nur ein gesperrter Server zählt nicht, und ein gelöschter ebenso wenig: Eine Maschine zu stoppen macht keinen Platz frei.

Das passt gut zum Mahnwesen: Ein Kunde, den Sie sperren, zählt während der Sperre nicht und zählt wieder, sobald er zahlt und Sie freigeben.

PufferPanel neben allem anderen

Sie müssen sich nicht für ein Panel entscheiden. Provibr deckt seine Controlpanels, Hypervisoren und Gamepanels in einem Dashboard ab, mit einer API und einer Kapazitätszahl.

POST /v1/servers/{id}/actions/suspend tut dasselbe, ob darunter ein Pelican-Server, ein PufferPanel-Server oder ein DirectAdmin-Hostingkonto liegt. Die Unterschiede wohnen im Provider, nicht in Ihrem Integrationscode, und wo ein Provider etwas wirklich nicht kann, bekommen Sie eine Ablehnung, die die fehlende Fähigkeit nennt, statt eines stillen No-ops.