Build a container image with Cloud Build

Share on:

Introduction

If you want to build a container image there are lots of options available. Docker, Buildpacks and Cloud Build provides a very convienient way to manage builds. In this blog post, we will use Cloud Build to create an image based on a configuration.

Google Cloud Project

Definitely check out Free Tier to try Google Cloud products. Cloud Build is included in the free tier. To use Cloud Build ensure:

  • The Cloud Build API (i.e. cloudbuild.googleapis.com) is enabled

Cloud Build 101

Cloud Build is a serverless automation tool available on Google Cloud. Its purpose is to remove the toil associated with building software. To do this, Cloud Build uses containers to define custom workflows for build, test and deploy stages. In addition it works seamlessly with the Google Cloud products and also plays nicely with source control solutions such as GitHub.

Cloud Build Configurations

Google provides a number of customised images for Cloud Build. However the true advantage of Cloud Build is the massive list of commuinity images built for development for example Maven, Bazel, Ansible, and Packer. Take a look at the example links to get an idea of the types of applications supported by Cloud Build.

Link Description
GoogleCloudPlatform/cloud-builder Builder images and examples commonly used for Google Cloud Build
GoogleCloudPlatform/cloud-builders-community Community contributed images for Google Cloud Build

Docker Manifest

To demonstrate how to build an image, we will use the Community Builders version of Hugo.

  1. Create the file Dockerfile
1FROM busybox
2ENV HUGO_VERSION=0.80.0
3RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz | tar zx
4
5FROM gcr.io/distroless/cc
6ENTRYPOINT ["/hugo"]
7COPY --from=0 /hugo /

Docker Manual Build

In this example the image should be tagged with the Google registry hostnames. The name of the image includes where the image will be stored. Ensure it is named correctly for your Google Cloud project.

NOTE: In the following steps replace PROJECT_ID with your Google Cloud Project Id. If you are doing this in Cloud Shell, you can use the environment variable $GOOGLE_CLOUD_PROJECT to replace the [PROJECT ID].

  1. Build an image and tag it for use with Container Registry
1docker build -t gcr.io/[PROJECT_ID]/hugo .
  1. Push the image to Container Registry
1docker push gcr.io/[PROJECT_ID]/hugo

Cloud Build Automation

In the previous build steps for Docker we do a lot of manual work. By using Cloud Build to build containers, we can hand off the creation of our image. Lets replicate the Docker build and push using Cloud Build:

  1. Create the file cloudbuild.yaml
1steps:
2- name: 'gcr.io/cloud-builders/docker'
3 args: [ 'build', '-t', 'gcr.io/PROJECT_ID/hugo:0.1', '.' ]

NOTE: The build arguments are exactly the same as using Docker at the command line. Cloud Build is actually running Docker as a container (i.e. gcr.io/cloud-builders/docker) to complete the task. At this point hopefully you are thinking about all the applications that run in containers that can use this type of automation!

  1. Run the build
1gcloud builds submit --config cloudbuild.yaml

The build process uploads the config to Google Cloud Storage and initiates a build process. From there a Cloud Build will process the cloudbuild.yaml instructions resulting in a hugo image. Unfortunately if you dont tell Cloud Build to keep the artefact built, it will assume it temporal. Lets correct that by updating the configuration file.

  1. Edit the file cloudbuild.yaml
1steps:
2- name: 'gcr.io/cloud-builders/docker'
3  args: [ 'build', '-t', 'gcr.io/PROJECT_ID/hugo:0.2', '.' ]
4- name: 'gcr.io/cloud-builders/docker'
5  args: [ 'push, 'gcr.io/PROJECT_ID/hugo:0.2' ]
  1. Run the build
1gcloud builds submit --config cloudbuild.yaml

Running the above script will now build the Docker image and push it to Container Registry. If you examine Cloud Build, you will see there are two steps which align with the cloudbuild.yaml configuration. Should you choose to add more steps, these would be presented in the Cloud Build interface.

As an added bonus, the intermediate steps can share information between the build stages. The workspace folder is accessible between stages and enables the developer to access information at each stage of the build lifecycle.

The above is a very basic use case for Cloud Build. Once you are comfortable using Cloud Build, take a look at Cloud Build Triggers. Triggers allow integration work to be automated and can be synchronised with source version control to initiate build cycles seamlessly.