kubecon24/content/day3/05_buildpacks.md
2024-03-26 15:43:47 +01:00

63 lines
1.7 KiB
Markdown

---
title: Container Image Workflows at Scale with Buildpacks
weight: 5
tags:
- images
- platform
---
{{% button href="https://youtu.be/cenTw6WzQv8" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}}
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
```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