Shiny in Docker: to Shiny-Server or not to Shiny-Server, that is the question
81 views
Skip to first unread message
Murat Tasan
Jun 2, 2021, 10:30:14 PM6/2/21
to Shiny - Web Framework for R
I've gone back-and-forth on this a lot in the last few years, and I'm very curious to hear what others have to say about this decision: when deploying a single Shiny application via Docker, what are the pros/cons to:
* using Shiny Server within that container
* making the entrypoint R/Shiny itself
* either of the above with a process manager running in that container
I'm really tempted to move back to the R/Shiny direct entrypoint approach (for simplicity), but I also don't want to shoot myself in the foot by overlooking any known caveats.
What approach do folks here favor, and why?
Erik Westlund
Jun 2, 2021, 11:29:40 PM6/2/21
to Murat Tasan, Shiny - Web Framework for R
In my experience the big benefit with Docker comes from
1) making your app easier to share for others to use, if that's something you need
2) feeling confidence that your development environment will easily translate to production.
In the case of (1), you may not need others to run your app on their own hardware, or you may be forbidden from that. On the other hand, if you're on a team, Docker helps a lot here.
In the case of (2), this kind of depends on your dependencies and use case. Most apps probably will translate just fine across environments, but there may be some pain points in getting everything set up.
So, as usual, the answer is: It Depends.
I think it's worth pointing out that Docker has downsides:
For example, they're starting to do weird things to become profitable. For example, it's now a paid feature to sk an update (https://www.reddit.com/r/programming/comments/n2za7x/skipping_an_update_on_docker_is_a_paid_feature/). Using Docker puts another dependency in your stack.
Likewise, Docker doesn't always perform well for everyone. M1 Macs still have experimental support, and Docker for mac is often kind of janky as it is.
While Docker performs pretty well, it does add complexity to deployment sometimes. For example, you may need to setup appropriate proxying and play with ports to make sure everything coexists. Depends what you are doing.
It's often hard to "dockerize" everything. You probably, e.g., do not want to Dockerize a database in production.
Docker is a dependency, and like all dependencies, it takes care to keep things in order.
In my personal case, I went through a phase of dockerize everything.
I've given up on most of it because I ended up having more pain from Docker than benefit. Turns out everything was easier and more performant to just set up things natively for me, and to the extent I got "bit" by this, I was getting "bit" far less than I was from dealing with Docker pain.
These days, I still use Docker. Sometimes it's a great way to just get going with something.
But I don't think it's a no brainer. I also feel like I see a lot less Docker evangelism these days as people realized it's not an unmixed blessing. On the other hand, maybe it just became old tech so no one cared to write about it.
Erik
1) making your app easier to share for others to use, if that's something you need
2) feeling confidence that your development environment will easily translate to production.
In the case of (1), you may not need others to run your app on their own hardware, or you may be forbidden from that. On the other hand, if you're on a team, Docker helps a lot here.
In the case of (2), this kind of depends on your dependencies and use case. Most apps probably will translate just fine across environments, but there may be some pain points in getting everything set up.
So, as usual, the answer is: It Depends.
I think it's worth pointing out that Docker has downsides:
For example, they're starting to do weird things to become profitable. For example, it's now a paid feature to sk an update (https://www.reddit.com/r/programming/comments/n2za7x/skipping_an_update_on_docker_is_a_paid_feature/). Using Docker puts another dependency in your stack.
Likewise, Docker doesn't always perform well for everyone. M1 Macs still have experimental support, and Docker for mac is often kind of janky as it is.
While Docker performs pretty well, it does add complexity to deployment sometimes. For example, you may need to setup appropriate proxying and play with ports to make sure everything coexists. Depends what you are doing.
It's often hard to "dockerize" everything. You probably, e.g., do not want to Dockerize a database in production.
Docker is a dependency, and like all dependencies, it takes care to keep things in order.
In my personal case, I went through a phase of dockerize everything.
I've given up on most of it because I ended up having more pain from Docker than benefit. Turns out everything was easier and more performant to just set up things natively for me, and to the extent I got "bit" by this, I was getting "bit" far less than I was from dealing with Docker pain.
These days, I still use Docker. Sometimes it's a great way to just get going with something.
But I don't think it's a no brainer. I also feel like I see a lot less Docker evangelism these days as people realized it's not an unmixed blessing. On the other hand, maybe it just became old tech so no one cared to write about it.
Erik
--
You received this message because you are subscribed to the Google Groups "Shiny - Web Framework for R" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shiny-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/bba1b2d7-d1ba-45a4-ae79-b441b01ca89fn%40googlegroups.com.
Murat Tasan
Jun 3, 2021, 6:44:58 PM6/3/21
to Shiny - Web Framework for R
Ah, yeah, I'm already committed to deploying Shiny apps via Docker.
I'm specifically wondering about using Shiny Server vs Shiny plain vs some-other-combination-of-process-managers _within_ the Docker container.
So far the best argument for Shiny Server is its handling of older browsers that don't support WebSockets (i.e. it serves as a shim), but I'm not super-concerned about that anymore (as I think for my users I can require they use a halfway-modern browser).
But I'm also sure I'm missing other good arguments for each of the choices!
Joe Cheng
Jun 3, 2021, 6:48:36 PM6/3/21
to Murat Tasan, Shiny - Web Framework for R
Shiny Server also has logic for dealing with unreliable networks; a certain number of dropped packets will break a WebSocket connection, but Shiny Server will (in theory) seamlessly reconnect if the connection is restored within 15 seconds. This seems to be particularly helpful when using VPNs across different continents, if all of your users are on high-quality connections it may never be an issue.
To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/a09c30c7-d264-4716-bb9f-642c6256d731n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages