A Critique of Google Container Builder
At Google Cloud Next, Google announced that Google Container Builder is now generally available in beta.
Very simply put, container builder is a CI service that runs pipelines of build steps. Each step is run inside a Docker container.
I have a lot of experience with developing locally in Docker containers. I’ve even taken a stab at building a tool to help me do so, called Godo. We at Deis have also been running containerized CI jobs for a long time inside Travis CI (example: https://travis-ci.org/deis/builder). I have a lot of experience with running docker-based CI jobs.
After learning all about Google Container Builder, I decided to give it a shot for one of my personal projects. Below are my thoughts on the product.
Pipelines are Great #
Many CI systems (Jenkins, Wercker, Travis, Circle) let you define your jobs as a pipeline, and it’s a great abstraction.
Container builder lets you write them in a pretty simple, linear yaml format. Until you get into concurrent pipeline steps. They expose concurrency by requiring you to list a pipeline step’s dependencies. So, if you end up with a lot of concurrent steps, beware – you’re going to end up doing a graph traversal in your head to figure out what steps come before yours. That’s not fun, and very error prone.
It’s Containers All the Way Down #
There’s no magic to pipeline steps, and that’s a very good thing. Each step is a docker run with some extra arguments, and they all share a common directory. Google even provides a few pre-made images for you to use, but you can just as easily use your own too.
Being container-based, you can build a docker image with all the tools you need and run your pipeline step with that image. No more relying on tools to be pre-installed and configured just right by the CI system.
Note that you can use containers for everything in other CI services just like you do here, but those services don’t feel like they were designed to be “container-native” (buzzword alert!).
Container builder feels like it was designed to run containers in pipeline steps.
Where’s the Documentation? #
The documentation has good “getting started” and tutorial-style pieces, but given that this is a pretty simple abstraction, you get a good basic understanding of the system pretty quickly. After that, the “advanced” docs or a reference guide is missing.
For example, there’s no documentation on best practices for designing an image to be run in a custom build step. I had to study the code in the Google-provided ones to learn some for myself.
Maybe there are more docs hidden somewhere or on the way.
No Local Environment #
I spent about an hour debugging a pipeline step. First, I had some environment variables wrong, then I was looking in the wrong directory. Then, I noticed that the waitFor keyword wasn’t working.
Each time I fixed something, I had to git push the changes to test them out. gcloud container builds submit would have been really convenient to test my changes before I pushed them, but it has to create a tarball of everything and upload it to the server. For large projects like the one with which I was testing, this process can take a long time, which can be frustrating when I want to test a one-line change to my configuration file.
I hope that, before this service comes out of beta, they release a tool that runs my pipeline locally so I can quickly check if my changes work. Obviously this wouldn’t replicate exactly what the service would do, but it would be far better than what the service offers now.
Note that Google already has local development environments for at least App Engine and Google Cloud Datastore.
Edit: I was recently informed that the service now provides a local environment. I haven’t tested it out though.
Build Notifications #
As far as I can tell, container builder won’t notify anyone if the build fails. If it does, the documentation doesn’t clearly show how to set these notifications up.
That means: no build badges, emails, Slack notifications, GitHub status hooks or anything else. Even for private projects, I consider at least status hooks crucial.
The lack of build notifications is a serious deficiency of container builder.
Conclusion #
A good, modern CI system needs to have a few key features:
- Easy to set up your builds
- Easy path toward more complex builds
- Fast builds
- Deep integration into source control
- Deep integration into artifact delivery
Container builder has nailed it on everything but #1 and #4. It can be an onerous task to get even something simple working (in my case, this was installing Go dependencies with glide). And, the fact that you can’t easily set up build status notifications is a big oversight.
I think that container builder is backed by great technology, as is the case with most Google products, but it lacks the developer experience needed to make it a critical part of any CI/CD pipeline.
If I’m misinformed or missed anything about container builder, ping me on Twitter and set the record straight!