Lebenszyklus- und Sicherheitsmodell

Opfield unterscheidet zwischen einer angeforderten Operation und ihrem geprüften Ergebnis.

Diese Unterscheidung ist immer dann wichtig, wenn Arbeit die Control Plane, Relay, einen verwalteten Daemon und eine Host-Laufzeit durchläuft. Eine API-Antwort kann bestätigen, dass Opfield eine Anweisung validiert und erfasst hat, während der zuständige Daemon sie noch anwendet. Verwenden Sie den dauerhaften Zustand der Ressource, den Task, Ereignisse, den Health-Zustand und Logs, um das tatsächliche Ergebnis festzustellen.

Sollzustand und beobachteter Zustand

Die Control Plane speichert die Sollkonfiguration und den Operationszustand vor dem Versand. Daemons melden das beobachtete Inventar, Fähigkeiten, Zustand und Laufzeitzustand. Opfield vergleicht diese Sichten und erfasst die Arbeit, die nötig ist, um sie zur Deckung zu bringen.

Der Sollzustand übersteht einen Neustart der Anwendung, eine vorübergehende Unterbrechung von Relay, einen erneuten Verbindungsaufbau eines Daemons oder einen Neustart des Hosts. Der beobachtete Zustand kann veralten, solange der Zuständige nicht verfügbar ist. Eine bereinigte, zuletzt bekannte Momentaufnahme kann zur Diagnose sichtbar bleiben, beweist aber nicht, dass die Laufzeit noch existiert oder eine Änderung sicher ist.

Ein abgeschlossenes Ergebnis erfordert einen Beleg der zuständigen Komponente. Prüfen Sie bei einem Workload den Laufzeitzustand, den Health-Zustand, die Logs und seine Route oder private Abhängigkeit. Prüfen Sie bei einer Ingress-Änderung, ob nginx die Konfiguration angenommen hat, und testen Sie den externen Hostnamen. Prüfen Sie bei einem Datenbank-Binding die Verbindung des Bindings auf dem Secure-Link-Connector des Nodes, die Engine-Identität und eine echte Anwendungsabfrage.

Lebenszyklus einer Operation

Lang laufende Arbeit wird durch einen dauerhaften Task oder eine dauerhafte Operation dargestellt. Typische Phasen sind eingereihte Arbeit, Versand an einen Zuständigen, Vorbereitung auf dem Host, Validierung, Anwendung oder Umschaltung, Prüfung und Bereinigung. Die genauen Phasen und das Abbruchverhalten hängen von der Ressource ab.

Notieren Sie die ID des Tasks oder der Operation, bevor Sie eine Änderung verlassen. Ein Neuladen der Seite sollte sich wieder mit demselben dauerhaften Eintrag verbinden. Eine Zeitüberschreitung im Browser, eine verlorene Antwort oder ein unterbrochener Datenstrom beweist nicht, dass der Zuständige den Befehl nie erhalten hat. Prüfen Sie sowohl den Task als auch den aktuellen Ressourcenzustand, bevor Sie ein Erstellen, Neuerstellen, eine Migration oder ein Löschen doppelt senden.

Fortschritt ist ein Beleg, den der zuständige Worker oder Daemon meldet, keine Browser-Animation. Ein abschließender Erfolg sollte der Nachbedingung entsprechen, die die Operation festlegt. Ein abschließender Fehler sollte genug Kontext zu Phase, Fehler und Anfrage bewahren, um die nicht erfüllte Voraussetzung zu erkennen, ohne die Aktion blind zu wiederholen.

Abgleich

Opfield wiederholt sichere idempotente Arbeit nach vorübergehenden Verbindungsunterbrechungen und gleicht Ressourcen nach einem Neustart der Anwendung oder eines Daemons ab. Der Abgleich verwendet den dauerhaften Eigentümer, den Sollzustand, die aktuelle Fähigkeitsmeldung und den beobachteten Laufzeitzustand. Er vermeidet es, einen Erfolg aus veraltetem Inventar abzuleiten oder ein fremdes Objekt mit gleichem Namen zu übernehmen.

Wenn Zuständigkeit, Fähigkeit, Leistungsumfang oder aktueller Zustand nicht nachgewiesen werden können, schlagen Änderungen sicher fehl (fail closed). Stellen Sie zuerst die fehlende Voraussetzung wieder her: Verbinden Sie den Node erneut, stellen Sie Relay wieder her, korrigieren Sie die Registry oder das Zertifikat, stellen Sie den Speicher wieder her oder lösen Sie die aktive Operation auf. Lassen Sie Opfield dann das Inventar aktualisieren und die ursprüngliche Ressource abgleichen.

Verwenden Sie direktes Löschen auf dem Host nicht als allgemeines Abgleichswerkzeug. Das Entfernen eines Containers, Netzwerks, Listeners, einer Engine-Rolle, eines Connectors oder einer Revisionsmarkierung, die Opfield gehören, kann die Belege zerstören, die zum Abschließen oder Zurücksetzen der Operation nötig sind. Verwenden Sie die unterstützten Aktionen zum Wiederholen, Reparieren, Abbrechen oder zur Wiederherstellung der Bereinigung, wenn sie verfügbar sind.

Destruktive Aktionen

Löschen, Rotation von Zugangsdaten, Umschaltung bei einer Migration, Archivimport, Abbau einer Datenbank und Austausch eines Zertifikats haben weiterreichende Folgen als gewöhnliche Bearbeitungen. Ermitteln Sie vor dem Start die zuständige Ressource, abhängige Routen und Bindings, persistente Daten, externe Clients, den Rollback-Kandidaten und die erwartete Bereinigung.

