Rework Dockerfile, Rework Scripts, Rework ENV/Config, add k8s examples

[panromir]

• A Process-State based Healthcheck has been added (mainly for k8s - can also be used for Docker image formats, not for OCI images)

• The Dockerfile has been rewritten completely and is now based on the "officialy" endorsed steam-cmd image (and therefore Debian bookworm)

• The PV/Mount paths have therefore also changed

• It's now hadolint safe (except version pinning)

• The configuration now uses envsubst. This makes configuration by environment variables MUCH easier and more extensible - no manual fiddling with config files anymore

• Not sure if the config mount needs anything else. If this is all that's saved to Persistent Data Path (not Server Files) we can also consider removing that Mount entirely. Config files are automatically generated at runtime and logs should always go to stdout anyway, given the option to mount them somewhere else or send them to logging via sidecar

• I added examples for Kubernetes (kustomize) - I'm running a version of this in my personal cluster and it works fine
  The New Docker image is pretty large, not sure if all the packages I install are strictly necessary - WINE Sucks for hosting headless Gameservers, I hope they release a linux-native version soon :(

• The container image now runs rootless

PLEASE NOTE: MANY OF THESE CHANGES ARE BREAKING FOR CURRENT USERS

[kevinf100]

This works with current users.
Example with docker compose. However are you sure the quotes are correct in docker compose? If you use them it breaks current servers configs. Haven't tested on new servers tho.
Also you added STEAM_USER_UID and STEAM_USER_GID but never use it

services:
  vrising:
    build: .
    environment:
      - HOST_SETTINGS_NAME=V-Rising Server
      - HOST_SETTINGS_LISTEN_ON_STEAM=false
      - HOST_SETTINGS_PASSWORD=1234
      - HOST_SETTINGS_MAX_CONNECTED_USERS=20
      - HOST_SETTINGS_LISTEN_ON_EOS=false
      - SAVE_NAME=world1
      - HOST_SETTINGS_SERVER_ADMIN_LIST="YOU,64IDS,HERE"
      - TZ=America/New_York
    volumes:
      - type: bind
        source: /home/vrisingserver/vserver/server
        target: /home/steam/vrising/server
        bind:
          create_host_path: true
      - type: bind
        source: /home/vrisingserver/vserver/persistentdata
        target: /home/steam/vrising/persistentdata
        bind:
          create_host_path: true
    ports:
      - '9876:9876/udp'
      - '9877:9877/udp'
    restart: unless-stopped
    network_mode: bridge

[panromir]

Hey!

Thanks for your feedback, I removed the quotes in the docker-compose.yml file, granted I haven't tested that one, podman and kubernetes do not seem to behave like this. Apparently Docker compose takes anything behind the "=" in the environment section very literally :D

I also removed the STEAM_USER_UID and STEAM_USER_GID env vars. I intentionally left the out of the README already because I didn't really see a reason to change them, but I kept them in the Dockerfile for no apparent reason.

I guess it's worth mentioning that this container will run as user 1000:1000 by default, if Docker Compose creates folders, make sure you either run it as user 1000:1000 or change the owner of your bind mount folders accordingly. I added this to the docs.

As for the "breaking" changes: I suppose it is breaking in the sense that existing users need to adjust their env vars accordingly, as well as their compose file or docker arguments. If someone just uses ":latest" and pulls the image, they will get a whole new server. Therefore this should probably be a major version jump, if it gets merged.

I decided to add an "OVERRIDE_CONFIG" default "true" parameter, to allow people to manually edit their configs and keep the changes, instead of using env vars.

PS: Also added actual log rotation, logs are now rotated daily. And by default deleted after 30 days.

[kevinf100]

panromir#1
Maybe not the best way to go about it, but this will add arguments to allow someone to change the user and group id if wanted. Did test it and it works perfectly.
Only other option I could think or is trying to edit the user ID in the entrypoint (didn't work when I tried, probably need to be root for this), we change user in the entrypoint aka we run enetrypoint as root and remove USER from the Dockerfile, or we run the server process as the steam user in the end of entrypoint.

[panromir]

Thanks! I think the Dockerfile-based solution that you suggested is preferable, since running a container rootless is good practice.
Currently waiting for review on PR panromir#1 so we can merge into this PR :)

[kevinf100]

Done. If we further want too, we could also change the CLI example due to using expose in the Dockerfile.
From

docker run -d --name='vrising' \
--net='bridge' \
--restart=unless-stopped \
-e TZ="Europe/Paris" \
-e HOST_SETTINGS_NAME="trueosiris-V" \
-v '/path/on/host/server':'/home/steam/vrising/server':'rw' \
-v '/path/on/host/persistentdata':'/home/steam/vrising/persistentdata':'rw' \
-p 9876:9876/udp \
-p 9877:9877/udp \
'trueosiris/vrising'

to

docker run -d --name='vrising' \
--net='bridge' \
--restart=unless-stopped \
-e TZ="Europe/Paris" \
-e HOST_SETTINGS_NAME="trueosiris-V" \
-v '/path/on/host/server':'/home/steam/vrising/server':'rw' \
-v '/path/on/host/persistentdata':'/home/steam/vrising/persistentdata':'rw' \
-P \
'trueosiris/vrising'

[panromir]

I didn't even know about -P until now, however what I don't like about that solution is that the ports are random within a certain range, so I think -p is the better (or at least less confusing for newcomers) way.

[kevinf100]

Ah, missed that part. On the documention for expose it doesn't mention that, but for the correct page of -P does. Yeah that just gets confusing. Good for if you just don't want the default ports. Bad for if your new to docker or can easily forget -P uses a random host port. Yeah better to avoid it.

[panromir]

I added supervisord as a kind of "child process manager".
This isn't exactly the best way or even a good way of doing it, but the only one that is compatible with single container Docker, as well as Kubernetes and Docker Compose deployments.

Usually in k8s I would add a recurring job to rotate the logs, in Docker I have to use supercronic if I want to run the container in rootless mode, or I have to use an external process automation, which makes it more difficult to use for beginners.

Since supercronic need to run in the background and I want the container to restart if
a) the log tail dies
b) supercronic dies
c) vrising dies

