As discussed in other topics, I think the realistic earning estimator Realistic earnings estimator is overly optimistic. To put my money where my mouth is, I set up a Docker Node.
Will report back monthly how it is going!
My node costs exactly 0$ to run, as it only uses 100% unused resources
RAIDZ2 120TB dataset (currently free 90TB), 1MiB recordsize, mirrored SSDs as special vdev set to 2KiB. 10GBit Fiber connection, no neighbors in my subnet.
We just hope that finally we would get more customers with IPv6 eventually (right now it’s very low numbers, like 2 connections from 110), but maybe you can provide a stat for your node to see how it’s changed since I’ve checked.
First 32 hours are done! I am, starting to like Docker. Just change some commands, stop container, delete container, restart container. It is really fun to play around. Still think I would go for bare metal for anything serious, but for something like that it is great. Also I could easely run 10 containers without much effort.
I got 39GB data, which is over 1GB an hour! Not to bad!
How is the container overhead in general nowadays? I like to keep complexity to a minimum and I like to thinker with settings and read into it.
Take Nextcloud for example. There are so many settings you can tune. PHP settings, caching settings, locales. My guess is that you could do the same by just adding hunderds of options to the Docker commands? I guess that is what the yaml files are used for?
Containers provide os level virtualization, so the overhead is minimal, and is mostly in management overhead and resources needed to run the whole contraption.
Generally, for go software, containerization provides almost no benefits – perhaps, it simplifies deployment a bit, but that’s it. go software is already self-contained, so resource isolation aspects of docker – the big chunk of why it exists – does not help anything.
What remains are various virtual networking solutions – that arguably do more harm than good – see all the struggle enabled TCP Fast Open on docker managed virtual bridges for example, and a fancy scheduler and updater – it’s easy to download, update, and schedule execution of the container.
Docker (which is also written in go btw) grew to become an a massive monster that can do way more than storagendoe requires (swarms, clusters, volumes, fancy networking) and all this reduces reliability and increases use of resources.
So, if you want efficiency – run storagenode directly on your host OS. There are no dependencies, so no conflicts with existing software (aka dependency hell). You will need to manually configure systemd to start your node, and run stroagenode-updater to keep it updated.
It’s a non-zero amount of work.
Here is where podman comes in. It’s a drop-in replacement for docker (you can literally symlink docker command to podman and all your docker commands will continue working) but it’s much more lightweight that actual docker, it does not have a separate service that is always running, it can run containers rootless arguably easier than docker, and it generates service definitions for systemd automatically for you.