58 lines
1.5 KiB
Markdown
58 lines
1.5 KiB
Markdown
---
|
|
title: Container Image Workflows at Scale with Buildpacks
|
|
weight: 5
|
|
---
|
|
|
|
A talk by Broadcom and Bloomberg (both related to buildpacks.io).
|
|
And a very full talk at that.
|
|
|
|
## Baselinbe
|
|
|
|
* CN Buildpack provides the spec for buildpacks with a couple of different implementations
|
|
* Pack CLI with builder (collection of buildopacks - for example ppaketo 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
|
|
|
|
```mermaid
|
|
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
|