Best practice to setup CI/CD deployment to GCE VM via Cloud Build and GH repo (non-containerized)?

I have a Shiny R codebase  residing in a GH Repo. The app is deployed on GCE VM (Debian OS) and is non-containerized and used by DEVs. At present DEVs manually SSH into the VM and deploy their changes. What is a good way to setup CI/CD via Cloud Build to deploy Shiny R app to GCE VM. This is one solution I had

  1. Setup a Cloud Build trigger that will have a gcloud command to stop and restart the VM
  2. During restart use the startup-script provision available with GCE VM to git clone the repo.  This will effectively replace the entire codebase not just the files changed by the developer. 

 

Solved Solved
3 2 127
1 ACCEPTED SOLUTION

Hi @dheerajpanyam 

Welcome to Google Cloud Community!

Here are some best practices for setting up CI/CD via Cloud Build to deploy a Shiny R app on a Google Cloud VM instance:

  • Use a version control system like Git to manage your code. This allows for tracking changes, collaboration, and easier rollbacks if needed.
  • Define your CI/CD pipeline using a cloudbuild.yaml file. This file specifies the build steps, triggers, and deployment actions.
  • Leverage pre-built container images for R environments like rocker/verse to ensure consistent build environments.
  • Use Cloud Build triggers to automate deployments. Triggers can be set to run on pushes to specific Git branches.
  • Consider containerizing your Shiny app using Docker. This promotes portability and simplifies deployment across different environments.
  • Instead of directly deploying to the VM, explore deploying your containerized app to a service like Cloud Run. Cloud Run offers serverless execution and scales automatically based on traffic.
  • If deploying directly to the VM is necessary, use SSH keys for secure and automated deployment from Cloud Build to the VM.

Remember, containerizing the app with Cloud Run is generally a recommended approach for scalability and manageability. However, the choice ultimately depends on your specific requirements.

Here are some resources that you might find helpful:

Google Cloud Build documentation
Deploying a Node.js server with Cloud Build and GCE
Best practices for CI/CD deployment to GCE VM (discussion)

I hope this information is helpful.

If you need further assistance, you can always file a case with our support team.

View solution in original post

2 REPLIES 2

Hi @dheerajpanyam 

Welcome to Google Cloud Community!

Here are some best practices for setting up CI/CD via Cloud Build to deploy a Shiny R app on a Google Cloud VM instance:

  • Use a version control system like Git to manage your code. This allows for tracking changes, collaboration, and easier rollbacks if needed.
  • Define your CI/CD pipeline using a cloudbuild.yaml file. This file specifies the build steps, triggers, and deployment actions.
  • Leverage pre-built container images for R environments like rocker/verse to ensure consistent build environments.
  • Use Cloud Build triggers to automate deployments. Triggers can be set to run on pushes to specific Git branches.
  • Consider containerizing your Shiny app using Docker. This promotes portability and simplifies deployment across different environments.
  • Instead of directly deploying to the VM, explore deploying your containerized app to a service like Cloud Run. Cloud Run offers serverless execution and scales automatically based on traffic.
  • If deploying directly to the VM is necessary, use SSH keys for secure and automated deployment from Cloud Build to the VM.

Remember, containerizing the app with Cloud Run is generally a recommended approach for scalability and manageability. However, the choice ultimately depends on your specific requirements.

Here are some resources that you might find helpful:

Google Cloud Build documentation
Deploying a Node.js server with Cloud Build and GCE
Best practices for CI/CD deployment to GCE VM (discussion)

I hope this information is helpful.

If you need further assistance, you can always file a case with our support team.

Thank you @LeAnt