Unix Socket Instead of TCP about shinyproxy

[dragoonis]

@dseynaev

[PlasmaPower]

#33 fixes this by making the default to communicate with docker through the socket.

[dragoonis]

Update: I am trying unix:///var/run/docker.sock but untested right now

[dragoonis]

@PlasmaPower

I'm using docker-compose, on a single host btw

if the spotify docker client supports UNIX_SCHEME then why do we still need an external bridge network?

[PlasmaPower]

Shinyproxy still needs to communicate with the underlying containers, not just the docker daemon. The bridge network is for the former.

[dragoonis]

@PlasmaPower

AFAIK shiny proxy needs to spin up its own containers, and it can do this with the docker daemon socket,

can you educate me on what "underlying containers" means?

[PlasmaPower]

Shinyproxy spins up the containers and then forwards requests to them. For instance, shinyproxy might spin up a container with the name boring_cori. Then, a request to localhost:8080/boring_cori/subpath would be forwarded to /subpath in the container. That requires a network connection.

[dragoonis]

@PlasmaPower if my shinyproxy and shiny are using docker-compose with their own default bridge network .. will all containers that shinyproxy spins up be in the same network? which network do you attach your boring_cori containers to ?

[PlasmaPower]

@dragoonis You'll have to manually set the docker-network option to the network that docker compose creates. For instance, if the docker-compose.yml is in a folder named example_app, the default network will be named example_app_default.

[dragoonis]

@PlasmaPower okay - i have tried the unix socket syntax but i was getting permission denied (500) on creating a container, so I modified the docker daemon and now my docker connection string is 172.x.x.x:PORT

The outstanding issue for us (OasisLMF team) is:

The shiny_proxy makes containers on the fly, but we don't know how to correlate the containers made on-the-fly with the containers in the docker-compose network, therefore when we do our teardowns it keeps alive the on-the-fly ones up and running

What can we tweak/do to easily detect which containers were made on the fly, so we can tear them them too?

• we are loading up in a docker-compose.yml file
• our docker-compose containers are: flamingo_server, flamingo_shiny and shiny_proxy
• our teardowns are: docker-compose down -v

[dragoonis]

@dseynaev

[fmichielssen]

Unix sockets can now be used either by specifying docker.host: unix:///var/run/docker.sock or by omitting the docker.host setting entirely.
This functionality was enabled by PR #33 as @PlasmaPower mentioned.

[romunov]

@fmichielssen just to be clear, this option could be used instead of url in application.xml?