►
From YouTube: Cloud Native Live: Slim.AI
Description
Comparing different minification techniques and their vulnerability assessments
A
A
So
every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
cloud
native
technologies.
They
will
build
things,
they
will
break
things
and
they
will
answer
all
of
your
questions
so
join
us
every
wednesday
to
watch
live
this
week.
We
have
martin
luther
here
to
talk
with
us
about
comparing
different
minification
techniques
and
their
vulnerability
assessments
and
another
great
news
from
the
kubecon
and
cloud
native
comes
here.
A
The
america
north
america
cfp
has
been
pushed
to
june
3rd,
so
everyone
still
has
time
to
submit
their
sessions,
so
go
ahead
and
get
that
done
so
great
to
hear.
So
this
is
an
official
live
stream
of
the
cncf
and
as
such
it
is
subject
to
the
cncf
code
of
conga.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
kind
of
conduct.
B
Hello,
it's
great
to
be
back
on
cncf
live.
I
think
we
were
here
about
five
months
ago,
and
today
we
have
a
slightly
different
topic,
so
we're
going
to
be
talking
about
a
container
images
and
looking
specifically
at
managing
sort
of
complexity,
of
container
image
management
versus
the
size
of
the
container
images
versus
sort
of
the
security
of
the
container
images.
B
B
B
So
the
first
question
is:
why
should
you
slim
container
images
so
very
clearly,
you
should
only
ship
into
production
what
you,
what
your
application
requires-
and
I
see
gibran
says:
is
there
a
presentation,
visual
so
yet,
hopefully,
you'll
get
the
link
in
chat
in
just
a
moment
to
this
article
which
you
can
review
after
the
fact.
Oh,
they
only
see
a
blue
screen.
B
B
A
B
A
Yeah,
I
see
everything
fine
as
well,
sometimes
with
with
the
streaming
earth.
It
can
help
the
quality.
If
everyone
closes
the
tabs,
they
have
don't
have
at
least
they
have
opened
a
lot
of
tabs,
including
all
of
the
others,
but
that
might
not
help
in
this
case,
but
worth
the
shot,
and
then
we
do
have
our
host
is
letting
us
know.
A
B
So
that
all
looks
fine,
I
mean
I,
like
I
say
I
I
can
see
what's
being
shared
in
the
event
yeah
everyone's
saying
it's
not
visible.
It
will
be
necessary
to
see
my
screen
later
on.
Unfortunately,
but
for
the
moment
I
can
explain
what's
going
on
here,
so
we
believe
you
should
only
ship
into
production.
What
your
app
requires.
B
B
A
B
B
We
can
share
screens
we'll
give
some
practical
examples
of
actually
how
we're
doing
this.
So
the
tools
that
we're
going
to
be
using
today
is
the
slim,
ai,
docker,
desktop
extension,
because
we
can
use
that
to
introspect
the
container
images
and
do
some
deep
exploration
and
analysis
of.
What's
in
the
container
images
we'll
be
using
docker
slim
to
minify
or
optimize.
The
containers
and
we'll
also
be
using
sift
well,
not
not
so
much
using
it.
B
But
we'll
use
data
from
sift
to
sort
of
catalog
the
number
of
packages
that
our
containers
have
and
then
trivi
to
do
some
security
analysis
and
then
we'll
be
doing
some
manual.
So
diving
into
the
containers
in
order
to
actually
see
what
happens
when
we
optimize
a
container
what
residual
vulnerabilities
are
left
behind,
if
any
at
all,
so
we'll
be
going
through
that
whole
process.
B
Now,
what
are
we
going
to
be
looking
at
we're
going
to
be
looking
at
container
construction
in
the
first
instance,
and
in
order
to
do
that,
we
have
a
very
simple
python,
flask
app
that
implements
an
even
simpler
restful
api
and
the
application
is
kind
of
irrelevant
it's
for
illustrative
purposes.
Only
and
its
function
is
unimportant
and
as
it
happens,
it's
exactly
the
same
application
we
used
when
we
were
here
last
time
when
we
talked
about
building
analyzing
and
optimizing
containerized
images.
So
it's
a
python
flask
gap.
B
B
So
it
seems,
unfortunately,
that
the
that
everyone
that's
watching
the
live
stream
is
not
seeing
any
any
visuals.
But
if,
if
the
link
can
be
shared
to
the
article,
then
I
can
talk
through
where
we
are
in
the
article
and
explain
what's
going
on.
This
will
get
tricky
when
we
get
towards
like
how
we
do
the
deeper
analysis
of
the
containers,
because
that
is
a
very
visual
process.
A
I
I
trust
this.
I
trust.
Usually
the
cloud
native
line
is
very
visual,
so
the
podcast
format
is
very
challenging
for
sure,
but
let's
get
the
link
shared
to
the
chat,
but
there
it
is
to
be
an
issue
on
possibly
on
youtube
side
currently,
but
we
are
still
working
on
it
for
sure.
But
let's
get
that
link
shared
and
then
we
can.
We
can
talk
to
it.
B
B
The
first
thing
we
did
is
as
it's
a
python
application.
We
went
to
the
official
python
docker
hub
images
and
we're
using
the
python
3.9
slim
bullseye
image,
so
you,
if
you're,
not
familiar,
that,
obviously
means
it's
a
python
orientated
image
from
the
python
project.
It's
python
3.9
it's
what
they
consider
to
be
their
minified
or
slim
image,
and
it's
built
against
debian
bullseye,
which
is
debian
11,
and
that
base
image
is
129
megabytes.
B
B
B
That's
now
being
shared
of
a
live
stream.
We
did
where
we
actually
sort
of
dug
into
that
live
and
again
used
exactly
the
same
tools
we're
going
to
be
using
today
in
order
to
determine
exactly
why
it
was
five
megabytes,
larger
and
then
finally,
we're
going
to
use
a
distrolus
python,
3
image
and
that's
going
to
be
a
multi-stage,
build
and
that
image
weighs
in
at
54
megabytes.
A
It
appears
that
it
is
not
working
correctly
at
the
moment
there
is
we're
trying
to
fix
it,
obviously
in
the
background,
but
the
article
has
been
shared
to
people.
So
if
there's
anything
that
we
can
run
through
there,
this
audio
only
podcast
style.
I
think
that
would
be
really
great,
but
yes,
we're
trying
to
get
the
the
video
feed
working
as
well.
B
Okay,
on
my
one
moment,
just
bear
with
me
I'm
just
doing
my
own
and
checking
in
the
background
I'll
come
back
to
that.
So
if
you've
got
the
link
to
so,
we
have
a
question
here
from
rolf.
Is
this
cloud
native
foundation
live
comparing
different
minification
techniques
and
their
vulnerability
assessments?
B
Yes,
essentially,
yes,
we're
going
to
be
looking
at
precisely
that,
and
also
the
impact
of
starting
with
different
base
images
on
the
minification
process
and
the
outcome
of
the
security
profile
of
the
containers,
so
you're
in
the
right
place:
rolf
you're
among
friends,
okay
and
I'm
just
looking
yeah.
Okay,
when
I
I
I
understand
now
what
people
are
saying
about
a
blue
screen
they're
not
talking
about
the
screen,
I
am
sharing
they're
talking
about
the
whole
screen.
B
So
I
would
ask
for
those
of
you
that
are
following
along
to
drop
down
to
the
title
that
says:
dockerfile
complexity
and
what
we're
going
to
do
now
is
we're
going
to
actually
look
at
about
half
a
dozen
different
dockerfiles
that
are
containerizing
the
same
application
using
those
different
base
images,
so
we're
going
to
start
with
the
python
what
these
will
be
tags
in
the
images
that
we
create
later.
So
I'm
opening
this
on
my
screen.
B
I
know
that
you
can't
see
it,
but
maybe
you
can
follow
along
as
well
so
in
in
this
dockerfile.
What
we're
looking
at
here
is
a
very
simple
container
image.
We
just
have
to
use
the
python
3.9
slim
bullseye
image.
All
of
this
adheres
to
bet
best
practice.
We
establish
our
working
directory,
we
copy
our
requirements
file
in
we
run
pip
without
caching
any
data
to
install
the
pip
requirements
for
our
app.
We
then
copy
in
our
application
itself.
B
We
tell
the
app
what
user
it
should
run
under
what
port
it
should
run
under
and
we
define
a
well-defined
entry
point.
So
this
is
a
adheres
to
best
practices,
very
simple,
docker
file.
So,
in
terms
of
the
complexity,
it's
simple
and
it
adheres
to
best
practice.
So
now
what
we'll
do
is
we'll
take
a
look
at
the
alpine
based
image
and
again.
This
is
using
a
python
base
image
published
by
the
python
project.
It's
3.9
and
it's
our
point:
3.1
alpine
3.15,
and
it's
almost
identical.
B
B
Now
it
is
entirely
possible
to
add
those
I've
elected
not
to
do
that
for
simplicity
and
sort
of
show
some
of
the
differences
in
these
different
techniques.
So
consequently
you
could
say
that
this
container
image
does
not
adhere
to
best
practices
as
it's
currently
defined
because
it
doesn't
run
the
application
in
an
unprivileged
user
or
system
account,
and,
like
I
say,
if
we
added
some
extra
steps
to
this
dockerfile,
we
could
do
that.
I've
just
chosen
not
to
fur
the
purposes
of
simplicity,
and
you
know
highlighting
the
differences
in
the
techniques.
B
B
Now,
as
somebody
that's
familiar
with
ubuntu,
so
I
used
to
work
at
canonical.
In
fact,
I
was
the
engineering
director
for
canada
for
ubuntu.
While
I
worked
there,
so
I'm
very
familiar
with
ubuntu
so,
but
this
does
introduce
some
additional
complexity
in
that
we
have
this
run
statement
which
does
our
apt-get
updates.
It
then
apt
installs,
some
that
basically,
the
python
requirements,
the
minimal
python
interpreter
and
pip,
and
we
also
need
this
certificates
bundle.
B
B
B
B
We
will
see
later
on
so
this
these
images
we
will
tag
with
no
wreck
in
order
to
distinguish
between
a
full
ubuntu
image
and
also
one
where
we've
tried
to
create
a
slim
image,
but
all
of
these
ubuntu
images
adhere
to
best
practices
and
then,
lastly,
we
have
a
distro
less
image,
and
this
is
where
we
need
a
bit
more
knowledge,
and
this
is
a
more
complex
docker
file
for
several
reasons.
First
of
all,
it's
a
multi-part
dockerfile
and
also
we
need
to
know
something
about
how
distrolus
works
with
python.
B
So
I'm
going
to
sort
of
talk
about
what
that
is
now
there's
some
things
that
are
common
with
alpine
here.
In
that
there
are
no
user
accounts
defined
or
no
system
accounts
either.
So
we
don't
have
we
and
again
we
could
have
created
those
with
additional
steps,
but
I've
elected
not
to
for
the
purposes
of
simplicity.
B
But
what
we
do
is
we
create
a
build
stage
where
we
install
our
app
and
all
of
its
requirements
via
pip,
and
then
we
create
the
the
production
container
and
that's
where
we
then
use
the
distrolus
python
3
image,
and
then
we
copy
from
our
build
image
the
app
itself
and
then
those
python
packages
that
were
installed
via
pip.
So
the
the
benefit
here
is,
we
can
create
a
container
that
is
smaller
and
we'll.
Look
at
that
in
a
moment
when
compared
to
other
debian-based
images,
but
the
trade-off
here
is.
B
A
B
Going
to
reshare
my
screen
so
that
you
can
see
what
I'm
looking
at
here.
So
if
you're
not
familiar
docker
desktop
recently
added
his
support
for
extensions
and
slim
ai
were
among
the
first
to
use
that
program.
So
what
I'm
going
to
look
at
is
the
distrolus
container
and
I'm
gonna
analyze
that,
because
I
had
a
hunch
that
this
was
based
on
debian,
but
it
was
like
well
what
version
of
debian
is
it
based
on?
A
If
anyone
joined
in
late,
we
are
doing
duty,
technical
difficulties,
we're
essentially
having
a
podcast
style
for
now
trying
to
figure
out
the
issues
in
the
background.
But
a
recording
of
this
will
be
available
after
the
session
and
I,
for
example,
can
see
the
screen.
So
the
recording
will
have
all
of
the
screen
share
and
all
of
the
graphics
and
our
lovely
faces
in
it
as
well.
So.
A
B
B
I
can
see
that
it's
using
python
3.9,
so
these
were
important
clues
that
I
needed
in
order
to
understand
how
to
create
my
build
container
with
a
container
from
the
python
project
that
was
compatible
with
the
distro-less
container.
That
I
was
using
for
my
production
container,
but
this
all
adds
a
degree
of
complexity.
B
Hang
on
a
moment,
let's
go
here,
because
I
I
now
need
to
know
a
bunch
of
different
things,
so
I
need
to
have
some
deeper
insight
into
how
python
works.
I
need
to
set
my
python
path
to
the
correct
version
of
python.
I
need
to
know
how
to
copy
the
python
site
packages
into
the
appropriate
location
for
the
distroless
container,
so
the
complexity
of
maintaining
that
container
image
goes
up,
so
that's
sort
of
a
review
of
those
container
those
dockerfiles
and
how
they
differ
from
one
another.
B
Now
I've
pre-built
all
of
these
docker
images,
except
for
one.
So
what
I'm
going
to
do
is
I'm
going
to
build
each
one
of
just
one
of
those
container
images,
I'm
going
to
illustrate
how
we
do
this
so
we're
going
to
build
the
version
of
the
container
image
that
is
based
on
the
official
python
project
image,
that's
debian
based
and
if
we
then
go
back
to
the
presentation
here,
we
can
now
take
a
look
at
the
sizes
of
these
respective
containers
when
they've
been
built
with
our
application.
B
B
We
have
to
choose
to
use
alpine
when
we
know
we're
not
going
to
introduce
build
time,
issues,
build
time,
performance
issues
or
runtime
compatibility
issues
and,
as
I
said,
we
were
able
to
use
the
slim
ai
docker,
desktop
extension,
to
discover
that
the
distrolus
container
is
based
on
debian
11
and
python.
3.9
we've
already
illustrated
why
those
two
bits
of
information
are
important
in
order
to
create
a
container
that
works.
B
B
It
can
work
on
just
file
systems,
but
we're
using
a
container
image
here
and
if
we
so
that
just
took
a
few
seconds
to
run,
I
know
you
can't
see
my
screen
right
now
unless
you're
watching
the
recording
after
the
fact.
But
if
we
return
back
to
the
article,
we
learn
a
couple
of
things.
So
what
we're
looking
at
here
is
well,
there
must
be
a
correlation
between
number
of
packages
and
size
of
container
images,
and
certainly
that's
borne
out.
B
So
this
in
itself
is
interesting,
and
certainly
you
can
inspect
those
reports
in
order
to
understand
exactly
which
packages
are
in
your
container
image.
But
this
gets
more
interesting
when
we
move
on
to
vulnerability
analysis,
which
is
the
next
thing
we're
going
to
look
at
and
we're
going
to
be
looking
at
going
to
be
using
trivi
in
order
to
do
our
vulnerability
analysis,
other
security
scanners
are
available.
B
This
is
the
one
that
we're
using
primarily
for
today's
example,
so
I've
just
switched
over
we're
going
to
run
this
again,
and
this
is
scanning
my
container
and
it
produces
a
very
nice
report
indeed.
So
you
can
see
that
on
my
screen,
but
what
we'll
do
is
we'll
look
at
like
summary,
information
of
the
vulnerability
and
analysis
when
run
against
each
of
those
containers
in
turn.
Now
what
we
learn
here
is
there
is
no
denying
that
the
alpine
results
are
excellent
here
it
has
zero
vulnerabilities.
B
But
then
we
see
some
sort
of
interesting
information
here
so
distrolus,
which
is
a
small
image.
Actually,
that
has
three
critical
vulnerabilities
and
seven
high
vulnerabilities
and
the
official
python
image
which
is
built
on
debian
has
two
critical
vulnerabilities
and
15
high
vulnerabilities.
So
that's
quite
the
jump
from
a
a
clean
bill
of
health
with
alpine,
but
then,
when
you
look
at
the
ubuntu
based
images,
even
those
that
have
not
been
optimized
in
any
way
by
a
sensible
use
of
apt,
they
have,
they
all
have
zero
critical
vulnerabilities
and
only
one
of
them.
B
So
in
actual
fact,
irrespective
of
the
number
of
packages
or
the
size
of
the
image
when
using
ubuntu,
there
are
zero,
critical
and
zero
high
vulnerabilities
in
all
of
those
container
images,
which
then
begs
the
question:
how
is
that
possible?
You
know
why
is
this?
Ubuntu
is
derived
from
debian,
so
why
is
it
so
very
different?
B
And
again
I
used
to
work
for
canonical.
I
have
some
insight
here
and
I'm
going
to
squash
this
down
very
quickly,
which
is
ubuntu,
is
a
commercially
backed.
Linux.
Distro
are
with
a
full-time
security
team
that
has
slas
to
mitigate
vulnerabilities
for
their
customers
and
there's
a
link
to
the
documentation
that
describes
exactly
what
the
commitment
to
security
within
ubuntu
is,
and
that
commitment
also
includes
mitigating
all
critical
and
high
vulnerabilities
for
the
supported
lifetime
of
the
distribution.
B
And
so
when
you
compare
that
with
debian,
which
is
a
community
project,
and
while
many
contributors
to
debian,
including
myself,
do
fix
security
issues
in
debian,
it
simply
cannot
provide
the
same
level
of
commitment
to
security
as
the
commercially
backed
linux
distribution.
Vendors
such
as
canonical
red
hat
and
souza
do
so.
This
is
a
very
important
point
when
you're
choosing
your
base
image,
it's
not
just
about
choosing
something
that
is
smaller.
B
It's
about
choosing
something
that
is,
has
a
better
security
stance
by
default,
and
I
think
these
numbers
sort
of
illustrate
that
point
which
maybe
not
many
people
are
aware
of
in
terms
of
what
the
security
benefits
might
be.
So
this
then
presents
a
couple
of
what
ifs
it's.
What
if
I
could
have
the
low
complexity
of
maintaining
ubuntu-based
containers
with
the
security
profile
of
alpine
we've
just
seen.
You
know
no
vulnerabilities
as
a
result
of
using
alpine,
what
if
I
can
make
container
images
that
are
smaller
than
alpine.
B
So
let's
try
that
and
what
we're
going
to
do
here
is
we're
going
to
use
docker
slim
to
minify
the
container
images,
but
we
could
equally
use
the
slim
ai
developer
platform
to
do
the
same
thing,
but
for
the
purposes
of
this
demonstration,
I'm
just
going
to
copy
this
one
line.
Here,
I'm
going
to
go
back
to
my
terminal
and
I'm
now
going
to
minify
this
container
image.
B
Now
we're
not
going
to
talk
about
the
internals
of
how
this
works,
because
that
was
the
topic
that
we
talked
about
when
we
were
last
here
with
the
cncf,
so
we'll
just
push
forward
and
we
have
a
minified
container
image.
So
I'm
now
going
to
switch
back
to
the
presentation
which
has
a
table
of
the
results.
B
B
I
know
some
of
you
watching
live,
can't
see
my
screen
so
I'll
quickly
run
down
here,
but
in
terms
of
the
size,
all
of
the
images
are
between
20
and
26
megabytes,
once
they've
been
minimized
using
docker
slim
and
at
the
lower
end.
That
means
on
distro,
less
we're
looking
at
about
a
3x
reduction
in
size,
the
same
for
alpine
for
the
ubuntu
images,
we're
looking
between
a
5
and
17
times,
reduction
in
size
and
for
that
debian
image.
B
We're
looking
for
our
six
times
reduction
in
size,
but
now
we've
really
leveled
the
playing
fields
in
terms
of
the
size
of
the
images
and
we've
also
gone
beyond
what
we
get
by
using
just
alpine
alone.
You
know:
we've
significantly
reduced
the
size
of
our
container,
so
the
next
question
is
well.
If
we
now
have
far
fewer
files
inside
our
container
image
has
that
removed
vulnerabilities.
B
So
we'll
start
by
we're
going
to
pick
a
particular
container
image
at
this
point.
So
we're
going
to
look
at
the
container
image
that
was
built
with
ubuntu
2204
that
also
didn't
install
the
container
image
up.
There
didn't
install
the
recommended
packages
that
we
have
now
minified
with
docker
slim,
and
we
already
know
that
that
container
image
is
free
of
critical
and
high
vulnerabilities.
B
So
what
we're
able
to
do
is
actually
use
the
docker
desktop
extension
from
slim
ai
to
go
and
look
inside
those
container
that
container
to
see
is
there
any
residual
files
left
behind
from
those
vulnerable
packages
that
we
should
be
concerned
about?
So
what
we're
going
to
do
is
we're
going
to
use
the
docker
desktop
extension
to
open
that
container
image,
and
that
will
just
take
a
moment
here.
B
It
is
and
we're
looking
at
the
all
layers
view
here
and
what
we're
going
to
do
is
we're
going
to
use
the
search
criteria
to
actually
go
and
peek
inside
the
container
to
see
if
any
of
the
vulnerable
bits
are
left
behind.
So,
for
example,
I
know
that
all
of
the
extended
two
file
system
utilities
start
with
e2f,
so
we're
going
to
go
and
search
for
that
and
then
we'll
flatten
the
results
to
make
it
easy
to
see.
Oops
oh
bother
just
bear
with
me
a
moment.
I've
just
clicked
clicked
a
button.
B
I
shouldn't
have:
let's
go
back
to
there.
We
go.
Let's
go
back
here
so
we'll
flatten,
flatten
the
results
and
we'll
put
our
search
criteria
in
and
it
comes
back
with
no
information,
so
the
extended
two
utilities
are
absent
from
the
container
and
we
can
do
the
same
thing
by
looking
at
this
library,
which
is
related
to
the
same
vulnerability.
B
B
B
So
what
we
can
do
is
when
we
look
at
this
vulnerability
analysis.
We
can
see
they're
all
actually
the
same
cve
relating
to
the
same
issue,
so
it's
to
do
with
male
caps.
So
what
we'll
do
is
we'll
we'll
we
craft
this
search
term
and
before
we
go
and
look
at
the
minified
container.
What
we're
going
to
do
is
verify
that
this
search
term
is
actually
the
way
that
we
should
identify
that
this
vulnerability
exists
in
the
fat
containers.
B
So
I'm
going
back
to
my
fat
version
of
this
container
and
I
am
searching
for
male
cap
and
fla,
I'm
going
to
flatten
the
results
for
simplicity
and
we
can
see
it's
a
pure
python
module
and
we
can
also
see
the
what's
called
the
bike:
the
compiled
byte
code.
So
this
mail
cap
does
exist
in
the
fat
container
and
therefore
the
fat
container
does
indeed
carry
this
particular
vulnerability.
B
B
So
that's
the
fundamental
library
that
just
about
all
applications
are
linked
against
and
that
remains
in
both
the
python
based
image,
the
the
debian
based
official
image
from
the
python
project
and
also
the
distro-less
containers,
unlike
ubuntu,
where
that
cve
has
already
been
mitigated,
and
unlike
alpine,
where
that
vulnerability
never
existed
by
virtue
of
the
fact
that
alpine
uses
muscle.
So
this
highlights
again
the
importance
of
choosing
the
right
base
image
in
order
to
generate
the
most
appropriate
security
stance
for
your
container
images.
B
So
we'll
move
on
to
some
conclusions
here.
Firstly,
I'm
not
going
to
suggest
that
you
should
never
use
alpine
or
distrolus,
particularly
if
you're
working
with
go
or
rust.
Then
they
are
good
choices,
particularly
if
you
use
the
destroyerless
static,
debian
base
image
with
go
and
rust,
but
to
recap:
slimming
container
images
is
a
vital
process
in
the
software
supply
chain.
It
can
reduce
the
attack
surface,
it
can
increase
deployment.
Momentum
start
increased
startup
performance
and
it
requires
no
changes
to
your
existing
container.
B
Build
processes
unlike
having
to
learn
multi-part
builds
with
distroless
or
switching
to
alpine,
which
may
well
be
unfamiliar
and
vulnerability.
Scanners
can
produce
false
positives,
so
there's
an
argument
to
be
made
for
using
multiple
vulnerability
scanners
and
actually
cross-checking
the
results,
and
it's
also
trivial,
to
inspect
your
container
images
to
verify.
If
vulnerable
components
are
present
or
not
so
don't
rely
just
on
the
results
of
the
scanners.
B
So,
what's
the
outcome
of
all
of
this,
I
would
choose
to
use
the
jammy
no
wreck
docker
file.
This
is
based
on
ubuntu
2204,
which
came
out
just
last
month.
It
by
default
has
a
better
security
posture
than
2004
and
we
did
a
live
stream,
live
stream,
talking
about
being
a
tech,
debt
warrior
and
moving
to
newer
releases
as
fast
as
possible,
and
here's
why
ubuntu
makes
sense
for
the
purposes
of
the
evaluation.
Here
I
work
in
a
team
familiar
with
ubuntu.
B
B
B
So,
in
conclusion,
comparing
about
caring
about
image
size
demonstrates
that
you
care
about
the
quality
of
the
containers
you
deploy
into
production.
Introducing
slimming
into
your
container
production
workflow
can
considerably
reduce
image
complexity
and
reduce
the
attack
surface,
while
maintaining
development,
velocity
and
adhering
to
best
practices.
B
A
No
worries
perfect.
That
was
exactly
put
so
everyone.
If
you
want
to
see
it
a
new
version
of
this.
You
can
tune
in
tomorrow
to
just
leave
my
eye
twitch.
Also,
the
recording
of
this
with
the
video
in
text
and
the
shared
screen
and
all
of
the
example
visuals
will
be
shared,
will
be
available
immediately
in
the
cncs
for
cloud
native
computing
foundation.
Youtube
channel
immediately
after
the
stream
ends.
So
do
not
worry
the
visuals
will
be
available.
A
B
That's
exactly
correct,
so
you'll
have
to
watch
the
video
recording
after
the
fact
to
see
what
I'm
about
to
share
on
my
screen,
but
I'm
going
to
compare
two
container
images:
the
traditional
fat
container
and
the
one
that
was
slimmed
using
docker
slim.
But
the
first
thing
to
explain
is
that
the
slim
image
that
docker,
slim
or
slim
ai
creates
is
a
single
layer,
container
image
that
only
includes
inside
it
precisely
what
that
application
requires
in
order
to
function.
B
So,
yes,
a
a
whole
new
container
image
is,
and
it's
as
if
it's
a
from
scratch
image
only
using
those
assets
from
the
original
image
that
are
actually
required
for
the
app
to
run
and
what
I'll
do
is.
If
I
go
here
so
I've
got
this,
I'm
using
the
docker
desktop
extension,
and
we
have
this
compare
feature.
So
I'm
going
to
compare
this,
not
this
one,
sorry,
the
one
that
we've
been
referring
to,
so
the
jammy
no
wreck
image
with
the
slim.
Oh,
I
did
it
wrong.
B
B
B
B
So
you
can
see.
Sort
of
you
know
the
impact
that
this
is
going
to
have
on
not
just
the
security
profile,
but
the
performance
impact
of
of
this
container,
and
last
week
when
we
were
at
kubecon,
we
were
speaking
to
a
number
of
organizations
who
saw
using
this
minification
technique
as
a
way
to
make
the
mess
go
away.
B
They
they
were
working
with
customers
who
who
were
supplying
container
images
to
them
and
they
were
operating
the
infrastructure
for
them
and
whilst
those
container
image
may
well
have
been
functional,
they
absolutely
did
not
adhere
to
best
practice
and
would
have
dozens
and
dozens
of
layers,
for
example,
ambi
multi
gigabyte
in
size,
so
they're
looking
at,
and
we
have
customers
like
this
using
this
technology.
In
order
to
actually,
you
know
clean
up
the
containers
to
make
them
production
ready,
regardless
of
how
those
containers
were
created.
In
the
first
instance,.
A
B
A
Perfect
then,
I
think
it's
about
to
try
to
wrap
up.
If
there's
any
questions
you
can,
maybe
maybe
it's
it's
time
to
wrap
up.
You
don't
have
time
for
any
more
questions
back
up
again,
always
oh
there's
immediately
when
I
say
that
what
input
slash
configuration
doesn't
use
for
dynamic
analysis
that
affects
the
flow
path.
B
B
Api
endpoints
and
whether
they're,
what
methods
they
use
and
what
the
success
and
error
conditions
look
like,
and
you
can
pass
that
into
the
observation
piece
and
so
it
can.
It
can
hit
all
of
those
endpoints
to
fully
exercise.
You
know
your
micro
service
and
similarly,
if
your
user,
if
you've
got
a
web
application,
you
can
provide
a
list
of
all
of
the
url
endpoints
that
your
application
has
in
order
to
exercise
it
completely
and
even
then
you
may
bump
into
situations
where
not
all
of
your
static
assets
get
loaded
through.
B
You
know
your
integration
tests.
We
saw
an
example
recently
with
a
static
website
with
an
image
carousel,
and
not
all
of
the
images
in
the
carousel
got
loaded.
So
you
can
even
stipulate
paths
within
the
container
image
that
should
always
be
absolutely
included
or
excluded
for
that
matter,
but
there's
a
whole
whole
gamut
of
options
in
order
to
sort
of
tune.
The
before
the
behavior
of
the
observation.
A
Great
but
yeah
apologies
again
for
the
technical
difficulties,
but
now
it
is
time
to
wrap
up,
but
at
the
same
time
now
that
we
wrap
up
the
recording
will
be
available
when
the
csvf
youtube,
so
you
can
actually
see
with
the
visuals
there
or
you
can
tune
in
tomorrow,
for
example,
tuesday.
May
I
twitch
to
see
a
new
version
of
today's
session
and
ask
more
questions.
A
There
also,
obviously,
there's
probably
a
lot
of
info
in
the
article
that
was
linked
within
the
stream,
where
you
can
find
a
host
of
things
to
to
follow
up
on
the
materials,
but
as
always,
thank
you,
everyone
for
joining
the
latest
episode
of
cloud
native
live.
It
was
really
great
to
have
martin
here
talking
about
comparing
different
minification
techniques
and
their
vulnerability
assessment.