adding docker and singularity container recipes and instructions

[vsoch]

Signed-off-by: Vanessa Sochat vsochat@stanford.edu

This pull request will add a docker folder, including recipes to build a Docker and Singularity container that can be used (with Singularity) to run the game in a container. For those that are interested in testing, you should install Singularity and then pull this container from Docker Hub

$ singularity pull docker://vanessa/unknown-horizons:dev

and then run it:

$ singularity run unknown-horizons_dev.sif

I think that it might be possible to leverage devices from the host with Docker (see this post)
but I couldn't get it working on my host. For the time being, Singularity is a better technology for leveraging the host resources.

If the user/developer wants to avoid Docker all together, I've also provided a Singularity recipe that can be built and run:

$ sudo singularity build uh.sif docker/Singularity
$ singularity run uh.sif

[Jeeppler]

@vsoch what are the performance impacts running Unknown Horizons in a singularity container? Have you done any testing to evaluate if it can run smoothly in a container?

[vsoch]

I can't give you performance of Docker vs. host, but I can say that for HPC workloads, Singularity is right on par with bare metal. It's actually been seen that python applications can run faster, given that Singularity can block off extraneous python imports that would have been found on the host.

The goal is really providing quick to run, reproducible builds. The steps to install on the host are a bit arduous, and this makes it usable in one command. I wouldn't be the right one to test the container because I'm not familiar with host game play (and I don't typically install libraries directly on my host).

[vsoch]

Do you know why the travis tests fail? I didn't change any of the game code itself. If travis is being patchy, I've moved a lot of my testing over to CircleCi which (thus far) is working much better.

[jmdejong]

The tests are outdated. The same tests fail in master too.

[vsoch]

Ah, ok, thanks for the detail.

[Jeeppler]

@vsoch Running web server and headless Python applications in containers is easy. However, running a game in a container is a different story, especially if you want to use the Graphics card for acceleration. The reason is that containers are normally not allowed to use hardware peripherals, otherwise it would impact the isolation.

You mentioned this:

I think that it might be possible to leverage devices from the host with Docker (see this post)
but I couldn't get it working on my host.

Can you clarify you statement in terms of performance and gaming experience?

[vsoch]

Have you tried it? I can't comment on Docker, but Singularity works as I'd expect. You have to understand that there are different kinds of container technology - Singularity is optimized for having a seamless environment with the host, meaning we can use the hardware. Here, see:

[MasterofJOKers]

I'd prefer not having a Dockerfile if it cannot be run with docker directly, but only with Singularity. I suspect people will not read the docs, that one has to use another container technology. Having only the Singularity file makes that clearer.
That being said, it would be nicer to make it work with docker instead. Another option could be adding a check to the container, if it's run with Singularity and if not, exit displaying a helpful error message. But for that it must be possible to detect the container technology used.

[vsoch]

The reason we have the Dockerfile is because we can use Docker Hub to host the guts of the container, which is then pulled into Singularity. It's a common practice for users, because you kill two birds with one stone. I detailed this in the README.md in the folder, if you haven't taken a look.

It's on the user/developer to read the README.md in the docker folder. If they don't, and open an issue, you can point them to that. It doesn't make sense to superficially delete the Dockerfile. It's optimal for building a container (using a cache) that can be dumped into Singularity. Building Singularity means doing it from scratch every time, and it's painfully slow.

If you can make it work with docker by all means, but I couldn't get the video driver working from the host. I'm not sure what you mean by "adding a check to the container" - docker and Singularity are completely different technologies, they are not the same container (just the file system contents).

[Jeeppler]

@vsoch thanks that is what I wanted to know. You could also measure the FPS rate running UH in the container and running it outside of the container directly on your machine.

[vsoch]

I can definitely do that! What’s the best way?

[Jeeppler]

@vsoch many games allow you to enable the FPS measurement via settings. I am not sure what you have to do in Unknown Horizons (UH). However, it should be fairly easy.

[vsoch]

ah, found it! (F10)

It looks like it goes between 35 and 42, and right now I have a ton of containers running and web browsers and music streaming :)

This is a pretty crappy laptop so I can't say it's on an optimal platform, but it feels about the same as when I played the early warcraft games as a kid, or Duke Nukem 3d. I can't offer to compare to running the game natively because I'm not willing to install those dependencies on my computer, but if some of the others on here already have, it should be fairly easy to give Singularity a try.

[MasterofJOKers]

The reason we have the Dockerfile is because we can use Docker Hub to host the guts of the container, which is then pulled into Singularity. It's a common practice for users, because you kill two birds with one stone. I detailed this in the README.md in the folder, if you haven't taken a look.

I have. I don't expect users to do it. Especially, if we would start uploading official images to Docker Hub. That was the point I was trying to make.

It's on the user/developer to read the README.md in the docker folder. If they don't, and open an issue, you can point them to that. It doesn't make sense to superficially delete the Dockerfile. It's optimal for building a container (using a cache) that can be dumped into Singularity. Building Singularity means doing it from scratch every time, and it's painfully slow.

I get that, but the other option I see is increased maintenance effort and dissapointed users. That sounds worse to me, tbh.

If you can make it work with docker by all means, but I couldn't get the video driver working from the host. I'm not sure what you mean by "adding a check to the container" - docker and Singularity are completely different technologies, they are not the same container (just the file system contents).

Exactly my point. They are different technologies, so should be distinguishable from within the container. That's why I was proposing to change the entrypoint to e.g. a bash-script, which first checks that it's actually a singularity container and prints an error message if it's not, pointing the user to the correct container technology, i.e. Singularity. Then I'd be all for keeping the Dockerfile.

[vsoch]

You aren't hitting the right use case - the user here is a developer. I'm a developer - and I would like to tinker around. I have no interest in installing all this on my local machine, but with a container I have a method to build and test without doing that. If this community is completely closed off to trying new technologies, that's a different thing. But to say that the container option hurts the project? That is not correct.

[MasterofJOKers]

I didn't get that is was mainly meant for developers. Then it should probably go into the development directory, so users don't stumble over it.

[vsoch]

Happy to do that. :)

[Jeeppler]

@vsoch 30+ FPS is good enough for smooth playing.

However, what hardware do you use? This is not a useful description:

pretty crappy laptop

Can you tell me your laptop model, CPU model, GPU model and amount of memory?

[vsoch]

I'm on a Linux Thinkpad T440s (from grad school!) that I believe has 16GB RAM, and it started with Windows, was immediately wiped with Ubuntu 14.04, and now has Ubuntu 16.04. The graphics card is whatever it came with:

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07)

For early Ubuntu installs I used to disable hardware acceleration, but I haven't had to do that with more recent. That says, I can't say I have much of a card to begin with :) I just use it for programming.

[Jeeppler]

@vsoch thanks for the details.

Can you provide the processor/CPU model as well? Here is the command to do it: cat /proc/cpuinfo | grep "model name". This will print out the CPU model for every core, so you might see the CPU model a couple of times.

[vsoch]

Sure thing!

$ cat /proc/cpuinfo | grep "model name"
model name	: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
model name	: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
model name	: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
model name	: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz

[Jeeppler]

@vsoch thanks.

[ArangoGutierrez]

+1

[ArangoGutierrez]

I will give it a try on my HP mini WS, with a Quadro M620, this weekend.
singularity + the --nv option is a + for gaming !

[vsoch]

ping! :)

[LinuxDonald]

Sorry for the long delay.