Container w/ Yamagi Quake II
Go to file
Daniel Wolf 70eebc1cf5
Build Container Image / build_amd64 (push) Successful in 1m26s Details
Build Container Image / build_i386 (push) Successful in 1m21s Details
Build Container Image / publish_amd64 (push) Successful in 27s Details
Build Container Image / publish_i386 (push) Successful in 29s Details
Build Container Image / build_arm64 (push) Successful in 4m58s Details
Build Container Image / publish_arm64 (push) Successful in 30s Details
Build Container Image / build_riscv64 (push) Successful in 7m22s Details
Build Container Image / publish_riscv64 (push) Successful in 8s Details
Build Container Image / build_armhf (push) Successful in 10m28s Details
Build Container Image / build_manifest (push) Successful in 7s Details
Build Container Image / publish_armhf (push) Successful in 51s Details
Build Container Image / publish_manifest (push) Successful in 54s Details
add reuse copyright information
2023-10-25 12:50:03 -04:00
.gitea/workflows build i386 images 2023-10-25 12:41:33 -04:00
.reuse add reuse copyright information 2023-10-25 12:50:03 -04:00
LICENSES add reuse copyright information 2023-10-25 12:50:03 -04:00
override add reuse copyright information 2023-10-25 12:50:03 -04:00
.dockerignore update *ignore files 2023-10-25 12:37:37 -04:00
Dockerfile build i386 images 2023-10-25 12:49:23 -04:00
LICENSE.md migrate from drone to gitea-runner 2023-05-04 13:51:17 -04:00
README.md add reuse copyright information 2023-10-25 12:50:03 -04: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-latest tag points to version 8.20 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-latest
    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-latest
    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-latest
    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-latest
    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.