Architektur

Opfield trennt zentral verwaltete Absichten und Identitäten von der Ausführung auf den Hosts.

flowchart TB
    users["Benutzer und Automatisierung"] -->|"HTTPS / WebSocket"| opfield["Opfield-Anwendung"]
    opfield <-->|"Dauerhafter Zustand und Koordination"| state[("PostgreSQL / Redis")]
    opfield <-->|"Authentifizierter Dienstkanal"| relay["Opfield Relay<br/>TCP 9443"]

    subgraph hosts["Verwaltete Hosts"]
        direction LR
        daemons["Rollen-Daemons<br/>nginx · Docker · Storage · Build Worker · Monitoring"]
        workloads["Private Anwendungs- und Datenbankendpunkte"]
        daemons -.->|"Lebenszyklus auf dem Host"| workloads
    end

    relay <-->|"Ausgehende Steuerungssitzungen"| daemons
    relay <-->|"Private Datenströme"| workloads

Private Nutzdaten fließen direkt zwischen Relay und den Anwendungs- oder Datenbankendpunkten auf dem Host. Opfield autorisiert und koordiniert diese Pfade, die Opfield-Anwendung liegt aber nicht im Datenstrom.

Control Plane

Die Opfield-Anwendung ist die Control Plane. Sie verwaltet Benutzer, Gruppen, Scopes, Ressourcendefinitionen, den Sollzustand, Audit-Einträge, verschlüsselte Zugangsdaten von Integrationen, den Zustand lang laufender Operationen und Wiederherstellungsentscheidungen. PostgreSQL ist die dauerhafte maßgebliche Quelle für diese Einträge. Redis stellt die benötigte kurzlebige Koordination bereit, etwa Sitzungen, Caches, Warteschlangen, Ratenbegrenzungen und begrenzte Reservierungen; es ersetzt keinen dauerhaften Ressourcenzustand.

Operatoren und Automatisierung übermitteln ihre Absichten über die Operations Console, die REST API, OAuth, Remote-MCP oder AI Workspace an die Control Plane. Diese Einstiegspunkte teilen dieselben Backend-Prüfungen für Autorisierung, Validierung, Tarif-Leistungsumfang, Zuständigkeit und Lebenszyklus. Eine Aktion in der Oberfläche auszublenden ist nicht die Sicherheitsgrenze, und die Verwendung einer API oder eines KI-Werkzeugs umgeht keine Produktregel.

Die Control Plane betrachtet eine angenommene Anfrage nicht als Beweis dafür, dass die Arbeit auf dem Host abgeschlossen ist. Änderungen, die einen Daemon erfordern, werden als begrenzte Operationen erfasst und versendet. Der zuständige Daemon meldet Fortschritt und beobachteten Zustand, und Opfield stellt dauerhafte Tasks, Ressourcenstatus, Ereignisse und Logs bereit, damit ein Operator die Konvergenz prüfen kann.

Relay

Relay ist ein erforderlicher, langlebiger Dienst der Datenebene und der einzige öffentliche Inhaber von 9443/tcp. Verwaltete Daemons verbinden sich ausgehend über einen authentifizierten Transport; ihre Steuerungsschnittstellen sind normalerweise nicht im Netzwerk erreichbar. Die Opfield-Anwendung hält ihren gRPC-Listener intern und kommuniziert über eine authentifizierte Dienstgrenze mit Relay.

Relay transportiert den Steuerungsverkehr verwalteter Nodes und unterstützte private Datenströme. Es verwaltet weder nginx-Konfiguration noch Container, Datenbanken, Builds oder Monitoring-Arbeit auf dem Zielhost. Es transportiert nur die Datenströme, die Opfield autorisiert; es ist kein flaches Netzwerk zwischen Hosts. Jeder verwaltete Host muss seinen zugewiesenen Relay-Endpunkt erreichen: Relay öffnet keine Firewall-Regeln und überwindet kein NAT, um dorthin zu gelangen.

In der Produktion laufen mindestens zwei Relays auf anderen Hosts als dem Opfield-Host; siehe Wie viele Relays. Ist kein Relay verfügbar, schlagen neue Operationen verwalteter Nodes und neue Zulassungen privater Verbindungen sicher fehl (fail closed), weil Identität und Autorisierung nicht hergestellt werden können. Ein Ausfall nur der Opfield-Anwendung ist etwas anderes: Ein Relay lässt Verbindungen anhand einer signierten Richtlinie mit einer Lease zu, standardmäßig 72 Stunden, und lässt daher weiterhin autorisierte Verbindungen zu, während die Opfield-Anwendung gestoppt oder nicht erreichbar ist; siehe Relays ohne Opfield. Angewendete Workloads laufen lokal weiter. Bestehende Sitzungen der Datenebene laufen weiter, soweit das Protokoll und der Lebenszyklus der Autorisierung es erlauben; schließen Sie nicht aus einem fehlerfrei laufenden Anwendungsprozess, dass der Steuerungspfad wiederhergestellt ist.

Verwaltete Daemons

Jeder verwaltete Daemon hat eine begrenzte Rolle und Identität. Die Profile Ingress, Docker, Storage, Build Worker, Monitoring und Relay stellen unterschiedliche Fähigkeiten und Vertrauensgrenzen bereit. Ein Docker-Daemon kann nicht zu einem Datenbank-Daemon werden, nur weil ein Client eine Anfrage ändert, und APIs für den Benutzer-Lebenszyklus dürfen keine internen Container verändern, die Opfield gehören.

