fpiesche / docker-hercules Goto Github PK

This'll need some experimentation to figure out what data the different server executables actually need to function. Once I've figured that out, I'll want to create a build and then separate it out into three separate images.

Bonus: this means I can experiment with running e.g. multiple replicas of the login or character servers! I'm assuming the map server cannot be replicated and is what keeps the server-side game state...

The functionality for setting the interserver username and password works as far as configuring the Hercules servers goes, BUT the database initialisation creates only the default ones so setting any other ones actually causes the servers to fail to run as their login fails.

I'm trying to get this running on my Synology NAS from the docker registry and once I launch it the container stops.
Checking the logs I get this;

hercules_game_servers_1

If I run the compose I get two containers. The DB is running fine but the game server still cuts off with the same log as above.

Any help would be appreciated and thank you!

If I reduce the number of platforms to build they work just fine, but running all platforms - even with single-build concurrency on BuildKit - will cause builds to fail as they run out of memory.

What the heck?

The convention for Docker images is that configuration can be passed in via environment variables. On my old repo for this, I bundled in Autolycus - however this comes with a huge set of dependencies, and I would like to separate it from the Hercules server images to run in a separate container.

This means that the Docker image for Hercules will need a new entrypoint script, ideally something nice and slim such as a bare shell script to keep image size small, that can parse configuration from environment variables and push it into the configuration files.

As implied by issue title, the current version of hercules-build/Makefile attempts to assemble a Dockerfile using stages that no longer exist in the repo, probably due to a refactor.

#13 has demonstrated a need to be able to identify when the images have been rebuilt. Adding some versioning to the image tags might be useful...