►
Description
An introduction to Cloud Native Buildpacks. We're going to look at how to build containers without dockerfiles using the CNCF adopted Cloud Native Buildpacks project. We'll dive into what they are and how they work before moving on to using them both locally and as kubernetes resources to manage the lifecycle of our containers.
Jason Morgan, a Solutions Engineer with VMware, focuses on helping customers build and mature microservices platforms. Passionate about helping others on their cloud native journey, Jason enjoys sharing lessons learned with the broader developer community.
A
B
Well,
hey
folks,
like,
like
you
said,
I'm
I'm
jason
solutions,
engineer
with
vmware
and
I
specialize
in
how
to
how
to
do
ci
cd
in
the
space
around
kubernetes
right.
So
my
particular
areas
of
focus
are
or
are
we
in
cloud-native
build
packs
right
and
running
and
managing
containerized
apps
on
kubernetes
yeah.
So
I
know
I
know
drew
said
a
bit
about
it,
but
I
can
tell
you
for
me
personally
right
like
I
don't
I
don't
function
well
just
talking
at
folks.
So
I
really
appreciate
questions
interruptions.
B
You
know
there's
a
little
bit
a
little
bit
of
this
is
is
kind
of
pre-scripted
and
then
a
lot
of
it
is
is
really
dynamic.
So
we
can
hop
into
whiteboards.
We
can
do
stuff
at
the
terminal.
It's
really
it's
really
your
session.
So
I'd
appreciate
as
much
interaction
as
we
can
get
and
I
was
gonna
plug.
I
was
gonna,
go
plug
another
dc
area
meetup,
but
I
won't
do
it
since
you're,
recording
it
I'll,
maybe
throw
something
in
after
the
fact
all
right.
B
Right
that
is
actually
not
as
many
people
as
I
thought
all
right,
all
right,
so
I'll,
just
I'll
just
step
back
and
talk
about
containers.
Real,
quick
right
like
so
containers
are
a
tool
for
packaging
up
some
application,
along
with
its
dependencies
right,
they're
they're,
similar
in
structure
to
a
to
a
virtual
machine,
or
in
the
sense
that
you
can
kind
of
bundle
all
your
stuff
together,
but
they
they
don't
have
the
same
isolation
as
a
virtual
machine
right
or
the
same.
B
A
B
B
B
B
So
here
I've
got
a
docker
file
for
for
downloading
and
compiling
a
downloading
and
compiling
a
a
spring
boot
app
called
spring
pet
clinic
right.
So
this
is.
This
is
a
like
a
relatively
simple,
simple,
docker
file,
but
it's
still
an
example
of
what
we
call
multi-stage
builds
where
we
run
multiple
containers
to
get
our
end.
Output
of
you
know
the
application
we
want
ready.
B
B
All
right,
so
I'm
going
to
go
ahead
and
show
you
some
slides
that
a
friend
of
mine,
corey,
abraclide,
put
together
for
a
talk.
She
did
at
a
at
a
recent
conference
around
around
this
kind
of
topic
right
and
I'll
be
happy
to
send
along
the
actual
actual
recording
of
her
talk.
If
y'all
want
to
see
it
and
she
goes
into
a
lot
more
depth
than
I'm
going
to
go
into.
B
Let
me
find
my
little
laser
pointer
all
right,
so
I
want
to
talk
about
about
how
we're
going
to
build,
build
these
applications
without
docker
files
right
so
back.
You
know
back
in
2011,
right,
heroku
introduced
the
concept
of
build
packs
right
and
heroku
cloud
foundry.
A
couple
other
couple.
Other
implementations
are
examples
of
something
called
a
paths
or
platform
as
a
service.
B
Right
now,
paz
came
about
with
the
idea
that
you
know
I
used
to
be
at
a
company
called
pivotal
and
pivotal
used
to
have
this
this
little
haiku
that
we
we
talked
about
for
you
know,
running
containerized
applications
and,
and
the
haiku
goes
here's
my
code
run
it
in
the
cloud.
For
me,
I
do
not
care
how
and
the
way
we
the
way
we
accomplished
that
was
our
our
environment.
B
Our
container
environment
could
inspect
your
code,
build
it
into
a
container,
run
it
on
a
machine
and
then
wire
up
http
routing
certificates,
logging,
everything
you
need
to
run
your
application,
we
do
it,
we
do
it
for
you,
hoku
did
did
the
same
sort
of
thing
and
the
way
they
did
that
was
was
build.
Packs
and
build
packs
were
great,
but
there
were
some
real
downsides.
B
One
predating
predating
docker
right.
They
weren't
creating
images
that
were
in
a
portable
format
right.
So
a
little
bit
more
history
right,
docker
came
about
as
as
the
kind
of
company
that
popularized
making
it
easy
to
run
and
distribute
these
container
images
around
right,
but
they
weren't
they
weren't
really
alone.
B
At
the
time
right,
there
was
another
tool
competing
called
rocket,
which
is
also
a
very
well
a
somewhat
popular
way
to
do
this
right
and
so
docker
and
rocket
got
together
in
2013
2014
somewhere
in
there
to
create
a
common
specification
for
these
containers
and
for
the
container
registries,
the
places
where
we
store
these.
These
containers-
that's
called
the
open
container
initiative
specification,
not
real.
B
At
this
point
right,
we
we
found
ways
to
find
ways
to
improve
that
that
life
cycle
around
the
container,
which
we're
going
to
get
into
a
little
bit
more
depth,
the
biggest
one
is
using
using
cloud
native,
build
packs.
You
can.
You
can
share
the
layers
of
your
container,
so
let
me
actually
step
back
a
little
bit
a
container.
B
You
look
at
it.
You
see
it
like
an
archive
typically
right,
but
a
container
is
really
a
stack
of
archives,
one
on
top
of
the
other
referenced
by
a
common,
manifest
right.
That
describes
describes,
what's
what's
in
it
right.
So
when
I
go
to
show
a
quick
example
when
I
do
doctor
pull
nginx
right.
What
I
see
is
this
is
a
command
saying,
go
to
a
registry
and
pull
a
file
and
and
these
these
layers
that
you
see
here
on
the
screen.
These
actually
represent
layers
of
of
the
image
itself
right.
B
B
What
we
get
is
as
we
as
we
build
images.
We
can
share
a
lot
of
layers
within
a
single
image,
but
it's
hard
to
share
them
between
images.
So
I
could
build
10
different
images
on
top
of
nginx
right
and
the
only
layers
they
would
share
would
be
those
bass,
nginx
layers
right.
Everything
else
above
that
would
be
unique
for
every
single
image,
so
build
packs
attempt
to
reduce
the
number
of
new
layers
that
we
have
to.
B
So
when
you
see
that
google
cloud
has
a
has
an
implementation
of
this
or
project
techton
has
an
implementation
or
kpac
or
pac
have
implementations.
Those
are
all
examples
of
platforms
right
that
build
your
container
images
and
these
build
packs.
These
are
that
common
common
tool
that
can
be
reused,
no
matter,
no
matter
where
you
are
or
what
what
platform
you're
using
right.
They
are
they're
modular
right.
B
So
that
means
you
can
you
can
assemble
them
together
and
you
can
you
can
write
your
own
they're,
an
open
standard
but
they're
also
part
of
the
cloud
native
computing
foundation
right,
so
they
were
adopted
by
the
cncf
and
in
fact,
just
yesterday
they
graduated
from
a
sandbox
product
project
to
an
incubating
project
right.
So
that's
just
they're
going
up
the
cncf
maturity
cycle
for
four
projects
for
open
source
projects.
B
You
take
you,
take
these
build
packs
and
you
pair
them
with
with
two
container
images
very
similar
to
that
that,
from
line
that
you
saw
in
that
previous
previous
file,
sorry
someone's
waiting
to
get
in
admit
you
pair
them
with
with
two
two
container
images,
one
that
is
there
to
do
to
do
build
time,
tasks
right!
That's
anything
you
need
for
for
compilation
and
one
slimmer
image
that
you
need
for
actually
running
that
application.
B
B
If
you're
a
spring
boot
user
spring
boot
itself
has
included
cloud
native,
build
packs
into
its
into
maven
and
gradle.
So
you
can
actually
use
your
compilation
tools
to
generate
a
a
particularly
optimized
container
image
for
your
spring
boot
app
there's
a
thing
called
project
techton,
which
is
a
tool
from
the
continuous
delivery
foundation.
B
There
is
there's
a
bunch
of
commercial
products
out
there,
including
tons
of
build
service
tool
from
vmware
microsoft.
Azure
has
built
as
built
pack
or
the
this
build
packs
thing
right
into
their
cli,
and
then
google
cloud
has
a
number
of
different
offerings.
A
couple
aren't
listed
there
digitaloceans
implemented
one
and
I'm
sure
they're.
Oh
sorry,
gitlab
includes
an
implementation
of
build
packs
directly
inside
gitlab's,
auto
devops.
B
So
it's
it's.
It's
a
big
ecosystem
and
it's
getting
bigger
as
far
as
build
packs
right
we've
got,
we've
got
the
open
source
paquetto
build
packs,
which
are
what
we're
gonna
we're
gonna
look
at
today.
You
have,
you
have
heroku
the
other
company
that
was
involved
in
creating
this
standard.
They
publish
and
maintain
their
own
build
packs.
Google
platform
has
has
their
own
build
backs,
they're,
also
open
source
vmware
town
zoo
has
some
has
some
proprietary
build
packs
that
you
can
buy?
B
A
D
B
Yeah,
so
what
you're,
what
you're
getting?
Is
the
ability
to
convert
your
code
into
a
container
image
without
actually
having
to
learn
to
write
a
docker
file
yourself
on
on
top
of
that
you're
going
to
get
some
some
things
around
building
a
container
that
would
actually
be
fairly
complex
to
implement
yourself
with
a
docker
image
and
one
thing:
I'm
gonna
gonna
recommend
sorry,
not
this
one.
So
my
my
colleague,
corey
abreclide,
has
a
great
course
here
on
cube
academy.
That's
free
that
really
goes
into
depth.
So
it's
it's!
B
It's
over
an
hour
of
you
know.
How
do
you
build
images
with
with
docker
files?
How
do
you
implement
multi-stage
builds?
How
do
you
get
a
lot
of
efficiency
out
of
it?
Then
she
shows
doing
the
same
thing
with
with
pac
right
vishal.
I
don't
believe
that
aws
has
an
implementation
of
it,
but
they're
the
only
cloud
provider
that
I
know
of
that
doesn't.
E
Sorry,
yes,
sorry
for
the
interrupt
from
pharmacy's
question.
I
think
it's
also
correct
me
if
I'm
wrong
jason,
it's
also
like
a
declarative
versus
imperative
approach,
like
everything
in
the
in
the
in
the
industry,
is
shifting
away
from
telling
machines
exactly
how
to
do
things
and
we're
just
telling
them
what
we
want
instead,
like
like
kubernetes
manifest
files
are
just
simple
yaml
files
that
describe
what
we
want
and
build
packs
are
taking
that
same
approach.
B
I'd
give
you
some
some
nuance:
only
in
that
pac
can
can
work
or
your
the
tools
around
cloud-native
build
packs
can
work
in
an
imperative
or
declarative
way,
but
moving
it
into
kubernetes.
You
absolutely
get
entirely
that
that
declarative
way
of
working
right.
It
is
a
way
I'll
tell
you
what
you
do
get
and
and
true
to
your
point,
what
one
thing
you
do
get
with
cloud
native
build
packs.
Is
you
get
much
more?
B
Repeatable
builds
to
the
point
that
every
time
you
build
an
image
using
the
same
inputs
and
cloud
native
build
packs,
you
get
exactly
the
same.
The
same
output
to
include
the
the
actual
hash
or
the
description
of
that
bundle
that
you've
created
right,
which
isn't
something
you
can
guarantee
using
using
docker
files
right.
B
B
B
B
All
right
and
we'll
do
a
curl,
that's
lo,
so
I'm
saying
curl
please
follow
because
github
does
redirects,
please
follow
github
to
redirect
and
then
save
me
a
file
called
pac
dot.
I
think
it's
tgz
tell
me
it's
tgz,
yes
got
it.
We
got
it
wrong
last
night
and
then
we
put
down
the
link
right
to
the
package.
We're
getting
and,
of
course
you
change
this
from
linux
to
mac
to
windows,
whatever
you're
going
after
we
grab
it.
We
do.
B
All
right
so
feel
free
to
follow
along,
ask
questions
in
the
chat
or
live
if
you're
stuck
on
any
of
this,
and
we
can,
we
can
go,
take
a
look
at
it.
So
now,
let's
just
dig
in
into
pack
and
see
some
of
what's
available
here
right
got
some
commands
here
we
can,
we
can
build,
which
is
creating
a
new
application.
B
This
thing
called
rebase,
which
is
swapping
out
the
base
layers
in
a
given
in
a
given
application
container
without
modifying
the
layers
above
that
image
right.
So
it's
a
really
fast
rebuild
operation.
We
have
the
ability
to
dig
into
a
given
image
and
look
at
its
metadata,
and
then
we
can.
We
can
dig
into
our
build
packs
right.
B
So
we
remember
we
have
the
concept
of
of
that
base
image,
that
we
call
a
stack
right
that
that
concept
of
the
build
packs
which
actually
do
the
job
like
inspect
our
code,
see
what
language
we're
working
with.
Do
the
compilation
and
then
contribute
the
layers
that
we
need
to
actually
run
our
application
saying
this
sound
like
something
you
want
to
see
on
a
whiteboard
for
a
second.
Are
we
cool
to
just
roll
through
with
a
demo.
B
All
right
so
to
start
out
in
order
to
use
pack
we're
gonna
need
we're.
Gonna
need
two
things:
we
need
source
code
and
we're
gonna
need
a
builder
okay,
so
I've
got
I've
got
two
bits
of
source
code.
I
went
and
downloaded
this
this
spring
pet
clinic
app
right,
which
you
can
get
right
here.
I
should
have
had
that
link
available.
B
B
So,
let's
start
out,
let's
do
pack
suggest
dash
builders,
okay,
so
we're
gonna
ask
pack
what
what
are
some
options
that
I
have
for
building,
building
images
right.
Well,
I've
got
a
bunch.
I've
got
I've
got
a
build
pack
from
google.
I've
got
my
heroku
build
pack,
and
I've
got
a
few
options
from
from
picato
right
out
the
gate,
so
we're
going
to
go
ahead
and
use
picato
full
and
we're
going
to
do
pack.
B
B
B
And-
and
that's
it
right,
you
go
look
at
that
spring
pet
clinic
repository,
there's,
no
there's
no
there's
no
docker
file
in
there.
I
didn't
tell
it
what
language
I
was
looking
at
right.
I
just
gave
it
a
repository
with
source
code
and
it's
going
to
build
it
for
me
right.
It's
gonna,
it's
gonna
automatically,
give
me
a
multi-stage
build.
B
So
it's
gonna,
it's
gonna,
compile
this
this
java
app
for
me
right
using
maven
or
gradle,
I'm
not
even
sure
which
right
I'm
kidding,
I
am
sure
which,
but
I
don't
need
to
know
in
order
to
do
this
right.
Then
it's
gonna,
it's
gonna,
put
my
compiled
jar
in
a
very
in
a
slimmed
down,
runtime
container.
That
has
only
what
I
need
to
run
it.
That
was
really
fast.
I
I
did
this
earlier,
so
it
cast
it.
B
It
normally
takes
about
five
to
ten
minutes,
to
build
probably
about
five
minutes
to
build
a
spring
boot
up
because
pulling
down
everything
from
maven
takes
a
really
long
time.
Nice
thing,
because
because
I've
already
built
it
here,
it
had
a
cache
right.
So
we
can
look
up
a
little
bit
and
it
saw
that
it
cached
things
around
around
how
to
build
this
application.
Various
layers
that
I
need
for
this
image
were
cached
locally
and
say
so.
They
just
got
reused
automatically
right
without
me
having
to
specify
anything.
B
So
I
got
a
fairly
efficient
build
right
if
you
calm
down
that
sample
app
right.
So
if
you
did
the
git
clone
samples
you
can
you
can
head
in
here,
you
can
check
out
there's
a
number
of
different
languages
in
everything
from
from
net
core
to
node.js
php,
you
can
do
golang
doesn't
really
matter
we're
going
to
do
a
node.js
app,
so
cd
node.js
check
out
they've
got
an
npm
version
and
a
yarn
version.
B
B
B
B
If
you
look
at,
if
you
look
at
images
built
with
cloud-native,
build
packs,
they'll
all
say
they
were
built
40
years
ago,
which
is
the
start
of
epoch
time
for
windows
or
linux,
I'm
not
sure
which
and
the
reason
they
do.
That
is
every
bit
every
bit
of
data
you
attach
to
a
container
changes
the
the
checksum
value
of
that
container.
So
in
order
to
make
them
fully
repeatable
the
the
build
time
is
always
set
statically
right,
so
it
doesn't
ever
it
doesn't
ever
change.
B
Now,
as
you
push
these
things
to
your
registry
they'll,
your
registry
will
record
what
time
they
were
pushed
provided
using
like
a
an
enterprise
registry,
but
so
you'll
have
you'll
have
that
that
data
about
it
so
down
here
I
built
my
I
built
my
node
app.
While
I
was
talking
and
again
I
don't.
I
don't
even
know
how
to
compile
a
node
app
right,
but
we're
gonna,
we're
gonna,
launch
it
and
we're
gonna
run
it
right.
B
B
I've
got
I've,
got
a
container
launched.
I've
got
container
launch
that
was
built
with
a
multi-stage,
build
you
know
in
this
environment,
so
that's
kind
of
the
that's
kind
of
the
key
concept
we
can
do
it.
We
keep
going
around
with
whatever
language
and
in
none
of
these
in
none
of
these
spots
will
you
find
a
docker
file
right
because
again
like?
If,
if
I'm,
if
I'm
someone
who
writes
application
code
right
like
I
don't,
I
don't
actually
care,
I
actually
care
about
the
wiring
to
get
my
application
built.
B
I
care
about
the
business
logic
that
I'm
putting
into
my
application
and
cloud-native
build
packs.
Allow
you,
as
an
organization
to
provide
to
provide
a
standardized
interface
for
building
for
building
containers,
and
they
allow
you
to
do
it
in
a
way
where,
where
any
improvements
you
make
to
the
build
process
you
put
into
these,
you
put
into
these
build
packs,
and
then
you
share
that
that
improved
build
process
contractually
with
your
whole
environment
right.
So
let's
take
an
example.
I
had
a
customer
right.
They
they
were.
B
They
were
talking
in
a
meeting
about
how
they
were
really
good
at
building.
Flask
apps
python,
flask
apps
in
in
containers
like
like,
listen
like
we're
way
ahead.
I
don't
want
to
share
a
build
process
with
with
the
rest
of
my
organization
because
they
don't
know
what
they're
doing
right.
If
they
want
to
transfer
that
knowledge
about
how
to
build
the
better
flask
app
they
do.
B
What
right
like
go,
do
lunch
and
learns
talk
to
their
colleagues,
maybe
submit
pull,
requests
or
repositories
whatever
that
may
be,
but
if,
instead
of
using
docker
files,
I've
got
I'm
leaning
on
cloud-native,
build
packs
and
that
my
organization
has
a
central
store
for
these
builders
and
these
build
packs.
I
can
build
a
flask,
build,
build
pack,
contributed
to
that
central
store
and
then,
when
I
make
that
improvement
with
how
it's
done,
everyone
in
my
organization
gets
to
consume
that
programmatically
without
having
to
learn
anything
about
building
flask
apps.
B
E
I
think
it's
cool
nice,
like
I've
like
I've,
lived
lives
where
I
was
the
guy
riding
the
the
doctor
files
for
every
application.
It's
like
literally
one
for
one
and
it's
it's
freaking
torture.
I
mean
it
was
especially
painful
when
you
had
the
one
hipster
who
decided
to
try
using
this
one
variant
of
a
debian
based
os
image
and
like
because
he
needed
some
dependency
in
there,
and
you
literally
couldn't
port
it
over
onto
the
centos
image
that
everybody
else
was
using.
B
Cool
well
that
sucks,
but
I
mean
you
know
it's
better
now,
yeah
all
right,
let's
see
if
I've
got
any
more
of
those
slides,
I
think
I
lost
it
all
right.
Well,
we
don't
really
need
the
slide
deck
anymore.
So
that's
our
process.
A
couple
other
neat
things
that
you
get
like
some
some
free
stuff
you
get
with
with
cloud
native,
build
packs
right
that
you
don't
you
don't
see.
Otherwise.
I
just
want
to
show
you
this
real
quick
for
those
that
have
an
interest
in
security.
B
I
know
judy
that
seems
to
be
seems
to
be
a
strong
suit
of
yours
right,
but
for
those
that
are
are
in
a
regulated
environment
right
and
you
need
to
be
able
to
surface
hey.
What's
the
content
of
this
container,
what
am
I
building?
What
am
I
using
right
in
in
in
live
production
images
right
when
I
look
at
something
like
like
alpine
right,
so
this
is
the
official
alpine
image
from
docker
hub
right
and
I
pipe
it
over
to
I
pipe
it
over
to
a
command
to.
B
Let
me
take
a
look
at
it
right
I
can
see.
I
can
see
some
data
about
this
container
right,
I
see
when
it
was
created,
cool
a
little
bit
of
like
what's
the
command,
what
environment
files
or
what
environment
variables
that
they
inject
at
build
time.
Docker
version
cool
right
but
like
this
is
alpine
right.
Apk
has
a
major
vulnerability.
How
do
I
know
if
this
container
has
the
apk
vulnerability?
B
I
don't
know
right,
I'm
gonna
have
to
scan
it
and
and
find
out,
because
the
versions
of
the
things
that
were
included
in
the
build
of
this
container
are
entirely
opaque.
To
me
right,
my
container
is
a
black
box
and
I
can
do
some
after
the
fact
analysis
on
compiled
artifacts,
but
I
don't
know
I
don't
know.
B
B
So
here
we've
got
our
newly
built,
our
newly
built
pet
clinic
app
right,
so
basically
you're
seeing
the
same
info
right
right
up
until
we
get
to
the
metadata
section
right.
We
see
just
this
unbelievable
wall
of
text
right
and
I'm
kind
of
scrolling
through
fast
here,
but
I'll
show.
You
I'll
show
you
this
in
a
jq
statement
in
a
second
right.
B
I've
got
everything
I
need
to
know
about
this
container
from
from
what
things
were
included
in
it
right
this,
this
life
cycle
metadata
to
down
to
like
what
you
know
what
git
commit
id
triggered
the
build.
Let's
see
where
do
I
get?
Let
me
get
the
git
commit
it's
just
a
ton
right
like
everything
I
could
want
to
know
about
this
image,
including
every
bit
about
the
about
the
osl
licenses.
B
Jesus.
I
didn't
think
it
was
this
long.
Let
me
just
get
out
is
is
just
tattooed
on
my
image,
so
I
go
run
this
in
kubernetes.
I
go
run
it
in
docker
swarm.
I
go
run
it
anywhere
right.
If
I
want
to
know
what's
included,
I
can
just
take
that
inspect
info
pipe
it
over
to
jq
and
start
seeing
some
neat
some
neat
stuff
about
it.
So
let
me
just
grab
a
a
jq
query,
because
I
keep
a
couple
of
these
stored
because
I
can't
ever
remember
jq
on
the.
B
B
So
here
I've
got
like
a
bill
of
materials
right
just
straight
up
bill
of
materials
about
what's
in
this
thing.
So
if
I
want
to
know
like
what
jdk
version
did
I
build
this
with
right?
It's
right
here.
You
know
what
you
know,
what
jre
versions
in
the
is
in
the
running
image
right
and
everything
everything
down
to
like
every
other,
dependent,
dependent
tool
and
library
that
got
pulled
in
right.
I
get
the
checksums
I
get
the
I
get
the
open
source
libraries
right
like
like
anything.
B
I
need
to
provide
programmatic
data
to
my
security
folks
right
so
talk
about
that
idea
of
contracts.
Right
like
we
all
want
to.
You
know
devops
devsecops.
We
want
to
talk
together
better
and
get
better
at
sharing
information
right
well,
like
a
lot
of
us
stay
bad
at
talking
right.
I
I
talk
a
lot,
but
not
everybody's
in
that
in
that
camp,
right
with
tools
like
cloud
native,
build
packs.
What
we've
got
now
is
contractual
interfaces
between
organizations
where
the
data
about.
What's
in
my
image,
isn't
something
I
have
to
send
over
to
security.
B
I
can
just
surface
it
run
a
little
scraper
in
my
container
runner,
assumibly
kubernetes,
pull
this
data
out,
send
it
over
to
logstash,
send
it
to
splunk
whatever,
and
they
can
write.
Queries
hey,
which
live
images,
have
a
jre
version,
that's
older
than
1.1.x
right,
making
sense
right!
That's
that's
another
thing.
B
So,
if
you
like,
I
can
hop
over
and
talk
about
talk
about
a
little
bit
more
about
how
these
images
build
and
just
show.
You
show
you
that
on
a
whiteboard-
and
I
can
talk
about
what
I
mean
by
a
rebase
right,
because
because
this
is
one
thing
building
your
containers
is
one
step
right,
but
that
life
cycle
involves
keeping
that
image
up
to
date
right
and
I'd
love
to
show
you
a
little
bit
about
how
you
can
how
you
can
do
that
sound.
Okay,
all
right,
I
had
a.
B
I
had
a
docker
captain
on
my
on
my
meetup
last
night.
He
wasn't
super
pleased
but
ended
up
getting
me
a
lot
of
questions
which
was
which
was
nice.
I'm
sure
that
was
a
little
awkward.
No,
he
loved
it
in
the
end
right,
but
it
was
you
know
he
had
to.
He
had
to
be
convinced
right
because
he's
been
writing
docker
files,
since
docker
files
were
a
thing.
B
I'm
sharing
my
screen
all
right
folks.
So
I
do.
I
do
a
lot
of
whiteboarding
here,
so
I'm
just
going
to
show
you
another
whiteboard
example
right.
So
here
what
I've
got
is,
is
some
color
coded
thing,
so
I'm
going
to
talk
about
stacks,
build
packs
in
your
custom
code
right.
The
stacks
are
gray
stacks.
Being
that
base
image
right.
The
build
packs
are
in
green
right.
B
That's
that
that's
that
that
tool
to
either
inspect,
compile
or
add
layers
to
your
code
and
then
custom
code
is
going
to
be
in
orange
cool,
so
start
with
a
stack
right.
So
when
we
build
an
image,
what
happens
here
is
that
we
actually
create
two
base
images
two
base
stacks
right,
because
it's
a
stack
of
layers
right,
that's
what
that's!
What
they're
referring
to
one
for
build
time
stuff
right
so
here
we've
got
our
build.
B
B
And
one
for
for
runtime
concerns
right.
What's
going
to
actually
be
in
that
in
that
live
running
environment,
important
important
difference
here
is
is
what's
actually
going
to
go,
live
to
your
kubernetes
clusters
and
what's
just
going
to
get
stored
locally
in
a
cache
now
so
so
say
we're
talking
about
that
that
spring
boot
app
that
we're
just
looking
at
right,
we
go,
we
go
contribute
some
build
packs.
We
evaluate
the
code,
we
see.
Okay,
it
is,
it
is
a.
B
It
is
a
a
java,
a
java
app,
so
we're
going
to
commit
we're
going
to
go,
contribute
the
the
open
jdk
here
to
this
image,
then,
on
top
of
it
we're
going
to
add
in
maiden
cool
those
are
our
build
time
layers,
but
we've
got
some.
We've
got
runtime
concerns,
so
things
like
the
jre
is
in
a
layer
and
the
jre
is
going
to
get
contributed
to
that
runtime
layer
tomcat
as
an
example.
It's
going
to
end
up
in
that
in
that
runtime
image.
B
You
know
it's
going
to
look
at
that
that
uncompiled
code
and
it's
going
to
put
it
on
the
on
that
build
stack.
Then
it's
going
to
run
the
compilation,
commands
and
and
provide
anything
else
that
my
runtime
image
is
going
to
need
to
consume
this
code,
and
then
our
compiled
jar
comes
over
here
in
the
runtime
in
the
runtime
stack
now.
B
Our
runtime
stack,
that's
going
to
get
contributed
to
our
registry
and
stored,
then
pulled
down
and
run
in
different
environments,
and
this
build
this
build
stack
here
is
going
to
be
cached
in
whatever
builder
that
we
have
so
with
with
one
spring
boot
app
every
time
it
rebuilds
we're
going
to
get
some
efficiency
gains,
because
because
it's
got
all
these
layers,
cached
right,
the
only
thing
that's
going
to
change
from
spring
boot
out
to
springboot
app
is
this:
is
this
top
this
top
layer
here
right?
That's!
That's
all!
That's
going
to
shift
that
build
time!
B
Stuff
is
going
to
stay
static,
right,
exact,
same
exact,
same
checksums
at
every
layer
right,
which
means,
as
you
go
look
at
your
registry.
The
same
is
true
for
the
runtime
right.
Only
those
top
application
layers
are
going
to
be
different
right.
The
the
layers
that
the
build
packs
and
the
stacks
contributed
are
going
to
be
the
same.
B
Send
that
whole
one
gig
one
time,
then
every
other
transfer
is
just
the
unique
layers
that
are
going
to
get
moved
up
right
so
already
you're,
looking
at
a
lot
less
stuff
moving
around
your
network
because
more
things
are
held,
true,
which
enhances
that
whole
repeatability,
which
is
how
we
get
faster,
builds
and
faster
rebuilds,
still
still
making
sense
all
right
moving
on
to
the
next
spot.
So
I
want
to
talk
about
what
happens
later
right
when
we've
got
when
we've
got
an
image.
B
That's
in
our
registry
or
a
number
of
images
that
are
in
our
registry
and
we
have
a
vulnerability
right.
Everyone
remembers,
everyone
remembers
a
heartbleed,
maybe
right
so
heartbleed
was
was
a
vulnerability
within
openssl
right,
which
is
a
really
base
library
that
a
lot
of
folks
are
using
right
that
basically,
everyone
uses
that
serves
up
web
traffic
right.
So
so
heartbleed
came
out
and
became
became
vulnerable,
and
then
we
had
to
go
around
and
race
the
repair
applications,
so
they
could.
B
They
could
maintain
the
behavior
that
we
had
before,
but
no
longer
no
longer
have
that
vulnerability.
A
lot
of
developers
had
to
get
spun
up
to
to
rebuild
and
re-test
their
apps
a
lot
of
devops
folks,
a
lot
of
security.
Folks,
there's
a
lot
of
work
going
into
that.
Let's
remediate!
Let's
remediate
this
this
issue
right
now.
Let's
talk
about
that
in
a
in
a
cloud-native,
build
packs
world
right.
B
So
as
we
look
at
as
we
look
at
the
next
version
of
heartbleed
comes
out,
open
ssl
goes
vulnerable,
and
here
I
have
an
example
of
one
of
a
hundred
one
of
a
thousand
images
right
in
my
registry.
They're
all
sharing
these
base
layers,
they've
all
got
open
ssl,
and
it's
it's
vulnerable
to
this.
To
this
very
serious
bug
right,
so
we
need
to
find
a
way
to
remediate
it.
So
so,
with
cloud-native
build
packs,
we
have.
B
We
have
rebuilds
that
need
to
rebuild
code
rebuild
intermediary
layers,
and
then
we
have
rebases
where
something
fundamental,
something
in
the
stack
is
made
vulnerable
and
the
stack
just
gets
replaced.
So
the
so
the
way
we
patch
the
stack
right,
whether
that's
provided
by
by
a
vendor
whether
it's
done
in-house
right.
B
The
way
we
we
we
patch
the
stack
is
we
patch
it
leveraging
something
called
avi
compatibility,
which
is
we
take
that
open
ssl
and
we
repair
it,
but
we
repair
it
in
a
way
where,
where
the
binary
interface
stays
the
same
as
the
old
one,
with
only
the
only
that
bad
behavior
removed
right.
So
what
that?
What
that
allows
us
to
do
right
if
you're
familiar
with
a
docker
image
right?
B
B
So
we're
going
to
do
the
same
thing:
you're
going
to
get
provided
either
by
your
platform
team
by
your
vendor
by
the
open
source
community,
a
patch
stack
right,
you'll,
upload
that
stack
to
your
container
registry
and
then
you'll
trigger
that
that
process,
that
cloud
native
build
packs
implementation
right
to
to
go
ahead
and
start
rebasing
images
and
rebasing
images
is
literally
going
into
the
registry
looking
at
the
manifest
file.
So
this
there's
a
little
manifestation
file
with
every
image
that
describes
what
layers
are
in
use
and
inside
that
manifest
file.
B
We'll
say:
hey
this
layer
here
that
you've
got
that's,
got
the
old,
open,
ssl
toss
it
replace
it
with
this
layer
here
that
we've
uploaded
to
your
registry
right
and
the
time
it
takes
to
rebase
an
image
in
this
way
is
the
time
it
takes
to
connect
a
web
request
up
to
your
registry
modify,
do
basically
a
put
on
a
json
file
to
modify
one
line,
and
then
it's
done
right.
So
I
can,
I
can
do
I
can
do
a
patch
on
on
10
30,
100,
1,
000
images
in
five
minutes.
B
When
I
do
demos
of
this,
when
I
show
people
I
I'll
go
in
and
I'll
show
them
patching
an
app
and
doing
a
rebase
and
then,
in
the
background
I've
replaced
30
apps
at
the
same
time,
and
then
I
show
them
after
that
fact.
So,
like
all
right
who
who
cares
about
patching
one
image,
I
can
patch
an
image
today
right,
and
so
you
show
that
you
can.
You
can
do
it
at
scale.
B
So
that's
what
I
mean
by
that's
what
I
mean
by
rebasing.
This
process
makes
sense.
I
know
it's
it's
it's
not
like
crazy,
straightforward
right,
but
but
when
you
understand
a
little
bit
about
what
what
is
in
a
docker
file,
you
can
see.
There's
there's
a
ton
of
power
here
or
the
way
a
docker
container
works.
There's
a
lot
of
power
here.
C
I
have
a
question.
Thank
you
so
much.
This
has
been
very
interesting
and
informative
and
I'm
very
excited
to
try
and
use
it
with
what
I
do
at
work.
Is
there
a
specific
way?
I
know
that
you
said
that
you
use
this
with
kubernetes.
Is
there
a
specific
way
that
it
benefits
kubernetes,
because
I
would
assume
once
you
have
an
image
it
kubernetes
wouldn't
care
as
much
is
there
some
extra
benefit
there
or.
B
So
it
benefits
kubernetes
in
the
sense
that
like
like
so
yes,
the
kubernetes
itself
doesn't
care,
but
your
apps
care,
because
you're
going
to
be
able
to
you're
going
to
be
able
to
run
and
repair
your
apps
much
faster
same
thing.
If
you've
got
a
cube
cluster
right,
imagine,
you've
got
you've,
got
a
few
different
ones
in
a
few
different
locations.
As
we
get
this
this
big
vulnerability
and
we
need
to
distribute
those
images
right
using
standard
image
builds.
B
A
lot
of
those
layers
are
unique
right
using
cloud-native
build
packs,
a
lot
of
them
are
shared.
So
when
it
comes
time
to
patch,
you
need
to
pull
only
that
that
vulnerable
layer
or
that
patch
layer
to
your
coop
clusters
right,
which
means
less
time
to
pull
the
image
less
bits
to
pull
around
right.
Let's
actually
have,
as
as
unique
data
on
the
actual
nodes
right
themselves,
so
less
less
cache
they
need
to
hold.
B
You
feel
me,
so
there's
there's
a
number
of
ways.
It
works.
I'll.
Tell
you
putting
this
tool
into
kubernetes
allows
you
to
leverage
custom
resource
definitions,
which
is
a
big
deal
right,
so
kubernetes
just
to
go
on
a
quick
tangent
kubernetes
is
really
powerful
because
it's
a
big
desired
state
reconciliation
engine
right,
which
means
basically,
I
just
say
what
to
do,
and
it
does
it
it
doesn't
just
do
it
once
it
keeps
doing
it
forever
like
every
two
seconds.
It's
trying
to
do
that
thing
that
I
told
to
do
you
know
six
months
ago.
B
So
if
I
register
a
hundred
images
with
a
kubernetes
cluster
and
tell
it
yo,
keep
these
images
up
to
date,
kubernetes
is
keeping
them
up
to
date
like
every
couple
of
seconds
all
the
time.
So
as
I
as
I
do
that
that
thing
where
I
say,
hey,
listen
update
this
stack
because
my
old
one
was
bad.
I
need
it
patched
right.
Kubernetes
is
going
to
go
through
and
be
like.
Oh
awesome
work
to
do,
let's
go
patch,
all
these
images
and
let's
do
it
right
now,
and
no
one
had
to
remind
it.
B
You
know
no
one
had
to
go
bug
your
developer
and
be
like
yo
dude.
Can
you
please
do
a
git
commit,
so
we
can
get
past
right?
Instead,
it's
just
nope
you're
patched
and
the
ci
right
that
continuous
integration
gets.
You
gets
you
an
updated
image
artifact
into
your
registry,
and
then
you
can
hand
off
to
whatever
your
delivery
process
is
to
validate
that
image
and
say
that
it's
good
to
go
in
production.
C
B
If
you
want
to
see
some
examples,
it's
pretty
easy
to
integrate.
If
you
already
run
a
ci
system,
it's
pretty
easy
to
integrate
with
a
ci
system.
So,
let's
see
what
do
I
have?
I
need
to
find
which
window
to
pull
up
so
I've
got
a
I've,
got
a
little
ci
server.
It's
broken
right
now,
but
but
in
my
in
my
ci
server
right
like
I,
I
take
source
code,
my
ci
server
monitors
the
source
code
runs
a
test,
so
a
maven
test
goes
and
runs
a
maven
build.
B
So
ignore
the
ignore
the
failed
one
that
just
happened.
It
runs
a
maven
build
right,
so
my
last
one
didn't
build.
But
that's
you
know,
that's
life.
It
compiles
the
code
and
then
it
hands
it
off
after
it
does
the
compilation
hands
it
off
to
an
implementation
of
this
cloud
native,
build
packs
where
I
get
this
inside
kubernetes
this
this
detect
this
analyze.
What
have
you
already
done?
Go
ahead
and
go
ahead
and
build
this
image
again
right,
hands
it
off
now
to
a
cluster
repo
right
where
I
can
store.
B
Note,
while
I
well,
I
know
we're
about
a
time,
but
I
just
want
to
put
this
out
if
you're,
using
docker
images,
there's
a
what
you
usually
see
like
like
when
you
see
like
latest
or
version
one,
two,
three
whatever
it
is,
that's
a
tag,
so
that
tag
is
actually
that's.
That's
for
humans,
not
not
for
computers,
and
it's
actually
mutable
right.
So
that
means
it
can
change.
B
B
It
updates
this
this
cluster
repo
and
then
my
continuous
delivery
kicks
off
and
and
slips
in,
but
but
whether
you're,
using
you
know
whatever
ci
tool
you're
using
or
you
can
integrate
with
a
cloud-native,
build
packs
implementation
right
and,
like
I
said
earlier
right,
like
gitlab
ci,
already
has
an
implementation
where
it
uses
this
natively,
and
you
can
see
an
example
of
integrating
it
with
a
kubernetes
based
implementation
of
cloud
native,
build
packs
actually
from
from
the
last
vmworld
all
right.
All
right
that
was,
it
didn't
mean
to
run
longer.
B
Yeah,
so
you
so
pack,
the
pack
tool
itself
requires
docker
right,
so
so
you'd
have
to
do
docker
and
docker
to
run
pack
natively
within
kubernetes
right.
That
being
said,
when
you
use
something
like
auto
devops
from
gitlab,
ci
they've
already
set
up
the
docker
and
docker
interface
and
then,
when
you
hand
it
off
to
a
native,
a
native
kubernetes
integration
like
like
kpop,
which
I
had
pulled
up
a
minute
ago,
but
let
me
just
pull
up
the
kpak
again.
B
B
B
C
B
Explained
in
a
ton
of
depth
when
we,
when
we
go
into
the
individual,
build
packs
right
so
and
these
are
all
open
source,
so
you
can
just
go
check
them
out
right.
So
they've
got
they've,
got
a
couple
interfaces
inside
the
build
pack
and
they
talk
about
it
a
lot
here
and
they
talk
about
a
lot
here
at
buildpacks.io
and
they'll
actually
walk
you
through
creating
your
own
build
pack.
If
you
want
to
see
it.
B
A
Yeah
one
question:
jason,
not
sure
it
is
a
right
question,
but
so
the
docker
images
has
always
like
issues
with
the
security
like
security.
It
could
have
a
lot
of
issues,
because
if
we
are
not
hardening
it
properly
it
it
will
have
some
open
holes
right.
So
does
this
particular
build
packs
helps
anyway,
to
make
it
simpler
to
harden
the
image
yeah.
B
So
it
it
does
some
things
by
default,
which
are
going
to
give
you
more
hardened
images
than
if
you're,
building
off
docker
files.
That
being
said,
right,
like
the
the
responsibility
for
hardening
hurting
those
base,
images
is
still
something
that
that
needs
to
be
handled
by
either
you
a
vendor
or
the
open
source
community.
So
it
does
some
things
that
are
more
secure
than
standard
docker
files
by
default.
Things
like
multi-stage,
builds
or
making
it
simpler
to
keep
keep
your
code
patched
and
up
to
date
right,
but
it
doesn't.