Verwaltete Instanzen

Diese Seite ist für Hoster, die Rechner mit Envoryx darauf vermieten, und für deren Kunden, die wissen wollen, warum auf ihrer Instanz manches anders aussieht. Wenn du Envoryx für dich selbst betreibst, betrifft dich nichts davon: Ohne Tarif und ohne Fleet Manager verhält sich Envoryx genau wie immer.

Ein Tarif bindet nur, wer ihn nicht ändern kann. Gedacht ist das also für verwaltete Rechner: Der Kunde bekommt Envoryx (die Weboberfläche, SSH in die Projekt-Container, SFTP, die API), aber keine Shell auf dem Rechner und keinen Zugriff auf den Docker-Socket.

Tarife

Ein Tarif ist die Datei /config/plan.json. Sie legt fest, wie viele Projekte und aktive Benutzer eine Instanz haben darf, wie viel Speicherplatz in GiB ihre Projekte belegen dürfen (Verzeichnisse, Volumes und Backups), welche Runtimes neue Projekte nutzen dürfen, welche Funktionen abgeschaltet sind (addons, customImages, branchEnvironments, externalServices, offsite, ideGateway) und welche Instanz-Einstellungen der Hoster festlegt, etwa die Basis-Domain.

{
  "name": "Starter",
  "limits": { "projects": 5, "users": 3, "diskGb": 50 },
  "runtimes": ["php", "node"],
  "disabled": ["customImages", "ideGateway"],
  "settings": { "baseDomain": "c1042.example.net", "forceHttps": true }
}

Envoryx schaut alle 30 Sekunden nach der Datei. Ein Tarif begrenzt nur, was danach kommt: Ein kleinerer Tarif löscht kein Projekt, er lehnt nur das nächste ab. Die Ablehnung kommt mit einer klaren Meldung zurück (HTTP 403, Code plan_limit), und die Oberfläche blendet aus, was der Tarif nicht enthält: Der Runtime-Tab eines Projekts bietet nur die Runtimes des Tarifs an (plus die, die das Projekt schon hat), und am Projekt- oder Benutzerlimit sind Neues Projekt und Benutzer einladen mit einem Hinweis gesperrt. Der Kunde findet den Tarif und wie viel davon belegt ist unter Einstellungen → Allgemein; festgelegte Einstellungen tragen ein Schloss. Alle Felder stehen in DEPLOYMENT.md unter Plans.

Die Karte Plan (deutsche Oberfläche: Tarif) unter Einstellungen, Allgemein: Tarif Starter, vom Hoster als Customer 1042 verwaltet und verbunden, 3 von 5 Projekten, 2 von 3 Benutzern, 7,3 GB von 50 GB Speicherplatz, die Runtimes PHP und Node.js, Custom Images und IDE-Gateway nicht enthalten, Basis-Domain und HTTPS festgelegt

Der Fleet Manager

plan.json auf jeden Rechner von Hand zu schreiben, wird schnell lästig. Der Fleet Manager ist ein eigener Dienst, in dem du Tarife und Instanzen an einer Stelle pflegst. Du legst dort eine Instanz an und bekommst ein Einmal-Token; die Instanz startet mit

ENVORYX_FLEET_URL=https://fleet.example.net
ENVORYX_FLEET_TOKEN=…

und koppelt sich beim ersten Start mit einem eigenen Schlüssel (liegt in /config/fleet.json, nie in einem Instanz-Backup). Danach hält sie eine Verbindung zum Manager offen. Sie baut die Verbindung selbst auf, der Rechner des Kunden braucht also keinen offenen Port. Der Manager schickt den Tarif, und die Instanz meldet jede Minute ihre Version, Projekte, Benutzer, den Speicherplatz und ihre Backups.

Auf der Instanz sieht der Kunde unter Einstellungen → Allgemein den Hinweis Von deinem Hoster verwaltet.

Hast du eine Instanz aus dem Manager entfernt und willst sie zurück, leg sie dort wieder an, um ein neues Token zu bekommen, setz es auf der Instanz als ENVORYX_FLEET_TOKEN und starte sie neu. Ein Token, mit dem sie sich noch nicht gekoppelt hat, lässt sie sich neu koppeln; /config/fleet.json musst du dafür nicht löschen.

Eine Instanz sperren

Bleibt eine Rechnung offen, kannst du die Instanz im Manager sperren, auf Wunsch mit einer Nachricht an den Kunden. Die Instanz stoppt dann alle Projekte (so, als hätte der Kunde sie gestoppt), lehnt alles andere ab und zeigt angemeldeten Benutzern nur noch eine Seite mit deiner Nachricht und einem Abmelden-Button. API, MCP, SSH und SFTP lehnen ebenfalls ab. Gelöscht wird nichts.

