Garage: S3-kompatiblen Objektspeicher auf dezentraler Rechenleistung betreiben
Objektspeicher ist überall. Anwendungen nutzen ihn für Bilder, Backups, Dokumente, Anwendungs-Assets, Datensätze und so gut wie jede andere Datei, die irgendwo außerhalb der Anwendung selbst liegen muss.
Für viele Entwickler heißt das, zu einem S3-kompatiblen Speicherdienst in der Cloud zu greifen.
Doch S3 ist eine Schnittstelle, kein Ort. S3-kompatibler Speicher implementiert dieselbe API wie Amazon S3, sodass für S3 gebaute Anwendungen und Tools damit arbeiten können, egal wo der eigentliche Speicher gehostet ist. Das ist wichtig, denn so lassen sich vertraute S3-Tools nutzen, während der Speicher selbst auf dezentraler Infrastruktur läuft.
In dieser Anleitung stellen Sie Garage, eine Open-Source-Lösung für S3-kompatiblen Objektspeicher, im dezentralen Processor-Netzwerk von Acurast bereit. Sie konfigurieren das Deployment, starten Garage mit Cargo, verbinden sich mit dem entstehenden S3-kompatiblen Endpunkt und laden Ihre erste Datei hoch.
Am Ende haben Sie eine S3-kompatible Speicherinstanz, die auf einem Acurast Processor läuft.
Auch Speicher ist ein Compute-Workload
Bei dezentraler Rechenleistung denkt man wohl nicht zuerst an Speicher als Workload. Doch ein Objektspeicher-Server ist letztlich Software.
Er braucht eine Laufzeitumgebung, ein Netzwerk, Rechenressourcen und einen Ort, an dem er seine Daten ablegt. Mit der richtigen Linux-Umgebung kann er an vielen verschiedenen Orten laufen.
Genau hier kommt Codename Cargo ins Spiel.
Cargo erweitert Acurast über die bisherige Node.js-Laufzeitumgebung hinaus, indem es vollständige Linux-basierte Workloads ermöglicht. Entwickler können Anwendungen deployen, die mit Python, Go, Rust, C++ und anderen unter Linux laufenden Technologien gebaut sind. So lässt sich bestehende Software im Acurast-Netzwerk ausführen, ohne sie eigens für eine eingeschränkte Laufzeitumgebung neu zu bauen. Garage ist ein gutes Beispiel dafür.
Statt ein eigenes Speicherprotokoll für dezentrale Infrastruktur zu entwickeln, lässt sich Software deployen, die die vertraute S3-API bereits implementiert.
Das Ergebnis ist ein Objektspeicherdienst, mit dem bestehende S3-kompatible Tools und Anwendungen kommunizieren können.
Garage auf Acurast deployen
Das Repository mit den Acurast-Beispiel-Apps enthält ein Garage-Beispiel, bei dem der Großteil des zugrunde liegenden Setups bereits erledigt ist. Die Deployment-Skripte laden Garage herunter, konfigurieren den Dienst, bauen den nötigen Tunnel auf und stellen die Informationen bereit, die Sie für die Verbindung brauchen.
Bis zum Start ist also nur noch vergleichsweise wenig Konfiguration nötig.
Schritt 1: Die Garage-Beispiel-App öffnen
Checken Sie zunächst das Repository mit den Acurast-Beispiel-Apps aus.
Wechseln Sie in den Ordner App Cargo Garage.
Darin finden Sie alle Dateien, die für das Deployment nötig sind. Die meisten davon sind Setup-Dateien, die Sie nicht ändern müssen. Sie übernehmen Aufgaben wie das Herunterladen des Garage-Binärprogramms, das Vorbereiten der Umgebung und den Aufbau des Tunnels, der den Dienst erreichbar macht.
Bearbeiten müssen Sie im Wesentlichen nur die Umgebungsdatei.
Schritt 2: Das Deployment konfigurieren
Der erste Wert, den Sie brauchen, ist eine Acurast-Mnemonic. Mit diesem Konto wird das Deployment autorisiert und bezahlt. Verwenden Sie aus Sicherheitsgründen nicht die Mnemonic Ihrer Haupt-Wallet. Erzeugen Sie stattdessen eine separate Mnemonic für Deployments und übertragen Sie nur das Guthaben, das der Workload benötigt. Sensible Wallet-Zugangsdaten sollten niemals unnötig in lokalen Konfigurationen oder CLI-Umgebungen offengelegt werden.
Konfigurieren Sie als Nächstes die Callback-URL. Wenn Acurast das Deployment vorbereitet, erzeugt es eindeutige URLs, über die Sie auf Garage zugreifen. Diese URLs müssen irgendwo ankommen. Das Beispiel löst das, indem es eine POST-Anfrage an die von Ihnen angegebene Callback-URL sendet. Sie können also jeden Dienst verwenden, der eine POST-Anfrage empfangen und ihren Inhalt anzeigen kann. In diesem Tutorial kommt webhook.watch zum Einsatz. Erstellen Sie einen persönlichen Endpunkt, kopieren Sie dessen URL und tragen Sie sie in die Konfiguration ein.
Sobald das Deployment bereit ist, kommen die Deployment-Informationen an diesem Endpunkt an.
Schritt 3: SSH und das Netzwerk konfigurieren
Außerdem konfigurieren Sie ein SSH-Passwort. Wenn alles wie erwartet funktioniert, ist SSH-Zugriff im normalen Betrieb nicht erforderlich. Er dient vor allem als Rückfalloption, falls Sie sich zum Debuggen oder zur Fehlersuche direkt mit dem Processor verbinden müssen.
Verwenden Sie ein sicheres Passwort. Als Deployment-Netzwerk empfiehlt sich Mainnet, weil es Zugang zu einem größeren Pool verfügbarer Processors bietet.
Außerdem sehen Sie eine Einstellung für das Domain-Suffix. Zum Zeitpunkt dieses Tutorials müssen Sie eine eigene Domain mitbringen und die passenden DNS-Einträge konfigurieren. Dieser Vorgang soll künftig stärker automatisiert werden, die genauen Anforderungen können sich also mit der Weiterentwicklung von Cargo ändern.
Konfigurieren Sie zum Schluss den Bucket-Namen. Für ein einfaches Deployment können Sie ihn einfach auf dem Standardwert belassen.
acurast.json prüfen
Werfen Sie vor dem Deployment einen Blick in die Datei acurast.json. Sie enthält weitere Einstellungen, die steuern, wie der Workload läuft.
Ein wichtiger Parameter ist die Deployment-Dauer. In diesem Beispiel läuft Garage vier Stunden lang. Das reicht zum Testen, doch je nachdem, was Sie bauen, können Sie die Dauer verlängern.
Hier lässt sich auch das Netzwerk konfigurieren, in diesem Beispiel bleibt es aber auf Mainnet. Achten Sie außerdem darauf, die erforderliche Android-Version anzugeben. Ältere Processor-Umgebungen unterstützen möglicherweise nicht alle Funktionen, die das Garage-Deployment benötigt.
Damit ist alles bereit, um den Speicherdienst zu starten.
Garage starten
Führen Sie im Verzeichnis mit dem Garage-Beispiel Folgendes aus: acurast deploy
Die Acurast CLI führt Sie durch den Deployment-Prozess. Bevor Sie das Deployment abschicken, wird Ihnen die zugehörige Gebühr angezeigt. Ist die konfigurierte Gebühr höher als nötig, können Sie stattdessen den vorgeschlagenen Wert verwenden.
Bestätigen Sie das Deployment – ab da übernimmt Acurast. Das Deployment wird registriert, ein Processor wird vorbereitet und die nötigen Dienste starten automatisch.
Nach einigen Minuten sollten die ersten Anfragen am zuvor konfigurierten Callback-Endpunkt ankommen.
Das Deployment überprüfen
Die Callback-Anfragen geben einen guten Einblick in das, was auf dem Processor passiert. Zuerst sehen Sie Logs, die anzeigen, dass die Umgebung startet.
Anschließend installiert der Processor den SSH-Server, lädt Garage herunter und baut den Tunnel auf.
Schließlich erhalten Sie die Informationen, auf die Sie gewartet haben: die erzeugten URLs und Zugangsdaten für den Zugriff auf das Garage-Deployment.
Die Logs bestätigen dann, dass Garage vollständig deployt und live ist. Jetzt läuft ein S3-kompatibler Speicherdienst auf einem Acurast Processor.
Zeit, sich damit zu verbinden.
Mit Ihrem S3-kompatiblen Speicher verbinden
In diesem Beispiel kommt eine einfache Oberfläche zum Einsatz, die zur Demonstration der Verbindung erstellt wurde.
Für die Verbindung brauchen Sie vier Angaben aus dem Deployment:
- Die erzeugte Endpunkt-URL
- Die Access Key ID
- Den Secret Access Key
- Den Bucket-Namen
Geben Sie diese Werte im Client ein und klicken Sie auf Connect. Der Client kommuniziert nun mit der Garage-Instanz, die auf Ihrem Acurast Processor läuft.
Da Garage eine S3-kompatible Schnittstelle bietet, sind Sie nicht auf die Demo-Oberfläche beschränkt. Jeder kompatible S3-Client lässt sich mit dem passenden Endpunkt und den Zugangsdaten für das Deployment konfigurieren.
Ihre erste Datei hochladen
Prüfen Sie jetzt, ob der Speicher tatsächlich funktioniert. Wählen Sie eine Testdatei – ein Bild eignet sich gut – und laden Sie sie über die Oberfläche hoch.
Sobald der Upload abgeschlossen ist, erscheint die Datei im Bucket. Von dort aus können Sie ihre URL abrufen, sie teilen, herunterladen oder löschen. Eine einfache Demonstration, aber genau darum geht es. Aus Sicht des Clients arbeiten Sie mit vertrautem S3-kompatiblem Objektspeicher. Das Ungewöhnliche ist, wo dieser Speicher läuft.
Statt auf einer klassischen Cloud-Instanz läuft Garage jetzt auf einem Acurast Processor.
Ein einzelner Processor ist keine Backup-Strategie
Bevor Sie dieses Setup als Produktivspeicher betrachten, sollten Sie eine wichtige Einschränkung kennen.
In diesem Beispiel liegen Ihre Daten auf einem einzigen Processor. Wird dieser Processor nicht verfügbar, wird er zurückgesetzt oder läuft das Acurast-Deployment ab, können die dort gespeicherten Daten dauerhaft verloren gehen. Für Experimente, Entwicklung und Tests ist das völlig in Ordnung. Für Produktivspeicher reicht es nicht. Eine Produktivarchitektur braucht Redundanz. Ein möglicher Ansatz wäre, mehrere Garage-Instanzen auf verschiedenen Processors zu deployen und eine Replikation zwischen ihnen zu konfigurieren. Geht dann ein Processor offline, bleibt eine weitere Kopie der Daten verfügbar. Diese Unterscheidung ist wichtig, denn eine S3-kompatible API zu betreiben und dauerhaften Objektspeicher bereitzustellen, sind zwei verschiedene Probleme.
Das Beispiel löst das erste. Eine Produktivarchitektur muss auch das zweite lösen.
Für die Zukunft werden Lösungen erforscht, bei denen die Abhängigkeit von einem einzelnen Processor entfällt.
Mehr als ein S3-kompatibler Server
Garage zeigt etwas Grundsätzlicheres darüber, was Cargo zu Acurast beiträgt. Hier entsteht kein neues Speichersystem speziell für dezentrale Rechenleistung. Bestehende Linux-Software bekommt einfach einen neuen Ort, an dem sie laufen kann. Das ist ein wichtiger Unterschied.
S3-Kompatibilität bedeutet außerdem, dass Anwendungen nicht unbedingt verstehen müssen, was darunter passiert. Sie können weiter mit einer vertrauten API arbeiten, während sich die zugrunde liegende Infrastruktur ändert.
Und Garage ist nur ein Beispiel. Derselbe Ansatz lässt sich auf Datenbanken, Backend-Dienste, APIs, Entwicklerinfrastruktur, Gameserver, KI-Agenten und andere Linux-Workloads übertragen.
Die Frage ist nicht nur:
„Was lässt sich für dezentrale Infrastruktur bauen?“
Sondern zunehmend:
„Welche bestehende Infrastruktur lässt sich dort betreiben?“
Mit Cargo wird diese Liste deutlich länger.
Das vollständige Video-Tutorial ansehen
Diese Anleitung behandelt die wichtigsten Schritte, um Garage auf Acurast zu deployen, doch der begleitende Video-Walkthrough zeigt den Ablauf von Anfang bis Ende.
Sie sehen, wie Sie die Garage-Beispielanwendung konfigurieren, sie mit der Acurast CLI starten, die Deployment-Logs verfolgen, die erzeugten Zugangsdaten abrufen, einen S3-kompatiblen Client verbinden und eine Datei hochladen.
Es ist zugleich eine anschauliche Demonstration der größeren Idee hinter Cargo: Bestehende Linux-Anwendungen brauchen nicht unbedingt klassische Cloud-Infrastruktur, um zu laufen.
Beginnen Sie mit einem S3-kompatiblen Bucket. Und sehen Sie dann, was Sie sonst noch umziehen können.
