Good question. For updating apps it is not needed to restart ShinyProxy: if you update Docker images, Docker will run the latest ones. When updating app configurations or adding apps, it is currently required indeed to restart ShinyProxy.
If the behaviour you are after is supported by Spring Boot, we can support it for ShinyProxy too.
With the current behaviour, note that an admin user can see the live usage of ShinyProxy in the admin view, so you can know you are not bothering users (or which users exactly you are potentially bothering) when doing a restart.
I have configured automated pipelines to build containers from user git repositories and then publish the resulting containers using ShinyProxy. When a user creates a new repository (dashboard), or changes metadata (eg. title/description), the CI/CD process builds the container and it gets pushed to the container registry and automatically updates the application.yml with the dashboard metadata. Unfortunately, the pipeline then needs to restart the shinyproxy service for the new dashboard/metadata to be made available.
Initially this wasn’t really an issue, but as more developers start pushing dashboards, the restarts of the shinyproxy service for newly created dashboards/metadata changes is impacting the end users/consumers more regularly.
With the ongoing restarts i’ve unfortunately had to move promotion of new dashboards to production out of the pipeline and schedule restarts after hours.
If there was a SIGHUP equivalent that re-reads configuration, it would be perfect.
I notice there was some more recent discussion on github here:
With regard to reloading the configuration, would it be possible to split the configuration information out of application.yml, so that there is a configuration file that only includes dashboard information, and then have the service re-reads this file on load of the landing page?
ie. config.yml <-- loaded when application starts, and includes application configuration application.yml <-- loaded dynamically when users hit the landing page and contains dashboard configuration
Thanks to everyone working on this, it’s a great product we get lots of value from.
I was expecting this to be possible given the website description, but now I understand “update” refers to updating current applications.
If you have multiple ShinyProxy containers and want to put a new configuration online, you can perform a ‘rolling update’ without causing any downtime for your users.
We could copy the application.yml, change the port, create/update the shinyproxy image (as the Dockerfile copies the yml), create a new service publishing the new port (e.g. 8081:8080), and update a reverse proxy? Still there’s downtime as at some point the old service must be shut down.