Do you think IIT Guwahati certified course can help you in your career?
No
Introduction
Cloud Build is a service used by Google to execute your builds on Google Cloud. It can import source code from various repositories or cloud storage spaces, execute a build to your specifications, and produce artifacts such as Java archives or Docker containers.
This article explains how to use Cloud Build to build a Docker image and push the image to a Container Registry.
Build configuration file schema
A build config file carries instructions for Cloud Build to perform tasks based on your specifications. E.g., your build config file can contain instructions to build, package, and push Docker images. Let us now understand the schema of the Cloud Build configuration file.
Structure of a build config file
The Cloud Build API's Build resource is used to model build configuration files. The build configuration file can be written in either JSON or YAML style. Use the JSON syntax when submitting build requests via third-party http tools like curl.
Build steps
An action that you want Cloud Build to take is specified in a build step. Cloud Build runs a docker container as an instance of docker run for each build step. Build steps allow you to carry out any instructions in your build and are comparable to commands in a script.
timeout
We use the timeout field for a build to specify the time the build must be allowed to run. If this period has passed, the build will be considered complete, and the build status will be changed to TIMEOUT. The build will have a default timeout of 10 minutes if the timeout is not provided. Twenty-four hours is the maximum value that can be set to timeout.
queueTtl
To specify the time a build can be queued, use the queueTtl field. A build expires and the build status is changed to EXPIRED if it is in the queue for an amount of time greater than the value specified in queueTtl. Cloud Build utilizes the value "3600s" as the default if no value is specified (1 hour). The queueTtl generally starts ticking from createTime.
logsBucket
For a build, define a Cloud Storage bucket where logs must be written by setting the logsBucket field. Cloud Build will use a default bucket to store your build logs if this field is left blank.
substitutions
We can use substitutions in our build config file to substitute specific variables at build time. Substitutions are helpful for variables whose value is unknown until build time or to re-use an existing build request with any other variable values. By default, the build returns an error if there is a missing substitution or a substitution variable. However, you can use the ALLOW_LOOSE option to omit this check.
availableSecrets
We can use this field to use a secret from Secret Manager with Cloud Build.
Secrets
It is used to pair a set of secret environment variables with encrypted values with the Cloud KMS key to decrypt the value.
serviceAccount
We can use this field to specify the IAM service account at build time.
images
One or more Linux Docker images are specified in the build configuration file's images field and sent to the Container Registry by Cloud Build. Even though a build may execute tasks without creating any Linux Docker images, if images are created and not sent to the registry, they are deleted after the build is finished.
artifacts
The artifacts field in the build config file helps specify one or more non-container artifacts to be stored in Cloud Storage.
Cloud builders
Cloud builders are container images with standard tools and languages and tools installed in them. You can configure Cloud Build to run a specific command within the context of these builders.
Publicly available images
Cloud Build allows you to use any publicly available image to execute your tasks. To use an image, specify the image URL in the name field in your config file. Use the args field to specify commands you want to run within the image. The args field of a build step takes a list of arguments and passes them to the image referenced by the name field.
Supported builder images provided by Cloud Build
Cloud Build maintains pre-built images you can reference in your config file to execute your tasks. The given table lists some examples of supported builder images:
Community-contributed builders
You can use the open-source builders offered by the Cloud Build developer community to complete your tasks. These builders don't support pre-built images. To use these builders, get the source code from the cloud builders community's GitHub repository, then create the image from scratch.
Some examples of community-contributed builders are included in the following table:
Cloud Build triggers
Cloud Build uses build triggers to enable CI/CD automation. You can configure triggers to listen for incoming events, such as when a new commit is pushed to a repository or when a pull request is initiated, and then automatically execute a build when new events come in. You can also configure triggers to build code on any changes to your source repository or only on changes that match specific criteria.
Cloud Build notifiers
Docker images used as containers on Cloud Run are known as Cloud Build notifiers. Cloud Build notifiers employ push subscriptions to send notifications to a defined service, such Slack or an SMTP server, when polled by a subscriber application.
The table below illustrates how Cloud Build works together with other Google Cloud products, such Cloud Run and Pub/Sub, to transmit notifications:
Supported notifiers provided by Cloud Build
The following table lists available notifiers:
Supported notifiers provided by Cloud Build
The following table lists available notifiers:
IAM roles and permissions
Identity and Access Management controls access in Cloud Build (IAM). You can set and manage permissions for Google Cloud resources using IAM. Cloud Build offers a specific set of preconfigured IAM roles, each containing a set of rights. These roles allow you to grant more precise access to particular Google Cloud resources while blocking unauthorized access to other resources. By granting only the essential access to your resources, IAM enables you to adhere to the security principle of least privilege.
Predefined Cloud Build roles
The diagram below lists the Cloud Build IAM roles and the permissions that they include:
Permissions
The following table lists the permissions that the caller must have to call each method:
Cloud Build service account
Cloud Build uses a particular service account to execute builds on your behalf. The email for the Cloud Build service account is [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com. By default, Cloud Build service account has permissions for performing several tasks such as fetching code from your project's Cloud Source Repositories or writing objects to any Cloud Storage bucket owned by your project.
Default permissions of Cloud Build serviceaccount
The following table lists the permissions that the Cloud Build service account role contains and the purpose for which the Cloud Build service account uses these permissions.
Private pools overview
Private pools are dedicated pools of workers that give greater customization over the built environment and can access resources in a private network. Private pools are hosted and fully managed by Cloud Build and scale up and down to zero, with no infrastructure to upgrade, set up, or scale. Since private pools are customer-specific resources; you can configure them in many ways.
The given tables compare the features of the default pool with a private pool:
Network architecture
A private pool is a user-created, fully-managed resource in a Google Cloud project. Private pools can be handled using infrastructure provisioning tools like Terraform, the Google Cloud CLI, the API, and the Google Cloud console.
The flow of builds to the exclusive pool is depicted in the diagram below. The customer delivers builds from two projects to Cloud Build in this configuration. The customer has set up their private pool to receive all builds from these projects. Buildings have access to private resources in the customer's VPC network via the service producer network, where the private pool is located.
Frequently Asked Questions
What is a container?
Containers are the abstraction at the app layer that contains dependencies and code together.
What do you understand by Docker?
Docker is an open-source containerization platform. It packages your application and all its dependencies together in containers to ensure that your application works seamlessly during development, test, or production.
What is Cloud Logging?
Cloud Logging is service that enables you to store, search, analyze, monitor, and alert on logging data and events from Google Cloud and Amazon Web Services.
What is GCP?
GCP is a provider of public clouds. Customers can use GCP and other cloud suppliers to utilize computer resources located in Google's data centers worldwide for free or on a pay-per-use basis.
What services does GCP provide?
GCP provides a full range of computing services, including tools for managing GCP costs, managing data, delivering web content and online video, and using AI and machine learning.
Conclusion
I hope this article provided you with insights into the usage of Cloud Build in GCP. It also gives brief introduction of structure, notifiers, builders and triggers of the Cloud Build functions.
We hope this blog has helped you increase your knowledge regarding AWS Step functions, and if you liked this blog, check other links. Do upvote our blog to help other ninjas grow. Happy Coding!"