Skip to main content
  1. Posts/

Cloud Run Websocket support now allows you to deploy a R Shiny Server as a serverless app to GCP Cloud Run

··966 words·5 mins
Author
Hairizuan Noorazman
Software engineering experiments, implementation notes, and lessons learned.

Sometime earlier this year (2021), Google Cloud Run started to support websocket support - which is one of the critical components in order to be able to run a R Shiny Dashboard application.

Refer to the the following documentation on the Google Cloud Run website:
https://cloud.google.com/run/docs/release-notes
https://cloud.google.com/run/docs/triggering/websockets

Let’s see how to quickly get a R Shiny Server application running on Google Cloud Run. But before we get one to run on the Google Cloud Run service, let’s try to get one running on our local computer.

If you head over to the following website, we can just quickly run a simple docker image that already has shiny installed in it and test it out on our local computer.

docker run --rm -p 3838:3838 rocker/shiny:4.0.0

If we head over to the local url: http://localhost:3838/sample-apps/hello/. The website displayed should be one that is interactive; it shouldn’t be completely grayed out. If grayed out, that would mean that the websocket connection has already expired or broke etc. Unfortunately, seeing that this situation deals with own local computer, it would be something that you have debug manually on your own if any issue arises.

There are other sample functionality available in this image. You can check them out before configuring further:

  • http://localhost:3838/01_hello/
  • http://localhost:3838/02_text/
  • http://localhost:3838/03_reactivity/

You can find and understand more by going into the following folder in the container: /srv/shiny-server

Pushing the rocker/shiny image to Google Container Registry/Artifact Registry
#

The first step before before we can deploy such a service to Google Cloud Run is to get the image into the project’s container/artifact registry we wish to deploy in.

Ensure that our docker cli tool can authenticate to our Google Cloud Project
https://cloud.google.com/container-registry/docs/advanced-authentication#gcloud-helper

gcloud auth login
gcloud auth configure-docker

With that, we can then push the image to the respective project’s container/artifact registry. If we are to push to the container registry (Please substitute the project id accordingly):

# Re-tag the public rocker/shiny docker image to point to gcr.io/<project-id> registry
docker tag rocker/shiny:4.0.0 gcr.io/<project-id>/rocker/shiny:4.0.0

# Push image
docker push gcr.io/<project-id>/rocker/shiny:4.0.0

Although its also possible to push the images to artifact registry and use the images in said registry to deploy the services on Google Cloud Run, we would not cover it here. On initial look, it looks way to pricey as compared to just relying on Google Container Registry instead.

Create the Cloud Run Service
#

To deploy the service, we can use the UI simply and deploy it or we can utilize the following gcloud command

gcloud run deploy shiny-dashboard --concurrency=1 --memory=2Gi --platform=managed --region=asia-northeast1 --allow-unauthenticated --port 3838 --image=gcr.io/<project-id>/rocker/shiny:4.0.0

We can then test that this works as expected and that this whole setup works as expected for this. Do note that this setup has no authentication which may mean issues if you only mean to restrict this R shiny dashboard to only internal company access.

Expose dashboards for selected users
#

If all we wanted to do was just to deploy the dashboard in Google Cloud Run, then we can just stop with the actions mentioned above. However, in many cases, we usually deal with “private” datasets that should only be accessed in internal company settings; it should not be exposed to public.

Do take note that R Shiny library doesn’t have anything that deals with authentication. (I’m talking more of the open source edition). I’m pretty sure that if you were to look into the enterprise level Shiny framework, you might be able to find some sort of authentication mechanism.

So in order to do protect our data/dashboards, it would be good to put some sort of proxy in front of the dashboards. We can do that via nginx but the authentication options available that are available out of the box might be a little limited. In cases where we would want to authenticate using Google accounts etc, that option may not be readily via nginx mechanism. We might need some external mechanism to string together with nginx which we can then use it to proxy it on. If we’re ok with password based authentication, doing it via nginx might be quite easy, although it would still involve setting nginx in some virtual machine etc.

We can instead look into another mechanism that Google Cloud already provide: IAP (short for Identity Access Proxy). Refer to the following documentation for details on this capability: https://cloud.google.com/iap/docs/concepts-overview

IAP is not directly integrated with Google Cloud Run, but it is already integrated with Google Cloud Load Balancer. And we can have Google Cloud Load Balancer serve traffic with Google Cloud Run as its backend. Refer to the following documentation for details on this capability: https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless

With that we can have IAP for our Shiny dashboard via Google Load Balancer by doing the following:

  • Deploy the Google Cloud Run and ensure that it requires no authentication but it is only exposed to private network as well as the load balancer
  • Configure a Google Cloud Load Balancer (GCLB) with backends
    • Might require creating serverless network endpoints to point to our aleady setup Google Cloud Run service
    • Ensure that you have a domain to not deal with creating the SSL certificates manually. Alternatively, you can create Self Signed SSL certs but you would need to be kind of familiar with all the commands here. Out of convenience, it would be better to just purchase a domain and toss it to Google to manage the SSL cert etc
    • It takes about 10-15 minutes to wait for a good response from load balancer - it takes a long while to provision it
  • At this point, test to make sure that the Shiny Dashboard can be accessed from a browser via the domain pointed to it.
  • Add your Google user that you would want to access the Shiny dashboard with the IAP-secured Web App User role. Reference: https://cloud.google.com/iap/docs/app-engine-quickstart

Related

App with Metrics, Logs and Distributed Traces

·1118 words·6 mins
In a previous post, it details some information of how to setup some open source tooling to capture logs, retrieve metrics as well as capture distributed trace information from apps. The previous blog post would cover the setup of logging system which is Loki, distributed tracing system which is Tempo and metrics collection system which is Prometheus. Refer to the link below here.

Setting up Observability Tooling in GKE

··2418 words·12 mins
Generally, most cloud providers come along with all the observability tooling that you need for your apps built-in with the platform. Some of the common observability tools such as logging, monitoring and nowadays, distributed tracing are usually made available and you can easily use said tools by reading up on the various documentation of how to setup each of these tooling. E.g. if your application is inside a virtual machine and if you need collect metrics and logs from the application, you may need to install an agent in the said VM. The agent would collect those information and send it to the centralized observability tooling in the cloud provider where the information would be provided to you via a UI. Most of the time, these tools are charged based on the amount of logs/metrics you generate from the application (so the less logs/metrics you generate, the cheaper it is monitor your application - a very understanable/reasonable situation). In cases where if your application runs in Kubernetes, maybe the cluster comes with agents pre-installed, making it easier to make use of the logging/metrics/distributed tracing that the cloud provider has.

Using Envoy for GRPC Applications in Kubernetes

··1555 words·8 mins
As of now, one of the common and easier way to have services communicate with each other would be over HTTP. In real world use cases, HTTPS is usually used (in order to ensure communications are secure) and this communication is done following some sort of REST framework. This provides some sort of structure of how to standardize such communications for the various software applications out there. It got to the point where entire companies are developing in order to support this: e.g. Apigee, SmartBear