Decouple extend phase from kaniko #414
Description
The lifecycle currently uses kaniko as a library to perform build- and run-image extension, but kaniko has fallen into unmaintained status making it impractical and undesirable to rely on this dependency.
Possible alternatives considered:
- buildah
- buildkit
As a first step, we should decouple the CNB platform spec from the extender implementation, making it possible for platforms to "bring their own" extender. To note:
/kanikois a required input directory for the restorer and the extender when using extensions, as a way of handing off the manifest & config file of the image to extend- This may not be desirable in all cases. For example an alternative extender might simply read the run image reference in analyzed.toml after it has been resolved by the restorer (after image extensions may have switched it from the original)
kaniko-cache-ttlis an optional flag for the extender- The exporter expects that the extended run image manifest, config, and layers will be available in OCI layout format in
<layers>/extended/runafter running the extend phase- This may not be desirable in all cases. For example an alternative extender might simply update the run image reference used by the exporter instead of providing layer tars
Important
Because we are using kaniko as a library, we are currently able to combine build image extension with the lifecycle build phase as a single command invocation within a single container. This may not be achievable with alternative extender implementations.
- For an example of how non-kaniko build image extension might work, see this pack PR: add support for pack to extend base images using daemon pack#1791. We were able to get it working and saw improved performance when extending the build image, but in the end we felt that the additional complexity was too much to support.
The lifecycle currently ships with /cnb/lifecycle/extender (which is just a symlink pointing back to /cnb/lifecycle/lifecycle) - we might want to rip that out after a sufficient deprecation period. We could start by shipping it as a separate tarball/image - e.g., something like index.docker.io/buildpacksio/extender:latest so that the kaniko code is at least isolated from the rest of the lifecycle.
In the end, we might provide an alternative project-supported extender, or simply rely on platforms to bring their own. Perhaps the various implementations could live in buildpacks-community as a middle ground.