1. El nuevo repositorio en DockerHub

Aprvechando esta situación armé un nuevo repo que contiene también el tidyverse. La decisión de cargarlo en esta etapa, si bien es discutible, la tomé porque normalmente en cualquier aplicación de Shiny que armo trabajo con el tidyverse y, si tuviese que instalarlo al momento de crear la imagen de la aplicación, tardaría una eternidad.

Ya he escrito anteriormente sobre el proceso que me llevó a armar mi primer repositorio en DockerHub, así que están invitados a leerlo.

Por lo pronto, la imagen la van a poder encontrar aquí: r-shiny.

2. Dockerizando Shiny

La aplicación que voy a subir es la que armé para una presentación de la libraría rRofex.

No es el objetivo de este posteo explicar en que consite, pero si quieren replicarla localmente pueden hacerlo rápidamente con el siguiente Gist dentro de RStudio:

shiny::runGist(gist = "https://gist.github.com/augustohassel/4eea614f80a8bbc548b2b4c3c5edd7c3")

El Dockerfile que permite correr localmente la aplicación lo van a encontrar en GiHub, junto con el resto de los archivos de este posteo: GitHub Demo-ShinyDockerRun

FROM augustohassel/r-shiny

# Cargo librerias
RUN R --slave -e "install.packages('remotes')"
RUN R --slave -e "remotes::install_github('rstudio/httpuv')"

# Llevo la aplicacion
RUN mkdir -p /srv/shiny-server
RUN rm -rf /srv/shiny-server/*
COPY app /srv/shiny-server/app

# Modifico la configuracion
COPY shiny-server.conf /etc/shiny-server/shiny-server.conf

# Creo el ejecutable
COPY shiny-server.sh /usr/bin/shiny-server.sh
RUN chmod +x /usr/bin/shiny-server.sh

RUN sudo usermod -a -G staff shiny

RUN mkdir -p /home/shiny/paquetes
COPY paquetes.R /home/shiny/paquetes/

RUN Rscript /home/shiny/paquetes/paquetes.R

EXPOSE 8080

CMD ["/usr/bin/shiny-server.sh"]

3. A la nube!

Ahora que tenemos todo funcionando localmente, es el momento de probarlo en la nube y para esto vamos a usar Cloud Run que es una solución “serverless” de Google.

No voy a entrar en detalles en el paso a paso, porque tengo pendiente otro posteo al respecto, pero si voy a mostrar el resultado final y el código.

Primero tenemos que crear un disparador con Cloud Build y asociarlo con nuestro repositorio de GitHub.

Para que todo funcione, el repositorio tiene que contener los siguientes archivos (además de la aplicación propiamente dicha):

• Dockerfile: secuencia para construir la imagen que se usará en el contenedor propiamente dicho.
• cloudbuild.yaml: contiene loa pasos que va a usar Cloud Build para deployar la aplicación.
• shiny-server.conf: configuración del server de shiny
• shiny-server.sh: ejecutable que arrancará la aplicación de shiny.

Ahora, cada vez que actualicemos nuestro repositorio en GitHub, se van a ejecutar las tareas que se encuentren en el archivo cloudbuild.yaml.

Para subir la aplicación a Cloud Run, tenemos dos formas: la primera es manualmente en Cloud Run y la segunda proporcionando el archivo cloudbuild.yaml que contendrá todas los pasos para que se ejecute por sí solo!

# cloudbuild.yaml

steps:
    # build the container image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-f',  'Dockerfile','-t', 'gcr.io/augusto-hassel/demo-shiny', '.']
    # push the container image to Container Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/augusto-hassel/demo-shiny']
    # Deploy container image to Cloud Run
  - name: 'gcr.io/cloud-builders/gcloud'
    args:
      [
        'run',
        'deploy',
        'demo-shiny',
        '--image',
        'gcr.io/augusto-hassel/demo-shiny',
        '--region',
        'us-central1',
        '--platform',
        'managed',
        '--quiet',
        '--allow-unauthenticated'
      ]
images:
  - gcr.io/augusto-hassel/demo-shiny

timeout: 14400s

Si llegaron hasta acá, entonces la aplicación probablemente les ha funcio…… no……

4. Lis… Alerta! Calzada resbaladiza…

Cloud Run no soporta Websocket y lastimosamente mi aplicación lo necesita para funcionar…

Si bien Shiny Server posee otros protocolos que logran ‘bypasear’ este impedimiento, en mi caso particular, la aplición lo usa para obtener información de otra API.

Si no fuese por este detalle, se podría haber resuelto según sugieren en el issue cargado al repo oficial de Shiny en GitHub

# cloudbuild.yaml

steps:
    # build the container image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-f',  'Dockerfile','-t', 'gcr.io/augusto-hassel/demo-shiny', '.']
    # push the container image to Container Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/augusto-hassel/demo-shiny']
    # Deploy container image to Cloud Run
  - name: 'gcr.io/cloud-builders/gcloud'
    args:
      [
        'run',
        'deploy',
        'demo-shiny',
        '--image',
        'gcr.io/augusto-hassel/demo-shiny',
        '--cluster',
        'my-first-cluster-1',
        '--cluster-location',
        'us-central1-c',
        '--platform',
        'gke'
      ]
images:
  - gcr.io/augusto-hassel/demo-shiny

timeout: 14400s