add support for pack to extend base images using daemon

[itsdarshankumar]

Summary

As pack already has access to a daemon, it can apply the dockerfiles directly, saving the extended build base image in the daemon which gives us great performance benefits. Thus it will not need to use the extender phase of lifecycle. Additionally it will drop the requirement that the image being extended must be published to a registry.

Output

Related

Resolves #1623

[jjbustamante]

Moving this one to milestone 0.31.0

[natalieparellano]

@itsdarshankumar thank you for making all the updates to your branch. I tried to re-run the test mentioned in #1791 (comment), but I'm still getting the error: [extender (build)] {"errorDetail":{"message":"COPY failed: file not found in build context or excluded by .dockerignore: stat mvnw: file does not exist"},"error":"COPY failed: file not found in build context or excluded by .dockerignore: stat mvnw: file does not exist"}. When I rerun the command with released pack, the build succeeds.

Before we proceed further, it might be prudent to check with @loewenstein @c0d1ngm0nk3y and others to see if there is still appetite for this change, given forthcoming changes to the extend phase outlined in buildpacks/spec#384. To summarize, with #1791 we'd use the daemon to extend builder images only (effectively chaining docker build together using the generated build.Dockerfiles). This gives us a nice performance boost but introduces code complexity because we cannot extend run images this way as it makes performance worse (due to time spent saving extended layers from the daemon). If we merge this PR the changes from buildpacks/spec#384 might be more complicated to implement. Another possible consideration is that a future integration with BuildKit (if we ever get there) might make relying on the daemon for image extension a bit simpler. Please opine!

[loewenstein]

I will leave a thorough technical comment up to @pbusko @c0d1ngm0nk3y @modulo11 @phil9909 - but I am wondering how a pack optimisation could make a lifecycle change harder?

[natalieparellano]

@loewenstein it wouldn't make the lifecycle change harder - but, some things would need to be re-implemented in pack since we aren't relying on the lifecycle for build image extension.

[loewenstein]

@loewenstein it wouldn't make the lifecycle change harder - but, some things would need to be re-implemented in pack since we aren't relying on the lifecycle for build image extension.

FWIW buildpacks/lifecycle#1276 is said lifecycle implementation ;)

[natalieparellano]

@itsdarshankumar thank you for your work here. Given the evolution of the "Dockerfiles" feature and the introduction of configurable context directories (buildpacks/spec#384), it may no longer by prudent to have a separate implementation of build image extension that uses the daemon, as this would require changes to be implemented twice (once in the lifecycle for run image extension and non-pack platforms, and once in pack for build image extension). Also having build image extension (uses daemon) and run image extension (uses lifecycle) behave differently in pack might be confusing, especially for newer contributors.

However the work in this PR is still extremely valuable as it gives us an indication of the performance benefits we might see in relying on the daemon for image extension vs kaniko. I suggest we keep on eye on potential upcoming changes to the daemon (such as moby/moby#44369) that might run image extension with the daemon more performant. If build image extension and run image extension could both use the daemon, that would make things simpler in pack. That doesn't solve the need for changes to be implemented twice (lifecycle, pack) but we can still learn from this PR how to make that easier, if we decide the performance improvement is worth the effort.