Ein Blog über Code, Hardware und Co

Storj, Server und Betriebssysteme

Das Updaten von Storj-Instanzen

Storj ist ein dezentraler Open-Source-Cloudspeicher. Sogenannte Storage-Nodes bilden dabei ein Netzwerk und bieten objektbasierten Cloudspeicher über die Plattform Tardigrade.io als Drop-in-Replacement für S3 an.

Ich betreibe selbst einige Storage-Nodes. Im Prinzip können diese ohne Probleme und viel Aufmerksamkeit nebenher laufen. Trotzdem sollten diese immer aktuell gehalten werden. Gerade weil die Entwicklung des Netzwerkes noch sehr aktiv ist und es viele neue Versionen gibt, sollte man den Updateprozess im Auge behalten.

Abbildung 1: Wenn ein neues Update verfügbar ist, wird Dir das auf dem Node-Dashboard (unter Adresse des Nodes Port 14002) mitgeteilt.

Es gibt viele Möglichkeiten, Storj-Instanzen laufen zu lassen und entsprechend auch zu updaten. Ich widme mich in diesem Beitrag ausschließlich den Storj-Instanzen, die als Docker-Container laufen.

Und da gibt es wiederum 2 Möglichkeiten Updates einzuspielen:

  • Manuell über die Aktualisierung des Docker-Images
  • Automatisiert über einen weiteren Container

Manuelles Update

Da die automatische Methode bei mir in den ersten Tagen nicht zuverlässig funktioniert hat und ich ohnehin lieber selbst in der Hand habe, wann ich ein Update einspiele, um nicht unbedingt öffentlicher Tester zu sein, ist dies auch die von mir genutzte Methode.

1. Schauen, ob es ein Update gibt

Als erstes müssen wir verifizieren, ob es ein geupdatetes Docker-Image gibt.
In der regel wird hier ein Thread veröffentlicht und ein Changelog gepostet: https://forum.storj.io/c/engineer-amas/27

2. Den zu updatenden Container stoppen

Vor dem Update muss der laufende Storj-Node gestoppt werden. Ich gehe dafür über die Konsole:

docker stop -t 300 name_des_containers

Wichtig ist es, den Befehl inklusive des Parameters t aufzurufen. So wartet Docker in diesem Fall 300 Sekunden, ob der Container auch wirklich heruntergefahren ist, bevor er hart terminiert wird.

Wieso ist das wichtig?

3. Den Container Löschen

Der folgende Befehl löscht den entsprechenden Docker-Container. Keine Angst, es wird NUR der Container gelöscht, nicht die im Node hintgerlegten Daten!

docker rm name_des_containers

4. Das neue Dockerimage laden

Wir laden nun das aktuellste Docker-Image, welches die aktuelle Storj-Version enthält. Mit diesem Image starten wir dann den Container wieder.

 docker pull storjlabs/storagenode:latest

Wenn das neue Docker-Image erfolgreich geladen worden ist, sieht das z.B. in der Konsole so aus:

Abbildung 2: Das erfolgreiche Pullen/Herunterladen eines aktuellen Docker-Images.

Wieso lade ich ein Image mit dem „beta“-Tag?
Die Frage ist vollkommen berechtigt. In der Regel lädt man bei Docker-Images die „latest“-Images. Da sich Storj.io aber noch immer offiziell im Beta-Status befindet, werden neue Versionen mit dem Beta-Tag versehen.

Update August 2020: Mittlerweile ist Storj aus dem Beta-Status heraus. Die aktuellen Docker-Images sind daher unter dem „latest“-Tag zu finden.

Den Storagenode wieder starten

Zu guter letzt muss der Storagenode natürlich wieder gestartet werden.

Das geht entweder direkt über die Konsole

docker run -d --restart unless-stopped --stop-timeout 300 \
    -p 28967:28967 \
    -p 127.0.0.1:14002:14002 \
    -e WALLET="0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
    -e EMAIL="user@example.com" \
    -e ADDRESS="domain.ddns.net:28967" \
    -e STORAGE="2TB" \
    --mount type=bind,source="<identity-dir>",destination=/app/identity \
    --mount type=bind,source="<storage-dir>",destination=/app/config \
    --name storagenode storjlabs/storagenode:beta

Die folgenden Variablen müssen wir immer gesetzt sein:

WALLETDie Adresse Deines Ether-Wallets
EMAILDeine E-Mailadresse
ADDRESSDie Domain bzw. des Hostname (oder die IP) unter der der Storagenode im Internet erreichbar ist.
STORAGE Die Größe des zur Verfügung gestellten Speichers
identity-dirDer Verzeichnispfad, in dem die Identity-Files liegen
storage-dirDer Verzeichnispfad, in dem die Daten gespeichert werden
Tabelle 1: Variablen beim Neustart des Docker-Containers über die Konsole.

Oder mittels docker-compose.yml

Ich arbeite bei meinen Storagenodes mit einer docker-compose.yml-Datei für jeden Node. So muss ich nicht jedes Mal nach einem Update einen ellenlangen Befehl eingeben bzw. mir diesen (samt Wallet-Adresse und Co) merken.
Alle zum Start notwendigen konfigurationen sind in dieser docker-compose.yml hinterlegt. Der Start des Container geht dann ganz einfach mittels:

sudo docker-compose up -d
Abbildung 3: Start des Docker-Containers des Storagenodes mit Hilfe von docker-compose.


Et voila: Der Storagenode läuft nun mit der jeweils aktuellen Version.

Troubleshooting

Tipp: Es kommt vor, dass die o.g. Befehle so nicht ausgeführt werden können und man eine Fehlermeldung wie die folgende erhält:

Abbildung 4: Rechteproblem: Docker lässt sich mit dem normalen SSH-User nicht immer steuern.

Es handelt sich hierbei schlicht um ein Privilegien- bzw. Rechteproblem.
Docker kann hier mittels temporäre Rechteverschaffung gesteuert werden, indem man „sudo“ dem eigentlichen Kommando voranstellt.

sudo docker stop -t 300 name_des_containers

Automatisches Update

Das automatische Update funktioniert mittels eines zusätzlichen Docker-Images: Watchtower.
Ich nutze diese Möglichkeit aktuell nicht, da sie bei meinen Nodes schlicht nicht funktioniert hat.
Sobald ich die automatischen Updates mittels Watchtower nutze, werde ich es hier erklären 😉

Schreibe eine Antwort