Nodes und Daemons

Wie Sie VMs direkt aus Opfield erstellen, lesen Sie unter Hosting-Anbieter. Verbundene Konten erscheinen unter Nodes > Providers. Die Anleitung behandelt Berechtigungen für VM-Stromversorgung, Firewall, Snapshots und Abrechnung.

Ein Node ist die dauerhafte Identität von Opfield für eine verwaltete Host-Rolle. Der Daemon meldet Hostname, Version, Zustand, Inventar, Metriken, Dienstadressen und rollenspezifische Fähigkeiten über eine ausgehende, authentifizierte Sitzung.

Opfield trennt die Zuständigkeiten Ingress, Docker, Storage, Build Worker, Monitoring und Relay. Wählen Sie bei der Registrierung genau die Rolle und verwenden Sie eine Daemon-Identität nicht für eine andere Vertrauensgrenze wieder.

Die Detailseite eines Nodes ist der wichtigste Ort, um Konnektivität, Fähigkeitsabweichungen, Update-Bereitschaft, Ressourcendruck, aktuelle Operationen und den zuletzt synchronisierten Zustand zu prüfen. Eine veraltete Momentaufnahme kann eine reine Lesediagnose unterstützen, autorisiert aber niemals eine Änderung.

Identität und Zustand

Das Erstellen eines Nodes erzeugt zunächst eine ausstehende dauerhafte Identität. Das generierte Registrierungstoken ist einmalig verwendbar und an diese Identität gebunden. Eine erfolgreiche Registrierung installiert ein Daemon-Zertifikat und macht aus dem Node einen verwalteten Host, der online ist; das Löschen und Neuerstellen des Eintrags erzeugt bewusst eine andere Identität.

Opfield unterscheidet mehrere Arten von Zustand:

• Sollzustand: was Operatoren in Opfield konfiguriert haben;
• gemeldeter Zustand: die neueste vom Daemon bestätigte Inventar- und Fähigkeitsmeldung;
• Laufzeitzustand: Live-Zustand der Dienste und aktive Operationen;
• zwischengespeicherte Momentaufnahme: das zuletzt bekannte Lesemodell, das verwendet wird, wenn ein Node kurzzeitig nicht verfügbar ist.

Zwischengespeicherte Daten unterstützen die Diagnose, autorisieren aber niemals eine Änderung. Aktionen, die den aktuellen Host-Zustand benötigen, schlagen sicher fehl (fail closed), wenn der Daemon offline ist oder seine Fähigkeiten veraltet sind.

Rollengrenzen

Rolle	Zuständig für
Ingress	nginx-Konfiguration, Zertifikate, Routen, Telemetrie zu Zugriff und Datenverkehr
Docker	Container, Deployments, Compose, Images, Volumes, Netzwerke, Builds und Migrationsendpunkte
Build Worker	isolierte Ausführung von Git-Builds und Zulassung von Artefakten
Storage	verwaltete PostgreSQL-, Key-Value- und ClickHouse-Engines, verwalteter SeaweedFS-Objektspeicher (ältere MinIO-Cluster laufen weiter), Speicher-Images, direkte Endpunkte, Datenbanktelemetrie sowie Backup- und Wiederherstellungsjobs; allgemeine Workloads werden abgelehnt
Monitoring	Host-Metriken ohne Zugriff auf den Lebenszyklus von Workloads
Relay	authentifizierter Node-Transport und unterstützte private Tunnel

Behandeln Sie Rollenbezeichnungen nicht als kosmetisch. Jedes Installationsprogramm, jedes Daemon-Profil, jeder Fähigkeitensatz, jedes Update-Artefakt und jede Berechtigungsgrenze ist unterschiedlich.

Betriebliche Prüfungen

Bestätigen Sie für jeden Produktions-Node:

• Hostname und Anzeigename bezeichnen den richtigen physischen Host;
• Dienstadressen sind von ihren vorgesehenen Gegenstellen aus erreichbar;
• Version und Kompatibilitätszustand sind aktuell;
• erwartete Fähigkeiten sind fehlerfrei und nicht nur vorhanden;
• für Speicher-, Arbeitsspeicher-, CPU- und Festplattendruck gibt es Alarme;
• Update- und Wiederherstellungsverfahren sind dokumentiert;
• der Node gehört zum richtigen Ordner und zu den richtigen Berechtigungs-Scopes.

Zuständigkeit und Vertrauensgrenze

Der Node-Eintrag und das Daemon-Zertifikat sind Identitäten der Control Plane, keine Aliase für eine IP-Adresse. Wird ein Host unter einem neu erstellten Node neu installiert, entsteht ein neuer Eigentümer, selbst wenn Hostname und Adresse unverändert sind. Ressourcen, Berechtigungen, Operationen und zwischengespeichertes Inventar der alten Identität gehen nicht über, nur weil der Ersatz denselben Anzeigenamen hat.

Schützen Sie den Host entsprechend seiner Rolle. Ein Docker oder Storage Node kann auf Anwendungsdaten zugreifen, ein Ingress Node hält privates Zertifikatsmaterial, ein Build Worker verarbeitet potenziell feindliche Repository-Eingaben, und ein Relay transportiert authentifizierte Steuerungs- und private Datenströme. Vermeiden Sie es, Rollen auf einem Host zu kombinieren, wenn dadurch eine Sicherheits- oder Fehlergrenze zusammenfällt. Opfield stellt getrennte Rollen bereit, weil sich ihre Privilegien und ihr betrieblicher Wirkungsradius unterscheiden.

Der Daemon baut die verwaltete Sitzung ausgehend auf, sodass der Routinebetrieb keinen allgemeinen Administrationsport des Daemons erfordert. Host-Patches, Firewall-Richtlinie, Zeitsynchronisation, Zustand des Speichers und der Netzwerkpfad zu Relay bleiben bei Ihnen. Opfield meldet diese Abhängigkeiten und verweigert Änderungen sicher, wenn sie ausfallen; es repariert weder den Host noch das Netzwerk.

Abnahme nach der Registrierung

Platzieren Sie keine Produktionsressourcen auf einem Node, unmittelbar nachdem sein Status auf online wechselt. Warten Sie auf eine frische Momentaufnahme von Inventar und Metriken und prüfen Sie dann die erwarteten Rollenfähigkeiten und Dienstadressen. Führen Sie eine rollenspezifische Operation mit geringem Risiko aus: Validieren Sie die nginx-Konfiguration auf Ingress, prüfen Sie einen Test-Workload auf Docker, führen Sie einen zugelassenen Test-Build auf einem Build Worker aus oder bestätigen Sie die Speicher-Vorabprüfung auf Storage.

Halten Sie vor der Zuweisung den Wiederherstellungsweg fest: wie der Host erreicht wird, wo die Logs von Daemon und Rollendiensten liegen, welche persistente Identität oder welche Daten erhalten bleiben müssen und welche abhängigen Ressourcen nach einem Neustart geprüft werden müssen.

Fahren Sie vor der Registrierung mit Node-Rollen und Installation und vor dem Produktionseinsatz mit Node-Updates und Offline-Verhalten fort.