Building the Clouds

Google Cloud has a lot of impressive things to discover – one of the interesting and least known aspects is its integrated build system, Cloud Build. Let’s set it up for hosting a GIt-repository, for building a microservice and for storing the generated artifacts in a Docker registry inside Google Cloud.
First of all, there are some prerequisites to fulfill before using Google Cloud Build:

– Google Cloud account with payment functionality enabled needs to be present

– A Project has to be created inside Google Cloud – our sample project is called cloud-report-project

– The Google Cloud SDK is to be installed on your local machine

If all of these steps are taken, we should have a Microservice we want to build. In this article, we use a Spring Boot based Microservice written in Java (you can find the source code at [1]), but you can of course use a language of your liking – Google Cloud Build actually does not care about a programming language, it refers to builders being supported on the platform.

How does Google Cloud Build work?

Before building anything, we should understand the basic idea behind Google Cloud Build, since it is different to the approaches AWS or Azure have. Essentially, Google Cloud Build does exactly, what the name supposes: It imports sources, builds them, creates container images, stores and – if requested to – deploys them inside of Google’s own cloud environment.

At the center of it, there is the Google Cloud Build configuration file, a YAML-file being expected to be present inside the project. Builds are reflected as steps in that YAML-file, each step is represented by a builder being sup- ported by the platform or the community.

Already existing builders are tools such as Maven, Gradle, NPM, Bazel, Gulp or wget, that are able to be executed as some sort of command inside the environment. A list of builders supported by the platform is available at [2], but there are way more builders provided by the community – and you can even create and submit your very own builder. Each build step is executed inside a container. These containers run inside a local Docker network called cloudbuild. This allows for communication between the different builders and build steps being referenced in the build process.

Generated artifacts of a build step can be containerized and stored in a container registry, such as Docker Hub or (preferably) a private container registry inside the Google Cloud environment.

The build process can be triggered manually using the gcloud builds-command on your local machine or by utilizing hooks in GIT-repositories.

Generally, the lifecycle of a Cloud Build build is like this:

– We create our application

– A Cloud Build config-file is added to our application

– The build is submitted to the Cloud Build service

– The build process is executed inside Cloud Build

– Generated container images are pushed to a container registry

Google Cloud Build preparations

Before building any software project, we need to activate Google Cloud Build and create a GIT-repository for hosting the sources.

Hosting a GIT-repo

First, point your browser to and log in there with your account. Then use the Hamburger menu and select Cloud Source Repositories or head over to Create a new GIT-repository here by pressing the Add repository-button, name it cloud-report-source. This just takes some seconds.

Figure 1: Output of a Cloud Build operation

Enable Cloud Build

Next, Cloud Build needs to be enabled. Head over to and click on the Enable Cloud Build API-button.

The software project

Obviously, in a software project, some build- and configuration files need to be present. Usually, these are located in the root folder of the project.

In our example (a Java-based Spring Boot Microservice), we have three configuration files (pom.xml, Docker- file and cloudbuild.yaml) being present for building, containerization and Google Cloud Build execution.

The Maven build configuration

As we are building a Spring Boot based Microservice with Java, we need to provide a Maven POM-file for building the Microservice. This is a standard POM-file, so there is no need to look into it here.

The Dockerfile

Then, we need to provide a Docker configuration file, since the generated artifact from the Maven build step needs to be dockerized to run in a cloud-native environment. Let’s have a look at it:

# Start with a base image containing Java run
FROM openjdk:13-jdk-alpine
# Add Maintainer Info
LABEL maintainer=“karsten.samaschke@cloudical.
# Add a volume pointing to /tmp
# Make port 80 available to the world outside
this container
# The application’s jar file
ARG JAR_FILE=target/CGPMicroservice-0.0.1-SNAP-
# Add the application’s jar to the container
ADD ${JAR_FILE} service.jar
# Run the jar file
ENTRYPOINT [“java”,”


This Dockerfile is very straightforward: As base-image is the current version of the openjdk-Docker-image based on Alpine Linux referenced. The container exposes port

80. The generated JAR-file containing the Microservice is copied and renamed to service.jar. Finally, the command line entry-point for starting the Microservice inside this container is defined.

Figure 2: Build history in the Cloud Build console

Figure 3: Generated image in the Container Registry


The Google Cloud Build configuration

Now, let’s have a look at the Google Cloud Build configuration file cloudbuild.yaml. As stated above, each build (and deployment) step is noted down here. Additionally, the name of the image to be created from the build steps are depicted as well:

– name: ‘’
args: [‘install’]
– name: ‘’
args: [‘build’, ‘–$PROJECT_ID/
cloud-report-sample:latest’, ‘.’]
images: [


When executing this file, the sources are built using Maven. The generated artifact is dockerized using the Dockerfile provided within the project. The generated docker image is made available in the local container registry associated with the project having the tag latest.

Note: The name cloud-report-sample references the internal name of the project. It can be selected to your liking, but it should be a simple and unique name within your Google Cloud project.

Execute the build

Now, that we have all components in place, we can execute the build process. Open your command-line, switch into the directory of your sources and execute the following command (including the trailing dot):

gcloud builds submit –config cloudbuild.yaml.

Once you submitted this command, Google Cloud SDK will create an archive of your project, upload it to the Cloud Build infrastructure and execute all defined build steps there. While doing this, you are informed about the process as depicted in Figure 1.

In the Cloud Build-console at, you can now see the result of all build processes as depicted in Figure 2.

Head over to the Container Registry using the Ham- burger menu to the right (or via and notice the generated Docker container as depicted in Figure 3.

Let’s automate it!

Now, there is only very few steps left for creating an auto- mated build process. Remember the GIT-repository created earlier? Just commit and push your code there and then head over to the Triggers section of Cloud Build configuration page in the Google Cloud Console at https://console.

Here we can create a new build trigger. Click on the button Create Trigger to start. Now select Cloud Source Repository (or any of the other available options, if applicable) and click Continue. Select the repository you created earlier on and click on Continue. Now define the trigger itself – name a specific branch (or leave it with the default option pointing to all branches, but I highly recommend pointing it to specific branch only) and select the option Cloud Build configuration file in the Build configuration section. Finally, click on Create Trigger, and you are all set!

Finally, change something in your sources, commit and push them – and then head over to the Cloud Build console and see the magic happen (Figure 4).

Figure 4: The current build is triggered automatically


Google Cloud Build is a very interesting and easy to use approach to build and build-automation. It does not re- quire any local builds anymore, since every build step is executed in a cloud environment. We as developers gain a lot of power with very few effort – as of now, there is no such easy to set up and use mechanism available on other cloud platforms.

And we did not even speak about publishing everything to Kubernetes, which we will cover in the next issue…


– [1] Source code of the sample project – https://github. com/cloudical-io/google-cloud-build-sample

– [2] List of supported builders – com/cloud-build/docs/cloud-builders




Karsten Samaschke/CEO Cloudical Deutschland GmbH