►
From YouTube: KubeCon EU 2020 – Booth Demo
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
the
pax
cli
has
a
bunch
of
different
commands
in
it,
but
the
one
that's
interesting
to
us
is
this:
build
command
and
in
the
build
command
we're
going
to
go
in
here
and
say.
I
want
to
create
an
image
based
on
this.
We
want
to
use
as
an
input
a
particular
jar
file
and
then
there's
just
some
other
stuff
that
are
going
to
make
sure
that
in
our
docker
environment,
things
build
well.
A
Pac
itself
is
simply
one
implementation
of
a
platform
that
uses
cloud
native,
build
packs
and
there
are
many
others
heroku
uses
it.
Vmware
uses
it
directly.
We
see
things
like
gitlab
using
it.
Google
using
it
bits
of
microsoft,
are
using
it
as
well.
It's
a
widespread
standard
that
many
people
are
using
and
pax
cli
just
happens
to
be
one
platform
that
happens
to
be
useful
at
the
cli.
A
So
let's
take
a
look
back
at
exactly
what
happened
here.
So
the
very
first
thing
we
saw
was
a
detecting
phase.
We
see
that
in
this
particular
instance,
there
are
16
possible,
build
packs
that
might
choose
to
participate
when
given
our
particular
jar
file,
but
each
build
pack
has
the
opportunity
to
decide
whether
or
not
it
wants
to
actually
participate,
and
so
we
see
that
five
of
the
build
packs
said
that
they
would
be
candidates
for
using
this
for
use
with
this
particular
jar
file.
A
So
if
we
take
a
look,
the
very
first
one
is
this
paquetto
bellsoft
liberica
build
pack,
and
what
this
does
is
it
goes
and
drops
a
jre
into.
Our
image
adds
some
other
stuff,
such
as
a
memory
calculator,
an
openssl
certificate,
loader
that
sort
of
does
things
to
help
a
jvm
run
inside
of
a
container
in
a
better
way.
It
turns
out,
it's
really
really
difficult
to
do
this.
We
want
to
make
it
as
easy
as
possible
for
as
many
applications
as
possible.
A
The
next
build
pack
that
participates
is
the
paquetto
executable
jar
build
pack,
and
what
this
one
says
is
I
recognize
this
is
an
executable
jar
file.
I
want
to
run
this
particular
command
java,
setting
its
class
path,
allowing
users
to
set
some
java
ops
and
then
finally
executing
a
particular
class
inside
of
it
and
then
finally,
we
have
a
third
kind
of
build
pack.
The
spring
boot
build
pack-
and
this
says:
hey.
Not
only
is
this
a
java
application
that
needs
a
jvm.
A
Not
only
is
this
an
executable
jar
file,
it
needs
to
be
run
this
way.
I
know
some
things
about
spring
boot
applications.
I
can
take
a
look
and
see
hey.
This
is
a
reactive
web
application
and
therefore
it
needs
a
certain
number
of
threads
dedicated
to
it.
I
know
that
you're
using
something
like
spring
cloud
and
you
want
to
do
service
binding,
so
we're
going
to
contribute
a
jar
file
to
that.
We
even
slice
up
the
application
itself
to
help
with
caching
and
deduplication,
and
we
set
some
image
labels
that
go
along
with
it.
A
A
We'll
be
using
a
utility
here
called
dive,
which
is
really
really
useful.
It
basically
allows
you
to
take
a
look
at
the
file
system
of
an
image
and
how
it's
pieced
together,
and
so
the
first
thing
we
see
is
the
first
couple
of
layers
here
are
a
bunch
of
different
things
that
are
effectively
an
ubuntu
bionic
operating
system
being
set
up
with
all
of
its
certificates
and
things
like
that
and
then
eventually
we
get
to
where
we
start
doing,
contributions
from
the
build
pack.
A
We
see
that
a
layer
has
been
created
that
has
a
class
counter
on
it,
maybe
some
security
properties.
Eventually,
we
get
to
the
point
where
we
see
a
jre
has
been
contributed.
It's
full
standard
jre.
We
set
some
other
environment
variables,
the
certificate
loader
we
mentioned
earlier.
We
go
and
we
take
a
look
at
the
spring
boot
clock
build
pack,
we
see
the
spring
cloud
bindings
jar
file
is
going
to
be
there
and
eventually
we
get
to
the
actual
application.
A
This
is
a
standard
spring
boot
application
with
all
of
its
dependencies
on
one
layer,
the
loader
application
jar
launcher
on
another
layer.
The
application
itself
just
called
demo
application
on
yet
a
third
layer.
We
split
these
up
so
that
they
have
different
life
cycles.
They
change
at
different
rates
dependencies,
don't
change
nearly
as
much
as
applications
do,
which
means
that
that
20
meg
layer
with
all
of
your
dependencies
on
it
is
likely
already
cached
on
your
edge
nodes
or
is
deduplicated
inside
of
a
a
registry
saving
you
space,
saving,
you
transfer
time.
A
So
we
say
we
can
build
an
image
using
these
build
packs,
and
that
was
pretty
quick.
If
we
take
a
look,
we
saw
that
it
was
about
17
seconds
to
do
that
particular
build.
But
what
happens
if
we
do
that
build
again,
oh
build.
A
If
we
do
that
exact
same
build
again,
we
actually
can
take
advantage
of
a
lot
of
the
de-duplication
of
layers
that
are
already
part
of
this
image.
We
know
that
we
were
going
to
contribute
belsoft,
liberica
11.0.8
previously
right.
We
did
that
we
can
download
a
very
small
amount
of
metadata
to
say.
Am
I
going
to
contribute
the
same
thing?
If
I'm
going
to
contribute
the
same
thing?
Don't
transfer
any
data
at
all.
Just
use
here
is
a
pointer
to
that
layer.
A
I
want
you
to
include
that
layer
again
when
it
comes
time
to
build
this
thing,
and
this
is
sort
of
a
trivial
example
where
nothing
has
changed,
and
so
all
of
the
layers
are
rebuilt.
We
see
that
this
time
around
it
happened
in
something
very
small,
my
limits
around
five
seconds,
so
something
less
than
five
seconds
to
actually
rebuild
this.
But
what
you
see
is
we
see
a
lot
of
reuse
if
one
thing
had
changed.
A
For
example,
if
we
had
a
different
version
of
jre
that
would
have
been
the
only
layer
that
was
recreated.
If
I
change
something
about
the
web
application
type,
that's
the
only
layer
that
ends
up
getting
recreated.
So
this
is
all
sitting
on
a
registry,
and
we
say
that
what's
created
is
a
standard,
oci
or
docker
image
file.
That
means
it
can
run
on
any
platform
such
as
kubernetes.
I
can
run
it
in
this
case.
A
The
platform
that
we
want
to
run
it
on
is
actually
my
local
docker
demon,
so
we'll
go
ahead
and
do
a
docker
pull
for
this.
Go
ahead
and
grab
that
particular
jar
file.
We
already
had
it
from
dive
and
we'll
go
ahead
and
do
a
docker
run
this
time
and
what
we
see
is
the
application
startup.
We
see
some
stuff,
such
as
how
the
the
java
memory
configuration
is
calculated.
We
see
it,
add
a
bunch
of
certificates
to
the
jvm
trust
store.
A
So
that's
really
really
interesting,
but
we
can
also
go
beyond
that
because
of
the
way
build
packs,
create
their
images
they're,
not
necessarily
what
you
sort
of
think
of
in
the
old
way
of
docker
images
being
created
where
every
single
line
in
a
docker
file
is
dependent
on
the
execution
of
the
line
above
it,
which
means
that
if
you
change
any
top
level
line
or
if
you
change
the
from
statement
specifically,
you
have
to
rebuild
absolutely
everything
underneath
it
build
packs.
A
Have
this
concept
called
rebasing
and
rebasing
basically
says
if
you
have
a
stack
or
an
operating
system
right,
we
know
what
layers
those
are
versus
the
layers
that
the
build
pack
contributed
and
your
application
contributed.
We
can
say
hey
what
we
want
to
do
is
actually
take
all
of
the
upper
layers,
the
stuff,
that's
not
the
operating
system
and
pick
them
up
and
put
them
on
top
of
a
different
operating
system.
This
is
really
commonly
used
to
deal
with
security
vulnerabilities.
A
If
there's,
for
example,
another
heartbleed
kind
of
thing
coming
up
open,
ssl
has
a
vulnerability
in
it.
What
we
want
to
be
able
to
do
is
say
how
do
we
get
your
applications
to
be
safe
as
quickly
as
possible
and
that's
not
to
rebuild
every
single
image
it's
to
take
all
the
images
you're
currently
using
and
put
them
on
top
of
a
new
version
of
the
operating
system,
rather
than
rebuilding
your
java
application
from
scratch.
A
So
we
have
a
command
for
that.
A
command's
called
pac
rebase,
I'm
going
to
put
time
in
front
of
it
because
it
happens
so
quick.
I
want
you
to
see
exactly
how
quick
it
comes,
and
so,
in
this
case
we're
going
to
say,
hey.
I
want
you
to
take
that
previously
existing
image
and
put
it
on
top
of
a
different
run
image.
In
this
particular
case.
It's
version
0
0
6.
A
So
if
we
execute
this,
we
see
it
happen,
and
according
to
this,
it
happened
in
0.2
seconds
right.
We
effectively
went
to
a
registry
downloaded
just
the
metadata
about
this
image.
None
of
the
actual
image
data.
We
took
a
look
at
all
of
the
layers
that
were
referenced
in
it,
removed
the
layers
that
were
responsive
or
were
the
old
version
of
the
operating
system
added
in
a
bunch
of
new
layer,
pointers
to
the
new
layers
in
the
operating
system
and
then
push
that
metadata
back
up
to
the
registry.
A
A
We
go
and
we
download
just
the
new
layers
for
the
operating
system,
the
stuff
that
com
that
came
out
of
our
particular
application
already
exist
locally.
We
don't
get
any
new
data
for
this
and
then,
finally,
we
can
do
a
docker
run
and
now
we're
starting
that
exact
same
application
without
changing
the
jre
that
was
on
it
without
recompiling
the
java
or
changing
any
of
the
configuration
parameters
or
even
rebuilding
the
image.
Really,
we
can
restart
that
with
a
new,
safer
version
of
the
operating
system.