Ein Blog über Code, Hardware und Co

Storj

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. Einmal installiert, prüft der WatchtowerContainer regelmäßig die Version der Storagenodes.

Der Prozess ist sehr einfach:

  1. Watchtower-Container aus dem Docker-Hub laden.
  2. Mit dem unten stehenden Kommando starten.
  3. Fertig!

Den Watchtower-Container starten – Oder: Der Aufbau des Docker-Commands

Der Watchtower-Container lässt sich wie folgt starten:

docker run -d --restart=always --name watchtower -v /var/run/docker.sock:/var/run/docker.sock storjlabs/watchtower  watchtower nodeXY --stop-timeout 300s
ParameterErläuterung
docker runDocker soll einen Container starten
-dDer Container wird im detached-Modus gestartet
–restart=alwaysDer Container soll nach einem Stromausfall oder Absturz direkt neugestartet werden
–name watchtowerDer Name des Containers, in diesem Fall “watchtower”
-v /var/docker/.sock:/var/run/docker.sock-v ist der “volume”-Parameter. Er besagt, dass unter dem folgenden Pfad im Container der nach dem Doppelpunkt stehende Pfad aus dem Hostsystem gemounted, also dort verfügbar gemacht werden soll.
storjlabs/watchtowerDas Docker-Image, welches gestartet werden soll. In diesem Falle das storjlabs-watchtower-image.
watchtower nodeXYEs folgt eine Auflistung aller Container, die vom Watchtower-Container überprüft und geupdatet werden sollen. In diesem Fall der watchtower-Container selbst sowie sämtliche auf dem System laufende Nodes.
–stop-timeout 300sDas Stoppen der aufgelisteten Container soll beim Update mit einem Timeout von 300s geschehen.
Wieso?
Es ist immens wichtig, dass ein Storagenode geordnet heruntergefahren wird, um Fehler im Dateisystem zu vermeiden. Damit die Nodes nicht “hart” beendet werden, geben wir ihnen etwas zeit, sich selbst zu beenden 😉
Tabelle1: Erklärung der Parameter des Docker-Kommandos

In meinem Fall sieht das Startkommando für den Watchtower-Container damit z.B. so aus:

docker run -d --restart=always --name watchtower -v /var/run/docker.sock:/var/run/docker.sock storjlabs/watchtower  watchtower storagenode1 storagenode3 node4 node5 node6 node7 node8 --stop-timeout 300s


Anmerkung: Im Storj-Forum ist immer wieder von Nutzern zu lesen, die Probleme mit den automatischen Updates mittels Watchtower haben. Im Schlimmsten Fall haben sogar Nutzer ihre Nodes verloren.

Anmerkung 2: Dieses Verfahren hat jedoch einen entscheidenden Nachteil. Und zwar widerspricht es der grundlegenden Philosophie von Docker. Denn wieso erstellt man oftmals Container? Um sie vom Hostsystem und anderen Containern abgekapselt und getrennt zu haben (Sicherheitsaspekt!). Durch das Einbinden des Docker-Sockets ist es dem Watchtower-Container nun theoretisch möglich, auf alle Deine Container zuzugreifen. Behalte das im Hinterkopf.

Ich habe daher bis vor einer Weile meine Nodes immer manuell geupdatet. Dieses Vorgehen stößt aber nach einer Weile an seine Grenzen: Ich betreibe mittlerweile 8 Storgaenodes (Stand Dezember 2020) und es könnten in Zukunft ja durchaus auch noch mehr werden 😉
Den Zustand bzw. die Version von 8 Nodes zu monitoren und den manuellen Updateprozess bei all diesen Nodes durchzuführen wurde immer aufwändiger.
Daher nutze ich seit Oktober 2020 die automatisierte Watchtower-Methode. Bisher ohne Probleme.

Update Dezember 2020: Aktuell befindet sich ein AutoUpdater für Linux in der Entwicklung, der in Zukunft direkt in der Storagenode-Software integriert sein wird. Damit wird die Updatemethode über das Watchtower-Image vermutlich obsolet.

Schreibe eine Antwort