I'm setting up an environment which could contain multiple docker container. Each container contains the same SpringBoot Application. During the runtime of the SpringBoot application an .ini-file is needed to work through different things. Furthermore the .ini-file might be updated from outside the containers. This update or new .ini-file should be distributed among all other containers so that it is available at the other SpringBoot apps at the end. Distributing the file is not the problem at this point but how to store the file because the classpath can't be used.
I'm using hazelcast to use its cluster feature. With the help of it I'm able to distribute the new file over all other members in the cluster. At the beginning I stored the .ini-file within the classpath. But if the .ini-file changes it makes no sense to have it in the classpath because you cannot write within a jar. Also, if the container goes down, the memory of the hazelcast is lost because it only has a in-memory database.
What I expect is a process where I can easily substitute the .ini-file. For example a container already knows the file (all newer versions of the .ini-file will have the same name) during build or something like that. If the container was down, it is able to find the file by itself again. And, as I already mentioned, I need to change the .ini-file during runtime. Then the container, or to be more specific, the SpringBoot app has to recognize this change automatically. In my opinion a changing of the file could be done via a REST call which stores the file anywhere within the container or a place where it is allowed to write because classpath doesn't work.
As your question is holding a tag "kubernetes", I will try to answer you in context of this specific container orchestrator.
The feature you are looking for is called ConfigMap in Kubernetes.
Think of it as a key-value pairs created from data source (in your case ini config file).
kubectl create configmap game-config --from-file=.ini-file
You can then use ConfigMap data in two ways inside your containers:
Important thing to note here is, that mounted ConfigMaps are updated automatically. If you are interested in this concept please read more about it here.