Das Updaten von Storj-Instanzen

Zuletzt aktualisiert am 19. Dezember 2021.

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.

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:

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:

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

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:

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

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 node9 --stop-timeout 300s --rolling-restart

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.

Update Oktober 2021: Bisher gibt es den Linux-AutoUpdater noch nicht, aber ich fahre nach wie vor sehr gut mit der watchtower-Lösung. Mit wachsender Anzahl der Storagenodes sollte man jedoch noch den Parameter “–rolling-restart” verwenden. Dieser sorgt dafür, dass nicht gleichzeitig alle Container gestoppt, aktualisiert und dann wieder gestartet werden (viel Last auf einmal), sondern dass zunächst ein Container geupdated wird, dann der nächste, usw – also der Reihe nach.