Container

Ein Container ist die Option zur direkten Verwaltung einer Docker-Laufzeit. Opfield speichert seine Konfiguration und Zugriffsbeziehungen, während der ausgewählte Docker-Daemon den tatsächlichen Prozess startet und überwacht. Verwenden Sie einen Container, wenn weder Blue/Green-Release-Slots noch die Projektzuständigkeit für mehrere Dienste erforderlich sind. Container, die bereits auf einem Docker Node laufen, werden aufgeführt und können bedient werden, ohne dass Opfield sie neu erstellt; siehe Container, die Opfield nicht erstellt hat.

Wann ein Container der richtige Eigentümer ist

Wählen Sie einen Container für einen einzelnen Dienst, dessen Neustart, Update und Wiederherstellung als eine Laufzeit verwaltet werden kann. Das eignet sich gut für interne Werkzeuge, Agenten, zustandslose Dienste und Workloads mit einer einfachen Beziehung zu einem persistenten Volume. Der Anwendungsverantwortliche bleibt dafür zuständig zu entscheiden, ob der Austausch des Prozesses sicher ist und ob seine Daten ein Backup oder ein Wartungsfenster erfordern.

Wählen Sie stattdessen ein Deployment, wenn ein Release vorbereitet und per Health Check geprüft werden muss, bevor Datenverkehr wechselt, mit einem vorgehaltenen Rollback-Kandidaten. Wählen Sie Compose, wenn sich mehrere Dienste, Netzwerke, Variablen und Volumes unter einer Revision ändern müssen. Ein Container ist bewusst direkt; Opfield erfindet keine Release-Strategie für ihn.

Erfolg bedeutet mehr als den Zustand running. Der erwartete Health Check muss bestehen, die Anwendung muss auf dem ausgewählten Port lauschen, ihre Route oder private Verbindung muss funktionieren, und persistente Daten müssen nach einer Neuerstellung eingebunden bleiben. Legen Sie diese Prüfungen vor dem ersten Produktions-Update fest.

Container, die Opfield nicht erstellt hat

Der Docker-Daemon meldet jeden Container auf seinem Node, nicht nur die über Opfield erstellten. Ein Container, der mit docker run oder einem anderen Werkzeug ohne Projekt-Labels von Docker Compose gestartet wurde, erscheint unter Docker > Containers als gewöhnlicher eigenständiger Container mit einer stabilen Opfield-Ressourcenidentität. Es gibt keinen separaten Übernahmeschritt: Benutzer mit den passenden Scopes können seine Logs, Statistiken und Prozesse ansehen, ihn starten, stoppen, neu starten oder beenden, die Konsole oder den Dateibrowser öffnen und ihn bearbeiten oder neu erstellen.

Opfield gewährt niemandem automatisch Zugriff auf einen erkannten Container. Benutzer mit Node-weiten oder globalen Docker-Scopes sehen ihn sofort; andere Benutzer benötigen eine Gruppen- oder direkte Berechtigung für diesen Container, seinen Node oder einen Docker-Ordner, der ihn enthält. Beispielberechtigungen finden Sie unter Workloads betreiben, ohne sie zu übernehmen.

Zwei andere Arten von Containern werden anders behandelt:

• Compose-Container. Ein Container mit dem Label com.docker.compose.project gehört zu seinem Compose-Projekt und wird nicht als eigenständiger Container aufgeführt. Logs, Monitoring, Konsole und Dateizugriff bleiben für seine Dienste verfügbar. Starten, Stoppen, Neustarten, Bearbeiten, Neuerstellen, Duplizieren und Löschen werden für einzelne Compose-Container abgelehnt, unabhängig davon, ob das Projekt extern ist oder von Opfield verwaltet wird.
• Interne Opfield-Container. Dienstcontainer, die Opfield für sich selbst betreibt, sind für die APIs des Benutzer-Lebenszyklus ausgeblendet.

Ressourcenbezogene Berechtigungen folgen der Opfield-Ressourcenidentität. Opfield behält diese Identität und die Berechtigungen darauf über eine Neuerstellung oder ein Update über Opfield hinweg bei. Wird ein Container außerhalb von Opfield entfernt und erneut gestartet, selbst mit demselben Namen, erfasst Opfield eine neue Ressource und entzieht die Berechtigungen auf die alte. Ändern Sie Container mit ressourcenbezogenen Berechtigungen über Opfield oder vergeben Sie den Zugriff auf Node- oder Ordnerebene.

Bevor Sie beginnen

