Hacker News new | past | comments | ask | show | jobs | submit login

Disclaimer: I work at Google but I do not work on the product, so this is my personal experience.

I recently tried out Cloud Container Builder before it went public. I host a lot of small personal Docker projects on my private GitHub repositories and build Docker images for them using CircleCI and push them to GCR (Google Container Registry). Once you figure out how to do this with $your_favorite_CI_tool, it is easy. However it took me about an hour to build this Circle CI and I had to do some tasks like set up Service Accounts, copy keys around etc.

Google Container Builder eliminates this completely, you just connect your GitHub account, pick what you want to build (every commit, branch or tag) and specify the image name you want to build and forget about it forever.

It runs faster compared to free CI services I've used in the past (probably because image pulls are fast b/c Google Networking, but I'm not sure how much CPU is allocated for builds). Also if you're pushing to GCR, then it'll be faster to push images as well. So overall pull/build/push cycle is just fast. To compare, build for a very simple image I have (base image docker.io/library/python) takes 3m30s on CircleCI vs 1m10s in Google Cloud Container Builder. That's 3x faster.




Hmm, I recently wired up CircleCI to do this exact thing, thanks for the write-up, will check it out.


How does it work for monorepos with multiple docker images?


Good question, I actually hit this problem. In one of my projects, I build 3 microservices out of a single GitHub repository. So I had 3 different Dockerfiles. What didn't work out for me was that Cloud Container Builder does not let you specify the Dockerfile name (but it lets you specify the Dockerfile directory, so if your dockerfiles are in separate dirs, you're good; however it's not very helpful if you need to host all your dockerfiles in the repo root.). If you think providing a custom Dockerfile name would be a useful feature, please let the folks know here. I am sure they would be interested in your feedback.

That said, I was easily able to unblock myself because Cloud Container Builder does not actually rely on Dockerfile. You can in fact specify build steps arbitrarily, like Travis CI (or other CI services) by writing a json/yaml file. See https://cloud.google.com/container-builder/docs/api/build-re... and https://cloud.google.com/container-builder/docs/api/build-st.... In that file, you can specify what you want to build and how you want to build it. It is quite flexible.


We've tried to satisfy the 90% case with the UI and "easy" options, especially those that transfer well from other push-to-build products.

To keep the UI simple and understandable for everyone, we decided to drop some options and require that you use a config for the more interesting cases.

There are lots of examples of config files (often named `cloudbuild.yaml`) in our github repo: https://github.com/googlecloudplatform/cloud-builders


What size is the project? Trying to guesstimate if it's worth investigating using 3rd party vs. [google] cloud container builder - speed tradeoffs, convenience, friction etc. Cheers.


I am simply building a Python container with about ~15 dependencies installed via pip and some ~50 MB of static assets added to the container. The base image comes from Docker Hub (hosted on S3/AWS CF).

If the final destination of your Docker image is GCR, it is really fast. You're basically not waiting for your build box to start up. Based on my experience the build starts almost right away after you push to the source control system, whereas CI systems like TravisCI/CircleCI spend quite some time preparing the build env (i.e. container) and running some preliminary commands, collecting artifacts/logs etc. Google Container Builder is looks like it is designed to build containers (not to run tests) and it does that quite fast.


Question: was this on regular CircleCI, or the v2 beta?


Regular Circle CI. I do not have access to the v2 beta. For comparison here is the same Dockerfile built with Circle CI, it took 3m30s: https://cl.ly/0U1c2Q1n2S20/Image%202017-03-06%20at%209.50.31... and Google Cloud Container Builder: https://cl.ly/3E1c3l1L2Q3o/Image%202017-03-06%20at%209.52.01... although Cloud Container Builder does not list how long each step it takes, it totals 1m10s.


Hey, Dev Advocate at CircleCI here:

Saw that you didn’t have 2.0 beta access; we’re actually opening that up to everyone this week, so keep an eye on our docs over the next few days. Biggest features you probably care about are the faster speeds/improved caching and native Docker support.


I tried setting up Docker deploys to K8S today on CircleCi v2 beta. I had a horribly difficult time getting it to work because running docker in the docker runtime is nearly impossible to do in a way that is compatible with Bazel.io. I ended up having to use the VM mode and it just felt like Circle v1.


You may be interested in trying GCCB with the bazel build step: https://github.com/GoogleCloudPlatform/cloud-builders/tree/m...

In a GCCB build, we volume-mount in the VM host's docker daemon socket, so you can use the docker CLI, and related CLIs, with no additional setup.

We initially tried a docker-in-docker approach here, but it was a bit too fragile. This attempt was quite some time ago, so it's possible things have improved.


Is there anything we can do to help on the Docker side?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: