Actually, containers are isolated enough to do no require a separate VM. Unless you use Mac or Windows.
Since the only program I use in a container is the node it made sense to me to create a new VM for it instead of trying to put it in some other VM with something else. Especially since I want to keep this particular VM online as much as possible.
So is Storj.
My proven formula/ stack is:
Ubuntu Server
LXD / Containers (not VMs) / Docker / Storj
LXD Storage volumes managing ZFS and mounting to to /mnt/storj
LXD network proxies to the containers (ie proxy-storj-01)
Been running this way for years with almost no issues. For me this to be the most flexible and scalable when running your own hardware. I find LXD to be incredibly good tech and the project is well managed.
I’m sorry, what? You can’t be serious. This is the dumbest thing I have read this week, and week is almost over.
A process is already an isolated entity. A process. Containers add dependencies isolation (which you don’t need for storagenode) and network stack (which you dont’ need for storagenode), and some sandboxing (which, you guessed it, you don’t need for storagenode, but if you want to – there are OS tools for that).
And then you wrap it into another whole separate virtual machine, so that whole computer now can exist to support running one process?
WHY?
This makes no sense whatesoever. Lack of anything is simpler than presence of that thing.
If VMs is the only thing you know how to manage, and you decided you are not going to spend time learning anything else – then this madness may seem to you like the only possibility and hence a great idea. It is not. It’s a bloated, inelegant, layered, wasteful, abomination, that could have been justifiable if it was solving real problem. You have none. There are no problems it solves. It’s fuckery for fuckery’s sake. “But it works for me” is not a technical argument.
Creating separate hardware to support running a single process is egregious. It is not desirable trait. Storagenode does not require the whole computer for itself.
There is nothing to figure out. You launch storagenode exact same way you do inside your VM anyway. Exactly the same way. Except you don’t have an extra bloat of a VM, so fewer things to figure out, not more.
Unprivileged processes in the OS are already isolated. One process cannot read memory of another process. This is how modern OSes work.
Next, being online and being VM are completely orthogonal things. In fact, creating so many layers reduces uptime – now you have to maintain each layer independently, and reduces reliability for the same reasons, and performance (no, not hyperwisor – memory partitioning and disk caches), as I described in the prior comment.
Please dismantle this nonsense and use technology when appropriate, and not “just because you can”.
Correct. Processes in the OS are also isolated. That’s the whole point of a process. As opposed to a thread. Containers add dependency encapsulation and networking, which node does not need nor benefits from. It’s pure overhead for nothing in return.
This is not Mac or windows issue. This is an issue attempting to have linux runtime on non-linux hosts. You need to have either linux user space (which, by the way, windows has, you can run node directly win WSL1 (screw WSL2), if they did not kill it) or FreeBSD which has the whole linux user-space bindings. If your container is not linux and is based on some other OS you don’t need a VM to run it on the OS.
Right, and?
There’s no obligation for Storj to offer its services without third parties.
It’s would be impossible to do so even if desired.
My point was that docker is not some gold standard paragon of correctness in how containers orchestrator shall be designed and implemented. It’s a crappy product of some company that is very good at marketing but not so much at engineering. The fact that containers and docker are conflated in peoples minds is an unfortunate consequence of their branding ingenuity.
However this is a technical forum, and it’s bewildering to hear docker from every corner, all while normalizing its shortcomings.
And extra medal for those doing it on synology. That I will never understand. I guess some people like to suffer.
The reason I am using docker is because originally the node was only available on docker. I would have used a separate binary if that was available at the time.
And since I had to use docker, I continue using it, because I do not see the point of changing anything in a running system.
It would still be a separate VM just like with everything else though.
Lets say my host runs an old Debian version and some program (not necessarily the node) wants a newer one. Alternatively, when I update the host, all of the VMs remain the same until I decide I want to update them as well, so nothing breaks. Even better, I can run Windows VMs on the same host as Linux VMs and they all work.
Docker networking is more complicated. I’m sure it is possible to ahieve the same thing (storagende on a different vlan than the host), but, again, it seems more difficult than just running a VM that has only one network interface (to that vlan) and running the node by following instructions on Storj website.
I dislike docker in general, to me it makes stuff more complicated, because, to me, the line between the container and the host gets a bit blurry. With a VM it is easy for me to separate things, for example, if I run “ps aux” on the host I do not see processes that run on VMs, just the VM processes. I like that. Maybe it is possible to do this with containers as well, I don’t know though.
Whenever I want to run something, I spin up a VM, I run the thing on there and if I decide I no longer want it, I can delete the VM and all changes made to run the thing are gone. I don’t need to uninstall all packages that I installed for the thing and so on. I do not need to make two things that want different system settings or different packages (say, different php versions) work together. This is why VMs are easiest for me.
Also, escaping from a container seems to be easier than escaping from a VM.
Let’s say I run the node and something else on the same VM (or the same server with no VMs). I decide to update the other thing, but it requires newer version of the OS. So now I have to update the OS and that means restarting the server, which includes the node.
As it is right now, the node and the other thing are on separate VMs. If I decide to update the other VM, the node is not affected, I can restart the other VM as many times as I want. Alternatively, if I decide to update the node VM, the other thing is not affected. They are only affected if I decide to update the host, but then at least the VMs do not change, so I do not have to deal with any possible breaking changes there.
Does running a VM result in less performance? Yeah. But if my old hardware can deal with it, I guess it’s not a big deal.
The title is misleading and this thread addresses a non-existent problem. What issues does anyone has running storagenodes with Docker?
My nodes are running perfectly even on Synology with its “special” Docker version. I never felt that I’m struggeling more with Docker than someone running nodes as services, or had more problems with it.
I did not write the title, the discussion was branched out from another topic by moderators.
None. None at all. Everything is tip-top
It works for me, therefore the problem does not exist, cannot exist, this is a testament to an excellent design, and everyone else just does not know what they are talking about.
Obviously, there will be some that have no issue with this at all, and that’s part of my problem.
The problem is described multiple times in this very thread from multiple angles btw.
exactly. As far as I understand, some can have a server with Proxmox, so the convenient way is to use VMs. I know, that Proxmox also support containers, but users do not know how to run a docker image there properly or do not like it 
This is a lightweight Linux VM with a good integration to Windows. So not a reverse analogue of Wine/Proton.
That describes WSL2
WSL1 is linux ABI/Syscall compatibility layer provided by windows kernel; there is no linux kernel, there is no VM.
WSL2 is a “lightweight” managed VM that runs linux kernel.
WSL1 is great. But as 100% of great things that came out of Microsoft, it was effectively killed in favor of WSL2, which on paper shall be easier to stabilize, but in reality it’s worse VM with Microsoft bloat and extra layer of bugs. For example, they never fixed memory consumption and [lack of] release issue. issue still open since 2019. its trash. If you use WSL2 – you’ll be better off with VM inside a sane hypervisor.
LOL, with WSL1’s I/O performance.
True. But this is expected, we are talking about Microsoft here, after all, what do you expect?
I’m commending the idea, not the execution.
And yes, the fact that they managed to screw up perfomrnac with direct ABI compatibility layer.. is in its own way magnificent.
“They are gluttons for punishment.” (Meaning: Someone who continues doing something despite it causing them pain or misery) would likely be the closest in actual meaning.
ChatGPT suggested me the same analogue, but it is not accurate at all and misses the crucial distinction:
This versions means: “ they keep choosing something unpleasant, often because they seem to perversely tolerate or seek hardship”.
Original means: “they are visibly suffering from a self-inflicted bad choice, understand it hurts, complain about it, yet irrationally continue”.
Maybe the best would be just literal-ish translation:
“They keep chewing the cactus and complaining that it hurts” or “ They keep crying about the spikes while chewing the cactus.”.
This was also suggested by ChatGPT, but conveys the message colours a bit better.
This thread reminds me that… sometimes… people just want to argue about what color crayon tastes best.
Not a problem: go for it: you do you! 
(what have you done!?!!)
Red or orange, obviously, because they map to sweet/fruit/candy expectations best.
The worst would be gray… it maps to nothing but sadness…