Sie benötigen Zugriff auf den Ziel-Docker-Node und die Berechtigung, den Container zu erstellen oder zu ändern. Bestätigen Sie, dass das Image aus einer erlaubten Registry verfügbar ist, der Node Kapazität hat und die angeforderte Laufzeit unterstützt wird. Prüfen Sie Ports, Routen, Datenbank-Bindings, verwaltete Volumes und Secrets, bevor Sie einen Namen wählen: Diese Beziehungen können sich auf spätere Umbenennungen, Migrationen oder Löschungen auswirken. Ein Container kann an eine verwaltete Datenbank gebunden werden; eine externe Datenbank wird über Verbindungswerte erreicht, die als Container-Secrets gespeichert sind. Siehe Verwaltete und externe Datenbanken im Überblick.

Neue Host-Bind-Mounts werden abgelehnt. Verwenden Sie für neue persistente Daten von Opfield verwaltete lokale Volumes. Ältere Bind-Mounts können bei einem gewöhnlichen Update bestehen bleiben, nach ihrem Entfernen aber nicht über Opfield wieder hinzugefügt werden.

Ein Workload mit älteren Host-Bind-Mounts behält diese bei Änderungen, die sein Image nicht ändern, etwa Bearbeitungen der Umgebung, Datenbank- oder Speicherverbindungen und das Umschalten von Deployment-Slots; diese benötigen kein docker:containers:mounts. Ein neues Image erhält denselben Host-Zugriff, daher erfordert seine Änderung diesen Scope: von der Person, die die Änderung startet, und bei automatischen Git-Deployments und Webhooks von dem Konto, das die Quelle oder den Webhook zuletzt gespeichert hat, geprüft zum Zeitpunkt des Deployments. Webhooks, die vor 2.11 gespeichert wurden, haben kein erfasstes Konto und werden bei solchen Workloads abgelehnt, bis jemand mit dem Scope sie erneut speichert.

Die Default-Laufzeit ist auf unterstützten Docker Nodes verfügbar. Die sichere gVisor-Laufzeit erfordert eine fehlerfrei gemeldete Fähigkeit und kann nicht mit GPUs, Geräten, Host-Bind-Mounts, Migration oder Archivexport kombiniert werden.

Einen Container erstellen und aktualisieren

1. Wählen Sie den Docker Node und das Image, für einen Produktions-Workload vorzugsweise einen unveränderlichen Digest.
2. Legen Sie Befehl, Entrypoint, Umgebung, verschlüsselte Secrets, Labels, Ports, Neustartrichtlinie, Ressourcenlimits, Health Checks und verwaltete Volumes fest.
3. Prüfen Sie die aufgelöste Konfiguration und erstellen Sie den Container.
4. Verfolgen Sie den Erstellungs-Task, bis der Daemon den Laufzeitzustand meldet.
5. Prüfen Sie Health-Zustand, Logs und jede Route oder private Datenbankverbindung, bevor Sie Anwendungsverkehr senden.

Einige Label-Namensräume sind reserviert, weil Opfield und Docker Compose sie verwenden, um Container zu platzieren, zu gruppieren oder auszublenden: jedes Label, das mit com.docker.compose. oder net.opfield. beginnt oder mit den Präfixen aus der Zeit vor Opfield wiolett.gateway., net.wiolett.gateway. und com.wiolett.gateway., sowie das Label gateway.sandbox. Das Erstellen eines Containers mit einem davon wird in der Konsole, der REST API und MCP mit Labels <names> are reserved for Opfield and Docker Compose abgelehnt. Das Neuerstellen oder Aktualisieren eines Containers sendet seine Labels als Ganzes zurück: Reservierte Labels, die er bereits hat, dürfen unverändert zurückkommen, aber das Hinzufügen oder Ändern eines solchen schlägt mit 400 RESERVED_DOCKER_LABEL fehl. Duplicate lässt die reservierten Labels in der Kopie weg und behält nur die eigenen Aufzeichnungen des Docker-Daemons zur kopierten Konfiguration, etwa die Herkunft einer GPU-Gruppe. Ältere Docker-Daemons kopieren jedes Label, daher wird auf einem Node, dessen Daemon nicht aktualisiert wurde, das Duplizieren eines Containers mit reservierten Labels mit 409 UNSUPPORTED_DAEMON abgelehnt, bis der Daemon aktualisiert ist. Das Importieren eines Container-Archivs verwirft Compose-Labels sowie die Archiv-, Deployment- und Migrations-Labels von Opfield, statt das Archiv abzulehnen.

Auf einem Docker Node, dessen Standard-Log-Treiber json-file ist, begrenzt Opfield die Logs jedes Containers, den es ohne eigene Logging-Konfiguration erstellt oder neu erstellt, auf drei Dateien zu 50 MB. Compose-Projekte erhalten dasselbe Limit für jeden Dienst ohne eigenen logging-Abschnitt; siehe Unterstützte Compose-Konfiguration. Andere Log-Treiber bleiben unverändert, und ein Node, dessen /etc/docker/daemon.json Standard-log-opts festlegt, behält diese. Wenn das Einrichtungsskript für Docker Nodes Docker selbst installiert, schreibt es diese Datei mit derselben Rotation von 50 MB × 3, sodass auch Container begrenzt werden, die außerhalb von Opfield erstellt wurden.

