►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Building Multi-Architecture Images With Buildpacks - Aidan Delaney, Bloomberg
Buildpacks transforms source applications into images that run on any cloud. We will introduce the key architecture of Buildpacks and explain the separation of concerns between the buildpack and the platform API. In addition, we will take a deeper dive into two platform implementations. We deep-dive into a stand-alone buildpack builder (pack) and a Kubernetes native buildpack service (kpack), detailing how both use the lifecycle component to build source applications into images.
Having established a deeper understanding of how a platform works, we workshop approaches to supporting multi-architecture builds. It is increasingly common for developers to require their application to run on both x86_64 and ARM64. The current platform specification maps a platform onto a single architecture and implementations build x86_64 images on x86_64 build platforms and ARM64 images on ARM64 platforms. We ask how applications can be built on x86_64 and produce images for both x86_64 and ARM64? Are the necessary changes to the platform and Buildpacks APIs backward compatible? Is it feasible for pack and kpack to produce muti-architecture output?
A
Surprisingly
or
I,
don't
know
what
I
don't
really
have
any
answers
in
this
talk,
but
I
would
like
to
ask
a
lot
of
questions,
but,
firstly,
as
I
said,
I
kind
of
got
to
introduce
myself
and
then
I'd
like
to
get
a
picture
of
your
general
knowledge
of
of
build
packs.
I've
spoken
to
some
people
already
just
to
see
where
things
are.
B
A
As
I
mentioned,
I'm
Aiden
I'm
part
of
a
team
in
Bloomberg
that
develops
app
or
platforms
on
which
are
AI
engineers
at
Bloomberg,
depend
and
for
us.
Bill
packs
are
a
critical
component
because
they
allow
the
Bloomberg
AI
Engineers
to
achieve
High
Velocity
when
they
iterate
on
experiments
so
I'm
also
a
bill.
Paxterio
team
lead
where
I
mostly
help
with
documentation.
So
if
you
find
any
problems
with
the
documentation,
you
can
just
shout
at
me
in
this
talk.
I
want
to
give
a
brief
overview
on
the
state
of
Bill
Pax
in
2022.
A
The
key
Focus,
though,
is
to
accelerate
the
discussion
around
multi-architecture
images
and
to
encourage
kind
of
design
questions
around
it.
So
I've
spoken
to
some
of
you,
but
could
I
get
maybe
a
hands
up
if
you're
kind
of
interested
in
build
packs,
but
haven't
yet
done
very
much
with
them?
Oh
wow,
interesting!
That's
over
half
the
talk
so
certainly
I've
got
some
stuff
in
this
talk.
Certainly
early
on
that
will
hopefully
wet
your
appetite,
and
you
can
talk
to
me
later
about
more
details
of
the
buildbacks.io
booth
hands
up
here.
A
If
you've
got
a
reasonable
amount
of
experience
with
Bill
packs.
There's
a
couple
of
people
here
whose
ways
of
amount
of
experience,
okay,
great
I'm,
certainly
going
to
be
leaning
on
those
of
you
to
contribute
to
the
this
talk
or
the
questions
later
on
and
then
I
do
recognize
some
faces,
Stephen
and
Max.
You
are
the
season,
build
packs
users,
but
are
there
any
kind
of
seasoned
Bill
packed
veterans
out
there
in
the
audience?
A
Oh
you're,
hiding
in
the
back
there
fantastic
Matt,
you
just
Matt's,
giving
me
kind
of
half
yeah
he's
only
a
k-pak
developer,
but
hey.
So
what
are
build.
Packs
is
kind
of
an
interesting
question
to
ask
in
the
first.
The
way
I
like
to
talk
about
build
packs
is
to
say
that
there
are
a
declarative
way
to
translate
application
source
code
into
a
production.
Image
right
and
I
can
give
you
hopefully
a
little
demo
of
what
I
mean
by
this
I'm
going
to
start
with
a
fairly
standard,
hello,
world
python
project.
A
What
I'm
going
to
do
is
what
am
I
going
to
do,
I'm
going
to
CD
into
the
directory
and
then
I'm
going
to
eventually
run
pack
a
CLI
tool
to
build
the
output
image
so
again,
I've
started
with
a
standard
python
project.
I've
run
the
pack
Tool.
The
build
pack
process
will
introspect
your
project
source
code
to
determine
to
determine
what
build
packs
contribute
to
the
build
and
then,
during
the
build
phase
a
bit
later
on
what
it
tends
to
do
or
build
packs
kind
of
commonly
do.
Is
they
provide
an
application
runtime?
A
In
this
case,
it's
going
to
be
a
python
runtime.
They
install
application
dependencies.
In
this
case,
it's
going
to
be
installing
some
pip
dependencies
that
were
in
the
requirements.txt
file,
and
then
it's
got
to
apply
some
kind
of
configuration
settings
in
this
case,
I've
used
a
Heroku
style
proc
file.
So
it's
going
to
configure
an
entry
point
into
my
image
using
that
that
proc
file-
if
you
don't
know
what
the
Pro
Crystal
proc
file
is,
you
can
talk
to
me
later
or
ask
a
question
about
it.
A
A
The
builds
are
replicatable,
meaning
that
if
you
rebuild
an
image
using
the
same
application
source
with
the
same
dependencies
with
the
exact
same
dependencies,
it
leads
for
to
a
byte
for
byte
reproducible
image.
This
is
important
in
some
regulated
Industries
yeah.
We've
also
got
a
nice
property
of
build
packs,
the
idea
of
being
rebasable
the
ability
to
switch
out
our
run
image
with
a
small
registry
update.
A
If
you
want
to
talk
about
rebase
or
see
in
a
bit
more
depth,
have
a
visit
of
the
build
pack
spoof
later
I'm
not
going
to
go
into
it
in
this
talk.
But
it
is
a
really
neat
operation,
so
build
packs
or
more
properly
known
as
Cloud
native
buildpacks
is
a
cncf
project.
Go
team
cncf
come
on
people,
don't
want
to
get
it
yet
yay
right,
Cloud
native,
build
packs
are
the
third
generation
of
an
approach
that
was
originally
pioneered
by
kind
of
Heroku
and
people
are
pivotal
about
a
decade
ago.
A
So
the
ideas
that
are
in
this
have
been
around
for
a
long
time.
We
do,
though,
have
some
really
nice
emerging
features
in
2022
we
have
started,
or
we've
actually
released,
some
experimental
support
to
configure,
build
and
run
images
using
a
restricted,
Docker
file.
Syntax,
which
is
quite
neat.
We've
got
some
better
support.
This
quarter
for
user
profiles
on
an
image
and
there's
hopefully
soon
some
easier,
tooling.
A
To
start
writing
new
build
packs
coming
on
stream,
but
in
addition
to
the
individual,
open
source
contributions
we
have
had
in
this
quarter
contributions
from
13
different
companies,
which
shows
you
that
it
is
a
a
live
project
with
a
lot
of
different
contributors
from
multi,
multiple
vendors.
So
it
is,
you
know
it's
precisely
what
we'd
like
to
see
in
a
cncf
project
being
multi
multi-vendor.
A
A
A
A
For
them,
obviously,
we
provide
the
specifications.
We
provide
the
specification
of
the
of
the
platform
and
we
provide
a
library,
lib,
CNB
library
and
go
which
allows
them
to
write,
build
packs
for
their
end.
Users,
Python
and
rust.
Lib
CNB,
like
bindings,
are
available
from
from
other
sources,
and
you
can
also
write
build
packs
in
in
bash
or
the
technology
that
of
your
choice.
A
A
It's
currently
maintained
by
VMware
as
an
open
source
project
and
I
kind
of
questionally,
going
to
look
at
new
here
and
say
that
cloud
foundries
coreify
is
derived
from
kpac
or
based
on
kback
kind
of
maybe
nothing
he's
kind
of
nodding.
I
gotta.
Take
that
as
confirmation
other
platforms
are
pack,
it's
a
command
line
tool
provided
by
us
at
buildpax.io
on
the
CMB
project
and
the
pack
tool
is
used
with
a
lot
of
other
projects.
It's
used
quite
often
in
GitHub
actions.
It's
used
in
circle,
CI.
A
It's
used
on
a
lot
of
places
where
build
packs
are
used
to
build
an
image,
Tech
tones
and
open
source
CI
CD
platform.
It's
maintained
by
The,
Continuous
delivery.
Foundation
spring
boots,
interestingly,
is
also
a
build
packs
platform.
They
use
the
build
pack
steps
underneath
to
Output
an
oci
image
for
your
spring
application
and
then
there's
other
platforms
out
there.
Salesforce
is
functions,
uses
build
packs
to
power,
their
functions
as
a
service
platform.
A
A
A
The
Salesforce
people
have
Heroku
no
Bill
packs
for
Heroku,
which
Target
the
Heroku
cloud
or
the
Heroku
platform.
Google
has
a
set
of
build
packs
that
they've
authored,
which
largely
targets
Google
Cloud,
run
and
the
VMware
folk
have
a
set
of
build
packs
which
are
some
of
them,
are
derived
from
the
paquetto
build
packs
and
they
target
vmware's
tanzu
Cloud
platform.
A
A
So,
interestingly,
most
end
users
will
interact
with
a
platform
like
Pac
or
kpac,
rather
than
interacting
with
with
the
build
packs
themselves
and
yeah.
Suppose
we
have
that
hello
world
python
application
and
we
like
how
the
piketo
build
packs,
for
example,
build
python
applications.
Well,
we
tell
pack
to
use
and
Trust
the
piquetto
Builder,
which
is
what
you
saw
in
the
demo
earlier.
I
had
a
pack
build
example
and
I
passed
in
a
builder
as
a
command
line
flag,
which
was
the
paquero
Builder
and
most
Builders
contain
four
things.
A
A
A
It
mounts
the
application
source
code
and
does
whatever
the
mounting
it
needs
to
do,
and
then
it
invokes
the
build
pack
steps
in
a
particular
order,
and
that
order
is
the
order
that
they're
given
here
we
start
with
the
analyze
step
and
the
key
role
of
the
analyze
step
is
pretty
much
just
to
bug
out
early.
If
you
don't
have
access
to
read
and
write
to
a
registry.
So,
for
example,
we
don't
want
to
perform
a
full
build
if
we
can't
access
the
Run
image
on
your
registry.
A
Now
I've
colored,
as
you
can
see,
the
detect
step
in
pink,
like
I've,
called
the
build
step
and
think
because
these
are
generally
of
more
interest
to
the
buildpax
end
users
in
the
detect
phase.
What
happens
is
that
each
individual
build
pack
provides
its
own
detect
binary
the
detect,
build
step,
runs
the
detect
binaries
of
each
build
pack
and
finds
out
which
build
pack
can
which
build
packs
contribute
to
the
build.
A
Now,
we've
seen
this
in
the
demo
earlier,
if
I
scroll
back
up,
you
can
see
that
one
of
the
first
phases
is
the
detect
and
that
in
this
this
Builder
contains
a
number
of
images
that
are
build,
packs
that
I
can't
read
what
does
it
say
over
there?
On
the
left
hand,
side,
how
many
images
are
build
packs?
A
Does
this
Builder
contain
see
nine,
but
only
six
of
them
contribute
to
the
build,
so
the
detect
phase
of
all
nine
has
run,
but
only
six
of
them
have
recognized
that
this
is
a
python
project
and
that
we
need
to
contribute
builds
are
part
of
the
build
for
this
python
project.
The
other
three
are
node.js,
build
packs
and
obviously
a
node.js
build
pack
a
related
build
pack,
don't
contribute
to
a
python
budget,
fantastic.
A
Cool
so
finds
out
what
could
build
packs
contribute
to
the
build,
and
then
it
outputs
at
the
end
of
this
stage,
a
build
plan
and
a
build
order
for
running
the
build
packs
in
there
is
a
restore
phase
which
is
next
and
Bill
pack
support
cashing
out
at
many
levels,
I'm
not
going
to
go
into
the
depths
of
this.
In
this
talk,
particularly
because
of
the
the
variety
of
caching
techniques
that
can
be
implemented
in
build
packs,
but
the
restore
phase
restores
previously
cached
layers
from
volumes
or
from
a
registry.
A
Next
phase
is
the
build
phase,
and
this
is
a
particularly
interesting
one
to
those
us
end
users.
It
takes
the
build
order
computed
by
the
detect
phase
and
then
each
bill
pack.
Each
individual
build
pack
contributes
a
build
binary
and
the
build
process
executes
the
build
binary
of
each
build
pack
in
the
order
given
in
the
build
order.
So
I
think
some
details
here
are
probably
a
little
bit
appropriate.
A
You
can
see
the
build
order
that
I've
kind
of
put
in
the
middle
of
this
diagram,
and
what
we
can
see
is
that
the
each
build
pack
is
is
executed
in
the
build
order.
That's
given
and
the
input
to
each
individual
build
pack
is
a
subset
of
the
bill
plan
that
is
useful
to
that
particular
build
pack.
We'll
call
this
a
build
pack
plan.
A
So,
in
the
case,
in
this
particular
case,
there's
kind
of
a
python
distribution
pill.
Pack
that
contributes
a
c
python
runtime
to
the
as
a
layer
to
the
image.
There's
a
pip
install
build
pack,
that's
going
to
contribute
at
least
a
layer
containing
the
application
dependencies,
probably
some
caching
stuff
as
well,
which
I'm
completely
ignoring
right
now
and
then
there's
the
proc
file
build
pack,
which
is
contributor
layer
containing
the
entry
point
of
the
application
and
in
all
cases,
a
full
software
bill
of
materials
is
provided
for
each
layer.
A
Finally,
we've
got
the
kind
of
export
phase
and,
given
all
the
layers
produced
by
the
build
phase,
the
export
phase
produces
an
oci
image
on
top
of
the
Run
image.
That
was
a
part
of
the
Builder.
Not
all
the
layers
are
exported
as
part
of
the
image
you
know,
I
have
ignored
some
details.
There
may
be
caching
layers.
There
may
be
build
only
layers,
those
are
not
exported
as
part
of
the
image,
but
they
may
be
used
for
speeding
up
rebuilds
in
future,
and
the
export
phase
doesn't
show
that
the
cache
layers
are
correctly
cached.
A
Now
I
get
to
talk
about
something
really
really
exciting,
but
I've
only
got
to
touch
on
it
and
the
person
you
really
need
to
bug
about
this
is
a
person
called
Natalie
at
the
buildpacks.io
booth.
Now
I've,
given
you
one
slide
here
on
this,
but
this
feature
has
taken
many
months
to
implement
so
I'm
really
underselling
her
work
here,
but
we
released
this
month
a
new
experimental
feature
and
the
feature
adds
new
build
steps
which
allows
us
to
extend,
build
and
run
images.
The
input
to
the
extended
phase
is
a
very
restricted
Docker
file.
A
We
certainly
do
not
allow
and
don't
intend
to
allow
the
full
syntax
and
expressiveness
of
Docker
files,
but
currently
the
Restriction
already
allows
you
to
change
the
Run
image.
The
way
we've
currently
implemented
it.
So
we
expect
to
increase
the
subset
of
dockerfile
syntax
that
we
do
support
and
going
forward.
A
A
The
build
packs
themselves
are,
you
know,
primarily
designed
and
they're,
implemented
and
tested
are
to
run
on
AMD
64.
I'm,
going
to
use
the
kind
of
go
names
for
these
platforms,
so
AMD
64.
What
we
might
know
is
x8664
and
other
terminology,
so
the
piqueto,
the
sales
force,
the
Google,
the
tanzu
and
our
build
packs.io
billpacks
all
support,
Linux
and
AMD
64
and
are
all
tested
in
for
that.
It
is
unfortunately
not
the
same
case
for
Linux
on
arm
64..
A
We
find
that
still
that
pack
life
cycle
the
build
and
run
images
on
our
are
available
on
arm
64,
for
from
many
providers
of
build
packs,
but
in
general
sorry,
but
in
general,
there's
only
partial
support
for
Linux
and
arm
64
from
pretty
much
any
of
the
providers
of
build
packs,
and
the
question
is:
why
would
be
we
be
interested
in
this?
In
the
first
place?
Why
are
we
interested
in
kind
of
AMD,
64
and
arm
64.?
A
Well,
as
I
said,
you
know,
the
platforms
on
K-POP
are
pack
and
kpac
are
released
on
multiple
architectures.
However,
with
this
talk,
we're
particularly
interested
in
the
output
image
and
many
of
us
are
interested
in
deploying
output
applications
on
both
AMD
64
and
arm
64..
This
is
largely
because
the
cloud
providers
currently
support
both
of
these
Hardware
platforms.
So
you
can,
you
know
you
can
get
a
server
from
a
a
cloud
provider
that
is
an
arm64
server.
A
If
we
have
support
for
two
platforms,
our
AMD
64
now
I'm
64,
then
in
future
it
should
be
easier
to
support
other
platforms
like
some
kind
of
mips
64
platform,
and
it's
also
the
case
that
Developers
at
the
moment
have
AMD,
64
or
arm
64
laptops.
This
nice
shiny,
new
Mac
M1
that
I
have
is
an
arm
64
machine
and
we'd
like
to
make
the
development
process
experience
as
neat
and
efficient
for
developers
using
non-amd,
64,
Hardware.
A
So
how
do
we
go
about
supporting
multi-architecture
at
buildpax?
Is
it
simply
the
case
that
if
we
provide
arm
64
build
packs,
then
the
problem
is
solved?
Well,
I
kind
of
want
to
think
about
the
problem
from
the
perspective
of
each
of
our
three
user
groups
from
the
perspective
of
an
application
developer,
an
application
developer,
as
we
figured
out
before
just
wants
to
build
a
production
image,
and
it
seems
reasonable
to
provide
some
way
for
the
application
developers
to
choose
an
output
image
architecture
in
this
case
I've.
A
A
You
know
podman
run
BusyBox
or
Docker
run
busy
box
and
the
container
engine
chooses
the
most
appropriate
image
for
their
particular
platform,
so
in
general
we
can
produce
multi-architecture
images
by
providing
manifest
lists
and
the
Manifest
list.
On
the
left
hand,
side
of
this
diagram
is
a
list
of
manifests
with
the
platform
metadata
and
from
the
Manifest
list.
You
can
find
the
image
for
your
platform,
so
this
is
all
part
of
the
oci
specification
for
images
that
we
all
know
and
love
that
we've
all
been
running
for
probably
many
years
at
this
stage.
A
From
the
perspective
of
billpack
authors,
though,
the
question
becomes
a
little
bit
more
complex
and
I'm
aware
that
many
there
aren't
many
of
us
in
the
room
who
are
build,
packs,
authors
or
who
want
to
be
buildbox
authors,
but
Bill
Peck's
authors
do
need
to
support
language
specific
technology
stacks,
for
example,
build
pack.
Authors
might
want
to
provide
a
list
or
a
set
of
build
packs
to
support
applications
written
in
go
now.
The
go
ecosystem
is
designed
to
really
smoothly
support
this
multi-architecture
use
case,
which
is
great.
A
However,
it's
not
the
case
if
you're
providing
a
set
of
build
packs
that
support
python
or
node.js
or
Ruby,
or
even
Java
or
other
technology
stacks,
for
example,
the
if
you're
providing
python
build
packs
that
provide
a
python
runtime,
you
need
to
have
a
python
runtime,
that's
available
for
your
AMD
64
and
your
arm
64
platform.
It's
also
the
case
that
you
know
build
packs,
contribute
that
contribute
dependencies
and
they
need
to
be
aware
of
architectural
differences.
A
A
So
of
the
three
classes
of
build
pack
users
platform
operators,
these
people
who
run
a
build
our
kpac
instance,
for
example?
They
need
to
figure
out
how
to
support
multi-architecture,
build
packs
to
build
multi-architecture
images.
Build
pack.
Authors
I
want
a
probably
want
a
mechanism
to
distinguish
architectures
and
then
actually
test
their
build
packs
on
multiple
architectures
and
finally
last,
but
the
most
important
class
of
user
application
developers
need
only
be
aware.
A
Probably
of
the
architectures
that
their
platform
is
intended
or
their
application
is
intended
to
support
I'm
I'm,
going
to
argue
that
there
are
kind
of
three
main
approaches
to
considering
generating
multi-architectures
images.
There's
a
cross
compilation,
approach,
an
emulation
approach
and
a
bare
metal
approach
and
again,
if
you're
new,
to
build
packs.
Maybe
this
kind
of
next
four
or
five
minutes
of
the
talk
is
going
to
not
particularly
apply
to
you,
but
you
know.
Hopefully
we
learned
something
fun
anyway,
10
minutes.
Thank
you
very
much
at
the
end
of
this
entire
process.
A
Whatever
implementation
week
Technique
we
use,
we
want
something
that
I'm
going
to
diagram
like
this
I'm
going
to
present
it
like
this.
We
want
an
image
manifest
list
and
we
want
that
image
manifest
list
to
point
at
architecture,
specific
images,
but
in
this
instance
we
want
architecture,
specific
layers,
the
Run
image
for
md64
and
I
wrote
a
limit
for
AMD
64..
We
want
architecture,
specific
layers
on
top
of
those,
but
we
also
might
want
to
be
able
to
share
some
non-architecture
specific
layers
between
the
two
images.
A
So
what
would
happen,
or
how
would
we
do
go
about
doing
this
if
we
use
the
cross
compilation
process
so
in
this
diagram,
I've
drawn
kind
of
a
representation
of
the
Builder
on
top
which
I
introduced
a
bit
earlier,
I've
drawn
below
that
in
the
bottom
left
hand
corner
a
representation
of
how
packed,
in
this
case,
I've
chosen
one
platform.
It
might
execute
the
build
steps
or
some
of
the
build
steps
and
I'm
using
that
kind
of
stacked
image.
A
Layers
diagram
in
the
in
the
bottom
right
hand,
corner
to
represent
the
output
image,
and
assuming
that
we
have
an
AMD
64
host
machine,
we
might
only
need
to
provide
a
single
amd64
Builder,
which
points
to
the
Run
image
for
each
which
points
to
multiple
Run
images,
one
for
each
output
architecture
and
the
host
build
packs
could
cross,
compile
native
dependencies
for
the
Target
run
architecture.
So
internally,
a
platform
like
Pac
could
run
a
single
detect
process
and
then
wouldn't
build
an
export
process
per
Target
architecture.
A
In
short,
though,
click
yay,
the
cross
compilation
approach
is
most
simple
for
platform
operators.
It's
probably
most
simple
for
the
people
that
we
probably
don't
need
to
simplify
the
process.
For
the
course
compilation
approach
really
does
probably
make
life
difficult
for
end
users
who
may
find
that
their
native
dependencies
or
their
python
apple
or
python
dependencies
which
have
NATO's
dependencies
simply
don't
cross,
compile
putting
them
in
the
situation
where
they
have
to
talk
to
the
Upstream
developers
to
make
things
easily
cross
compile.
A
What
did
we
use
kind
of
an
emulation
in
place
of
cross
compilation?
Suppose
again
we're
on
the
amd64
machine
and
the
Builder
image
then
requires
a
run
image
per
Target
architecture,
a
set
of
build
packs
for
per
Target
architecture.
So
the
Builder
itself
is
now
effectively
composed
of
two
different
builders
and
a
life
cycle,
binary
per
Target
architecture.
A
Unlike
the
case
in
the
emulator
approach,
we
need
a
builder
to
provide
this
effectively
two
different
Builders.
So
a
single
Builder
image
that
that
points
to
two
different
builders
and
where
the
bare
metal
approach
differs,
is
that
the
platform
needs
to
coordinate
building
between
two
different
hosts.
A
Now
again,
what's
clear
in
this
case?
Is
that
using
multiple
bare
metal
holes
will
introduce
new
failure
modes
for
platforms
that
we
may
not
may
or
may
not
want
to
to
to
consider
to
put
into
a
platform,
that
is
to
say,
the
platform
now
has
to
deal
with
the
networking
failures
when
talking
to
multiple
bare
metal
hosts,
and
this
can
impact
both
end
users
and
platform
operators.
A
However,
end
users
in
this
case
would
benefit
from
native
compilation,
speeds
on
all
platforms,
which
is
certainly
a
bonus.
So
to
summarize
all
this,
oh
I
need
to
look
at
this
slide.
What
I've
done
so
far
is
kind
of
outline
the
build
packs
process.
So
hopefully
those
of
you
who
are
in
need
to
build
packs
I've
learned
a
little
bit
about
the
buildbox
process,
I.
A
Briefly,
all
too
briefly
consider
the
new
extender
functionality
which
has
taken
us
months
to
develop
and
is
really
a
cool
piece
of
functionality
and
I've
presented
three
approaches
to
implementing
multi-architecture
image
builds,
that
is
cross,
compilation,
Hardware
emulation
or
the
bare
metal
approach
of
having
multiple
hosts
and
why
I've
done
this
is
because
I
want
to
accelerate
this
discussion
around
multi-architecture
images,
as
I
said,
I
have
no
actual
Solutions
in
this
talk.
I
really
only
have
questions.
A
A
This
is
independent
of
the
approach
that
we
take
to
generate
the
multi-architecture
images,
no
matter
which
of
these
three
approaches
we
choose,
we
still
have
to
generate
multi
oci,
manifest
indexes
and,
depending
on
the
approach
that
we
choose,
platforms
may
need
to
consume
multi-architecture
builders
and
nicely
after
a
conversation
yesterday
with
Steve
and
I.
Think
we're
closer
to
this
goal
than
I
originally
thought
we
were
when
I
started.
Writing
this
talk.
So
where
does
that
leave
us?
A
Well,
we
want
your
opinions,
people
there
are
links
here
to
to
GitHub
issues
that
discuss
different
aspects
of
the
multi-argate
of
multi-architecture
images.
Please
visit
these
give
us
your
opinion,
give
us
some
feedback
and
if
you
get
there,
that's
where
I
can
talk.
If
GitHub
isn't
your
communication
tool
of
choice
then
find
us
at
the
buildpacks.io
booth
where
we
can
see
you
face
to
face
and
talk
with
you.
A
Finally,
thank
you
very
much
for
your
time.
I
hope
this
is
the
start
of
a
conversation,
and
you
know
if
you
can't
visit
the
bill.
Pax
Booth,
please
catch
up
with
us
async,
either
on
the
bill.
Packs
community
on
slack
on
the
cncf
slack
on
Twitter
or
you
know,
contribute
some
code
on
GitHub.
Thank
you
very
much
for
your
time.
A
A
Right,
the
question
is:
why
would
I
want
to
use
something
like
build
packs
as
opposed
to
Docker
files?
It's
it's
a
common
question
that
we
get
I'm
going
to
give
you
the
kind
of
one
minute
answer.
Docker
files
are
great
I
really
liked
what
they
do.
What
I
have
found,
or
what
many
of
us
have
found
is
that
if
we've
got
tens
or
hundreds
of
projects,
it
then
becomes
difficult
to
maintain
sometimes
difficult
to
maintain
Docker
Falls,
particularly
as
things
change
over
time.
A
So,
for
example,
python36
has
recently
fallen
out
of
support,
I
think
and
what
we'd
like
to
do
is
upgrade
all
the
applications
that
use
python36
to
at
least
python37.
Now
in
the
docker
files
approach,
you
write
a
bot
or
something
that
goes
along
scans,
each
Docker
file
and
and
does
the
update
in
place.
Maybe
it
submits
a
PR
in
the
build
packs
approach,
particularly
when
I
use
a
centralized
build
form
like
kpac.
A
All
of
them
are
brilliant,
but
a
lot
of
them
are
very
specialized
and
if
I
ask
them
to
write
a
Docker
file,
of
course,
they
can
because
they're
brilliant,
but
it's
really
taking
them
away
from
their
bread
and
butter,
which
might
be
some
kind
of
a
AI
machine,
learning,
stuff
or
financial
analytics
or
that
kind
of
stuff,
and
if
I
can
take
that
cognitive
load
off
them
and
put
it
onto
a
team
of
one
or
two
people
who
can
centralize
all
this
and
all
this
policy?
Well,
we
make
a
lot
of
problems
go
away.
A
C
A
C
A
A
It's
common
to
have
a
requirements.txt
or
you
put
your
dependencies
in
your
Pi
project.tommel
file
under
the
requires
thing
that
new
thing
that
I
haven't
quite
figured
out
yet
right,
A,
C
library,
that's
a
more
difficult
question,
generally
speaking
for
python
dependencies
if
they
compile
their
own
C
libraries
that
works.
If
you
want
to
install
a
C
library,
well,
I
think
the
best
answer
is
those
would
normally
be
installed.
Well,
how
has
the
best
way
to
answer
this
question?
I've
done
it
in
two
or
three
different
ways.
A
The
other
way
is
that
you
might
install
the
C
library
on
the
Run
image
to
start
with,
and
now
with
the
new
approach
of
allowing
Docker
files
to
switch
the
Run
image,
you
can
switch
between
a
lot
of
the
Run
images,
depending
on
what's
building
on
top
of
them,
but
previously
what
I
would
do
if
there's
a
common
C
library
that
a
lot
of
our
application
developers
use
I
would
install
that
as
part
using
RPM
or
our
apt-get
On
The
Run
image
that
we
shipped
to
everything
fantastic.
Thank
you
very
much
one
more
question.
A
B
Go
into
that
example,
you
had
of
running
it
natively
and
you've
got
multiple
hosts
and
potentially
running.
Those
builds
in
parallel
is
the
mercep,
something
that
you
have
to
like
manually
orchestrate
together
or
is
that
something
that
potentially
each
build
stream
could
do
and
potentially
have
the.
A
A
That
that's
it
I
mean
I.
Think
that
the
question
needs
to
be
asked
the
way
I'm
currently
thinking
about
it
is
that,
yes,
they
can
run
in
parallel,
each
of
the
output
images
might
get
pushed
to
a
registry,
and
then,
at
the
end
of
all
that,
you
might
have
some
kind
of
process
that
kicks
in
and
computes
the
Manifest
list
for
for
all
the
output
images
for
from
the
different
Target
architectures,
but
it
does
lead
to
the
questions
like
if
I
want
to
build
for
two
architectures
and
if
one
of
the
hosts
fails.