Skip to content

Commit 264b5a7

Browse files
authored
Merge pull request cds-hooks#611 from buildpacks/platform/migration
Add migration guide for Platform 0.11 & 0.12
2 parents ef9cb98 + 1d8a6bf commit 264b5a7

10 files changed

+257
-11
lines changed

content/docs/reference/spec/migration/buildpack-api-0.8-0.9.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -20,9 +20,9 @@ Buildpack processes can still use a shell! However, the `command` must now expli
2020

2121
Hand-in-hand with shell removal is the introduction of overridable process arguments.
2222

23-
In `launch.toml`, `command` is now a list. The first element in `command` is the command, and all following entries are arguments that are always provided to the process, regardless of how the application is started. The `args` list now designates arguments that can be overridden by the end user - if supported by the platform (platform API version 0.10 and above). For further details, see the platform [migration guide](/docs/reference/spec/migration/platform-api-0.9-0.10).
23+
In `launch.toml`, `command` is now a list. The first element in `command` is the command, and all following entries are arguments that are always provided to the process, regardless of how the application is started. The `args` list now designates arguments that can be overridden by the end user - if supported by the platform (Platform API version 0.10 and above). For further details, see the platform [migration guide](/docs/reference/spec/migration/platform-api-0.9-0.10).
2424

25-
For older platforms (platform API version 0.9 and below), arguments in `args` will be appended to arguments in `command`, negating the new functionality (but preserving compatibility).
25+
For older platforms (Platform API version 0.9 and below), arguments in `args` will be appended to arguments in `command`, negating the new functionality (but preserving compatibility).
2626