Um Container zu finden, deren Logs noch unbegrenzt wachsen, erstellen Sie einen Container-Alarm auf Log Size (MB). Er zählt die Logdatei des Containers und ihre rotierten Kopien auf dem Node; ein noch nicht aktualisierter Docker-Daemon meldet null.

Verwenden Sie Recreate, wenn eine Änderung der Laufzeitkonfiguration einen Ersatzprozess erfordert. Opfield behält die stabile Ressourcenidentität bei, während es die vorgesehene Laufzeit neu erstellt. Verwenden Sie Duplicate, wenn Sie eine separate Ressource mit unabhängigen Zugriffsberechtigungen und eigenem Lebenszyklusverlauf benötigen. Verwenden Sie Rename erst, nachdem Sie abhängige Routen, Bindings und Integrationen geprüft haben. Ein Name, der von einer Git-Quelle belegt ist, deren Container noch auf seinen ersten Build wartet, kann nicht durch Erstellen, Duplizieren, Umbenennen oder Importieren eines anderen Containers übernommen werden: Die Anfrage schlägt mit 409 NAME_IN_USE fehl. Das Entfernen eines Containers entfernt auch seine Git-Quelle, und sein Umbenennen verschiebt die Quelle auf den neuen Namen.

Duplicate kopiert die eigenen Secrets des Containers, aber nicht seine Datenbank- oder Speicherverbindungen: Die Variablen, die diese Verbindungen einspeisen, werden in der Kopie weggelassen. Inspect, die Registerkarte Environment und der Archivexport legen niemals Passwörter von Verbindungen oder Schlüssel von Speicherverbindungen offen. Das Aktualisieren des Images eines Containers erfordert docker:containers:environment und docker:containers:secrets, weil die neue Laufzeit die Umgebung und die Secrets des Containers erhält, und das Anbinden eines Containers an Netzwerke erfordert Bearbeitungszugriff auf diese Netzwerke.

Prüfen und betreiben

Die Detailansicht ist der betriebliche Eintrag: Bestätigen Sie Soll- und beobachteten Zustand, Health-Ergebnis, Image-Identität, aktuelle Tasks und Logs. Die Overview nennt das Laufzeitprofil des Containers, zum Beispiel Secure · gVisor, und das Monitoring zeigt seine Arbeitsspeicher- und PID-Limits neben der Nutzung. Stop bei einem Container, der nichts ausführt – erstellt, beendet oder tot –, wird sofort abgeschlossen. Verwenden Sie Konsolen- oder Dateizugriff nur im Rahmen der Ihnen gewährten Scopes und vermeiden Sie eine interaktive Konsole als normalen Deployment-Weg.

Nach einem Neustart oder einem erneuten Verbindungsaufbau des Daemons gleicht Opfield den gespeicherten Sollzustand ab. Läuft der Container, kann aber keinen Datenverkehr bedienen, prüfen Sie in dieser Reihenfolge seinen Health Check, den lauschenden Port, das Routenziel, die Umgebung und das Anwendungslog.

Die Registerkarte Environment

Die Registerkarte Environment enthält von oben nach unten drei Blöcke:

• Links: die privaten Verbindungen des Containers. Add link fragt, womit sich der Workload verbindet: mit einer verwalteten Datenbank (ihre Zugangsdaten werden zu Variablen, siehe Bindings), mit verwaltetem Speicher (private Objektspeicher-Zugangsdaten für ausgewählte Buckets, als Variablen gesetzt) oder mit einem Port eines anderen Containers, Deployments oder Compose-Dienstes (ein Container-Link). Verbindungen, die andere Workloads zu diesem öffnen, werden als eingehend aufgeführt. Änderungen an Datenbank- und Speicherverbindungen werden mit Save & Recreate oder beim nächsten Start eines gestoppten Containers angewendet.
• Environment Variables: eine Tabelle mit Schlüsseln und Werten. Edit as text öffnet alle Variablen als KEY=value-Zeilen, eine pro Zeile; Apply überträgt sie zurück in die Tabelle, und sie werden beim Speichern gespeichert. Verwenden Sie das, um eine .env-Datei einzufügen oder viele Werte auf einmal zu ändern.
• Secrets: verschlüsselte Werte, die beim Start des Containers als Umgebungsvariablen eingespeist werden; sie werden nach dem Speichern nie wieder angezeigt.

