-
Notifications
You must be signed in to change notification settings - Fork 33
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
Propose the merge of static, tiny and base stacks and builders #313
Open
loewenstein-sap
wants to merge
11
commits into
main
Choose a base branch
from
ubuntu-core-builder
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
ff8bafd
Propose the merge of static, tiny and base stacks and builders
loewenstein-sap 5f690a1
Update text/0000-core-builder.md
loewenstein-sap 8137bff
Update text/0000-core-builder.md
loewenstein-sap d32990e
Update text/0000-core-builder.md
loewenstein-sap b838461
Update text/0000-core-builder.md
loewenstein-sap 18ec1fa
Update text/0000-core-builder.md
loewenstein-sap 7f9a46c
Update text/0000-core-builder.md
loewenstein-sap e2eacae
Update text/0000-core-builder.md
loewenstein-sap 237f192
Update text/0000-core-builder.md
loewenstein-sap 4fa079b
Update text/0000-core-builder.md
loewenstein-sap e42a3a9
Document new image names
loewenstein-sap File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
# Ubuntu Core Builder | ||
|
||
## Summary | ||
|
||
Over the past, the Paketo project has created four different stacks and builders based on the Ubuntu Linux distribution. The difference is in the number of packages included which in turn is based on the requirements of the different buildpacks included. | ||
This RFC proposes to create a new stack repository that will create a single `build` image and a number of `run` images based on the Ubuntu distribution and replace the existing `static`, `tiny` and `base` stacks. The `full` stack will be deprecated immediately, making the Jammy stack the last iteration of it. | ||
This RFC further proposes to create a new builder repository that will create a single builder using the build image as a base layer and the `base` run image as the default `run` image. | ||
|
||
Users will be able to use the new builder to build and run their applications using any of the language family buildpacks included. Instead of requireing a decision for an optimised builder, they can "just" start and later decide on an optimised `run` image. | ||
|
||
## Motivation | ||
|
||
The Paketo project will be easier to use for users - they can start without being asked to decide on optimisation. | ||
The stacks and builders maintainer team will have less work to do - they will only need to maintain a single stack and builder instead of three. | ||
|
||
## Detailed Explanation | ||
|
||
We would replace the current `base`, `tiny` and `static` stacks with a single stack that includes all packages required by the buildpacks. Similarly, we would replace the current `base`, `tiny` and `static` builders with a single builder. | ||
loewenstein-sap marked this conversation as resolved.
Show resolved
Hide resolved
loewenstein-sap marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
The `full` stack will be deprecated, making the present Jammy stack the last iteration of the `full` stack released by the Paketo team. This provides support for the full stack through [April of 2027](https://ubuntu.com/about/release-cycle), which is a sufficiently long deprecation period. Upon approval of this RFC, the Paketo Steering Committee will write a blog post announcing the stack changes and the deprecation of the full stack. The PHP buildpack will then need to be altered so that it can run on the new base stack or it will need to be changed to utilize extensions to install any additional packages that it requires over and above what is in the base image. | ||
|
||
Container images have a layer limit and in the past, we have had issues with builders that include a lot of buildpacks because this can quickly cause the builder to hit the layer limit. To prevent this from happening, we will by default squash layers for all composite buildpacks included in the builder. This will be done by using the `--flatten` of `pack builder create`, and it should allow the builder to scale to include all of the Paketo buildpacks. | ||
|
||
## Rationale and Alternatives | ||
|
||
We could leave everything as it is. We would stick to maintaining four stacks repositories and eight builder repositories and creating new ones for every LTS we adopt. But that would increase the burden on the maintainers. | ||
|
||
## Implementation | ||
|
||
I would propose to create the new stack and builder as part of moving to Ubuntu Noble Numbat. I.e. | ||
- we should create a repository `paketo-buildpacks/ubuntu-noble-base-images` | ||
- we should take the `build` image content from the `paketo-buildpacks/noble-base-stack` repository and apply it to `paketo-buildpacks/ubuntu-noble-base-images` | ||
- we should take the `run` image content from the `paketo-buildpacks/noble-base-stack` repository and apply it to `paketo-buildpacks/ubuntu-noble-base-images` | ||
- we should take the `run` image content from the `paketo-buildpacks/noble-tiny-stack` repository and apply it to `paketo-buildpacks/ubuntu-noble-base-images` as additional run image | ||
- we should take the `run` image content from the `paketo-buildpacks/noble-static-stack` repository and apply it to `paketo-buildpacks/ubuntu-noble-base-images` as additional run image | ||
- we should create a repository `paketo-buildpacks/ubuntu-noble-builder` | ||
- we should use the above `build` image as a base layer for the `builder` image | ||
- we should use the above `run` image as the default `run` image for the `builder.toml` | ||
- we should use the above `run-static` and `run-tiny` images as additional `run` images for the `builder.toml` | ||
- we should use the above images in another `builder-buildpackless.toml` in the same repository to create and publish a buildpackless builder | ||
|
||
The image names will be changed like the following: | ||
paketobuildpacks/build-noble-base -> paketobuildpacks/ubuntu-noble-build | ||
paketobuildpacks/run-noble-base -> paketobuildpacks/ubuntu-noble-run | ||
paketobuildpacks/run-noble-static -> paketobuildpacks/ubuntu-noble-run-static | ||
paketobuildpacks/run-noble-tiny -> paketobuildpacks/ubuntu-noble-run-tiny | ||
paketobuildpacks/builder-noble-base -> paketobuildpacks/ubuntu-noble-builder | ||
paketobuildpacks/builder-noble-buildpackless-base -> paketobuildpacks/ubuntu-noble-builder-buildpackless | ||
|
||
I would propose to delete the `paketo-buildpacks/noble-base-stack`, `paketo-buildpacks/noble-tiny-stack` and `paketo-buildpacks/noble-static-stack` repositories. | ||
I would propose to delete the `paketo-buildpacks/builder-noble-buildpackless-static`, `paketo-buildpacks/builder-noble-buildpackless-tiny` and `paketo-buildpacks/builder-noble-buildpackless-base` repositories. | ||
|
||
## Prior Art | ||
|
||
This has been done in https://github.com/paketo-community/ubi-base-stack already. The `stacks` folder and `images.json` should give guidance on how to create multiple run images. Also, this is currently WiP in https://github.com/paketo-buildpacks/noble-base-stack/pull/11. | ||
|
||
## Unresolved Questions and Bikeshedding | ||
Q: With pack, it is very easy to specify a different run image. Is it similarly easy when not using pack? | ||
A: We know this to work with some platforms. The notable exception is kpack. | ||
|
||
For example: | ||
Q: How does this impact the [language-specific builders RFC](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0055-create-language-family-builders.md)? | ||
A: It does not impact language-specific builders and Paketo buildpacks language families can continue to ship language-specific builders as needed. | ||
Q: Does this proposal require Paketo buildpacks language families to implement an extension to switch or auto-select runtimes? | ||
A: No. That is out of the scope of this RFC, and will be the topic of a future discussion and possibly future RFC. | ||
- Spring: https://docs.spring.io/spring-boot/maven-plugin/build-image.html#build-image.customization | ||
- Tekton: https://github.com/buildpacks/tekton-integration/tree/main/task/buildpacks/0.4#parameters | ||
Q: What about the `full` stack and builders? | ||
A: This proposal does not include the `full` builder and recommends that it be deprecated. If approved, this RFC will make the Jammy Full stack the last supported iteration of the full stack. There is presently only one buildpack, PHP, which requires the full stack and is thus impacted. This buildpack will be able to continue using the Jammy Full stack through [April 2027](https://ubuntu.com/about/release-cycle) with the goal of converting it to run on the new Noble all-in-one stack before that point. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with that, it's confusing to choose which builder to use. But I think it would be better if the image starts by default being optimized and in case the user needs more packages into the run image (a bigger run stack image) then he/she could choose a different run image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a trade-off to consider (as usual) and I would be inclined to prioritize "works out of the box" over "provides minimal dependencies".
Extensions could be a way to remove the need to choose one over the other. However, they introduce other trade-offs. For one, with the recent news on Kaniko (see here and here) I'd say the future of at least the implementation of Extensions is unclear. Independent of that, I think an implementation for choosing the best run image based on language choice using Extensions can quickly become unwieldy - as far as I remember this would require Extension(s) and special Buildpack(s) to work in collaboration with each other via the Build Plan.
It is likely possible, but I am not sure it is worth the effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 - I think it needs to just work out of the box. If it's not the smallest possible image, that's OK. We can then provide other runtime images that allow you to make smaller app images.
I think a nice side effect of this approach is that it socializes and makes commonplace the usage of a runtime image not provided by the builder. This could even allow a user to take our runtime image and add or remove stuff in their own custom runtime image. You could do this before, but it's making it more accessible / "normal" if we're suggesting folks do it.