2727
### Image extensions are supported (experimental)
2828

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
+++
2+
title="Platform API 0.10 -> 0.11"
3+
+++
4+
5+
<!--more-->
6+
7+
This guide is most relevant to platform operators and builder authors.
8+
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.11) for Platform API 0.11 for the full list of changes and further details.
10+
11+
## Platform Operator
12+
13+
### SBOM files for the `launcher` are included in the application image
14+
15+
In Platform 0.11, the lifecycle ships with standardized SBOM files describing the `lifecycle` and `launcher` binaries
16+
(these are included in the tarball on the GitHub release page and within the image at `index.docker.io/buildpacksio/lifecycle:<version>`).
17+
18+
After a build, SBOM files describing the `launcher` are included in the application image at `<layers>/sbom/launch/buildpacksio_lifecycle/launcher/sbom.<ext>`,
19+
where `<ext>` is each of: `cdx.json`, `spdx.json`, and `syft.json`.
20+
Additionally, SBOM files describing the `lifecycle` are copied to `<layers>/sbom/build/buildpacksio_lifecycle/sbom.<ext>`,
21+
where they may be saved off by the platform prior to the build container exiting.
22+
23+
This mirrors what is already being done as of Platform 0.8 for buildpack-provided standardized SBOM files,
24+
which are exported to `<layers>/sbom/launch/<buildpack-id>/<layer>/sbom.<ext>` (for runtime dependencies)
25+
and copied to `<layers>/sbom/launch/<buildpack-id>/sbom.<ext>` (for build-time dependencies).
26+
27+
To use this feature, no additional action is required from platforms that are already handling buildpack-provided SBOM files.
28+
The SBOMs for the image will simply be more complete.
29+
30+
### The rebaser accepts a -previous-image flag to allow rebasing by digest reference
31+
32+
Previously, when rebasing an image, the rebased image would always be saved to the same tag as the original image.
33+
This prevented rebasing by digest, among other use cases.
34+
35+
In Platform 0.11, the original image may be specified separately from the destination image with the `previous-image` flag, as in the following:
36+
37+
```bash
38+
/cnb/lifecycle/rebaser -previous-image some-original-image some-destination-image
39+
```
40+
41+
As before, additional tags for the destination image can also be provided:
42+
43+
```bash
44+
/cnb/lifecycle/rebaser -previous-image some-original-image -tag some-additional-tag:latest some-destination-image
45+
```
46+
47+
To use this feature, platforms can provide the new `-previous-image` flag to the `rebaser`.
48+
49+
## Builder Author
50+
51+
### Platforms can specify build time environment variables
52+
53+
Builders can include a `/cnb/build-config/env/` directory to define environment variables for buildpacks.
54+
55+
As an example, file `/cnb/build-config/env/SOME_VAR` with contents `some-val` will become `SOME_VAR=some-val` in the buildpack environment.
56+
57+
Files in the `/cnb/build-config/env/` directory can use suffixes to control the behavior when another entity defines the same variable -
58+
e.g., if `/cnb/build-config/env/SOME_VAR.override` has contents `some-builder-val` and `<platform>/env/SOME_VAR` has contents `some-user-val`,
59+
the buildpack environment will contain `SOME_VAR=some-builder-val`.
60+
This is similar to the [environment modification rules for buildpacks](https://github.com/buildpacks/spec/blob/main/buildpack.md#environment-variable-modification-rules),
61+
except that the default behavior when no file suffix is provided is `default`.
62+
63+
The order of application for env directories is:
64+
* Buildpack: `<layers>/<buildpack-id>/<layer>/<env>/`
65+
* User: `<platform>/env/` - overrides buildpack values
66+
* Builder: `/cnb/build-config/env/`
67+
68+
For additional information, see the [buildpack environment](https://github.com/buildpacks/spec/blob/main/platform.md#buildpack-environment) section in the Platform spec.
69+
70+
To use this feature, builder authors should include a `/cnb/build-config/env/` directory with the desired configuration.
Lines changed: 176 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,176 @@
1+
+++
2+
title="Platform API 0.11 -> 0.12"
3+
+++
4+
5+
<!--more-->
6+
7+
This guide is most relevant to platform operators, base image authors, and builder authors.
8+
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.12) for Platform API 0.12 for the full list of changes and further details.
10+
11+
## Platform Operator
12+
13+
### Stacks are deprecated
14+
15+
In Platform 0.12, the concepts of stacks and mixins are removed
16+
in favor of existing constructs in the container image ecosystem such as operating system name, operating system distribution, and architecture.
17+
18+
#### During build
19+
20+
The `-stack` flag is removed from the `analyzer` and `exporter` and replaced with a `-run` flag
21+
that indicates the location of a `run.toml` file with schema:
22+
23+
```toml
24+
[[images]]
25+
image = "<image>"
26+
mirrors = ["<mirror>", "<mirror>"]
27+
```
28+
29+
This file will be created automatically at `/cnb/run.toml` during `pack builder create` if the `pack` version is at least `0.30.0` (see below).
30+
31+
For each image in `[[images]]`, `image` is a tag reference to a run image and `mirrors` contains tag references to its mirrors.
32+
Note that whereas `stack.toml` (removed in this API version) only contained a single run image with mirrors, `run.toml` contains a list of images.
33+
This is because of image extensions and the possibility of run image switching, introduced in Platform 0.10.
34+
For platforms that do not use image extensions, only a single run image with mirrors is needed in `run.toml`.
35+
36+
#### After build
37+
38+
The `stack` key in the `io.buildpacks.lifecycle.metadata` is removed.
39+
To find a tag reference to the run image and mirrors information,
40+
platforms should read the newly added `runImage.image` and `runImage.mirrors` in `io.buildpacks.lifecycle.metadata`.
41+
42+
#### During rebase
43+
44+
Additional validations were added to the `rebaser` along with a `-force` flag to force rebase when validations are not satisfied.
45+
46+
If `-force` is not provided,
47+
* The following values in the image config for the new run image must match the original image config:
48+
* `os`
49+
* `architecture`
50+
* `variant` (if specified)
51+
* `io.buildpacks.base.distro.name` label (if specified)
52+
* `io.buildpacks.base.distro.version` label (if specified)
53+
* If `-run-image` is provided it must be found in `io.buildpacks.lifecycle.metadata` in either `runImage.image` or `runImage.mirrors`
54+
* `io.buildpacks.rebasable` must be `true` (see image extensions below)
55+
56+
### Run image extensions is supported (experimental)
57+
58+
In Platform 0.12, extensions can be used to extend not only build-time base images, but runtime base images as well.
59+
60+
#### During build
61+
62+
To use the feature, platforms should:
63+
* Invoke `analyzer` as usual for Platform 0.12
64+
* Invoke `detector` with the `-run` flag, to specify the location of a `run.toml` file containing run image information
65+
* When extensions switch the run image, this is used to log a warning if the new run image is not a known run image
66+
* Invoke `restorer` with the `-dameon` flag (newly added in this Platform API version) if the export target is a daemon
67+
* When extensions switch the run image, the `restorer` must re-read target data from the new run image in order to provide this information to buildpacks; if `-daemon` is provided the `restorer` will look for the run image in a daemon instead of a registry
68+
* When extensions extend the run image, the `-daemon` flag has no effect as the `restorer` must be able to pull the run image manifest from a registry
69+
* Invoke `extender` as usual to extend the builder image (see [migration guide](/docs/reference/spec/migration/platform-api-0.9-0.10/index.html) for Platform 0.10)
70+
* Inspect the contents of `analyzed.toml` - if `run-image.extend` is `true` we must run the `extender` on the run image
71+
* Using the **run image** as the basis for the container, invoke `extender` with flags `-kind run` and `-extended <extended dir>`
72+
* `<extended dir>` is the directory where layers created from the application of each `run.Dockerfile` to the run image will be saved for use by the `exporter`; it defaults to `<layers>/extended`
73+
* Run image extension may be done in parallel with builder image extension
74+
* Invoke `exporter` with the `-extended` flag
75+
76+
#### After build
77+
78+
Note that unlike buildpack-provided layers, layers from extensions may NOT be safe to rebase.
79+
The `io.buildpacks.rebasable` label on the exported application image will be `false` if rebase is unsafe.
80+
The `-force` flag must be provided to the `rebaser` in order to rebase images with unsafe extension layers,
81+
and should be used with great care.
82+
83+
### The `exporter` no longer deletes cache images
84+
85+
The `exporter` will no longer delete the previous version of the cache image before saving the new version -
86+
which could lead to untagged blobs in the registry.
87+
88+
Platforms should ensure that any untagged blobs are cleaned periodically if their registry does not already support such pruning.
89+
90+
### OCI layout is a supported export format (experimental)
91+
92+
Platform 0.12 adds a new capability to [export application images on disk in OCI layout format](https://github.com/buildpacks/rfcs/blob/main/text/0119-export-to-oci.md).
93+
94+
#### Before build
95+
96+
To use the feature, platforms must prepare a [layout directory](https://github.com/buildpacks/rfcs/blob/main/text/0119-export-to-oci.md#how-it-works) containing input images (`<run-image>` or `<previous-image>` if available) in OCI layout format,
97+
following the [rules](https://github.com/buildpacks/spec/blob/platform/v0.12/platform.md#map-an-image-reference-to-a-path-in-the-layout-directory) to convert the image reference to a path.
98+
99+
#### During build
100+
101+
The feature is enabled by providing a `-layout` flag or by setting the `CNB_USE_LAYOUT` environment variable to `true` for the following lifecycle phases:
102+
103+
- [Analyze](https://buildpacks.io/docs/concepts/components/lifecycle/analyze/)
104+
- [Restore](https://buildpacks.io/docs/concepts/components/lifecycle/restore/)
105+
- [Export](https://buildpacks.io/docs/concepts/components/lifecycle/export/)
106+
- [Create](https://buildpacks.io/docs/concepts/components/lifecycle/create/)
107+
108+
Additionally, the path to the layout directory must be specified, either by providing a `-layout-dir` flag or by setting the `CNB_LAYOUT_DIR` environment variable.
109+
110+
**Note**: [Rebasing](https://buildpacks.io/docs/concepts/components/lifecycle/rebase/) an image exported to OCI layout format
111+
and extending OCI layout base images with Dockerfiles are currently not supported.
112+
113+
## Base Image Author
114+
115+
### Stacks are deprecated
116+
117+
When creating build-time or runtime base images, base image authors should set `io.buildpacks.base.distro.name` and `io.buildpacks.base.distro.version` labels
118+
containing the values specified in `/etc/os-release` (`$ID` and `$VERSION_ID`).
119+
This information - along with operating system, architecture, and architecture variant from the OCI image config,
120+
will be exposed to buildpacks through `$CNB_TARGET_*` environment variables.
121+
122+
Additionally, authors may set an `io.buildpacks.base.id` label on runtime base images to uniquely identify the image "flavor" - see the [Platform spec](https://github.com/buildpacks/spec/blob/main/platform.md#target-data) for further information and requirements.
123+
124+
To allow newer builders to run on older platforms, base image authors should continue to set any `io.buildpacks.stack.*` labels that are still relevant.
125+
Note that "information only" labels such as `io.buildpacks.stack.maintainer` have new equivalents in `io.buildpacks.base.maintainer`,
126+
and it is recommended to set both sets of labels for the time being.
127+
128+
To maintain compatibility with older buildpacks, build-time base images should continue to set `$CNB_STACK_ID` in the build environment.
129+
130+
## Builder Author
131+
132+
### Stacks are deprecated
133+
134+
With the removal of stacks, there is also a new way to reference build-time and runtime base images in `builder.toml`.
135+
Builder authors should ensure their `pack` version is at least `0.30.0` in order to create builders that will work with newer platforms.
136+
137+
The new `builder.toml` schema is:
138+
139+
```toml
140+
[run]
141+
[[run.images]]
142+
image = "cnbs/some-run-image"
143+
mirrors = ["mirror1", "mirror2"]
144+
[build]
145+
image = "cnbs/some-build-image"
146+
```
147+
148+
Run image information will be translated to `run.toml` in the builder with schema:
149+
150+
```toml
151+
[[images]]
152+
image = "cnbs/some-run-image"
153+
mirrors = ["mirror1", "mirror2"]
154+
```
155+
156+
Run image information will also be translated to `stack.toml` (for compatibility with older platforms) in the builder with schema:
157+
158+
```toml
159+
[run-image]
160+
image = "cnbs/some-run-image"
161+
mirrors = ["mirror1", "mirror2"]
162+
```
163+
164+
The old `builder.toml` schema is still valid:
165+
166+
```toml
167+
[stack]
168+
id = "some.stack.id"
169+
run-image = "cnbs/some-run-image"
170+
run-image-mirrors = ["mirror1", "mirror2"]
171+
build-image = "cnbs/some-build-image"
172+
```
173+
174+
If the old `builder.toml` schema is used, run image information will be translated to the same `run.toml` and `stack.toml` file formats as above.
175+
176+
It is possible to define both the new and the old schema within `builder.toml`, but they must be consistent or `pack builder create` will fail.

content/docs/reference/spec/migration/platform-api-0.3-0.4.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ title="Platform API 0.3 -> 0.4"
66

77
This guide is most relevant to platform operators.
88

9-
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.4) for platform API 0.4 for the full list of changes and further details.
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.4) for Platform API 0.4 for the full list of changes and further details.
1010

1111
### Windows support
1212

content/docs/reference/spec/migration/platform-api-0.4-0.5.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ title="Platform API 0.4 -> 0.5"
66

77
This guide is most relevant to platform operators and stack authors.
88

9-
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.5) for platform API 0.5 for the full list of changes and further details.
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.5) for Platform API 0.5 for the full list of changes and further details.
1010

1111
## Platform Operator
1212

content/docs/reference/spec/migration/platform-api-0.5-0.6.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ title="Platform API 0.5 -> 0.6"
66

77
This guide is most relevant to platform operators.
88

9-
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.6) for platform API 0.6 for the full list of changes and further details.
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.6) for Platform API 0.6 for the full list of changes and further details.
1010

1111
## Platform Operator
1212

content/docs/reference/spec/migration/platform-api-0.6-0.7.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ title="Platform API 0.6 -> 0.7"
66

77
This guide is most relevant to platform operators.
88

9-
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.7) for platform API 0.7 for the full list of changes and further details.
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.7) for Platform API 0.7 for the full list of changes and further details.
1010

1111
## Platform Operator
1212

content/docs/reference/spec/migration/platform-api-0.7-0.8.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ title="Platform API 0.7 -> 0.8"
66

77
This guide is most relevant to platform operators.
88

9-
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.8) for platform API 0.8 for the full list of changes and further details.
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.8) for Platform API 0.8 for the full list of changes and further details.
1010