Das Speichern von Variablen erstellt einen laufenden Container nach einer Bestätigung neu, rechnen Sie also mit einer kurzen Unterbrechung. Bei einem gestoppten Container werden sie gespeichert und beim Start angewendet. Ein Container, der zu einer App gehört, erhält außerdem die Variablen und Secrets seiner Umgebung; diese Schlüssel sind auf dieser Registerkarte gekennzeichnet.

Fehlerbehandlung und Bereinigung

Ein Fehler beim Beziehen des Images, nicht verfügbare Registry-Zugangsdaten, ein Portkonflikt, ein ungültiger Mount, eine nicht unterstützte Laufzeitfähigkeit oder erschöpfte Node-Ressourcen müssen behoben werden, bevor Sie es erneut versuchen. Während ein Git-Build auf den Container ausgerollt wird, liefern Lebenszyklus-, Konfigurations- und Secret-Änderungen BUILD_ROLLOUT_IN_PROGRESS, bis der Rollout endet; siehe Git-Quellen und Build Worker. Der Task-Verlauf zeigt die Phase, in der abgebrochen wurde; Wiederholungen ohne Änderung der Voraussetzung wiederholen meist denselben Fehler. Fehler, die Sie beheben können, kommen als Client-Fehler mit eigenem Code zurück, zum Beispiel 409 HOST_PORT_IN_USE mit dem Port, 409 IMAGE_NOT_ON_NODE, 409 DISK_IMAGE_VOLUMES_UNSUPPORTED, wenn der Node kein freies Loop-Device für ein Disk-Image-Volume hat, und 404 CONTAINER_NOT_FOUND. Das Neuerstellen eines Secure-Runtime-Containers mit einer GPU wird mit 409 SECURE_RUNTIME_GPU_UNSUPPORTED abgelehnt, bevor der Container gestoppt wird.

Prüfen Sie vor dem Löschen Routen, Datenbank-Bindings, Berechtigungen, Volumes, Quelleinstellungen und exportierte Daten. Das Löschen des Containers entfernt seine Ressourcenberechtigungen sowie seine Datenbank- und Speicherverbindungen, sodass ein späterer Container mit demselben Namen weder Zugriff noch Verbindungs-Zugangsdaten erbt. Ein Container, der auf den ersten Build seiner Git-Quelle wartet, kann nicht eigenständig gelöscht werden (409 SOURCE_CONTAINER_NOT_BUILT); löschen Sie stattdessen seine Git-Quelle. Das Löschen eines Volumes ist eine separate destruktive Aktion; bewahren oder sichern Sie persistente Daten, bevor Sie eine der beiden Ressourcen entfernen.

Details für Betreiber: Neuerstellung und Wiederherstellung

Eine Konfigurationsänderung, die Image, Befehl, Umgebung, Mounts, Laufzeit, Ports, Limits oder Neustartverhalten betrifft, kann eine Neuerstellung erfordern. Die Neuerstellung ersetzt die Docker-Laufzeit und behält dabei die stabile Container-Identität von Opfield und unterstützte Beziehungen bei. Bestehende Sitzungen im Prozess werden unterbrochen; planen Sie die Operation daher ein oder verwenden Sie ein Deployment, wenn eine Unterbrechung nicht akzeptabel ist.

Halten Sie vor der Neuerstellung den aktuellen Image-Digest, das Health-Ergebnis, eingebundene Volumes, den Zustand von Route und Binding sowie anwendungsspezifische Anforderungen an das Auslaufen fest. Vergleichen Sie nach Abschluss des Tasks die neue Laufzeit mit dem gespeicherten Sollzustand und testen Sie den echten Client-Pfad. Schlägt der Start fehl, stellen Sie die vorherige bekannt fehlerfreie Konfiguration oder das vorherige Image wieder her und erstellen Sie erneut; bearbeiten Sie das fehlgeschlagene Docker-Objekt nicht außerhalb von Opfield.

Trennt sich der Docker Node während einer Operation, warten Sie nach dem erneuten Verbindungsaufbau auf ein frisches Inventar, bevor Sie es erneut versuchen. Der Host hat die Laufzeitaktion möglicherweise abgeschlossen, ohne sie zu bestätigen. Fehlt ein Container, während sein Sollzustand noch existiert, verwenden Sie den unterstützten Weg zum Abgleichen oder Neuerstellen. Den Opfield-Eintrag zu löschen und neu zu erstellen, ändert Zuständigkeit und Berechtigungen und sollte nicht die erste Wiederherstellungsmaßnahme sein.

Konsolen- und Dateizugriff sind Werkzeuge für Vorfälle und Prüfungen, kein Ersatz für reproduzierbare Konfiguration. Änderungen, die nur innerhalb eines laufenden Containers vorgenommen werden, können bei der nächsten Neuerstellung verschwinden und sollten in das Image, die verwaltete Konfiguration oder ein persistentes Volume verlagert werden.