Column01
commented
2 years ago This is something that if we implemented, would essentially make the wrapper pointless. Docker already can be used to do these things, and the reason mark2 exists is so all server instances are in one location with a common console interface (and for its scripting and automation capabilities).
The servers are already separate, each instance cannot escape the server root directory nor affect each other significantly unless there is an exploit in the Minecraft server code that allows you to do so (like an RCE or malicious plugin you install). If you are talking about completely separate filesystems and containers for separate instances, that simply isn't possible with how mark2 is coded since all the communication with the server processes happens via UNIX socket files stored on the hard drive somewhere. If we open up the file system to allow that communication, it defeats the purpose of containerizing the entire server. I also don't think mark2 would handle suspension of the process without pooping itself, nor would any server proxy AFAIK.
A wrapper that works with Docker containers could be made, but mark2 (and mark3 when I get time to work on it) will not be supporting it.
Running servers inside containers would be beneficial as it would make sure servers can never effect each other. It also allows for much better scalability. You would also be able to pause docker containers without needing to reboot the server, meaning servers could pause when no players are online, and come back on when they try to join. Would require a proxy server of sorts but would be easy to do.