I did it this way.
The healthcheck.sh is technically not necessary, but also causes no harm.

If supervisord is not desired, I preserved the old state in another branch. There however, logs are not properly rotated automatically due to the lack of cron.

[panromir]

@TrueOsiris have you had an opportunity to check this out yet?

[QuigonJohnn]

Hey!

Thanks for your feedback, I removed the quotes in the docker-compose.yml file, granted I haven't tested that one, podman and kubernetes do not seem to behave like this. Apparently Docker compose takes anything behind the "=" in the environment section very literally :D

I also removed the STEAM_USER_UID and STEAM_USER_GID env vars. I intentionally left the out of the README already because I didn't really see a reason to change them, but I kept them in the Dockerfile for no apparent reason.

I guess it's worth mentioning that this container will run as user 1000:1000 by default, if Docker Compose creates folders, make sure you either run it as user 1000:1000 or change the owner of your bind mount folders accordingly. I added this to the docs.

As for the "breaking" changes: I suppose it is breaking in the sense that existing users need to adjust their env vars accordingly, as well as their compose file or docker arguments. If someone just uses ":latest" and pulls the image, they will get a whole new server. Therefore this should probably be a major version jump, if it gets merged.

I decided to add an "OVERRIDE_CONFIG" default "true" parameter, to allow people to manually edit their configs and keep the changes, instead of using env vars.

PS: Also added actual log rotation, logs are now rotated daily. And by default deleted after 30 days.

Is the user change to 1000:1000 already live? My files are being created as root and then the autosave cleanup doesn't work

[kevinf100]

Hey!
Thanks for your feedback, I removed the quotes in the docker-compose.yml file, granted I haven't tested that one, podman and kubernetes do not seem to behave like this. Apparently Docker compose takes anything behind the "=" in the environment section very literally :D
I also removed the STEAM_USER_UID and STEAM_USER_GID env vars. I intentionally left the out of the README already because I didn't really see a reason to change them, but I kept them in the Dockerfile for no apparent reason.
I guess it's worth mentioning that this container will run as user 1000:1000 by default, if Docker Compose creates folders, make sure you either run it as user 1000:1000 or change the owner of your bind mount folders accordingly. I added this to the docs.
As for the "breaking" changes: I suppose it is breaking in the sense that existing users need to adjust their env vars accordingly, as well as their compose file or docker arguments. If someone just uses ":latest" and pulls the image, they will get a whole new server. Therefore this should probably be a major version jump, if it gets merged.
I decided to add an "OVERRIDE_CONFIG" default "true" parameter, to allow people to manually edit their configs and keep the changes, instead of using env vars.
PS: Also added actual log rotation, logs are now rotated daily. And by default deleted after 30 days.

Is the user change to 1000:1000 already live? My files are being created as root and then the autosave cleanup doesn't work

No it's not. Git pull from https://github.com/panromir/docker-vrising/tree/main
Remove image: trueosiris/vrising from the docker-compose and add context: . to the build section.
EX - https://github.com/panromir/docker-vrising/blob/e791364b5b21c8d6199bc469dbcd6cb38f5560d7/docker-compose.yml

[QuigonJohnn]

Perfect, thank you

[TrueOsiris]

@TrueOsiris have you had an opportunity to check this out yet?

Not yet to be honest. But as it holds stuff on kubernetes, I will, somewhere in time, have a look at this pull request.

[arcreigh]

Can we flesh out the docs a bit more on this to show the various allowed options for each config variable?

Would be nice for newcomers to be able to know what the available config options are for example GAME_SETTINGS_PRESET what are the other options?

This might be beyond the scope of this particular effort but it would be a nice additional good to have!

[arcreigh]

I also do not see the point of 2 specific bind mounts here /home/steam/vrising is the parent of both the folders we should be able to just have that as the single mount point.

[arcreigh]

Something of interest with how the PV/C is working with this container I usually use an NFS storage class for kubernetes workloads, and for some odd reason I can see the folders when looking at my NFS mount but they are empty.

When looking in the pod however all the data is there... not sure what is causing that.