Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buildpacks Dockerfile RFC Tracking #865

Open
BarDweller opened this issue Jul 8, 2022 · 2 comments
Open

Buildpacks Dockerfile RFC Tracking #865

BarDweller opened this issue Jul 8, 2022 · 2 comments
Assignees
Labels
1 - Community engagement Chat, mail, discuss with upstream projects/community 9 - R&D Research & Development, Tech watch

Comments

@BarDweller
Copy link

This issue is to allow us to track the work happening in the Buildpacks community to deliver the 'Dockerfiles RFC'.

Links:

The buildpacks community is implementing the Dockerfile RFC as a series of stages.. (taken from RFC)

  • Phase 1: run.Dockerfiles can be used to switch the runtime base image
  • Phase 2: build.Dockerfiles can be used to extend the build time base image
    • 2a: pack applies the build.Dockerfiles
    • 2b: the lifecycle applies the build.Dockerfiles using kaniko
  • Phase 3: run.Dockerfiles can be used to extend the runtime base image
    • 3a: pack applies the run.Dockerfiles
    • 3b: the lifecycle applies the run.Dockerfiles using kaniko

Our goal is to have UBI8 based builder/run images, where dependencies are installed via rpm/dnf.
This will become possible for subsets of applications at Phase 2, with complete support requiring Phase 3.

Phase 1 is of little use to us, except for creation of small scoped PoC's to test the overall approach, and provide feedback to the buildpacks community.

@BarDweller BarDweller added 1 - Community engagement Chat, mail, discuss with upstream projects/community 9 - R&D Research & Development, Tech watch labels Jul 8, 2022
@BarDweller BarDweller self-assigned this Jul 8, 2022
@BarDweller
Copy link
Author

Phase 1 may seem small to us from a functionality perspective, but Phase 1 to buildpacks is the introduction of the concepts surrounding 'extensions' which are the vehicles through which the Dockerfiles will be generated. As such, although Phase 1 offers us no real capabilities to make use of, it's still very worth being engaged, as it's now that the docs/specs are being updated to allow for the existence of extensions. This process takes times because really it's the first point at which the wider buildpack community is considering the implications of extensions, and slowly but surely anticipated problems are being discussed and resolved. This process has already resulted in changes to the spec since the PoC, with extensions gradually being treated as different entities to buildpacks, rather than just a different flavour.

@BarDweller
Copy link
Author

Updates!

It took longer than expected, as a few issues had to be resolved. However, the current plan is now to release Phase 1 & 2 together.. the RFC has been accepted, and the lifecycle changes are currently being built in the branch https://github.com/buildpacks/lifecycle/tree/extensions-phase-2 which we are expecting to merge to main during September.

From the original list.. Phase 2a & 2b and 3a & 3b have been collapsed to just 2b & 3b respectively.

I've been testing the phase1+phase2 branch by composing my own builder image containing extensions, buildpacks, and the updated/patched lifecycle binaries, and it is looking functional.

Using such a builder image requires a platform implementation that is compliant to the upcoming platform version that supports that lifecycle. Or, in other words, this won't work with most existing platform implementations until they update.. I'm using a trivial implementation of a platform I've written in bash. The most notable difference from previous platforms is that (currently) you cannot use the single 'creator' lifecycle phase with builder images containing extensions, you have to drive the individual phases sequentially. I will be updating the quarkus buildpack library shortly to recognise & support these buildpacks. Support via 'pack' should follow shortly from the buildpack team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - Community engagement Chat, mail, discuss with upstream projects/community 9 - R&D Research & Development, Tech watch
Projects
None yet
Development

No branches or pull requests

1 participant