Eine Instanz ist eine Installation des betreuten Produkts – etwa "Produktiv", "Test" oder die Installation eines bestimmten Kunden. Jede Instanz hat eine Kennung und ein geheimes Token.
Alles dazu unter Instanzen in der Oberfläche.
manage-client/config.php der Instanz eintragen.Kennungen dürfen Buchstaben, Zahlen, Punkt, Unterstrich und Bindestrich enthalten,
müssen mit einem Buchstaben oder einer Zahl beginnen und höchstens 120 Zeichen lang
sein. Sie erscheinen im Dateipfad der Backups; sprechende Namen wie example-prod und
example-test zahlen sich aus.
Mit dem Token kann eine Instanz Releases herunterladen und Backups hochladen. Sie kann nicht Backups herunterladen und nicht Releases verändern; beides erfordert die Anmeldung an der Oberfläche.
Instanzen → Token erneuern. Das alte Token verliert sofort seine Gültigkeit;
die Instanz meldet danach Authentifizierung fehlgeschlagen, bis das neue Token
eingetragen ist. Kurze Ausfälle von Cron-Jobs sind also einzuplanen.
Anlässe: Verdacht auf Kompromittierung, Personalwechsel, Übergabe eines Projekts.
Deaktivieren lässt die Instanz bestehen, weist aber jede API-Anfrage mit 403
ab. Der richtige Weg, wenn eine Installation vorübergehend stillgelegt wird oder
etwas unklar ist – das Token bleibt gültig und die Instanz ist mit einem Klick
wieder betriebsbereit.
Entfernen löscht den Registereintrag. Die gespeicherten Backups bleiben erhalten und unter Backups sichtbar und herunterladbar; sie werden dort als "nicht mehr registriert" gekennzeichnet. Neue Uploads sind nicht mehr möglich.
Die Übersicht zeigt für jede Instanz:
| Feld | Herkunft |
|---|---|
| Status | aktiv, inaktiv (länger als 7 Tage nicht gesehen) oder deaktiviert |
| Version | letzte Meldung der Instanz |
| Update | Vergleich dieser Version mit dem aktuellen Release |
| Zuletzt gesehen | jede authentifizierte Anfrage aktualisiert diesen Wert |
| Letztes Backup | Zeitpunkt des letzten empfangenen Backups |
| Offene Migrationen | aus dem Heartbeat der Instanz |
inaktiv bei einer laufenden Installation bedeutet meist, dass der Cron-Job für
den Heartbeat nicht läuft. Ohne Cron meldet sich eine Instanz nur, wenn jemand die
Oberfläche im Projekt benutzt.
Offene Migrationen sind das wichtigste Warnsignal: Sie bedeuten, dass ein Update zwar ausgerollt wurde, ein Teil des Post-Update-Schritts aber fehlgeschlagen ist.
Der Ordner client-package/ enthält den Client und dessen vollständige
Dokumentation. Zum Weitergeben:
./scripts/build-client-package.sh --server-url https://manage.example.org
Das Ergebnis liegt unter build/manage-client-<datum>.zip. Mit --server-url ist
die Server-Adresse in der mitgelieferten config.sample.php bereits eingetragen;
die empfangende Seite ergänzt nur noch Kennung und Token.
Das Skript entfernt vor dem Packen jede config.php und alle Protokolldateien,
damit kein Token aus einer Testinstallation mitgeliefert wird.
Übliches Vorgehen für ein Produkt mit Test- und Produktivsystem:
| Instanz | Zweck |
|---|---|
produkt-test |
bekommt neue Releases zuerst |
produkt-prod |
folgt nach erfolgreichem Test |
Beide holen sich dasselbe latest. Wer ein Release nur auf dem Testsystem haben
will, veröffentlicht es und setzt vorübergehend das ältere wieder als aktuell –
oder rollt auf dem Testsystem mit update --force gezielt aus. Getrennte Kanäle
pro Instanz gibt es bewusst nicht; dafür wird ein zweiter Manage-Server ausgerollt.