Opfield bewerten

Diese Seite beantwortet die Fragen, die Käufer und ihre Sicherheitsprüfer üblicherweise stellen, bevor sie sich für Opfield entscheiden. Jede Antwort ist kurz und verweist auf die Seite, die das Verhalten im Detail dokumentiert. Die Antworten beschreiben das aktuelle Release; Roadmap-Punkte sind in der Tarifmatrix gekennzeichnet.

Können wir Opfield mit einem kostenpflichtigen Tarif selbst hosten?

Ja. Jeder Tarif – Community, Personal, Business und Enterprise – kann auf Ihrer eigenen Infrastruktur installiert und betrieben werden. Ein kostenpflichtiger Tarif ist ein Lizenzschlüssel, der auf eine selbst gehostete Installation angewendet wird; die Control Plane wird dadurch nirgendwohin verlagert. Die Managed Cloud, bei der das Opfield-Team die Control Plane betreibt, ist ein Add-on für die Tarife Personal und Business und wird zusammen mit dem Lizenzschlüssel in Ihrem Opfield-Konto verkauft. Sie ist eine Alternative und niemals Voraussetzung für einen Tarif.

Community benötigt keinen Lizenzschlüssel und erlaubt bis zu 25 verwaltete Nodes, 3 Benutzer und 1 benutzerdefinierte Berechtigungsgruppe. Schlüssel für Personal, Business und Enterprise decken jeweils eine aktive Opfield-Installation ohne diese Kontingente ab. Kostenpflichtige Funktionen werden als signierter kommerzieller Kern ausgeliefert, den die Installation herunterlädt und prüft; siehe Kommerzieller Kern. Siehe Opfield installieren oder die manuelle Installation, wenn Ihre Prüfung es nicht erlaubt, ein Installationsskript direkt in eine Shell zu leiten.

Wo liegen unsere Secrets und Schlüssel in einer selbst gehosteten Installation?

Innerhalb der Installation. Opfield ist eine Control Plane, die Sie selbst betreiben, daher bleiben die Zugangsdaten, mit denen sie Ihre Infrastruktur verwaltet, in Ihrer Umgebung:

Gespeicherte Zugangsdaten – Docker-Secrets und Umgebungswerte, Registry-Zugangsdaten, Tokens von DNS- und Hosting-Anbietern, SSH-Schlüssel, OIDC- und SMTP-Secrets, Datenbank-Zugangsdaten, Schlüssel von KI-Anbietern, private Schlüssel von Zertifizierungsstellen und ACME sowie der Lizenzschlüssel selbst – werden mit AES-256-GCM-Envelope-Verschlüsselung verschlüsselt und in der eigenen PostgreSQL-Datenbank der Installation gespeichert.
Der Master-Schlüssel, der sie schützt (PKI_MASTER_KEY), wird bei der Installation auf Ihrem Host erzeugt und in der .env-Datei der Installation aufbewahrt, nicht in der Datenbank. Er verlässt den Host nur, wenn Sie ihn kopieren.
Der eigene private TLS-Schlüssel von Opfield bleibt auf dem Opfield-Host. Jeder verwaltete Node bewahrt den privaten Schlüssel seines Daemons lokal auf, und Storage Nodes speichern TLS-Schlüssel der Datenbanken im Speicher, der dem Daemon gehört.

Schützen Sie den Opfield-Host als privilegiertes System und sichern Sie den Master-Schlüssel getrennt von den Datenbank-Backups: Ein Datenbank-Backup ohne seinen Master-Schlüssel kann nicht entschlüsselt werden. Siehe Sicherheitsmodell und Updates, Backups und Wiederherstellung.

Was sendet Opfield an den Lizenzdienst?

Ausschließlich Metadaten der Installation. Opfield kontaktiert https://license.opfield.dev, um die Installation zu registrieren, einen Heartbeat zu senden – alle 15 Minuten mit einem kostenpflichtigen Schlüssel und alle 30 Minuten mit Community –, einen Schlüssel zu aktivieren oder zu deaktivieren, das Ziel-Release vor einem Update zu autorisieren und, bei einer lizenzierten Installation, den signierten kommerziellen Kern herunterzuladen.

Anfragen enthalten die Installations-ID, den Installationsnamen (den Hostnamen der konfigurierten öffentlichen URL oder den Hostnamen des Servers), die Opfield-Version, die Schemaversion des Leistungsumfangs und ein Installationstoken. Bei der Registrierung wird eine einmalige Registrierungs-Nonce gesendet, bei der Aktivierung der kostenpflichtige Schlüssel und bei einem Update die Zielversion, die Release-ID und der Dateipfad. Infrastrukturkonfiguration, Ressourceninhalte, Secrets, Logs, Benutzer- oder Ressourcenzahlen, Prompts und Modellantworten werden nicht gesendet.

Prüfungen von Berechtigungen und Leistungsumfang nutzen den zwischengespeicherten Lizenzzustand in Ihrer Installation, sodass einzelne Operationen nicht auf den Lizenzdienst warten. Weitere ausgehende Verbindungen, etwa Release-Prüfungen, sind unter Was eine selbst gehostete Installation verlässt aufgeführt.

Was passiert, wenn die Lizenz abläuft oder der Lizenzdienst nicht erreichbar ist?

Laufende Infrastruktur läuft weiter. Weder ein Ablauf noch ein nicht erreichbarer Lizenzdienst stoppt oder löscht Container, Deployments, Compose-Projekte, Routen, Zertifikate, Engines verwalteter Datenbanken oder veröffentlichte Pages-Deployments.

Ablauf des Schlüssels. Nach dem Ablaufdatum bleibt der kostenpflichtige Tarif für eine tarifabhängige Kulanzfrist voll aktiv: 24 Stunden bei Personal, 3 Tage bei Business und 7 Tage bei Enterprise. Das Dashboard zeigt während der Kulanzfrist eine Warnung. Nach der Kulanzfrist laufen Workloads, die Datenebene und die Daten weiter; geplante Backups, Wiederherstellungen in bestehende Datenbanken, Ansicht, Logs, Monitoring, das Anzeigen von Zugangsdaten und das Löschen bestehender kostenpflichtiger Ressourcen funktionieren weiterhin. Das Erstellen kostenpflichtiger Ressourcen und das Ändern ihrer Konfiguration sind gesperrt, und die SIEM-Weiterleitung sowie der Zugriff auf externe Registries pausieren bis zur Verlängerung.
Lizenzdienst nicht erreichbar. Eine zuvor gültige kostenpflichtige Installation behält ihren Tarif für 100 Tage nach dem Ausstellungszeitpunkt ihres letzten signierten Lizenzzustands, mit dem Status Licensed with warning. Ein bekanntes Ablaufdatum wird dadurch nicht verlängert. Nach 100 Tagen entspricht das Verhalten einem gewöhnlichen Ablauf. Community-Installationen laufen weiter, solange der Dienst nicht erreichbar ist, und eine Community-Installation ohne Schlüssel wird auch ohne ihn aktualisiert. Das Aktivieren eines kostenpflichtigen Schlüssels und das Aktualisieren einer Installation, die einen kostenpflichtigen Tarif hat oder hatte, erfordern einen erreichbaren Dienst; ein fehlgeschlagenes Update lässt die aktuelle Version weiterlaufen. Siehe Voraussetzungen für Updates in 2.11.
Ressourcen über den Community-Limits. Community-Limits gelten nur, wenn Sie einen verwalteten Node, einen Benutzer oder eine benutzerdefinierte Berechtigungsgruppe erstellen. Bestehende Nodes, Benutzer und Gruppen über dem Limit funktionieren weiter und werden niemals gelöscht.
Downgrade und Verlängerung. Bei einem Downgrade auf einen niedrigeren kostenpflichtigen Tarif bleibt der höhere Tarif für seine Kulanzfrist erhalten. Eine Verlängerung des Schlüssels stellt den vollen Betrieb wieder her, ohne Ressourcen neu aufzubauen. Installationen, die einen kostenpflichtigen Tarif hatten, erhalten weiterhin Updates mit dem kommerziellen Kern, sodass bestehende kostenpflichtige Ressourcen nach einem Update weiterlaufen.