Lesen Sie den Bestätigungstext, statt anzunehmen, dass zusammenhängende Objekte derselben Löschrichtlinie folgen. Das Löschen eines Containers entfernt seine Ressourcenberechtigungen, löscht aber nicht automatisch ein separates Volume. Das Löschen einer Route setzt ihren Secure Link außer Kraft, löscht aber keine wiederverwendbaren Zertifikate oder Access Lists. Das Entfernen einer Quellverbindung stoppt künftige Builds, entfernt aber nicht automatisch bereitgestellte Artefakte. Das Löschen einer Datenbank erfordert, dass zuerst Bindings und die Aufbewahrung von Backups behandelt werden.

Prüfen Sie nach einer destruktiven Operation sowohl das beabsichtigte Fehlen als auch die beabsichtigt verbleibenden Objekte. Prüfen Sie die Bereinigung von Beziehungen, den Entzug von Zugriffen, die Speicheraufbewahrung, die öffentliche Erreichbarkeit, die Audit-Zuordnung und den abschließenden Task. Wird die Bereinigung unterbrochen, behalten Sie den dauerhaften Eintrag bei und stellen Sie über die erfasste Operation wieder her, statt Zwischenobjekte manuell zu entfernen.

Sicheres Verhalten im Offline-Fall

Wenn ein Node offline ist, zeigt Opfield möglicherweise eine bereinigte, zuletzt bekannte Momentaufnahme an. Es erlaubt keine Änderung, die sich auf einen ungeprüften aktuellen Zustand stützen würde. Bestehendes nginx, Container, verwaltete Datenbanken und andere bereits angewendete Dienste können unabhängig davon weiterlaufen.

Beginnen Sie die Wiederherstellung mit Stromversorgung und Netzwerk des Hosts, Systemzeit, DNS, dem Daemon-Dienst, der Zertifikatsidentität und der ausgehenden Erreichbarkeit von Relay. Vermeiden Sie es, den Node-Eintrag zu löschen, solange sich der alte Daemon erneut verbinden könnte: Das Löschen erzeugt eine andere dauerhafte Identität und kann einen sicheren Abgleich verhindern.

Warten Sie nach dem erneuten Verbindungsaufbau auf eine frische Fähigkeits- und Inventarmeldung. Prüfen Sie fehlgeschlagene oder unterbrochene Operationen, bevor Sie sie wiederholen, und prüfen Sie dann jede Ressourcenfamilie, die dem Node gehört. Eine grüne Verbindungsanzeige allein beweist nicht, dass Routen, Zertifikate, Workloads, Compose-Projekte, Datenbank-Bindings oder Monitoring konvergiert sind.

Der Lizenzzustand folgt demselben Prinzip. Ein abgelaufener Schlüssel oder ein nicht erreichbarer Lizenzdienst blockiert nach der dokumentierten Kulanzfrist neue Verwaltungsaktionen, die nur in kostenpflichtigen Tarifen verfügbar sind, aber Opfield stoppt, löscht oder entfernt deswegen keine Workloads, Routen, verwalteten Datenbanken oder veröffentlichten Pages-Deployments durch Abgleich. Siehe Downgrade und Ablauf.

Lang laufende Operationen

Builds, Migrationen, Deployments, Zertifikatsarbeiten, Updates und die Bereitstellung von Datenbanken sind dauerhafte Tasks. Verwenden Sie den Operationsverlauf und begrenzte Logs, statt eine Aktion zu wiederholen, weil eine Seite langsam erscheint. Eine zweite, konkurrierende Änderung zu starten, kann abgelehnt oder zurückgestellt werden oder einen schwierigeren Wiederherstellungsweg erzeugen.

Wiederholen Sie nur, wenn der Vertrag der Operation die Arbeit als wiederholbar kennzeichnet oder der vorherige Versuch bekanntermaßen abgeschlossen ist. Ein Abbruch erfolgt kooperativ, wenn der Zuständige ihn unterstützt. Force Cancel kann verhindern, dass Opfield weiter auf eine aufgegebene Operation wartet, beweist aber nicht, dass die zugrunde liegende Laufzeitaktion nie stattgefunden hat. Aktualisieren Sie den Zustand des Zuständigen und lösen Sie jede Markierung einer unterbrochenen Operation auf, bevor Sie die nächste Änderung vornehmen.

Disziplin bei Prüfung und Wiederherstellung

Legen Sie für jede wesentliche Änderung vor der Ausführung die erwartete Nachbedingung fest. Prüfen Sie über den Pfad des echten Nutzers: externes DNS/TLS/HTTP für öffentlichen Datenverkehr, eine Anwendungsabfrage für ein Datenbank-Binding, einen bezogenen unveränderlichen Digest und einen Health Check für ein Release oder erneuten Verbindungsaufbau und aktuelle Fähigkeiten für ein Node-Update.

Wenn eine Änderung fehlschlägt, bewahren Sie Task-ID, Request-ID, Phase, begrenzte Logs, Sollzustand und aktuellen Zustand des Zuständigen. Korrigieren Sie die eng umrissene Voraussetzung und setzen Sie über Opfield fort. Setzen Sie über den übergeordneten Eigentümer zurück, wenn eine bekannt fehlerfreie Revision, ein Deployment-Slot, ein Tag oder ein Quellartefakt vorhanden ist. Melden Sie eine Wiederherstellung erst, wenn der Zustand in Opfield und das extern beobachtete Verhalten übereinstimmen.