Ihren ersten Node hinzufügen
Ein Node ist ein Linux-Host, der für eine bestimmte betriebliche Rolle in Opfield registriert ist. Auf dem Host läuft ein von Opfield verwalteter Daemon, der seine Identität und seine Fähigkeiten meldet und nur die für diese Rolle erlaubten Befehle erhält. Das Hinzufügen eines Nodes verschiebt keinen bestehenden Workload automatisch; es schafft vertrauenswürdige Kapazität, die Sie später auswählen können.
Verbindungsart wählen
Abschnitt betitelt „Verbindungsart wählen“Sie können einen Node auf eine der folgenden Arten hinzufügen:
- Auf Ihrem eigenen Server oder Ihrer eigenen VM: Führen Sie den von Opfield generierten Installationsbefehl gemäß der folgenden Anleitung aus.
- Eine VM über Opfield erstellen: Wenn Sie eine VM direkt über die Oberfläche bestellen möchten, verbinden Sie einen Hosting-Anbieter und wählen unter Add Node die Option Hosted VM. Opfield erstellt die VM und installiert den Daemon. Warten Sie, bis der Node bereit ist, nicht nur, bis der Anbieter die VM eingeschaltet hat.
Eine erfolgreiche Registrierung bedeutet, dass der Node mit der vorgesehenen Rolle und den vorgesehenen Fähigkeiten Online ist.
Die Rolle vor der Registrierung wählen
Abschnitt betitelt „Die Rolle vor der Registrierung wählen“| Rolle | Einsatzzweck | Wichtigste Entscheidung zur Zuständigkeit |
|---|---|---|
| Ingress | Routen, Bereitstellung von TLS-Material, Pages, nginx-Logs und Traffic-Metriken | Welche öffentlichen Adressen und Ports dieser Host belegt |
| Docker | Container, Deployments, Compose-Projekte, Images, Volumes, Netzwerke und Laufzeitoperationen | Welche Workloads sich diesen Docker-Host teilen dürfen |
| Storage | Von Opfield verwaltetes PostgreSQL, Key-Value-Stores und ClickHouse, verwalteter Objektspeicher und Datenbank-Backup-Jobs | Isolation von Speicher, Backups und zustandsbehafteten Workloads |
| Build Worker | Isolierte Builds aus Git-Quellen mit BuildKit/containerd | Build-Egress und Trennung von wiederverwendbaren Zugangsdaten |
| Monitoring | Unterstützte Monitoring-Erfassung | Welche Systeme der Node beobachten darf |
| Relay | Kapazität und Ausfallsicherheit der Secure-Link-Datenebene | Erreichbare angekündigte Adresse und physische Fehlerdomäne |
Wählen Sie eine Rolle nicht nur deshalb, weil ihr Installationsprogramm zufällig auf dem Host funktioniert. Eine Produktionsrolle sollte zur vorgesehenen Vertrauensgrenze, Netzwerkplatzierung, zum Speicher und zum Verantwortlichen für die Wiederherstellung des Hosts passen. Insbesondere Build Worker und Storage Nodes sollten normalerweise ausschließlich ihrem Zweck dienen.


Bevor Sie den Node erstellen
Abschnitt betitelt „Bevor Sie den Node erstellen“Bestätigen Sie, dass das Ziel ein unterstützter Linux-Host mit Root-Zugriff oder funktionierendem sudo, korrekter Systemzeit und zuverlässigem DNS ist und das öffentliche gRPC-Ziel von Opfield auf 9443/tcp ausgehend erreichen kann. Das Ziel ist der über Relay bereitgestellte Steuerungsendpunkt, den verwaltete Daemons verwenden; es kann ein direkter Host oder eine IP-Adresse sein, auch wenn die Opfield-Weboberfläche hinter einem Proxy liegt.
Bestätigen Sie außerdem die rollenspezifische Zuständigkeit:
- Ingress Nodes benötigen die vorgesehenen öffentlichen Listener und ein klares Betriebsmodell für DNS und TLS.
- Docker Nodes benötigen eine lokal unterstützte Docker Engine und ausreichend Kapazität für ihre Workloads; das Node-Installationsprogramm kann unterstützte Laufzeitkomponenten auf einem neuen kompatiblen Host vorbereiten.
- Storage Nodes benötigen geeigneten dauerhaften Speicher, die erforderlichen Loop- und Mount-Fähigkeiten und ausgehendes HTTPS zu
ghcr.io. Gehen Sie nicht davon aus, dass ein gewöhnlicher eingeschränkter LXC-Gast ausreicht: Er benötigt einen Pool von Loop-Devices, der für jede verwaltete Instanz und jedes gleichzeitige Backup dimensioniert ist; siehe Voraussetzungen für Storage Nodes und Docker Nodes. - Build Worker benötigen einen dedizierten Host oder einen äußeren unprivilegierten Container und ein freigegebenes Egress-Profil.
- Relay Nodes benötigen eine Adresse und einen Port, die von den beteiligten Opfield-, Docker-, Ingress- und Storage-Hosts erreichbar sind. Opfield öffnet weder die Firewall noch überwindet es NAT für Sie.
Den Node auf Ihrem eigenen Host registrieren
Abschnitt betitelt „Den Node auf Ihrem eigenen Host registrieren“- Öffnen Sie Nodes, wählen Sie Add Node und dann External VM.
- Wählen Sie die vorgesehene Rolle. Geben Sie bei Relay die Adresse ein, über die andere Teilnehmer den Relay-Worker erreichen.
- Geben Sie dem ausstehenden Node einen erkennbaren Namen, der seinen dauerhaften Zweck beschreibt, nicht ein temporäres Ticket oder den Namen einer Person.
- Erstellen Sie den Node und kopieren Sie den generierten Installationsbefehl. Er enthält ein einmaliges Registrierungstoken und den erwarteten Fingerabdruck des Opfield-Zertifikats.
- Führen Sie den Befehl auf dem Zielhost mit den erforderlichen Rechten aus. Entfernen Sie den Fingerabdruck nicht und ersetzen Sie die generierte Opfield-Adresse nicht, es sei denn, das konfigurierte öffentliche oder lokale Ziel ist falsch.
- Bewahren Sie die Ausgabe der Installation auf, bis sich der Daemon registriert hat und die Opfield-Oberfläche den Node als Online anzeigt.
- Öffnen Sie die Node-Details und vergleichen Sie gemeldeten Hostnamen, Rolle, Betriebssystem, Version, Adressen und Fähigkeiten mit der vorgesehenen Planung.
Der Daemon prüft das festgelegte Opfield-Zertifikat, bevor er das einmalige Token sendet. Nach erfolgreicher Registrierung erfolgt die dauerhafte Authentifizierung über Mutual TLS: Sowohl Opfield als auch der Node legen Zertifikate vor. Die wiederverwendbare Beziehung ist die registrierte Identität, nicht das Einrichtungstoken.
Erfolgskriterien
Abschnitt betitelt „Erfolgskriterien“Betrachten Sie die Registrierung erst dann als abgeschlossen, wenn:
- der Node Online ist, nicht nur erstellt oder ausstehend;
- sein Typ und Hostname korrekt sind;
- die gemeldete Version mit dem Opfield-Release kompatibel ist;
- die erwarteten Fähigkeiten vorhanden sind und keine Warnung zu einer Versionsabweichung angezeigt wird;
- der rollenspezifische Status fehlerfrei ist;
- sich der Node nach einem Neustart seines Daemon-Dienstes erneut verbindet;
- eine integrierte Update-Prüfung den konfigurierten Release-Kanal erreichen kann;
- der zuständige Operator die Scopes besitzt, um ihn ohne breiten Systemadministrator-Zugriff anzuzeigen und zu betreiben.
Bei Relay macht eine erfolgreiche Registrierung den physischen Host für den Relay-Pool verfügbar. Das Hinzufügen eines fehlerfreien Relays verschiebt bestehende Endpunkte nicht automatisch; prüfen Sie die Erreichbarkeit und verwenden Sie die ausdrückliche Rebalance-Operation, wenn Sie die Platzierung ändern möchten.
Prüfungen für Betreiber nach Rolle
Abschnitt betitelt „Prüfungen für Betreiber nach Rolle“- Ingress: Validieren Sie die nginx-Konfiguration, prüfen Sie die Dienstadresse, bestätigen Sie bei Bedarf die Ports 80/443 und öffnen Sie begrenzte nginx-Logs.
- Docker: Bestätigen Sie die Inventarsynchronisation, den Laufzeitstatus, den Dateisystemzugriff und jede erwartete GPU- oder Secure-Runtime-Fähigkeit.
- Storage: Bestätigen Sie das ausgewählte Speicherwurzelverzeichnis, die Durchsetzung der Kapazität und den Abschluss der Vorabprüfung, bevor Sie eine verwaltete Datenbank oder verwalteten Speicher erstellen.
- Build Worker: Bestätigen Sie den Zustand von BuildKit/containerd, das durchgesetzte Ressourcenprofil, die Verfügbarkeit des Scanners und die ausgewählte Egress-Richtlinie.
- Relay: Bestätigen Sie den Zustand von Supervisor und Worker, den angekündigten Endpunkt, die Anzahl aktiver Tunnel und die Platzierung in der Fehlerdomäne.
Fehler und sichere Wiederherstellung
Abschnitt betitelt „Fehler und sichere Wiederherstellung“Wenn die Registrierung nicht abgeschlossen wird, behalten Sie den ausstehenden Node während der Diagnose bei. Prüfen Sie den genauen generierten Befehl, die Systemzeit, DNS, die ausgehende Erreichbarkeit von 9443/tcp, den Zertifikatsfingerabdruck, das Log des Installationsprogramms und das Log des Daemon-Dienstes. Ein über Cloudflare geproxyter Web-Hostname ist nicht automatisch ein gültiges gRPC-Ziel.
Entfernen Sie das Zertifikats-Pinning nicht, damit die Verbindung gelingt. Damit wird aus einem Konfigurationsproblem ein Identitätsrisiko. Korrigieren Sie Settings > General und erzeugen Sie einen neuen Befehl, wenn das öffentliche oder lokale gRPC-Ziel falsch ist.
Ein ausstehender Node kann gelöscht und neu erstellt werden, wenn Sie bewusst eine neue Registrierungsidentität wünschen. Verwenden Sie niemals ein altes einmaliges Token erneut. Nach der Registrierung hat das Löschen rollenspezifische Folgen: Ein Relay mit aktiven Zuweisungen muss geleert werden, und ein Node, dem Workloads oder Daten gehören, sollte über das entsprechende Workload- oder Datenbank-Runbook außer Betrieb genommen werden, statt einfach aus dem Inventar entfernt zu werden.
Nächster Schritt
Abschnitt betitelt „Nächster Schritt“Sobald ein Ingress oder Docker Node online ist, fahren Sie mit Ihre erste Route veröffentlichen fort. Für rollenspezifische Produktionsprüfungen nutzen Sie Node-Rollen und Installation sowie Node-Updates und Offline-Verhalten.