Opfield 2.12.3

Opfield 2.12.3 ist da. Der Großteil der Arbeit an diesem Release floss in drei Dinge: Festplatten laufen nicht mehr voll, der Zugriff von Agenten ist sicherer, und viele Kanten bei Git-Builds, Pages und verwalteten Datenbanken sind geglättet. Hier die Änderungen, die die meisten Nutzer bemerken werden. Die vollständige Liste steht im Changelog.

Festplatten bleiben im Rahmen

Eine Steuerzentrale, die Builds, Images und Logs auf vielen Servern verwaltet, kann unbemerkt eine Festplatte füllen. In 2.12.3 hat alles, was wächst, eine Grenze.

• Die interne Registry behält zwei Builds pro Container, löscht die Builds entfernter Quellen und nimmt keine neuen Builds mehr an, wenn ihre Festplatte zu 90 % voll ist.
• Docker-Knoten entfernen Images, die seit 12 Stunden niemand verwendet hat. Jeder Container behält das Image, mit dem er läuft, und eines für ein Rollback.
• Container-Logs auf Docker-Knoten bleiben begrenzt, auch bei Containern, die vor Opfield oder an Opfield vorbei angelegt wurden. Nginx-Knoten halten Routen-Logs unter einer Größengrenze und entfernen die Logs gelöschter Routen.
• Postgres-WAL und Replikationsslots füllen keine Datenbankfestplatte mehr.
• Housekeeping hält die eigenen Daten von Opfield auch dann begrenzt, wenn es ausgeschaltet ist, und läuft sofort, sobald eine Opfield-Festplatte zu 90 % voll ist. Außerdem zeigt es, was jede Festplatte füllt: die größten Tabellen, Redis, Container-Logs und alte Images pro Knoten.

Neue eingebaute Alarme warnen rechtzeitig: Festplattenalarme bei 85 % für jede Datenfestplatte eines Knotens, volle Opfield-Festplatte, volle Datenbankfestplatten und ein Housekeeping, das nicht läuft.

Schutz für Konsolenbefehle von Agenten

Der Assistent und MCP-Clients können Befehle in der Konsole eines Knotens ausführen. Sie laufen als root, damit ein Agent einen Knoten tatsächlich reparieren kann. Docker, containerd und Podman sind in dieser Konsole ausgeblendet: Ein Befehl mit Docker wird abgelehnt, und die Antwort nennt das Opfield-Werkzeug, das stattdessen zu verwenden ist.

Das ist ein Schutz vor Versehen, keine Sicherheitsgrenze. Er verhindert, dass ein Agent einen verwalteten Container aus Versehen an Opfield vorbei ändert. Außerdem können Agenten keine Befehle mehr per SSH auf Hosts ausführen, die Opfield-Knoten sind.

Wird ein verwalteter Container trotzdem von Hand gestoppt, geändert oder entfernt, löst der neue eingebaute Alarm „Container changed outside Opfield“ aus und erklärt, was die Änderung bedeutet.

Zugriffsregeln in der richtigen Reihenfolge

Die Regeln einer Zugriffsliste werden von oben nach unten geprüft, und der erste Treffer gilt. Bisher ließ sich die Reihenfolge nicht ändern, sodass eine Allow-Regel nach einem breiten Deny nie greifen konnte. Jetzt lassen sich Regeln in der Oberfläche, über die API und per MCP umsortieren, und Regeln, die nie greifen können, werden markiert.

Failover-Reihenfolge für Datenbanken und Speicher

Für verwaltetes Postgres, Key-Value-Stores, ClickHouse und S3-Speicher mit Verfügbarkeit lässt sich jetzt die Failover-Reihenfolge festlegen: welcher Server zuerst übernimmt, wenn der primäre ausfällt.

Registry in S3

Die interne Registry kann ihre Daten in S3 statt auf der Festplatte des Opfield-Hosts speichern. Beim Wechsel des Speichers wird jedes Image geprüft, das die Registry für Workloads vorhält.

Pages und Fehlerseiten

Pages-Projekte liefern für fehlende Pfade ihre eigene 404.html mit Status 404 aus.

Jede Seite, die nginx selbst erzeugt (Fehler, abgewiesene Clients, nicht erreichbare Upstreams, der Default-Server), ist jetzt eine Opfield-Seite. Die eigenen Fehlerseiten Ihrer Anwendungen werden unverändert durchgereicht.

Git-Quellen

• Ein Container mit Git-Quelle lässt sich auf den vorherigen Build zurücksetzen: im Tab Source, über die API oder per MCP.
• Ein fehlgeschlagener Build zeigt den fehlerhaften Dockerfile-Schritt und dessen Exit-Code, und eine Quelle sagt, warum ein Build fehlschlug oder nichts ausgerollt hat.
• Umgebungsvariablen, Secrets und Volumes lassen sich vor dem ersten Build setzen, und der erste Build startet sofort.
• Die Sicherheitsrichtlinie für Builds kann nur Schwachstellen blockieren, für die es einen Fix gibt, wahlweise für Anwendungspakete oder für alle Pakete.

Außerdem in diesem Release

Routen hinter Cloudflare sehen die echte Client-IP in Zugriffslisten, Rate Limits und Logs. Verwaltetes Postgres läuft auf Opfields eigenen Images, und PostGIS und pgRouting lassen sich bei Bedarf im Tab Extensions installieren.

Wichtig vor dem Update: Container-Archive verwenden jetzt das Opfield-Format (.ofca). Archive, die mit früheren Versionen exportiert wurden, lassen sich nicht importieren.

Selbst gehostete Installationen aktualisieren Sie wie gewohnt. Verwaltete Cloud-Installationen werden in ihrem Wartungsfenster aktualisiert.