Wo sollte eine selbst gehostete Anwendung ihre Dateien speichern? Ein Entscheidungsrahmen für persistente Volumes und Objektspeicher

Dateispeicher ist eine Architekturentscheidung

Eine selbst gehostete Anwendung speichert ihren dauerhaften Zustand üblicherweise an mehr als einem Ort. Die Datenbank kann Datensätze, Berechtigungen und Metadaten enthalten, während Dateien wie Uploads, Dokumente, Bilder und generierte Berichte auf einem Datenträger oder in einem Objektspeicher liegen. Wird nur die Datenbank wiederhergestellt, können daher Datensätze entstehen, die auf nicht mehr vorhandene Dateien verweisen.

In Docker-Bereitstellungen verschwinden Daten, die nur in der beschreibbaren Schicht eines Containers gespeichert werden, wenn dieser Container gelöscht wird. Dauerhafte Anwendungsdateien müssen an einem ausdrücklich persistenten Ort abgelegt werden, den die Anwendung unterstützt. Die richtige Wahl ist nicht automatisch Objektspeicher: Entscheidend ist das Speichermuster, das zum Dateizugriffsmodell der Anwendung, zu den Wiederherstellungsanforderungen und zu den Betriebskapazitäten des Teams passt.

• Behandeln Sie jeden Dateispeicherort als Teil des Datenmodells der Anwendung.
• Richten Sie Backups und Wiederherstellungen an der Datenbank und den von ihr referenzierten Dateien aus.
• Dokumentieren Sie den vorgesehenen Speicherort, statt sich auf ein Container-Image oder einen undokumentierten Host-Pfad zu verlassen.

Beginnen Sie mit einem Dateiinventar

Bevor Sie einen Speicher auswählen, identifizieren Sie jede Datenkategorie, die die Anwendung erzeugt oder verarbeitet. Lesen Sie die offizielle Bereitstellungs- und Backup-Dokumentation der Anwendung, prüfen Sie konfigurierte Pfade und Einstellungen und führen Sie in einer Nicht-Produktivumgebung einen Test-Upload oder -Export durch. Ziel ist es, zu verstehen, welche Daten maßgeblich sind, welche neu erzeugt werden können und welche erhalten bleiben müssen.

Gehen Sie nicht davon aus, dass ein Verzeichnis namens uploads die vollständige Antwort ist. Eine Anwendung kann Originaldateien, Vorschaubilder, private Anhänge, Plugin-Assets, Suchindizes, Payloads wartender Jobs oder Exportarchive an unterschiedlichen Orten speichern.

• Benutzer-Uploads und Anhänge: Originale, die von Benutzern oder Mitarbeitenden bereitgestellt werden.
• Medien und generierte Derivate: Bilder, Vorschauen, Thumbnails oder umgewandelte Dokumente.
• Generierte Exporte: Berichte, CSV-Dateien, Rechnungen oder Archiv-Downloads.
• Von der Anwendung verwaltete Assets: Dateien, die über eine Verwaltungsoberfläche erstellt werden.
• Caches, Sitzungen und temporäre Arbeitsdateien: oft entbehrlich, dies muss jedoch in der Herstellerdokumentation bestätigt werden.
• Logs und Diagnosedateien: betrieblich nützlich, werden aber normalerweise getrennt von der Anwendungswiederherstellung geregelt.

Die drei gängigen Speichermuster verstehen

Lokale persistente Volumes speichern Dateien außerhalb des Lebenszyklus eines einzelnen Containers. Docker-Volumes werden von Docker verwaltet und bleiben bestehen, wenn der sie verwendende Container entfernt wird. In Kubernetes haben PersistentVolumes ebenfalls einen vom Lebenszyklus eines einzelnen Pods unabhängigen Lebenszyklus. Dieses Muster eignet sich häufig für eine einzelne Anwendungsinstanz, deren Software gewöhnlichen Dateisystemzugriff erwartet.

Objektspeicher speichert Daten als Objekte in Buckets, die über Objektschlüssel adressiert werden. Er ist nur geeignet, wenn die Anwendung einen Objektspeicherdienst ausdrücklich unterstützt oder eine unterstützte Integration bereitstellt. Rails Active Storage unterstützt beispielsweise sowohl einen lokalen Datenträgerdienst als auch Cloud-Speicherdienste. Dies verdeutlicht, dass die Speicherwahl oft eine Konfigurationsentscheidung der Anwendung und kein transparenter Austausch der Infrastruktur ist.

Ein extern verwaltetes Dateisystem kann Workloads gemeinsamen Dateisystemzugriff bereitstellen. Es kann geeignet sein, wenn die Anwendung diesen tatsächlich benötigt und die gewählte Speicherimplementierung das erforderliche Zugriffsmuster unterstützt. Dadurch kommt ein weiteres System hinzu, das betrieben, abgesichert, gesichert und getestet werden muss.

