Anforderungen und Planung

Geben Sie Opfield einen eigenen Host und betreiben Sie Anwendungen und Datenbanken auf verwalteten Nodes. Opfield verwaltet Benutzer und Berechtigungen, Ressourcenkonfiguration, Zertifikate, Operationen und den Audit-Verlauf und überwacht den Zustand jedes Nodes. Die Hosts selbst bleiben bei Ihnen: ihre Dimensionierung, Festplatten, Betriebssystem-Updates und Härtung.

Opfield ist eine privilegierte Control Plane

Der Opfield-Host hat Zugriff auf verschlüsselte Infrastruktur-Zugangsdaten und einen beschreibbaren Docker-Socket, der für signierte Updates, Wiederherstellung, Housekeeping und lokale verwaltete Dienste verwendet wird. Die Kontrolle über diesen Host entspricht faktisch Root-Kontrolle über die Opfield-Installation und kann jede verbundene Ressource im Rahmen ihres autorisierten Bereichs beeinflussen. Verwenden Sie eine dedizierte VM oder einen dedizierten Host, platzieren Sie ihn in einem eingeschränkten Verwaltungsnetz und teilen Sie ihn nicht mit fremden Workloads.

Die Form der Bereitstellung festlegen

Für eine kleine Evaluierung können die Opfield-Anwendung und ihre internen Dienste auf einem einzigen Linux-Host liegen. Produktionsumgebungen sollten diesen Host dennoch als Abhängigkeit der Control Plane behandeln, mit klarer Zuständigkeit, dauerhaftem Speicher, einem Wiederherstellungsverfahren und überwachter Kapazität. Rollen für verwaltete Workloads können später registriert werden und auf separaten physischen Hosts, virtuellen Maschinen oder angemessen isolierten Systemcontainern liegen.

Halten Sie vor der Installation fest:

• die kanonische HTTPS-URL, der Benutzer und verwaltete Nodes vertrauen werden;
• wer für DNS, Zertifikate, Authentifizierung, Backups und Upgrades zuständig ist;
• welche Netzwerke die Webanwendung und Relay erreichen dürfen;
• welche Node-Rollen sofort benötigt werden und welche später hinzukommen können;
• den benötigten Produkttarif und den Leistungsumfang;
• das Wiederherstellungsziel für Opfield-Daten und Verschlüsselungsmaterial.

Vermeiden Sie eine Planung um temporäre IP-Adressen oder einen Hostnamen, der nach dem Onboarding umbenannt wird. Die kanonische URL wirkt bei Browsersicherheit, Weiterleitungen, generierten Befehlen und Integrationen mit.

Entscheidung zu Host und Kapazität

Stellen Sie einen unterstützten Linux-Host mit Root-Zugriff oder funktionierendem sudo bereit. Docker ist keine Voraussetzung für das öffentliche Installationsprogramm: Fehlen Docker Engine oder das Compose-v2-Plugin, installiert und konfiguriert das Installationsprogramm sie aus den offiziellen Paket-Repositories von Docker. Die automatische Docker-Installation unterstützt die Familien Debian, Ubuntu, Fedora, CentOS und RHEL. Ist Docker bereits vorhanden, prüft das Installationsprogramm, ob die Engine erreichbar und Compose v2 verfügbar ist.

Verwenden Sie diese Basisprofile zur Dimensionierung der Control Plane:

Profil	CPU	Arbeitsspeicher	Freie SSD-Kapazität
Minimum	2 vCPU	4 GB RAM	32 GB
Empfohlen	4 vCPU	8 GB RAM	64 GB

Die Festplattenangaben sind freie Kapazität nach der Installation des Betriebssystems. Lokales ClickHouse-Logging, das Opfield verwaltet, benötigt zusätzlich mindestens 32 GB, empfohlen 128 GB; der tatsächliche Bedarf hängt vom Aufnahmevolumen und der Aufbewahrungsdauer ab. Externes ClickHouse belegt keinen lokalen Logging-Speicher auf dem Opfield-Host.

Reservieren Sie persistenten Speicher für die PostgreSQL-Daten von Opfield, die Redis-Persistenz, sofern konfiguriert, hochgeladene Artefakte, Zertifikate, Konfiguration, die interne Registry und optionale strukturierte Logs. Builds aus Git-Quellen benötigen zusätzliche Registry-Kapazität, da erfolgreiche, aktive, für Rollbacks vorgehaltene, laufende und manuell angeheftete Artefakte aufbewahrt werden. Die eigenen Container von Opfield – die Anwendung, Relay, Registry, PostgreSQL und Redis – behalten jeweils höchstens drei Logdateien zu 50 MB; ein Update fügt dieses Limit bestehenden Installationen hinzu, sofern ein Dienst nicht bereits eine eigene Logging-Konfiguration hat.

Stellen Sie mindestens sicher, dass der Host außerdem Folgendes hat:

