►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Intro to Cloud Native Buildpacks - Javier Romero, VMware; Sambhav Kothari, Bloomberg
Cloud Native Buildpacks transform your application source code into images that can run on any cloud. In this session you'll learn the basics of using buildpacks, why they make a great choice over the alternatives, and what new features the project has to offer. Cloud Native Buildpacks embrace modern container standards, such as the OCI image format. They take advantage of the latest capabilities of these standards, such as cross-repository blob mounting and image layer "rebasing" on Docker API v2 registries.
A
Hello:
everyone
thanks
for
attending
our
talk
on
cloud
native
fill
packs.
My
name
is
summer
and
I
work
at
bloomberg.
I'm
also
a
maintainer
on
the
cloud
native
buildbacks
project.
I'm
joined
today
by
javier
and
together,
we'll
be
presenting
an
overview
of
what
buildbacks
are,
how
they
can
help
and
later
javier
will
be
ending.
This
talk
with
some
really
cool
demos
without
further
ado,
let's
get
started.
A
A
A
For
instance,
while
java
buildback
may
look
for
the
presence
of
dot
java
files,
a
node
build
pack
can
look
for
the
presence
of
packagelock.json
at
build
time.
These
build
packs
may
download
dependencies
as
needed,
compile
from
source,
generate,
build
or
run
time
bill
of
materials
or
set
stock
commands
or
entry
points.
A
A
The
cloudy
of
buildbacks
project,
interestingly,
doesn't
produce
any
buildbacks.
Rather,
we
define
a
specification
and
the
tooling,
which
is
then
utilized
by
a
variety
of
different
vendors
to
create
the
actual
buildbacks.
We
also
maintain
a
registry
that
allows
developers
to
discover
these
build
packs
from
various
vendors.
A
A
Speaking
of
discovering
and
reusing
build
packs.
This
brings
us
to
the
concept
of
builders.
One
of
the
key
ways
how
we
distribute
buildbacks
builders
are
an
ordered
combination
of
build
packs
with
a
base,
build
image
and
a
run
image
they're
a
convenient
way
of
distributing
all
the
build
logic
for
buildbacks
in
the
format
of
a
normal
oci
image.
A
A
Finally,
we
have
the
platform.
A
platform
is
any
tool
that
takes
the
builder,
together
with
the
application
source
code
to
produce
the
final
image.
A
platform
can
range
from
a
local
cli
tool
like
pac
or
a
cloud
native
platform
like
kpac,
or
it
can
even
be
built
on
top
of
existing
ci
cd
platforms
like
techtom
app
developers.
Don't
really
have
to
know
how
any
of
this
works.
They
just
have
to
write
their
application
under
the
hood.
A
Now.
This
is
how
the
image
build
operation
typically
works
in
the
build
packs
ecosystem.
However,
we
also
expose
a
special
kind
of
image
creation
operation
unique
to
the
project
called
vbase
rebase
allows
our
developers
or
platform
operators
to
rapidly
update
an
application
image
when
stacks
runtime
image
has
changed
by
using
image
layer
rebasing
this
command
avoids
the
need
to
fully
rebuild
the
application
at
its
core
image.
Rebasing
is
a
simple
process
by
inspecting
the
application
image.
A
Previous
can
determine
whether
or
not
the
new
version
of
the
app
space
image
exists
either
locally
or
in
the
registry,
and
if
it
does
freebase
updates
the
app's
layer
metadata
to
reference
the
new
base
image
version
now
that
we
have
a
better
understanding
of
the
buildback
api.
Let's
take
a
look
at
how
these
abstractions
and
getting
rid
of
dockerfiles
helps
us
we'll
focus
on
three
main
benefits.
A
First,
it
allows
app
developers
to
focus
on
what
they're
building
and
not
how
to
support
it
in
production
or
build
a
container
image
out
of
it
in
that
buildbacks
also
have
the
added
benefit
of
building
and
packaging.
The
application
better
and
faster
than
the
app
developers
may
have
been
able
to
do
by
themselves.
A
Buildback
authors
can
take
care
of
internalizing
both
the
container
and
language
ecosystem,
specific
best
practices
and
produce
build
packs
that
minimize
the
images
attack,
surface
area
handle
caching
for
you
and
inject
appropriate,
build
and
runtime
dependencies
and
more
second,
it
gives
platform
operators
precise
control
over
what
build
inputs
are
permitted
and
enables
them
to
enforce
policies
on
what
the
app
images
should
contain.
Using
the
builder
concept
we
just
talked
about.
A
A
A
After
we
have
identified
these
images,
we
can
selectively
patch
the
application
dependencies
by
updating
the
relevant,
build
backup
builder.
For
example.
Let's
say
we
have
a
python
build
pack
that
provides
the
interpreter,
which
has
a
security
issue.
We
can
update
the
spill
packs
logic
to
now
provide
a
patched
version
of
this
interpreter,
and
we
can
use
this
new
build
pack
to
rebuild
just
the
python
related
layers
of
our
app
images.
A
A
Apart
from
build
timeout
implications,
it
also
has
runtime
implications,
since
you
don't
need
to
re-download
all
these
app
layers
on
each
node.
Rather,
you
just
need
to
download
the
base
layer
once
and
poof.
All
your
applications
are
able
to
reuse
this
and
have
been
patched
next
up.
Javier
will
be
taking
over
and
he'll
be
talking
about
how
you
can
use
all
these
cool
tech
in
practice,
along
with
some
amazing
demos,
over
to
you,
javier.
B
B
B
B
Pac
was
intended
to
be
used
primarily
for
local
development,
but
quickly
it
made
its
way
into
being
used
by
many
cicd
pipelines.
Kpac
is
a
kate's
native
implementation
of
cloud-native
buildpacks
platform.
It
works
by
allowing
users
to
declare
their
images
as
well
as
other
components
as
kate's
resources.
These
declarative
resources
are
then
managed
by
kpac
itself.
B
B
B
B
B
As
you'll
notice,
we
don't
pass
a
source
directory.
This
is
because,
by
default
it
will
use
the
current
working
directory
as
the
application
source
now
step
by
step.
The
first
thing
it'll
do
is
pull
the
latest
version
of
the
builder
image.
It
will
then
proceed
to
execute
various
lifecycle
phases,
the
first
one
being
detection.
B
B
An
example
of
this
is
using
various
methods
of
cache.
If
this
was
their
second
build,
we
would
see
that
certain
forms
of
cash
are
restored
during
the
restore
phase.
Next,
the
actual
build
occurs,
because
this
is
a
java
application.
It
will
be
providing
the
jdk
and
execute
the
necessary
maven
tasks.
Now
we'll
skip
past
all
these
dependencies.
B
After
waiting
for
the
java
application
to
compile,
we
could
see
that
it
did
so
successfully
on
to
the
next
phase
during
export.
All
the
layers
created
by
the
build
pack
are
either
cached
or
added
to
the
app
image
the
container
execution
command
is
also
set,
and
the
image
is
sent
to
the
docker,
daemon
or
registry.
B
Okay,
there
we
have
it,
we
have
the
application,
the
pet
clinic.
You
could
click
around,
there's
not
much
to
see
here,
and
we
really
don't
care
too
much
about
what
the
application
does
for
this
demo.
But
what
I
do
want
us
to
look
at
is
this
welcome
message
here:
okay,
we're
going
to
go
ahead
and
do
a
rebuild
by
attempting
to
change
that
message,
going
back
to
the
terminal,
we're
going
to
go
ahead
and
stop
our
container
right
now
that
that
stopped
we're
going
to
look
at
for
this
message.
The
welcome
message
we
just
saw.
B
B
And
what
you'll
see
is
it'll
still
try
to
pull
the
latest
version
of
the
builder.
But
there
are
a
couple
other
little
things
here
that
change,
for
instance,
the
analyzing
phase.
Now
it
actually
found
that
there's
a
couple
items
that
it
could
retrieve
from
cache,
whether
it
be
the
app
image
or
a
volume
cache,
which
is
what
we're
using
here
once
it
does,
that
the
restoring
phase
or
restore
is
what
pulls
those
artifacts
or
more
information
down.
B
All
right
there
you
go,
we
have
successfully
built
our
application
in
a
couple
of
seconds
instead
of
minutes,
as
we
did
prior
you'll
also
see
during
the
exporting
phase
that
we're
reusing
a
couple
layers.
So
these
layers
are
not
pushed
off
to
the
daemon
they're
reused.
In
that
fashion,
we
still
set
the
process
type,
which
is
the
execution,
the
startup
of
the
container,
and
then
we
put
the
the
image
up
back
into
the
the
daemon
itself.
B
All
right
now
that
we've
got
that
let's
go
ahead
and
run
our
application
again,
all
right,
we'll
open
up
our
browser
go
back
to
the
application
refresh,
and
hopefully
we
should
see
welcome
back
there.
You
have
it
now
that
we
are
done
with
that.
We
can
move
on
to
our
next
demo,
we'll
go
ahead
and
stop
this.
B
B
It
also
defines
the
order
in
which
the
build
packs
from
the
store
will
be
used.
We
could
then
take
a
look
at
the
stack.
The
stack
defines
what
build
image
it
will
use
and
what
run
image
it
will
use
from
there.
We
could
look
at
the
store.
The
store
is
what
tells
us
where
these
build
packs
are
coming
from
and
what
build
packs
are
available.
B
B
B
B
B
B
So
back
on
the
terminal,
all
right,
we've
done
that
we've
gotten
another
alert.
A
vulnerability
has
been
discovered
with
our
run
image:
okay,
we're
gonna,
go
back
to
our
ui
all
right
and
mark
our
stack.
That
has
a
vulnerability.
We're
gonna
use
the
sha
in
order
to
mark
that,
okay,
and
as
you
can
see,
it's
practically
every
single
image
that
we
have
here:
okay,
we're
gonna,
go
back
to
the
terminal
and
we're
gonna
simulate
again
that
a
our
buildpack
provider
has
updated
the
stack.
B
B
We're
updating,
we've
updated
five,
we've
updated
all
of
them,
so,
as
you
can
see,
right,
we've
just
updated
a
whole
fleet
of
images,
and
you
know
it
took
less
than
a
few
seconds
for
the
rebase
operation.
That's
the
base
layer
aspect
of
it.
That
concludes
our
demos.
Let's
go
back
for
just
a
few
more
slides.
B
Now
that
we've
gotten
a
better
understanding
of
what
build
packs
are
and
how
we
can
use
them.
Let's
talk
about
the
future.
This
year,
the
project
has
identified
a
few
key
areas
they
would
like
to
focus
on.
These
are
a
few
highlights
of
what's
top
of
mind
and
what's
going
on
this
year,
configurability
as
users
migrate
from
using
docker
files
to
cloud-native
build
packs,
they
see
the
value,
but
they
also
miss
the
flexibility
and
extensibility
available
in
docker
files.
B
Things
like
inline
build
packs
which
allow
users
to
create
ad-hoc,
build
packs
as
part
of
configuration,
along
with
additional
oci
specific
configuration
and
more
extensive
modifications
to
runtime
images
during
the
build
process
in
order
to
enable
more
advanced
use
cases
supply
chain
security
security
is
a
core
value
proposition
of
build
max,
while
build
packs
may
already
provide
bill
of
materials.
We
want
to
do
more.
We
want
to
make
them
core
of
the
project
and
align
them
with
existing
standards.
We
also
want
to
enable
better
image.
B
Signing
workflows,
something
we
are
working
with
cosign
on
to
achieve
more
cloud
native
integrations
as
the
ecosystem
evolves.
We
want
to
make
sure
we
continue
to
align
with
it.
We
want
to
take
advantage
of
those
great
projects
in
the
ecosystem
and
enable
users
to
pick
and
choose
what
tools
they
want
to
use
alongside
clouded
bookmarks,
as
I
mentioned
before,
this
is
just
a
peek
of
what's
in
the
works,
to
learn
more
about
these
and
other
items
check
out
the
official
roadmap
on
the
buildpacks.io
website.
B
That
concludes
our
talk.
For
today,
you
can
go
to
buildpacks.io.
You
could
find
us
on
slack,
along
with
the
rest
of
the
community
select.buildpacks.io
on
twitter
and
github.
We
have
two
github
locations
there,
one
for
the
build
packs
project
as
a
whole
and
another
one
for
kpac,
which
is
at
this
moment
a
separate
repository
or
project
altogether.