De-Dockered storage node operation

I’d like to share my approach to running a storage node, which is to forget about Docker and its multi-megabyte downloads of random images with stuff I already have on my computer. Besides, I have better things to do with my time than figuring out how yet another tool which I don’t need works.

Thus, I simply build it from source, then start it manually / via systemd.

#!/bin/bash
if [ $# = 0 ]; then echo "Usage: $0 v0.12.3 # current release!" >&2 ; exit 2; fi
set -ex
test -d storj || git clone git@github.com:storj/storj.git
cd storj
git checkout $1
go build -ldflags " -s -w -X storj.io/storj/internal/version.buildTimestamp=$(date +%s) -X storj.io/storj/internal/version.buildCommitHash=$(git rev-parse HEAD) -X storj.io/storj/internal/version.buildVersion=$(git describe --tags) -X storj.io/storj/internal/version.buildRelease=true" -o ../bin storj.io/storj/cmd/storagenode
cd ..
mv bin/storagenode /usr/local/bin
systemctl restart storj-storage

Done. Works perfectly, no root necessary. The (dead simple) systemd unit for this simply starts /usr/local/bin/storagenode run --config-dir /etc/storj/config and is left as an exercise for the esteemed reader, as is creating a configuration file (storagenode setup is your friend) in /etc/storj/config/config.yaml.

2 Likes

Can you also show some stats on audits/uploads/downloads/score ?

Sure I can, but what’s your point? there’s no difference between before-Docker and after-Docker, the node is plenty busy. No point running a node without checking that it works …

October 2019 (Version: 7.0.1)			[snapshot: 2019-10-24 15:33:23Z]
			TYPE		DISK	   BANDWIDTH		
Upload			Ingress			   188.56 GB	
Upload Repair		Ingress			   368.91 MB
Download		Egress			   493.01 GB	
Download Repair		Egress			     0.00  B	
Download Audit		Egress			     2.21 MB	
Disk Current		Storage	   254.43 GB	
Disk Average Month	Storage	   130.01 GBm		
Disk Usage		Storage	    96.73 TBh

Since there is no auto updater yet for such a setup it will require some more maintenance from time to time and it is not a supported setup for now. But yes it should work just fine if you set it up right.

Production release of Storj V3 would be dockerless so for newbies its easier to set it up via docker or wait till production.

Well, let’s just say that I tend to disagree rather strongly with any statement that has “docker” and “newbies” in the same book, let alone the same sentence. (Just look at the number of questions WRT forwarding the various TCP ports for storagenode into the container.)

In fact, I seriously doubt that instructions starting with “apt install go git” (and ending with “run this script” which we’d include in the repository “via cron each couple of hours to auto-pull+build+restart your node”) could possibly be more complicated than anything that starts with “install docker”.

But maybe that’s just me.

5 Likes

Silly Noob here (me)

Getting ones head around docker is not that easy. Also maintaining Linux for newbies is hard enough.

And if I read correctly node operators should keep their nodes as simple as possible.

In my case I run an ESXi and I have plenty of space and cpu capacity tu run 1 or a few nodes.

Setup with docker:
Metal–>ESXi–>VM–>docker storj

Setup without Docker:
Metal–>ESXi–>VM + storj

The first looks like a VM inside a VM. The later has one thing less to worry about.

Why not an ova or a pre-built Linux installation that autouodates itself?

PS: I know that docker isn’t a VM ;p

AIUI that’s planned for when things stabilize.
(I really should polish+publish my “pull, check for latest non-RC tag, check out, build, restart” cronjob script …)

The advantage of docker is consistent testing and bug reporting. If the long term plan is dockerless then having some early testers is probably a good idea.
I don’t get your “megabytes” argument. It takes seconds only to download the images, compared to days for id and weeks for vetting!