shinyproxy-operator icon indicating copy to clipboard operation
shinyproxy-operator copied to clipboard

"Refreshing" shinyproxy and its application pods

Open mth003 opened this issue 6 months ago • 1 comments

We are running ShinyProxy in unauthenticated mode with container-sharing and pre-initialization enabled.

We’re looking for best practices or recommendations on two related issues:

  1. Refreshing application pods on container image updates

Currently, when users push updated container images, we don't have a clean way to ensure running application pods are refreshed to pick up the new image. As a workaround, we’ve implemented a cronjob that toggles a configuration value (e.g., seats-per-container from 15 to 14 and back) every 5 minutes. This change triggers the operator to recreate the pods.

We realize this is a hacky solution. Is there a recommended or more graceful way to programmatically refresh application pods when images are updated?

  1. Refreshing shinyproxy-operator and redis pods

While the workaround above refreshes application pods, it does not affect the shinyproxy-operator or redis pods. These continue running indefinitely unless we manually do a full redeploy.

Over time, we’ve observed that stale redis or operator pods can lead to failed refreshes or missed updates. This ultimately breaks even our current workaround. At that point, a full redeploy of ShinyProxy becomes necessary.

Is there a good practice to:

Automatically refresh redis and/or operator pods after a certain age (e.g., every X days)? Detect and handle when the operator/redis become "stale" or stop functioning correctly?

Any insights or guidance would be appreciated!

mth003 avatar Apr 16 '25 14:04 mth003