Widerruf, Übertragung des Schlüssels auf eine andere Installation, Deaktivierung oder ein ungültiger Schlüssel erhalten keine Kulanzfrist: Die Regeln nach Ablauf der Kulanzfrist gelten sofort, und laufende Workloads funktionieren weiterhin. Lizenzzustände des Dienstes werden signiert und von Opfield geprüft, sodass eine gefälschte oder wiederholte Antwort den Tarif nicht ändern kann. Siehe Downgrade und Ablauf.

Kann ein Team Container neu starten und Logs lesen, ohne das Projekt zu übernehmen?

Ja für eigenständige Container und lesend für externe Compose-Projekte.

Eigenständige Container, einschließlich Containern, die außerhalb von Opfield mit docker run gestartet wurden, werden auf ihrem Docker Node ohne Übernahmeschritt aufgelistet. Eine Gruppe kann docker:containers:manage für einen einzelnen Container erhalten, um ihn zu starten, zu stoppen, neu zu starten oder zu beenden und seine Logs zu lesen, ohne Zugriff auf andere Container oder Host-Details. manage erlaubt auch das Neuerstellen; einen Scope nur für den Neustart gibt es nicht.
Externe Compose-Projekte werden anhand von Docker-Compose-Labels erkannt. docker:compose:view für ein Projekt zeigt in jedem Tarif seine Dienste, ihren Zustand, das Monitoring und die zusammengefassten Logs. Ein externes Projekt oder einen einzelnen dazugehörigen Container neu zu starten, ist nicht möglich: Lebenszyklusaktionen erfordern die Übernahme des Projekts, und diese erfordert Personal oder höher. Nach der Übernahme startet, stoppt oder startet docker:compose:manage für dieses Projekt das gesamte Projekt neu.

Berechtigungen können sich auf eine Ressource, einen Node oder einen Docker-Ordner beziehen. Unter Workloads betreiben, ohne sie zu übernehmen finden Sie die genauen Scopes und wie sich Ressourcenidentitäten verhalten, wenn Container außerhalb von Opfield neu erstellt werden.

Wie übergeben wir ein bestehendes Docker-Compose-Projekt?

Übernehmen Sie das erkannte Projekt. Die Übernahme ist eine ausdrückliche Übertragung der Zuständigkeit und erfordert Personal oder höher. Sie fügen die vollständige Compose-Datei ein – Opfield liest sie nicht vom Host –, und Opfield validiert sie, speichert sie als erste unveränderliche Revision und wendet sie unter demselben Compose-Projektnamen an.

