Evaluate Cloud Storage as Statamic Asset Container for Improved Repository Management

[JimSeven]

Problem

Derzeit werden alle Assets unserer Statamic-Projekte im Git Repository verwaltet, was zu einer schnellen Vergrößerung des Repositories führt und unnötige Versionierungen verursacht. Obwohl Git Large File Storage (Git LFS) bereits verwendet wird, um große Dateien und Binärdateien separat zu verwalten, könnte die Einführung eines Cloud Storage als Statamic Asset Container eine weitere Optimierung bieten.

User Story

Als Entwickler möchte ich die Möglichkeit haben, einen Cloud Storage als Asset Container in Statamic zu verwenden, um die Größe unseres Git Repositories zu reduzieren und die Effizienz der Dateiverwaltung zu verbessern.

Vorhaben

1. Implementierung des Digital Ocean Volumes Block Storage als Cloud Asset Container für das Projekt.

2. Konfiguration des Cloud Asset Containers in Statamic über Flysystem

3. Durchführung von Tests, um die Vor- und Nachteile des Cloud Storage Setups zu identifizieren.

4. Analyse, welche Asset-Informationen weiterhin im Git Repository gespeichert werden müssen.

5. Überprüfung der lokalen Arbeitsfähigkeit mit diesem Setup, einschließlich Geschwindigkeit und Zuverlässigkeit.

Abgrenzung

Es wird nur Digital Ocean Volumes Block Storage getestet. Andere Cloud Storage Lösungen (z.B. AWS S3) sind nicht Bestandteil dieser Untersuchung.

Der Fokus liegt auf der Evaluierung und nicht auf der Implementierung. Sollte das Ergebnis jedoch positiv ausfallen, ist die Implementierung eines dauerhaften Setups vorzunehmen.

Akzeptanzkriterien

1. Digital Ocean Volumes Block Storage ist erfolgreich als Asset Container in Statamic eingerichtet.

2. Es liegt ein Bericht vor, der die Vor- und Nachteile des Cloud Storage Setups dokumentiert.

3. Klarheit darüber, welche Asset-Informationen im Git Repository verbleiben müssen.

4. Der Bericht enthält eine Bewertung der lokalen Arbeitsfähigkeit mit dem neuen Setup.

5. Die Konfiguration ist dokumentiert und für zukünftige Implementierungen nachvollziehbar.

[Sm1lEE]

Abweichend von dem im Ticket beschriebenen Volumes Block Storage habe ich den Spaces Object Storage verwendet. Anhand dieses Artikels scheint mir der Spaces Object Storage geeigneter für unseren Anwendungsfall.

Die Einrichtung des Asset Containers in Statamic konnte ich problemlos anhand dieser Anleitung durchführen.

Vorteile

• Das Git Repository beinhaltet keine Daten, weder die Asset-Dateien noch die meta-Dateien, alle liegen im Cloud Storage. Die Assets nehmen also keinen Platz im Repo ein!
• Skalierbarkeit
• Automatische Backup-Lösungen möglich

Nachteile

• Der Upload von Assets dauert länger als z. B. mit dem local driver
  • Für 10 normale Bild-Dateien (Gesamtgröße 16 MB) hat der Upload ca. 30 Sekunden gedauert
  • Für 91 verschiedene Bild-Dateien (Gesamtgröße 85 MB) hat der Upload ca. 3 Minuten gedauert. Bei Verwendung eines local Drivers hat der Upload ca. 1 Minute gedauert.
  • insgesamt hat das aber nicht gestört, sondern ist meiner Meinung nach der Upload-Menge und -Größe entsprechend vertretbar

Weitere Erkenntnisse

• Es gibt keine Einschränkungen für bestimmte Dateitypen: Bilder, Videos, SVGs konnten problemlos hochgeladen werden
• Die Thumbnails im Backend werden gecacht - es finden nur beim ersten Aufrufen der Asset-Liste im Backend Requests an den Cloud Storage statt, danach kommen die Thumbnails aus dem Cache. Das Navigieren in den Assets im Backend hat sich im Prinzip wie mit einem local Driver angefühlt, da war ich positiv überrascht.
• Auch das Navigieren in einer langen Liste mit Paginierung funktioniert wunderbar.
• Ich konnte Assets verschieben, umbenennen, ersetzen, löschen - das hat alles fehlerfrei funktioniert.
• Neben der direkten Ausgabe der Cloud Storage URL im Frontend (<img src="{{ teaser }}" /> -> das Bild wird über den Cloud Storage Server ausgeliefert) kann auch Glide verwendet werden (<img src={{ glide:teaser width="300" }} />), um die Bilder zu manipulieren und über den Website-Server auszuliefern.
  • Damit das focal point Feature funktioniert, muss explizit der Parameter fit="crop_focal" angegeben werden (für lokale Assets war das nicht notwendig).
• Bei Verwendung von Glide dauert das Generieren der Bilder für das Frontend etwas länger (logisch,die Bilder müssen auch erstmal vom Cloud Storage geladen werden). In der Praxis sollte das aber kein Problem darstellen, da nach dem ersten Laden die generierten Glide-Bilder gecacht werden. Das sollte auch ein rein zeitlicher Faktor sein, eine Mehrbelastung für den Server selbst sollte dadurch nicht entstehen. Als Test habe ich 20 Bilder mit Glide ausgegeben:
  • Generierung local driver: 2 Sekunden
  • Generierung Cloud Storage: 8 Sekunden
  • Nachdem die Bilder gecacht sind, gibt es keinen Unterschied

Kosten

Laut Digital Ocean Website belaufen sich die Kosten für eine Spaces subscription auf 5$ pro Monat. Dabei können beliebige Space Buckets angelegt werden. Jede Spaces subscription beinhaltet 250 GiB Storage. Für jedes zusätzliche GiB werden 0,02$ pro Monat berechnet (für weitere 250 GB sind das beispielsweise zusätzliche 5$ pro Monat). Weiterhin gibt es eine Bandbreitenschränkung von 1.024 GiB ausgehender Daten pro Monat. Jedes zusätzliche GiB kostet 0,01$. Wenn die Webseite auf einem DigitalOcean Droplet liegt, werden an dieser Stelle keine Daten berechnet. Es betrifft dann also v.a. die lokale Entwicklungsumgebung.

Zusammenfassung

Der größte Nachteil sind längere Wartezeiten bei Upload und erster Verarbeitung der Assets (z. B. durch Glide). Diese halten sich aber meiner Meinung nach im Rahmen und schlagen nach dem Caching nicht weiter negativ zu Buche. Demgegenüber steht der Vorteil, dass die Assets keinen Platz im Git Repository einnehmen, auch nicht in Git LFS. Bei der Verwendung der Assets im Backend konnte ich auch keine nennenswerten Unterschiede feststellen - Verschieben, Umbenennen, Löschen, Auswählen funktioniert alles problemlos und zufriedenstellend.

Je nachdem, welche Bewertungsmetriken man anwendet, könnte man weitere Performance-Vorteile bei der Cloud Storage Lösung finden, da z. B. der Server in dem Sinne entlastet wird, weil die Asset-Dateien auf einem gesonderten Dateisystem liegen.

Von mir gibt es daher eine klare Empfehlung dafür.