►
From YouTube: Pack to the Future: Cloud-Native Buildpacks on k8s
Description
Are you a developer that would rather build features than maintain Dockerfiles? Is your organization excited about Kubernetes but worried about patching vulnerable dependencies across a great number of containers? In this talk, you’ll learn how to use the pack CLI to go from source to image in seconds and patch a pod even faster. Cloud Foundry and Heroku users have long appreciated the developer experience and security guarantees provided by buildpacks. Cloud-Native Buildpacks (a CNCF sandbox project) represents a generational leap in buildpacks, bringing the power of buildpacks to k8s and beyond.
Speakers: Emily Casey, Principal Software Engineer, Pivotal; Joe Kutner, Java Language Owner, Heroku
Filmed at SpringOne Platform 2019
Slideshare: https://www.slideshare.net/SpringCentral/pack-to-the-future-cloudnative-buildpacks-on-k8s
A
We're
safe,
mm-hmm
III,
don't
work
at
pivotal,
so
everything
I
say
is
straight
from
the
divine,
but
Emily
here
works
for
a
pivot.
Also,
what
she
says
is
just
for
your
information:
it's
not
contractual,
etc,
etc.
My
name
is
Jo
Kutner
I
work
at
Heroku,
which
is
a
platform
as-a-service.
We
host
about
10
million
applications
and
handle
more
than
23
billion
requests
per
day.
My
job
there
is
to
curate
the
Java
experience
so
I'm
responsible
for
making
sure
that
our
customers,
Java
apps
work
on
the
platform
and
one
of
the
tools
I
have
to
do.
A
B
A
Yeah
right,
ok,
let's
talk
about
why
you're
here
today
is
kubernetes
track.
You
probably
love
containers
who
loves,
containers
right
good.
We
love
containers
too.
You
probably
love
kubernetes
everybody
using
kubernetes.
We
love
kubernetes
too.
So
this
is
this
great
world
where
we
can
run
our
apps
and
containers
and
orchestrate
them
with
kubernetes.
But
we've
got
to
build
images
somehow
right
so
who
loves
docker
files
yeah
when
I
see
the
like
this
new
container
ecosystem,
that's
developed
over
the
last
few
years
and
and
in
kubernetes
and
all
this,
it
really
feels
like
a
bright
future.
A
But
when
I
like
a
docker
file,
it's
like
Jos
13.
You
know
this
is
this:
is
the
future
there's
things
about
docker
file
that
I
think
actually
increase
our
operational
burden
and
I'll
explain
why
in
a
bit,
but
I
want
to
make
one
thing
clear.
First,
when
I
say
docker
file,
I'm
not
talking
about
docker,
so
docker
is
an
ecosystem.
It's
a
collection
of
CLI
and
registry
specifications
and
tools,
and
one
of
those
tools
is
docker
file.
A
Docker
file
is
a
mechanism
for
describing
how
a
repository
becomes
a
docker
image,
and
it's
just
one
of
the
mechanisms
we
have
to
do
that.
There
are
other
ways
and
we
believe
better
ways
and
that's
what
cloud
native
build
packs
are.
They
are
a
higher
level
abstraction
for
creating
docker
images
from
your
application
source
code.
So
at
a
very
high
level
they
take
source
code
as
input
and
as
output.
They
produce
a
docker
image
with
layers
that
map
logically
to
your
application.
A
So
to
understand
why
this
solution
or
why
this
tool
is
a
better
alternative
than
something
like
docker
file.
We
need
to
first
take
a
look
at
how
you
create
a
docker
file
for
a
very
simple
java
application
and
we're
gonna
follow
the
steps
that
are
given
to
us
by
the
folks
at
docker.
We're
just
gonna
walk
through.
A
What's
in
this
blog
on
Walkertown
docker
comm,
they
talked
about
making
sure
that
you're
copying
your
files
into
the
image
in
the
correct
order,
so
that
you
don't
copy
your
java
files
in
before
you
install
the
jdk,
because
then
a
change
to
your
source
code
would
cause
you
to
have
to
bust
your
cache
and
reinstall
the
jdk.
Every
time
you
build,
which
is
very
inefficient.
A
Along
with
installing
a
jdk,
you
need
to
make
sure
that
you're
doing
all
those
steps
on
a
single
run
directive
so
that
you
end
up
with
a
single
layer
that
represents
your
jdk.
You
have
to
make
sure
you're,
updating
your
package
indices
and
then
removing
the
leftover
cruft
from
the
apt
install.
So
you
end
up
with
these
bash
commands,
ampersand
it
together
to
end
up
with
this.
You
know
single
directive,
and
this
is
a
fairly
tame
example,
but
it
can
get
out
of
hand
if
we
look
at
the
docker
file
for
the
official
Python
image.
A
That's
on
docker
hub,
it
is
a
112
line,
run
command
and
it's
all
of
these
steps
and
purse
ANDed
together,
so
that
the
final
Python
runtime
is
contained
on
a
single
layer
without
any
extra
cruft.
Now
this
is
what
I
call
dockerfile
gymnastics
where
you
have
to
like
bend
docker
file
to
your
will
to
get
to
get
the
kind
of
image
that
you
want.
So
what
we're
talking
about
docker
hub?
Let's
talk
about
the
open,
JDK
image
which
you
should
not
use.
A
Open
JDK
is
not
the
only
image
that
has
issues
the
folks
that
snick
a
dependency
monitoring
and
management
solution
did
an
analysis
of
the
most
popular
images
on
docker
hub
and
they
found
that
the
top
10
most
downloaded
images
had
30
vulnerabilities
each.
So
these
are
not
things
you
should
run
in
production
when
you're,
using
a
base
image
from
docker
hub
you're,
putting
a
lot
of
trust
in
the
provider
of
that
image,
and
sometimes
it's
misguided.
So
coming
back
to
our
Java
example,
we
probably
also
want
to
run
maven
in
a
container.
A
So
now
we
have
to
do
more
gymnastics.
We're
gonna
copy
our
pom.xml
into
the
image
first,
so
that
a
change
to
our
source
code
doesn't
invalidate
our
maven
cache
and
we
have
to
redownload
the
internet
every
time
we
change
our
code,
so
we
copied
the
pom.xml
and
we
run
dependency
resolve.
Then
we
copy
our
source
in
and
then
we
run
maven
package.
So
it's
not
something
an
ordinary
developer
would
do
it's
something
we
just
have
to
do
for
docker
file
and
this
works.
A
Ok
but
like
if
you
change
the
authors
in
your
pom.xml
you're,
still
going
to
bust
your
maven
cache
and
have
to
redownload
the
internet
unnecessarily.
Also,
if
you
have
multi
module
maven
projects,
I
don't
good
luck
have
fun.
You
have
to.
You
know,
keep
this
in
sync
with
your
repository,
so
the
thing
to
take
away
from
this
is
not
what
this
docker
file
looks
like.
It's
look
at
all
the
things
we
had
to
know
in
order
to
create
a
docker
file
for
the
simplest
possible
java
application.
A
A
What's
worse,
is
that
every
time
you
create
a
new
Java
app,
you
have
to
repeat
this
process
right.
So,
in
the
best-case
scenario,
you're
gonna
copy
paste
this
docker
file
into
a
new
repository
and
in
the
worst
cases,
you're
gonna
copy,
paste,
bits
and
pieces
of
them,
because
the
structure
is
different
or
something
like
that.
Some
people
use
templates
for
this,
but
in
any
case,
what
you
end
up
with
is
propagating
these
snowflake
docker
files
out
throughout
all
the
repos
in
your
organization,
and
these
are
just
the
problems
on
day.
One.
A
The
real
issues
begin
on
day
two
when
there
are
security
security
patches
that
need
to
be
applied.
So
to
illustrate
this.
Let's
take
an
example:
the
meltdown
inspector
vulnerabilities.
These
were
two
CVEs
that
exploited
characteristics
of
modern
CPUs
and
they
affected
all
applications.
So
if
we
look
at
the
typical
docker
image
for
a
java
application,
it
has
sort
of
three
sets
of
layers.
You've
got
your
application
layer
or
layers.
You've
got
a
layer
for
the
JDK
or
JRE,
and
then
one
or
more
layers
for
your
operating
system.
A
So
this
vulnerability
could
be
protected
by
patching
the
operating
system.
Layer
down
to
the
very
bottom,
but
because
of
the
way
docker
file
works,
updating
this
layer
requires
rebuilding
all
the
layers
above
it.
So,
even
though
the
external
interface
for
the
operating
system
does
not
change,
we
still
have
to
download
the
JDK
install
it
redownload
the
maven
cache
and
rebuild
your
app.
A
We
compile
your
code
now,
there's
a
process
that
can
take
hours
so
it
you
know
it
just
increases
the
amount
of
time
it
takes
you
to
remediate
this
issue,
but
in
the
real
world
you
have
more
than
one
job
application.
You
probably
have
hundreds
in
your
organization
and
because
of
the
nature
of
this
vulnerability,
they
all
need
to
be
rebuilt.
A
So
now
we're
going
from
hours
to
days
or
even
months.
In
the
worst
case
scenarios
you
have
those
snowflake
docker
files,
they're
using
a
different
operating
system
or
a
different
version
of
the
JDK,
or
you
know
they
have
some
different
external
dependency
and
in
some
of
those,
maybe
they've
been
running
in
production
for
years,
just
fine
and
then
now
you
have
to
rebuild
it
and
it
won't
recompile,
there's
something
on
maven
Central's
change.
A
A
It's
increasing
our
operational
burden,
it's
making
it
more
difficult
for
us
to
protect
our
apps
to
be
secure,
so
we
think
there's
a
better
way
and
that's
why
Emily
and
I
work
on
a
project
called
cloud
native,
build
packs
bill
packs
at
I/o.
Our
cladding
at
build
packs
is
a
CNC
F
sandbox
project,
and
it
is
a
specification
and
set
of
tools
for
turning
your
application
source
code
into
a
docker
and
into
a
docker
image
without
using
docker
file.
A
As
I
said
before,
at
a
very
high
level,
we
take
in
source
code
and
we
use
a
tool
called
PAC
which
we're
going
to
see
a
demo
of
in
a
moment
to
run
build
PACs.
They
execute
specific,
build
steps
based
on
what
kind
of
build
pack
they
are,
what
well
they're,
using
maven
or
Gradle
or
MPN
or
whatever
it
may
be,
and
then,
as
output,
they
produce
a
docker
image
that
is
structured
in
a
way
that
Maps
logically,
to
your
application.
A
So
there
will
be
layers
for
your
stack
image,
which
was
your
OS
and
some
system
packages
layer
for
your
runtime,
which
is
your
JDK
JRE,
your
node
runtime,
whatever
it
may
be
your
dependencies
and
then
layers
for
your
application
and
because
of
this
structure,
that's
like
well
defined
structure,
which
is
based
on
the
characteristics
of
your
app
and
not
based
arbitrarily
on
whatever
directives
are
in
your
docker
file.
It
allows
us
to
do
things
that
you
that
you
can't
do
with
other
tools
like
docker
file.
A
So,
aside
from
the
build
packs
themselves,
the
build
pack
ecosystem
consists
of
many
different
components,
including
what
we
call
the
platform
and
one
example
of
a
platform
is
PAC
which
we're
going
to
talk
about
some
more
there's.
Pac
is
a
mechanism
for
running
the
build
pack
execution
environment,
which
we
call
the
lifecycle
and
then,
as
part
of
the
bill,
packs
a
day'll
project.
We
define
a
specification
for
these
things
and
then
the
bill
packs
themselves
actually
sit
outside
of
the
project
and
produced
by
organizations
like
cloud,
foundry
and
Heroku.
A
So
to
visualize
this
at
the
very
bottom.
We
have
our
platforms
which
execute
the
lifecycle,
which
in
turn
executes
build
packs,
and
the
specification
defines
the
interface
between
each
of
these
components
and
that
well-defined
interface
allows
us
to,
for
example,
swap
out
build
packs.
So
you
can
use
Heroku
zubi
build
pack
or
cloud
foundries
Java
build
pack,
and
these
are
all
going
to
execute
the
same
way
because
of
that
definition
for
the
lifecycle.
On
the
other
end,
we
have
platforms
like
PAC,
but
there
are
other
options
that
you
can
substitute
out
to
run.
A
This
build
PAC
execution
environment
like
k
pack,
which
we'll
talk
about
some
more
commercial
platforms
like
Heroku
or
open
source
technologies
like
Tecton,
so
build
packs,
have
some
characteristics
that
make
them
a
better
abstraction
for
application
developers.
They're
reusable
so
one
build
pack
is
used
on
many
different
applications
as
compared
to
docker
file,
where
you
have
to
create
a
new
docker
file
for
every
application.
A
The
build
pack
itself
is
battle-hardened
its,
but
has
bug
fixes
they're
produced
by
organizations
that
are
working
actively
on
them
and
lots
of
people
are
contributing
to
them.
They're
fast.
They
only
rebuild
and
upload
later
layers
when
necessary.
If
you
don't
need
to
reinstall
your
JDK,
we
will
not
reinstall
your
JDK.
If
you
don't
need
to
recompile
your
code,
you
won't
recompile
your
code.
There
modular,
you
can
combine
build
packs
to
create
composite
images.
A
So
if
you
have
like,
for
example,
a.j
hipster
kind
of
application
with
a
spring
boot
back-end
and
an
angularjs
front-end
in
order
to
build
the
java
part
of
it,
use
the
java
build
pack
in
order
to
prepare
the
front-end
use
a
nodejs
build
pack.
This
is
something
that's
very
difficult
or
really
impossible
to
do
with
docker
file
you
can't
use
multi-stage
builds
to
combine
the
runtimes,
build
packs
are
also
safe.
They
allow
you
to
meet
security
requirements
without
developer
intervention,
so
they
separate
the
concerns
of
the
platform.
A
Like
the
operating
system
version,
the
system
packages
from
the
application
developer,
who
really
just
wants
to
work
on
spring
boot
or
something
like
that
all
right?
So
let's
talk
about
how
build
packs
the
build
packs
themselves
have
to
externally
defined
phases,
entry
points
if
you
will
and
then
a
few
internal
phases
that
we're
going
to
talk
about
as
well,
so
all
build
packs
start
with
the
detection
phase,
and
this
is
where
they
determine
whether
they
should
or
should
not
run
against
a
particular
repo.
A
So
a
Java
build
package,
Java
maven
build
pack
would
look
for
a
pom.xml
to
determine
if
it
should
execute
against
this
particular
application.
After
that,
we
get
to
the
analysis
phase.
This
is
where
the
built
pack
execution
environment
decides
if
it
can
reuse
layers
from
a
previous,
build
or
use
some
cached
something
in
the
cache.
A
So
if
we
were
to
walk
through
this
with
an
example
we'll
take
that
J
hipster
example
again,
we've
got
a
spring
boot
back-end,
where
we
need
the
Java
build
pack
and
a
nodejs
build
pack
to
prepare
our
angularjs
or
front-end.
So
the
Java
and
node
build
packs
will
pass
detection
because
they're
going
to
see
a
pom.xml
or
a
package.json
or
whatever
they
require.
A
Then
we
run
the
build
process
to
install
the
JDK
run.
Maven
install
the
bill.
Pex
we'll
do
all
this.
Where
you
install
node,
1
npm,
install
the
export
step,
we'll
take
all
those
artifacts
and
produce
layers
that
map
to
each
of
these
components.
So
we
have
a
node.js
layer
for
the
node.js
runtime,
a
modules
layer
for
your
node
modules,
Java
layer,
your
jars
layer,
a
player
and
then,
in
this
case
we're
building
on
top
of
link
218
and
a
configuration
layer
which
tells
the
build
pack
execution
environment.
A
What
is
in
this
image
now,
the
second
time
we
run
a
build.
Let's
say
we
just
change
our
dependencies
in
our
package.
Json
and
our
pom.xml,
our
Java
and
node.
Build
packs
are
going
to
pass
detection
and
then,
during
the
build,
they'll
only
do
what's
necessary,
they're
going
to
use
the
cache
and
the
metadata
to
we
use
what
layers
they
can
and
then
just
run.
Maven
install
or
NPM
install
to
get
those
new
dependencies
and
during
the
export
step,
all
they
need
to
do
is
update
those
layers
that
have
changed.
A
So
we
do
not
need
to
update
the
node.js
layer
because
it,
our
node.js
version,
did
not
change.
We
can
reuse
that
one
so
in
this
example
we're
building
on
top
of
Buda
18,
as
I
said,
and
that
kind
of
that
operating
system.
That
platform
gives
us
a
guarantee,
called
ABI
compatibility,
and
this
allows
us
to
do
things
with
these
layers
that
we
could
not
otherwise
do
so.
Application
binary
interface
defines
it's
sort
of
a
guarantee
from
the
vendors
of
these
operating
systems
that
there's
going
to
be
a
certain
level
of
compatibility
when
applying
patches.
A
So
if
we
look
at
our
the
image
that's
produced
by
a
build
pack
build,
we
have
our
a
player
and
our
JDK
layer
sitting
on
top
of
this
operating
system,
and
let's
say
there
is
an
outdated
operating
system
that
has
a
CVE
and
the
vendor
produces
a
new
operating
system
image
that
has
patches.
Because
of
this
ABI
compatibility.
We
can
do
sort
of
a
lift
and
shift
where
we
take
the
layers
that
sit
on
top
of
that
stack
and
move
it
over
to
the
new
operating
system
without
actually
running
a
build.
A
So
this
operation
can
happen
in
fractions
of
a
second
without
having
to
run
maven
having
to
download
the
JDK
things
like
that.
But
the
OS
itself
is
just
a
part
of
the
construct
that
we
call
the
run
image
so
run.
Images
represent
the
operating
system
plus
some
system
packages
and
then
platforms
like
cloud
foundry
and
Heroku
have
their
own
implementations
of
that.
So,
in
our
case,
both
are
based
on
a
boon
to
18
all
right
who's,
ready
for
a
live
performance.
B
Alright
guys,
today,
I'm
gonna
be
demoing
two
different
platforms
for
you
that
are
both
going
to
generate
an
image
from
the
cloud
native
build
packs.
These
platforms
are
pack
and
K
pack,
so
both
of
these
platforms
will
execute
the
exact
same
life
cycle
that
Joe
described
when
you
did
that
diagram
of
the
components
of
the
ecosystem
they're
both
going
to
execute
the
same,
build
packs
and
they're
going
to
generate
identical
images,
but
both
of
these
platforms
are
optimized
for
very
different
use
cases
so
to
take
PAC.
B
First
pack
is
a
CLI
tool
that
employs
an
imperative
model
and
it's
optimized
for
the
local
development
experience.
So
it's
been
to
be
run
by
developers
on
their
workstation.
It's
going
to
execute
the
life
cycle
in
containers
and
the
docker
demon
pack
is
a
part
of
the
cloud
didn't
build
packs
project
Capek,
on
the
other
hand,
is
a
kate's
native
platform
for
running
cloud
native,
build
packs,
it's
piece
of
pivotal
open
source
software
and
it
employs
a
declarative
model
and
it's
optimized
for
managing
multiple
images.
B
So
rebuilding
images
at
scale
when
a
new
operating
system
version
comes
out
or
there's
a
patch
and
in
dependency,
so
I'm
going
to
start
with
PAC
because
it
provides
the
most
straightforward
introduction
to
the
ecosystem
at
the
PAC
CLI
here
and
in
the
simplest
case,
you
just
run
PAC
build
and
you
get
an
image
now,
just
running
PAC
build
and
looking
at
the
output
and
saying
it
works,
wouldn't
be
very
interesting
demo.
So
first
I'm
going
to
describe
another
domain
concept,
that's
used
in
both
pack
and
K
pack,
and
this
is
called
a
builder.
B
So
a
builder
is
an
image
that
when
PAC
executes
the
different
lifecycle
phases
is
going
to
execute
them
in
containers
based
on
this
builder
image.
So
I
have
a
builder
image
here
for
the
demo.
Let's
take
a
look
at
what's
inside
this
image
so
in
this
output
and
we
can
use
PAC
to
take
a
look
inside
any
builder.
You're
gonna
see
a
lot
of
concepts
that
are
familiar
from
the
explanation.
Joe
just
gave
about
the
ecosystem,
so
it's
printing
out
both
the
local
one
and
the
docker
keep
it
in
the
room.
We're
gonna!
B
Look
at
the
remote
version
right
now,
so,
first
of
all,
we
have
the
life
cycle
which
is
packaged
up
inside
this
image.
This
is
life
cycle
version,
oh
for
oh,
you
can
see.
The
different
API
is
that
this
particular
life
cycle
implements
so
Joe
described
how
the
life
cycle
implements
two
contracts
that
are
defined
in
r-spec.
These
are
the
versions
of
the
two
contracts
that
this
life
cycle
implements.
B
The
next
thing
to
notice
here
is
that
the
builder
contains
a
reference
to
a
run
image,
so
when
the
builder
is
used
generating
the
image
it's
going
to
take
the
image
that
exists
at
this
run
image
tag
and
use
that
to
pull
in
the
base
layers
for
the
images
generating.
Now
the
run
image
that
this
builder
uses
lives
in
docker
hub,
so
I
have
added
a
local
mirror
on
the
registry
they're
going
to
be
exporting
to
as
part
of
my
pack
config
and
when
pack
runs
it'll,
be
smart
enough
to
know
to
choose
the
mirror.
B
B
B
So
gone
are
the
days
of
monolithic,
build
packs,
and
now
we
have
tiny
modular
composable
build
packs
and
we
put
these
bill
packs
into
groups
and
when
detection
runs,
it's
going
to
look
for
a
group
where
every
bill
pack
that
isn't
marked
as
optional
passes
detection.
That's
gonna.
Take
the
set
of
bill
pics
that
passed
and
those
are
the
bill
packs
that
are
going
to
contribute
to
your
bill.
So
I'm
gonna
build
the
java
application.
So
if
all
goes
well,
we're
gonna
hope
this
first
group
passes.
B
We
are
doing
this
demo
on
the
Wi-Fi.
So
let's
hope
the
demo
gods
are
with
us
today.
Alright,
so
I'm
gonna
pass
a
path
to
my
application
jar.
These
book
packs
are
also
capable
of
building
your
java
application
from
source,
but
this
is
faster
and
we
like
fast,
especially
for
demos,
so
I'm,
going
to
tell
PAC
explicitly
to
use
the
Builder
that
I
just
showed
you,
the
demo
builder
I'm,
going
to
give
it
a
location
where
I
want
it.
To
put
my
image,
I'm
gonna
put
it
in
my
local
registry
and
I'm
gonna.
B
B
We
need
to
build
the
PAC
boom.
Alright,
so
there's
a
couple
things
to
notice
in
this
output,
it's
making
sure
that
our
builder
image
is
up-to-date.
We
can
see
that,
like
we
expected
a
set
of
Java
build
packs
past
the
texture,
that's
great.
If
we
come
down
to
the
building
phase,
we
can
see
these
build
packs
contributing
dependencies
to
the
image.
B
So
the
open,
JDK
bill
pack
is
contributing
a
JRE,
we're
getting
some
process
types
and
configuration
some
jars
and
then,
in
the
exporting
stage,
the
life
cycle
is
turning
each
of
these
dependencies
into
semantically
meaningful
layers.
So
when
you
look
at
your
final
image,
like
your
application
will
be
a
single
layer
and
each
layer
in
the
image
is
understood
by
the
cloud
native
build
pack
time.
B
B
B
So
one
nice
thing
is
that
the
life
cycle
adds
a
bunch
of
metadata
to
the
image
generates
and
we
can
use
PAC
to
actually
take
a
look
at
that
metadata.
We're
gonna
use
a
new
command
they'll,
be
coming
the
next
release
of
PAC
inspect
image.
So,
let's
see
what
we
got
here
all
right.
So
when
we
were
describing
the
run
in
inch
and
said
this
was
the
image
we're
gonna
base
our
new
image.
B
On
top
of,
we
were
looking
at
a
tag
reference
it's
important
after
you've,
built
to
know
the
exact
digest
reference
like
the
particular
run
image
that
you
built
your
application
on
top
of
the
application.
Metadata
still
contains
references
to
the
run
image
tag
so
that
you
can
rebase
when
new,
updated
images
are
pushed
to
that
tag
without
having
to
use
a
builder
or
some
other
configuration.
You
can
see
the
exact
build
PACs
that
contributed
to
this
image.
B
So
there's
one
extra
flag:
we
can
stick
on
the
end
of
this
inspect
image
command.
Now
we're
gonna,
look
at
just
the
remote
output
here,
and
this
fly
here
is
telling
inspect
image
to
print
the
bill
of
materials.
So
when
the
bill
PACs
run
a
build,
they
are
working
together
to
create
a
bill
of
materials
which
describes
everything
that
the
bill
PACs
have
added
to
this
image.
B
So
if
you
look
at
there's
a
lot
of
data
here,
but
just
to
make
it
look
less
overwhelming,
if
we
focus
on
this
last
in
entry,
we
can
see
that
the
auto
reconfiguration
bill,
PAC
added
the
auto
reconfiguration
dependency.
You
can
see
what
URL
that
dependency
came
from.
We
can
see
the
digest.
We
can
even
see
that
it
has
an
Apache
2
license.
So
if
we
scroll
up
here,
I
want
to
call
your
attention
civically
to
the
JRE.
B
B
Let's
take
a
look
at
this
one.
You
can
say
we
went
from
the
old
version
to
the
new
version.
This
is
the
Builder
we
want
alright.
So
let's
go
back
to
our
pack
build
and
let's
run
it
against
this
new
builder
and
see
what
happens
so.
The
build
is
going
to
be
faster
this
time,
because
it's
not
creating
all
of
these
layers
from
scratch.
B
When
we
get
down
to
the
exporting
step,
you
can
see
that
it
gets
to
essentially
reuse
the
layer
blobs
in
the
registry
for
everything
that
it
didn't
explicitly
change
during
build
time.
So
it's
adding
a
new
Jerry,
lighter
layer,
it's
adding
a
new
config
layer
which
we
change
every
time,
but
everything
else
gets
to
be
reused
directly
out
of
the
registry,
which
makes
it
very
fast.
So
now,
if
we
come
and
look
at
our
bill
of
materials
and
we
scroll
up
and
we
find
a
JRE
and
you
can
see-
oh,
we
have
the
updated
version.
B
That's
very
easy.
I
had
to
create
two
builders
to
sort
of
show.
This
contrived
example,
but
if
you're
using
a
builder,
that's
maintained
by
a
provider
like
cloud
foundry
or
Heroku
and
PAC
is
always
pulling
down
the
newest
builder.
From
that
tag,
this
kind
of
update
is
just
happening
behind
the
scenes.
Every
time
you
build,
you
might
not
even
notice
it.
B
B
B
B
Want
it
to
run
against
the
registry
and
that's
what
should
go.
This
is
very
fast
because
no
new
layers
had
to
be
generated
at
all.
We
basically
just
created
a
new
image,
manifest
that
stitched
the
old
application
layers
on
top
of
the
new
base
layers,
which
will
have
an
updated
operating
system
and
updating
system
packages.
So
this
may
seem
to
magic.
You
might
be
wondering
if
it
still
actually
works.
Do
we
trust
the
ABI
compatibility?
So
let's
pull
it
down
and
run
it
just
so
we
feel
good
about
it.
B
So
all
that
magic,
the
application,
still
works.
Fine.
This
sort
of
update
but
rebasing
base
layers
is
something
that
platforms
like
cloud.
Foundry
and
Heroku
have
been
doing
for
years
on
App
and
production.
So
you
can
like
really
trust,
but
a
bi
compatibility
is
something
you
can
depend
on
when
you're
rebasing
images.
B
So
again
we
can
see
only
the
application
layer
changed.
So
this
is
the
type
of
update
like
most
developers
will
be
experiencing
most
of
the
time
because
they're
iterating
on
their
app
and
they
don't
care
about
the
rest
of
it.
They
just
want
it
to
get
out
of
the
way
and
be
fast.
So
now,
if
I
thought
I
pulled
this
image,
one
more
time
and
I
run
it
I
can
see
that
I've
changed
the
banner
here.
It
looks
good
right,
so
that's
PAC,
CLI
tool.
B
You
can
see
the
imperative
workflow
I'm,
telling
PAC
exactly
when
to
build.
The
next
tool.
I'm
going
to
demo
is
Kay
pack,
so
I'm
gonna
jump
over
to
where
I
have
some
kpac
set
it
up.
Okay,
so
I
have
mini
cube
running
on
this
machine
and
we've
installed
some
custom
resources
I'm
an
alias
for
cube
GTL
because
for
some
reason
I
can't
seem
to
type
it.
But
that's
alright,
and
even
these
custom
resources
you'll
see
a
lot
of
familiar
words.
So
we
talked
about
builders.
B
Cluster
builders
are
just
builders
that
are
available
for
the
entire
cluster.
We've
seen
a
build
run
and
we're
going
to
show
you
in
a
minute
how
we
can
apply
a
declarative
image
declaration
and
Kay
pack
has
been
to
schedule.
However,
many
builds
it
needs
whenever
it
needs
to
in
order
to
make
sure
that
the
image
you
described
just
kept
up
to
date.
It
looks
good
in
the
registry.
B
B
So
a
lot
of
things
in
here
gonna
look
familiar
from
the
pack
build
output,
so
you
can
see
that
K
pack
has
looked
at
the
Builder
tag
that
I've
applied
and
it
has
populated
the
status
here
with
all
of
the
bill
packs
that
it
found
in
the
Builder
and
in
addition
to
that,
it
has
the
digest
that
it
believes,
is
the
latest
image
at
the
run
image
tag.
So
let
me
show
you
what
we
had
to
apply
to
create
this
builder.
B
B
A
B
I
want
to
look
at
I,
gotta,
say
I
want
to
look
at
the
first
build.
So
let's
look
at
this.
This
output
should
look
very
familiar.
This
is
just
the
life
cycle
running,
but
it's
running
in
kubernetes
this
time
you
can
see
the
same
things
we
saw
before
this
is
the
output
of
protection.
Gonna
have
the
prefixes,
but
it's
all
here
same
build
packs,
are
doing
a
bill
and
we're
getting
down
to
the
export
stage,
which
is
putting
our
image
in
the
registry.
So.
B
B
B
All
right,
so
here's
our
build
materials
for
the
new
image
we
generated
that
should
all
look
familiar.
Oh,
we
have
the
old
Jerry.
Let's
fix
that,
so
what
I'm
going
to
do
to
fix
it?
This
time
is
I'm
going
to
edit.
My
builder
definition
to
point
add
an
updated
builder
which
should
have
the
new
build
packs
in
it
and
I'm
going
to
apply
it.
B
Should
see
when
I
scroll
up
and
look
at
the
list,
the
build
packs
here
that
I
have
the
new
version
of
the
open,
JDK
Jerry.
Now
what
Capek
is
going
to
do?
Is
it's
going
to
look
at
images
that
this
bill
pack
contributed
to
and
see
that
there
has
been
a
build
pack
update
and
it
needs
to
schedule
a
new
build,
so
I'm
gonna
look
at
the
builds
again.
B
We
can
see
a
new
builder
scheduled
I'm
gonna.
Show
you
something
that's
helpful
as
a
developer
when
you
see
builds
running
in
K
pack,
because,
let's
say
an
operator
has
updated
the
builder
or
a
run
em
in
she
might
not
know
why
a
new
build
has
become
scheduled.
So
what
I
can
do
is
look
at
the
annotations
on
the
image.
B
B
There
we
go
so.
The
second
build
was
scheduled
for
recent,
build
pack,
I
updated
the
OpenJDK
build
pack
and
it's
kicked
off
a
new
build,
and
it's
telling
me
why
it
did
that.
So
again,
I
can
use
the
longest
tool.
Look
at
the
second
build
you
can
see.
It's
almost
reached
the
end
of
the
build.
If
we
scroll
up,
we
can
see
it
installed
the
newer
JDK
and
we
can
use
PAC
inspect
image
again
to
look
at
our
newest
metadata
and
see
the
Gerry
is
updated.
B
So
what's
nice
about
using
multiple
platforms,
that
use
cognitive,
build
packs
is
because
they're
using
the
same
underlying
lifecycle
and
implementing
the
same
specification
I
can
build
something
with
the
tool
like
a
pack
but
still
use
a
tool
like
pack
to
get
information
about
it.
So
all
of
these
modules
are
plug-and-play.
I
can
plug
in
a
different
platform
to
run
the
lifecycle.
I
can
have
the
lifecycle
plug-in
a
different,
build
pack
as
long
as
I'm
implementing
the
specification.
B
So
finally
we're
going
to
do
a
rebase.
So,
let's
look
at
this
image
again,
but
this
time
not
the
build
materials,
we're
gonna
look
and
see
that
again
we
have
the
older
version
of
the
run
image
so
I'm
going
to
make
sure
that
I
have
this
labeled
the
same,
my
daugher
local.
This
is
just
an
alias
for
localhost
by
the
way.
B
B
B
B
B
B
B
Other
thing
to
think
about
when
we're
showing
some
of
the
automatic
updates
like
around
the
rebase
or
around
the
build
pack
change,
is
that
this
story
becomes
very
strong
when
you're
managing
hundreds
of
applications
right
all
with
Capac.
So
when
I
push
a
run
image
change
in
this
particular
demo,
I'm
just
seeing
one
image
get
rebased,
but
if
I
had
500
images,
500
images
we
get
rebase
when
I
did
that
one
darker
push
the
same
thing
with
the
build
pack
update.
B
And
run
it
and
we've
recreated
all
the
same
updates
in
kpac
that
we
did
in
pack
in
some
ways,
I
had
to
go
out
of
my
way
and
these
examples
to
create
situations
where
there's
an
out-of-date
JRE.
That
needs
to
be
patched,
but
we
have
an
out-of-date
run
image
if
you're,
pointing
at
a
builder,
that's
managed
and
it's
getting
regularly
updated
bill,
paxton
regularly
updated,
run
images.
You
don't
necessarily
even
need
to
think
about
these
things
happening
they'll
just
be
happening
behind
the
scenes
by
default,
so
we've
barely
scratched
the
surface
here.
B
Pac
has
a
lot
of
tools
you
can
use
to
manage
your
own
builders
or
customize.
Your
build
with
your
own,
build
packs,
extend
your
build,
but
I
think
this
gives
you
a
general
overview
of
how
you
can
use
pack
to
iterate
use
packing
tape
back
to
iterate
on
your
source
code
and
also
have
a
strong
security
story
and
make
sure
all
your
dependencies
are
up-to-date.
A
A
So
again
we
had
to
update
every
one
of
our
Java
applications
right
and
with
something
like
docker
file
you
have
to
rebuild,
but
with
rebase
it's
like
a
bolt
of
lightning.
All
of
these
apps
can
be
updated,
almost
instantaneously,
bringing
them
up
to
compliance,
and
this
is
actually
what
happened
on
a
platform
like
Heroku.
When
the
Spector
meltdown
patches
were
released,
we
updated
10
million
applications
essentially
overnight
because
of
this
ABI
compatibility.
A
So
an
Emily
ran
PAC,
inspect
image.
She
got
this
bill
of
materials
that
told
her
what
was
in
the
image
right
it
tell.
It
gives
us
a
way
to
audit
what
we're
putting
into
our
production
runtimes,
and
this
is
something
you
can't
do
with
docker
file
right
like
each
little
snowflake
docker
file,
there's
no
way
to
control
what
a
particular
developer
has
added
to
that,
and
it's
putting
into
into
your
runtimes
build
packs
in
general.
A
Give
you
a
unified
way
to
control
your
build
processes
and
audit
them
and
and
when
containers
like
an
adult
that
the
yeah
it's
you're
getting
inside
of
the
head
of
your
image
right,
I'm
from
the
future,
okay,
so
pack
and
K
pack,
which
Emily
demonstrated,
are
two
platforms.
As
we
mentioned
before,
there's
other
platforms,
you
can
use
to
run
build
packs
as
yours,
a
CR
pack
build
commercial
platforms
like
Heroku
tech
Tom.
A
The
Tecton
catalog
has
a
bull
packs
templates,
where
you
can
use
this
to
run
the
build
pack
lifecycle
in
a
Tecton
tech
tongs
environment.
Rif
is
an
interesting
example
because
it's
using
pack
as
a
dependency
to
create
a
sort
of
higher
level
abstraction
platform
which
is
for
functions
and
functions
as
a
service.
All
of
these
work,
with
the
specification
that
we've
defined
and
essentially
as
Emily,
showed
work
the
same
way
and
use
the
same
build
packs.
So
this
is
the
future
right.
A
We're
separated
developers
from
the
concerns
of
the
platform,
which
are
the
operating
system
updates
and
the
system
packages
so
that
they
can
focus
on
adding
value
to
their
business
building
a
spring
boot
application
and
writing
features
those
things
that
a
job
developer
a
good
at.
If
you
want
to
use
pack
yourself
and
you're
on
a
Mac,
you
can
use
brew
to
install
it.
A
We
also
have
installers
for
Windows
and
Linux,
but
in
any
case
oh
and
you
can
get
those
from
bill
paxton,
but
in
any
case,
once
you
have
pack
installed,
you
run
pack
build
on
your
application
repository
whether
it's
a
Java
app
or
a
node,
app
you'll
choose
your
builder
or
either
Heroku
or
Cloud
Foundry,
and
it
will
turn
that
repository
into
a
docker
image.
Without
you
having
to
add
configuration
or
adjust
it,
it
should
just
work.
If
you
want
to
learn
more,
go
to
build
packs.
A
Do
we
have
documentation
some
other
important
links,
videos
to
talks
like
this?
You
can
join
the
conversation,
it's
buildpack
style.
We
have
a
growing
community
with
lots
of
people
answering
questions
and
discussing
the
future
of
this
specification.
You
can
find
the
source
code
on
github
at
github.
Comm
slash,
go
back
yeah!
B
A
So
your
so
the
question
is:
how
would
I
test
a
build
pack?
So
are
you,
as
the
author
of
a
build
pack,
is
that
your
question
right?
Okay,
so
for
first
of
all,
so
most
people
that
are
using
build
packs
will
not
write
their
own
bill
packs.
They
will
typically
use
a
build
pack.
That's
you
know,
provided
by
either
cloud
foundry
or
Heroku
and
and
very
mature
or
whatever,
but
yeah.
You
can
write
your
own
build
packs.
A
B
Also
provides
some
tools
to
help
with
that
experience.
So
there's
a
build
pack
flag.
They
didn't
get
a
chance
to
show
that
we'll
take
a
build
pack,
that's
on
your
local
file
system
and
add
it
to
the
Builder
before
running
the
build.
There's
also
tools
for
creating
your
own
builder,
so
you
can
take
an
existing
builder
and
add
your
modular
build
pack
to
it
or
create
your
own
builder
from
a
set
of
custom.
Build
packs
and
pack
will
help
you
that
experience.
So
then,
you
have
a
builder
image.
You
can
test.
B
B
B
So
if
we're
talking
about
multiple
builders
and
say
I've,
updated
a
builder
and
kpac
is
pulling
the
registry
to
learn
about
the
Builder
I
think
you
can
configure
the
polling
interval
on
that,
and
we
also
expect
that
in
most
organizations
there
might
be
many
application
images,
but
only
a
couple
builders,
that's
sort
of
the
general
use
case.
We
imagine,
but
we
also,
you
know,
provide
a
way
for
you
to
provide
your
secrets
to
authenticate
with
your
registry.
B
Yes,
so
you
can.
We've
been
experimenting
with
that
at
cloud
foundry,
where
we've
created
a
distro
list
back
and
have
used
it
to
build
going
images
mostly
right
now.
So
yes,
it
works
exactly
the
same.
Like
your
run.
Image
is
basically
disrelish
image
and
the
application
layers
get
added
very
similar
story.
The.
B
B
A
Know
plugin
I
think
you
mean
like
like
jib,
so
the
question
is:
if
there's
plans
for
a
maven
or
Gradle
plugin,
so
sono
pack
works
like
sort
of
in
like
it
uses
an
inverted
model
from
the
build
plugins.
So
it's
running
outside
of
the
build
tool.
So
if
you
think
of
like
a
maven
or
Gradle
plug-in,
what's
controlling
the
version
of
maven,
how
do
you
run
maven
in
the
container,
so
PAC
sits
outside
of
it
so
that
it
can
control
those
things
as
well?
A
But
the
advantage
of
that
is
one
that
you
can
have
a
unified
pipeline,
so
whether
it's
a
node
or
Python
or
Gradle
or
maven,
build
pack
or
a
application.
You're
gonna
have
this
same,
build
process
the
same
bill
of
materials
that
you
can
use
right,
yeah,
the
other.
So
that's
the
main
advantage.
They
also.
The
other
advantage
is
that
you
don't
have
to
do
anything
to
your
code.
So,
like
you,
don't
even
have
to
add
a
plug-in
to
pom.xml.
You
just
run
pack
build
on
the
App.
A
A
Yeah,
the
question
is:
how
is
configuration
delivered
to
the
build
pack
in?
In
most
cases,
it
depends
on
the
build
pack.
The
Heroku
build
pack
looks
for
a
system
properties
file
which
defines
the
Java
Runtime
version.
Some
build
packs
work
with
environment
variables,
which
you
can
pass
to
it
via,
like
the
a
flag
on
pack
as
part
of
the
specification,
I,
think
we're
working
towards
or
considering
some
kind
of,
like
Universal
or
unified
way
to
do
that.
But
right
now
it's
just
on
a
build
pack
per
build
pack
case.