I finally spent the time to kick the tires on packaging the UT4 Alpha server in Docker and so far so good aside from some weirdness I suspect to be related to it's Alpha state.
This docker module took me a bit of time to get up and running even thou it's conceptually a pretty straight forward system, it has no dependencies on other services running and isn't particularly picky about OS vintage. However these servers do pose a few challenges for people looking for very svelte install profiles and non weird server behaviors. Specifically a number of oddities crop up in this docker image that you don't experience when setting up a 'raw' Linux installation. Some are nuisances, others are heavier problems for resource usage that hopefully Epic resolves in the future.
- The configuration files migrate from the 'correct' location in a standard Linux install up the tree one step, this seems to be a bug in the platform detection which presumably returns a null instead of an OS type. This isn't a huge problem, but it made adapting from expectations in the raw Linux configuration a bit confusing.
- The server software requires an xserv to be running in order for the package to start up. This is probably the biggest stumbling block, the reason for it seems to be only to verify that you approve the EULA of the server via a visual accept button rather than a y/n prompt on the command line but it's there and we have to address it. The docker file includes a work around utilizing Xvfb to create a headless system but will require you to accept the EULA by configuration file tweak instead of accept button. You can find the Unreal EULA here, I believe this is the same one that applies for the server and you should probably review it if you plan to use the software, the related configuration tweak is included below.
- The zip files containing the Linux Server binaries can not be posted on third party sites (like say this one). This means you will need to retrieve the links from the official forums. A secondary effect of this is that if I uploaded this to the docker repository it would not be capable of building the Dockerfile as provided.
Taking that all into account, lets walk through the pile of scripts I use to setup and rebuild my personal UT4 server.
First, we have the rebuild script. This will stop the currently running container and remove it, then rebuild the image from the Dockerfile located in the same directory as the script.
If we need to get a bit more aggressive, if for instance we want to rebuild the entire image the cleanut.sh script will handle that for us. It operates similarly to a 'make clean' command in that it stops and removes the running container, and then goes further to remove the underlying image. This is basically the nuclear option for when you want to start over from scratch, I've found it useful when docker won't rebuild even though a new build has been released.
Now for the meat of the gist post, the Dockerfile itself. It's not 'that' complicated but it's got a few weird things that I should explain for people.
Once again I'm building this against a CentOS base image, it works extremely well and gives you a solid no frills install. Which we promptly crud up with a handful of tools we need, wget, unzip, and an odd one called Xvfb get pulled in. This is also where the actual code for the server is downloaded, you MUST replace the text '<unreal Linux source link here>' with the current URL for the server code, from the official forums, in order for the docker file to work. We expose a folder called '/conf' to mount against for importing configuration files into the environment. We also setup a number of symbolic links from where the server process wants to put those files to the /conf folder so that we aren't presenting a weird SUPER leaky interface on that volume. We also create a symlink between /conf and a deeper nested folder, just in case the newer versions of the server software put config files where they are supposed to go in Linux servers. This is necessary because the platform identification doesn't seem to work correctly inside docker.
After all that we get to the last piece of magic, the CMD run at the end of the file. This command issues the actual server start command but wraps it in the 'xvfb-run' command which allows it to startup happy. It does this by effectively creating a fake screen for the server process to draw to, it doesn't actually draw anything but it requires the ability to do so. It is important to note this will not work 'out of the box' because of the previously mentioned Unreal EULA approval. You will need to add the below tweak to your Engine.ini file for everything to work.
The last script in question is the set of commands I use for setting up the server on my local system. By changing '-v /zfswdred/nfs/dockdata/ut4serv/LinuxConfs' to a location on your local file-system you can select the location of the UT4 server config files making setup beyond this point trivial.
Future Work: I haven't figured out how to roll this into a UT4 HUB instance just yet, that's mostly because I haven't looked at the docs at this time. I plan to do that soon, time permitting. I'd also like to figure out more clearly how to manage the map play-list and add additional maps to the system. That will likely require an additional post in the future. This one also still relies on --net=host which I need to correct now that my router and server are separated into different physical machines.
TL; DR: Like the JAServ docker file it works pretty well, and it's nowhere near as leaky. You currently get a single outward facing folder to store configuration files in and that's it. As of 11/3/2015 (it should work with the latest version as well but the auth servers are down while I'm working on this) a fresh cleanuput/rebuildut set was run with the latest server and all worked as expected. Enjoy running your own server!