News for hackers. Stuff that matters.

A comment on Introducing Google Cloud Container Builder. Parent comment

Re:Introducing Google Cloud Container Builder by skj on Monday March 06, 2017 @05:40PM (#13806748)
One approach to this problem that I like is storing these dependencies in an intermediate image. Then, you can do an incremental build by referencing (rather than rebuilding) this intermediate image, and pay only the cost of downloading the raw data which should be cheap compared to the normal install process.
[ Parent | on HN ]
Re:Introducing Google Cloud Container Builder by gkop on Monday March 06, 2017 @05:43PM (#13806762)
Why not leverage Docker's built-in image layer caching?
[ Parent | on HN ]
Re:Introducing Google Cloud Container Builder by kentt on Monday March 06, 2017 @05:52PM (#13806830)
I think the idea here is that the docker level caching isn't well suited for this. Eg for us we install all relevant gems with `bundle install`. If you update one gem, that the whole layer is rebuilt. Since the whole `bundle install` layer is rebuilt, every gem is fetched again from rubygems.

Yarn works the same.

[ Parent | on HN ]
Re:Introducing Google Cloud Container Builder by morgante on Monday March 06, 2017 @06:06PM (#13806924)
Having a separate FROM image doesn't help that situation either, since you have to rebuild it.
[ Parent | on HN ]
Re:Introducing Google Cloud Container Builder by skj on Monday March 06, 2017 @06:39PM (#13807121)
Couldn't you FROM and then update? I'm not a ruby expert but I'd hope that it could be incremental.
[ Parent | on HN ]
Re:Introducing Google Cloud Container Builder by puzzle on Monday March 06, 2017 @06:21PM (#13807015)
That might be less effective if you can't guarantee that all the builds end up always on the same node.
[ Parent | on HN ]