• Persistentes Volume: einfache Dateisystemsemantik für ein unterstütztes Single-Host- oder Single-Node-Design.
• Objektspeicher: anwendungsbewusster Objektzugriff, potenziell vom Compute-Host getrennt.
• Verwaltetes Dateisystem: gemeinsame Dateisystemsemantik, wenn sie durch Anwendungsanforderungen gerechtfertigt ist.

Verwenden Sie eine Entscheidungsmatrix statt einer Standardannahme

Wählen Sie den Speicher je Dateikategorie, nicht zwingend einmal für die gesamte Anwendung. Eine Dokumentenmanagement-Anwendung kann dauerhaften Speicher für Anhänge benötigen, während ihr temporäres Verzeichnis zur Dokumentkonvertierung nicht persistent bleiben sollte. Eine Reporting-Anwendung kann Quelldokumente behalten, Exporte nach einer Wiederherstellung jedoch neu erzeugen.

Ein Speicherkonzept ist vertretbar, wenn es eindeutige Antworten zu Dauerhaftigkeit, Anwendungskompatibilität, Wiederherstellung, Portabilität, Zugriffskontrolle und laufender Wartung gibt.

• Dauerhaftigkeit: Was geschieht, wenn der Container, Host oder Node ersetzt wird?
• Kompatibilität: Unterstützt die Anwendung dieses Speicher-Backend und dessen Konfiguration offiziell?
• Komplexität der Wiederherstellung: Kann das Team Dateien und Datenbankdaten auf einen nachweislich kompatiblen Stand wiederherstellen?
• Migrationsportabilität: Können Daten ohne undokumentierte Annahmen exportiert, kopiert und validiert werden?
• Zugriffsgrenzen: Welche Dienstidentität darf Dateien lesen, schreiben oder löschen?
• Betriebsaufwand: Wer verantwortet Zugangsdaten, Kapazitätsüberwachung, Aufbewahrungsregeln und Wiederherstellungstests?
• Skalierungsmodell: Müssen mehr als ein Anwendungsprozess dieselben Dateien schreiben, und wird dies unterstützt?

Datenbanken und Dateien als zusammenhängendes System wiederherstellen

Die zentrale Frage lautet, ob die Datenbank Verweise auf Dateien enthält oder Dateien benötigt werden, um Datenbankdatensätze zu interpretieren. Wenn ein Anhangsdatensatz auf einen Pfad oder Objektschlüssel verweist, benötigen der Anhangsspeicher und die Datenbank eine gemeinsame Wiederherstellungsplanung. Eine Wiederherstellung, die eine neuere Datenbank mit älteren Dateien kombiniert oder umgekehrt, kann zu fehlenden Anhängen oder nicht referenzierten Dateien führen.

Die genaue sichere Reihenfolge der Wiederherstellung hängt von der Anwendung ab. Einige Produkte bieten einen dokumentierten Wartungsmodus, Backup-Befehl oder Wiederherstellungsprozess; verwenden Sie ihn, sofern verfügbar. Wenn die Anwendung keinen dokumentierten Konsistenzmechanismus besitzt, definieren Sie ein kurzes Wartungsfenster oder eine andere kontrollierte Methode, um Schreibvorgänge zu verringern, während Datenbank- und Dateisicherungen erstellt werden.

• Identifizieren Sie das führende System für jede Dateikategorie.
• Halten Sie fest, ob die Datenbank Pfade, Objektschlüssel, Prüfsummen oder Anhangsmetadaten speichert.
• Definieren Sie einen akzeptablen Wiederherstellungspunkt für Datenbank und Dateien.
• Testen Sie, was Benutzer nach der Wiederherstellung sehen sollen: aktuelle Uploads, ältere Anhänge, Berechtigungen und Downloads.

Wann lokale persistente Volumes die richtige Wahl sind

Ein lokales persistentes Volume ist für eine kleine Bereitstellung häufig die klarste Wahl, wenn die Anwendung für lokalen Dateispeicher konzipiert ist, als eine aktive Instanz läuft und das Team das zugrunde liegende Volume sichern und wiederherstellen kann. Dadurch wird vermieden, eine Objektspeicherintegration hinzuzufügen, nur weil diese skalierbarer klingt.

Die Einfachheit ist nur dann real, wenn die Betriebsdetails ausdrücklich festgelegt sind. Ein Docker-Volume wird vom Host verwaltet, und ein lokaler Volume-Name ist auf seinem Host eindeutig. Das Verschieben der Anwendung auf einen anderen Host erfordert einen bewussten Prozess zur Datenübertragung und Verifikation. Docker dokumentiert eine Methode, mit der Volume-Inhalte über einen temporären Container archiviert und dieses Archiv in ein Volume zurückgespielt werden kann. Dies kann einen kontrollierten Migrations- oder Wiederherstellungs-Workflow unterstützen.

