Container w/ Yamagi Quake II
Go to file
Daniel Wolf 0045a42393
Build Container Image / build_amd64 (push) Successful in 2m4s Details
Build Container Image / build_i386 (push) Successful in 2m0s Details
Build Container Image / build_arm64 (push) Successful in 7m17s Details
Build Container Image / push_i386 (push) Successful in 16s Details
Build Container Image / push_arm64 (push) Successful in 22s Details
Build Container Image / push_amd64 (push) Successful in 8s Details
Build Container Image / build_riscv64 (push) Successful in 14m30s Details
Build Container Image / push_riscv64 (push) Successful in 17s Details
Build Container Image / build_armhf (push) Successful in 15m36s Details
Build Container Image / build (push) Successful in 1m37s Details
Build Container Image / push_armhf (push) Successful in 16s Details
Build Container Image / update_readme (push) Successful in 9s Details
Build Container Image / push (push) Successful in 6m44s Details
fix: remove temporary bandaid from zaero code
2024-03-28 11:07:36 -04:00
.gitea/workflows refactor: rewrite ci workflows 2024-03-28 11:01:26 -04:00
.reuse chore: better reuse compliance 2024-03-28 10:54:59 -04:00
LICENSES add reuse copyright information 2023-10-25 12:50:03 -04:00
override chore: better reuse compliance 2024-03-28 10:54:59 -04:00
.dockerignore update *ignore files 2023-10-25 12:37:37 -04:00
Dockerfile fix: remove temporary bandaid from zaero code 2024-03-28 11:07:36 -04:00
LICENSE.md update license #noci 2024-03-09 09:38:51 -05:00
README.md use tag yamagi instead of yamagi-latest to match unraid template 2024-03-06 11:24:50 -05:00
docker-compose.yml add reuse copyright information 2023-10-25 12:50:03 -04:00

README.md

Git | Docker | unRAID

Yamagi Quake II Dedicated Server

This docker container manages the Yamagi Quake II dedicated server.

The yamagi tag points to version 8.30 and this is the only image actively being updated. There are tags for older versions, but these may no longer be using the latest Alpine version and packages.

Docker-Compose

These are example docker-compose files for various setups.

Single Server

This is just a simple Quake II server.

services:
  quake2-server:
    image: nephatrine/quake2-server:yamagi
    container_name: quake2-server
    environment:
      TZ: America/New_York
      PUID: 1000
      PGID: 1000
    ports:
      - "27910:27910/udp"
    volumes:
      - /mnt/containers/quake2-server:/mnt/config

Single Server w/ HTTP Mirror

This container is set up to create an HTTP mirror of the game contents so that players joining can get better download speeds on engines that support it. You can easily add an NGINX container and map a separate volume that is shared between the game server and NGINX. Then you can just put that volume in QUAKE2_MIRROR and the ${QUAKE2_MIRROR}/www/quake2 directory will reflect the installed game data on the server.

NB: You will need to manually configure NGINX's config to share /mnt/config/www/quake2.

services:
  quake2-server:
    image: nephatrine/quake2-server:yamagi
    container_name: quake2-server
    environment:
      TZ: America/New_York
      PUID: 1000
      PGID: 1000
      QUAKE2_MIRROR: /mnt/mirror
    ports:
      - "27910:27910/udp"
    volumes:
      - /mnt/containers/quake2-server:/mnt/config
      - /mnt/containers/quake2-http:/mnt/mirror
  quake2-http:
    image: nephatrine/nginx-ssl:latest
    container_name: quake2-http
    environment:
      TZ: America/New_York
      PUID: 1000
      PGID: 1000
      ADMINIP: 127.0.0.1
      TRUSTSN: 192.168.0.0/16
      DNSADDR: "8.8.8.8 8.8.4.4"
    ports:
      - "80:8080/tcp"
    volumes:
      - /mnt/containers/quake2-http:/mnt/config

Multiple Servers

This is an example where you want to run two servers on the same host. In such cases, it is possible to have them use a shared game data volume. You just map a separate volume that is shared by both and put that volume in QUAKE2_INSTALL on one and QUAKE2_DATA on the other. Make sure that the first container starts before the other so that the installation is all set up for it and you should be good to go.

When hosting multiple servers, you can use a port setting of 27911:27910/udp instead of specifying a different internal listening port in GAME_START, but the port is used for both the port being listened to by the server as well as what they advertise to the master server. So if you want your servers to show up properly in the master servers, you'll want to specify the port each should run on and map those separate ports on both sides.

services:
  quake2-server-1:
    image: nephatrine/quake2-server:yamagi
    container_name: quake2-server-1
    environment:
      TZ: America/New_York
      PUID: 1000
      PGID: 1000
      QUAKE2_INSTALL: /mnt/shared
	  GAME_START: "+set port 27910 +exec server.cfg"
    ports:
      - "27910:27910/udp"
    volumes:
      - /mnt/containers/quake2-server-1:/mnt/config
      - /mnt/containers/quake2-data:/mnt/shared
  quake2-server-2:
    image: nephatrine/quake2-server:yamagi
    container_name: quake2-server-2
    environment:
      TZ: America/New_York
      PUID: 1000
      PGID: 1000
      QUAKE2_DATA: /mnt/shared
	  GAME_START: "+set port 27911 +game ctf +exec server.cfg"
    ports:
      - "27911:27911/udp"
    depends_on:
      - quake2-server-1
    volumes:
      - /mnt/containers/quake2-server-2:/mnt/config
      - /mnt/containers/quake2-data:/mnt/shared

Server Configuration

These are the configuration and data files you will likely need to be aware of and potentially customize.

  • ${QUAKE2_DATA}/data/quake2/*
  • ${QUAKE2_DATA}/data/quake2/baseq2/server.cfg

By customizing the GAME_START variable, you can run in a different game directory or exec a different config file, of course.

Modifications to some of these may require a service restart to pull in the changes made.