►
From YouTube: KubeCon EU 2020 – Ben Hale, Terence Lee
Description
Conference talk from KubeCon EU 2020
A
Good
afternoon
everybody
and
welcome
to
building
docker
images
with
cloud
native
build
packs.
My
name
is
ben
hale.
I
lead
the
java
language
on
all
of
the
cloud
platforms
at
vmware
with
me
is
terence.
B
A
A
We
see
over
and
over
again
that
as
the
languages
and
frameworks
that
we
use
proliferate
within
our
development
teams,
it's
becoming
harder
and
harder
to
treat
application
artifacts,
as
the
immutable
artifacts
have
passed
to
our
systems
gone
are
the
days
when
we
could
build
a
jar
and
pass
a
jar
through
ci
pass
it
out
through
cd,
pass
it
to
a
production
team.
We
just
don't
get
to
do
that
anymore.
A
Many
of
the
common
languages
that
we
see
people
using
are
actually
interpreted
rather
than
compiled.
This
means
we're
distributing
source
repositories
effectively
rather
than
actual
compiled
single
file
artifacts.
At
the
end,
we
also
see
a
new
trend
in
developers
wanting
to
be
able
to
both
test
their
applications
in
the
environment
that
they're
going
to
run
in.
A
This
is
a
really
good
idea,
but
also
have
full
control
of
that
environment
that
their
applications
are
running
in,
rather
than
relying
on
another
team
to
configure
that,
for
them
we've
seen
so
many
times
a
development
team
gets
everything
working
on
their
local
development
systems
gets
it
all
working
in
their
qa
environment
throws
it
over
the
wall
to
production
where
something
is
configured
differently
and
everything
breaks.
So
all
of
that
leads
us
to
the
following
statement.
A
What
do
I
mean
by
this
effectively?
What
I'm
saying
is
that
this
is
the
new
immutable
artifact
that
we
want
to
pass
around
and
it's
great
because
it
contains
everything
it
contains
the
operating
system
file
system.
It
contains
the
application
file
system.
It
contains
the
command
that
we're
going
to
actually
run
the
application
with
it
gives
us
a
nice
self-contained
environment
that
runs
exactly
the
same
everywhere.
A
B
Docker
files
are
probably
how
most
people
create
the
docker
images
that
ben's
talking
about
and
they're
great
they're
easy
to
use.
They
provide
a
lot
of
control
to
developer,
but
it's
a
double-edged
sword.
It
requires
a
lot
of
work
to
harden
these
docker
files
for
production
use,
and
you
have
to
resort
to
thing
what
I
like
to
call
dockerfile
gymnastics
as
an
example.
This
the
official
alpine
python
docker
image,
is
137
lines
long
and
the
main
run
command.
That
does.
A
A
The
pax
cli
is
a
command
line
utility
created
by
the
cloud
native,
build
packs
project
that
creates
an
application
image
in
this
case
called
applications
demo
from
some
sort
of
source.
In
this
particular
case,
it's
the
demo01
snapshot
jar
using
a
builder,
so
a
bunch
of
build
packs
in
this
case
called
builders
adopt
open
jdk.
A
A
An
executable
jar
build
pack
has
figured
out
what
the
command
line
for
this
particular
application.
Could
should
be
it's
pretty
conventional
java,
setting
its
classmates
setting
its
java
ops
and
then
calling
a
particular
class
inside
of
it,
and
then
because
we
know
that
this
application
is
a
spring
boot
application.
It
can
come
in
here
and
do
all
sorts
of
things
such
configuration
given
its
web
application
type.
A
In
this
case,
it's
a
reactive
web
application,
contributing
some
things
around
spring
cloud
bindings
slicing
up
the
application
into
multiple
slices,
adding
a
bunch
of
image
labels
to
the
image
itself,
and
then,
when
it's
done,
it
goes
off
and
creates
a
particular
image.
In
this
case,
it's
called
applications
demo
have
tagged
latest
and
we
can
see
that
all
of
that
build
took
only
12
seconds
to
do.
B
That's
built
on
top
of
a
technology
called
build
packs
and
mill
packs
have
been
running
in
productions
on
millions
of
apps
since
2011,
ranging
from
applications
that
are
startups
all
the
way
up
to
enterprises
and
what
they
do
is
they
provide
a
higher
level
abstraction
on
top
of
the
standard
dockerfile
allowing
app
developers
to
do
what
they
do
best,
which
is
delivering
business
value
to
their
customers
and
we're
able
to
do
this
with
a
set
of
features
like
faster
builds
by
using
various
layers,
not
having
to
kind
of
re-run
instructions
that
don't
need
to
be
run
being
able
to
reproduce
those
images
in
a
reliable
way.
B
The
bill
packs
themselves
that
are
being
used
to
actually
build.
These
images
can
be
modular
and
composable
and,
at
the
end
of
the
day,
we're
producing
a
docker
image
similar
to
how
dockerfile
also
produces
docker
images,
and
that
makes
them
portable
via
the
oci
standard.
That
ben
was
talking
about
before,
so
we're
going
to
go
and
take
a
deeper
dive
or
second
look
at
cloudant,
build
packs
and
kind
of
look
into
these
features
in
more
detail.
A
So
terrance
just
listed
off
a
whole
bunch
of
different
things
that
build
packs
can
do
that
are
kind
of
advantages.
You
might
say
over
something
like
a
normal
docker
file.
So
let's
take
a
look
at
the
first
one.
What
does
it
mean
to
reuse
layers?
So
what
we're
going
to
do
is
we're
going
to
rerun
the
exact
same
command
we
ran
previously,
so
we're
going
to
do
that
build
we
see.
Detection
pick
the
same
five
build
packs,
but
this
time
we
see
something
even
more
interesting.
A
We
see
that
as
we
analyze
the
previously
existing
image,
it
noticed
that
there
was
a
bunch
of
layers
that
already
existed.
We
download
the
metadata,
not
the
data
from
those
layers,
but
just
the
metadata
which
gives
us
the
ability,
in
this
case
the
adopt
open,
jdk,
build
pack
to
say,
hey
I've
already
delivered
version
11.0.8.
A
I
don't
need
to
do
it
again.
What
I
want
you
to
do
is
create
an
image
but
use
the
layer
that
already
existed
in
that
image
same
thing
in
the
spring
boot
application.
I
already
did
the
work
I
needed
to
do
because
of
the
web
application
type
or
around
spring
cloud
bindings,
so
I
don't
need
to
do
those
again.
A
I
don't
need
to
transfer
that
data
and
what
we
see
now
is
that
that
same,
build
that
took
more
than
10
seconds
last
time
has
immediately
shrunk
to
six
seconds,
so
we're
probably
seeing
it
being
twice
as
fast
the
second
time
around,
but
that's
not
the
only
kind
of
advantage
we
can
get
that
kind
of
layer
reuse.
We
can
also
take
a
look
at
what
exactly
is
going
to
be
used
when
builds
happen.
A
The
first
one
here
this
is
the
adopt
open,
jdk
build
pack,
you
can
remember,
we
saw
the
executable
jar
build
back
participate,
we
saw
the
spring
boot,
build
pack
participate
as
well,
and
there
are
many
others
that
chose
not
to
participate
but
could
have
if
we'd,
given
it
a
different
set
of
of
input.
A
Let's
take
a
look
at
a
bellsoft
liberica
builder
bellsoft
liberic
is
just
another
distribution
of
java
like
adopt
open,
jdk
or
oracle
or
sap
or
any
of
a
number
of
others,
and
what
we'll
see
is
because
of
the
way
the
build
packs
are
built
in
a
modular
way
and
the
way
we
compose
them
most
of
the
build
packs
14
of
the
15
build
packs
that
were
in.
There
are
exactly
the
same
as
they
were
before,
but
we've
been
able
to
replace
just
the
java
distribution
that
we
want
to
use
say
we
support
contract
with
bellsoft.
A
A
If
there's
any
changes
to
the
way
memory
calculation
is
done
or
certificates
are
loaded,
those
all
are
recontributed
as
well,
but
only
this
build
pack
has
changed.
If
we
take
a
look
at
the
spring
boot
build
pack,
we
get
to
reuse
those
previously
cache
layers,
because
this
build
pack
is
orthogonal
to
the
java
build
pack
itself.
A
A
So
if
we
take
a
look
at
the
first
couple
of
layers
of
this
application,
you'll
start
recognizing
that
file
system
on
the
right
as
the
kind
of
thing
that
typically
gets
built
when
you're
installing
a
new
operating
system
installing
a
set
of
packages.
What
you're
actually
seeing
here
is
a
standard,
ubuntu,
bionic
installation
with
all
of
the
packages
that
normally
come
with
that.
We
then
take
that
stack
image
which
basically
that
base
os,
and
we
will
instead
we'll
then
start
putting
stuff
on
it.
A
The
first
thing
we
put
on
it
is
the
launcher,
and
the
launcher
is
a
bit
of
the
life
cycle
that
we
leave
inside
your
application,
that's
responsible
for
guaranteeing
that
the
environment
is
set
up
right
and
that
we
start
your
application
with
the
proper
command
line.
Every
time
you
try
and
run
with
this
particular
image,
but
then
we
also
start
seeing
the
build
packs
themselves
are
contributing
things.
We
see
the
bellsoft
librarica
build
packet
installs.
This
thing
called
a
class
counter
some
stuff
around
java
ops.
A
Eventually
it
installs
an
entire
jre
side
of
this
particular
image.
140
megs
there,
but
we
go
even
further
than
that.
We
can
see
the
executable
jar
does
some
stuff
with
the
class
path.
That's
what
we
see
over
here
on
the
right
with
this
class
path
environment
at
launch.
We
see
spring
cloud
bindings
go
in.
We
see
the
thing
that
it's
going
to
make
a
change,
because
this
happens
to
be
a
reactive
web
application
type
and
then
eventually
we
get
to
the
point
where
we
see
our
application
as
well.
A
In
this
particular
case,
spring
boot
applications
are
really
well
known.
They
understand
what
it
means
to
go
into
an
image,
and
so
they
actually
can
be
sliced
up.
We
effectively
have
a
layer
that
has
all
of
your
dependencies
on
it,
another
one
that
has
the
boot
loader
application.
If
there
were
snapshot
dependencies,
we
put
that
on
a
layer,
another
layer
here
that
is
the
classes
of
your
particular
application,
in
this
case
a
demo
application
all
of
these
end
up
on
separate
layers,
and
that
may
seem
like
a
little
bit
of
overkill.
A
A
A
Can
use
that
exact
same
image
as
you
see
right
here.
This
is
normal
kubernetes
deployment.
Descriptor
says
exactly
what
my
container
is
going
to
be
sets,
for
example,
the
the
probe.
So
we
know
when
the
application
is
live
and
ready,
but
we're
going
to
use
the
exact
same
image
in
this
particular
case.
It's
going
to
start
the
exact
same
start
command.
It's
going
to
do
it
with
the
exact
same
environment
variable
set.
All
of
that's
embedded
inside
of
that
image.
It'll
run
here,
it'll
run
on
heroku
it'll
run
on
cloud.
B
So
all
this
is
great
for
your.
You
know
app
as
an
application
developer
you're,
you
know,
building
these
images.
But
what
do
you
have
to
what
happens
when
you
actually
have
to
run
these
images
in
production?
What
do
cloud-native
build?
Packs,
get
you,
and
one
of
the
nice
things
is
that
with
planet
build
packs
and
the
way
we
build
our
applications
through
the
layers
and
stuff
that
you
saw
get
contributed
in
a
very
specific
way.
B
Is
that
how
we
build
them
is
actually
standardized,
and
that
provides
a
lot
of
benefits
to
operators
who
need
to
actually
deal
with
stuff
like
compliance
and
security
of
your
application
image
once
it's
running
in
production
and
that
allows
us
to
help
with
kind
of
like
two
main
features
that
we
provide
as
part
of
the
climate
bill
packs
ecosystem.
B
B
You
can
actually
see
what's
in
that
particular
image
as
well
as
a
feature
that
we
like
to
call
git
rebase,
so
think,
along
the
lines
of
like
what
you
do
when
you
have
a
git
rebase
and
so
the
oc
image
spec
has
ordered
pointers
for
various
layers,
and
this
is
different
from
kind
of
the
older
docker
image,
v1
spec,
which
treated
them
as
kind
of
this
tree-like
structure,
which
meant
that
if
you're
changing
that,
like
kind
of
from
line
when
you're
gonna
do
an
operating
system
manage
update,
you
actually
have
to
rebuild
the
entire
tree
because,
like
your
parent
root
tree
is
now
different.
B
So
you
can't
like
make
any
assumptions
about
kind
of
the
child
properties,
they're,
all
all
invited
and
validated.
But
one
nice
things
with
this
new
oca
image
manifest.
Is
that
they're
pointers?
And
so
that
means
that
if
you
have
stack
images
built
on
top
of
operating
systems
that
comply
to
this
application,
binary
interface
compatibility.
B
So,
basically,
when
you
update
your
operating
system
from
one
version
to
the
next,
if
the
aba
interface
hasn't
changed,
you
don't
actually
have
to
rebuild
all
those
layers
on
top
of
kind
of
your
stack
image
because
they
comply
with
the
same
avi
interface,
and
so
what
this
looks
like
in
practice.
If
we
take
a
sample,
node
build
pack,
that's
building
a
node
application
are
at
the
node.js
layers.
Complied
this
avi
compatibility
against
this
operating
system,
and
it
once
we
need
to
update
this
operating
system.
B
It's
going
to
have
an
abi
compatible
operating
system
update,
and
that
means
we
can
actually
do
a
lift
and
shift
and
just
rewrite
the
manifest
layer
which
is
this
json
text
file
with
pointing
to
the
new
layers,
which
massively
speeds
up
the
image
update,
as
well
as
the
push
to
the
registry
when
we
actually
have
to
push
these
layers
up
and
this
scales
really
well,
when
you
do
this
across
an
enterprise
fleet
of
you
know,
thousands
or
tens
of
thousands
of
images,
so
ben's
gonna
go
ahead
and
show
what
kind
of
these
day
two
operations
look
like,
while
using
cloudmate
builtpacks.
A
So
this
next
demo
here
is
gonna
focus
less
on
application
developers.
Although
this
information
that
we're
going
to
see
is
pretty
interesting
and
it's
going
to
focus
more
on
what
your
applications
can
do
to
help
the
operations
teams
that
are
around
you.
So
one
of
the
really
really
interesting
questions
that
a
lot
of
security
teams
and
compliance
teams
really
care
about
our.
A
So
inspect
image
allows
us
to
take
a
look
at
some
information
about
the
the
image
itself,
so
give
it
a
second
it
comes
in.
It
tells
us
of
all
of
those
15
build
packs.
Here
were
the
five
that
were
going
to
do
their
thing
right.
We
saw
bellsoft
liberica,
executable
jar,
all
of
these
things
participated
and
we
can
even
see
which
versions
they
were
and
we
can
see
the
command
that
was
going
to
get
run.
This
is
all
embedded
in
metadata
on
the
image.
A
One
of
the
key
things
about
this
information
is
we
get
this
not
by
downloading
the
entire
image.
All
you
know,
hundred
megs
or
whatever
it
is.
We
download
a
very
small
amount
of
data,
a
couple
of
tens
of
k
effectively
that
contain
all
of
this.
It
allows
our
compliance
teams
to
iterate
over
large
numbers
of
images
currently
in
production
and
ensure
that
they
are
what
they
think
they
are
find
out
if
there
are
any
existing
vulnerabilities.
A
So
this
is
the
kind
of
information
about
what
exactly
was
run
to
build
this
particular
image,
but
we
can
go
further
than
that
as
well.
We
can
say
pack
inspect
images
and
we
can
take
a
look
at
something:
we
call
the
bill
of
materials.
So
whenever
an
image
is
created
by
specification,
the
the
build
packs
can
contribute
and
say:
hey
here
are
some
things
that
we
put
into
this
particular
image.
A
So,
for
example,
we
can
take
a
look
and
see
that
we
put
in
bellsoft
liberica
version
11.08,
here's
where
we
would
have
downloaded
it
from
if
we
needed
to
download
it.
If
you
want
to
validate
it,
here's
the
jaw256
hash
of
that
we
can
even
tell
you
what
the
license
was
for
this
dependency
that
we've
put
into
your
image.
A
If
you
want
to
do
sort
of
license
compliance
kind
of
testing-
and
we
do
that
for
absolutely
everything
that
we
put
into
the
build
pack
itself,
our
memory
calculator,
the
class
counter
things
about
how
we
configure
link
local
dns,
all
sorts
of
things
that
come
from
the
build
packs,
but
even
beyond
things
that
come
from
the
build
packs.
So,
for
example,
here
are
a
set
of
dependencies
that
your
application
contains.
So
if
you're
running
a
normal
spring,
boot
application,
probably
you're,
writing
a
rest
api
that
returns
json,
payloads.
A
A
You've
got
to
move
a
lot
of
bytes
to
do
that
or
you
can
take
a
look
at
this
metadata
and
the
bill
of
materials
that
we've
attached
and
we
can
find
out
that
you're
using
jackson,
core
version
2.11.0
again,
if
you
aren't
trust
trustworthy
of
our
metadata
here-
is
the
hash
you
can
go
and
validate.
That
hash
is
exactly
the
version
that
we
claimed
it
was,
and
it
goes
beyond
that
right,
you're,
you're,
a
spring
user
right.
So
let's
go
ahead
and
take
a
look
down
here
in
spring
spring.
Boot
version
2.3.0.
A
So,
in
addition
to
the
metadata
about
how
we
built
this,
we
also
have
metadata
about
what
exactly
we
put
into
it
when
we
did
the
build,
but
also
what
we
were
presented
with,
what
our
application
was
when
it
was
built,
we
don't
have
to
sort
of
look
back
and
try
and
corroborate
this
with
a
give
and
commit
and
figure
out
what
the
answer
is.
We
look
this
up
during
the
build
and
we
put
it
on
as
metadata
that
can
be
inspected
in
a
very
light
and
quick
way.
A
The
final
thing
that
we
we
talked
about
as
an
operator
feature
is
something
called
rebasing
and
so
rebasing,
as
we
said,
is
the
act
of
taking
a
a
a
bunch
of
layers
that
comprise
things
that
are
contributed
by
the
build
pack,
as
well
as
your
application
that
sit
on
top
of
an
operating
system
and
move
all
of
those
to
a
different
version
of
the
same
abi
compatible
operating
system.
So
in
this
case,
I'm
going
to
put
the
time
command
on
the
front
of
it.
A
So
we
can
find
out
exactly
how
long
something
like
this
takes,
but
we're
going
to
do
a
time
pack
rebase
we're
rebasing
that
applications
demo
we're
going
to
change
what
the
run
image
is
underneath
it
in
this
particular
case
we're
going
to
a
different
version.
This
version
is
0
0,
4
7,
which
is
a
slightly
newer
version
than
the
one
we've
been
doing,
the
the
demo
on
so
far.
A
And
so,
if
we
take
a
look
at
what
the
time
says,
we
we
managed
to
change
the
operating
system
underneath
this
entire
application
in
1.39
seconds
right.
If
we
were
working
against
a
registry.
This
is
a
weird
oddity
of
using
a
docker
demon.
It's
actually
much
slower
to
do
it
locally
against
the
docker
demon.
A
If
we
were
doing
this
against
a
real
live
docker
registry,
even
a
docker
registry
over
a
network
link,
we
would
have
expected
this
to
be
closer
to
a
quarter
to
a
tenth
of
a
second
to
actually
get
this
done,
because
we're
transferring
back
and
forth
very
small
bits
of
metadata,
like
on
the
order
of
three
or
four
kilobytes
of
metadata
versus
hundreds
of
megs
of
data
being
transferred.
A
But,
most
importantly,
we
didn't
execute
any
of
the
rest
of
the
build
we
didn't
have
to
untar
or
unjar
the
the
application
we
didn't
have
to
untar
the
jre
we
didn't
have
to
do
any
install
around
file
system.
We
transferred
almost
no
data
back
and
forth.
B
So
that's
great
we've
been
doing
a
ton
of
stuff
with
this
tax.
Cli
and
pac
is
really
just
a
platform,
but
really
you
know
built
for
your
local
cli
for
your
local
development,
but
that's
not
the
only
place
you
can
run
build
packs,
build
packs
are
out
there
in
the
wild
being
used
by
the
address
ring
cloud
on
google
app
engine,
it's
running
on
roku.
B
You
know
vmware
and
kpac,
even
all
the
way
to
java
frameworks
like
spring
boot
that
are
using
it
and
really
targeted
towards
developer
productivity,
and
so
we're
gonna
demo
and
show
what
it
looks
like
to
actually,
if
you're
a
spring
boot
developer,
what
it
takes
to
actually
just
build
a
docker
image
that
is
ready
for
production.
A
So,
as
terrance
said,
spring
boot
can
act
as
just
another
platform,
the
same
way
that
we
consider
the
pax
cli
to
be
one
platform.
The
same
way
we
consider
vmware's
kpac
to
be
a
platform
or
heroku
to
be
a
platform.
It
turns
out
that
platforms
can
come
in
all
shapes
and
sizes.
One
of
my
favorite
platforms,
given
my
history
as
a
member
of
the
spring
team,
is
actually
spring
boots.
Maven
plug-in
can
be
a
platform,
so
in
this
particular
case
we're
going
to
go
ahead
and
run
a
maven
command.
A
Maven
test
skip
spring
boot,
build
image,
and
what
this
does
is
it
goes
off
to
maven,
as
you
normally
expect
it
to,
and
it
actually
builds
this
jar
file
for
us
right.
The
the
last
thing
we
see
is
here
is
where
it's
jarring
up
the
application
itself,
and
then
it
immediately
kicks
off
a
build
right
like
internally.
Without
you
ever
leaving
maven,
you
could
have
done
the
same
thing
with
gradle
as
well.
We
see
that
exact
same
output,
detecting
a
bunch
of
build
packs,
contributing
the
jre
to
the
layer
in
this
particular
case.
A
It's
jerry8
because
that's
how
we
we
built
this
particular
application.
We
have
this
command
that
we
ran
all
of
spring
boot.
Stuff
gets
added
image,
labels
open
container,
and
we
see
that
it
actually
created
this
particular
image.
One
of
the
really
cool
things
that
building
an
image
this
way
does
because
it's
inside
of
a
running,
build
system.
It
can
learn
things,
it
knows
which
version
of
java
you
actually
want.
Is
this
a
java
8
application?
Is
it
a
java
11
application?
Is
it
a
java,
14
application?
A
A
B
Built
so
in
closing
platinum,
bill
packs
brings
a
ton
of
advantages
to
build
packs
in
this
docker
image
world
through
some
of
the
features
that
we've
showed
throughout.
This
talk
like
faster,
builds
reproducible
images
being
able
to
reuse
the
various
layers
and
what
have
you?
In
addition,
it
provides
because
of
our
standardization
higher
level,
abstraction
things
that
docker
files
simply
can't
do
and
that's
not
because
docker
files
are
efficient.
It's
just
that
our
standardization
allows
us
to
have
things
like
composability
that
you
just
can't
have
with
all
that
power
and
flexibility.
B
Things
like
the
build
materials
that
the
bill
packs
can
provide
as
well
as
stuff
like
rebasing
saving
you
a
bunch
of
time
when
you
actually
need
to
do
image
updates
across
your
entire
fleet
and
it's
common
build
packs
are
available
through
local
development
through
tools
like
pac,
as
well
as
various
cloud
providers
out
there,
and
one
of
the
big
goals
that
we're
trying
to
achieve
with
this
project
is
new
developers
where
they
are,
which
is
right
at
their
application,
where
they're
focused
on
delivering
value
to
their
customers,
so
go
out
and
try
climate
bill
packs
a
day.
B
We
have
version
point
12
of
the
paxy
line,
just
go
through
brew,
or
what
have
you
to
go?
Install
that
pax
cli
go
to
our
documentation,
we're
fairly
active
on
slack,
where
a
lot
of
the
kind
of
conversations
around
development
outside
of
github
are
as
well
as
join
our
mailing
list,
where
you
can
get
the
announcements
and
various
things
as
cloudmin
build
packs
are
being
developed.