1.6 KiB
1.6 KiB
title | weight | tags | ||
---|---|---|---|---|
Container Image Workflows at Scale with Buildpacks | 5 |
|
A talk by Broadcom and Bloomberg (both related to buildpacks.io). And a very full talk at that.
Baseline
- CN Buildpack provides the spec for buildpacks with a couple of different implementations
- Pack CLI with builder (collection of Buildpacks - for example Paketo or Heroku)
- Output images follow OCI -> Just run them on docker/Podman/Kubernetes
- Built images are
production application images
(small attack surface, SBOM, non-root, reproducible)
Scaling
Builds
- Use in CI (Jenkins, GitHub Actions, Tekton, ...)
- KPack: Kubernetes operator -> Builds on new changes
Multiarch support
flowchart LR
subgraph OCIImageIndex
lamd(linux/amd64)
larm(linux/arm64)
end
larm-->imageARM
lamd-->imageAMD
subgraph imageARM
layer1.1
layer2.1
layer3.1
end
subgraph imageAMD
layer1.2
layer2.2
layer3.2
end
- Goal: Just a simple docker full that auto-detects the right architecture
- Needed: Pack, Lifecycle, Buildpacks, Build images, builders, registry
- Current state: There is an RFC to handle image index creation with changes to Buildpack creation
- New folder structure for binaries
- Update config files to include targets
- The user impact is minimal, because the builder abstracts everything away
Majority
- kpack is slsa.dev v3 compliant (party hard)
- 5 years of production
- scaling up to Tanzu/Heroku/GCP levels
- Multiarch is being worked on