MSM Docker Intergration

[nuttah]

Some more time has passed by.. Docker has become way more stable and majure. A lot of new features (swarm, compose, networks stuff .... ) has become a reguilar part of docker.

With swarm there are several new ways to scale out minecraft nodes to a 2nd/3rd.. machine by still using the same network. Especially together with bungeecord and a good ansible conception (because it's easy to implement) MSM can be brought to a new level of utilization for Minecraft operators.

What do you think about and has anyone ever drilled any deeper into docker/minecraft in combination with msm ?

[OvermindDL1]

Not with msm, sadly given up on msm, but while bored two days ago I whipped up a test project that basically handles that. It has a web interface (also can be controlled via the command-line though, could disable the web interface), it manages temporary docker containers that link to defined areas and launch's the minecraft server inside a docker session. If I get around to actually finishing this I plan to allow people to log in, be part of a group (assigned by admin), the group has a certain amount of servers they are allowed to run (1 by default, probably better to limit by ports used though...), they would upload the server (like a mod pack) or could run vanilla or whatever, it would be launched inside docker exposing the default MC port to whichever of the ports they are allowed to use and assigned to it. Seems easy to build, but mostly doing it as a fun project instead of a real project. If anyone wants to help to finish it faster I can upload it to github instead of bitbucket?

[nuttah]

Can't really get the focus of your docker project. Here's What I'm unintested in:

• Command line based start/stop/restart of mine craft server instances running in containers
• data handling of docker containers, at the moment I'm using local mounts which are linked into the container
• resource management of minecraft containers
• maintenance of docker containers' data (backup, snapshot etc) Functionality which should be featured as well:
• Centralized logging for servers and plugins
• support for swarm and overlayed networks for load balancing and scale out functionality
• bungee support for automated linking of minecraft containers

I've forgot some important features by sure and some will have a lot more ideas... I'm interested in supporting/contributing into such a docker based project and already worked out some things for my server environment, depending on the way you are planning to design such a framework I can support less or more. What are your plans? Maybe it would be a good idea to start with a new git project which maybe can still have a realtion to msm.

[OvermindDL1]

Right now what mine does is run a daemon that manages the specific containers that it starts up and knows about, links to a local data directory that is subfolders of //// Right now they keep a stream open to the server so it can easily send commands to and get the real-time log from the MC server itself (currently just displaying the log in the browser in real-time while also letting you send commands, so right now it is a web page interface to the MC Server, plan to add more features later if I feel the need). So the daemon itself handles logging. MC Servers themselves are just designed to be uploaded zip archives of a MC server (I might add vanilla setups built in to start, but in general it lets you take, for example, an FTB Server build, upload it, and run it). Logging in the daemon is broadcast to any listeners on those channels. The server is capable of being branched to other servers and right now I have no access bottlenecks so it is possible, but I've not made anything explicit on it.

I have no clue what bungee is, so far it is only supporting minecraft, though I did leave it open enough that I am likely to integrate StarMade and Factorio servers. The framework is still very open, just making things that I find useful, and currently I have no auth for it at all yet (I have it behind nginx with an HTTP login header) but I do plan to add auth so my friends can manage their own servers without seeing the other peoples, but as the framework is very much in flux right now then any input or PR's would be useful.

Right now the plan is just to make simple server administration via website (and console/ssh interaction as I prefer the console, the main reason for this is for the web interface because the other people hosting servers here fear ssh... >.>). Currently I am testing running containers via the docker -it --rm java /data/launch.sh command and via the http interface, however I've found a bug in docker in which is the 'hosting' server (docker client) dies while the container is still going, then the container is left in an open 'zombie' state (see https://github.com/docker/docker/issues/16575 for details, it is still Open and unresolved). After I finish testing whichever works best between raw command access and using the docker http API (the http API is nice as it could administrate other servers without needing to run the daemon 'on' those servers, however that also means opening up the http interface on docker, which I do not like...), then I will add in functionality to scan existing containers to see if any are zombied and try to recover it or kill the MC server within. It is still very early code but it was working up until I started this docker changeover, will upload it to github instead when I get some time to work on it and try to decide.

What do you think is better and why, the raw docker client commands, or using the docker http interface?

[nuttah]

Sorry, at the moment i Can't get all the features you have already implemented or you've planned.

first the answer to your question: if you're talking about the native http interface, there's no difference between the two methods, they are using the same API and using the same CLI. The thing you are calling raw is known as Sockets API. Well, if you ask me, I'd prefer the http rest based API. There are a lot of advantages:

1. you don't have to give out shell accounts nor you have to have root rights to run or administrate containers
2. you can do all docker based management over the network which is not possible with sockets.
3. you can implement multihost architecture and link them with a overlayd network (VX technology). This can best realized with docker swarm.

Docker itself does not know anything about users and roles, yet. If you want to seperate clients (mandators) from each other you have to encapsulate the whole docker api (whether its socket or rest based) from that WEB GUI you're offering the service on. If you're planning to use the native docker daemon there's no other way at the moment which became prominent in my opinion. There are only big solutions handling multiclient hosting like openshift or mesos. Both are a big pain XXXX to implement. To terminate SSL and secure the http API best practise is to use a Proxy (as you did with NGINX). The docker Clients can send a header containing their certificates.

Docker itself has a lot of features which can be used as a replacement of msm. You can just attach yourself to a mc server console by reattach to a docker container. I'm using the -ti for tty and standard in as well. This is because getting back attached to the container's console quit easy, but maybe it has to be checked if -d would have any benefits. And of course you can also deploy and run by new using the --rm switch, but then you have to have everything else sorted out in front of the deployment. For loggin you can just use 'docker log'

I'm using -v and having my config, the worlds and plugins on a mount on the local server and mount them into the container. I'm using a little post deployment process after running the container. Here I'm arraning the mounts inside the container etc. At this point you can think about implementing etcd for big envrionments.

If it is planned to fully deploy a minecraft server as part of the container creation as msm does, you might have to put in the deployment process into image deployment or into the post container deployment because of legal issues. If you want to leave it to the admin to obtain and deploy the right server jar file you can leave that point. Netherless it's still the question if you want to deliver a finished image containing the deployed mc server, an container or to leave it to the server admin. This is a philosophical question.

Well some thoughts from me... :D

Again, we have to find the focus for that docker based framework. Is it just for maintainig web based ot should it cover all the rest. I've already outlined very rough my blueprint for such a framework yesterday.

[OvermindDL1]

I've not planned mine out for such a big system, just little web administration (though pull requests accepted). No images are created, I've just been using the raw 'java:8' docker image, linking a data directory internally to the filesystem where the users server zip was extracted to, stuffing their launch command into a script that is run when the --rm'd (about to be removed to manage it manually) container launches. The system I am using can already distribute amongst servers so opening up ports for docker is not necessary, but yeah probably going to change it to the http interface.

Heck, if you want to handle the docker stuff then I'll work on the web interface?

[nuttah]

Yes, this sounds like a plan. Some things needs to be defined and declared so we're moving into the same direction. How to start and where to start from? Are you using bash for the scripting part ? Well I'm mostly interested in spigot servers yet. craftbukkti and vanilla seems to be quit easy to adapt.. For StarMade and Factorio i have to have a look on it. Just had a look. Are they typcial mc servers at all ?

[OvermindDL1]

Well my starting (which could be thrown out if needed, I've not put a lot of time into it yet but I know the language and its features well and they are well suited for this task). Right now a 'Server' is defined as:

  schema "servers" do
    field :name, :string
    field :group, :string
    field :cmd, :string
    field :server_type, :string

    timestamps
  end

The name is the name, the group is the group, the name<>group combination is a unique indexed field. The cmd is dumped into a 'launch.sh' file that is put into the data storage_directory/integer_id_field_of_server/scaffold directory (or whatever it ends up being, I'm in the midst of rewriting this part of the system at this moment). The user can upload a zip, which is then extracted into a storage_directory/integer_id_field_of_server/data directory. When the server is launched then it mounts both the scaffold directory as read-only and the data directory as read-write in the docker java container, sets the current working directory to /data and runs /scaffold/launch.sh to run the user commands within the container to launch it. In the rewrite of the server launching and handling part that I mentioned above I am also starting functionality to setup server interfaces, so a minecraft one (or spigot or whatever custom setups) can have unique buttons and commands, starmade could have its own, factorio its own, etc... etc...

Any servers whether MC, forge, or other games servers could run in this style with no issue, I want it fairly generic as I manually manage about 10 different running servers across 4 kinds of games on my main server right now, would be nice to get that in a simple interface for them all.

Starmade and factorio are both just 'launch and wait', some accept commands on input as well like minecraft. But this style should be able to handle any type of headless stdin/stdout game server on any game, which is near all.

[DGreenstein]

I suggest you look at the Kubernetes Minecraft Chart (https://github.com/kubernetes/charts/tree/master/stable/minecraft) If you are not familiar, k8s provides a way to manage dockerized apps, but has extracted storage and network stuff into easily managed and provisioned services. So now you can build a data safe Docker instance of Minecraft, and manage deployments / etc from a central management interface. I was thinking about starting a project to take the MSM tool and bring it to a k8s chart which would build the storage and provide appropriate network constructs for a MC server in a cloud architecture. I like the MSM scriptability. Being able to make a container which grabs MSM, then builds the correct server version on the fly seems really appealing. Support for passing env variables or secrets for describing which specific MC version to use, pass in a world name, etc.

[nuttah]

Thanks for the info. I'll give it a try. I'm about to install origin on my MC servers..... I still like MSMfor all the facts you've mentioned. If you're planning to add docker/kubernetes functionality into MSM please let me know.