►
From YouTube: Commit Virtual 2020: Creating Production Ready Containers with Cloud Native Buildpacks
Description
In this session we will cover the basics of Cloud Native Buildpacks and show how they can be leveraged from GitLab pipelines. By the end of this talk you’ll understand how you can make short work of building images in a secure, repeatable way.
Building production-grade container images with confidence and ease has become a critical element to achieving productivity and success, yet presents significant challenges. Cloud Native Buildpacks make it quick and easy to go from source to container image for a variety of languages, while providing security, auditability, transparency, and control for building and patching images.
Speakers:
Cora Iberkleid - Developer Advocate, VMware
Andreas Evers - Sr. Solutions Architect, VMware
Get in touch with Sales: http://bit.ly/2IygR7z
A
A
Cloud
native
apps
tend
to
be
based
on
container
images
which
have
to
be
frequently
rebuilt,
cora
and
andreas.
Take
us
through
the
evolution
of
building
container
images
as
they
zero
in
on
the
current
state
of
the
art
which
they'll
demonstrate.
The
use
of
this
is
great
stuff.
Let's
dive
in,
and
don't
forget
that
if
you
have
any
questions
or
comments,
you
can
chat
with
the
speakers
and
other
attendees
during
and
after
the
talk
using
the
chat
function.
B
B
Great
so
today
we're
going
to
be
giving
a
basic
intro
to
different
ways
that
are
common
for
building
images
and
then
we'll
walk
you
through
the
cloud
native
build
tax
project
in
particular.
We'll
do
a
few
demos,
both
outside
of
gitlab.
So
you
can
see
how
you
can
use
this
locally
at
your
command
line
and
then
we'll
show
you
how
it
works
within
gitlab
and
then
we'll
cover
some
additional
features
of
the
buildbacks
project
and
we'll
wrap
up
with
a
summary.
So
with
that
go
ahead
and
dress
with
the
intro.
C
All
right
thanks
a
lot
for
that
cora,
let's
jump
right
in
so
this
should
look
pretty
familiar
to
people
in
a
lot
of
organizations.
You
start
off
with
code
in
a
git
repository,
your
ci
pipeline
builds
an
application
artifact,
after
which
you
deploy
that
artifact
into
an
environment
which
is
managed
by
an
operations
team.
However,
kubernetes
is
quickly
becoming
the
platform
of
choice
and
is
shifting
responsibilities
to
the
left
into
csd
pipeline.
C
It's
a
responsibility
such
as
building
an
image,
including
any
middleware
and
operating
system
batching.
The
entire
stack
as
time
goes
by
making
sure
that
everything
is
secure
and
everything
is
done
according
to
compliance
and
accountability
standards.
So
this
really
begs
the
question,
but
are
the
sweat
and
tears
that
we
were
experiencing
farther
on?
The
right
of
this
flow
are
now
going
to
shift
left
or
maybe
we
can
prevent
that
increased
complexity
and
making
it
an
easier
process
for
ourselves.
C
C
C
C
There
are
a
few
solutions
out
there,
with
each
their
respective
pros
and
cons
and
for
java
one
choice,
that's
been
very
popular
is
jib,
it
builds
quickly,
there's
no
local
docker
dependency
and
it
integrates
seamlessly
with
your
maple
or
green
maven
or
gradle
workflows.
Sorry,
where
it
falls.
A
little
short,
though,
is
that
it
doesn't
have
a
centralized
governance
mechanism
think
about
how
teams
would
update
these
images.
C
How
organizations
would
like
to
have
visibility
on
the
different
versions
of
base
images
running
in
production
over
time
and
scale,
you're
still
going
to
find
a
lot
of
variants
across
your
images
and
that's
going
to
increase
the
risk
of
the
estate
and
chip
and
docker
files?
Don't
really
help
manage
that
risk
in
any
way,
and
that's
where
buildbacks
might
offer
a
solution?
C
C
Now,
hiroku-ish
aims
to
bring
the
idea
of
the
heroku
build
packs
to
kit
lab
without
actually
having
to
run
the
heroku
platform
and
since
2017
gitlab
has
a
new
feature
called
autodavos
and
it
uses
hiroquish
and
buildbacks
in
cat
in
case
you're
not
familiar
with
autodevops.
The
idea
is
to
provide
a
cicd
pipeline
without
the
need
for
any
yaml
configuration
or
dockerfiles
for
the
build
and
test
sections
of
the
autodevops
pipeline.
C
This
is
a
project
that
was
initiated
by
pivotal,
which
is
now
vmware
and
heroku
about
two
years
ago
to
improve
upon
the
older
model
of
buildpacks,
while
also
leveraging
the
modern
technology,
the
modern
container
technology.
Actually
that
has
evolved
more
recently
pivotal
and
heroku
have
a
nearly
10
year,
history
of
building
and
supporting
enterprise-grade
buildbacks.
So
all
of
that
knowledge,
all
of
that
code
can
be
taken
and
tailored
to
work
with
kubernetes.
C
So
cloud-native
buildbacks
is
a
unified
standard
that
enables
an
ecosystem
of
build
platforms
and
modular,
build
packs
with
the
goal
of
taking
source
code
and
producing
docker
images
that
can
then
be
stored
in
any
registry
of
your
choice
and
deployed
on
any
docker
runtime
and
also
gitlab
has
adopted.
Cloud-Native
buildbacks
in
the
auto
develops
pipelines
and
heroku-ish
has
been
deprecated
in
favor
of
cloud-native
buildbacks.
B
B
So
as
an
end
user,
the
two
sort
of
elements
that
you'll
be
interacting
with
most
often
when
you're
working
with
cloud
native,
build
packs
is
a
platform
and
the
actual
build
packs,
and
the
platform
is
the
tool
that
you
use
as
an
end
user.
It
could
be
a
cli,
it
could
be.
A
service
may
be
hosted
on
kubernetes.
It
could
be
a
maven
or
gradle
plug-in.
There
are
different
platforms
that
will
give
you
the
ability
to
use
build
packs.
B
The
build
packs
are
distributed
on
an
image
called
a
builder
image
which
acts
as
your
build
time,
environment
and
that
build
time
environment
that
build
image
also
includes
a
piece
of
software
called
the
life
cycle,
which
contains
the
generic
orchestration
logic
that
any
platform
would
have
to
execute
in
order
to
take
advantage
of
build
packs.
So,
rather
than
have
every
pla
form
or
build
pack
implementation
write
this
generic
code.
The
cloud
native,
build
text
project
provides
this
reference
implementation
and
a
build
pack
builder.
B
Image
can
simply
incorporate
that
and
make
it
available
to
the
platform
and
then
there's
a
reference
to
a
slimmer
run
image,
because
you
don't
want
your
build
tooling,
like
you,
wouldn't
want
your
jdk
to
be
deployed
to
your
production
environment
right.
You
only
need
a
jre,
so
the
build
time
environment
is
one
image
and
the
runtime
environment
is
a
slimmer
second
image
and
the
components
of
like
your
jaw.
B
Your
your
comp,
your
compiled
class
files,
for
example,
would
be
transferred
from
the
build
image
to
the
run
image
to
produce
the
image
that
you're
going
to
deploy
into
your
production
environment.
So
the
as
I
mentioned,
there's
an
ecosystem
growing
around
this,
because
what
the
project
offers
is
the
platform
api
and
the
build
packs
api,
so
they're
really
just
establishing
this
unified
standard,
as
andreas
mentioned,
in
order
to
support
a
growing
ecosystem
around
this
and
so
from
a
platform
perspective.
B
There's
the
ecosystem
currently
includes
the
pax
cli.
So
pac
is
a
cli
that
gives
you
an
imperative
tool
with
which
you
can
build
images,
and
this
is
actually
the
reference
platform
implementation.
That's
provided
by
the
cloud
native
bill,
packs
project
itself
recently,
for
example,
spring
boot
and
spring
boot,
230
introduced
support
for
cloud
native,
build
packs
in
its
maven
and
gradle
plug-ins.
So,
if
you're
familiar
with
jib
the
spring
boot
plug-ins
give
you
a
similar
experience,
but
they
use
the
cloud-native,
build
packs
project
to
produce
an
oci
image.
B
So
with
a
maven
package
or
gradle
cradle
build,
you
would
have
an
image
that
has
all
of
the
goodness
of
cloud
native,
build
packs.
K
pack
is
a
service
that
you
can
install
on
kubernetes
and
configure
it
declaratively
that
can
operate
at
scale
to
build
and
update
images
and
so
on.
So
the
ecosystem
is
growing,
which
is
which
is
nice
to
see
and
on
the
builder
side,
there's
also
a
growing
ecosystem,
heroku
and
pivotal,
of
course,
have
taken
their
previous
set
of
cloud.
B
Foundry
and
heroku
build
packs
and
updated
them
to
comply
with
the
cloud
native,
build
packs
standard,
and
so
you
have
the
heroku
build
packs
and
the
paquetto
build
packs.
Are
the
evolution
of
those
cloud
foundry
build
packs,
but
here
there's
also
a
growing
ecosystem.
Google
cloud
platform
recently
came
out
with
a
set
of
build
packs.
Vmware
tanzu
is
a
commercial
superset
of
the
paquetto
build
packs.
B
Both
ecosystems
are
growing,
and
so
what
I'm
going
to
demo
for
you
is
using
the
pax
cli
and
the
paquetto
build
packs
together
to
create
an
image
and
the
tax
cli
is
actually
what
the
cloud
native
integration
in
gitlab
is
using.
We'll
show
you
that
in
a
second
okay,
so
in
this
directory,
I'm
just
going
to
build
a
simple
go
application.
It's
just
a
hello
world
application
written
in
go,
but
as
a
point
of
comparison,
since
dockerfile
is
sort
of
one
of
the
most
common
way,
the
oldest
way
to
build
docker
images.
B
B
So
the
first
one
is
the
build
environment
and
so
we're
using
an
image
called
golang
publically,
available
on
docker
hub
that
has
the
tooling
necessary
in
order
to
build
the
source
code
into
a
runnable
application
and
then
the
second
code
block
the
second
build
stage
as
it's
called
in
docker
file
starts
with
a
the
a
more
minimal
base.
So
in
this
case
we
can
get
away
with
the
most
minimal,
which
is
scratch,
but
it
really
depends
on
what
language,
what
framework
you're
using
and
it
copies
the
binary.
B
That
was
created
during
the
build
stage
into
what's
going
to
be
your
runtime
image
and
then
establishes
what
command
should
be
run
when
this
image
is
run
as
a
container
to
execute
this
docker
file,
you
would
use
the
docker
cli
your
docker
file
and
your
source
code
would
be
sent
up
to
the
docker
demon.
The
docker
demon
would
run
the
the
docker
file
and
produce
the
final
image.
So
when
we're
talking
about
the
cloud
native
build
packs
project,
there's
some
comparisons,
we
can
draw
so
the
base
image.
B
So
what
would
be
the
in
this
case
the
golang,
the
build
image
and
the
runtime
image
the
in
this
case?
The
scratch
in
this
example
would
be
coming
from
the
build
packs
implementation
project
and
so
we're
using
paquetto
buildpacks
for
this
demo,
so
that
that
already
provides
the
builder
provides
the
actual
run,
build
image
and
it
has
a
reference
to
the
run
image
to
use
in
that
builder.
Image
are
all
of
the
build
packs,
so
the
build
packs
are
the
pieces
that
would
basically
provide
all
of
the
other
commands
in
your
docker
file
right.
B
All
of
the
other
knowledge
and
intelligence
to
produce
an
image
from
your
particular
application
and
the
pac
platform
as
well
as
that
piece
of
software
I
mentioned
called
the
lifecycle.
That's
also
in
the
builder
image
together
play
the
role
of
the
docker
cli
and
the
docker
demon
in
order
to
orchestrate
the
production
of
the
final
image.
So
I'm
going
to
show
you
an
inspection
pack
allows
you
to
inspect
both
builders
and
images.
B
So
first
I'll
show
you
an
inspection
of
the
builder
itself,
so
you
can
see
what's
included
inside
of
it,
and
you
can
see,
for
example,
that
this
particular
builder
supports
several
frameworks.
Java
node
go
etc,
so
it
works
well
as
a
default
builder.
I've
already
set
that
as
my
default
builder,
in
fact-
and
I
have
a
go
application,
so
I
know
that
it'll
work
and
then
I
can
see
the
full
list
of
build
packs
that
are
included
in
this
builder.
B
So
you
can
see
that
for
every
build
pack,
there's
multiple
for
every
length
for
every
framework,
there's
multiple
build
packs
that
might
participate
in
a
build,
and
so
there's
this
detection
order.
That's
established
that
enables
the
process
to
auto
detect
which
build
packs
to
use
for
a
particular
application.
There's
also
some
more
metadata
here
about
the
image
that
we're
going
to
use
for
runtime
and,
for
example,
I
can
see
the
stack.
So
this
is
an
ubuntu
stack
for
both
the
build
time
and
the
runtime.
B
So
with
that,
I'm
going
to
show
you
the
build
command
so
again
we're
using
pac
as
a
platform,
which
is
a
cli
and
all
we
do
is
call
pac
build.
I
don't
have
to
specify
the
builder
because
I've
set
it
as
my
default
on
my
machine,
and
I
just
provide
an
arbitrary
name
for
my
image
and
I've
we're
in
the
we're
in
the
directory
where
the
source
code
live.
So
it's
going
to
look
in
the
local
directory
and
I've
already
pre-downloaded
that
builder
image.
B
So
I'm
just
saying
no
pull
so
I'm
not
pulling
from
the
internet
to
make
it
a
little
bit
faster.
So
what
you
see
now
is
the
different
stages.
The
platform
is
orchestrating
the
life
cycle
stages,
and
so
these
stages
of
detection,
analyzing,
restoring
building
exporting,
are
the
different
stages
of
the
orchestration
of
producing
an
image.
Those
are
the
generic
stages,
and
so
you
can
see
during
the
detection
we
go
through
that
detection
order
in
the
builder
and
it
automatically
determines
which
build
packs
applied
in
my
application,
the
analyzing
and
restoring
stages.
B
I've
already
built
this
image
once
on
my
computer
before
so
I
have
the
prior
built
image
with
its
metadata,
as
well
as
a
local
cache.
So
the
process
can
now
take
advantage
of
both
of
those
sources
of
information
to
make
subsequent
builds
more
efficient.
So
that's
what's
happening
between
analyzing
and
restoring
and
then
the
actual
build
is
where
every
build
pack
that
was
detected
is
relevant
is
executed
one
after
the
other
right.
B
So
you
can
see
here's
one
build
pack
and
then
the
second
build
pack
is
here
and
then
the
third
build
pack
that
was
detected
is
run
here
and
each
build
pack
is
producing
layers.
So
the
most
of
this
logging
is
coming
from
the
orchestration,
the
generic
orchestration
from
the
life
cycle.
But
what
you
see
inside
of
the
build
stage
that
comes
from
the
build
packs,
so
this
is
coming
from
the
paquetto
build
packs
in
particular
right
these
this
pieces
of
logging.
B
Now,
once
that's
done,
the
layers
that
are
relevant
for
runtime
are
exported
to
the
run
image
and
the
layers
that
might
help
subsequent
builds
be
more
efficient,
like
the
go.
Compiler
are
cached
locally
and
finally,
we
have
our
our
image
to
use.
So
if
I
can
look
at
my
docker
images,
I
can
see
go
demo.
B
C
C
C
By
the
way,
it's
quite
useful
to
have
access
to
the
source
code
behind
autodevops,
it's
basically
just
a
bunch
of
cell
scripts,
which
aim
to
provide
the
border
plate
code
at
80
of
the
pipelines
out
there
typically
duplicate
the
auto
devops
developers
have
written
this
for
you,
so
you
won't
have
to.
In
that
sense,
it's
very
similar
to
spring
boot.
Auto
configuration
if
you're
familiar
with
that
framework,
manipulating
that
default
behavior
is
also
fairly
straightforward.
C
The
first
one
enables
cnb
or
gladiator
buildback's
beta
functionality
and
turns
off
the
use
of
herokuish
for
for
building
images,
and
this
is
the
only
required
flag
or
variable
if
you
wish
to
use
clarinet
buildbacks
in
gitlab
auto
levels.
The
second
one
sets
the
builders
you'd
wish
to
use.
In
our
case,
this
would
be
the
picado
builders
with
the
third
variable
you
could
pass
in
a
specific
url
where
bill
packs
can
be
found.
C
We
can
define
the
same
variables
as
the
previous
approach,
but
now
as
part
of
the
yaml
file.
As
you
can
see
here
now,
there's
a
number
of
things
that
we
added
here,
let's
go
through
them,
so
we've
bumped
the
java
version
to
14.star
from
11.,
which
is
the
default
we've
also
added
maven
settings
to
enable
running
of
tests
during
the
builds
during
the
maven
build.
Now.
C
This
is
just
to
demonstrate
how
you
could
run
tests
as
part
of
your
pacado
or
cloud-native
build
packs
in
general,
using
exactly
the
same
platform
as
your
builds
and
we've
also
added
in
a
custom
build
pack
here,
hello,
world
and
in
the
before
script
we
we
can
add
any
logic
on
top
of
the
other
type
of
default
behavior,
and
currently
we
clone
the
buildbacks
sample
the
samples
repository
and
reference
that
in
the
buildback
url.
As
you
can
see
here,
okay,
let's
take
a
look
at
the
logs
of
this
pipeline
run.
C
So
if
we
take
a
look
at
this
builds
stage
here,
you
can
see
it
has
succeeded,
but
the
logs
are
a
bit
too
too
big.
So
I've
opened
them
here
and
tried
to
colorize
them
a
bit
and
sadly,
there's
no
real
plugin
for
this
in
chrome.
So
you'll
have
to
bear
with
me
here.
Let's
take
a
look
at
the
detection
phase.
That
cora
was
talking
about.
C
As
you
can
see,
it
has
detected
that
my
application
in
my
repo
is
a
java
application
with
spring
boot,
and
it
has
selected
a
set
of
buildbacks
that
it
can
execute
for
this
particular
build
for
this
particular
repo.
As
you
can
see,
we're
using
the
gvm
bellsoft
liberica
build
pack,
which
has
always
has
a
dock
link
here
or
a
link
to
the
homepage,
which
is
very
useful.
C
If
you
want
to
get
more
information
about
how
the
buildback
works
internally-
and
you
also
get
environment
variables
that
you
can
set
specifically
for
this
buildback
and
in
this
case
we've
set.
This
we've
set
it
to
14
for
the
java
version,
and
indeed
it
has
also
propagated
that
variable
and
then
there's
also
the
maven
build
back
here,
which,
if
you're,
if
you're,
actually
using
gradle
it
will,
it
will
scrap
this
out
for
the
gradle
one.
C
We
can
also
see
that
if
we
look
at
test
run
or
tests
run
that
indeed,
tests
are
being
run
now
as
part
of
the
maven
package
and
to
finalize
the
hello
world
custom.
Build
pack
is
indeed
printing
successfully
all
the
environment
variables.
So
basically
it's
pretty
straightforward
to
use
your
own
custom
build
packs.
If
you'd
like,
let's
go
back
to
the
slides
right
now,
cora,
I
will
take
a
closer
look
at
some
of
additional
features
of
canadian
buildbacks.
B
B
We
already
saw
an
inspection
on
the
builder,
I'm
going
to
show
you
how
you
can
inspect
an
image,
and
then
I
want
to
talk
to
you
about
this
feature
called
rebasing,
which
is
swapping
out
the
operating
system
layer.
So
this
is
an
incredibly
powerful
security
feature
and
think
about
a
situation
like
heartbleed
or
spectre,
where
there's
a
vulnerability
in
the
operating
system
and
as
an
enterprise,
you
might
need
to
patch
hundreds
or
thousands
of
virtual
machines
or
container
images,
and
so
this
in
in
the
case
of
cloud-native,
build
packs.
B
So,
with
an
oci
image,
the
oci
image
is
represented
by
a
manifest
that
has
pointers
to
these
various
layers
and
so
with
a
rebase
operation.
What
happens
is
that
you
get
a
new
image,
a
new
manifest
file
which
has
its
own
new
sha,
but
the
pointers
in
that
new
manifest
are
pointing
to
the
same
application
or
build
pack
layers
as
the
previous
image,
and
only
the
pointers
to
the
run
image
are
updated,
and
so
this
operation
happens
within
a
few
seconds
on
a
local
machine.
It
can
happen
in
sub
sub.
B
Second,
on
a
registry
and
with
something
like
the
pax
cli.
Of
course
you
do
this
imperatively,
one
image
at
a
time
and
with
a
platform
like
kpac,
which
you
is
the
one
that
gets
installed
as
a
service
configured
declaratively
on
kubernetes,
for
example,
that
can
operate
on
at
scale
and
do
an
operating
system
patching
of
all
of
your
images
in
a
very,
very
quick
amount
of
time.
So
I'm
going
to
show
you
that
as
well
as
inspections
now
so
from
the
transparency
point
of
view,
let's
do
the
inspections.
B
First,
I'm
going
to
be
using
the
same,
the
image
that
andreas
just
built,
which
is
right
now
in
the
gitlab
registry,
for
that
java
application.
So
I'm
going
to
use
the
pack
inspect
image
command.
So
previously
I
showed
you
the
inspect
builder
command.
Now
I'm
doing
an
inspect
image
and
giving
it
the
image
name.
Now,
if
I
just
provide
the
first
part
of
this
command,
that
will
give
me
metadata
provided
at
the
orchestration
level
so
which
build
packs
were
used.
What
versions
were
they?
B
But
if
I
add
this
minus
minus
bom,
which
stands
a
bill
of
materials
flag,
then
it
gives
me
information
provided
by
the
individual,
build
facts
right.
So,
in
this
case,
it'll
be
information
provided
by
the
paquetto,
build
packs
that
were
applied
for
the
java
application.
Now
that
returns
json.
So
I'm
actually
going
to
show
you
that
in
a
browser
because
it's
easier
to.
B
B
Okay,
so
we
can
see,
for
example,
information
added
by
the
bellsoft
liberica
the
jvm
build
pack,
so
we
can
see
that
the
jdk
and
the
jre
are
both
version
14..
So
that's
again,
very.
If
you
look
at
this
from
an
operational
point
of
view,
you
have
an
image.
The
ability
to
to
take
that
image
and
inspect
it
and
know.
What's
inside
of
it
is
incredibly
powerful.
B
So
we
have
that
kind
of
information
and
just
as
an
example,
if
I
scroll
to
the
bottom
of
the
file,
I
can
even
see
that
the
custom
build
pack
was
applied
last
so
that
build
pack
itself
doesn't
add
too
much
to
the
metadata.
But
it's
definitely
identified
and
then
before
that
the
spring
boot
build
pack
was
was
a
prior
one
to
run,
and
it
so
happens
that,
with
a
spring
boot
build
pack
with
paquetto
that
actually
adds
all
of
the
java
dependencies,
as
well
as
their
as
their
version
into
the
metadata,
the
informational
metadata.
B
The
way
that
that
would
work
is
that
I
would
you
can
do
this
on
the
registry
itself
as
well,
but
I'm
going
to
show
you
this
demo
running
locally
on
my
machine,
so
I'm
pulling
down
the
image
that
andreas
just
built
on
gitlab
and
then
I'm
going
to
so
this.
This
next
docker
poll
is
basically
saying
that,
let's
say
there's
a
vulnerability
found
on
the
image
that
exists,
but
a
new
operating
system
was
released.
B
So
this
is
me
obtaining
that
new
operating
system,
so
downloading
that
new
run
image
and
I'm
going
to
do
the
rebase
locally
on
my
machine
using
the
same
builder
as
before,
and
that
builder
is
looking
for
a
base
image.
That's
tagged
as
base
cnb,
so
I'm
just
taking
this
updated,
fixed
image
that
I
just
downloaded
and
re-tagging
it
locally.
B
So
that
my
builder
will
find
it
so
then
all
I
have
to
do
I'll
show
you
the
different
images
that
are
here,
but
I
have
this
is
so
this
is
the
existing
image
id
and
then
I
have
the
the
run
images.
So
I
have
the
old
one
here
which
is
ida5d,
which
is
the
the
one
with
say,
heartbleed
or
spectre
in
it.
That's
now
untagged
and
the
new
fixed
one
is
now
tagged
as
bcmb
and
just
for
convenience.
I'm
going
to
go
ahead
and
save
the
old
id
of.
B
B
And
now
I'm
going
to
run
the
pack
rebase
command,
and
so
this
on
a
local
machine.
It
does
take
a
few
seconds,
but,
as
I
mentioned,
this
is
a
sub
second
operation
on
a
registry
and
it
can
be
run
out
at
scale
with
a
with
a
platform
like
kpac,
so
incredibly
powerful
from
a
security
perspective.
But
this
basically
so
it's
produced
a
new
image
so
that
so
I
have
a
patched
image
and
just
to
show
you
what
that
actually
does.
B
In
the
background,
the
docker
inspect
command
gives
you
the
sha
of
every
layer
so
including
the
root
file
system
layers.
So
if
I
compare
the
old
and
the
new,
you
can
see
that
three
of
the
layers
and
the
root
fs.
These
are
the
root.
Fs
layers
have
changed,
but
there's
no
other
difference
to
the
manifest
file.
So
that's
a
rebase.
B
So
now
I'm
going
to
go
back
here
and
just
just
to
wrap
up
with
a
few
summaries,
so
we
hope
that
this
has
given
you
a
good
insight
into
how
cloud
native
build
packs
works
and
what
the
benefits
are.
So
as
a
project,
it's
extremely
easy
to
use.
You
saw
the
pack
build
command
the
pack
rebase
command.
Of
course,
git
lab,
auto
devops
makes
it
even
easier,
but
it
basically
is
a
project
that
establishes
its
unified
standard
and
therefore
fosters
a
growing
ecosystem
of
both
platforms
and
build
packs.
B
It
works
for
a
variety
of
languages,
any
language
implemented
by
a
build
pack
implementation.
So
it
really
is
applicable
to
many
many
applications.
It
it's
very
efficient
and
sophisticated
in
its
caching
system
and
its
data
transfer
optimizations.
It
has
sophisticated
methods
like
the
rebase,
which
is
powerful
for
security.
B
It
encourages
and
enables
this
modularization
of
build
functionality,
and
it
gives
you
this
transparency
and
inspection
capabilities
both
into
your
builders,
as
well
as
your
images
and
the
paquetto
build
packs
in
particular,
as
you
saw,
they
support
various
frameworks.
They
incorporate
best
practices
for
each
of
these
frameworks.
They
include
the
base
images
with
the
avi
compatibility
guarantee
they're
actively
ablated
updated.
So
you
have
the
latest
patches,
both
in
in
upstream
for
runtimes,
as
well
as
os
packages
available.
B
B
You
know
further
your
knowledge
into
cloud-native,
build
packs,
and
if
you
found
this
interesting,
then
hopefully
you'll
be
interested
in
passing
in
stopping
by
our
virtual
vmware
booth
and
hopefully
joining
our
demo
on
the
demo
stage
later
on
in
the
gitlab
conference,
which
you
can
find
online.
So
thanks
a
lot
for
joining
us.
Thank
you.