4 ms·
That's cool, I'll need to read up on the v3 design. I think you are right about the rebuilds, but maybe not in all cases.. If you had. FROM nodejs:whatever
by justinsaccount 8y ago
That's cool, I'll need to read up on the v3 design.
I think you are right about the rebuilds, but maybe not in all cases.. If you had.
FROM nodejs:whatever as js
RUN npm build
FROM golang:whatever as go
RUN go build
FROM base
COPY --from js app.js
COPY --from go app
If only 'base' was updated rebuilding the image would just need to re-run the COPY commands. The only way everything would get rebuilt is if you also updated the go and js images.
I think for more complicated applications https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images is ultimately the best way to do things... ensuring that every step is isolated with explicit dependency information.
- jacques_chester 8y agoI agree, the Nix approach makes lots of problems go away, but you have to be bought in first. I wrote something distinct a few months back which overlaps on the "we can be smarter about layers" thing[0]. Google folks worked on "FTL", which is a technique for determining layering by reasoning about packaging system information. Jib[1] is one such system. There is a view that it will be possible to use FTL implementations or derivatives as buildpack components in the future. [0] https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POUaadcvK3ZNT9QEGDZhPk/edit# https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POU... [1] https://github.com/GoogleContainerTools/jib https://github.com/GoogleContainerTools/jib