• genug Reserven für die Anwendung, PostgreSQL, Redis und Relay ohne anhaltenden Swap-Druck;
• dauerhaften Speicher mit Überwachung des freien Speicherplatzes und ein getestetes Backup-Ziel;
• korrekte Systemzeit und zuverlässige DNS-Auflösung;
• einen Update-Prozess für das Betriebssystem, der persistente Volumes nicht stillschweigend ersetzt;
• Zugriff auf das aktuelle signierte Opfield-Release und den Lizenzdienst.

Bewahren Sie die einzige Kopie des Backups oder des Verschlüsselungsschlüssels nicht auf dem Opfield-Host auf. Ein Datenbank-Backup ohne das zugehörige Material zur Secret-Verschlüsselung ist kein vollständiges Wiederherstellungsset.

Details für Betreiber: Netzwerkzugriff

Die öffentliche Installation benötigt normalerweise eingehendes HTTP/HTTPS für die Benutzeroberfläche und die API. Verwaltete Nodes verbinden sich über Relay, das erreichbaren Port 9443/tcp benötigt, wenn Nodes außerhalb des lokalen Netzwerks liegen. Beschränken Sie den administrativen Zugriff nach Möglichkeit am Netzwerkrand, platzieren Sie aber keinen Proxy und keine Firewall im Relay-Pfad, sofern diese die benötigten langlebigen Verbindungen nicht unterstützen.

Ausgehender Zugriff hängt von den aktivierten Funktionen ab. Typische Ziele sind Identitätsanbieter, ACME- und DNS-Anbieter, Quellcodeverwaltungssysteme, Container-Registries, Release- und Lizenzdienste, E-Mail- und Webhook-Endpunkte, SIEM-Empfänger und konfigurierte KI-Anbieter. Build Worker benötigen möglicherweise eine andere und restriktivere Egress-Richtlinie als die Control Plane.

Einige Node-Rollen benötigen mehr:

• Storage Nodes beziehen den Backup-Runner aus der GitHub Container Registry und benötigen daher ausgehendes HTTPS zu ghcr.io. Verwaltete Engines (SeaweedFS, PostgreSQL, Valkey, ClickHouse) und der Compose-Sidecar von Docker Nodes werden per Digest zuerst vom Opfield-Mirror auf ghcr.io bezogen, mit Docker Hub als Ausweichquelle.
• Workload Availability im Lease-Modus: Jeder Docker Node einer Richtlinie und jeder Ingress Node ihrer Routen muss jedes Relay des Pools auf seinem angekündigten Port erreichen; siehe Failover der Datenebene.

Lesen Sie Ports und Netzwerk, bevor Sie Firewalls ändern. Prüfen Sie Pfade vom tatsächlichen Host und Netzwerk-Namespace aus, der die Verbindung aufbauen wird; eine erfolgreiche Anfrage vom Laptop eines Administrators beweist nicht, dass Opfield oder ein Node denselben Endpunkt erreichen kann.

Node-Rollen und Vertrauensgrenzen

Wählen Sie nur die Rollen, die Sie benötigen:

• nginx-Node: Ingress, Bereitstellung von TLS-Material, Pages, Access- und Error-Logs sowie Traffic-Metriken;
• Docker Node: Container, Deployments, Compose-Projekte, Dateien, Logs und Laufzeitzustand;
• Storage Node: verwaltete PostgreSQL-, Key-Value- oder ClickHouse-Instanzen, verwalteter Objektspeicher, deren dauerhafter Speicher sowie Datenbank-Backup-Jobs;
• Build Worker: isolierte BuildKit/containerd-Ausführung, ohne einen Docker-Engine-Socket offenzulegen;
• Monitoring-Node: Monitoring-spezifische Erfassung für unterstützte Ziele;
• Mitglied des Relay-Pools: transportiert Secure Links sowie Datenbank- und Speicherverbindungen. Die Produktion und jede Availability-Konfiguration benötigen mindestens zwei Relays auf anderen Hosts als dem Opfield-Host, in unterschiedlichen Fehlerdomänen (Host, Stromversorgung, Netzwerkpfad); siehe Wie viele Relays.

Voraussetzungen für Storage Nodes und Docker Nodes

Ein Storage Node führt den Docker-Daemon als Root aus und hält jede verwaltete Datenbank, jeden Objektspeicher-Cluster und jeden Backup-Arbeitsbereich in einem ext4-Image fester Größe auf einem Loop-Device, sodass seine Festplattennutzung begrenzt ist. Das Installationsprogramm prüft dies vor der Registrierung: Es formatiert, mountet, vergrößert und trennt ein Test-Image und bricht ab, wenn der Host das nicht kann. Jede verwaltete Datenbank, jedes Mitglied eines Objektspeichers und jedes laufende Backup belegt ein Loop-Device, solange es existiert. Virtuelle Maschinen und physische Hosts erstellen Loop-Devices bei Bedarf. Ein LXC-Gast funktioniert nur, wenn sein Host /dev/loop-control und einen Pool von Loop-Devices durchreicht und Loop-Blockgeräte sowie Mounts erlaubt; dimensionieren Sie diesen Pool für jede verwaltete Instanz und jedes gleichzeitige Backup, das der Node halten wird. Ist der Pool erschöpft, schlägt das Erstellen einer Instanz mit node has no free loop device fehl; der Daemon gibt die Devices gelöschter Instanzen selbst frei.

Auf einem Docker Node belegt auch ein verwaltetes Disk-Image-Volume ein Loop-Device. Für das Failover der Datenebene führt jeder Docker Node, der eine Availability-Lease halten kann, den Lease-Watchdog als Root-Dienst unter systemd oder OpenRC aus; das Docker-Node-Installationsprogramm installiert ihn.

Ein Docker Node benötigt außerdem, dass Docker seinen Containern die cgroup-Controller memory, pids und cpu zur Verfügung stellt; andernfalls verweigert das Installationsprogramm die Registrierung des Nodes. Ein Alpine-LXC-Gast mit OpenRC benötigt meist zuerst eine cgroup-Einrichtung; siehe Alpine-, OpenRC- und LXC-Gäste. Ein Build Worker benötigt systemd. Monitoring-, Docker-, nginx- und Relay-Daemons können ohne Root laufen; siehe Einen Daemon ohne Root ausführen.

Die Trennung der Rollen ist eine Betriebs- und Sicherheitsentscheidung. Ein Storage Node sollte Speicher- und Backup-Richtlinien haben, die zu zustandsbehafteten Diensten passen. Ein Build Worker verarbeitet vom Repository gesteuerte Build-Eingaben und sollte sich keinen Host mit fremden Workloads oder wiederverwendbaren Infrastruktur-Zugangsdaten teilen. Behandeln Sie die äußere VM oder den unprivilegierten Systemcontainer des Workers als Sicherheitsgrenze; die innere Build-Sandbox ist eine zusätzliche Schutzebene, nicht die einzige Grenze.

Ein Docker Node benötigt normalerweise die Kontrolle über die lokale Docker Engine. Wer diesen Daemon-Pfad kontrolliert, kann privilegierte Container erstellen, Host-Pfade mounten und andere Workloads auf derselben Engine beeinflussen. Behandeln Sie einen Docker Node innerhalb der Docker-Vertrauensgrenze dieses Hosts als Root-äquivalent; verwenden Sie einen dedizierten Host oder eine bewusst akzeptierte Workload-Grenze, statt anzunehmen, dass Ressourcen-Scopes einen kompromittierten Host-Administrator isolieren.

DNS und Zertifikate

Entscheiden Sie, ob Opfield DNS über Cloudflare verwaltet oder ob die Einträge extern verwaltet bleiben. Die Zertifikatsausstellung per HTTP-01 erfordert den öffentlichen Port 80 auf dem zugewiesenen Ingress Node. DNS-01 erfordert eine konfigurierte Anbieterintegration mit den minimal nötigen Berechtigungen zum Anlegen der Challenge-Einträge. Hochgeladene Zertifikate brauchen einen Zuständigen für Verlängerung und Ablaufüberwachung.

Verwenden Sie für die erste Opfield-URL einen Hostnamen, der bereits durch ein vertrauenswürdiges Zertifikat abgedeckt ist. Browserwarnungen während der Ersteinrichtung verleiten zu unsicheren Umgehungen und können echte Proxy- oder Hostnamenprobleme verschleiern.

Checkliste zur Bereitschaft

Bestätigen Sie vor dem Ausführen des Installationsprogramms alle folgenden Punkte:

1. Der kanonische Hostname wird auf den vorgesehenen Endpunkt aufgelöst.
2. Die TLS-Terminierung und die Zuständigkeit für Forwarded-Header sind dokumentiert.
3. Persistenter Speicher und ein Backup-Ziel außerhalb des Hosts sind vorhanden.
4. Firewall-Regeln decken die Webanwendung, Relay und die benötigten ausgehenden Dienste ab.
5. Der erste Administrator und ein zweiter Verantwortlicher für die Wiederherstellung sind benannt.
6. Node-Rollen und Host-Isolation sind bewusst gewählt.
7. Erwartungen an Aufbewahrung, Audit, Benachrichtigungen und SIEM sind dokumentiert.
8. Der benötigte Leistungsumfang des Tarifs ist verfügbar.

Wenn eine dieser Entscheidungen offen ist, halten Sie vor dem Onboarding von Produktions-Workloads an. Es ist wesentlich sicherer, Topologie, DNS oder Authentifizierung zu ändern, bevor Nodes und Integrationen davon abhängen.

Lesen Sie Ports und Netzwerk, bevor Sie Firewalls ändern.