New things learned from Minecraft Docker project

Note: this post was migrated from my old Tumblr-backed blog

After pondering for the better part of a day since building my Minecraft Docker image, I’ve come to realize some poor assumptions that I’ve made and now see a more correct way of doing things.

The primary thing that I learned is that I need to treat Docker containers more like a standard unix process with a slightly different interface rather than like a Virtual Machine, like I had been [mentally] treating it.

The image that I built is using mcwrapper inside the container to manage the Minecraft Server process rather than using mcwrapper to manage the container itself. Doing it this new way requires some changes to the mcwrapper, too, as it needs to inspect the container’s ID rather than the pid, and needs to call docker run rather than calling java with the necessary configurations.

In the coming week, I’m planning to make these changes and kick out another release of the Docker image along with a new mcwrapper. I just need to figure out exactly how to approach this. Currently, my TODO list is:

• use container_id instead of pid for determining if the server is running
• install/upgrade minecraft_server.jar inside the image
• use docker run to launch the process
• make sure the FIFO works between the host machine and the Docker image
• because docker run requires root privileges on the host, mcwrapper needs to support that (it’s partially implemented now, albeit, a little half-assed).
• add mcwrapper config options for memory and cpu shares of the Docker container
• add mcwrapper config options for filesystem locations of the world data and server config

I don’t necessarily want mcwrapper to be married to Docker, so I may have to make changes so mcwrapper can be extended to support any target platform, be it AWS, DigitalOcean or Docker. It should be possible, but may be quite an undertaking.