App Containers Always End Up on Bridge Network, Not on Same Network as ShinyProxy

ShinyProxy
1

Hi all,

I’m trying to get a very simple ShinyProxy setup working for testing purposes, but I keep running into a strange networking issue and would really appreciate some advice.

My Setup:

  • I’m using ShinyProxy (openanalytics/shinyproxy:2.6.1) via Docker Compose on Linux.
  • My app is just a dummy/test R Shiny app (shinyproxy-apps) – nothing special, just the classic slider + text output to prove the concept.
  • I mount the Docker socket into the ShinyProxy container, as recommended.
  • I followed all the usual guides and docs.

Problem:

  • When I start ShinyProxy, it creates its own default network.
  • But when I open an app via the ShinyProxy web UI (after logging in), the spawned Shiny app container always ends up on the default bridge network instead of the network that ShinyProxy is running on.
  • This means ShinyProxy cannot reach the app container by hostname, and I always get the “container did not respond in time” error.

I tried following:

  • Using the latest versions of Docker, Docker Compose, and ShinyProxy
  • Downgrading Docker and ShinyProxy to older versions (still the same result)
  • Setting internal-networking: true/false in application.yml
  • Explicitly defining a custom Docker network and assigning both ShinyProxy and the apps to it in both docker-compose.yml and application.yml
  • Removing all custom network config and letting everything use the default bridge network
  • Cleaning up all old containers, images, and networks, rebooting, trying again
  • Playing with the network parameter and all other Docker/Compose options
  • Different combinations of ShinyProxy and app image versions

No matter what I try, the app containers are always attached only to the default bridge network, not the network that ShinyProxy uses.

Is this a known issue with recent Docker, Compose, or ShinyProxy versions? What is the correct way to ensure that app containers always end up on the same network as the ShinyProxy container so hostname routing works? Is there something basic I might be missing, or a new best practice for recent releases?

docker-compose.yml:

version: "3"
services:
  shinyproxy:
    image: openanalytics/shinyproxy:2.6.1
    container_name: shinyproxy-net
    user: root
    ports:
      - 8080:8080
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /home/xxxx/r-shiny/application.yml:/opt/shinyproxy/application.yml
    restart: unless-stopped

application.yml:

proxy:
  title: OpenAnalytics Shiny Proxy
  port: 8080
  authentication: simple
  users:
    - name: test1
      password: test
      groups: [admins]
  docker:
    internal-networking: true
  specs:
    - id: helloworld
      display-name: Hello World App
      container-image: shinyproxy-apps-reveal
      container-cmd: ["R", "-e", "shiny::runApp('/helloworld', host='0.0.0.0', port=3838)"]
      container-port: 3838
  container-wait-time: 60000

Dockerfile:

FROM rocker/shiny:4.2.0

COPY helloworld /helloworld
COPY histogram /histogram

# Instaliraj pakete ako treba:
RUN R -e "install.packages(c('shiny'))"
EXPOSE 3838

Thanks!
Regards,
Nikola

2

Hi

First of all ShinyProxy 2.6.1 is already three years olds, I recommend to use the latest version of ShinyProxy (3.2.0).

The pods created by ShinyProxy are not automatically added to the network in which ShinyProxy is running. You’ll have to tell ShinyProxy in which network to create the applications.

In ShinyProxy 3.2.0 you can do this using the proxy.docker.default-container-network setting. When using docker compose, docker automatically creates a network. You can find the correct network name using docker network ls.

You can have a look at this example: shinyproxy-config-examples/02-containerized-docker-engine at master · openanalytics/shinyproxy-config-examples · GitHub . It’s not using Docker compose, but will be very similar, except for the name of the network.