1111
## Platform Operator
1212

content/docs/reference/spec/migration/platform-api-0.8-0.9.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ title="Platform API 0.8 -> 0.9"
66

77
This guide is most relevant to platform operators.
88

9-
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.9) for platform API 0.9 for the full list of changes and further details.
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.9) for Platform API 0.9 for the full list of changes and further details.
1010

1111
## Platform Operator
1212

content/docs/reference/spec/migration/platform-api-0.9-0.10.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ title="Platform API 0.9 -> 0.10"
66

77
This guide is most relevant to platform operators.
88

9-
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.10) for platform API 0.10 for the full list of changes and further details.
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.10) for Platform API 0.10 for the full list of changes and further details.
1010

1111
## Platform Operator
1212

@@ -71,11 +71,11 @@ Note: image extensions are not supported for Windows container images.
7171
* To create a builder with extensions, ensure the `pack` version in use is at least `0.28.0` and enable experimental features: `pack config experimental`.
7272
* Enable experimental features in the lifecycle by setting `CNB_EXPERIMENTAL_MODE=warn` or `CNB_EXPERIMENTAL_MODE=silent` in the lifecycle execution environment for ALL lifecycle phases
7373
* Invoke `analyzer` as usual
74-
* Invoke `detector` with a new optional argument: `-generated`, to specify the directory where Dockerfiles generated by image extensions will be output (defaults to `<layers>/generated`) and include image extensions in `order.toml`
74+
* Invoke `detector` with a new optional flag: `-generated`, to specify the directory where Dockerfiles generated by image extensions will be output (defaults to `<layers>/generated`) and include image extensions in `order.toml`
7575
* Dockerfiles for customizing the build image can be found in `<generated>/build/<image extension ID>/Dockerfile`
7676
* Dockerfiles for customizing the run image can be found in `<generated>/run/<image extension ID>/Dockerfile`
7777
* The new run image will be written to `analyzed.toml`
78-
* Invoke `restorer` with a new required argument (when using extensions): `-build-image`, a tag reference to the builder image in use
78+
* Invoke `restorer` with a new required flag (when using extensions): `-build-image`, a tag reference to the builder image in use
7979
* A new volume mount is introduced with target `/kaniko`; this volume must be writable by the `restorer` user
8080
* Invoke `extender` (new lifecycle binary), instead of `builder`; the extender will use kaniko to apply the relevant generated Dockerfiles to the build image and then drop privileges to run the `build` phase
8181
* The same volume from `restore` should be mounted at `/kaniko`

0 commit comments

Comments
 (0)