Ressourcenmodell und Zuständigkeit

Opfield-Ressourcen haben stabile Identitäten, die sich von veränderlichen Laufzeitnamen oder Container-IDs unterscheiden.

Stabile Identitäten

Berechtigungen, Bindings, Quelleinstellungen, Health-Konfiguration, Operationsverlauf und Migrationszustand hängen an der Identität einer Opfield-Ressource. Laufzeitnamen, Prozess-IDs, Container-IDs, IP-Adressen und die Platzierung können sich ändern, ohne dass eine neue Produktressource entsteht. Diese Unterscheidung ermöglicht es Opfield, geeignete Laufzeitobjekte neu zu erstellen oder zu verschieben und dabei die Beziehungen zu erhalten, die Operatoren bewusst konfiguriert haben.

Das Neuerstellen eines verwalteten Workloads erhält seine Opfield-Identität und behält daher geeignete Beziehungen zu Routen, Bindings, Berechtigungen und Quellen bei. Das Duplizieren eines Workloads erstellt eine separate Ressource mit eigenem Zugriff und eigenem Lebenszyklusverlauf. Ein ausdrückliches Löschen entfernt die Berechtigungen, die der gelöschten Ressource gehören, sodass eine spätere Ressource mit demselben Anzeigenamen nicht versehentlich deren Befugnisse erbt.

Verwenden Sie stabile Ressourcen- und Operations-IDs, wenn Sie API-Antworten, Tasks, Ereignisse, Logs und Audit-Einträge miteinander in Beziehung setzen. Namen sind für Operatoren gedacht und können sich ändern oder über Nodes oder Ordner hinweg kollidieren. Eine Namensübereinstimmung ist kein ausreichender Beleg dafür, dass ein neu beobachtetes Laufzeitobjekt die Ressource ist, die Opfield zuvor verwaltet hat.

Grenzen der Zuständigkeit

Ein Compose-Projekt besitzt seine Dienstcontainer, benannten Volumes und nicht externen Netzwerke.
Ein Blue/Green-Deployment besitzt beide Laufzeit-Slots und seinen Rollout-Zustand.
Eine verwaltete Datenbank besitzt ihren Datenbankcontainer und die Identität des Engine-Eigentümers.
Ein Datenbank-Binding besitzt eine separate Anwendungsidentität mit minimalen Rechten.
Eine Route oder eine Additional Route kann ihr Secure-Link-Binding besitzen.
Interne Container, die Opfield gehören, liegen außerhalb der APIs für den Benutzer-Lebenszyklus.

Diese Grenzen verhindern, dass eine API auf niedrigerer Ebene den übergeordneten Lebenszyklus umgeht, der die Ressource erstellt hat. Ein untergeordnetes Objekt kann zur Diagnose sichtbar sein, ohne eigenständig veränderbar zu werden. So werden beispielsweise Deployment-Slots über das Deployment geprüft, Compose-Dienste über das Compose-Projekt und ein Secure Link einer Route über die Route, die ihn erstellt hat.

Zuständigkeit überträgt sich nicht automatisch auf referenzierte Abhängigkeiten. Eine Route, die ein wiederverwendbares Zertifikat oder eine Access List verwendet, besitzt diese Ressourcen nicht und löscht sie nicht. Ein Workload, der auf einem Node platziert ist, besitzt den Node nicht. Eine Pages-Route zeigt auf einen Tag, ohne das unveränderliche Deployment zu besitzen, das dieser Tag auswählt. Prüfen Sie vor dem Löschen oder einer Migration sowohl die eigenen untergeordneten Objekte als auch die referenzierten Abhängigkeiten, da für sie unterschiedliche Bereinigungsregeln gelten.

Opfield erstellt außerdem interne Laufzeitobjekte, mit denen Produktverhalten umgesetzt wird. Ihre Labels, Laufzeitnamen, Netzwerke, Volumes, Zugangsdaten, Connectoren und Task-Einträge sind Implementierungsdetails, sofern eine unterstützte Aktion sie nicht ausdrücklich bereitstellt. Direktes Löschen oder Umbenennen über die Docker-Werkzeuge des Hosts kann Abgleich, Routing, private Konnektivität oder Rollback zerstören.

Soll-, gemeldeter und Laufzeitzustand

Die Produktressource hält den dauerhaften Sollzustand in Opfield. Ihr zuständiger Daemon meldet Inventar, Fähigkeiten, Zustand und Ergebnisse von Operationen. Die Host-Laufzeit enthält den tatsächlichen Prozess, die Konfiguration, den Speicher und die Netzwerkanbindung. Diese Sichten können während einer Operation, eines Neustarts, einer Verbindungsunterbrechung oder eines Fehlers vorübergehend voneinander abweichen.

