Images, Volumes und Netzwerke

Images, Volumes und Netzwerke sind Ressourcen des Docker-Daemons, die von mehreren Workloads gemeinsam genutzt werden können. Opfield meldet und verwaltet geeignete Ressourcen, aber eine sichere Bereinigung hängt weiterhin davon ab zu wissen, wem sie gehören und wer auf sie verweist. Behandeln Sie das Inventar eines Nodes, der offline ist, als zuletzt bekannte Information, bis die Synchronisation abgeschlossen ist.

Zuständigkeit vor der Bereinigung festlegen

Diese Ressourcen sehen wie Inventar aus, bergen aber unterschiedliche Risiken. Images beeinflussen die Fähigkeit, Software zu starten oder zurückzusetzen. Volumes können die einzige Kopie von Anwendungsdaten enthalten. Netzwerke können Teil der Diensterkennung oder privater Konnektivität sein. Der Plattformverantwortliche sollte für jede Klasse Aufbewahrungs- und Backup-Regeln festlegen, statt eine allgemeine Richtlinie für „ungenutzt“ anzuwenden.

Die Kennzeichnung unused bedeutet, dass das aktuell synchronisierte Docker-Inventar keine aktive Anbindung hat; sie beweist nicht, dass die Ressource sicher gelöscht werden kann. Ein gestoppter Workload, ein vorgehaltener Deployment-Slot, eine ausstehende Migration, ein Wiederherstellungs-Runbook oder ein externer Compose-Ablauf kann noch davon abhängen. Erfolg bei der Bereinigung bedeutet, dass Speicher freigegeben wurde, ohne ein benötigtes Wiederherstellungsartefakt, einen benötigten Datenbestand oder eine benötigte Konnektivitätsgrenze zu entfernen.

Images

Images sind lokales Inventar eines Nodes. Beziehen Sie ein Image, wenn ein Workload es benötigt, prüfen Sie vor dem Produktionseinsatz seinen Digest und seine Herkunft und bevorzugen Sie für Releases unveränderliche Digests. Aus Repositories gebaute Artefakte sollten per Digest statt per veränderlichem Tag verfolgt werden.

Prüfen Sie vor dem Entfernen eines Images oder einem Prune aktive Container, inaktive Rollback-Slots von Deployments, laufende Tasks und jede erwartete Wiederherstellungsaktion. Eine Bereinigung auf dem Node kann dazu führen, dass ein späterer Neustart fehlschlägt, bis das Image erneut bezogen wird. Entfernen Sie nur Images, die nachweislich nicht verwendet werden, und warten Sie die Synchronisation des Daemons ab, bevor Sie beurteilen, ob eine Bereinigung abgeschlossen ist. Images, die Opfield aus Git für nicht mehr existierende Container, Deployments und Compose-Projekte gebaut hat, werden automatisch vom Node entfernt; ein nicht verwendetes Build-Image kann auch manuell entfernt werden, und eines, das ein Container auf dem Node noch verwendet, wird mit 409 OPFIELD_INTERNAL_IMAGE abgelehnt.

Volumes

Von Opfield verwaltete lokale Volumes sind das unterstützte Ziel für neue persistente Mounts. Ein Volume überdauert einen Container, sofern es nicht separat gelöscht wird, was für eine geplante Neuerstellung nützlich, aber gefährlich ist, wenn die Daten nicht mehr gesichert sind.

Umbenennen, neu Beschriften, Größenänderung und Übernahme eines Volumes erfordern docker:volumes:edit, das auf ein Volume, einen Node oder einen Ordner beschränkt werden kann. Ein Host-Pfad, der dort eingegeben wird, wo ein Volume-Name erwartet wird, wird mit einer klaren Meldung abgelehnt, und jeder Volume-Name wird geprüft, bevor ein Volume erstellt wird.

Disk-Image-Volumes

Ab Personal kann ein Volume ein Disk image sein: ext4-Speicher fester Kapazität, der später erweitert werden kann. Neue Disk-Image-Volumes sind für Anwendungen beschreibbar, die nicht als Root laufen. Jedes belegt auf seinem Docker Node ein Loop-Device, solange es existiert; dimensionieren Sie den Pool von Loop-Devices eines LXC-Docker-Nodes entsprechend.

Der Docker-Daemon mountet Disk-Image-Volumes, bevor Docker startet, über einen Boot-Schritt namens opfield-volume-images (er ersetzt das frühere gateway-volume-images), den er für systemd oder OpenRC installiert. Kann das Image eines Volumes beim Booten nicht gemountet werden, erhält sein Mountpunkt einen schreibgeschützten, leeren Platzhalter, sodass ein Container nichts in das Root-Dateisystem des Nodes schreibt und stattdessen mit Read-only file system fehlschlägt. Der Daemon mountet das Image, sobald er kann, bei seinem Start oder bei seiner Prüfung alle 10 Minuten, und startet dann die Container neu, die das Volume verwenden, damit sie ihre Daten sehen. Ein Volume, das nicht gemountet werden kann, deaktiviert Disk-Image-Volumes nicht mehr auf dem gesamten Node.

