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

21–30 of 114 posts

Re: Introducing Google Cloud Container Builder

#21

Post by skj »

searchfaster wrote: post #18
skj wrote: post #11

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

Thanks skj.. any plans of supporting containers other than docker ?

I really like rocket, and technically you can build and push rkt images right now, though it would require a lot of rocket knowhow.

Briefly, you can run any container image as a build step with this service, including one that builds rocket containers, and including one that pushes them. But, we're not currently offering any direct support for this ability.

Re: Introducing Google Cloud Container Builder

#24

Post by philips »

skj wrote: post #21
searchfaster wrote: post #18

Earlier quoted context omitted.

Thanks skj.. any plans of supporting containers other than docker ?

I really like rocket, and technically you can build and push rkt images right now, though it would require a lot of rocket knowhow. Briefly, you can run any container image as a build step with this service, including one that builds rocket containers, and including one that pushes them. But, we're not currently offering any direct support for this ability.

rkt supports running Docker Images[1], Open Container Initiative (OCI) Images[2], and appc images.

So, any container image this system builds will run under rkt.

rkt is explicitly designed as a container engine not as a container build system. And this is because build and execute are largely separate concerns. And it leaves the door open for new build systems as demonstrated here by Google.

[1] https://coreos.com/rkt/docs/latest/running-docker-images.htm...

[2] https://github.com/opencontainers/image-spec/issues/126#issu...

Re: Introducing Google Cloud Container Builder

#26

Post by puzzle »

skj wrote: post #11

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

Is there any caching involved?

In other words, what happens if I build the same source tree twice or if one line changes between one run and the next?

Re: Introducing Google Cloud Container Builder

#27

Post by oakhaven »

skj wrote: post #17
oakhaven wrote: post #14

Earlier quoted context omitted.

I think it's sort of container building as a service. It moves the burden of building Docker container from your laptop (or from your CI tool) to the GCE. It takes away the docker push, as it goes straight to the GCE registry (I guess). So if you need to do docker build too often, or maybe your container-release process feels a bit quirky, you might want to do it with the container builder. It doesn't seem too ground…

In addition to the "typical" kinds of builds you'll get with existing services (ie run 'docker build' and 'docker push' for me), we offer a flexible and powerful configuration language: https://cloud.google.com/container-builder/docs/api/build-st... One of the goals is to make it easy to separate the build-time environment from the run-time environment. eg, keep the JDK out of your deployable. We do this by letting y…

I went through the doc. Yes, in addition to Dockerfile, there is a way to run tasks in parallel. I'm not sure how killing of a feature that is, when every build tool lets you pass a job count. And beside that, I can't think of a legit use-case of what to run side by side in a container build. Maybe someone else knows/cares?

I've never built anything with JDK, but is cleanup of build dependencies really a problem in 2017?

For these goodies, you get a nice piece of vendor lock-in.

Re: Introducing Google Cloud Container Builder

#28

Post by skj »

puzzle wrote: post #26
skj wrote: post #11

Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.

Is there any caching involved? In other words, what happens if I build the same source tree twice or if one line changes between one run and the next?

We don't currently cache anything from one build to the next. We are open to optimizations here, in the future.

Re: Introducing Google Cloud Container Builder

#30

Post by skj »

oakhaven wrote: post #27
skj wrote: post #17

Earlier quoted context omitted.

In addition to the "typical" kinds of builds you'll get with existing services (ie run 'docker build' and 'docker push' for me), we offer a flexible and powerful configuration language: https://cloud.google.com/container-builder/docs/api/build-st... One of the goals is to make it easy to separate the build-time environment from the run-time environment. eg, keep the JDK out of your deployable. We do this by letting y…

I went through the doc. Yes, in addition to Dockerfile, there is a way to run tasks in parallel. I'm not sure how killing of a feature that is, when every build tool lets you pass a job count. And beside that, I can't think of a legit use-case of what to run side by side in a container build. Maybe someone else knows/cares? I've never built anything with JDK, but is cleanup of build dependencies really a problem in 2…

The difference between including the JDK vs only the JRE in your deployable image can mean hundreds of megabytes saved. If you're trying to roll out this image to hundreds or thousands of nodes, this can save a lot of resources.

Additionally, less in your deployable is better from a security standpoint.

re lock-in: We're definitely cognizant of lock-in issues, and were trying to make it as friendly as possible. In the end, our service is running a series of containers with your source mounted in. If you really want out, replicating this process is straightforward.

Post reply on HN