Can't change settings after initial configuration
lsglick opened this issue · 2 comments
Hi there. We're having some challenges using this image since once the data volumes are created and configured, there is no way to modify the configs with future updates.
Say, for example, we want to add a new forward server, app, etc. I could update the ENV variables to accomplish this when first starting a container. But if the data volumes already exist, I have to either completely delete them or log into the container and run commands manually.
It might be nice to have an ENV variable to run splunk commands even if the server is already configured? Or perhaps a flag to re-run configuration regardless of what it finds in the volume (assuming that Splunk properly handles the case of identical commands being re-run)?
Thanks!
@lsglick this is by design.
Intention is pretty simple, when this is a fresh instance - we can safely call these commands, if not - there are can be a lot of undefined situations. Let's say that we will implement a flag "RERUN_ALL_COMMANDS" - what will happen when you server will be restarted and restart policy for this container is set to always restart? These commands will be invoked again and again.
My original Intention for these environment variables was to have them for stateless forwarders, for which you don't really have to keep var
and etc
folders, you can safely start them clean with using these environment variables.
If you want to modify splunk configuration after upgrade there are two recommended ways of doing it
Call splunk binary
docker exec -it container_name entrypoint.sh splunk status
Or open bash in container and invoke several commands
docker exec -it container_name entrypoint.sh splunk-bash
(big thank to @bshuler for https://github.com/outcoldman/docker-splunk/pull/19)
Thanks for the explanation! We've been using your suggested way, I was just hoping for a more seamless way.
I'll probably fork and add a local set of ENV variables for commands to always run regardless of if configured. You're right our instance isn't stateless since the scripted_input keeps track of its progress uploading data.
Specifically I want to execute something like: install app /tmp/my_app.tar -update 1 -auth admin:changeme
so it shouldn't hurt anything to run it extra, but will ensure if I update my_app, the latest version is installed on the volumes.