Ein erfolgreiches Speichern bedeutet, dass der Sollzustand angenommen wurde, nicht unbedingt, dass der Zuständige ihn angewendet hat. Verfolgen Sie den dauerhaften Task und warten Sie auf einen frisch gemeldeten Zustand. Ist ein Node offline, zeigt Opfield möglicherweise bereinigte, zuletzt bekannte Daten an, blockiert aber Änderungen, die aktuelle Zuständigkeit oder Fähigkeit erfordern. Stellen Sie den Zuständigen wieder her und lassen Sie den Abgleich zu, bevor Sie entscheiden, dass ein fehlendes Laufzeitobjekt manuell neu erstellt werden sollte.

Ordner organisieren unterstützte Ressourcen und können am eingeschränkten Zugriff mitwirken. Sie ändern weder Laufzeitvernetzung noch Platzierung oder Zuständigkeit für den Lebenszyklus. Das Verschieben oder Gruppieren einer Ressource in der Navigation verschiebt weder ihre Laufzeit noch überträgt es ihre abhängigen Ressourcen.

Ressourcen, die zu einer App gehören, befinden sich in den Umgebungen der App und erscheinen nicht in den allgemeinen Listen; öffnen Sie sie über die App. Ein Benutzer ohne apps:view sieht eine App trotzdem, wenn er über seine eigenen Berechtigungen eines ihrer Mitglieder sehen kann, aber nur die Umgebungen, die diese Mitglieder enthalten, und nur diese Mitglieder.

Ergebnisse der Suche und der Befehlspalette führen zur kanonischen Seite der Opfield-Ressource statt zu untergeordneten Implementierungsobjekten. So bleiben Aktionen, Audit-Verlauf, verwandte Ressourcen und Wiederherstellungsfunktionen an der stabilen Identität verankert, die für den Lebenszyklus zuständig ist.

Externe Ressourcen

Extern erstellte Compose-Projekte können anhand kanonischer Docker-Labels erkannt werden. Opfield kann ihre Dienste, ihren Zustand, ihre Health-Prüfungen, Logs und ihr Inventar anzeigen, externe Projekte bleiben aber schreibgeschützt, bis ein Operator sie mit vollständigem YAML und den erforderlichen Berechtigungen ausdrücklich übernimmt. Die Übernahme überträgt die künftige Verwaltung erst nach der Validierung und der Vorbereitung einer unveränderlichen Revision an Opfield; Opfield vertraut keinem per Label übergebenen Host-Pfad als Quellkonfiguration.

Externe Datenbanken bleiben in der Verwaltung des Betreibers. Opfield speichert ihre Verbindungseinstellungen verschlüsselt, testet die Konnektivität und kann erlaubte Werkzeuge bereitstellen, ist aber nicht für Engine-Upgrades, Speicher, Verfügbarkeit oder Löschung zuständig. Ab Personal können Datenbank-Backups sie sichern. Ebenso bleiben globale Docker-Images und bewusst externe oder gemeinsam genutzte Compose-Ressourcen außerhalb der Bereinigung projekteigener untergeordneter Objekte.

Sicheres Ändern und Löschen

Bevor Sie eine Ressource ändern, ermitteln Sie ihren Eigentümer, ihre eigenen untergeordneten Objekte, die referenzierten Abhängigkeiten, die aktive Operation, den Rollback-Kandidaten und die persistenten Daten. Nehmen Sie jeweils eine Lebenszyklusänderung über den obersten Eigentümer vor und prüfen Sie den resultierenden Zustand, die Beziehungen und den gemeldeten Zustand. Vermischen Sie keine direkten Änderungen am Host mit einer aktiven Opfield-Operation.

Löschen ist nicht die Umkehrung des Erstellens. Es kann Berechtigungen, Engine-Identitäten, Verbindungen einer Route, den Revisionsverlauf oder Rollback-Slots entfernen und dabei wiederverwendbare Zertifikate, Access Lists, externe Ressourcen oder persistente Volumes bewusst beibehalten. Lesen Sie die Bestätigung, lösen oder migrieren Sie Abhängigkeiten, sichern Sie benötigte Daten und verfolgen Sie den Lösch-Task bis zur Bereinigung. Wird die Bereinigung unterbrochen, behalten Sie den Opfield-Eintrag bei und nutzen Sie seinen Operationszustand für die Wiederherstellung, statt untergeordnete Objekte gewaltsam zu entfernen.