Book Image

Cloud Native Automation with Google Cloud Build

By : Anthony Bushong, Kent Hua
Book Image

Cloud Native Automation with Google Cloud Build

By: Anthony Bushong, Kent Hua

Overview of this book

When adopting cloud infrastructure, you are often looking to modernize the automation of workflows such as continuous integration and software delivery. Minimizing operational overhead via fully managed solutions such as Cloud Build can be tough. Moreover, learning Cloud Build’s API and build schema, scalability, security, and integrating Cloud Build with other external systems can be challenging. This book helps you to overcome these challenges by cementing a Google Cloud Build foundation. The book starts with an introduction to Google Cloud Build and explains how it brings value via automation. You will then configure the architecture and environment in which builds run while learning how to execute these builds. Next, you will focus on writing and configuring fully featured builds and executing them securely. You will also review Cloud Build's functionality with practical applications and set up a secure delivery pipeline for GKE. Moving ahead, you will learn how to manage safe roll outs of cloud infrastructure with Terraform. Later, you will build a workflow from local source to production in Cloud Run. Finally, you will integrate Cloud Build with external systems while leveraging Cloud Deploy to manage roll outs. By the end of this book, you’ll be able to automate workflows securely by leveraging the principles of Google Cloud Build.
Table of Contents (18 chapters)
1
Part 1: The Fundamentals
5
Part 2: Deconstructing a Build
9
Part 3: Practical Applications
14
Part 4: Looking Forward

Configuring build-wide specifications

Finally, there are sets of configurations that you might use to configure global settings that apply across all build steps. We have already discussed some of them prior to this chapter:

  • timeout
  • env
  • secretEnv

The preceding fields behave the same as their counterparts defined at the individual build step level; the core difference is that defining them globally now makes them available to all build steps in the build.

However, there is an additional global field that you must specify when you are using secretEnv, regardless of whether it is at the individual build step level or the global level:

  • availableSecrets

It is in this field where you declare the availableSecrets you would like to use at some point in your build, as well as where you are pulling them from. It is recommended that you utilize Secrets Manager to store sensitive credentials that you will be using in your builds; we will review this, in...