Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Google Cloud Container Builder

cloudplatform.googleblog.com

Post reply on HN
Print view View original

71–80 of 114 posts

Re: Introducing Google Cloud Container Builder

#71

Post by philip1209 »

pbiggar wrote: post #66
alpb wrote: post #57

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.…

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

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.

Re: Introducing Google Cloud Container Builder

#72

Post by philip1209 »

jacobparker wrote: post #45
nchuhoai wrote: post #34

I'm so surprised that both Docker's as well as Google's solution to this problem involves 0 caching. Much of our container building includes fetching dependencies from various package managers which rarely changes across builds, yet takes up the majority of the build time. Most of the time thats good enough, but for cases where we want to immediately deploy a fix, it can be quite frustrating to having to spend all th…

I'd give this a look: https://github.com/GoogleCloudPlatform/cloud-builders/tree/m... (unfortunately key links to Bazel docs are 404'ing.) Bazel is a general purpose build system that focuses on reproducibility (same build inputs -> same build outputs) and strict dependency specification (at various levels: file, subsystem, external package fetching etc.) enforced by sandboxing which allows for fast incremental build…

We just open sourced our monorepo which uses Bazel - https://GitHub.com/staffjoy/v2

It has some major speed benefits. But it's not turnkey. Setting it up is hard. Its dep management in Go isn't compatible with lint, vet, etc. We never got node modules installing with Bazel.

Re: Introducing Google Cloud Container Builder

#73

Post by philip1209 »

theCricketer wrote: post #4

Could someone explain specifically what problem Container Builder solves?

The problem is that it's tough to push code and have it just start running on a server. Docker makes packaging and running easy. Google has docker hosting. There's still a missing intermediary of building and registering the container, and this seems to solve that need.

Re: Introducing Google Cloud Container Builder

#74

Post by alpb »

philip1209 wrote: post #69
alpb wrote: post #57

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.…

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.

Re: Introducing Google Cloud Container Builder

#77

Post by graphememes »

alpb wrote: post #57

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.…

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

Re: Introducing Google Cloud Container Builder

#78

Post by dottedmag »

kmicklas wrote: post #50
mickronome wrote: post #48

Earlier quoted context omitted.

I like what I understand to be the core ideas of NixOS to be, but i have to say: There might be a chance that some century, people both in the industry and outside understand that new syntax, or languages, are rarely necessary, or even beneficial. Use different semantics if you must, but please use some existing syntax for your DSL. I'm so tired of learning a pointless new variety of almost the same thing, only with…

Agreed, Nix the language is probably unnecessary. (The main benefit I can think of is avoiding depending on the moving target that is basically any other scripting language they could have tried to co-opt.)

To be fair, Nix language is completely different from other languages out there -- it employs only immutable data structures -- so using another language would not be possible.

It does not excuse Nix to have such a braindamaged^W esoteric syntax.

Re: Introducing Google Cloud Container Builder

#80

Post by lucian1900 »

mickronome wrote: post #48
kmicklas wrote: post #44

Earlier quoted context omitted.

Some century the industry will discover the NixOS model...

I like what I understand to be the core ideas of NixOS to be, but i have to say: There might be a chance that some century, people both in the industry and outside understand that new syntax, or languages, are rarely necessary, or even beneficial. Use different semantics if you must, but please use some existing syntax for your DSL. I'm so tired of learning a pointless new variety of almost the same thing, only with…

The alternative is co-opting an existing language, which is what Ansible and Saltstack do with YAML. I find that to be much worse, since a lot more is valid as just YAML than ansible/salt files.
Post reply on HN