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!

I used the OP script with slight modifications and supervisord to run it.
Only thing that isn’t working for me is the console, which simply returns 404

Tried using to point where i have the static files from git, but same problem:
console.static-dir: “/mnt/shared/storj/build/storj/web/storagenode”

Any ideas?

I’m interested to know more about your system specs and the compile time of go build -ldflags . thanks.

I think this topic is outdated :slight_smile:

Look into GitHub commits, it was merged to master.

1 Like

I’ve had some success getting the web dashboard to work when I build storj on Linux using the included make file.
Simply running the make command with no arguments will give you a list of build options.
You might first try running:
make build-dev-deps
to download some of the build dependencies.
You then might try:
make binaries
which will build just about everything for every platform. You can study the contents of the make file to see how it builds things.
It seems to be using a docker image to build the web console files and a go-bindata program to “embed web assets into go”. The make command will handle all that for you if you get all the dependencies installed which you might have to do manually.
Disclaimer: I haven’t really tested the build results with a real online node that contains live customer data yet, so I can’t say if this will break your node or get you disqualified. Proceed at your own risk.