Opfield 2.12: Apps, Datenbanken auf mehreren Servern und ein neuer Name

Opfield 2.12.0 ist da. Anwendungen bekommen einen eigenen Ort, verwaltete Datenbanken können auf mehreren Servern laufen, und das Produkt trägt jetzt den Namen Opfield. Hier die Änderungen, die die meisten Nutzer bemerken werden. Die vollständige Liste steht im Changelog.

Apps und Umgebungen

Eine App bündelt jetzt alles, was eine Anwendung braucht: Container, Compose-Projekte, Datenbanken, Speicher, Key-Value-Stores, Routen und Pages. Jede App hat Umgebungen, etwa production und staging. Apps gibt es in jedem Plan.

• Jede Umgebung hat eigene Einstellungen. Variablen, Secrets, erlaubte Knoten und Zugriff werden pro Umgebung festgelegt. Container erhalten die Werte der Umgebung beim Anlegen, Aktualisieren und Neuerstellen, und die Seite der Umgebung listet die Workloads, die noch neu erstellt werden müssen.
• Promotion. Eine Umgebung lässt sich in eine andere übernehmen: genau die Images, die Compose-Revision und der Pages-Build, die in ihr laufen.
• Eine Seite pro App. Sie zeigt die Mitglieder jeder Umgebung mit Zustand, Alarmen und Aktivität. Ressourcen lassen sich direkt in einer App anlegen, in sie importieren oder wieder herausnehmen.
• Zugriff pro Umgebung. Apps haben eigene Berechtigungen, und Zugriff lässt sich auch nur für eine Umgebung vergeben. Apps lassen sich außerdem über die REST API, MCP und den KI-Assistenten verwalten.

Eine App lässt sich herunterfahren und wieder starten. Für einen Sicherheitsvorfall gibt es einen Kill switch: Er trennt die Container der App von ihren Netzwerken, hält ihre Secure Links geschlossen und friert ihre Mitglieder ein. Wird er aufgehoben, ist alles wieder wie vorher. Apps und Umgebungen haben außerdem eigene Wartungs-Zugangscodes und eine Wartungsseite für ihre Routen.

Datenbanken und Speicher auf mehreren Servern

In Business und Enterprise können verwaltetes PostgreSQL, Key-Value-Stores, ClickHouse und Speicher auf 2 bis 5 Servern laufen. Ein Primary nimmt Lese- und Schreibzugriffe an, die Kopien folgen ihm, und eine davon übernimmt, wenn der Primary ausfällt.

Das Failover zwischen diesen Servern funktioniert auch, wenn Opfield selbst nicht erreichbar ist. Relays, die in Settings > Relay erlaubt sind, und Docker-Knoten auf anderen Hosts dienen als Witnesses, die mitentscheiden, welcher Server Primary ist.

Einstellungsänderungen, Versionsupdates und Neustarts laufen Server für Server, ein Knoten-Update übergibt seinen Primary zuerst, und Backups lesen von einer aktuellen Kopie. Das Dashboard zeigt Datenbanken und Speicher an, die Aufmerksamkeit brauchen. Nach der Kulanzfrist der Lizenz schalten sie weiter um und lassen sich weiter reparieren; nur das Einschalten, das Hinzufügen von Servern und Einstellungsänderungen warten auf eine erneuerte Lizenz.

Neue Key-Value-Stores laufen mit Valkey und den Modulen JSON, Bloom und Search. Move to Valkey prüft einen bestehenden Redis-Store und zieht ihn auf demselben Knoten nach Valkey um. Backups gelöschter Datenbanken lassen sich jetzt auflisten und wiederherstellen.

Der Name Opfield und eine ruhigere Oberfläche

Name, Logo, Farben und Schriften von Opfield sind jetzt in der Konsole, auf der Anmeldeseite, der Statusseite, in E-Mails, Installern und im KI-Assistenten. Die Seitenleiste hat 14 Einträge, und Routes und Certificates öffnen sich jeweils als eine Seite mit Tabs.

Bereiche, die Ihr Plan nicht enthält, sind ausgeblendet. Ein direkter Link darauf zeigt den Plan statt eines Fehlers.

Jeder Audit-Eintrag zeigt jetzt eine lesbare Aktion und Beschreibung, im Audit-Log, in seinem Export und in den Aktivitätsansichten.

Signierte Releases und die Fortführungszusage

Opfield-Images und Release-Binaries sind mit Sigstore signiert und kommen mit SBOMs. Die Anleitung Verifying Releases im Repository zeigt, wie Sie sie mit cosign prüfen.

Die Fortführungszusage (Continuity Grant) geht jetzt weiter: Wird Opfield eingestellt, steht der Quellcode des letzten Releases einschließlich des kommerziellen Kerns unter der MIT-Lizenz zur Verfügung, und Schlüsselinhaber können ihn ohne den Lizenzdienst weiter betreiben. Außerdem findet Opfield den Lizenzdienst über eine signierte Adressliste und nimmt die nächste Adresse, wenn eine nicht antwortet.

Eine Installation auf einen neuen Host umziehen

Die ganze Installation lässt sich in Settings > General in eine verschlüsselte Datei exportieren und auf einem anderen Host wiederherstellen, im Einrichtungsassistenten oder mit install.sh --restore. Knoten und Relays lassen sich vorab über die neue Adresse informieren.

Außerdem in diesem Release

• Der Eigentümer der Maschine eines Relays kann das Relay schützen: Opfield hat dann darüber keinen Konsolen-, Datei- oder Host-Zugriff.
• install.sh --domain und --acme-email stellen die Konsole auf Port 443 bereit, mit einem Let's-Encrypt-Zertifikat, das sich selbst erneuert.
• Eine Installation lässt sich mit einem Code in Settings > Cloud mit einem Opfield-Cloud-Konto verbinden. Die Anfragen dieser Verbindung werden im Audit erfasst und aufgelistet.

So aktualisieren Sie

Installationen auf 2.11.4 oder älter bekommen automatisch zuerst 2.11.5 angeboten und danach 2.12.0. Aktualisieren Sie zuerst Opfield, dann die Docker-, nginx- und Monitoring-Knoten, dann den Relay Pool. Updates und der Installer kommen jetzt von get.opfield.dev, Images von ghcr.io/opfield/opfield, daher müssen Firewalls get.opfield.dev zulassen. Die bisherigen Adressen funktionieren weiter.

2.12.1 folgte einen Tag später und bringt den Namen überallhin: Knoten, Relays, API, Webhooks und Audit-Ereignisse. Neue API-Tokens beginnen mit opf_, bestehende Tokens funktionieren weiter.

Die Details jeder Änderung stehen im Changelog, die Anleitungen zu Apps und Datenbanken auf mehreren Servern in der Dokumentation.