How we use Google Container Builder
If you’ve been experimenting with CI/CD pipeline tools like Travis, Codeship and Jenkins then you might want to give Google Container Builder (GCB) a spin.
GCB is a hosted solution to package your software using the Google Cloud Platform (GCP) infrastructure. The tool was initially used internally by Google and was released to the public in March 2017.
At Kudos, we use it as part of our CI/CD process to download dependencies required for the projects, run tests, lint the project and then package and deploy it on Google Kubernetes Engine (GKE).
Out of the box GCB comes with great features such as supporting builds direct from a Dockerfile, custom build steps orchestrated by a yaml file, the ability to run steps in parallel with no limit and currently a promotional tier of 120 minutes build time for free per day. There is also the option to use higher spec machines, both 8 CPU and 32 CPU, with per build minute pricing. So if your builds are so slow that they let you meditate on the meaning of life it might be time to crank up the 32 core and parallelise everything. On top of that the documentation is clear and there is a very good and very responsive community on Slack.
It takes a few attempts to discover that GCB is a very generic tool which can adapt or improve your process, from automating your workflow, to using it as part of your toolchain. The quickest way to get started is to connect a repository with a Dockerfile to a GCB trigger. The generated container can be pushed to any store such as Docker or Google Container Registry and be used as a Docker image in your team.
Where it becomes interesting is that you can use Docker functionality such as multi stage builds to generate small images by separating the build process from the packaging. For example the first step can test and build whereas the second step can be about packaging your application. See the docs for more information.
When running everything in a Dockerfile becomes impossible, like packaging sensitive information, deploying or A/B testing, GCB has a build process managed by yaml file, allowing it to run extra tasks such as managing secrets or connecting to 3rd party services or deploying your application.
A few steps are pre-built such as using wget, kubectl, go or git. A build step is essentially a Docker container running commands which can be run in series or parallel. See here for more detail.
If builds are failing then quicker iteration can be done by installing a local builder on your machine.
To conclude we’ve had a great experience with GCB and it has become one of our go to tools. We use it to build and deploy our services and we’ve even managed to integrate it to GitHub (to allow PRs to be merged). The biggest success we’ve had so far was to halve the build time for our biggest application. Recommended!
If you want to explore GCB further:
— Example using Docker and custom steps
— GCP Slack (say hello to us if you join)
— Kelsey Hightower guide to create a deployment
If you like what you read and think you could contribute to our team at Kudos then take a look at our careers page to see what roles we currently have open.
