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

RFC: Dynamic Runtime Base Image Selection #174

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 54 additions & 0 deletions text/0000-run-image-selection.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# Meta
[meta]: #meta
- Name: Dynamic Runtime Base Image Selection
- Start Date: 2021-06-30
- Author(s): sclevine
- RFC Pull Request: (leave blank)
- CNB Pull Request: (leave blank)
- CNB Issue: (leave blank)
- Supersedes: [RFC0069](https://github.com/buildpacks/rfcs/blob/main/text/0069-stack-buildpacks.md), [RFC#167](https://github.com/buildpacks/rfcs/pull/167), many others
- Depends on: [RFC#172](https://github.com/buildpacks/rfcs/pull/172)

# Summary
[summary]: #summary

*NOTE: This proposal is part of a larger initiative to reduce complexity originally outlined in https://github.com/buildpacks/rfcs/pull/167*

This RFC introduces functionality for dynamically selecting runtime base images, as a partial alternative to stackpacks (along with [RFC#173](https://github.com/buildpacks/rfcs/pull/173)).

# Motivation
[motivation]: #motivation

- Buildpacks on the same builder may have different OS package requirements.
- OS package requirements may vary based on the type of application.

# What it is
[what-it-is]: #what-it-is

This RFC proposes that we allow buildpacks to select a minimal runtime base image during detection.

# How it Works
[how-it-works]: #how-it-works

Builders may specify an ordered list of runtime base images, where each entry may contain a list of runtime base image mirrors.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we include an example of what this would look like?

[[stacks]]
id = "centos"
build-image = "example/centos7-build:123"
run-image = "example/centos7-run:123"

[[stacks]]
id = "bionic"
build-image = "example/ubuntu-build:123"
run-image = "example/ubuntu-run:123"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do


Buildpacks may specify a list of package names (as [PURL URLs](https://github.com/package-url/purl-spec) without versions or qualifiers) in a `packages` table in the build plan during detection.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that the lifecycle needs to be able to inspect a base image and determine what packages it includes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, just like it works with mixins and buildpack.toml today.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But does this mean it needs to be aware of how to do that on a particular stack (apt, yum, etc)? With mixins it can do this generically.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PURL URLs in the CycloneDX-formatted SBoM provide a generic abstraction for this.


The first runtime base image that contains all required packages is selected. When mirrors are present, the runtime base image mirror matching the app image is always used, including for package queries.

# Drawbacks
[drawbacks]: #drawbacks

- Involves breaking changes.
- Buildpacks cannot use this mechanism to install OS packages directly, only select runtime base images.

# Alternatives
[alternatives]: #alternatives

- Stackpacks
- Only allow app developers to install OS packages (using Dockerfiles via [RFC#172](https://github.com/buildpacks/rfcs/pull/172))

# Unresolved Questions
[unresolved-questions]: #unresolved-questions

- Should packages be determined during the detect or build phase? Opinion: detect phase, so that a runtime base image's app-specified Dockerfiles may by applied in parallel to the buildpack build process.