Why proxy's protocol and host is read from hostURL instead of application.yml about shinyproxy

[shrektan]

Forgive my ignorance, trying to connect https://192.168.99.101:20000 or http://worker1:20000 makes no sense to me. Is the problem rooted on my docker configuration or something else?

Thanks for your help in advance.

[fmichielssen]

Hi @shrektan ,

Can you clarify your setup further? Are you running shinyproxy on windows and the docker inside virtualbox? Or both inside virtualbox? Which OS is running in virtualbox?

Can you also confirm that the shiny app that fails to launch, works correctly when launched separately (via docker run) ?

Note: have you considered using Docker for Windows? It uses hyper-v instead of virtualbox, and runs nicely on my Windows machine.

[shrektan]

@fmichielssen Thanks for your help. Docker for Windows is currently not available in my case, because it requires win10 or win server 2016.

My setup is the docker running inside virtualbox (the docker-machine) while the shinyproxy running on windows 7.

I can confirm that the shiny app works correctly, as I mentioned above, immediately after I click the app link, I can even reach the running container in my browser, using http:// with the same address displayed in shinyproxy log ( in contrast the log says shinyproxy use https://).

It's weird for me that shinyproxy is trying to connect the container through https:// (or connect http://worker1:20000 if the container deployed with swarm) , based on my a little docker user experience... However, I'm very likely to be wrong.

Do you have any ideas of what's going wrong? Thanks again.

[fmichielssen]

Hi @shrektan ,

Thank you for clarifying. You are right that the use of https:// is not appropriate in this scenario.
It was implemented under the assumption that SSL happened entirely either before or after shinyproxy. But in this scenario, it is mixed: there is SSL on daemon traffic, but not on container traffic.

In the docs (https://www.shinyproxy.io/security) we propose a setup where an nginx reverse proxy is placed before shinyproxy and offloads all SSL.
In this case:

• Shinyproxy would use plain http to contact the docker daemon as well as the docker containers.
• For security, the docker host should only be exposed to shinyproxy.
• Clients would connect to shinyproxy via https.

For the second item, I believe virtualbox's "host-only" networking mode can be used, though I am not sure. I'm afraid I am not very familiar with virtualbox networking configuration.

Regards,
Frederick

[shrektan]

@fmichielssen Well, thanks for your explanation. I'll try to find a solution to contact the docker daemon using plain http, when using docker-machine. Hopefully, it exists.

However, I still have questions.

It was implemented under the assumption that SSL happened entirely either before or after shinyproxy.

First, about the statement above, I doubt the assumption is realistic...

Secondly, it is not consistent with the protocol http when using swarm. As I mentioned before, it contacts http://worker1:20000 in my case. Also, I double the rationality of contacts http://worker1... Are you sure it is not a bug?

shinyproxy/src/main/java/eu/openanalytics/services/DockerService.java

Line 304 in 24df356

proxy.protocol = "http";

Thanks again.

[fmichielssen]

Hi @shrektan ,

Indeed it is not consistent with the swarm mode, and we'll consider it as a bug. I think having the protocol as an optional setting (defaulting to the protocol used in the url setting) will improve usefullness in both swarm mode and single-machine mode.

Regarding the swarm support in shinyproxy, this is still quite new and lacks some flexibility and documentation. In particular, it requires that shinyproxy can resolve all the nodes in the swarm (worker1 being one in your example), so that the proxy can be set up appropriately.

In the future, we'd like to get rid of this requirement via ingress load balancing, but this appears to be unstable at the moment: moby/moby#25325
(I encountered issues when testing this myself)

[shrektan]

Hi @fmichielssen ,

I will vote for having the protocol as an optional setting 👍 .

Again, I appreciate your kind help and will rebuild shinyproxy with the protocol changing to http as a temporary solution.

[tverbeke]

protocol as an optional setting will be included in the next release

[shrektan]

@tverbeke thanks.

[tverbeke]

@shrektan

Release 1.0.0 has a new optional setting shiny.proxy.docker.container-protocol to configure the container protocol; if not set, it will be taken from the docker host url as specified in shiny.proxy.docker.url.

Does this work for your use case?

[shrektan]

@tverbeke I guess it will solve my issue but I can only verify it tomorrow. Anyway, I will close this issue for now. Thanks for your help. 🍺

[shrektan]

@tverbeke I confirm that the new version works. Thanks.