Code: Select all
docker build . -t armagetronad
Code: Select all
docker run --rm -ti --network=host armagetronad
But it's running with a default configuration, and log files and other persistence data aren't kept around (they are if you remove the --rm, but they are a pain to get at and are not automatically reused in the next run).
The ideal way to both make the configuration editable and var data persistent would be via a bind mount of, for example, the home directory of the user that's configured to run the server:
Code: Select all
docker run --rm -ti --network=host type=bind,source=/some/directory,target=/home/armagetronad armagetronad
If I configure the docker image to run the server as root, it all works in podman/rootless docker. But then I'm running as root in the regular rootful docker configuration, which is hardly ideal.
I looked a bit into user remapping, but that would work so well with multiple users on the system. If I read it correctly.
What does work in all situations is to not use bind mappings, but volumes. Docker knows how to properly make them accessible inside the container. But volumes are an abstraction, and it's quite hard (for me) to view and edit their content.
Am I maybe thinking completely wrong here? Should I just use volumes (named, for persistence across runs) and instead of trying to get to them from the outside, whenever I want to change or inspect something, ENTER the container with 'docker exec' and use the contained tools to inspect/edit stuff? Or, if I get annoyed by only having vi available (I'm sure it's great! I'm... just always glad I remember how to exit it.), copy stuff in and out with 'docker cp'?
Or a mixture? Use the volume for variable data and the resource cache, bind mound a read only configuration directory? Yeah, I think I'll see whether that makes me happy.