January 20, 2023
Roger Martinez
Developer Relations Engineer
Patricia Shin
Cloud Developer Relations Engineer
Build, push and deploy your serverless application to Cloud Run automatically.
You’ve got a shiny new application ready to deploy to the cloud. After researching your options, you land on using Cloud Run with Cloud Build to build and push your containerized application code to an Artifact Registry repository. In three steps, using a Dockerfile and a Cloud Build configuration you build your container, push it to Artifact Registry, and deploy it to Cloud Run:
steps:
# Build the container image
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app', '.']
# Push the container image to Artifact Registry
- name: 'gcr.io/cloud-builders/docker'
args: ['push', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app']
# Deploy container image to Cloud Run
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: gcloud
args: ['run', 'deploy', 'my-serverless-app', '--image', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app', '--region', 'us-central1']
images:
- us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app
The example above combines the build, push and deployment steps into one Cloud Build job. This blog will show you what this could look like as a series of manual deployment steps, and how it can be developed into an automatic serverless deployment pipeline that can be used as a jumping off point for more complex solutions. We’ll be using Cloud Build, Artifact Registry, Pub/Sub and Cloud Run.
We'll use the open source GitHub project, Emblem, to model a working reference of Google Cloud serverless architecture. References to Emblem will be marked with the 
emoji.
A manual pipeline
Let’s start by examining the manual steps to deploy a containerized application to Cloud Run.
-
First, you make application code changes to your repository's main branch.
-
When an application change is merged, you use Cloud Build to build a new container.
-
After a successful build, Cloud Build pushes the newly built container to Artifact Registry.
-
You update Cloud Run with a new configuration pointing to the new build.
-
Cloud Run deploys a new revision of your service. Your code changes are now deployed.
Of course, you would need to go through these steps each time there are changes to your application code. That’s not practical and can turn into a logistical nightmare for a team making continuous updates to the code. Not to mention the added complexity of staging changes to multiple environments or incorporating systematic testing or incremental rollouts. Let’s see how you can automate your lovely little pipeline by looking at it as two parts: the build and the deployment.
Automate the build
To automate the build step of your pipeline, Cloud Build should build and push when a change is committed to the application code in your repository. Here’s what’s needed to make this happen:
1. Connect your GitHub repository to your Cloud project
By connecting your GitHub repository to your project, Cloud Build can use repository events to initiate a Cloud Build trigger. Common repository events are supported including pushing to a specific branch, pushing a new tag, and creating a pull request.
2. Include a Cloud Build yaml configuration in your repository
You can configure a Cloud Build job with a build config file. This YAML file provides task-level instructions to Cloud Build. This file can live alongside your application’s Dockerfile, or in a separate directory in your repository. For an automatic build, your config file will tell Cloud Build to build the container image and push it to Artifact Registry.
The Emblem project continuously builds multiple containers and keeps corresponding build config files in a centralized ops/ directory. This allows for the separation of ownership of the Cloud Build configs and the application code they may build.