Benannte Volumes behalten ihre Namen. Opfield benennt weder das Projekt noch seine Volumes um und versieht sie mit keinem Präfix, sodass Docker Compose die bestehenden Volumes <project>_<volume> oder Volumes mit ausdrücklichem name: samt ihren Daten weiterverwendet. Behalten Sie bei zustandsbehafteten Diensten wie Temporal die Volume-Schlüssel unverändert bei und vergleichen Sie die Volume-Liste vor dem ersten Anwenden mit dem erkannten Projekt.
env_file wird nicht unterstützt. Deklarieren Sie Variablen in environment: und liefern Sie ihre Werte als Opfield-Variablen und verschlüsselte Projekt-Secrets über ${NAME}-Interpolation.
Host-Bind-Mounts werden abgelehnt, einschließlich relativer Pfade wie ./config. Verlagern Sie Konfigurationsdateien in das Image oder in ein benanntes Volume.
Einmalige Jobs. Es gibt kein docker compose run und keinen Pre-Deploy-Hook. Führen Sie einen Migrationsbefehl über die Konsole eines Dienstcontainers aus oder bilden Sie ihn als Dienst mit restart: "no" ab, auf den andere Dienste über depends_on warten; ein beendeter einmaliger Dienst wird als nicht laufend gemeldet.
Weitere Grenzen. Dienste müssen vorgefertigte Images verwenden, sofern das Projekt keine Git-Quelle mit Business oder Enterprise hat, und Schlüssel wie container_name, privileged, cap_add, devices, network_mode und deploy werden abgelehnt. Siehe die vollständige unterstützte Compose-Konfiguration.
Löschen. Das Löschen eines verwalteten Projekts löscht die Volumes, die ihm gehören. Sichern Sie persistente Daten vorher.

Rechnen Sie damit, dass das erste Anwenden die Dienstcontainer neu erstellt, und proben Sie die Übernahme an einer Staging-Kopie. Compose-Projekte können nicht per Cross-Node-Migration zwischen Nodes verschoben werden, und ihre Container können nicht als GWCA-Archive exportiert werden. Eigenständige Container schon: Die Migration kopiert Volume-Daten und behält Volume-Namen bei, während GWCA-Archive niemals Volume-Daten enthalten. Siehe Compose-Projekte und Migrationen und Container-Archive.

Was ist der Unterschied zwischen verwalteten und externen Datenbanken?

Opfield arbeitet mit PostgreSQL, Key-Value-Stores (Redis und Valkey) und ClickHouse in zwei Modellen:

Eine verwaltete Datenbank wird von Opfield als Container mit Speicher fester Größe auf einem Storage Node bereitgestellt und betrieben. Opfield kümmert sich um ihren Lebenszyklus, die Größenänderung, die TLS-Veröffentlichung, Logs, PostgreSQL-Erweiterungen und private Bindings, die Verbindungseinstellungen in Workloads einspeisen.
Eine externe Verbindung speichert verschlüsselte Verbindungsdaten für eine Datenbank, die anderswo läuft. Opfield testet die Verbindung, überwacht ihren Zustand und stellt Explorer und Konsolen bereit, stellt diese Engine aber nicht bereit, pausiert, skaliert, bindet oder löscht sie nicht.

Beide Modelle erfordern Personal oder höher, und beide können mit geplanten Datenbank-Backups in eine Speicherverbindung geschützt werden.

Den vollständigen Vergleich finden Sie in der Datenbankübersicht.

Helfen Sie bei der Migration?

Ihren Stack zu Opfield umziehen gibt die Reihenfolge des Umzugs und eine Prüfung für jeden Schritt vor, in jedem Tarif. Business enthält Guided Onboarding and Configuration Review und Enterprise enthält Assisted Deployment and Migration als Tarifleistungen; der Umfang dieser Unterstützung wird durch die kommerzielle Vereinbarung festgelegt. Für Migrationshilfe in einem anderen Tarif oder für ein bestimmtes Projekt wenden Sie sich an das Opfield-Team unter [email protected] oder über die Opfield-Website.

Wo finde ich die Preise?

Die aktuellen Tarifpreise sind im Preisbereich der Opfield-Website veröffentlicht. Diese Dokumentation legt keine Preise oder Preiszusagen fest; Vertrags- und Preisbedingungen, einschließlich der Enterprise-Bedingungen, ergeben sich aus der jeweiligen kommerziellen Vereinbarung. Funktionen und Limits der Tarife sind unter Tarife und Leistungsumfang aufgeführt.

Nächste Schritte

Vergleichen Sie die benötigten Funktionen in der Tarifmatrix.
Prüfen Sie das Sicherheitsmodell und die Host-Anforderungen.
Planen Sie den Umzug mit Ihren Stack zu Opfield umziehen.