Skip to content

Latest commit

 

History

History
86 lines (59 loc) · 3.59 KB

0000-additional-exported-layers.md

File metadata and controls

86 lines (59 loc) · 3.59 KB
Raw

Meta

  • Name: Additional exportable layers
  • Start Date: 2021-08-13
  • Author(s): @samj1912
  • RFC Pull Request: (leave blank)
  • CNB Pull Request: (leave blank)
  • CNB Issue: (leave blank)
  • Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC)

Summary

Allow users to provide additional volumes that can be exported similar to the application directory and allow easy configuration of the application directory. These volumes are defined via the buildpack.exportable-volumes by each buildpack.

Definitions

  • exportable-volumes: A set of volumes describing where the buildpack process is likely to write data specific and should be exported alongside the application workspace.

Motivation

The main motivation behind this RFC is to unlock exporting application images that require libraries or software to be installed in certain directories apart from the default application directory and these installations are rebase safe and self-contained. This unlocks use cases where buildpacks may install software in /opt directories (for AWS Lambda extensions or other common standalone software) for example or preserve some settings in a /home/$USER/.config for the output application. This provides a rebase safe extension point without major changes to the buildpacks API.

What it is

Buildpack authors would be able to buildpacks with buildpack.exportable-volumes keys in their buildpack.toml files.

For example a a buildpack may look like -

api = "<buildpack API version>"

[buildpack]
id = "<buildpack ID>"
name = "<buildpack name>"
exportable-volumes = ["aws-extensions", "user-config-dir"]

The above would only be valid for normal buildpacks and not meta-buildpacks. Based on the exportable-volumes field, a platform would be responsible for validating that the build and run image do not have any content on these paths. By default these volume names will map to /workspaces/<exportable-volume-name> but a user may specify a label io.buildpacks.exportable-volumes on the build image to map a volume name to a different location. This label would look like -

[
    {"name": "user-config-dir", "value": "/home/cnb/.config"},
    {"name": "aws-extensions", "value": "/opt"}
]

For volumes defined by buildpacks but not in the io.buildpacks.exportable-volumes we will use a default /workspaces/<exportable-volume-name> directory.

How it Works

This RFC would require changes to the lifecycle and platform API.

The lifecycle would be responsible for creating symlinks from /workspaces/<exportable-volume-name> in the build image to the actual mapped directory and make these writable for buildpacks. It will also be responsible for exporting the content on these directories to the actual paths on the run-image.

The current default workspace directory would be moved to /workspaces/default but the lifecycle will symlink that directory back to /workspace for backwards compatibility.

Drawbacks

  • Additional complexity

Alternatives

N/A

Prior Art

Unresolved Questions

TBD.

Spec. Changes (OPTIONAL)

As noted above.