Google Container Builder is more than a Docker factory

Earlier this week, Google unveiled yet another tool for its Google Cloud Platform. Google Cloud Container Builder, which Google developed to run its own cloud infrastructure, is described as “a stand-alone tool for building container images regardless of deployment environment.”

The tool automatically creates Docker container images from application source code stored in a Google Cloud Storage instance. The resulting images are then made available in Google Container Registry, where they can be deployed in every part of Google Cloud Platform where containers run.

But Container Builder is not only for building containers—it lets you use software in containers to drive the whole build pipeline.

Google claims a few advantages of using the Container Builder cloud architecture as a service for other items: 

1. Users doesn’t have to administer their own build environment.
2. The build process takes place closer to where the images will run.
3. Google can offer far better scale for the dollar than most anyone could build themselves.

Tools like these don’t get much traction if they aren’t attractive to developers, and cloud-based build tools can fall short if the build process is inflexible. Container Builder’s build process is described via a .YAML file; each step can refer to a “build step image”; a Docker image containing software that’s run at the step in question, such as Maven or Gradle; or Google’s own Bazel build tool. Google supplies a variety of official step images, but users can assemble and supply their own as needed.

Also in Container Builder’s favor: You’re not restricted to creating Dockerfiles from scratch; existing Dockerfiles can be uploaded to the service and built there. Likewise, you can use common repository types like GitHub or Bitbucket as code sources.

Container Builder provides 120 build-minutes per day free for customers; each minute after that costs 0.34 cents. The free tier comes with a asterisk warning that it’s “subject to change,” meaning it might vanish if Container Builder takes off. Also, there is no SLA for build times—in other words, there’s no guarantee from Google on how long any step will take, such as the check-in of the initial code. (Each project can also run only one build at a time.)

Containers have long been thought of as a common unit of distribution for an application. Even though it has “Container” in its name, it’s clear Google is thinking about Container Builder as a service for building not only containers, but also pluggable components in a pipeline. “There’s no requirement that your build produce a container as output,” Google states in its blog post.