Daemons melden Fähigkeiten, Inventar, Zustand, Metriken, Dienstadressen und Ergebnisse von Operationen. Opfield verwendet diese Meldungen, um zu entscheiden, ob ein Host eine Aktion sicher ausführen kann. Installierte Pakete allein beweisen keine Fähigkeit: Der Daemon muss die Funktion als verfügbar und fehlerfrei melden. Ist ein Node offline oder ist seine Fähigkeitsmeldung veraltet, können Ansichten zum Lesen aus einer bereinigten Momentaufnahme verfügbar bleiben, Änderungen, die den aktuellen Host-Zustand benötigen, werden jedoch abgelehnt.

Der Daemon ist für die Ausführung auf seinem Host zuständig: Beispielsweise wendet nginx die Konfiguration an, Docker verwaltet Laufzeitobjekte, und ein Storage Node betreibt Datenbank-Engines. Opfield ist für die dauerhafte Identität und die Sollkonfiguration verwalteter Ressourcen zuständig. Diese Aufteilung erlaubt es einem Workload, während einer vorübergehenden Unterbrechung der Control Plane weiterzulaufen, ohne dass der Host einen neuen autorisierten Zustand erfinden kann.

Datenebene

Öffentlicher Anwendungsverkehr wird von Ingress Nodes mit nginx ausgeliefert. Eine Domain wählt die Platzierung, eine Route legt das Verhalten des Datenverkehrs fest, und Opfield verteilt Zertifikatsmaterial nur an Nodes mit aktivierten TLS-Routen, die es benötigen. Der nginx-Prozess ist daher Teil der Datenebene, während die Einträge zu Domain, Route, Zertifikat, Zugriff und Sollzustand in der Control Plane verbleiben.

Private Pfade verwenden eng definierte Mechanismen statt eines gemeinsamen flachen Netzwerks. Ein Secure Link von nginx zu einem Workload verwendet einen Connector, der Opfield gehört, und den Relay-Transport. Bindings verwalteter Datenbanken, Speicherverbindungen und Container-Links laufen über einen gemeinsamen Secure-Link-Connector pro Docker Node, jede Verbindung in einem eigenen privaten Netzwerk; ein Datenbank-Binding hat außerdem eine eigene Engine-Identität. Diese Mechanismen haben getrennte Zuständigkeiten und Diagnosen, auch wenn alle private Konnektivität bereitstellen.

Opfield Inference ist eine weitere separate Datenebene. Ein überwachter Inferenz-Kern führt die anbieterseitige Arbeit aus und wird über den Opfield-Proxy erreicht. Veröffentlichte Modell-IDs, Anbieterverbindungen, Benutzerlimits, Abrechnung und Autorisierung bleiben Angelegenheiten der Opfield Control Plane.

Betriebliche Grenzen

Verwenden Sie die Detailseite der Ressource und ihren dauerhaften Operationsverlauf, um festzustellen, wer für einen Fehler zuständig ist. Ein gespeicherter Sollzustand mit einem Node, der offline ist, deutet zuerst auf Host, Daemon, Zeit, DNS, Zertifikatsidentität oder Relay-Konnektivität. Ein verbundener Node mit einem erfolglosen Task deutet auf die rollenspezifische Laufzeit oder eine Voraussetzung. Eine fehlerfreie Laufzeit mit einer fehlschlagenden öffentlichen Anfrage deutet auf den Pfad über Domain, TLS, Route, Secure Link oder Anwendung.

Beheben Sie ein Zuständigkeitsproblem nicht, indem Sie untergeordnete Implementierungsobjekte direkt bearbeiten. Deployment-Slots werden von ihrem Deployment gesteuert, Container und Netzwerke eines Compose-Projekts von ihrem Compose-Projekt, Secure Links einer Route folgen ihrer Route, und Identitäten verwalteter Datenbanken folgen dem Lebenszyklus ihres Bindings. Direkte Änderungen am Host können Abweichungen erzeugen, die Opfield nicht sicher abgleichen kann.

Fehlermodell

Ansichten zum Lesen können bereinigte, zuletzt bekannte Momentaufnahmen verwenden, während ein Node offline ist. Solche Daten sind diagnostische Belege, keine aktuelle Autorisierung. Änderungen bleiben nicht verfügbar, solange Opfield Zuständigkeit, Fähigkeit, Leistungsumfang oder aktuellen Zustand nicht nachweisen kann.

Sollzustand und Operationseinträge sind dauerhaft, damit Opfield nach Neustarts der Anwendung, von Relay, eines Daemons oder eines Nodes abgleichen kann. Bei der Wiederherstellung sollte zuerst der ausgefallene Zuständige wiederhergestellt werden; warten Sie dann auf frische Inventar- und Fähigkeitsmeldungen und prüfen Sie anschließend jede abhängige Ressourcenfamilie. Vermeiden Sie es, als erste Reaktion Identitäten zu löschen und neu zu erstellen: Das kann Berechtigungen entfernen, Beziehungen zerstören oder dazu führen, dass sich der alte Daemon nicht mehr sicher verbinden kann.

Eine Ausfallmatrix Pfad für Pfad – einschließlich des Unterschieds zwischen einem fehlerfreien Relay, einem lokalen Relay, das mit dem Opfield-Host verloren gegangen ist, und einem unabhängigen externen Relay – finden Sie unter Verfügbarkeit, Kompatibilität und Grenzen.