Ermitteln Sie vor dem Verschieben, Neuerstellen, Exportieren oder Löschen eines Workloads alle eingebundenen Volumes und erstellen Sie ein für die Engine geeignetes Backup zustandsbehafteter Daten. Das Löschen eines Volumes ist destruktiv und kann durch Neuerstellen des Workloads nicht rückgängig gemacht werden. Exporte von Container-Archiven enthalten keine Volume-Inhalte, daher ist die Wiederherstellung von Volumes ein separater Wiederherstellungsschritt.

Netzwerke

Netzwerke stellen Konnektivität zwischen Workloads bereit und können private Implementierungsressourcen sein. Ein Netzwerk, das von einem verwalteten Workload oder einem übergeordneten Eigentümer erstellt wurde, darf nicht manuell entfernt werden: Routen, Datenbank-Bindings, Diensterkennung und Abgleich können davon abhängen.

Das Anbinden eines Containers an ein Netzwerk erfordert Bearbeitungszugriff auf dieses Netzwerk. Compose-Projekte und importierte Container-Archive können weder das Host-Netzwerk noch die internen Netzwerke von Opfield verwenden: opfield-secure-links, die Verbindungsnetzwerke verwalteter Datenbanken opfield-db-*, die Netzwerke verwalteten Speichers opfield-storage-* und die Netzwerke von Container-Links opfield-link-*. Netzwerke, die vor 2.12.1 erstellt wurden, behalten ihre gateway--Namen und werden gleich behandelt. Diese internen Netzwerke sind in der Netzwerkliste ausgeblendet: Sie können nicht verbunden, getrennt, entfernt oder von neuen Containern verwendet werden, und ein neues Netzwerk kann keinen Namen dieser Form annehmen. Nicht externe Netzwerke, die Compose gehören, bleiben im externen Compose-Ablauf. Externe oder bewusst gemeinsam genutzte Netzwerke bleiben globale Ressourcen und sollten erst entfernt werden, nachdem jeder referenzierende Workload getrennt wurde. Prüfen Sie zuerst Node-Zustand und Referenzen; ein scheinbar ungenutztes Netzwerk auf einem Node, der offline ist, ist kein ausreichender Beleg für eine Löschung.

Checkliste für eine sichere Bereinigung

1. Warten Sie, bis der Docker Node online ist und das aktuelle Inventar synchronisiert wurde.
2. Ermitteln Sie den Eigentümer der Ressource und jede aktive, Rollback- oder Wiederherstellungsreferenz.
3. Sichern Sie Daten vor jeder Volume-Änderung.
4. Führen Sie eine Bereinigungsaktion über Opfield aus und verfolgen Sie ihren Task.
5. Prüfen Sie danach den erwarteten Workload-Zustand und die Speicher- bzw. Netzwerkanbindung.

Schlägt ein Lösch-Task fehl, versuchen Sie es nicht mit einem erzwungenen Entfernen auf Daemon-Ebene erneut. Lesen Sie den Fehler, stellen Sie die fehlende Voraussetzung wieder her oder lösen Sie die erfasste Abhängigkeit und wiederholen Sie dann die beabsichtigte Opfield-Aktion.

Details für Betreiber: Prune und Prüfung

Führen Sie Prune nur auf einem Node aus, der online ist und ein frisches Inventar hat, und prüfen Sie die Kandidatenmenge vor der Bestätigung. Interne Opfield-Ressourcen und untergeordnete Ressourcen eines Eigentümers sind ausgeblendet oder geschützt, wo das Produkt sie erkennen kann, Operatoren müssen aber dennoch externe und gemeinsame Zuständigkeiten prüfen. Planen Sie kein breites Prune als einzigen Aufbewahrungsmechanismus für Produktions-Nodes ein.

Prüfen Sie nach einer Image-Bereinigung, dass aktive Workloads fehlerfrei bleiben und die benötigten, bekannt fehlerfreien Rollback-Artefakte weiterhin bezogen werden können oder aufbewahrt sind. Vergleichen Sie nach einer Volume-Bereinigung die freigegebene Größe und bestätigen Sie, dass kein erwarteter Mount verschwunden ist. Prüfen Sie nach einer Netzwerkbereinigung Diensterkennung, Compose-Zustand, Routen und Datenbank-Bindings, die Workload-Grenzen überschreiten.

Hat eine Bereinigung ein Image entfernt, das später benötigt wird, stellen Sie es per Digest aus der vertrauenswürdigen Registry wieder her. Ein gelöschtes Volume erfordert eine Wiederherstellung aus dem Backup der Anwendung; den Volume-Namen neu zu erstellen, stellt keine Daten wieder her. Ein gelöschtes gemeinsam genutztes Netzwerk kann erfordern, seine vorgesehene Konfiguration neu zu erstellen und jeden Eigentümer ausdrücklich erneut anzubinden; bewahren Sie daher seine Einstellungen vor dem Löschen.