Die Seite, die eine gesperrte Instanz nach der Anmeldung zeigt: Diese Instanz ist gesperrt, die Nachricht des Hosters zu einer offenen Rechnung, der Hinweis, dass die Projekte gestoppt und die Daten erhalten sind, der Zeitpunkt der Sperre und ein Abmelden-Button

Hebst du die Sperre auf, ist die Instanz wieder offen, startet aber kein Projekt von selbst: Was läuft, entscheidet der Kunde. Eine gesperrte Instanz ist nach einem Neustart weiter gesperrt, und sie bleibt es auch, wenn du sie aus der Flotte entfernst. Heb die Sperre also vorher auf, wenn der Kunde sie weiter nutzen soll.

Support-Zugang

Manchmal musst du dir die Instanz eines Kunden ansehen, um zu helfen. Envoryx lässt dich nur herein, wenn die Admins des Kunden das erlauben, unter Einstellungen → Allgemein → Support-Zugang: für eine Stunde, einen Tag, eine Woche oder bis auf Widerruf. Solange es erlaubt ist, bietet der Manager Support-Login an. Das öffnet die Instanz in einem neuen Fenster, angemeldet als Benutzer “Hoster support”.

Dieser Benutzer ist Admin, zählt aber nicht zu den Benutzern des Tarifs, taucht in keiner Liste auf und kann sich nicht mit Passwort anmelden. Er kann keine API-Tokens anlegen, keine SSH-Schlüssel hinterlegen und seinen Zugang nicht selbst verlängern. Außerdem bleibt er von allem weg, was darüber entscheidet, wer hereinkommt: Er kann keine Benutzer einladen, ändern oder löschen, ihre Projektrollen nicht ändern, keine Einladungs- oder Passwort-Links erzeugen, Single Sign-on und die SSH-Schlüssel der Instanz nicht anfassen, und er kann kein Instanz-Backup einspielen, das die Konten und Tokens dieses Backups zurückbrächte. Diese Teile der Einstellungen sieht er nur lesend. Nichts, was du tust, überdauert also die Zustimmung des Kunden. Nimmt er sie zurück, endet deine Sitzung sofort. Jeder Support-Login steht mit dem Namen des Hoster-Benutzers, der ihn angefordert hat, im Audit-Log.

Die Karte Support-Zugang, als erlaubt markiert: Der Support des Hosters darf sich bis zur angegebenen Zeit anmelden, daneben der Button zum Zurücknehmen

Backups für den Hoster

Ein Tarif kann ein Offsite-Ziel von dir nennen (S3, SFTP oder WebDAV, mit denselben Feldern wie die Offsite-Ziele einer Instanz). Jede Instanz mit diesem Tarif kopiert dann ihr tägliches Instanz-Backup dorthin, in einen eigenen Ordner (<prefix>/<Instanz-ID>), und mit projects auch ihre geplanten Projekt-Backups. Schalte die Verschlüsselung ein, damit die Kopien versiegelt sind, bevor sie den Rechner verlassen.

Der Kunde sieht das Ziel unter Einstellungen → Backups mit dem Vermerk von deinem Hoster und kann nach dem Verlust des Rechners Kopien daraus holen, es aber weder ändern noch löschen. Es funktioniert weiter, wenn der Tarif die eigenen Offsite-Ziele des Kunden abschaltet: Backups gehen trotzdem hoch, und Kopien lassen sich trotzdem daraus holen.

Im Manager kannst du sofort ein Instanz-Backup anstoßen und siehst die zehn neuesten, samt denen, die bei deinem Ziel angekommen sind. Eine Instanz, deren letztes Backup älter als zwei Tage ist, wird als “Braucht Aufmerksamkeit” markiert.

Updates

Der Manager kann eine Instanz, oder alle mit einer älteren Version, auf ein anderes Release aktualisieren. Die Instanz lädt das Image dieser Version und startet einen kurzlebigen Helfer-Container. Der ersetzt den Envoryx-Container durch einen neuen mit denselben Einstellungen und wartet auf dessen Health-Check. Kommt die neue Version nicht hoch, holt der Helfer den alten Container zurück, und hat die neue Version die Datenbank schon geändert, stellt die alte sie aus dem Backup von direkt davor wieder her. Die Projekt-Container laufen die ganze Zeit weiter; nur ihre Adressen sind für die paar Sekunden des Wechsels nicht erreichbar, weil der Proxy Teil von Envoryx ist.

Wie das letzte Update gelaufen ist, steht im Manager und im Audit-Log der Instanz. Ein gescheitertes Update wird sofort gemeldet, auch wenn das neue Image so kaputt ist, dass der Helfer gar nicht erst läuft. Solange ein Update läuft, lehnt der Manager ein zweites für dieselbe Instanz ab.

Für Updates aus dem Manager muss Envoryx in einem Container laufen, den es selbst findet; auf Unraid nimm lieber Unraids eigenes Update, damit das Template passt.