Allow custom ports and environment

[jaredlander]

Passing Environment Variables to shinyproxy

This allows users to pass environment variables through shinyproxy-operator (via docker compose) to the shinyproxy container as requested in #66.

When setting the variable set it with a SHINYPROXY_ENV_ prefix. For example setting SHINYPROXY_ENV_TEST_VAR: test_value will result in the shinyproxy-operator container have an environment variable named SHINYPROXY_ENV_TEST_VAR with a value of test_value AND the shinyproxy container will have an environment variable named TEST_VAR with a value of test_value.

Setting Custom Ports

This allows users to specify ports for caddy using SPO_CADDY_PORT_HTTP and SPO_CADDY_PORT_HTTPS as requested in #65. This will change the external ports for caddy but everything internally will still be on the standard 80/443 ports.

Automatic Image Building

Added a GitHub Action to automatically build the operator image and push to a registry as set in the repo secretes.

[jaredlander]

Hi @LEDfan I know I added a bunch of stuff to this PR, including scaffolding like devbox and CI/CD. Is there anything I can chop away to make this easier for you to merge?

[LEDfan]

Hi @jaredlander first of all thank you for creating this PR and your patience.

I understand the need for passing environment variables, but I see a few problems with your current approach:

• when hosting multiple shinyproxy servers (using one operator instance), all environment variables are passed to all ShinyProxy servers. This reduces the isolation between the multiple servers and might make it difficult to pass similar environment variables (but with different values) to different servers.
• everyone that can inspect the running containers, can see all the environment variables (maybe also if you are able to see the running processes on a system). This risk is of course also present when passing environment variables when using ShinyProxy without the operator.
• updating the environment variables requires updating the docker-compose.yml file of the operator, restarting the operator and then triggering a change of the ShinyProxy instance, such that the operator re-creates the instance.

We recently needed this feature for a customer and took a different approach (which is similar to Docker secrets):

• adding an configuration option called additionalConfigFiles, which is a list of (absolute) paths to additional config files.

• these files will be copied to the ShinyProxy config directory and automatically imported using spring.config.import

• similarly to the main configuration file, the operator watches for changes in these files and will deploy a new ShinyProxy instance if the file changes

• these files can contain any configuration (which can be merged with the main configuration). However, you can also use it to define simple key-value pairs, e.g.:

  MY_SECRET=my-value

Similar to environment variables, you can use these in the main configuration file using ${MY_SECRET}.

With this approach we solve the main reason to use environment variables, i.e. moving "secrets" outside your main file (which is typically stored in Git). However, I think this approach is a little bit more secure, and much more user friendly (because of the automatic reload).

I just pushed this code to the develop branch of this repo.

---

Regarding your other changes:

• scaffolding like devbox and CI/CD: for us it would be good to remove these. We use devbox for other projects as well, but currently not for ShinyProxy. We also have internal CI/CD pipelines for building and testing (the tests also run on GHA). Similarly the docs are hosted on our website now ( https://shinyproxy.io/documentation/shinyproxy-operator/kubernetes/ ), so we'll add any new feature there before release.
• Made it possible to specify the name of the redis and caddy images.: I'm fine with the idea, I still need to look a bit at the code
• Changed the hard coding of SPRING_CONFIG_IMPORT to SPRING_CONFIG_IMPORT_0 so that we can add additional config imports and spring.config.import is no longer a forbidden configuration. I think this is solved by the additionalConfigFiles option in our implementation
• Enabling the user to specify the network name for containers spawned by shinyproxy-orchestrator: also fine for me.
• Custom ports: this would be very useful indeed!

So I'm happy to accept these smaller changes, and hope the additionalConfigFiles solves the issue with passing secrets.