-
Notifications
You must be signed in to change notification settings - Fork 71
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into fix-pack-publish-buildpack-link
- Loading branch information
Showing
5 changed files
with
1,525 additions
and
12 deletions.
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
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,131 @@ | ||
# Meta | ||
[meta]: #meta | ||
- Name: Enable CNB_SKIP_SBOM IN /cnb/lifecycle/creator | ||
- Start Date: (fill in today's date: 2023-10-17) | ||
- Author(s): kritkasahni-google | ||
- Status: Approved | ||
- RFC Pull Request: | ||
- CNB Pull Request: | ||
- CNB Issue: | ||
- Supersedes: N/A | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
Enable CNB_SKIP_SBOM IN /cnb/lifecycle/creator to skip restoring SBOM layer from previous app image. We support CNB_SKIP_LAYERS in analyzer which does the same thing and we should support the same in creator also. | ||
|
||
# Definitions | ||
[definitions]: #definitions | ||
* lifecycle: software that orchestrates a CNB build. | ||
* creator: executes all the lifecycle phases one by one in order. | ||
* analyzer: lifecycle phase that restores SBOM layer from previous app image. | ||
* restorer: lifecycle phase that restores layers from cache. | ||
* SBOM: a software bill of materials (SBOM) is a list of all the components that make up the app image. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
To skip restoring SBOM layer from previous image when platform executes lifecycle by calling /cnb/lifecycle/creator. Restoring SBOM layer from previous app image can cause degraded build latency but if buildpack logic does not rely on SBOM from previous app image then should be able to skip restoring it. | ||
|
||
# What it is | ||
[what-it-is]: #what-it-is | ||
|
||
CNB_SKIP_LAYERS is used by /cnb/lifecycle/analyzer to skip restoring SBOM layer from previous app image. | ||
Need a similar mechanism for /cnb/lifecyle/creator specifically to skip restoring only the SBOM layer. | ||
|
||
The target personas affected by this change are: | ||
|
||
- **buildpack user**: if buildpacks don't rely on reusing SBOM layer then buildpack user should ideally see improved build latency by skipping SBOM restoration but reusing other layers from previous app image. | ||
- **Platform implementors**: they will choose to skip restoring SBOM by providing CNB_SKIP_SBOM to trigger /cnb/lifecycle/creator. | ||
|
||
|
||
# How it Works | ||
[how-it-works]: #how-it-works | ||
|
||
Similar to how CNB_SKIP_LAYERS is handled in analyzer whether SBOM needs to be [restored](https://github.com/buildpacks/lifecycle/blob/292aa492a72f4e180bb92d109a73ebf7c8a0451d/phase/analyzer.go#L38) or [not](https://github.com/buildpacks/lifecycle/blob/292aa492a72f4e180bb92d109a73ebf7c8a0451d/phase/analyzer.go#L30) today, CNB_SKIP_SBOM will be be handled in same way in analyzer. | ||
At the platform level, it would be input same way as CNB_SKIP_LAYERS [here](https://github.com/buildpacks/lifecycle/blob/292aa492a72f4e180bb92d109a73ebf7c8a0451d/platform/defaults.go#L184) and [handled](https://github.com/buildpacks/lifecycle/blob/main/platform/lifecycle_inputs.go#L82) like:- | ||
|
||
|
||
``` | ||
var skipSBOM bool | ||
if boolEnv(EnvSkipSBOM){ | ||
skipSBOM = true | ||
} | ||
``` | ||
|
||
In the analyzer, | ||
|
||
``` | ||
analyzer := &Analyzer{ | ||
Logger: logger, | ||
SBOMRestorer: &layer.NopSBOMRestorer{}, | ||
PlatformAPI: f.platformAPI, | ||
} | ||
... | ||
if f.platformAPI.AtLeast("0.8") && !inputs.SkipLayers && !inputs.SkipSBOM { | ||
analyzer.SBOMRestorer = &layer.DefaultSBOMRestorer{ | ||
LayersDir: inputs.LayersDir, | ||
Logger: logger, | ||
} | ||
} | ||
``` | ||
|
||
# Migration | ||
[migration]: #migration | ||
|
||
CNB_SKIP_SBOM/<skip-sbom> will be an optional input to /cnb/lifecycle/creator, and will be false by default. We maybe need to add a new API option for buildpack users, to choose whether this should be enabled. | ||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
N/A | ||
|
||
# Alternatives | ||
[alternatives]: #alternatives | ||
|
||
Platforms that execute lifecycle today via /cnb/lifecycle/creator are unable to skip restoring SBOM layer from previous app image unless they skip reusing previous app image entirely. | ||
|
||
# Prior Art | ||
[prior-art]: #prior-art | ||
|
||
We already support enabling CNB_SKIP_LAYERS in /cnb/lifecycle/analyzer and /cnb/lifecycle/restorer, and CNB_SKIP_RESTORE in /cnb/lifecycle/creator. | ||
* CNB_SKIP_LAYERS in /cnb/lifecycle/analyzer to skip restoring SBOM from previous app image. | ||
* CNB_SKIP_LAYERS in /cnb/lifecycle/restorer to skip reusing previous app image layers entirely. | ||
* CNB_SKIP_RESTORE in /cnb/lifecycle/creator to skips restoring SBOM plus all other layers entirely from previous app image. | ||
|
||
# Unresolved Questions | ||
[unresolved-questions]: #unresolved-questions | ||
|
||
N/A | ||
|
||
# Spec. Changes (OPTIONAL) | ||
[spec-changes]: #spec-changes | ||
This new feature will affect the API of [Create](https://buildpacks.io/docs/concepts/components/lifecycle/create/) phase by adding the following fields. | ||
|
||
Back to API changes, we will add a new flag to control this. | ||
|
||
| Input | Environment Variable | DefaultValue | Description | | ||
|----------------|-----------------------|--------------|----------------------------------------------| | ||
| `<skip-sbom>` | `CNB_SKIP_SBOM` | `false` | Skip SBOM restoration | | ||
|
||
# History | ||
[history]: #history | ||
|
||
<!-- | ||
## Amended | ||
### Meta | ||
[meta-1]: #meta-1 | ||
- Name: (fill in the amendment name: Variable Rename) | ||
- Start Date: (fill in today's date: YYYY-MM-DD) | ||
- Author(s): (Github usernames) | ||
- Amendment Pull Request: (leave blank) | ||
### Summary | ||
A brief description of the changes. | ||
### Motivation | ||
Why was this amendment necessary? | ||
---> |
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,131 @@ | ||
# Meta | ||
[meta]: #meta | ||
- Name: Add extension layer to exchange data | ||
- Start Date: 2023-10-09 | ||
- Author(s): [c0d1ngm0nk3y](https://github.com/c0d1ngm0nk3y), [pbusko](https://github.com/pbusko) | ||
- Status: Approved | ||
- RFC Pull Request: | ||
- CNB Pull Request: | ||
- CNB Issue: | ||
- Related: [RFC#0105 Support Dockerfiles](https://github.com/buildpacks/rfcs/blob/main/text/0105-dockerfiles.md) | ||
- Supersedes: N/A | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
This RFC introduces support for Extension configurable context to allow data transfer between the build environment and the Kaniko execution. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
This change allows extensions to create their own context for the extend phase during the generation phase. Additionally, it ensures that extension output does not inadvertently interfere with other extension or buildpack layers during the build, and it does not unintentionally become part of the final application image. | ||
|
||
This would allow distroless run images to be extended. | ||
|
||
# What it is | ||
[what-it-is]: #what-it-is | ||
|
||
This follows up on RFC-0105 and proposes that during the execution of the extension's `./bin/generate`, an extension is allowed to write arbitrary data to the `context` folder within its exclusive output directory. This data then becomes accessible during the execution of the `extend` phase via Kaniko build context. The content of these extension-specific context is ignored at build and launch time, it serves only the extension phase. | ||
|
||
# How it Works | ||
[how-it-works]: #how-it-works | ||
|
||
- Before execution of the `./bin/generate`, the lifecycle will create a distinct writable layer `$CNB_GENERATED_DIR/<extension-id>` for each extension which passed detection. | ||
- The `$CNB_GENERATED_DIR/<extension-id>` is provided to the `./bin/generate` as `<output>` (`$CNB_OUTPUT_DIR`) directory. | ||
- In addition to the files specified in [RFC#0105](https://github.com/buildpacks/rfcs/blob/main/text/0105-dockerfiles.md), the extension may create the following folders with an arbitrary content: | ||
|
||
either: | ||
|
||
- `<output>/context` | ||
|
||
or the image-specific folders: | ||
|
||
- `<output>/context.run` | ||
- `<output>/context.build` | ||
|
||
If the `<output>/context` is provided together with any of the image-specific folders the detection phase must fail. | ||
- If the folder `<output>/context` is present it will be set as Kaniko build context during the `extend` phase of the build and run images. | ||
- If the folder `<output>/context.run` is present it will be set as Kaniko build context during the `extend` phase of the run image only. | ||
- If the folder `<output>/context.build` is present it will be set as Kaniko build context during the `extend` phase of the build image only. | ||
- If none of these folders is not present, Kaniko build context defaults to the `<app>` folder. | ||
|
||
The `$CNB_GENERATED_DIR/<extension-id>` folders will not be included in the final image by the lifecycle. | ||
|
||
### Example: Extend distroless run image with Debian packages. | ||
|
||
This example extension would allow to install `tar` package on the run image without package manager (distroless image). The extension contains `./bin/generate` and `./bin/custom-installer` file, which installs `.deb` files. | ||
|
||
##### `./bin/generate` | ||
|
||
```bash | ||
#!/bin/sh | ||
|
||
mkdir -p ${CNB_OUTPUT_DIR}/context.run | ||
|
||
cp ${CNB_EXTENSION_DIR}/bin/custom-installer ${CNB_OUTPUT_DIR}/context.run/ | ||
curl -o ${CNB_OUTPUT_DIR}/context.run/tar.deb http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1ubuntu0.1.22.04.1_amd64.deb | ||
|
||
cat >> "${CNB_OUTPUT_DIR}/run.Dockerfile" <<EOL | ||
ARG base_image | ||
FROM \${base_image} | ||
ARG build_id=0 | ||
ADD custom-installer . | ||
ADD tar.deb . | ||
RUN ./custom-installer -p ./tar.deb | ||
EOL | ||
``` | ||
|
||
# Migration | ||
[migration]: #migration | ||
|
||
- No breaking changes were identified | ||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
Why should we *not* do this? | ||
|
||
N/A | ||
|
||
# Alternatives | ||
[alternatives]: #alternatives | ||
|
||
- Allow multi-stage Dockerfiles | ||
|
||
# Prior Art | ||
[prior-art]: #prior-art | ||
|
||
Discuss prior art, both the good and bad. | ||
|
||
# Unresolved Questions | ||
[unresolved-questions]: #unresolved-questions | ||
|
||
- Should the `./bin/generate` be executed during the `extend` phase instead of the `detect` phase? | ||
|
||
# Spec. Changes (OPTIONAL) | ||
[spec-changes]: #spec-changes | ||
|
||
This RFC requires changes to the layers metadata and the `extend` phase: | ||
|
||
- the `$CNB_OUTPUT_DIR` must point to the `$CNB_GENERATED_DIR/<extension-id>` folder instead of a temporary directory. | ||
- allow optional folders `$CNB_GENERATED_DIR/<extension-id>/context`, `$CNB_GENERATED_DIR/<extension-id>/context.run` and `$CNB_GENERATED_DIR/<extension-id>/context.build` with an arbitrary content to be provided by extension. | ||
- if the context folders are present, kaniko context should be set to the corresponding folder instead of the `<app>` (following the rules defined in [#how-it-works](#how-it-works)). | ||
|
||
<!-- | ||
## Amended | ||
### Meta | ||
[meta-1]: #meta-1 | ||
- Name: (fill in the amendment name: Variable Rename) | ||
- Start Date: (fill in today's date: YYYY-MM-DD) | ||
- Author(s): (Github usernames) | ||
- Amendment Pull Request: (leave blank) | ||
### Summary | ||
A brief description of the changes. | ||
### Motivation | ||
Why was this amendment necessary? | ||
---> |
Oops, something went wrong.