Deploy Shiny apps on Shiny server using Gitlab CI / CD

Hello,

Currently, I have an EC2 Ubuntu machine (AWS) on which I installed my own Rstudio and Shiny servers.

Each time I have a modification to make on one of my applications, I go through my Rstudio-server to be able to access the script of the application in the /srv/shiny-server/app_name/app.R folder.

Is there a possibility for me to deploy my modifications on my applications from Gitlab (gitlab-ci.yml, gitlab-runner, CI / CD).

This will allow me to have versioning and to be able to make my tests locally before pushing them in Gitlab which will avoid me to connect each time to my Rstudio-server ?

Thanks

1 Like

Hi there,

I am also very interested in this topic as I am currently working on exactly that.

I can run my shiny app locally via docker, but as soon as I deploy my app using the Gitlab CI/CD pipeline (where the deployment also passes) the app greys out once I connect via the configured URL and the browser console throws an error, as I got a Websocket connection problem.

I have tried configuring nginx within the Dockerfile (following this guide: Shiny Server Deployment).

But that did not work in my case, so right now I am kind of stuck.

I believe it is possible to deploy shiny apps via the CI/CD pipeline, but it is quite complex to set up.

I am gonna update, once I found out more.

Hi @edoclaf ,

I finaly find out like this

image: docker:latest

deploy_server:
  stage: deploy
  variables:
    app_name: "app name"
  when: on_success

  before_script:  
## checks if ssh-agent is already installed and if not, then install it
  - 'command -v ssh-agent >/dev/null || ( apk add --update openssh )'
## starts ssh-agent
  - eval $(ssh-agent -s)
## adds SSH private key stored in variable ID_RSA to agent store
  - echo "$ID_RSA" | tr -d '\r' | ssh-add -
## creates .ssh directory and assign correct permissions
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh

## checks public key on remotes server using IP address stored in DEPLOY_IP variable and add it to known hosts. It is protecting from men-in-the-middle attack and is necessary to work, otherwise the job will fail.
  - ssh-keyscan $DEPLOY_IP >> ~/.ssh/known_hosts
## assign correct permissions
  - chmod 644 ~/.ssh/known_hosts
#### We disable host checking (we don’t ask for user accept when we first connect to a server, and since every job equals a first connect, we need this).
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
#
### Artefact
  artifacts:
    paths:
      - $CI_PROJECT_DIR/
## script is where our actual code to execute is defined. We simply want to connect to the remote host, create the new app directory if doesn't exist yet and copy the app or update the apps. 
  script:
    - ssh $DEPLOY_USER@$DEPLOY_IP "[[ -d $SHINY_SERVER/$app_name ]] && echo 'Directory Exists' || mkdir $SHINY_SERVER/$app_name"
    - scp -r -p22 $CI_PROJECT_DIR/App/. $DEPLOY_USER@$DEPLOY_IP:$SHINY_SERVER/$app_name/
  #  - scp -r -p22 $CI_PROJECT_DIR/app_name/. $DEPLOY_USER@$DEPLOY_IP:$SHINY_SERVER/$app_name/

Of course it's not very professional at the moment (I'm pretty new to the gitlab pipeline) but I'll push my research so that it's more complete when making merges requests and more robust like any .gitlab-ci.yml.

I welcome recommendations from professionals to help me improve

1 Like

This topic was automatically closed 54 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.