I see in all documentation that developers are too used with docker that don’t even put a documentation available for those who don’t want to use docker to run their node on Linux.
I have been running mine by downloading the binary files from Github and doing all the process manually, but it still needs improvement. For example it doesn’t create as a service and need to be run and updated manually.
Can’t we just have a proper documentation alongside with the docker one for those who do not wish to run on docker and perhaps a repository for the most popular distributions that one can simply do an ‘apt install storagenode’ and have everything set, including the storagenode-updater running in the cron ?
EDIT: I was doing that as well, but ended up going to the docker installations. The deployment is far easier and running more than one node per machine is far, far easier too!
I’m kind of curious - what are the reasons people don’t want to run it in Docker? I used to run some nodes outside of docker, but I found them to be much more painful to manage. Also easier for devs.
So when I started I was worried about performance penalties. But as my “fleet” of nodes grew and I started adding more nodes to the same machines (and after reading a bit more), the docker-method kinda became a no-brainer. Mostly for my sanity
Fine for those who want to run docker, even if it looks easier, but some may just want the traditional ‘apt install storagenode’ which is quiet simple as well.
People might just don’t want to have go through the extra steps to have docker installed, have it set or just may not even know docker but know Linux enough to have it installed in a traditional way that is fine too.
Docker is an additional potential point of failure. For me this was visible in two forms. One is that Docker’s attempt at doing NAT for some reason created additional overhead, which disappeared when I started using --network=host. Second is that I found stopping a container does not always clean up all networking stuff, and every so often I had to reboot the whole machine to start it again, because docker claimed there is already a network named this way. After several such cases I found it is possible to explicitly disconnect a network (docker network disconnect -f bridge «nodename»).
It’s annoying, and in my case it doesn’t bring much value—I don’t need isolation, as this box at this point is dedicated to Storj; and golang doesn’t really get much value from having a full container OS that needs to be updated separately from the host OS.
In fact these are good points to mention.
An extra NAT by default in the docker context is unnecessary, specially if the server is dedicated to run the node and most people will not switch to --network=host
Worth also to mention that by default most docker implementations make it more difficult to communicate on IPv6 where it is already available, so by having it the default method eliminates many cases where IPv6 is available in the LAN but won’t be used due that.
Agree that in a dedicated server for storagenode this isolation is not necessary and another reason some people may prefer to run natively on Linux.