• Binden Sie das dauerhafte Volume am dokumentierten Datenpfad der Anwendung ein.
• Verwechseln Sie einen Container-Dateisystempfad nicht mit persistentem Speicher.
• Dokumentieren Sie den Volume-Namen, das Einhängeziel, die Erwartungen an Eigentümerschaft und die Backup-Methode.
• Prüfen Sie das Einhängeverhalten bei der Bereitstellung: Das Einhängen eines nicht leeren Volumes blendet bereits vorhandene Image-Dateien am Ziel aus; ein leeres Volume kann aus dem Image-Verzeichnis befüllt werden, sofern das Kopieren nicht deaktiviert ist.
• Halten Sie temporäre Daten nach Möglichkeit getrennt; ein tmpfs-Mount eignet sich nur für Daten, die beim Stoppen, Neustarten oder Host-Neustart verschwinden sollen.

Wann Objektspeicher geeignet ist

Objektspeicher ist eine starke Option, wenn eine Anwendung ihn nativ unterstützt und der Workload davon profitiert, Dateiobjekte vom Anwendungshost zu trennen. Leiten Sie Kompatibilität nicht allein daraus ab, dass eine Anwendung in Docker läuft. Prüfen Sie in der eigenen Dokumentation der Anwendung das unterstützte Backend, erforderliche Zugangsdaten, Bucket-Struktur, Verhalten bei der Objektbenennung, Einstellungen zur URL-Auslieferung und mögliche Migrationsverfahren.

Objektspeicher verändert das Betriebsmodell, statt es abzuschaffen. Sie müssen weiterhin entscheiden, wer auf den Bucket zugreifen kann, wie versehentliches Löschen behandelt wird, wie sich aufbewahrte Versionen auf die Wiederherstellung auswirken und ob Lifecycle-Regeln zu den Aufbewahrungspflichten der Organisation passen. In Amazon S3 haben beispielsweise versionierte und nicht versionierte Buckets unterschiedliches Löschverhalten, und Lifecycle-Regeln können Objekte in andere Speicherklassen überführen oder löschen.

• Verwenden Sie einen dedizierten Bucket oder ein eindeutig isoliertes Präfix, sofern das Anwendungsdesign dies unterstützt.
• Gewähren Sie der Anwendung nur die benötigten Berechtigungen; halten Sie Dienstzugangsdaten von der Administration durch Personen getrennt.
• Dokumentieren Sie, wie Originale, Derivate und abgebrochene Uploads aufbewahrt oder entfernt werden.
• Testen Sie die Wiederherstellung mit derselben Bucket-Konfiguration und demselben Zugriffsmodell, das in der Produktion erwartet wird.
• Stellen Sie sicher, dass eine Lifecycle-Richtlinie keine Daten löschen kann, die die Anwendung oder ihre Benutzer weiterhin benötigen.

Machen Sie ein gemeinsames Netzwerkdateisystem nicht zum Standard

Ein gemeinsames Netzwerkdateisystem kann wie eine einfache Lösung erscheinen, wenn mehrere Container oder Nodes beteiligt sind, sollte jedoch aus einer Anwendungsanforderung folgen und ihr nicht vorausgehen. Mehrere Schreibende werfen Fragen zu Sperrmechanismen, gleichzeitigen Änderungen, Berechtigungen und Fehlerverhalten auf, für die Anwendungen möglicherweise nicht ausgelegt sind.

Auch Kubernetes-Speicherzugriffsmodi sind kein Ersatz für Koordination auf Anwendungsebene. ReadWriteOnce bedeutet eine Lese-/Schreib-Einbindung durch einen Node, nicht zwingend durch nur einen Pod. Die Unterstützung für ReadWriteMany hängt vom zugrunde liegenden Plugin oder CSI-Treiber ab, und gängige Zugriffsmodi erzwingen nach dem Einbinden selbst keinen Schreibschutz. Validieren Sie sowohl das Verhalten der Speicherplattform als auch das dokumentierte Multi-Instanz-Design der Anwendung.

• Verwenden Sie gemeinsamen Dateisystemspeicher nur, wenn die Anwendung das erforderliche Zugriffsmuster unterstützt.
• Bestätigen Sie, ob mehrere Instanzen dieselben Dateien sicher schreiben können.
• Legen Sie die zugrunde liegende Speicherimplementierung fest, nicht nur eine Kubernetes-Zugriffsmodusbezeichnung.
• Prüfen Sie das Freigabeverhalten, bevor Sie dynamischen Speicher bereitstellen; eine StorageClass kann bei einer Delete-Reclaim-Policy den zugrunde liegenden Speicher löschen.