A fork of https://github.com/mccarrmb/docker-doom with my own improvements

@Matt McCarragher Matt McCarragher authored on 10 Nov 2018
bin reverted summon to hard coded 6 years ago
builder template garbage 6 years ago
config changed to default 7 years ago
iwad forgot heretic 7 years ago
player renamed files to match defaults 6 years ago
wad started config work 6 years ago
.gitignore added vim and macos crap to gitignore 7 years ago
Dockerfile removed unnecessary ENV lines 6 years ago
README.md fixed README 6 years ago
build-docker-doom.bash updated README and cleaned up root 6 years ago
build-docker-doom.ps1 added PoSh script 7 years ago
docker-doom.bash changed extensions 6 years ago
docker-doom.ps1 neglected to write a powershell startup script 6 years ago
README.md

docker-doom

A Zandronum server configuration and deployment tool utilizing a Docker-based back-end.

Usage

  1. Install Docker
  2. Run build-docker-doom.bash or build-docker-doom.ps1
  3. Run docker-doom.bash or docker-doom.ps1
  4. Connect to your dumb shareware Doom server

F.A.Q.

Q. What if I want to customize this container to run a different Doom engine game?

A. You can manually edit Dockerfile, default.cfg, adminlist.txt, banlist.txt, whitelist.txt, and summon.bash to include the desired settings... or just hold tight until I get the "Builder" tool completed. Just a heads up: you'll need Ruby version >= 2.5.0 installed to run it. I plan to test this on the native Windows version of Ruby so it should run without having to do any weird Linux subsystem magic.

Q. What if I'm on Windows?

A. Good news! There is a PowerShell script included alongside the original Bash scripts. Just make sure your PowerShell environment is configured to run unsigned scripts via the Set-ExecutionPolicy cmdlet. I'm contemplating writing a seperate Dockerfile that will build a genuine Windows container, but that's a ways off.

Q. Why wouldn't I just run these servers locally instead of firing up containers?

A. You could totally do that. In fact, there really isn't much of a difference. I prefer to use Docker, though, because it saves me the hassle of trying to write clever UpStart/SystemD/rc.d-type service scripts and jobs. All I have to do is add --restart always to the run line and the Docker daemon will take care of keeping the servers running. Docker also makes it easier to run simultaneous instances since the network ports only have to be specified at container runtime - making custom config files for each port/instance unnecessary. You are more than welcome to use these resources in building your own non-container server, though. All of the configuration files - save for summon.bash - are OS agnostic, so you shouldn't have any problems using them on Windows, Linux, or macOS.