What i did / Steps to reproduce

1. Exec into Docker container
2. Attempt to edit a config file

Expected result

In a Kubernetes environment, SSH-ing into a server and editing files from a mounted volume isn't something that's encouraged or, in some cases, even a possibility. Because of this, I have to run a 2nd container that has text editors installed so that I am able to accept the EULA, for example. It would be great to have vi or something commonly accepted available in the container to make editing the configs more accessible

Actual result

No text editors are installed

Context

BlueMap Version:
ghcr.io/bluemap-minecraft/bluemap:v5.2

Kubernetes 1.31

You can get the entire default config locally by running docker run --rm -it -v "$(pwd)/config:/config" ghcr.io/bluemap-minecraft/bluemap:latest -c /config and then modify those and generate a ConfigMap from that directory. You anyway wouldn't need to do this often as most of the time BlueMap just adds some new config options you could add manually based on the changelog if you really wanted to but wouldn't be required to. And for those big changes such as v1 -> v3 or v3 -> v5 you would want to do a full reinstall anyway.

For config file locations it's best to follow platform standards (./config or ./plugins)
Meanwhile the CLI and Docker container do allow you to specify the config file location with the -c flag.

I don't know where you have gotten the idea that it is normal to exec into containers to edit config files. What you should do instead is to use ConfigMaps
If you really want to do this like this, nothing is stopping you from installing a text editor in the container when you need to edit files. But I don't think it's in our benefit to have such preinstalled.

You’re exactly right and I agree, ConfigMaps would be the most ideal option. What I found when originally taking this approach is that BlueMap templates out the default configuration file, so there’s no easy way to patch these without taking the time to generate them by standing up a 2nd pod with the newer version, then manually copying down the freshly generated files to my local machine so I can update the ConfigMap definitions.

My mindset going into execing in is that Minecraft itself is not very friendly to ConfigMaps due to the directory structure, and neither are most plugins. If I had hundreds of players I might consider taking the time to build out the initContainers to parse and patch all the config files, but quite frankly, it’s not worth the trouble until there’s a much easier option. I had the initContainers for Bluemap config patches on both my Minecraft and Bluemap deployments, but it felt silly to have a relatively complicated process in place while a dozen other plugins still needed manual management (ref).

I suppose the ask here could be could be resolved by making this process easier, by providing more accessible default configuration files, or by defining a process that makes the above ref less convoluted. For example, being able to customize the location of config files for both the mod and the plugin would likely remove the need for initContainers