Google Cloud Run with CI/CD via Terraform Cloud and GitHub Actions

Illustration of a person hanging different types of clocks and watches on a clothesline using clothespins. The image includes a round wall clock, a cuckoo clock, and a variety of wristwatches. The person is wearing an orange scarf and a gray shirt. Illustration of a person hanging different types of clocks and watches on a clothesline using clothespins. The image includes a round wall clock, a cuckoo clock, and a variety of wristwatches. The person is wearing an orange scarf and a gray shirt.

Today, we’ll explore a real example: deploying an application in Cloud Run on Google Cloud. We’ll also learn how to reduce costs and create a continuous integration and deployment (CI/CD) pipeline using GitHub Actions and Terraform Cloud.

The application we’re deploying is Claimora, a time tracker used to record employees’ working hours. It is built with Ruby on Rails and deployed on Cloud Run.

Initially, Claimora was designed to be deployed on AWS services like EKS Fargate or ECS Fargate. However, after some deliberation, the decision was made to migrate the entire infrastructure to Google Cloud Run.

What Is Google Cloud Run?

Google Cloud Run is a serverless compute platform that runs stateless containers invoked via HTTP requests. In this context, "stateless" means that the application does not retain any data or condition changes between requests. This includes memory contents, temporary storage, files, or other states. No storage is persistent, so if a container is terminated, the application must continue functioning seamlessly in a new container without relying on previous states.

Another key consideration for Cloud Run is avoiding background activities. Background threads or routines running outside the scope of HTTP requests are not supported. Since there’s no active process waiting for jobs in a serverless environment, there’s no initialization process. Processes are spawned based on HTTP requests.

Managing Background Jobs on Cloud Run with Ruby on Rails

To manage background jobs on Cloud Run with Ruby on Rails, you’ll need to use Google Cloud Tasks along with Cloud Stacker, a Ruby tool for handling background jobs via Google Cloud Tasks.

Key Components of Cloud Run Deployment

Let’s break down the main components of a Cloud Run deployment:

  1. Cloud Build: This is triggered every time code is pushed to the repository. It builds a container image and pushes it to the container registry.
  2. Cloud Run Service: This deploys a new revision of the container built by Cloud Build.

Infrastructure as Code with Terraform

We use Terraform Cloud to manage all infrastructure components, including:

  • Build triggers
  • IAM roles for service accounts
  • SQL instances
  • Cloud Tasks
  • Redis instances
  • Cloud Run services

Additionally, we map the application’s domain (e.g., claimora.com or stg.claimora.com) to the service. Google Cloud automatically handles SSL certificate generation for these domains, making the process seamless.

Continuous Deployment with Traffic Splitting

Every code push creates a new application version. Cloud Run supports gradual deployment by splitting traffic between container revisions. For instance, if you deploy a new version while working with revision 10, you can initially route 10% of traffic to the new version. Once tests pass, you can route the remaining traffic to the updated revision.

Cost Optimization with GitHub Actions

Building and deploying containers in Cloud Build incurs costs. To save money, we use the 2,000 free GitHub Actions minutes available monthly. Our pipeline:

  1. Builds the container image on GitHub servers (free of charge).
  2. Pushes the image to Google Cloud Registry.
  3. Deploys the image to the staging environment for testing.
  4. After testing, promotes the image to production and deploys it.

All these actions are defined in a .github/workflows file, which outlines each step in the CI/CD pipeline. By offloading builds to GitHub Actions, we avoid using Cloud Build for most tasks, significantly reducing costs. If additional minutes are needed, you can connect your own servers or purchase extra from GitHub.

Conclusion

Moving away from Google Cloud Build can yield significant cost savings, especially if you utilize the free minutes offered by GitHub Actions. This approach provides a fully functional CI/CD pipeline that optimizes both performance and budget.


Here's the same article in video form for your convenience: